JP2010009195A - バッチ処理方法、バッチ処理プログラム、リクエスト実行装置、および、データベースシステム - Google Patents

Abstract

【課題】データベース管理システムにおいて、バッチ処理の中断が発生しても、バッチ処理を効率的に実行する。
【解決手段】ＤＢサーバ３のＳＱＬ制御部３４は、バッチ処理が中断前の状態と判定されるときには、実行要求されたリクエスト内容を実行し、その実行に伴うデータアクセスをディスク装置８に対して行い、そのデータアクセスの読み込み結果であるデータ内容を返却データとして格納し、その返却データを返却し、バッチ処理が中断後の復帰状態と判定されるときには、実行要求されたリクエストの実行を省略するとともに、履歴管理データにおいて実行要求されたリクエスト内容に対応する返却データを実行要求元であるＡＰサーバに返却する。
【選択図】図３

Description

本発明は、バッチ処理方法、バッチ処理プログラム、リクエスト実行装置、および、データベースシステムに関する。

データベース管理システムにおいて、ＳＱＬ（Structured Query Language）などで記述されるリクエストにより発生するディスクアクセスを削減する技術として、データベース管理システムの更新ログを出力しない処理方法がある。

バッチ処理に対して更新ログを出力しないことで、ディスクアクセスを削減し、バッチ処理時間を短縮することができる。なお、バッチ処理とは、データベース上のデータに対して実施するリクエスト（検索、更新など）を、複数回まとめて一度に行うように指定する処理を指す。

バッチ処理は、データベースのオンライン業務が停止する夜間に実行されるため、翌朝のオンライン業務が開始するまでの規定の時間内に確実に終了することが求められる。バッチ処理が規定の時間内に終わらない場合には、バッチ処理を一旦中断し、翌晩などに再度オンライン業務を停止し、バッチ処理を最初から復帰実行する。

特許文献１では、中断したバッチ処理の自動復帰実行を行う旨が開示されている。
特開平０３−２２５４３４号公報

前記特許文献１の技術では、データベース管理システムの更新ログを出力しないため、バッチ処理を中断した場合、その復帰に時間がかかってしまう。この技術では、事前に取得しておいたバックアップを用いてデータベース管理システムをバッチ処理実行前の復帰状態に戻した後、バッチ処理を最初から復帰実行する。つまり、最初のほうに実行されるバッチ処理は、中断前と中断後とで重複して実行されるため、非効率である。

そこで、本発明は、前記した問題を解決し、データベース管理システムにおいて、バッチ処理の中断が発生しても、バッチ処理を効率的に実行することを、主な目的とする。

前記課題を解決するため、本発明は、バッチ処理を実行するバッチ実行装置と、バッチ処理から呼び出されるリクエストを実行するリクエスト実行装置と、リクエストの実行に伴うデータアクセスの対象となるデータを格納するディスク装置と、を用いるデータベースシステムにより実施されるバッチ処理方法であって、
前記バッチ実行装置のバッチ処理部が、
バッチ処理の実行を要求されると、そのバッチ処理を実行し、そのバッチ処理から指定されるリクエストの実行結果が必要になると、実行中のバッチ処理とそのリクエスト内容とを指定して前記リクエスト実行装置にリクエストの実行を要求し、
前記リクエスト実行装置のリクエスト制御部が、
リクエストの実行が要求されると、前記バッチ実行装置からの中断要求の通知の有無により、そのリクエストに対応するバッチ処理が中断前の状態か、中断後の復帰状態かを判定し、
バッチ処理が前記中断前の状態と判定されるときには、実行要求されたリクエスト内容を実行し、その実行に伴うデータアクセスを前記ディスク装置に対して行い、
そのデータアクセスがデータの読み込み処理であるときには、読み込み結果のデータ内容を返却データとして、前記実行要求されたリクエスト内容に対応づけて記憶手段内に履歴管理データとして格納し、その返却データを実行要求元である前記バッチ実行装置に返却し、
そのデータアクセスがデータの書き込み処理であるときには、前記実行要求されたリクエスト内容を前記記憶手段内に前記履歴管理データとして格納し、
バッチ処理が前記中断後の復帰状態と判定されるときには、前記実行要求されたリクエスト内容が前記記憶手段内の前記履歴管理データに存在するか否かを検索し、
前記履歴管理データの検索処理で前記実行要求されたリクエスト内容を発見できたときには、実行要求されたリクエストの実行を省略するとともに、前記履歴管理データにおいて前記実行要求されたリクエスト内容に対応する前記返却データを実行要求元である前記バッチ実行装置に返却し、
前記履歴管理データの検索処理で前記実行要求されたリクエスト内容を発見できなかったときには、前記実行要求されたリクエスト内容を実行し、その実行に伴うデータアクセスを前記ディスク装置に対して行うことを特徴とする。
その他の手段は、後記する。

