JP6175924B2 - プログラム、情報処理システムおよびデータ更新制御方法 - Google Patents

Description

本発明はプログラム、情報処理システムおよびデータ更新制御方法に関する。

現在、コンピュータなどの情報処理装置は種々のデータ処理に用いられている。データを管理するシステムでは、ある記憶装置に格納されたデータの複製を他の記憶装置にも格納することがある。すると、一方の記憶装置が故障しても他方の記憶装置に格納されたデータを用いて処理を継続し得る。例えば、複数の記憶装置に同じ内容のデータベースを格納し、各データベースを同期させることで、データベースを冗長化するシステムがある。

当該システムでは、一方の記憶装置が故障すると当該記憶装置に格納されたデータベースを利用できなくなるので、単独のデータベースでの運用となる。この場合、単独のデータベースが障害などで利用できなくなると、データ処理を継続できなくなる。そこで、利用停止中のデータベースを、運用中のデータベースと同じ時点まで回復させ、同期運用を再開することが考えられる。データベースの回復方法としては次のような方法がある。

例えば、運用中のデータベースに対する更新の履歴を記録したトランザクションログを取得し、運用中のデータベースの運用を完全に停止した上で、当該トランザクションログを回復対象のデータベースに対して再実行することで、当該データベースを回復させる。また、例えば、トランザクションログを用いない回復方法の提案もある。この提案では、第１のデータベース・システムに対して照会または更新が生じたときに、照会または更新の対象となったレコードを、復元対象である第２のデータベース・システムに複写していくことで、第２のデータベース・システムのデータベースを復元する。

特開平７−２６２０６８号公報

上記のように、第１の記憶装置に格納された第１のデータ群（例えば、データベース）に対する更新の履歴を示す履歴情報を用いて、第２の記憶装置に格納された第２のデータ群を復旧させることがある。このとき、第１のデータ群に対する更新を受け付けながら、第２のデータ群を復旧させることが考えられる。しかし、この場合、第２のデータ群の復旧が完了するまでの所要時間が増大する可能性があるという問題がある。

例えば、第１の時点までの履歴情報を用いて第２のデータ群を回復している間に、第１のデータ群の更新が発生すると、第１の時点より後の第２の時点までの差分の履歴情報（第１の差分）が生成され得る。すると、第２のデータ群を第１の時点まで回復させた後に、第１の差分を用いて第２の時点まで回復させることになる。そして、当該回復中にも第２の時点より後の第３の時点までの差分の履歴情報（第２の差分）が生成され得る。すなわち、以降、履歴情報の差分がなくなるまで新たな差分を順次適用することになる。

ところが、第１の差分を適用している間に大量の更新が発生し得る。当該更新は第２の差分に記録される。第２の差分が大量の更新を含むと、その適用時間は長くなる。すると、第２の差分の適用時間内での第１のデータ群の更新量も増大し得る。よって、更にその次の差分（第３の差分）の適用時間も長引く可能性がある。これが繰り返され、各差分の適用時間が長引くと、第２のデータ群の復旧が完了するまでに時間がかかる。単独のデータ群での運用が長引くと、障害発生時などに処理を継続できなくなる可能性が高まる。

１つの側面では、本発明は、データ復旧の長期化を抑制できるプログラム、情報処理システムおよびデータ更新制御方法を提供することを目的とする。

１つの態様ではプログラムが提供される。このプログラムは、コンピュータに、第１の記憶装置に格納された第１のデータ群に対する第１の更新の履歴を示す第１の履歴情報を用いて第２の記憶装置に格納された第２のデータ群を復旧する第１の復旧処理が行われている間に第１のデータ群に対する第２の更新の要求を受け付けると、当該第２の更新の履歴を示す第２の履歴情報を生成し、第２の履歴情報の情報量に基づき、第２の履歴情報を用いて第２のデータ群を復旧する第２の復旧処理が完了するまでの時間を予測し、予測された時間を用いた所定の判定処理の結果に基づいて第２の復旧処理が行われている間の第１のデータ群に対する第３の更新の少なくとも一部を制限する、処理を実行させる。

また、１つの態様では、情報処理システムが提供される。この情報処理システムは、第１の記憶装置に格納された第１のデータ群に対する第１の更新の履歴を示す第１の履歴情報を用いて第２の記憶装置に格納された第２のデータ群を復旧する第１の復旧処理が行われている間に第１のデータ群に対する第２の更新の要求を受け付けると、当該第２の更新の履歴を示す第２の履歴情報を生成し、第２の履歴情報の情報量に基づき、第２の履歴情報を用いて第２のデータ群を復旧する第２の復旧処理が完了するまでの時間を予測し、予測された時間を用いた所定の判定処理の結果に基づいて第２の復旧処理が行われている間の第１のデータ群に対する第３の更新の少なくとも一部を制限する情報処理装置を有する。

また、１つの態様では、データ更新制御方法が提供される。このデータ更新制御方法では、情報処理装置が、第１の記憶装置に格納された第１のデータ群に対する第１の更新の履歴を示す第１の履歴情報を用いて第２の記憶装置に格納された第２のデータ群を復旧する第１の復旧処理が行われている間に第１のデータ群に対する第２の更新の要求を受け付けると、当該第２の更新の履歴を示す第２の履歴情報を生成し、第２の履歴情報の情報量に基づき、第２の履歴情報を用いて第２のデータ群を復旧する第２の復旧処理が完了するまでの時間を予測し、予測された時間を用いた所定の判定処理の結果に基づいて第２の復旧処理が行われている間の第１のデータ群に対する第３の更新の少なくとも一部を制限する。

１つの側面では、データ復旧の長期化を抑制できる。

第１の実施の形態の情報処理システムを示す図である。 第２の実施の形態の情報処理システムを示す図である。 ＤＢサーバのハードウェア例を示す図である。 情報処理システムの機能例を示す図である。 ＳＱＬ優先度テーブルの例を示す図である。 無更新確率テーブルの例を示す図である。 アクセス統計テーブルの例を示す図である。 ログの出力例を示す図である。 障害時の正系の処理の例を示すフローチャートである。 片系運用時のログの出力例を示す図である。 副系のリカバリ処理の例を示すフローチャートである。 リカバリの具体例を示す図である。 副系リカバリ時の正系の制御の例を示すフローチャートである。 正系のＤＢ更新制御の例を示すフローチャートである。 リカバリ時の処理の例を示すシーケンスである。 差分適用の所要時間の例を示す図である。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理システムを示す図である。第１の実施の形態の情報処理システムは、情報処理装置１，２，３および記憶装置４，５，６を含む。情報処理装置１，２，３は、ネットワークを介して接続されている。情報処理装置１は、記憶装置４，６と接続されている。情報処理装置１は記憶装置４を内蔵してもよい。情報処理装置１はネットワークを介して記憶装置４，６と接続されてもよい。情報処理装置２は、記憶装置５，６と接続されている。情報処理装置２は記憶装置５を内蔵してもよい。情報処理装置２はネットワークを介して記憶装置５，６と接続されてもよい。記憶装置４，５，６は、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。

ここで、記憶装置４はデータ群４ａを記憶する。記憶装置５はデータ群５ａを記憶する。データ群４ａ，５ａはデータベースでもよい。第１の実施の形態の情報処理システムでは、情報処理装置１，２を用いてデータ群４ａ，５ａの内容を同期させることで、耐障害性を高めている。すなわち、通常時はデータを冗長化して運用する。情報処理装置１および記憶装置４を正系（現用系）とする。情報処理装置２および記憶装置５を副系（待機系）とする。情報処理装置３は、データ群４ａを用いた処理を行う。例えば、情報処理装置３は、データ群４ａに含まれるデータを参照したり、更新したりする。データ群４ａに対する更新には、データ群４ａにデータを追加すること、データ群４ａに含まれるデータを変更すること、データ群４ａに含まれるデータを削除することを含む。通常の運用時は、データ群４ａに対する更新はデータ群５ａにも反映され、両データ群は同期される。

情報処理装置１は、演算部１ａを有する。演算部１ａは、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。演算部１ａは、プログラムを実行するプロセッサであってもよい。プロセッサには、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る（以下、同様）。情報処理装置１は、演算部１ａの処理に用いられるデータを格納するＲＡＭ（Random Access Memory）などのメモリを有する（図示を省略）。

演算部１ａは、記憶装置４に記憶されたデータ群４ａを更新可能である。演算部１ａは、データ群４ａを更新し、更新の履歴を示す履歴情報（ログ）を生成して記憶装置６に格納する。履歴情報は、情報処理装置１が有するメモリに蓄積された更新ログを記憶装置６の記憶領域に出力したものでもよい。

情報処理装置２は、演算部２ａを有する。演算部２ａは、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどを含み得る。演算部２ａは、プログラムを実行するプロセッサであってもよい。情報処理装置２は、演算部２ａの処理に用いられるデータを格納するＲＡＭなどのメモリを有する（図示を省略）。演算部２ａは、記憶装置５で障害が発生すると、記憶装置６に記憶された履歴情報を用いて記憶装置５内のデータ群５ａを復旧させる。

図１（Ａ）は、演算部２ａが第１の履歴情報６ａを用いてデータ群５ａを第１の時点まで復旧させる際の演算部１ａの処理を例示している。演算部１ａは、情報処理装置３からの更新要求を継続して受け付け、データ群４ａの更新を継続する。演算部１ａは、更新に伴って第２の履歴情報６ｂを生成し、記憶装置６に格納する。演算部２ａは、第１の履歴情報６ａを用いてデータ群５ａを第１の時点まで復旧させると、第２の履歴情報６ｂを用いてデータ群５ａを第１の時点よりも後の第２の時点まで復旧させることになる。