本発明によれば、データベース管理システムにおいて、バッチ処理の中断が発生しても、バッチ処理を効率的に実行することが可能となった。

まず、本実施形態の概要について、説明する。
図１は、バッチ処理の実行の中断への対処法を示す説明図である。バッチ処理プログラムは、４つのリクエスト（ＩＤ＝Ｒ１〜Ｒ４）を順に実行する旨が記載されている。
まず、図１（ａ）は、中断がない場合を示す。１日目だけで、４つのリクエストが全て実行されるので、一番効率がよい。
次に、図１（ｂ）は、中断があり、最初からやり直す比較例を示す。１日目では、２つめのリクエストの処理を終えた時点で、中断が発生してしまう。そして、２日目では、最初のリクエスト（ＩＤ＝Ｒ１）からやり直すことにより、４つのリクエストが全て実行される。この図１（ｂ）の方式では、１日目に実行した２つのリクエストは、２日目にも重複して実行してしまうため、効率が悪い。

一方、図１（ｃ）は、中断があり、途中から復帰する本実施形態を示す。１日目では、図１（ｂ）と同様に、２つめのリクエストの処理を終えた時点で、中断が発生してしまう。しかし、２日目では、既に終えた２つのリクエスト（ＩＤ＝Ｒ１，Ｒ２）は、その実行結果を読み取ることで、リクエストの実行をスキップする。そして、まだ実行していない２つのリクエスト（ＩＤ＝Ｒ３，Ｒ４）を実行することにより、バッチ処理プログラムの処理を完了する。
このように、途中から復帰する図１（ｃ）の方式は、最初からやり直す図１（ｂ）の方式に比べ、同じリクエストを２回重複して実行することがないため、高速で処理できるなど、処理効率が高い方式である。
なお、「通常実行」とは、リクエストを実行するとともに、その実行結果を記憶手段に格納する処理を指す。
また、「簡易実行」とは、「通常実行」により格納された実行結果を記憶手段から読み取ってリクエストの要求元へと返却することで、リクエストの実行を代替する（スキップする）処理を指す。
復帰状態「復帰無」とは、「簡易実行」を伴わず、「通常実行」から開始する状態を指す。
復帰状態「復帰有」とは、「簡易実行」を行ってから、「通常実行」を行う状態を指す。

図２（ａ）は、データベースシステムを示す構成図である。データベースシステムは、ＡＰクライアント１と、ＡＰサーバ２（バッチ実行装置）と、ＤＢサーバ３（リクエスト実行装置）とが、ネットワーク９で接続されて構成される。ＤＢサーバ３には、ディスク装置８が接続されている。なお、ＤＢは、データベース（DataBase）の略であり、ＡＰは、アプリケーション（Application）の略である。

ＡＰクライアント１は、バッチ処理プログラムの実行を、ＡＰサーバ２に依頼する装置である。バッチ処理プログラム内には、リクエストの処理を必要とするバッチ処理も含まれている。
ＡＰサーバ２は、ＡＰクライアント１からの依頼を受け、バッチ処理プログラムを解釈および実行する装置である。バッチ処理プログラムからリクエストの処理が必要な場合、そのリクエストの処理をＤＢサーバ３に要求する。よって、ＡＰサーバ２は、ＤＢサーバ３にとっては、ＤＢクライアントに該当する。
ＤＢサーバ３は、ＡＰサーバ２からのリクエストの処理要求を受け、リクエストを解釈および実行する装置である。リクエストの実行によりデータベースのデータへのディスクアクセスが必要になるときには、ディスク装置８に対して、そのディスクアクセスを実行する。
このように、ＡＰクライアント１からは、ＡＰサーバ２とは直接やりとりをするフロントエンドであるが、ＤＢサーバ３は直接は見えないバックエンドである。

図２（ｂ）は、ＡＰサーバ２の構成図である。
ＡＰサーバ２は、ＣＰＵ２１と、主記憶部２２と、を備えるコンピュータである。
主記憶部２２は、バッチ処理部２３と、データベースアクセス部２４と、を有する。
バッチ処理部２３は、データベースアクセス部２４に対してリクエストを問い合わせる。
データベースアクセス部２４は、バッチ処理部２３から受けたリクエストについて、ネットワーク９を経由してＤＢサーバ３に問い合わせる。

図３は、ＤＢサーバ３およびディスク装置８を示す構成図である。