図１（Ｂ）は、演算部２ａが第２の履歴情報６ｂを用いてデータ群５ａを第２の時点まで復旧させる際の演算部１ａの処理を示している。演算部１ａは、第２の履歴情報６ｂの情報量により第２の履歴情報６ｂを用いた復旧が完了するまでの時間を予測する。例えば、演算部１ａは、第１の履歴情報６ａを用いた復旧処理の実績から履歴情報を適用するための速度（単位時間当たりに適用可能な情報量）を計測しておくことが考えられる。そうすれば、当該速度と第２の履歴情報６ｂとの情報量により、第２の履歴情報６ｂを用いた復旧が完了するまでの時間を予測し得る。

演算部１ａは、予測された時間を閾値と比較し、比較結果に基づいて第２の履歴情報６ｂを用いた復旧が行われている間のデータ群４ａに対する更新の少なくとも一部を制限する。例えば、演算部１ａは、予測された時間が情報処理装置１に予め与えられた閾値を超える場合に当該更新の制限を行う。閾値は、データ群４ａに対する更新が、所定の確率で発生しないと期待される時間に基づいて定められてもよい。

演算部１ａは、情報処理装置３で実行されるソフトウェアやソフトウェアの種別により、制限対象とする更新を決定し得る。例えば、優先度の相対的に低いソフトウェアによる更新を制限し、優先度の相対的に高いソフトウェアによる更新を制限しないようにしてもよい。この場合、演算部１ａは、更新の制限対象のソフトウェアから更新要求を受け付けたとしても、更新を行わないようにする。

こうして、演算部２ａが第２の履歴情報６ｂを用いてデータ群５ａを第２の時点まで復旧させている間にも、演算部１ａは情報処理装置３からの更新要求を受け付ける。そして、演算部１ａは、第３の履歴情報６ｃを生成し、記憶装置６に格納する。演算部２ａは、第２の履歴情報６ｂを用いた復旧が完了すると、続いて第３の履歴情報６ｃを用いた復旧を行うことになる。

第１の実施の形態の情報処理システムによれば、第１の履歴情報６ａを用いた復旧が行われている間に、情報処理装置１により、データ群４ａに対する更新の要求が受け付けられ、更新の履歴を示す第２の履歴情報６ｂが生成される。情報処理装置１により、第２の履歴情報６ｂの情報量により、第２の履歴情報６ｂを用いた復旧が完了するまでの時間が予測される。情報処理装置１により、予測された時間が閾値と比較され、比較結果に基づいて第２の履歴情報６ｂを用いた復旧が行われている間のデータ群４ａに対する更新の少なくとも一部が制限される。

これにより、データ復旧の長期化を抑制できる。例えば、第２の履歴情報６ｂに記録された更新の量が多い場合、第２の履歴情報６ｂを用いた復旧に時間がかかる可能性がある。この場合、当該復旧の時間中の全ての更新を受け付けていると、第２の履歴情報６ｂの次の履歴情報に記録される更新の量も増大し、当該履歴情報を用いた復旧にも時間がかかる可能性がある。このように、ある履歴情報を用いた復旧が行われている間に、大量の更新が記録された別の履歴情報が生成され得る。そして、これが繰り返されると、データ復旧が長期化するおそれがある。この場合、データ群４ａ，５ａの同期を再開させるまでに時間がかかることになり、データ群４ａのみでの運用が長期化し得る。

そこで、情報処理装置１は、第２の履歴情報６ｂを用いた復旧に比較的時間がかかると予測される場合、第２の履歴情報６ｂを用いた復旧が行われている間のデータ群４ａに対する更新の少なくとも一部を制限する。すると、第３の履歴情報６ｃに記録される更新の量を低減でき、全ての更新を記録する場合よりも第３の履歴情報６ｃを用いた復旧時間を低減できる。よって、第３の履歴情報６ｃを用いた復旧が行われている間に記録される更新の量も低減できることになる。すると、その次の履歴情報を用いた復旧時間が増大することを抑えられ、当該復旧が行われている間に記録される更新の量の増大も抑えられる。このようにすれば、順次生成される履歴情報をデータ群５ａに適用するための時間が長くなることを抑制でき、データ復旧の長期化を抑制できる。

［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、ＤＢ（DataBase）サーバ１００，１００ａ、共有ストレージ２００およびＡＰ（Application）サーバ３００を含む。ＤＢサーバ１００，１００ａおよびＡＰサーバ３００は、ネットワーク１０を介して接続されている。ネットワーク１０は、ＬＡＮ（Local Area Network）でもよい。ネットワーク１０は、ＷＡＮ（Wide Area Network）やインターネットなどの広域ネットワークでもよい。

ＤＢサーバ１００，１００ａは、共有ストレージ２００に接続されている。ＤＢサーバ１００，１００ａおよび共有ストレージ２００は、直接接続されてもよい。ＤＢサーバ１００，１００ａおよび共有ストレージ２００は、ＬＡＮやＳＡＮ（Storage Area Network）を介して接続されてもよい。ＤＢサーバ１００，１００ａおよび共有ストレージ２００は、地理的に離れた拠点に設置されるものでもよい。

ＤＢサーバ１００，１００ａは、ＤＢを格納するサーバコンピュータである。ＤＢサーバ１００，１００ａに格納されたＤＢの内容は同期される。ＤＢサーバ１００，１００ａのうちの一方が正系となり、他方が副系となる。正系のＤＢサーバは、ＡＰサーバ３００から受け付けるアクセス要求に応じて、自装置のＤＢにアクセスし、アクセス結果をＡＰサーバ３００に応答する。アクセス要求には、ＤＢに対する参照要求や更新要求が含まれる。例えば、正系のＤＢサーバは、ＡＰサーバ３００からレコードの参照要求を受け付けると、ＤＢ内の対象のレコードを読み出して、当該レコードの内容をＡＰサーバ３００に応答する。ここで、ＤＢの更新には、ＤＢにデータを追加すること、ＤＢに含まれるレコードの設定値を変更すること、ＤＢに含まれるレコードを削除することを含む。

例えば、正系のＤＢサーバは、ＡＰサーバ３００からレコードの更新要求を受け付けると、ＤＢ内の対象のレコードを更新して、当該レコードの更新結果をＡＰサーバ３００に応答する。正系のＤＢでレコードが更新されると、当該更新内容が副系にも通知されて、副系のＤＢのレコードも更新される。このようなＤＢの同期方法は、例えば、ログシップ（Log Ship）あるいはログシッピング（Log Shipping）などと呼ばれる機能を用いて実現される。

副系のＤＢサーバは、正系のＤＢサーバでのレコード更新を自装置のＤＢにも反映させる。副系のＤＢサーバは、正系の故障時に正系の役割を引き継ぐ。すなわち、第２の実施の形態の情報処理システムでは、ＤＢサーバ１００，１００ａの何れか一方が故障しても、他方で業務処理を継続できる。これにより、耐障害性を高めている。ただし、何れかのＤＢサーバのみで運用を継続していると、当該ＤＢサーバが故障した場合に処理を継続することができなくなってしまう。そこで、故障したＤＢサーバを復旧して、正系・副系での運用を回復する。

共有ストレージ２００は、ＤＢのリカバリ用のデータを記憶する。例えば、正系のＤＢサーバは、定期的にＤＢ全体のデータを共有ストレージ２００に格納する。定期的に取得されたＤＢ全体のデータをバックアップデータと称する。バックアップデータの取得周期は、例えば、日次、週次などである。

バックアップデータには、直近のＤＢの内容が反映されていないことがある。このため、正系のＤＢサーバは、バックアップデータを取得した時点からのＤＢに対する更新の内容を示す履歴情報（ログ）を取得する。当該ログは、ＤＢに対するトランザクションの内容を記録した情報ということもできる。当該ログは、ＤＢに対して行った操作を再実行するために用いられる。例えば、復旧対象のＤＢにバックアップデータを適用させた後、ログの操作を再実行させることで、当該ＤＢを前方回復できる。

例えば、正系のＤＢサーバはＤＢの更新を受け付けると、ＤＢを更新するとともに、正系のＤＢサーバのＲＡＭに更新内容を記録したログを格納する。なお、正系のＤＢサーバは、ＤＢ内（データの実体）の操作を実際に行う前に、ＲＡＭに当該ログを書き出してもよい。このような手法は、ログ先行書き込み（ＷＡＬ：Write Ahead Log）と呼ばれることがある。例えば、正系のＤＢサーバは、ＲＡＭ上に複数のログファイルを配置し、ラウンドロビンで各ログファイルにログの内容を書き込む。ＲＡＭ上に配置されたログをオンラインログということがある。上記のログシップは、オンラインログを副系と共有して、ＤＢを同期する手法といえる。

正系のＤＢサーバは、所定のタイミングで、オンラインログの内容を共有ストレージ２００に格納する。例えば、所定のタイミングは、上記のラウンドロビンによりオンラインログの書き込み対象のログファイルを切り換えるとき、オンラインログのサイズが所定のサイズに達したとき、ユーザによる指定を受け付けたときなどである。共有ストレージ２００に格納されたログをアーカイブログということがある。アーカイブログは、共有ストレージ２００に複数格納され得る。

アーカイブログおよびオンラインログは、バックアップデータが取得された時点から現時点までのＤＢの差分を記録した情報といえる。すなわち、故障したＤＢサーバのＤＢを直近の状態に復旧したいときは、まず、最近のバックアップデータを用いて当該バックアップデータが取得された時点にＤＢを復旧する。次に、アーカイブログを用いて当該バックアップデータが取得された時点から直近のアーカイブログが取得された時点までのＤＢに対する操作を再実行する。これにより、アーカイブログが取得された時点までＤＢを復旧する。ここまでの手順を以下の説明では、リカバリと称する。すなわち、リカバリには、バックアップデータを用いた復旧とアーカイブログを用いた復旧とが含まれる。リカバリが完了すると、ＤＢサーバ１００，１００ａはログシップによるオンラインログの同期を再開して、正系・副系での運用を再開する。

ＡＰサーバ３００は、正系のＤＢサーバに対してＤＢのアクセス要求を送信する。ＡＰサーバ３００では、複数のアプリケーションソフトウェア（以下、単にアプリケーションまたはＡＰと略記することがある）が実行されている。複数のアプリケーションそれぞれが正系のＤＢサーバに対してアクセス要求を送信する。ＡＰサーバ３００は複数台設けられてもよい。すなわち、正系のＤＢサーバは、複数のＡＰサーバからＤＢのアクセス要求を受信することもできる。

なお、ＡＰサーバ３００により送信されたアクセス要求を受信し、正系のＤＢサーバに転送するサーバ装置を別途設けてもよい。この場合、ＡＰサーバ３００は、当該サーバ装置を介して、正系のＤＢサーバと通信する。

図３は、ＤＢサーバのハードウェア例を示す図である。ＤＢサーバ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、通信部１０４，１０４ａ、画像信号処理部１０５、入力信号処理部１０６、ディスクドライブ１０７および機器接続部１０８を有する。各ユニットがＤＢサーバ１００のバスに接続されている。ＤＢサーバ１００ａおよびＡＰサーバ３００もＤＢサーバ１００と同様のユニットを用いて実現できる。

プロセッサ１０１は、ＤＢサーバ１００の情報処理を制御する。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどである。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、ＤＢサーバ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションのプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。

ＨＤＤ１０３は、ＤＢサーバ１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションのプログラム、および各種データが格納される。ＤＢサーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。

通信部１０４は、ネットワーク１０を介して他のコンピュータと通信を行えるインタフェースである。通信部１０４は、有線インタフェースでもよいし、無線インタフェースでもよい。

通信部１０４ａは、共有ストレージ２００と通信を行えるインタフェースである。当該インタフェースとして、ＦＣ（Fibre Channel）やＳＣＳＩ（Small Computer System Interface）などを用いることができる。通信部１０４ａは、プロセッサ１０１からの命令に従って、共有ストレージ２００にデータを書き込んだり、共有ストレージ２００からデータを読み出したりする。ここで、共有ストレージ２００は、ＨＤＤやＳＳＤなどの記憶装置を有している。共有ストレージ２００は当該記憶装置にデータを格納する。共有ストレージ２００に格納されたデータはＤＢサーバ１００，１００ａからアクセス可能である。

画像信号処理部１０５は、プロセッサ１０１からの命令に従って、ＤＢサーバ１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。

入力信号処理部１０６は、ＤＢサーバ１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２としては、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。

ディスクドライブ１０７は、レーザ光などを利用して、光ディスク１３に記録されたプログラムやデータを読み取る駆動装置である。光ディスク１３として、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などを使用できる。ディスクドライブ１０７は、例えば、プロセッサ１０１からの命令に従って、光ディスク１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

機器接続部１０８は、ＤＢサーバ１００に周辺機器を接続するための通信インタフェースである。例えば、機器接続部１０８にはメモリ装置１４やリーダライタ装置１５を接続できる。メモリ装置１４は、機器接続部１０８との通信機能を搭載した記録媒体である。リーダライタ装置１５は、メモリカード１６へのデータの書き込み、またはメモリカード１６からのデータの読み出しを行う装置である。メモリカード１６は、カード型の記録媒体である。機器接続部１０８は、例えば、プロセッサ１０１からの命令に従って、メモリ装置１４またはメモリカード１６から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

図４は、情報処理システムの機能例を示す図である。ＤＢサーバ１００は、ＤＢ１１０、オンラインログ記憶部１２０、制御情報記憶部１３０およびＤＢ管理部１４０を有する。ＤＢ１１０および制御情報記憶部１３０は、ＲＡＭ１０２またはＨＤＤ１０３に確保した記憶領域として実現できる。オンラインログ記憶部１２０は、ＲＡＭ１０２に確保した記憶領域として実現できる。ＤＢ管理部１４０は、プロセッサ１０１が実行するソフトウェアのモジュールとして実現できる。ここで、図４では、ＤＢサーバ１００を正系、ＤＢサーバ１００ａを副系である場合を想定して各機能を説明する。

ＤＢ１１０は、ＡＰサーバ３００で動作する各アプリケーションの処理に用いられる各種のデータ群を記憶する。オンラインログ記憶部１２０は、ＤＢ１１０に対するオンラインログを記憶する。制御情報記憶部１３０は、ＤＢ管理部１４０による処理に用いられる各種のデータを記憶する。

ＤＢ管理部１４０は、ＤＢ１１０へのアクセス、オンラインログの生成およびアーカイブログの生成を行う。ＤＢ管理部１４０は、制御部１４１、同期部１４２、分析部１４３および復元部１４４を有する。

制御部１４１は、ＡＰサーバ３００から受け付けたアクセス要求に応じてＤＢ１１０にアクセスし、アクセス結果をＡＰサーバ３００に応答する。ＤＢ１１０に対するデータの参照や更新の内容は、例えば、ＳＱＬ文によって表される。制御部１４１はアクセス要求に応じたＳＱＬ文を実行することで、ＤＢ１１０に対する参照や更新を実行し得る。制御部１４１は、参照や更新に応じてＤＢ１１０に対する操作内容を記録したオンラインログを生成し、オンラインログ記憶部１２０に格納する。また、制御部１４１は、分析部１４３の指示に応じて、ＤＢ１１０の更新を制限する。

同期部１４２は、オンラインログ記憶部１２０に格納されたオンラインログをＤＢサーバ１００ａに送り、ＤＢサーバ１００，１００ａに格納された各ＤＢを同期させる（ログシップ）。例えば、同期部１４２は、所定の周期（例えば、数秒〜数分程度）でオンラインログに記録された新たな内容をＤＢサーバ１００ａに送ることが考えられる。

分析部１４３は、ＤＢサーバ１００ａでＤＢのリカバリが実行されている間のリカバリ状況および制御部１４１による新規のアーカイブログの生成状況を監視し、分析する。分析部１４３は、分析結果に応じて、ＤＢ１１０の更新を制限するよう制御部１４１に指示する。

復元部１４４は、ＤＢ１１０のリカバリを実行する。具体的には、復元部１４４は、共有ストレージ２００に記憶されたバックアップデータを用いて、バックアップデータが取得された時点までＤＢ１１０を復元する。更に、復元部１４４は、共有ストレージ２００に記憶されたアーカイブログを用いて、当該アーカイブログが最後に取得された時点までＤＢ１１０を復元する。

ＤＢサーバ１００ａは、ＤＢ１１０ａ、オンラインログ記憶部１２０ａ、制御情報記憶部１３０ａおよびＤＢ管理部１４０ａを有する。ＤＢ１１０ａ、オンラインログ記憶部１２０ａ、制御情報記憶部１３０ａおよびＤＢ管理部１４０ａは、ＤＢサーバ１００が有する同名の機能と同様である。ＤＢ管理部１４０ａは、ＤＢ管理部１４０と同様に、制御部１４１ａ、同期部１４２ａ、分析部１４３ａおよび復元部１４４ａを有する。ここで、ＤＢサーバ１００ａが副系である場合を想定すると、ＤＢ管理部１４０ａの各部の処理はＤＢ管理部１４０とは一部異なる。

制御部１４１ａは、オンラインログ記憶部１２０ａに記憶されたオンラインログを用いてＤＢ１１０ａを更新する。同期部１４２ａは、ＤＢサーバ１００からＤＢ１１０の更新に応じたオンラインログを受信し、オンラインログ記憶部１２０ａに格納する。

分析部１４３ａは、ＤＢサーバ１００ａが正系で動作する場合に、分析部１４３と同様の機能を発揮する。復元部１４４ａは、ＤＢ１１０ａのリカバリを実行する。具体的な方法は、復元部１４４と同様である。

ここで、ＤＢ１１０，１１０ａは、ＤＢサーバ１００，１００ａに格納されるものとしたが、ＤＢサーバ１００，１００ａ以外の装置に格納されてもよい。例えば、ＤＢサーバ１００，１００ａそれぞれに外付けされた記憶装置に格納されてもよいし、ＤＢサーバ１００，１００ａとネットワーク１０を介して接続された記憶装置に格納されてもよい。

共有ストレージ２００は、バックアップ記憶部２１０およびアーカイブログ記憶部２２０を有する。バックアップ記憶部２１０およびアーカイブログ記憶部２２０は、共有ストレージ２００が備えるＨＤＤやＳＳＤなどに確保した記憶領域として実現できる。

バックアップ記憶部２１０は、ＤＢサーバ１００またはＤＢサーバ１００ａにより定期的に取得されるバックアップデータを記憶する。アーカイブログ記憶部２２０は、アーカイブログを記憶する。

ＡＰサーバ３００は、複数の種類のアプリケーションを実行する。例えば、当該アプリケーションには、バッチ処理ＡＰ３１０、一般処理ＡＰ３２０およびオンライン処理ＡＰ３３０が含まれる。バッチ処理ＡＰ３１０は、バッチ処理を実行するアプリケーションの集合である。一般処理ＡＰ３２０は、第２の実施の形態の情報処理システムで実行される主な業務処理とは別個に実行される一般的な処理を実行するアプリケーションの集合である。オンライン処理ＡＰ３３０は、第２の実施の形態の情報処理システムで実行される主な業務処理を実行するアプリケーションの集合である。バッチ処理ＡＰ３１０、一般処理ＡＰ３２０およびオンライン処理ＡＰ３３０は、その処理の実行にＤＢ１１０へのアクセスを伴う。なお、ＡＰサーバ３００で実行される各アプリケーションは、それぞれが別個のＡＰサーバ上で実行されるものでもよい。

図５は、ＳＱＬ優先度テーブルの例を示す図である。ＳＱＬ優先度テーブル１３１は、制御情報記憶部１３０に予め格納される。ＳＱＬ優先度テーブル１３１は、ＳＱＬ優先度およびＡＰ区分の項目を含む。