ディスク装置８には、データベース記憶領域８１が格納される。データベース記憶領域８１には、データベースが扱う論理構造データの一例としての表データ８２が格納される。なお、本実施形態において、表データ８２という論理構造データはあくまで一例であり、ツリー構造などの他の論理構造データを用いてもよい。

ＤＢサーバ３は、ＣＰＵ３１と、主記憶部３２と、を備えるコンピュータである。主記憶部３２は、データベース管理部３３と、バッチ処理管理テーブル４２ｂと、ＳＱＬ履歴管理テーブル４３ｂと、返却データ記憶領域４４ｂと、を有する。以下、主記憶部３２が格納する各データの詳細について、図４を参照して説明する。
さらに、ＤＢサーバ３のデータベース管理部３３は、前記した各データを処理するために、ＳＱＬ制御部３４（リクエスト制御部）と表データ管理部４１ａとバッチ処理管理部４２ａとＳＱＬ履歴管理部４３ａと返却データ管理部４４ａを備える。これらの各処理部の詳細については、後で説明する。

図４は、ＤＢサーバ３内の各データ構造を示す構成図である。
バッチ処理管理テーブル４２ｂは、バッチ処理プログラムを一意に特定する「バッチＩＤ」と、バッチ処理プログラムの名称である「バッチ名」と、次にバッチ処理プログラムを実行するときの「復帰状態」と、を対応づけて格納する。
「復帰状態」が「復帰無」の場合は、図１（ｃ）の１日目のように、前回のバッチ処理プログラムの実行履歴がないため、次は簡易実行を行わずに、通常実行を行う。
「復帰状態」が「復帰有」の場合は、図１（ｃ）の２日目のように、前回のバッチ処理プログラムの実行履歴があるため、次は簡易実行を行ってから、通常実行を行う。

ＳＱＬ履歴管理テーブル４３ｂは、「バッチＩＤ」と、「リクエストＩＤ」と、「リクエスト内容」と、「リクエストの返却データへのポインタ」と、を対応づけて格納する。
「バッチＩＤ」は、バッチ処理プログラムを一意に特定するＩＤであり、バッチ処理管理テーブル４２ｂの「バッチＩＤ」と対応する。
「リクエストＩＤ」は、バッチ処理プログラムから指定されるリクエストを特定するＩＤである。

「リクエスト内容」は、「リクエストＩＤ」で特定されるリクエストの内容を示す。なお、図４ではＳＱＬの文法に従って表記されるリクエストを格納しているが、他の記述言語の文法や、バッチ処理プログラムから指定されるＳＱＬの文法を構文解析した中間言語の文法に従って、リクエストを格納してもよい。中間言語の文法を用いることにより、実質的に同じ処理内容が、複数の記述言語で表記されているときに、同じリクエスト内容として統一的に管理することができ、そのリクエスト内容の実行履歴を効率的に利用することができる。

「リクエストの返却データへのポインタ」は、「リクエスト内容」の実行結果を示すデータの返却データ記憶領域４４ｂ内の格納先を指し示すポインタである。「Select」などの読み込みリクエストのときには、リクエストに応じて読み込んだ内容のデータが、指し示される。「Update,Insert」などの書き込みリクエストのときには、読み込んだ内容のデータがないため、リクエストは実行されるものの、実行結果を示すポインタは省略される。

返却データ記憶領域４４ｂは、ＳＱＬ履歴管理テーブル４３ｂの「リクエストの返却データへのポインタ」の参照先となるデータを格納する。この格納するデータは、中断前の通常実行において書き込まれ、中断後の簡易実行において読み込まれる。そのため、中断時に電源がオフになることが一般的であるため、返却データ記憶領域４４ｂを構成する記憶手段は、不揮発性のメモリやハードディスクとして構成されることが、望ましい。

図３に戻って、ＤＢサーバ３のデータベース管理部３３は、ＳＱＬ制御部３４（リクエスト制御部）と表データ管理部４１ａとバッチ処理管理部４２ａとＳＱＬ履歴管理部４３ａと返却データ管理部４４ａを備える。

ＳＱＬ制御部３４は、バッチ処理部２３から送られたリクエストを構文解析し、リクエストを実行する。そのため、ＳＱＬ制御部３４は、他の各処理部（バッチ処理管理部４２ａ、ＳＱＬ履歴管理部４３ａ、返却データ管理部４４ａ）を制御する。
そして、ＳＱＬ制御部３４は、リクエストの構文解析の結果から「リクエスト内容」を生成し、リクエストの実行結果から「リクエストの返却データ」およびそのポインタを生成し、それぞれＳＱＬ履歴管理テーブル４３ｂおよび返却データ記憶領域４４ｂに格納する。
さらに、ＳＱＬ制御部３４は、「リクエストの返却データ」を、リクエストの要求元であるバッチ処理部２３へと返却する。

表データ管理部４１ａは、表データ８２に対するアクセス（読み込み、および、書き込み）を実行する。
バッチ処理管理部４２ａは、バッチ処理管理テーブル４２ｂに対するアクセス（読み込み、および、書き込み）を実行する。
ＳＱＬ履歴管理部４３ａは、ＳＱＬ履歴管理テーブル４３ｂに対するアクセス（読み込み、および、書き込み）を実行する。ＳＱＬ履歴管理テーブル４３ｂには、バッチ処理部２３から要求されたリクエストに関するデータが記憶される。
返却データ管理部４４ａは、返却データ記憶領域４４ｂに対するアクセス（読み込み、および、書き込み）を実行する。返却データ記憶領域４４ｂには、リクエストの実行結果を示す返却データが記憶される。

図５は、「復帰状態」が「復帰無」の場合における、バッチ処理プログラムの実行処理を示すフローチャートである。本フローチャートの処理は、図１（ｃ）の１日目のように、前回のバッチ処理プログラムの実行履歴がないため、簡易実行を行わずに、通常実行を行う。

Ｓ１１において、ＡＰクライアント１は、実行するバッチ処理プログラムのバッチ名と、バッチ処理の復帰状態「復帰無」と、を指定するバッチ処理の実行要求を、ＡＰサーバ２のバッチ処理部２３に送信する。
Ｓ１２において、バッチ処理部２３は、バッチ処理の実行要求を受け、データベースアクセス部２４を用いて、ＤＢサーバ３のデータベース管理部３３に接続する。なお、接続要求には、バッチ処理の実行要求で指定されているバッチ名と、復帰状態「復帰無」とを含む。

Ｓ１３において、バッチ処理管理部４２ａは、接続要求の復帰状態が「復帰無」のときには、バッチ処理管理テーブル４２ｂに新規のレコードを１つ追加する。そして、追加するレコードの「バッチ名」には、接続要求で指定されたバッチ名を代入する。追加するレコードの「バッチＩＤ」には、登録済みの最大のバッチＩＤに１を加えたものを代入する。追加するレコードの「復帰状態」には、接続要求で指定された復帰状態「復帰無」を代入する。

Ｓ１４において、バッチ処理部２３は、Ｓ１２の接続要求に対する処理が完了すると、バッチ処理プログラムを実行し、バッチ処理中にリクエストの実行を要するときには、ＳＱＬ制御部３４に対して、リクエストの実行を要求する。
Ｓ１５において、ＳＱＬ制御部３４は、要求を受け付けたリクエストを通常実行する（詳細は図７）。
Ｓ１６において、ＡＰクライアント１は、以前Ｓ１１で実行要求した「バッチ名」を指定して、バッチ処理の中断要求を送信する。

Ｓ１７において、バッチ処理部２３は、バッチ処理の中断要求を受け、ＳＱＬ制御部３４に対して、そのバッチ処理内のリクエストの中断を要求する。
Ｓ１８において、ＳＱＬ制御部３４は、リクエストの中断要求に従い、リクエストの実行を中断する。具体的には、バッチ処理管理部４２ａに対して、バッチ処理管理テーブル４２ｂの内容の書き換えを指示する。バッチ処理管理部４２ａは、中断要求の「バッチ名」に対応するレコードをバッチ処理管理テーブル４２ｂから検索し、検索されたレコードの「復帰状態」を「復帰有」に変更する。

図６は、「復帰状態」が「復帰有」の場合における、バッチ処理プログラムの実行処理を示すフローチャートである。本フローチャートの処理は、図１（ｃ）の２日目のように、前回のバッチ処理プログラムの実行履歴があるため、簡易実行を行ってから、通常実行を行う。

Ｓ２１において、ＡＰクライアント１は、中断したバッチ処理の「バッチ名」と、復帰状態「復帰有」とを指定して、バッチ処理の再開要求を、ＡＰサーバ２のバッチ処理部２３に送信する。
Ｓ２２において、バッチ処理部２３は、ＡＰクライアント１から、中断したバッチ処理の再開要求を受け、データベースアクセス部２４を用いて、ＤＢサーバ３のデータベース管理部３３に接続する。なお、接続要求には、バッチ処理の再開要求で指定されているバッチ名と、復帰状態「復帰有」とを含む。
Ｓ２３において、バッチ処理管理部４２ａは、接続要求の復帰状態が「復帰有」のときには、バッチ処理管理部４２ａを用いて、バッチ処理管理テーブル４２ｂから既存のレコードを１つ検索する。このときの検索キーは、接続要求で指定されたバッチ名である。そして、検索されたレコードに対して、その「復帰状態」を「復帰有」に書き換える。