ＳＱＬ優先度の項目には、ＳＱＬ優先度を示す値が登録される。ここで、ＳＱＬ優先度は、その値が大きいほど、より優先されることを示すものとする。ＡＰ区分の項目には、アプリケーションの区分（以下、ＡＰ区分ということがある）を示す情報が登録される。ＡＰ区分は、ＡＰサーバ３００で実行されるアプリケーションの種類に対応している。例えば、ＡＰ区分には、“バッチ処理”、“一般処理”および“オンライン処理”などがある。

例えば、ＳＱＬ優先度テーブル１３１には、ＳＱＬ優先度が“１”、ＡＰ区分が“バッチ処理”という情報が登録される。これは、ＡＰ区分“バッチ処理”であるアプリケーションのＳＱＬ優先度が“１”であることを示す。ＳＱＬ優先度“１”は最低の優先度である。

ＳＱＬ優先度テーブル１３１によれば、ＡＰ区分が“一般処理”であるアプリケーションのＳＱＬ優先度は“２”であり、ＡＰ区分“バッチ処理”のアプリケーションよりも１段階優先度が高い。また、ＡＰ区分が“オンライン処理”であるアプリケーションのＳＱＬ優先度は“３”であり、ＡＰ区分が“一般処理”であるアプリケーションよりも１段階優先度が高い。図５ではＳＱＬ優先度“４”以上のＡＰ区分の図示を省略している。

図６は、無更新確率テーブルの例を示す図である。無更新確率テーブル１３２は、優先度閾値よりも小さいＳＱＬ優先度であるアプリケーションに対してＤＢ１１０の更新を制限した場合に、ＤＢ１１０が無更新である確率を、時間経過に対して求めたものである。無更新確率テーブル１３２は、制御情報記憶部１３０に格納される。無更新確率テーブル１３２は、分析部１４３により生成される。無更新確率テーブル１３２は、優先度閾値および無更新確率の項目を含む。

優先度閾値の項目には、優先度閾値が登録される。無更新確率の項目には、時間の経過に対して、ＤＢ１１０が無更新である確率（無更新確率）が登録される。
例えば、無更新確率テーブル１３２には、優先度閾値が“１”、１分間の無更新確率が“８０％”、２分間の無更新確率が“６７％”、３分間の無更新確率が“５５％”、・・・という情報が登録される。これは、ＤＢ１１０にアクセスする全てのアプリケーションがＤＢ１１０の更新を行う場合、ＤＢ１１０が１分間無更新である確率が“８０％”であることを示す。また、同じ場合に、ＤＢ１１０が２分間無更新である確率が“６７％”であること、３分間無更新である確率が“５５％”であることを示す。

また、例えば、無更新確率テーブル１３２には、優先度閾値が“２”、１分間の無更新確率が“８３％”、２分間の無更新確率が“７０％”、３分間の無更新確率が“６０％”、・・・という情報が登録される。これは、ＳＱＬ優先度が“２”以上のアプリケーションがＤＢ１１０の更新を行う場合、ＤＢ１１０が１分間無更新である確率が“８３％”であることを示す。また、同じ場合に、ＤＢ１１０が２分間無更新である確率が“７０％”であること、３分間無更新である確率が“６０％”であることを示す。

無更新確率テーブル１３２において、同一の優先度閾値の場合、時間が長くなるほど、更新要求を受け付ける可能性は高まるので、無更新確率は小さくなる傾向となる。また、同一の時間の場合、優先度閾値が大きくなるほど、更新を行うアプリケーションの数が少なくなるので、無更新確率は大きくなる傾向となる。

また、後述するように、ＤＢサーバ１００は、優先度閾値を選択し、ＳＱＬ優先度が優先度閾値以上であるＡＰ区分についてＤＢ更新を許容し、ＳＱＬ優先度が優先度閾値よりも小さいＡＰ区分についてＤＢ更新を制限する。すなわち、優先度閾値は、ＤＢ更新を制限するＡＰ区分の選択パターンを示しているといえる。例えば、優先度閾値“１”は何れのＡＰ区分に対してもＤＢ更新を制限しないことを示す。例えば、優先度閾値“３”は優先度閾値“１”、“２”のＡＰ区分に対してＤＢ更新を制限することを示す。

図７は、アクセス統計テーブルの例を示す図である。アクセス統計テーブル１３３，１３３ａ，１３３ｂ，・・・は、無更新確率テーブル１３２を求めるために作成されるものである。アクセス統計テーブル１３３，１３３ａ，１３３ｂ，・・・は、制御情報記憶部１３０に格納される。アクセス統計テーブル１３３，１３３ａ，１３３ｂ，・・・は、分析部１４３により生成される。

アクセス統計テーブル１３３，１３３ａ，１３３ｂ，・・・は、ＳＱＬ優先度の複数の範囲に対して生成される。ＳＱＬ優先度の複数の範囲とは、ＳＱＬ優先度が“１以上”、“２以上”、“３以上”、・・・というものである。例えば、アクセス統計テーブル１３３は、ＳＱＬ優先度“１以上”のＡＰ区分について計測された情報である。アクセス統計テーブル１３３ａは、ＳＱＬ優先度“２以上”のＡＰ区分について計測された情報である。アクセス統計テーブル１３３ｂは、ＳＱＬ優先度“３以上”のＡＰ区分について計測された情報である。

アクセス統計テーブル１３３，１３３ａ，１３３ｂ，・・・は、時間、計測数、更新数および無更新確率の項目を含む。時間の項目には、計測した累積の時間（経過時間）が登録される。計測数には、受け付けたアクセス要求の数が登録される。更新数の項目には、受け付けた更新要求の数が登録される。無更新確率の項目には、計測数に対する（計測数−更新数）の割合が登録される。

例えば、アクセス統計テーブル１３３には、時間が“１分間”、計測数が“２０”、更新数が“４”、無更新確率が“８０％”という情報が登録されている。これは、ＳＱＬ優先度が“１以上”のＡＰ区分に属するアプリケーション（すなわち、全てのＡＰ区分に属するアプリケーション）から計測開始より１分間の間に、アクセス要求を２０回受け付け、そのうち更新要求が４回であったことを示す。この場合、無更新確率は、｛（２０−４）／２０｝×１００＝８０％となる。アクセス統計テーブル１３３には、２分間、３分間、・・・と同様にして、累積時間ごとの無更新確率が記録される。アクセス統計テーブル１３３ａ，１３３ｂ，・・・についても同様である。

なお、制御部１４１および分析部１４３は、アクセス要求に含まれるアプリケーションの識別子（例えば、ＳＱＬ文に付加されたアプリケーションの識別子）により、何れのアプリケーションからアクセス要求を受け付けたかを識別できる。制御情報記憶部１３０には、各アプリケーションが何れのＡＰ区分に属するかを示す情報が予め記憶される。制御部１４１および分析部１４３は、当該情報を参照することで、ＡＰ区分単位の計測数および更新数を把握できる。ＡＰ区分単位の計測数および更新数をＳＱＬ優先度の範囲ごと、経過時間ごとに積算すれば、アクセス統計テーブル１３３，１３３ａ，１３３ｂ，・・・を得られる。

次に、第２の実施の形態の処理を例示する。以下の説明では、まず、ＤＢサーバ１００が副系であり、ＤＢサーバ１００ａが正系である場合を想定する。その後、ＤＢサーバ１００ａが故障すると、ＤＢサーバ１００が正系に切り換わることになる。

図８は、ログの出力例を示す図である。ＤＢ管理部１４０ａは、ＡＰサーバ３００から参照要求を受信する。ＤＢ管理部１４０ａは、参照要求に応じて、ＤＢ１１０ａからデータを読み出し、ＡＰサーバ３００に応答する。ＤＢ管理部１４０ａは、ＡＰサーバ３００から更新要求を受信する。ＤＢ管理部１４０ａは、更新要求に応じて、ＤＢ１１０ａを更新する。ＤＢ管理部１４０ａは更新の内容をオンラインログ１２１ａに書き出す。ＤＢ管理部１４０ａはオンラインログ１２１ａをオンラインログ記憶部１２０ａに格納する。

オンラインログ１２１ａは、ログシップ機能によりＤＢサーバ１００にも送られ、オンラインログ１２１としてオンラインログ記憶部１２０に格納される。ＤＢ管理部１４０は、オンラインログ１２１を用いてＤＢ１１０ａに対する更新内容をＤＢ１１０にも反映させる。

また、ＤＢ管理部１４０ａは、所定のタイミングでオンラインログ１２１ａからアーカイブログ２２１を生成し、アーカイブログ記憶部２２０に格納する。このような通常運用の状態から、ＤＢサーバ１００ａが故障した場合の処理を以下に例示する。ただし、ＤＢサーバ１００，１００ａの役割が逆になっても、処理の実行主体が入れ替わる他は、同様の手順となる。

図９は、障害時の正系の処理の例を示すフローチャートである。以下、図９に示す処理をステップ番号に沿って説明する。
（Ｓ１１）制御部１４１は、ＤＢサーバ１００ａの故障を検出する。例えば、ＤＢサーバ１００，１００ａは、死活監視用の所定の通信を定期的に行い、正系側がダウンしたか否かを判断してもよい。例えば、制御部１４１は、当該死活監視用の通信を行えなくなったことを検出することで、正系であるＤＢサーバ１００ａの故障を検出し得る。あるいは、制御部１４１は、ネットワーク１０に接続された管理用の端末装置から、ＤＢサーバ１００ａが故障した旨の通知を受け付けることで、当該故障を検出してもよい。

（Ｓ１２）制御部１４１は、ＤＢサーバ１００ａから正系の役割を引き継ぐ。ＤＢサーバ１００が正系として動作することになる。以降、ＤＢサーバ１００ａに代えて、ＤＢサーバ１００がＡＰサーバ３００からのアクセス要求を受け付けることになる。オンラインログおよびアーカイブログを生成する役割もＤＢサーバ１００が引き継ぐ。