Ｓ２４において、バッチ処理部２３は、Ｓ２３の接続要求に対する処理が完了すると、バッチ処理プログラムを実行し、バッチ処理中にリクエストの実行を要するときには、ＳＱＬ制御部３４に対して、リクエストの実行を要求する。
Ｓ２５において、ＳＱＬ制御部３４は、要求を受け付けたリクエストを簡易実行する（詳細は図８）。
Ｓ２６において、ＳＱＬ制御部３４は、Ｓ２５の簡易実行の続きとして、通常実行する（詳細は図７）。なお、簡易実行（Ｓ２５）と、通常実行（Ｓ２６）とは、ＡＰクライアント１に確認せずに、連続して実行してもよいし、ＡＰクライアント１からの通常実行の指示を待ってから、通常実行（Ｓ２６）を実行してもよい。

図７は、Ｓ１５およびＳ２６からそれぞれ呼び出される、通常実行における詳細処理を示すフローチャートである。

Ｓ１０１において、ＳＱＬ制御部３４は、バッチ処理部２３から受け付けたリクエストのＳＱＬ記述を構文解析し、「リクエスト内容」を取得する。
Ｓ１０２において、バッチ処理管理部４２ａは、バッチ処理管理テーブル４２ｂからリクエストの「バッチ名」を検索キーとしてレコードを検索し、検索されたレコードの「バッチＩＤ」を取得する。そして、バッチ処理管理部４２ａは、Ｓ１０１で取得した「リクエスト内容」、および、Ｓ１０２で取得した「バッチＩＤ」を、ＳＱＬ履歴管理部４３ａに通知する。
Ｓ１０３において、ＳＱＬ履歴管理部４３ａは、ＳＱＬ履歴管理テーブル４３ｂのレコードを新しく１つ生成し、生成したレコードの「リクエスト内容」および「バッチＩＤ」に対して、Ｓ１０２で通知された「リクエスト内容」および「バッチＩＤ」を登録する。

Ｓ１０４において、ＳＱＬ制御部３４は、Ｓ１０３の登録完了の通知を受け、バッチ処理部２３から受け付けたリクエストを実行する。
Ｓ１０５において、表データ管理部４１ａは、リクエストの実行に伴うＳＱＬ制御部３４からの指示によるディスクアクセスを、表データ８２に対して実行する。
Ｓ１０６において、返却データ管理部４４ａは、表データ管理部４１ａからディスクアクセスの結果の通知を受け、その内容を返却データ記憶領域４４ｂに書き込むとともに、ＳＱＬ履歴管理部４３ａを介して、書き込んだデータへのポインタをＳＱＬ履歴管理テーブル４３ｂの「リクエストの返却データへのポインタ」に登録する。なお、ポインタを登録するＳＱＬ履歴管理テーブル４３ｂのレコードは、Ｓ１０３で新しく生成されたレコードである。
Ｓ１０７において、返却データ管理部４４ａは、リクエストの実行結果である書き込んだディスクアクセスのデータを、ＳＱＬ制御部３４を介してバッチ処理部２３に返却する。

図８は、Ｓ２５から呼び出される、簡易実行における詳細処理を示すフローチャートである。

Ｓ２０１において、ＳＱＬ制御部３４は、バッチ処理部２３から受け付けたリクエストのＳＱＬ記述を構文解析し、「リクエスト内容」を取得する。
Ｓ２０２において、バッチ処理管理部４２ａは、受け付けたリクエストの「バッチ名」を検索キーとして、バッチ処理管理テーブル４２ｂから該当するレコードを検索し、発見したレコードの「バッチＩＤ」を取得する。そして、Ｓ２０１で取得した「リクエスト内容」、および、Ｓ２０２で取得した「バッチＩＤ」を、ＳＱＬ履歴管理部４３ａに通知する。

Ｓ２０３において、ＳＱＬ履歴管理部４３ａは、通知された「バッチＩＤ」を検索キーとして、ＳＱＬ履歴管理テーブル４３ｂから該当するレコードを検索し、該当する１つ以上のレコードを取得する。
Ｓ２０４において、ＳＱＬ履歴管理部４３ａは、Ｓ２０１で構文解析した「リクエスト内容」と一致する「リクエスト内容」をもつレコードを、Ｓ２０３で取得した１つ以上のレコードから特定する。
Ｓ２０５において、ＳＱＬ履歴管理部４３ａは、Ｓ２０４で「リクエスト内容」が一致するレコードが存在するか否かを判定する。Ｓ２０５を満たすときにはＳ２０６へ、Ｓ２０５を満たさないときにはＳ２１０へ、それぞれ移行する。

Ｓ２０６において、ＳＱＬ履歴管理部４３ａは、Ｓ２０４で特定したレコードの「リクエストの返却データへのポインタ」が存在するか否かを判定する。Ｓ２０６を満たすときにはＳ２０７へ、Ｓ２０６を満たさないときにはＳ２０８へ、それぞれ移行する。

Ｓ２０７において、返却データ管理部４４ａは、Ｓ２０６のポインタで示される返却データ記憶領域４４ｂ内の返却データを、主記憶部３２内の結果返却領域にコピーする。
Ｓ２０８において、返却データ管理部４４ａは、主記憶部３２内の結果返却領域のデータをクリア（返却データが無い状態に）する。

Ｓ２０９において、ＳＱＬ制御部３４は、リクエストを実行する代わりに、結果返却領域の情報をバッチ処理部２３に返却する。そして、処理を終了する。
Ｓ２１０において、バッチ処理管理部４２ａは、バッチ処理管理テーブル４２ｂの取得した「バッチＩＤ」に該当するレコードの「復帰状態」を「復帰無」に変更する。
Ｓ２１１において、ＳＱＬ制御部３４は、Ｓ１０４〜Ｓ１０７で説明したように、通常実行としてリクエストを実行し、実行結果をバッチ処理部２３に返却する。そして、処理を終了する。

以上説明した本実施形態は、以下に示すとおりの変形実施が可能である。

例えば、ＡＰクライアント１がＡＰサーバ２に送信する各要求（Ｓ１１，Ｓ１６，Ｓ２１など）について、その要求メッセージの内容をユーザに指定させるために、様々な入力方法を用いてもよい。例えば、ＧＵＩ（Graphical User Interface）を用いて指定してもよいし、定義ファイルや環境変数などを用いて指定してもよい。

また、ＡＰクライアント１は、簡易実行が可能なリクエスト（実行履歴が存在するリクエスト）のうち、簡易実行を行わないリクエスト（つまり、通常実行を再度行うリクエスト）を明示的に指定してもよい。
例えば、ＡＰクライアント１は、バッチ処理を中断したにもかかわらず、バッチ処理の再開要求を行う代わりに、復帰状態「復帰無」とするバッチ処理の実行要求を行うことで、バッチ処理の中断前に実行した全部のリクエストを、再度通常実行する。
また、ＡＰクライアント１は、復帰状態「復帰有」とするバッチ処理の再開要求を行い、その再開要求の中で、通常実行を再度行うリクエストをリクエストＩＤなどにより明示的に指定することにより、ＤＢサーバ３は、その指定されたリクエストを、実行履歴があるにもかかわらず、再度通常実行する。

さらに、キャッシュデータを活用して、データベースシステムの性能を向上してもよい。
図９は、図１とは別の変形実施のデータベースシステムを示す構成図である。図１では、ＤＢサーバ３のデータベース管理部３３にとって処理対象である表データ８２は、ＤＢサーバ３とは別装置であるディスク装置８内に格納することとした。図９では、表データ８２をディスク装置８内に格納し、さらに、ＤＢサーバ３内にもキャッシュデータとして表データ４１ｂに格納する。

表データ４１ｂと表データ８２とは、トランザクションの終了時ごとに、データの同期処理（同一化処理）が実施される。そして、データベース管理部３３（表データ管理部４１ａ）は、同じ装置内に存在する表データ４１ｂに対してデータアクセスを行うことにより、通信遅延時間を小さくすることができる。
よって、表データ８２のデータ内容は、トランザクションの実行中には、トランザクション内のリクエストによる書き込み指示により、表データ４１ｂよりも新しいデータ内容となる。一方、表データ４１ｂのデータ内容は、現在実行中のトランザクションからみて、直前のトランザクションの終了時に同期化されたままの古いデータ内容となる。
つまり、表データ４１ｂと表データ８２とは、実行中のトランザクションにおけるデータアクセスにより、データ内容が一時的に不一致となる場合も起こりうる。そこで、データ内容が不一致であるときに中断が発生しても、両データの内容が不整合にならないように、以下に示す対策を行う。