（Ｓ１３）制御部１４１は、オンラインログの同期を停止するよう同期部１４２に指示する。同期部１４２は、オンラインログの同期を停止する。
（Ｓ１４）制御部１４１は、ＡＰサーバ３００からのアクセス要求を受け付け、ＤＢ１１０の運用を継続する。制御部１４１は、ＤＢ１１０の更新に応じてオンラインログおよびアーカイブログの生成を継続する。制御部１４１は、生成したオンラインログをオンラインログ記憶部１２０に格納する。制御部１４１は、生成したアーカイブログをアーカイブログ記憶部２２０に格納する。

（Ｓ１５）制御部１４１は、ＤＢサーバ１００ａからリカバリ開始の通知を受信することで、ＤＢサーバ１００ａにおけるリカバリ開始を検出する。
（Ｓ１６）制御部１４１は、ＤＢ１１０に対するリカバリ時のアクセス制御を行う。制御部１４１による具体的なアクセス制御の内容は、後述するように分析部１４３によって決定される。

（Ｓ１７）制御部１４１は、ＤＢサーバ１００ａのリカバリが完了したことを検出する。ＤＢサーバ１００ａは副系として動作することになる。
（Ｓ１８）制御部１４１は、オンラインログの同期を再開するよう同期部１４２に指示する。制御部１４１は、何れかのアプリケーションについてＤＢ１１０の更新を制限している場合、当該制限を解除する。同期部１４２は、同期部１４２ａとの間でオンラインログの同期を再開する。

このようにして、正系であるＤＢサーバ１００ａが故障した場合は、ＤＢサーバ１００が正系の役割を引き継ぐ。そして、ＤＢサーバ１００ａのリカバリが完了すると、オンラインログの同期を再開させ、ＤＢサーバ１００，１００ａでの冗長化運用を再開させる。

ここで、ステップＳ１１において、ＤＢサーバ１００を副系、ＤＢサーバ１００ａを正系としたが、ＤＢサーバ１００を正系、ＤＢサーバ１００ａを副系とした場合も同様である。その場合、ＤＢサーバ１００は、ステップＳ１２の処理をスキップしてステップＳ１３を実行すればよい。

図１０は、片系運用時のログの出力例を示す図である。図１０では、図９のステップＳ１４におけるＤＢサーバ１００によるオンラインログおよびアーカイブログの生成を例示している。この場合、ＤＢ管理部１４０は、ＤＢ１１０に対する更新に応じてオンラインログ１２２を生成し、オンラインログ記憶部１２０に格納する。また、ＤＢ管理部１４０は、所定のタイミングでアーカイブログ２２２を生成し、アーカイブログ記憶部２２０に格納する。また、ＤＢサーバ１００ａは、故障しているので、ログシップの機能は停止されている（ＤＢサーバ１００，１００ａ間のオンラインログの同期は行われない）。次に、ＤＢサーバ１００ａのリカバリ処理を説明する。

図１１は、副系のリカバリ処理の例を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。
（Ｓ２１）制御部１４１ａは、リカバリ開始の指示を受け付ける。制御部１４１ａは、ＤＢサーバ１００ａに接続された入力デバイスに対するユーザの所定の操作を受け付けることで、当該リカバリ開始の指示を受け付けてもよい。制御部１４１ａは、ネットワーク１０に接続された所定の管理用の端末装置から当該リカバリ開始の指示を受信してもよい。

（Ｓ２２）制御部１４１ａは、ＤＢサーバ１００にリカバリの開始を通知する。制御部１４１ａは、復元部１４４ａによるリカバリを開始させる。
（Ｓ２３）復元部１４４ａは、バックアップデータの適用開始をＤＢサーバ１００に通知する。復元部１４４ａは、バックアップ記憶部２１０に記憶されたバックアップデータを取得し、ＤＢ１１０ａに適用する。これにより、ＤＢ１１０ａは当該バックアップデータが生成された時点まで復旧される。復元部１４４ａは、バックアップデータの適用完了をＤＢサーバ１００に通知する。

（Ｓ２４）復元部１４４ａは、アーカイブログの適用開始をＤＢサーバ１００に通知する。復元部１４４ａは、アーカイブログ記憶部２２０に記憶されたアーカイブログを取得し、ＤＢ１１０ａに適用する。これにより、ＤＢ１１０ａは当該アーカイブログが生成された時点まで復旧される。復元部１４４ａは、アーカイブログの適用完了をＤＢサーバ１００に通知する。ステップＳ２４が実行されている間にも、ＤＢサーバ１００ではＤＢ１１０の更新が行われ得る。

（Ｓ２５）復元部１４４ａは、アーカイブログ記憶部２２０を参照して、アーカイブログの適用中にＤＢサーバ１００により生成された新たなアーカイブログ（差分アーカイブログということがある）があるか否かを判定する。差分アーカイブログがある場合、処理をステップＳ２６に進める。差分アーカイブログがない場合、処理をステップＳ２７に進める。

（Ｓ２６）復元部１４４ａは、差分アーカイブログの適用開始（差分適用開始）をＤＢサーバ１００に通知する。復元部１４４ａは、アーカイブログ記憶部２２０に記憶された差分アーカイブログを取得し、ＤＢ１１０ａに適用する。以下の説明では、この処理を差分適用ということがある。これにより、ＤＢ１１０ａは当該差分アーカイブログが生成された時点まで復旧される。復元部１４４ａは、差分アーカイブログの適用完了（差分適用完了）をＤＢサーバ１００に通知する。そして、処理をステップＳ２５に進める。ステップＳ２６の後にステップＳ２５を実行する場合、復元部１４４ａは、当該差分アーカイブログの適用中に生成された、他の差分アーカイブログがあるか否かを判定することになる。

（Ｓ２７）復元部１４４ａは、リカバリの完了を制御部１４１ａに通知する。制御部１４１ａは、ＤＢ１１０ａのリカバリが完了した旨をＤＢサーバ１００に通知する（復元部１４４ａが当該通知を行ってもよい）。

このようにして、ＤＢサーバ１００ａにおけるＤＢ１１０ａのリカバリが行われる。次に、ＤＢサーバ１００ａによるＤＢ１１０ａのリカバリの具体例を説明する。
図１２は、リカバリの具体例を示す図である。ＤＢ管理部１４０ａは、バックアップ記憶部２１０からバックアップデータを読み出してＤＢ１１０ａに適用する（ステップＳ２３）。ＤＢ管理部１４０ａは、アーカイブログ記憶部２２０からアーカイブログ２２２を読み出してＤＢ１１０ａに適用する（ステップＳ２４）。アーカイブログ２２２がＤＢ１１０ａに提供されている間にも、ＤＢ管理部１４０により差分アーカイブログ２２３が生成されてアーカイブログ記憶部２２０に格納される。

ＤＢ管理部１４０ａは、アーカイブログ記憶部２２０から差分アーカイブログ２２３を読み出してＤＢ１１０ａに適用する（ステップＳ２６）。差分アーカイブログ２２３をＤＢ１１０ａに適用している間にも、ＤＢ管理部１４０により新規の差分アーカイブログ２２４が生成されてアーカイブログ記憶部２２０に格納される。すると、ＤＢ管理部１４０ａは、差分アーカイブログ２２３の適用が完了すると、新規の差分アーカイブログ２２４をアーカイブログ記憶部２２０から読み出してＤＢ１１０ａに適用する（ステップＳ２６ａ）。

このように、ＤＢ管理部１４０ａは未適用の差分アーカイブログがなくなるまで、生成された順に差分アーカイブログを取得して順次適用する。次に、図９のステップＳ１６の手順を説明する。

図１３は、副系リカバリ時の正系の制御の例を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。
（Ｓ３１）制御部１４１は、分析部１４３による分析を開始させる。分析部１４３は、統計情報を収集する。具体的には、分析部１４３は、ＡＰサーバ３００から受け付けるアクセス要求を参照して、アクセス統計テーブル１３３，１３３ａ，１３３ｂ，・・・を生成し、制御情報記憶部１３０に格納する。また、分析部１４３は、更新対象となったデータ量（例えば、オンラインログに書き込んだデータ量）や更新を受け付けた時間などを記録し、制御情報記憶部１３０に格納しておく。例えば、分析部１４３は、ＤＢサーバ１００ａによりバックアップデータの適用が行われている間に受け付けたＤＢ１１０に対するアクセス要求に基づいて、当該統計情報の収集を行える。また、分析部１４３は、図１１のステップＳ２３のバックアップデータの適用開始および適用完了の通知を基に、バックアップデータの適用に要した時間を計測し、制御情報記憶部１３０に格納しておく。

（Ｓ３２）分析部１４３は、制御情報記憶部１３０に記憶されたアクセス統計テーブル１３３，１３３ａ，１３３ｂ，・・・に基づいて、無更新確率テーブル１３２を生成し、制御情報記憶部１３０に格納する。

（Ｓ３３）分析部１４３は、ＤＢサーバ１００ａからアーカイブログの適用開始の通知を受け付ける。アーカイブログの適用開始の通知は、図１１で説明したステップＳ２４の適用開始の通知に相当する。分析部１４３は、アーカイブログ適用時間の計測を開始する。アーカイブログ適用時間の計測は、アーカイブログ（差分アーカイブログを含む）の適用に要した累積時間（総適用時間）を把握するために行われるものである。

（Ｓ３４）分析部１４３は、ステップＳ３１で収集された統計情報に基づいて、ＤＢ更新速度Ｖｕを算出する。ＤＢ更新速度Ｖｕは、例えば、バックアップデータの適用時間中に更新されたデータ量（例えば、アーカイブログに書き込まれたデータ量）を、当該適用時間で割ることで算出できる。ＤＢ更新速度Ｖｕを、アーカイブログの単位時間当たりの平均の増加量の予測値と考えることができる。また、分析部１４３は、ＤＢサーバ１００ａからアーカイブログの適用完了の通知を受け付ける。アーカイブログの適用完了の通知は、図１１で説明したステップＳ２４の適用完了の通知に相当する。すると、分析部１４３は、当該ステップＳ２４において適用が完了したアーカイブログのサイズと、適用に要した時間とに基づいて、差分適用予測速度Ｖａを算出する。差分適用予測速度Ｖａは、単位時間当たりに適用されたアーカイブログの平均サイズである（これを差分アーカイブログの適用速度の予測値として用いる）。例えば、Ｖｕ，Ｖａの何れも、バイト毎秒などの単位で表すことができる。

（Ｓ３５）分析部１４３は、アーカイブログ記憶部２２０を参照して、アーカイブログの適用中に生成された差分アーカイブログがあるか否かを判定する。差分アーカイブログがある場合、処理をステップＳ３６に進める。差分アーカイブログがない場合、処理を終了する。分析部１４３は、アーカイブログ適用中に制御部１４１により差分アーカイブログが生成されたか否かを監視することで当該判定を行ってもよい。

（Ｓ３６）分析部１４３は、完了希望時間Ｎに基づいて、確保すべき無更新確率ｐを算出する。完了希望時間Ｎは、全ての差分アーカイブログを用いたＤＢ１１０ａの復旧にかけられる時間としてユーザにより予め指定された時間である。分析部１４３は、全ての差分アーカイブログの適用が時間Ｎ以内に終わるように無更新確率ｐを決定する。具体的には、完了希望時間Ｎは、更新確率ｑ＝１−ｐを用いて、式（１）のように表せる。式（１）は、式（２），（３），（４）のように変形できる。

ここで、Ｓは、最初の差分アーカイブログのサイズ（例えば、単位はバイト）である。式（２）は、和記号を用いて式（１）を書き換えたものである。式（３）は、式（２）の係数を和記号の前に移動させたものである。式（３）において、０≦ｑ≦１である。また、アーカイブログの適用は連続したＤＢ更新を伴うため、更新要求による通常のＤＢ更新よりも、単位時間当たりの更新量は大きいと考えられるから、０＜Ｖｕ／Ｖａ＜１と考えられる。よって、０＜ｑ×（Ｖｕ／Ｖａ）＜１が成り立つ。式（３）から式（４）への変形にこの関係を用いている。式（４）をｑについて解くことで、式（５）を得る。

無更新確率ｐと更新確率ｑとの関係は式（６）で表せるから、無更新確率ｐは式（７）で表せる。

式（７）に計測したＶｕ，Ｖａ，Ｓと、ユーザにより予め与えられたＮの値を代入することで、無更新確率ｐを得る。例えば、時間Ｎとして６０分（３６００秒）、１２０分（７２００秒）など、運用に応じた値のユーザによる入力を許容する。すなわち、完了希望時間Ｎ以内で全ての差分アーカイブログの適用を完了させるためには、ＤＢ１１０に対して無更新確率ｐ以上を維持できる時間以内に、各差分アーカイブログの適用が行われればよい。

（Ｓ３７）分析部１４３は、ステップＳ３６で算出された無更新確率ｐに対して、無更新確率テーブル１３２を参照し、ＤＢ更新制限なし（すなわち、優先度閾値“１”）で無更新確率ｐ以上を確保できる最大の時間を無更新期待時間τ＝τ₀として特定する。例えば、無更新確率テーブル１３２によれば、ｐ＝６０％であれば、τ₀＝２分間である。τ₀は、無更新期待時間（ＤＢ１１０が無更新であると期待される時間）の初期値である。

（Ｓ３８）分析部１４３は、変数ｎに１を代入する。ここで、変数ｎは差分適用の回数を管理するための変数である。
（Ｓ３９）分析部１４３は、１回目の差分適用開始の通知を受け付ける。当該差分適用開始の通知は、図１１で説明したステップＳ２６の１回目の差分適用開始の通知に相当する。分析部１４３は、１回目の差分適用完了まで待機する。１回目の差分適用中は、ＤＢ１１０に対する更新制限を行わない。分析部１４３は、ＤＢサーバ１００ａから１回目の差分適用完了の通知を受け付けることで、当該１回目の差分適用が完了したことを検出する。

（Ｓ４０）分析部１４３は、差分適用時のＤＢ更新制御を行う。処理の詳細は後述する。
ここで、ステップＳ３１で示したように、リカバリ中に統計情報を収集すれば、最新のアクセス状況に基づいて、ＤＢ１１０の更新制限を行える。ただし、統計の収集方法は、ユーザにより任意に決定され得る。例えば、分析部１４３はＤＢ１１０ａのリカバリが開始される前に、アクセス統計テーブル１３３，１３３ａ，１３３ｂ，・・・を作成しておいてもよい。具体的には、前の週の同じ曜日における１日分のアクセス統計を、アーカイブログのバックアップなどから取得してもよい。そうすれば、曜日別のアクセス状況に基づいて、ＤＢ１１０の更新制限を行える。

なお、アクセス統計テーブル１３３，１３３ａ，１３３ｂ，・・・では統計情報を収集する時間の単位を１分とし、無更新確率を（経過時間の）１分単位に取得するものとしたが、他の時間を単位としてもよい。例えば、３０秒単位、５分単位、１０分単位、３０分単位などとしてもよい。

また、統計情報を収集する時間も任意に決定可能である。例えば、３０分、１時間などと時間範囲を定めて統計情報を収集してもよい。または、アーカイブログの増加分を予め与え、当該増加分に対応する時間帯のアクセス要求を採取して統計情報を収集してもよい。または、所定のサンプル数を予め与え、当該サンプル数に達するまでアクセス要求を採取して、統計情報を収集してもよい。

更に、無更新確率ｐは、ユーザにより予め与えられてもよい。例えば、リカバリが長引いても、ＤＢ更新の制限をかけたくない場合は、ｐ＝０％を予め設定しておいてもよい（常に全ての更新を許容する）。あるいは、参照業務専門のＤＢである場合など、更新を気にしない場合には、ｐ＝１００％を予め設定しておいてもよい（以降の処理に拘わらず、常に全ての更新が制限されることになる）。あるいは、ｐ＝５０％など、所定の値が予め設定されていてもよい。ｐの値が予め与えられる場合はステップＳ３６をスキップする。

また、ステップＳ３４〜Ｓ３７の処理に時間を要する場合には、ＤＢサーバ１００ａで１回目の差分適用が行われている間に、ステップＳ３４〜Ｓ３７を実行することも考えられる（１回目の差分適用完了まで時間的な猶予がある）。この場合、ステップＳ３９における１回目の差分適用開始の通知をステップＳ３８よりも前に受け付ける。次に、上記ステップＳ４０のＤＢ更新制御の手順を説明する。

図１４は、正系のＤＢ更新制御の例を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。
（Ｓ４１）分析部１４３は、差分適用中に生成された新規の差分アーカイブログがあるか否かを判定する。新規の差分アーカイブログがある場合、処理をステップＳ４２に進める。新規の差分アーカイブログがない場合、処理を終了する。分析部１４３は、差分適用中に制御部１４１により新規の差分アーカイブログが生成されたか否かを監視することで当該判定を行ってもよい。

（Ｓ４２）分析部１４３は、変数ｎに１を加算する。
（Ｓ４３）分析部１４３は、アーカイブログ（差分アーカイブログを含む）の総適用時間が閾値時間以上であるか否かを判定する。アーカイブログの総適用時間が閾値時間以上である場合、処理をステップＳ４４に進める。アーカイブログの総適用時間が閾値時間よりも小さい場合、処理をステップＳ４５に進める。ステップＳ４３の時点でのアーカイブログの総適用時間は、図１３のステップＳ３３で計測が開始されたアーカイブログ適用時間を参照すれば得られる。また、例えば、閾値時間は制御情報記憶部１３０に予め格納される。例えば、閾値時間はバックアップデータの適用に要した時間の２倍の時間とする。なお、バックアップデータの適用に要した時間は、図１３のステップＳ３１で取得済である。

（Ｓ４４）分析部１４３は、全てのアプリケーションによるＤＢ１１０の更新を制限する（更新要求を受け付けても更新しない）。そして、処理をステップＳ４９に進める。
（Ｓ４５）分析部１４３は、ｎ回目の差分適用時間Ｔｎを予測する。具体的には、「差分適用時間Ｔｎ＝（ｎ−１回目の差分適用中に生成された新規の差分アーカイブログのサイズ）／差分適用予測速度Ｖａ」とする。

（Ｓ４６）分析部１４３は、予測された差分適用時間Ｔｎ＞無更新期待時間τであるか否かを判定する。Ｔｎ＞τである場合、処理をステップＳ４７に進める。Ｔｎ≦τである場合、処理をステップＳ４９に進める。

（Ｓ４７）分析部１４３は、制御情報記憶部１３０に記憶された無更新確率テーブル１３２を参照して、無更新確率がｐ以上であり、かつ、差分適用時間Ｔｎ≦無更新期待時間τ＝τ’となるような時間τ’を取り得る優先度閾値を特定する。そして、分析部１４３は、特定した優先度閾値のうち最小の優先度閾値を特定する。当該最小の優先度閾値に対して無更新確率がｐ以上である最大の時間τ’をτに再設定する。例えば、前述のように無更新確率ｐ＝６０％、無更新期待時間τ＝τ₀＝２分間であり、予測された差分適用時間Ｔｎ＝４分であるとする。このとき、無更新確率テーブル１３２によれば、無更新期待時間τ＝τ’＝５分間に再設定され、優先度閾値“３”が特定される。これは、予測された差分適用時間Ｔｎに対して無更新確率ｐ＝６０％以上を維持するために、ＳＱＬ優先度が“３”よりも小さいＡＰ区分に属するアプリケーションによるＤＢ１１０の更新を制限すればよいことを意味する。