対策を行うため、図９のデータベースシステムは、図１のデータベースシステムと比較すると、表データ４１ｂに加え、更新ログ管理部４５ａと、更新ログ記憶領域４５ｂとが、追加されている。
更新ログ管理部４５ａは、バッチ処理を中断する前に、更新ログ記憶領域４５ｂに対して、表データ４１ｂの更新内容を更新ログとして記録し続ける。
更新ログ管理部４５ａは、バッチ処理を中断した際に、表データ４１ｂと表データ８２との差分データとなる更新ログを、更新ログ記憶領域４５ｂから取得する。この更新ログは、具体的には、バッチ処理を中断する直前のトランザクションの終了点から中断時点までの更新ログである。
更新ログ管理部４５ａは、取得した更新ログを、表データ４１ｂにロールバック（書き戻し）することにより、表データ４１ｂと表データ８２とデータ内容を互いに整合させる。
一方、更新ログ管理部４５ａは、バッチ処理が中断するまでは、更新ログ記憶領域４５ｂの更新ログを取得する必要はない。これにより、更新ログ記憶領域４５ｂへのデータアクセスを必要時だけに絞り込み、性能劣化を抑制する。

以上説明した本実施形態によれば、バッチ処理の復帰実行において、実行済みのリクエスト処理（ＳＱＬ処理）にかかる時間を削減できる。特に基幹データベースの情報を抽出し、情報データベースにデータマート（data mart）を作成するようなバッチ処理では、データベース管理システムにおいて負荷の高いリクエストを実行し、リクエストの処理時間が長くなる。そのため、実行済みのＳＱＬ処理をスキップする効果が高い。

本発明の一実施形態に関するバッチ処理の実行の中断への対処法を示す説明図である。 本発明の一実施形態に関するデータベースシステムを示す構成図である。 本発明の一実施形態に関するＤＢサーバ３およびディスク装置８を示す構成図である。 本発明の一実施形態に関するＤＢサーバ３内の各データ構造を示す構成図である。 本発明の一実施形態に関する「復帰状態」が「復帰無」の場合における、バッチ処理プログラムの実行処理を示すフローチャートである。 本発明の一実施形態に関する「復帰状態」が「復帰有」の場合における、バッチ処理プログラムの実行処理を示すフローチャートである。 本発明の一実施形態に関する通常実行における詳細処理を示すフローチャートである。 本発明の一実施形態に関する簡易実行における詳細処理を示すフローチャートである。 本発明の一実施形態に関する別の変形実施のデータベースシステムを示す構成図である。

符号の説明

１ ＡＰクライアント
２ ＡＰサーバ
３ ＤＢサーバ
８ ディスク装置
９ ネットワーク
２１ ＣＰＵ
２２ 主記憶部
２３ バッチ処理部
２４ データベースアクセス部
３１ ＣＰＵ
３２ 主記憶部
３３ データベース管理部
３４ ＳＱＬ制御部
４１ａ 表データ管理部
４１ｂ 表データ
４２ａ バッチ処理管理部
４２ｂ バッチ処理管理テーブル
４３ａ ＳＱＬ履歴管理部
４３ｂ ＳＱＬ履歴管理テーブル
４４ａ 返却データ管理部
４４ｂ 返却データ記憶領域
４５ａ 更新ログ管理部
４５ｂ 更新ログ記憶領域
８１ データベース記憶領域
８２ 表データ

Claims (7)

1. バッチ処理を実行するバッチ実行装置と、バッチ処理から呼び出されるリクエストを実行するリクエスト実行装置と、リクエストの実行に伴うデータアクセスの対象となるデータを格納するディスク装置と、を用いるデータベースシステムにより実施されるバッチ処理方法であって、
   前記バッチ実行装置のバッチ処理部は、
   バッチ処理の実行を要求されると、そのバッチ処理を実行し、そのバッチ処理から指定されるリクエストの実行結果が必要になると、実行中のバッチ処理とそのリクエスト内容とを指定して前記リクエスト実行装置にリクエストの実行を要求し、
   前記リクエスト実行装置のリクエスト制御部は、
   リクエストの実行が要求されると、前記バッチ実行装置からの中断要求の通知の有無により、そのリクエストに対応するバッチ処理が中断前の状態か、中断後の復帰状態かを判定し、
   バッチ処理が前記中断前の状態と判定されるときには、実行要求されたリクエスト内容を実行し、その実行に伴うデータアクセスを前記ディスク装置に対して行い、
   そのデータアクセスがデータの読み込み処理であるときには、読み込み結果のデータ内容を返却データとして、前記実行要求されたリクエスト内容に対応づけて記憶手段内に履歴管理データとして格納し、その返却データを実行要求元である前記バッチ実行装置に返却し、
   そのデータアクセスがデータの書き込み処理であるときには、前記実行要求されたリクエスト内容を前記記憶手段内に前記履歴管理データとして格納し、
   バッチ処理が前記中断後の復帰状態と判定されるときには、前記実行要求されたリクエスト内容が前記記憶手段内の前記履歴管理データに存在するか否かを検索し、
   前記履歴管理データの検索処理で前記実行要求されたリクエスト内容を発見できたときには、実行要求されたリクエストの実行を省略するとともに、前記履歴管理データにおいて前記実行要求されたリクエスト内容に対応する前記返却データを実行要求元である前記バッチ実行装置に返却し、
   前記履歴管理データの検索処理で前記実行要求されたリクエスト内容を発見できなかったときには、前記実行要求されたリクエスト内容を実行し、その実行に伴うデータアクセスを前記ディスク装置に対して行うことを特徴とする
   バッチ処理方法。
2. 前記リクエスト実行装置は、さらに、
   前記ディスク装置が格納するデータアクセスの対象となるデータを、前記リクエスト実行装置内の前記記憶手段にもキャッシュデータとして格納するとともに、データベースへのトランザクションの終了時に、前記ディスク装置のデータと、前記リクエスト実行装置のキャッシュデータとを同期処理し、
   前記リクエスト実行装置のキャッシュデータの更新ログを前記記憶手段に記憶し続け、
   バッチ処理の中断要求を受信すると、バッチ処理を中断する直前のトランザクションの終了点から中断時点までの更新ログを前記記憶手段から読み取り、前記リクエスト実行装置のキャッシュデータにロールバックすることで、前記ディスク装置のデータと、前記リクエスト実行装置のキャッシュデータとを整合化することを特徴とする
   請求項１に記載のバッチ処理方法。
3. 前記リクエスト実行装置の前記返却データを格納する前記記憶手段は、不揮発性の記憶媒体として構成されることを特徴とする
   請求項１または請求項２に記載のバッチ処理方法。
4. 前記リクエスト実行装置の前記リクエスト制御部は、さらに、実行要求されたバッチ処理が前記中断後の復帰状態と判定され、かつ、そのバッチ処理の実行要求において、前記履歴管理データを利用しないリクエストが指定されているときには、その指定されているリクエストが前記履歴管理データに存在するか否かにかかわらず、前記実行要求されたリクエスト内容を実行し、その実行に伴うデータアクセスを前記ディスク装置に対して行うことを特徴とする
   請求項１ないし請求項３のいずれか１項に記載のバッチ処理方法。
5. 請求項１ないし請求項４のいずれか１項に記載のバッチ処理方法を、前記データベースシステムの各コンピュータに実行させるための、バッチ制御プログラム。
6. バッチ処理を実行するバッチ実行装置と、バッチ処理から呼び出されるリクエストを実行するリクエスト実行装置と、リクエストの実行に伴うデータアクセスの対象となるデータを格納するディスク装置と、を用いるデータベースシステムにおけるリクエスト実行装置であって、
   前記リクエスト実行装置のリクエスト制御部は、
   前記バッチ実行装置からリクエストの実行が要求されると、前記バッチ実行装置からの中断要求の通知の有無により、そのリクエストに対応するバッチ処理が中断前の状態か、中断後の復帰状態かを判定し、
   バッチ処理が前記中断前の状態と判定されるときには、実行要求されたリクエスト内容を実行し、その実行に伴うデータアクセスを前記ディスク装置に対して行い、
   そのデータアクセスがデータの読み込み処理であるときには、読み込み結果のデータ内容を返却データとして、前記実行要求されたリクエスト内容に対応づけて記憶手段内に履歴管理データとして格納し、その返却データを実行要求元である前記バッチ実行装置に返却し、
   そのデータアクセスがデータの書き込み処理であるときには、前記実行要求されたリクエスト内容を前記記憶手段内に前記履歴管理データとして格納し、
   バッチ処理が前記中断後の復帰状態と判定されるときには、前記実行要求されたリクエスト内容が前記記憶手段内の前記履歴管理データに存在するか否かを検索し、
   前記履歴管理データの検索処理で前記実行要求されたリクエスト内容を発見できたときには、実行要求されたリクエストの実行を省略するとともに、前記履歴管理データにおいて前記実行要求されたリクエスト内容に対応する前記返却データを実行要求元である前記バッチ実行装置に返却し、
   前記履歴管理データの検索処理で前記実行要求されたリクエスト内容を発見できなかったときには、前記実行要求されたリクエスト内容を実行し、その実行に伴うデータアクセスを前記ディスク装置に対して行うことを特徴とする
   リクエスト実行装置。
7. 請求項６に記載のリクエスト実行装置と、前記バッチ実行装置と、前記ディスク装置と、を有することを特徴とするデータベースシステム。

Images