（Ｓ４８）分析部１４３は、ステップＳ４７で特定された優先度閾値よりも小さいＳＱＬ優先度のＡＰ区分に属するアプリケーションによる、ＤＢ１１０の更新を制限するように、制御部１４１に指示する。以降、制御部１４１は、指示されたアプリケーションによるＤＢ１１０の更新を制限する。例えば、特定された優先度閾値が“３”であれば、ＳＱＬ優先度“１”であるＡＰ区分“バッチ処理”に属するアプリケーションおよびＳＱＬ優先度“２”であるＡＰ区分“一般処理”に属するアプリケーションから更新要求を受信しても、更新を行わない。この場合、当該更新要求に対応するログは、オンラインログおよび差分アーカイブログに記録されないことになる。逆にいえば、ＳＱＬ優先度が“３”以上であるＡＰ区分に属するアプリケーションによるＤＢ１１０の更新のみを許容する。

（Ｓ４９）分析部１４３は、ｎ回目の差分適用開始の通知を受け付ける。当該差分適用開始の通知は、図１１で説明したステップＳ２６のｎ回目の差分適用開始の通知に相当する。分析部１４３は、ｎ回目の差分適用完了まで待機する。分析部１４３は、ＤＢサーバ１００ａからｎ回目の差分適用完了の通知を受け付けることで、当該ｎ回目の差分適用が完了したことを検出する。そして、処理をステップＳ４１に進める。

このように、ＤＢサーバ１００は、ＤＢサーバ１００ａで差分アーカイブログの適用が行われている間、ＤＢ１１０の更新を制限する。このとき、ＤＢサーバ１００は、ＡＰ区分ごとのＳＱＬ優先度を示すＳＱＬ優先度テーブル１３１を参照して、予測された差分適用時間以上の時間経過に対してＤＢ１１０ａが更新されない確率が無更新確率ｐ以上となるように、ＳＱＬ優先度の低い方から、更新の制限対象とするＡＰ区分を選択する。

更新の制限対象とするＡＰ区分の複数の選択パターン、および、各選択パターンを採用した場合に時間経過に対してＤＢ１１０ａが更新されない確率は、無更新確率テーブル１３２により与えられている。分析部１４３は、複数の選択パターンの中から、予測された差分適用時間以上の時間経過に対してＤＢ１１０ａが更新されない確率が無更新確率ｐ以上となる選択パターン（優先度閾値）を特定しているともいえる。

なお、ステップＳ４４で示したように、アーカイブログの総適用時間が閾値時間以上である場合に、ＤＢ１１０に対する全ての更新を行わないようにすることで、リカバリの所要時間が過大となるのを抑制できる。

図１５は、リカバリ時の処理の例を示すシーケンスである。以下、図１５に示す処理をステップ番号に沿って説明する。図１５では、アーカイブログの適用中に差分アーカイブログが生成される場合を例示している。なお、図１５では、図１２で例示した符号を用いる。

（ＳＴ１０１）ＤＢサーバ１００ａは、リカバリの開始指示を受け付ける。
（ＳＴ１０２）ＤＢサーバ１００ａは、バックアップデータの適用開始をＤＢサーバ１００に通知する（バックアップデータ適用開始通知の送信）。ＤＢサーバ１００は、当該通知を受信する。ＤＢサーバ１００は、統計情報の取得を開始する。ＤＢサーバ１００ａは、バックアップ記憶部２１０からバックアップデータを読み出して、ＤＢ１１０ａの復旧を行う。ＤＢサーバ１００は、当該復旧中にも更新要求を受け付け、オンラインログおよびアーカイブログを生成する。

（ＳＴ１０３）ＤＢサーバ１００ａは、バックアップデータの適用を完了する。ＤＢサーバ１００ａは、バックアップデータの適用完了をＤＢサーバ１００に通知する（バックアップデータ適用完了通知の送信）。ＤＢサーバ１００は、当該通知を受信する。

（ＳＴ１０４）ＤＢサーバ１００ａは、アーカイブログの適用開始をＤＢサーバ１００に通知する（アーカイブログ適用開始通知の送信）。ＤＢサーバ１００は、当該通知を受信する。ＤＢサーバ１００は、アーカイブログ適用開始時間の計測を開始する。ＤＢサーバ１００ａは、アーカイブログ記憶部２２０からアーカイブログ２２２を読み出して、ＤＢ１１０ａの復旧を行う。ＤＢサーバ１００は、当該復旧中にも更新要求を受け付ける。ＤＢサーバ１００は、更新に応じてオンラインログを生成する。また、ＤＢサーバ１００は、オンラインログに基づいて差分アーカイブログ２２３を生成し、アーカイブログ記憶部２２０に格納する。

（ＳＴ１０５）ＤＢサーバ１００ａは、アーカイブログ２２２の適用を完了する。ＤＢサーバ１００ａは、アーカイブログの適用完了をＤＢサーバ１００に通知する（アーカイブログ適用完了通知の送信）。ＤＢサーバ１００は、当該通知を受信する。

（ＳＴ１０６）ＤＢサーバ１００は、アーカイブログ２２２の適用状況に基づいて、差分適用予測速度Ｖａを算出する。また、ＤＢサーバ１００は、ＤＢ更新速度Ｖｕも算出する。ただし、ＤＢ更新速度Ｖｕは、別のタイミング（例えば、ステップＳＴ１０６よりも前）に算出しておいてもよい。また、例えば、ＤＢサーバ１００は完了希望時間Ｎから先の式（７）を用いて、無更新確率ｐを算出し、無更新期待時間τ＝τ₀を特定する（ただし、前述のように無更新確率ｐとして予め与えられた値を用いてもよい）。

（ＳＴ１０７）ＤＢサーバ１００ａは、１回目（ｎ＝１）の差分適用開始をＤＢサーバ１００に通知する（差分適用開始通知の送信）。ＤＢサーバ１００は、当該通知を受信する。ＤＢサーバ１００ａは、アーカイブログ記憶部２２０から差分アーカイブログ２２３を読み出して、ＤＢ１１０ａの復旧を行う。ＤＢサーバ１００は、当該復旧中にも更新要求を受け付ける。ＤＢサーバ１００は、更新に応じてオンラインログを生成する。また、ＤＢサーバ１００は、オンラインログに基づいて差分アーカイブログ２２４を生成し、アーカイブログ記憶部２２０に格納する。

（ＳＴ１０８）ＤＢサーバ１００ａは、１回目（ｎ＝１）の差分適用完了をＤＢサーバ１００に通知する（差分適用完了通知の送信）。ＤＢサーバ１００は、当該通知を受信する。

（ＳＴ１０９）ＤＢサーバ１００は、差分適用時間Ｔ２を予測する。差分適用時間Ｔ２は、差分アーカイブログ２２４の適用に要する時間の予測値である。ここでは、差分適用時間Ｔ２≦τ＝τ₀であるとする。このため、ＤＢサーバ１００は、ＤＢ１１０の更新制限を行わない。

（ＳＴ１１０）ＤＢサーバ１００ａは、２回目（ｎ＝２）の差分適用開始をＤＢサーバ１００に通知する（差分適用開始通知の送信）。ＤＢサーバ１００は、当該通知を受信する。ＤＢサーバ１００ａは、アーカイブログ記憶部２２０から差分アーカイブログ２２４を読み出して、ＤＢ１１０ａの復旧を行う。ＤＢサーバ１００は、当該復旧中にも更新要求を受け付ける。ＤＢサーバ１００は、更新に応じてオンラインログを生成する。また、ＤＢサーバ１００は、オンラインログに基づいて新たな差分アーカイブログ（図１２では不図示）を生成し、アーカイブログ記憶部２２０に格納する。ここで、２回目の差分適用時にＤＢ１１０に対して想定外に大量の更新が発生する。オンラインログに書き込まれるデータ量が増大し、新たに生成される差分アーカイブログのサイズも増大する。

（ＳＴ１１１）ＤＢサーバ１００ａは、２回目（ｎ＝２）の差分適用完了をＤＢサーバ１００に通知する（差分適用完了通知の送信）。ＤＢサーバ１００は、当該通知を受信する。

（ＳＴ１１２）ＤＢサーバ１００は、差分適用時間Ｔ３を予測する。差分適用時間Ｔ３は、ステップＳＴ１１０〜ＳＴ１１１の間に生成された新たな差分アーカイブログの適用に要する時間の予測値である。ここでは、２回目の差分適用時に、ＤＢ１１０に対して想定外の更新が発生したことで、差分適用時間Ｔ３が比較的長い時間となる。差分適用時間Ｔ３＞τ＝τ₀であるとする。この場合、ＤＢサーバ１００は、無更新確率テーブル１３２を参照して、無更新確率ｐ以上であり、かつ、Ｔ３≦τ＝τ’となる無更新確率を取り得る最小の優先度閾値を特定する（τ’が複数であれば最大のものを選択してτに代入する）。

（ＳＴ１１３）ＤＢサーバ１００は、ＤＢ１１０に対する更新制限を行う。例えば、ＡＰサーバ３００で実行される複数のアプリケーションのうちの一部から更新要求を受け付けたとしても、当該更新要求に応じた更新を行わないようにする。前述のように、ＤＢサーバ１００は、制限対象とするアプリケーションの組合せを、優先度閾値に基づいてＡＰ区分単位に特定できる。

（ＳＴ１１４）ＤＢサーバ１００ａは、３回目（ｎ＝３）の差分適用開始をＤＢサーバ１００に通知する（差分適用開始通知の送信）。ＤＢサーバ１００は、当該通知を受信する。ＤＢサーバ１００ａは、アーカイブログ記憶部２２０からステップＳＴ１１０〜ＳＴ１１１の間に生成された新たな差分アーカイブログを読み出して、ＤＢサーバ１００ａの復旧を行う。ＤＢサーバ１００は、当該復旧中にも更新要求を受け付けるが、一部のアプリケーションによる更新を制限する。

（ＳＴ１１５）ＤＢサーバ１００ａは、３回目（ｎ＝３）の差分適用完了をＤＢサーバ１００に通知する（差分適用完了通知の送信）。ＤＢサーバ１００は、当該通知を受信する。以降、ＤＢサーバ１００は、ステップＳＴ１１２と同様に、次の差分アーカイブログの差分適用時間Ｔｎを予測し、Ｔｎとτとの大小の比較結果に応じて、ＤＢ１１０の更新を制限するＡＰ区分の範囲を拡大する（優先度閾値を大きくする）。

（ＳＴ１１６）ＤＢサーバ１００ａは、ｎ回目の差分適用を完了した後、アーカイブログ記憶部２２０に新たな差分アーカイブログが生成されていないことを確認する。ＤＢサーバ１００ａは、リカバリ完了をＤＢサーバ１００に通知する（リカバリ完了通知の送信）。ＤＢサーバ１００は、当該通知を受信する。ＤＢサーバ１００は、ＤＢ１１０に対する更新制限を解除する。

（ＳＴ１１７）ＤＢサーバ１００は、ログシップ機能によるＤＢサーバ１００ａとのオンラインログの同期を再開する。
図１６は、差分適用の所要時間の例を示す図である。図１６（Ａ）は、ＤＢ１１０の更新制限を行う場合の差分適用の所要時間を例示している。図１６（Ｂ）は、その比較として、ＤＢ１１０の更新制限を行わない場合の差分適用の所要時間を例示している。

図１６（Ａ）では、横軸を時間として、（Ａ１）通常時（差分適用中に想定外のＤＢ更新が発生しない場合）と、（Ａ２）想定外のＤＢ更新発生時（図１５で例示した場合）とにおける、差分適用の所要時間を示している。

図１６（Ａ１）では、差分適用の回数が増えるにつれて、差分適用の所要時間は徐々に小さくなり、やがて新たな差分アーカイブログが生成される前に、差分適用が完了し、所定の時間でリカバリが完了する。

図１６（Ａ２）では、２回目の差分適用時にＤＢ１１０に対して想定外の更新が発生した場合を例示している。３回目の差分適用時にＤＢ１１０に対する更新を制限する。すると、３回目の差分適用に比較的長時間を要しても、３回目の差分適用中に生成される差分アーカイブログのサイズが過大となるのを抑制できる。その結果、４回目の差分適用を無更新期待時間τ以内に終えることができる。このように、無更新確率ｐによって求まる無更新期待時間内に各差分適用が完了するように、ＤＢ１１０の更新を制限する。そうすれば、差分アーカイブの適用をおおよそ完了希望時間Ｎ以内に完了させることができる。

図１６（Ｂ）では、横軸を時間として、（Ｂ１）通常時（差分適用中に想定外のＤＢ更新が発生しない場合）と、（Ｂ２）想定外のＤＢ更新発生時とにおける、差分適用の所要時間を示している。

図１６（Ｂ１）の場合は、図１６（Ａ１）と同様である。すなわち、差分適用の回数が増えるにつれて、差分適用の所要時間は徐々に小さくなり、やがて新たな差分アーカイブログが生成される前に、差分適用が完了し、所定の時間でリカバリが完了する。

図１６（Ｂ２）の場合は、２回目の差分適用時に正系のＤＢに対して想定外の更新が発生した場合を例示している。図１６（Ｂ２）では、３回目の差分適用時に正系のＤＢに対する更新を制限しない点が図１６（Ａ２）と異なる。３回目の差分適用に比較的長時間を要するため、３回目の差分適用中における正系のＤＢの更新数も増大し、差分アーカイブログに記録される更新の内容も過大となる。すると、４回目の差分適用も比較的長時間を要することになり、４回目の差分適用中における正系のＤＢの更新も増大し、差分アーカイブログに記録される更新の内容も過大となる。

図１６（Ｂ２）において、この状況が継続すると、差分適用が延々と完了しないことになり、リカバリが完了するまでに完了希望時間Ｎよりも長い時間がかかる可能性が高まる。その間、情報処理システムは、正系のＤＢ単独での運用となり、長時間この状態が続くほど、耐障害性に対する影響は深刻になる。これに対し、副系のＤＢも迅速にリカバリ完了させて、冗長化運用を再開することが望ましい。

そこで、ＤＢサーバ１００は、差分アーカイブログ２２４の適用に比較的時間がかかると予測される場合に、差分アーカイブログ２２４の適用中のＤＢ１１０の少なくとも一部に対する更新を制限する。すると、新たな差分アーカイブログに記録される更新の量を低減でき、全ての更新を記録する場合よりも、新たな差分アーカイブログの適用に要する時間を低減できる。よって、新たな差分アーカイブログの適用中に記録される更新の量も低減できることになり、これを繰り返すことで、リカバリの長期化を抑制できる。

また、差分アーカイブログを用いた復旧は、おおよそ完了希望時間Ｎ以内に完了されることが期待され、差分アーカイブログを用いた復旧が完了するおおよその時間を予測可能となる。

また、ＤＢサーバ１００ａがリカバリを行っている間は、ＤＢサーバ１００を用いた運用を停止して、ＤＢ１１０の更新を行わないことも考えられる。しかし、この場合、ユーザの業務も行えないことになり、利便性が悪い。第２の実施の形態の情報処理システムによれば、業務を継続しながら、リカバリを行えるので、ＤＢ１１０の更新を完全に停止するよりも、利便性が向上する。すなわち、利便性の向上と、リカバリの長期化抑制とをバランス良く両立できる。

なお、第２の実施の形態では、データ群の一例として、ＤＢ１１０，１１０ａを例示して説明したが、更新の履歴を用いてデータの更新を行うものであれば、ＤＢ１１０，１１０ａ以外のデータ群に第２の実施の形態の処理を適用し得る。

また、前述のように、第１の実施の形態の情報処理は、演算部１ａにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体（例えば、光ディスク１３、メモリ装置１４およびメモリカード１６など）に記録できる。

例えば、プログラムを記録した記録媒体を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。

１，２，３ 情報処理装置
１ａ，２ａ 演算部
４，５，６ 記憶装置
４ａ，５ａ データ群
６ａ 第１の履歴情報
６ｂ 第２の履歴情報
６ｃ 第３の履歴情報

Claims (8)

1. コンピュータに、
   第１の記憶装置に格納された第１のデータ群に対する第１の更新の履歴を示す第１の履歴情報を用いて第２の記憶装置に格納された第２のデータ群を復旧する第１の復旧処理が行われている間に前記第１のデータ群に対する第２の更新の要求を受け付けると、前記第２の更新の履歴を示す第２の履歴情報を生成し、
   前記第２の履歴情報の情報量に基づき、前記第２の履歴情報を用いて前記第２のデータ群を復旧する第２の復旧処理が完了するまでの時間を予測し、
   予測された時間を用いた所定の判定処理の結果に基づいて前記第２の復旧処理が行われている間の前記第１のデータ群に対する第３の更新の少なくとも一部を制限する、
   処理を実行させるプログラム。
2. 前記所定の判定処理では、前記予測された時間と閾値との比較を行う、請求項１記載のプログラム。
3. 前記制限では、前記予測された時間が前記閾値よりも大きい場合に、前記予測された時間に基づいて、前記第１のデータ群の更新の要求を行う複数のソフトウェアの中から、更新の制限対象とするソフトウェアを選択する、請求項２記載のプログラム。
4. 前記選択では、前記複数のソフトウェアそれぞれが属する区分に応じた優先度を示す情報を参照して、前記予測された時間以上の時間経過に対して前記第１のデータ群へのアクセス要求の第１の数と前記アクセス要求のうちの更新要求の第２の数との差の前記第１の数に対する第１の割合が所定割合以上となるように、優先度の低い方から、更新の制限対象とするソフトウェアを区分単位に選択する、請求項３記載のプログラム。
5. 前記選択では、複数の履歴情報を用いた前記第２のデータ群の復旧にかけられる時間のユーザによる入力を許容し、入力された時間に基づいて前記所定割合を算出する、請求項４記載のプログラム。
   
6. 前記選択を行う前に、時間経過に応じて受け付けた前記第１のデータ群に対する前記第１の数および前記第２の数を前記区分ごとに計測し、計測結果により、時間経過に対する前記第１の割合を、前記区分の組に対して算出し、
   前記選択では、前記予測された時間以上の時間経過に対して前記第１の割合が前記所定割合以上となる前記区分の組を特定する、請求項４または５記載のプログラム。
7. 第１の記憶装置に格納された第１のデータ群に対する第１の更新の履歴を示す第１の履歴情報を用いて第２の記憶装置に格納された第２のデータ群を復旧する第１の復旧処理が行われている間に前記第１のデータ群に対する第２の更新の要求を受け付けると、前記第２の更新の履歴を示す第２の履歴情報を生成し、前記第２の履歴情報の情報量に基づき、前記第２の履歴情報を用いて前記第２のデータ群を復旧する第２の復旧処理が完了するまでの時間を予測し、予測された時間を用いた所定の判定処理の結果に基づいて前記第２の復旧処理が行われている間の前記第１のデータ群に対する第３の更新の少なくとも一部を制限する情報処理装置、
   を有する情報処理システム。
8. 情報処理装置が、
   第１の記憶装置に格納された第１のデータ群に対する第１の更新の履歴を示す第１の履歴情報を用いて第２の記憶装置に格納された第２のデータ群を復旧する第１の復旧処理が行われている間に前記第１のデータ群に対する第２の更新の要求を受け付けると、前記第２の更新の履歴を示す第２の履歴情報を生成し、
   前記第２の履歴情報の情報量に基づき、前記第２の履歴情報を用いて前記第２のデータ群を復旧する第２の復旧処理が完了するまでの時間を予測し、
   予測された時間を用いた所定の判定処理の結果に基づいて前記第２の復旧処理が行われている間の前記第１のデータ群に対する第３の更新の少なくとも一部を制限する、
   データ更新制御方法。

Images