(57)【要約】【課題】欠損なしのデータベースの回復とサイトのオンライン性能を維持しながらも、平常時の運用管理コストを低減する。【解決手段】ＤＢ１０７を格納する主ストレージ１０３と、ＤＢを提供する主ＤＢＭＳ１０１を実行する主計算機１００とから第１の系を構成し、前記第２の系は、主ストレージ１０３からＤＢ１０７の更新差分を示すログのコピーを受け付けるとともに、副ＤＢ１１７を格納する副ストレージ１１３と、主ストレージ１０３からコピーしたログに基づいて副ＤＢ１１７を回復するサブセット５００と、を含み、第１の系に障害が生じた場合には、第１の系から第２の系への切り替えを行うとともに、第２の系に第２のＤＢＭＳ１１１が稼動する第２の計算機１１０を加えてから、サブセット５００で回復または回復中の副ＤＢ１１７を第２の計算機１１０へ引き継ぐ。【選択図】図１
2006004147.tif 000002
【特許請求の範囲】
【請求項１】
第１の系と第２の系とを遠隔地に配置してバックアップを行うディザスタリカバリシステムであって、
前記第１の系は、コピー機能を有するとともに第１のデータベースを格納する第１のストレージと、
前記第１のデータベースを提供する第１のＤＢＭＳを実行する第１の計算機とを含み、
前記第２の系は、前記第１のストレージから前記第１のデータベースに関する情報のコピーを受け付けるとともに、第２のデータベースを格納する第２のストレージと、
前記第１のストレージからコピーした前記情報に基づいて前記第２のデータベースを回復するデータベース回復部と、を含み、
前記第１の系に障害が生じた場合には、前記第１の系から第２の系への切り替えを行うとともに、前記第２の系に第２のＤＢＭＳが稼動する第２の計算機を加え、前記第２の系において前記データベース回復部から第２の計算機へ前記第２のデータベースを引き継ぐことを特徴とするディザスタリカバリシステム。
【請求項２】
前記第１のストレージは、第１のデータベースの更新差分を示すログをコピーし、
前記第２のストレージは、前記ログを受け付け、
前記データベース回復部は、前記第１のストレージからコピーした前記ログに基づいて前記第２のデータベースを回復することを特徴とする請求項１に記載のディザスタリカバリシステム。
【請求項３】
前記第２のストレージに接続された中間装置を備え、当該中間装置は、前記第２のＤＢＭＳの機能の一部を構成するログ適用機能を含む前記データベース回復部を備えることを特徴とする請求項３に記載のディザスタリカバリシステム。
【請求項４】
前記第２のストレージは、前記第２のＤＢＭＳの機能の一部を構成するログ適用機能含む前記データベース回復部を備えることを特徴とする請求項２に記載のディザスタリカバリシステム。
【請求項５】
前記データベース回復部は、前記第２の計算機または上位の計算機から引き継ぎの指令を受ける第１のＩ／Ｆと、
前記第２のデータベースの回復状況を前記第２の計算機または上位の計算機へ通知する第２のＩ／Ｆと、
前記指令に基づいて、第２のデータベースの回復処理を前記第２の計算機へ引き継ぐ第３のＩ／Ｆと、
を含むことを特徴とする請求項３または請求項４に記載のディザスタリカバリシステム。
【請求項６】
前記データベース回復部は、前記引き継ぎの指令に基づいて、前記第２のデータベースの回復処理を途中で終了し、前記第２のＩ／Ｆが、第２データベースの回復状況を第２の計算機へ通知するとともに、第３のＩ／Ｆは、回復途中の第２のデータベースを第２の計算機へ引き継ぐことを特徴とする請求項５に記載のディザスタリカバリシステム。
【請求項７】
前記データベース回復部は、前記引き継ぎの指令に基づいて、第２のデータベースの回復処理を完了した後に、前記第２のＩ／Ｆが、第２の計算機へ回復処理の完了を通知するとともに、第３のＩ／Ｆは、回復が完了した第２のデータベースを第２の計算機へ引き継ぐことを特徴とする請求項５に記載のディザスタリカバリシステム。
【請求項８】
前記第２の計算機は、第２のＤＢＭＳを稼動させ、
前記データベース回復部は、回復途中の第２のデータベースについて疑似的なチェックポイント情報を生成する疑似チェックポイント生成部を有し、
前記第２のＤＢＭＳは、前記疑似的なチェックポイント情報に基づいて、回復途中の第２のデータベースの回復処理を再開することを特徴とする請求項６に記載のディザスタリカバリシステム。
【請求項９】
前記疑似チェックポイント生成部は、前記第１のＤＢＭＳが生成するチェックポイント情報とは独立して、前記データベース回復部からの引き継ぎ時点で最後に適用したログに関する情報を疑似的なチェックポイント情報として記録することを特徴とする請求項８に記載のディザスタリカバリシステム。
【請求項１０】
前記疑似チェックポイント生成部は、ログ適用による第２のデータベースの回復の過程で、トランザクションの実行状況を管理するトランザクション管理部を備え、
前記データベース回復部から引き継いだ回復途中の第２のデータベースのうち、未決着のトランザクションの中で最も古いトランザクションの開始時点のログ情報を疑似的なチェックポイント情報として記録することを特徴とする請求項８に記載のディザスタリカバリシステム。
【請求項１１】
前記データベース回復部は、ログ適用による第２のデータベースの回復の過程で、トランザクションの実行状況と、前記トランザクションが使用するリソースを管理するトランザクションリソース管理部を備え、
前記第１のＩ／Ｆは引き継ぎの指令を受けた時点のトランザクションの実行状況とリソースの使用状況を出力し、
前記第２の計算機は、第２のＤＢＭＳを稼動させ、
当該第２のＤＢＭＳは、前記データベース回復部が出力したトランザクションの実行状況とリソースの使用状況から第２のデータベースの回復状況を再構築した後に、第２のデータベースの回復処理を再開することを特徴とする請求項６に記載のディザスタリカバリシステム。
【請求項１２】
前記第２の計算機は、第２のＤＢＭＳを稼動させ、
当該第２のＤＢＭＳは、前記データベース回復部から引き継いだ回復完了後の第２のデータベースに基づいてサービスの再開を行うことを特徴とする請求項７に記載のディザスタリカバリシステム。
【請求項１３】
前記データベース回復部は、ログ適用による第２のデータベースの回復の過程で、前記ログをバッファリングし、当該バッファリングされたログに対してトランザクションの決着状況を解析するトランザクション解析部を備え、
前記解析結果が決着したトランザクションについてのみ回復処理を実行した状態で、前記第２のＤＢＭＳへ引き継ぐことを特徴とする請求項１２に記載のディザスタリカバリシステム。
【請求項１４】
前記データベース回復部は、前記第１のＩ／Ｆが引き継ぎの指令を受けると、ログの終端まで読み込んで前記第２のデータベースの回復を行った後、未決着のトランザクションに関してログを巻き戻して第２のデータベースの回復を完了させるログ巻き戻し部を有することを特徴とする請求項１２に記載のディザスタリカバリシステム。
【請求項１５】
前記第１の系と第２の系は、前記第１のストレージと第２のストレージとを接続するストレージ間ネットワークと、前記第１の計算機とデータベース回復部または第２の計算機とを接続するサーバ間ネットワークと、を介して接続されたことを特徴とする請求項１に記載のディザスタリカバリシステム。
【請求項１６】
第２のデータベースを格納する第２のストレージを備えて、ネットワークを介して接続された第１のストレージよりコピーされた第１のデータベースのログに基づいて前記第２のデータベースを回復し、第２のデータベースを提供する第２のＤＢＭＳへ処理を引き継ぐプログラムであって、
前記第２のＤＢＭＳまたは上位のサーバから、前記第１のデータベースを提供する第１のＤＢＭＳから前記第２のＤＢＭＳへの切り替え指令を受ける手順と、
前記切り替え指令を受けたときには、トランザクションの整合性を確保して前記第２のデータベースを回復する手順と、
前記回復した第２のデータベースを利用可能な状態で前記第２のＤＢＭＳへ引き継ぐ手順と、
をコンピュータに機能させることを特徴とするプログラム。
【請求項１７】
第２のデータベースを格納する第２のストレージを備えて、ネットワークを介して接続された第１のストレージよりコピーされた第１のデータベースのログに基づいて前記第２のデータベースを回復し、第２のデータベースを提供する第２のＤＢＭＳへ処理を引き継ぐプログラムであって、
前記第２のＤＢＭＳまたは上位のサーバから、前記第１のデータベースを提供する第１のＤＢＭＳから前記第２のＤＢＭＳへの切り替え指令または停止指令を受ける手順と、
前記指令を受けたときには、前記第２のデータベースの回復を中止する手順と、
前記第２のデータベースの回復状況を前記第２のＤＢＭＳへ通知する手順と、
前記第２のＤＢＭＳで第２のデータベースの回復処理を継続可能な状態として前記第２のＤＢＭＳへ処理を引き継ぐ手順と、
をコンピュータに機能させることを特徴とするプログラム。
【請求項１８】
前記第２のＤＢＭＳへ処理を引き継ぐ手順は、最後に適用したログに関連する情報を疑似チェックポイント情報として生成し、当該疑似チェックポイントを前記第２のＤＢＭＳへ引き継ぐことを特徴とする請求項１７に記載のプログラム。
【請求項１９】
第２のデータベースを格納する第２のストレージを備えて、ネットワークを介して接続された第１のストレージよりコピーされた第１のデータベースのログに基づいて前記第２のデータベースを回復するプログラムであって、
前記第２のＤＢＭＳまたは上位のサーバから、前記第２のデータベースの回復処理の中断指令または復帰指令を受ける手順と、
前記中断指令を受けたときには、当該指令を受けた時点で前記第２のデータベースの回復を中止して待機状態へ移行する手順と、
前記待機状態で復帰指令を受けたときには、前記中断した時点から前記第２のデータベースの回復を再開する手順と、
をコンピュータに機能させることを特徴とするプログラム。
【請求項２０】
前記第１のデータベースのログに基づいて前記第２のデータベースを回復する際に、ログの処理量または経過時間が所定の条件となったときに、最後に適用したログに関連する情報を疑似チェックポイント情報として生成する手順を含むことを特徴とする請求項１６、請求項１７乃至請求項１９のいずれかひとつに記載のプログラム。
【請求項２１】
第１のデータベースを提供する第１のＤＢＭＳと、前記第１のデータベースを格納する第１のストレージを含む第１の系から前記第１のデータベースの更新差分を示すログのコピーを受け付けるとともに、第２のデータベースを格納する第２のストレージと、前記第１のストレージからコピーした前記ログに基づいて前記第２のデータベースを第２の系で回復するデータベースのリカバリ方法であって、
前記ログに基づいて前記第２のデータベースを回復する処理と、
前記第１の系に障害が生じた場合には、前記第２のデータベースを提供する第２のＤＢＭＳを稼動させる処理と、
前記第２のＤＢＭＳへ回復中または回復後の前記第２のデータベースを引き継ぐ処理と、を含むことを特徴とするデータベースのリカバリ方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ディザスタリカバリシステムの改良に関し、特に、データベースに適したディザスタリカバリシステムに関する。
【背景技術】
【０００２】
近年、ＩＴシステム（Information Technology）システムはビジネスにとって欠かせなくなっており、障害や災害であってもビジネスを継続することはますます重要になっている。ＩＴシステム停止に伴う機会損失は莫大なものになり、例えば、金融業や大企業では数百万ドルにもなるといわれている。このような背景から、主／副の２つのサイトを用意し、平常時から副サイトへ業務データをバックアップし、災害時には副サイトで業務を継続するディザスタリカバリ（以下、ＤＲ）技術が注目を集めている。
【０００３】
企業のデータは通常は、データベース（以下、ＤＢ）に格納されているため、ＤＲにおいては、災害時にも欠損なくＤＢを回復することが最も重要な要件となる。また、平常時から継続してバックアップを行うため、主サイトのオンライン業務への影響を最小減にすることも必要である。さらに、近年では、地震など広域災害に対応すること、すなわち、副サイトを数百〜数千km離れた遠隔地に配置するＤＲが求められるようになっている。
【０００４】
このＤＲシステムでは、災害時には副サイトでＤＢを回復し、副サイトのＤＢＭＳ（DataBase Management System）で業務を再開する。ここで、従来のＤＢＭＳのＤＢ更新方法、及び、障害/災害時のＤＢ回復方法について説明する。
【０００５】
最初に平常時のＤＢの更新方法について説明する。ＤＢＭＳは、データが格納されるＤＢに加え、データの差分を記録するログも管理する。ＤＢＭＳへデータ変更が指示されると、ストレージ上の(ログが記録される)ログファイルに変更の差分を記録する。しかし、ＤＢに関しては、性能向上のため、すぐには変更を反映させず、あるタイミングで変更部分をストレージに吐き出すといった処理を行う。このタイミングとしてはチェックポイント（以下、ＣＰ）と呼ばれる処理が知られている。ＣＰは、一般的に、一定時間を経過した場合、あるいは、一定数のトランザクションを処理した場合などを契機に発行される。ここで、更新差分を表すログは更新がある度に追記されていくため、通番(ＬＳＮ, Log Sequence Number)がつけられており、ＣＰ時には、どのログまでがＤＢに適用されたかをあらわすために適用したログのＬＳＮ、及び、ＣＰ取得時刻といったＣＰ情報が記録される。ＣＰ情報の保存先としては、ログファイルのヘッダ、あるいは、専用ファイルなどが考えられる。以下では、専用ファイルがある場合で説明する。
【０００６】
障害がおこった場合のＤＢ回復処理は、このＣＰを起点に行われる。手順を図１６に示す。最初にステップ２０１において、ＣＰ情報を読み込み、続いてステップ２０２においてログの読込み位置を決める。すなわち、ＣＰ情報に記録されるＬＳＮ(ＣＰ時にＤＢに反映されていることが保証されるログ)以降のログから読み始めればよい。次に、ステップ２０３では、ログファイルを終端まで読み込み、読んだ順序でログをＤＢに適用する。ログには、更新によって変更された後のイメージが変更を行うべき場所と共に書かれており(イメージではなく操作の場合もある)、該当する場所に対してそのイメージを適用することにより、加えられた更新を再現することが可能となる。このログ適用処理はredo処理、あるいはロールフォワード処理と呼ばれる。
【０００７】
ここで、redo処理は、トランザクション（以下、Ｔｒ）の決着/未決着(コミットの投入有無)を管理しながら行われる。Tr管理は、例えば、図１７のような管理テーブルを用いて行うことができる。例えば、トランザクションテーブル３００は、Ｔｒ毎に一意に割り当てられるＴｒ−ｉｄ（トランザクションＩＤ）３０１、及び、そのＴｒの開始ログのＬＳＮ３０２を項目として持てばよい。新たなＴｒに属する開始ログが読み込まれると、そのＴｒ−ｉｄとＬＳＮをトランザクション管理テーブルに登録する。あるいは、図７に示すトランザクション管理テーブル３１０のように、Ｔｒ（Ｔｒ−ｉｄ３１１）毎に、そのＴｒを構成するログの情報３１３（ＬＳＮ３２０、ログの種類３２１、使用リソース３２３）のチェインを管理してもよい。そのＴｒが決着した場合には、該当するＴｒをテーブルから削除する。この操作により、全てのログを適用した段階で、未決着なＴｒの一覧が得られる。
【０００８】
終端までログを読み込み未適用ログがなくなった場合は、このＴｒ管理テーブルを用いて、未決着な処理を取り消す。すなわち、関連するＴｒのログを逆読みし、処理を取り消していく。この取り消し処理は、undo処理、あるいは、rollback処理と呼ばれる。undo処理が終了した段階で、ＤＢは決着したＴｒに含まれる更新のみが反映された整合性のとれた状態となり、業務を再開し新たな更新を加えることが可能となる。
【０００９】
ここで、業務再開は、undo処理と並行して行うことにより、再開までの時間を短縮することも可能となる。すなわち、redo処理が完了した時点で、未決着Trが使用するリソースを割り出し、そのリソースに対してロックを取った状態で業務を再開する。
【００１０】
近年、ストレージの高機能化が進んでおり、サイト間の転送をサーバレスで行うリモートコピーを有するストレージが開発されている。このリモートコピーを用いたＤＲシステムを図１５に示す。正サイト１と副サイト９にはそれぞれ正副のサーバ１００及び１１０とストレージ１０３及び１１３より構成され、サーバとストレージはそれぞれ、サーバ間ネットワーク１５０とストレージ間ネットワーク１２０で接続されているとする。また、それぞれの正副サーバ１００、１１０には正副ＤＢＭＳ１０１、１１１がインストールされているとする。
【００１１】
平常時は、正サイトのＤＢＭＳ１０１（以下、正ＤＢＭＳ）で業務を行う。ストレージ１０３、１１３には、正ＤＢ１０７及び副１１７と正副のログ１０６、１１６を格納するボリュームが含まれ、正副ログ１０６、１１６、正副ＤＢ１０７、１１７はそれぞれリモートコピー１４０によりコピーされる。
【００１２】
この構成では、平常時のバックアップは、ストレージのみで実現可能なため、平常時は副サーバ１１０は不要となる。災害時などで副サイト９に業務を切り替える時のみ副サーバ１１０が必要となる。その場合は、副サイト９でＤＢＭＳ１１１を立ち上げ、図１６で説明したような回復処理（ｒｅｄｏ／ｕｎｄｏ）を行った後、業務受付を再開する。ログ１０６、１１６、ＤＢ１０７、１１７のコピー方法としては、ログ、ＤＢとも同期リモートコピーで転送する方法が知られている。同期コピーでは、副サイト９へのコピーが完了して初めて正サイト１への書き込みが完了するため、正サイト１の更新が副サイト９に伝わっていることが保証され、災害時にも欠損なくＤＢを回復することが可能となる。しかし、書き込みの度に、遅延が加わるので、広域災害を考慮して、副サイトが数百ｋｍ離れている場合には、正サイト１のオンライン性能が劣化するという問題点がある。
【００１３】
そこで、欠損なしの回復とオンライン性能維持を同時に実現するために、更新差分が含まれるログは同期で転送し、ログからの回復が可能なＤＢは転送不要とする方法が知られている。すなわち、副サイトでのＤＢ回復は、正サイトからコピーされるログをｒｅｄｏすることにより実現するものが知られている（例えば、特許文献１）。
【００１４】
また、ログの転送機能をＤＢＭＳに組み込んだものも知られている（非特許文献１）。      
【００１５】
この場合のシステム構成を図１８に示す。正／副サイトがサーバ１００、１１０とストレージ１０３、１１３から構成され、サーバ１００、１１０にはＤＢＭＳ１０１、１１０がインストールされている点は同一である。ただし、ストレージ１０３、１１３は、リモートコピー機能を有する必要はなく、サイト間はサーバ間ネットワーク１１０のみで接続される。ログ１０６のコピーはＤＢＭＳ１００、１１０によって行われる。すなわち、正ＤＢＭＳ１０１は、正ストレージ１０３に書き込むのと同時に、副ＤＢＭＳ１１１にログを転送する。副ＤＢＭＳ１１１は、受信したログを副ストレージ１１３に書き出すと共に、読み込んだログをＤＢ１１７に適用し、ＤＢを更新する。
【特許文献１】米国特許第５６４０５６１号明細書
【非特許文献１】「Oracle Data Guard」、「Overview of Oracle Data Guard Functional Components」、[online]、「平成１６年４月２７日検索」、インターネット＜http://otn.oracle.com/deploy/availability/htdocs/DataGuardOverview.html＞
【発明の開示】
【発明が解決しようとする課題】
【００１６】
しかしながら、上記図１８（非特許文献１）に示した従来例では、平常時からＤＢＭＳが稼動する必要があり、また、転送をサーバ間で行うために、転送負荷により正サイトで行う業務処理が圧迫される、という問題が生じ、さらに、災害時に業務を継続するためには、正サイトと同等の計算機を副サイトで稼動しておく必要があるが、実際に、広域災害が生じる可能性は、全体の停止理由の数％にすぎないため、平常時から副サーバを稼動させておくことは運用構築コストが大きくなるという問題がある。
【００１７】
そこで本発明は、上記問題点に鑑みてなされたもので、欠損なしのデータベースの回復とサイトのオンライン性能を維持しながらも、平常時の運用管理コストを低減可能とすること。
【課題を解決するための手段】
【００１８】
本発明は、第１のデータベースを格納する第１のストレージと、第１のデータベースを提供する第１のＤＢＭＳを実行する第１の計算機と、から第１の系を構成し、前記第２の系は、前記第１のストレージから前記第１のデータベースに関する情報（例えば、更新差分を示すログ）のコピーを受け付けるとともに、第２のデータベースを格納する第２のストレージと、前記第１のストレージからコピーした前記情報に基づいて前記第２のデータベースを回復するデータベース回復部と、を含み、前記第１の系に障害が生じた場合には、前記第１の系から第２の系への切り替えを行うとともに、前記第２の系に第２のＤＢＭＳが稼動する第２の計算機を加えてから、データベース回復部で回復または回復中の第２のデータベースを第２の計算機（第２のＤＢＭＳ）へ引き継ぐ。
【発明の効果】
【００１９】
したがって、本発明は、第１のデータベースに関する情報による第２のデータベースの回復（例えば、ログ適用）で欠損なしでデータベースの回復を実現しながら、第１の系と第２の系はストレージ間で情報のコピーのみを行えばよいので第１の系（サイト）のオンライン性能を確保できる。そして、平常時にはデータベース回復部のみが稼動していればよいので、第２のＤＢＭＳを実行する第２の計算機を不要にして、通常時の運用管理コストを低減することができる。障害発生時には、第２の系に第２の計算機を加えて第２のＤＢＭＳを稼動させ、第２のデータベースをデータベース回復部から引き継ぐことで、第２のデータベースのサービスを開始することができる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【００２１】
図１は、本発明で用いられる典型的なシステム図を示し、２つのサイトでディザスタリカバリを行う一例を示す。
【００２２】
図１では、副サイト２の副ＤＢＭＳ（DataBase Management System）からオフロード（分割）されたＤＢＭＳ機能のサブセット５００が、副サーバ１１０と副ストレージ１１３の中間に配置された専用装置（中間装置）５０１で稼動する例を示している。
【００２３】
正サイト１は正サーバ１００と正ストレージ１０３から構成される。正サーバ１００には、正ＤＢＭＳ１０１がインストールされており、この正ＤＢＭＳ１０１が業務を受け付ける。正ＤＢＭＳ１０１は、正サーバ１００のメモリ上にあるＤＢバッファ１０２と正ストレージ１０３を用いてＤＢ（DataBase）１０７を管理する。ＤＢ１０７はストレージ１０３上に配置されるが、更新がある度に副ストレージ１１３にアクセスすると性能が劣化するため、通常はＤＢバッファ１０２上で更新処理を行う。トランザクション（以下、Ｔｒ）がコミットされた場合、あるいは、ＤＢバッファ１０２があふれた場合など、予め設定したタイミングで更新をストレージ１１３に反映する。
【００２４】
正ストレージ１０３は、キャッシュ１０５、ディスク制御プログラム１０４、制御装置、複数のボリュームより構成される。それぞれのボリュームには、データ本体が格納されるＤＢ１０７、データ（ＤＢ１０７）への更新差分が格納されるログ１０６、及び、ＣＰ（チェックポイント）情報ファイル等を格納した設定ファイル５０２が存在する。なお、ＣＰは前記従来例で述べたものと同様である。
【００２５】
ディスク制御プログラム１０４は、ストレージ間ネットワーク１２０を介して副サイト２の副ストレージ１１３との間でリモートコピーを制御する。ここでは、ログ１０６のみを同期リモートコピー、あるいは、非同期リモートコピーで転送する。
【００２６】
副サイト２は、副サーバ１１０、副ストレージ１１３、および、副ＤＢＭＳ１１１の一部分の機能（例えば、ログ適用機能）から構成されるサブセット５００を含む専用装置５０１と、フェイルオーバが発生したときのみ稼動する副サーバ１１０及びこの副サーバ１１０で稼動する副ＤＢＭＳ１１１から構成される。また、主サイト１と副サイト２のサーバ１１０、１１１はサーバ間ネットワーク１５０を介して接続され、このサーバ間ネットワーク１５０には、主サイト１の障害を検知する管理装置２００が接続される。
【００２７】
管理装置２００は、例えば、監視プログラム等が実行されるサーバなどの計算機で構成され、主サーバ１１０のハートビートの検出や、主ストレージ１０３の障害情報などから主サイト１の障害を検出し、障害検出時には副サイト２のサブセット５００や副サーバ１１０へフェイルオーバを指令する。
【００２８】
ここで、専用装置５０１は、サブセット５００を実行可能な処理能力を備えた計算機であればよく、副ＤＢＭＳ１１１を実行可能な処理能力を必要としない。
【００２９】
副サーバ１１０は、常時副サイト２として稼動している必要はなく、フェイルオーバ処理の開始時点で副サイト２として稼動し、ＤＢＭＳ１１１を起動すればよい。
【００３０】
副ストレージ１１３はリモートコピー機能を有するとする。副ストレージ１１３内では、主ＤＢＭＳ１０１が管理するログ１１６、ＤＢ１１７、ＣＰ情報ファイル等が含まれる設定ファイル５１２が別々のボリュームに配置される。そのうち、ログ１１６のみが、正ストレージ１０３から副ストレージ１１３へリモートコピー機能により転送される。上述したようにリモートコピーは、同期リモートコピーであっても、非同期リモートコピーであってもよい。同期リモートコピーの場合は、副ストレージ１１３への書き込みが完了して初めて正ストレージ１０３への書き込みが完了するために、災害や障害が生じても欠損なくデータがコピーされることが保証される。しかし、書き込みの度に回線遅延が付加されるため、正ＤＢＭＳ１０１で行う業務への影響が無視できない。一方、非同期リモートコピーを用いた場合は、副ストレージ１１３への転送が行われる前に正ストレージ１０３への書き込みが完了したとみなして処理を継続するため、正ＤＢＭＳ１０１への影響は最小減に抑えられる。ただし、副ストレージ１１３への書き込みが完了する前に災害が生じた場合には、欠損が生じてしまう。
【００３１】
正副ＤＢ１０７、１１７と正副ＣＰ情報を含む設定ファイル５０２、５１２に関しては、ディザスタリカバリ（以下、ＤＲ）システムの開始時にのみ、同期状態にする。この最初の同期化は、リモートコピーを用いてもよいし、正副ＤＭＢＳ１０１、１１１が転送機能を有する場合は、その転送機能を用い、あるいは、ｆｔｐ等のコピープログラムを用いてもよい。この時、正副ＤＢ１０７、１１７と正副ＣＰ情報を含む設定ファイル５０２、５１２の間には、整合性が保たれている必要がある。すなわち、正副設定ファイル５０２、５１２には、ログの通番（ＬＳＮ＝Log Sequence Number）が書かれているが、少なくともこのＬＳＮまでは、ＤＢ１０７、１１７に反映されている必要がある。
【００３２】
リカバリの開始時以降は、副ＤＢ１１７はリモートコピーではなく、ログ適用により回復される。このログ適用は、副ストレージ１１３と副サーバ１１０の間に配置される専用装置５０１により実行される。
【００３３】
この専用装置５０１には、副ＤＢＭＳ１１１の一機能であるログ回復機能がサブセット５００としてオフロードされている。専用装置５０１は、ログ適用だけを行えばよいため、処理能力が低く、安価な計算機で実現可能となる。従って、平常時は、この専用装置５０１のみあればよく、副サーバ１１０を設置する必要がないことから、より安価なコストでＤＲシステムを構築することが可能となる。
【００３４】
また、サブセット５００は、機能が限定されているため、フル機能を持つＤＢＭＳ１１１の場合に比べて複雑な管理を行う必要がなく、運用管理面でも低コスト化が可能となる。
【００３５】
また、上記図１では、副サイト２にのみ専用装置５０１があるが、正サイト１にも専用装置を配置してもよい。例えば、系切り替え処理は、災害時だけでなく、計画的に行う場合もある。その場合は、正サイト１と副サイト２の役割を入れ替え、副サイトで業務を行うとともに、正サイトで回復処理を行う必要がある。その場合は、ログ１０６、１０７のリモートコピーのコピー元とコピー先を入れ替えると共に、正サイトの専用装置でＤＢ１０７を回復する必要がある。
【００３６】
なお、上記実施形態において専用装置５０１の処理能力が十分高い場合には、このサブセット５００を副ＤＢＭＳ１１１そのものとしても良い。
【００３７】
＜サブセットから副サーバへの切り替え−１＞
副サイト２内の切り替え手順としては、サブセット５００での回復（サイト内フェイルオーバ）の中途で上位サーバ（副サーバ１１０）へ引き継ぐ場合と、サブセット５００内で全ての回復を完了させてから上位サーバへ引き継ぐ場合がある。
【００３８】
まず、最初に、サブセット５００での回復の中途で上位サーバへ処理を引き継ぐ手順について説明する。
【００３９】
この処理では、サブセット５００から処理を引き継いだ上位サーバ（副サーバ１１０）は、回復処理を継続し、全ての回復処理を完了させた後で業務を再開することとなる。
【００４０】
図２にサブセット５００と上位サーバ（副サーバ１１０）のフローを示し、サブセットでの回復が中途な状態で、いち早く、副サーバへ引き継ぐ手順を説明する。
【００４１】
サブセット５００は、上述したように、平常時はログ適用を行っているが、割り込みなどの手段により上記管理装置２００などからＦ．Ｏ（Ｆａｉｌ  Ｏｖｅｒ）指示を受け取ることが可能であるとする。
【００４２】
まず、ステップ７００において、サブセット５００は、ユーザ（ＤＢ管理者または、ＤＢ１０１）、あるいは、監視ソフトウェア等からＦ．Ｏの指示を受信する。
【００４３】
Ｆ．Ｏ指示を受け、副ＤＢＭＳ１１１はステップ７１１において、事前に起動が行われていなければ起動処理を行い、ディスクアクセス手前で待機状態になる。災害時のＦ．Ｏの場合は、副ＤＢＭＳ１１１は起動されていないと考えられるが、計画Ｆ．Ｏの場合は、事前に起動されている場合も考えられる。
【００４４】
一方、サブセット５００では、Ｆ．Ｏ指示を受けると、ステップ７０２において、ログ適用を停止する。続いて、ステップ７０３において、ＤＢ回復処理の実行状況を出力する。この出力は、副ストレージ１１３上のファイルに行ってもよいし、あるいは、サブセット５００内のメモリ上に行ってもよい。
【００４５】
次に、ステップ７０５において、サブセット５００は、それまで取得していた副ストレージ１１３のディスク制御権を放棄し、ステップ７０６において副サーバ１１０にサブセット５００での回復処理を終了したことを通知する。
【００４６】
この通知は、直接、副ＤＢＭＳ１１１に送ってもよいし、ＤＢ管理者（ＤＢＡ）や管理装置２００へ送ってもよい。また、ステップ７０３でのＤＢ（副ＤＢ１１７）回復状況がサブセット５００のメモリに出力されている場合は、副ＤＢＭＳ１１１へ回復終了を通知すると同時にメモリ上のＤＢ回復状況を送信してもよい。
【００４７】
通知を受けたＤＢ管理者（ＤＢＡ）あるいは副ＤＢＭＳ１１１は、ステップ７１３においてディスク制御権を取得した後、ステップ７１４において各ファイルを読み込む。ここでは、例えばＣＰ情報を含む設定ファイル５１２を読み込むことにより、ログ読込みの開始位置を決定する。
【００４８】
ステップ７１５では、ファイル読込みやプロセス間通信によって得られた情報から、ＤＢ回復状況を再構築する。続いて、ステップ７１６において、再構築した回復状況から回復を再開すべき場所を特定し、ＤＢ回復処理（ログ適用）を再開する。ログ１１６を終端まで読み込み・適用したら、未決着なＴｒに関してｕｎｄｏ処理を行い、ＤＢ回復処理を完了させる。なお、ｕｎｄｏ処理は上記従来例と同様にして行われる。
【００４９】
ＤＢ回復処理の完了後、ステップ７１７において業務受付を再開する。なお、業務受付の再開は、ｕｎｄｏの開始と同時に制限付で行うことも可能である。
【００５０】
この手順では、サブセット５００の停止指示以降の回復処理は、よりリッチな計算機資源を持つ上位サーバ（副サーバ１１０のＤＢＭＳ１１１）で実行可能であること、制限つきの業務再開が可能なことから、回復時間の短縮を図ることが可能となる。
【００５１】
以上のように、サブセット５００での回復処理の中途で上位サーバに引き継ぐ方法では、副ＤＢＭＳ１１１は、サブセット５００で行ったＤＢ回復状況を引き継ぎ、ＤＢ回復処理を完了させる必要がある。
【００５２】
＜ＤＢ回復の引き継ぎ＞
サブセット５００と副サーバ１１０の間で、ＤＢ回復状況を引き継がせる手順としては、ファイルで引き継ぐ手順、あるいは、プロセス間通信で引き継ぐ手順が考えられる。以下では、ファイルで引き継ぐ手順について説明する。ファイルとしては、従来からＤＢＭＳで用いられるＣＰ情報ファイル（設定ファイル５１２）を利用する方法、及び、まったく新たなファイルを定義する方法がある。
【００５３】
最初に、ＣＰ（チェックポイント）情報ファイルを利用してＤＢ回復状況を引き継がせる手順を説明する。通常のＣＰ情報ファイルは、正サイト１において、一定時間が経過した場合や一定数のＴｒを処理した場合といったイベントを契機に更新される。この時、ＤＢバッファ１０２上でまだ（ストレージ１０３上の）ＤＢ１０７に未反映のデータをＤＢ１０７に反映させると共に、ＣＰ情報ファイル（設定ファイル５０２）には、ログ１０６のどの部分までがＤＢ１０７に反映されているかを表すＬＳＮやタイムスタンプ情報が記録される。このＣＰ処理により、ＣＰ情報ファイルとＤＢ１０７が整合性のとれた状態となる。
【００５４】
本発明では、副サイト２において、正サイト１で発行されるＣＰとは独立して、擬似的にＣＰを発生させ、ＣＰ情報ファイルを更新する。
【００５５】
すなわち、サブセット５００は、（正サイト１と独立して生成される擬似ＣＰ情報が含まれる）ＣＰ情報ファイルを用いて、サブセット５００のＤＢ回復状態を副ＤＢＭＳ１１１に通知する。擬似ＣＰを生成するタイミングとしては、ＤＢ管理者や副ＤＢＭＳ１１１からＦ．Ｏ指示または停止指示を受けた場合が考えられる。あるいは、一定時間を経過した場合や一定数のログを処理した場合に擬似ＣＰを生成してもよい。あるいは、正サイト１において発生されるＣＰがイベント情報としてログ１１６に書かれる場合には、サブセット５００においてそのイベントログを読み込んだ際に、擬似ＣＰを生成してもよい。
【００５６】
また、副サイト２のサブセット５００において、擬似ＣＰを生成させる手順としては、Ｔｒの実行状況を考慮しない場合と、考慮する場合が考えられる。
【００５７】
＜疑似チェックポイントの生成−１＞
最初に、Ｔｒの実行状況を考慮せずに擬似ＣＰを生成し、ＣＰ情報ファイルを更新する手順について説明する。
【００５８】
Ｔｒの実行状況を考慮しない場合は、Ｆ．Ｏ指示または停止指示を受けた時点、あるいは、ＣＰイベントログを読み込んだ時点で、サブセット５００で最後に適用したログ１１６のＬＳＮやタイムスタンプ情報をＣＰ情報ファイルに書き込めばよい（図３のステップ１００１）。副サーバ１１０の立ち上げ時には、このファイルを読むことにより、副サイト２のＤＢ１１７に対して、ログ１１６がどこまで適用されているかを知ることができる。そのため、ログ１１６を読み込んだ後は、上記ＬＳＮ以降のログを適用し、最終的にｕｎｄｏまで行えば、ＤＢ回復を完了することができる。ただし、この手順を用いた場合は、副ＤＢＭＳ１１１では制限つき業務再開を行うことはできない。
【００５９】
なぜなら、副ＤＢＭＳ１１１では、回復過程でリソース管理（あるＴｒが使用するリソースは、そのＴｒが決着するまでロックする）を行うが、副ＤＢＭＳ１１１での処理を再開する際に、このリソース情報を引き継がれていないために、ｒｅｄｏ完了時に完全なリソース情報を得ることが出来ないためである。その結果、引継ぎ時に未決着なＴｒが、副ＤＢＭＳ１１１のその後のｒｅｄｏの結果やはり未決着であった場合、そのＴｒがロックすべきリソースを完全に再現できない。さらに、そのＴｒをｕｎｄｏするためには、副ＤＢＭＳ１１１が読込みを開始した時点（ＣＰ情報ファイルにかかれたＬＳＮ）より以前のログまで読み戻る必要も生じる。
【００６０】
＜疑似チェックポイントの生成−２＞
次に、Ｔｒの実行状況を考慮して擬似ＣＰを生成し、ＣＰ情報ファイルを更新する手順について説明する。Ｔｒの実行状況を考慮したＣＰの概念図を図４に示す。図４は、サブセット５００でのログ適用状況を表す図であり、丸つきの線はトランザクションを、実線はコミットされたＴｒを表し、破線は災害が生じた時点８０２で、未決着である（コミットが投入されなかった）Ｔｒを表す。
【００６１】
ログ適用状況を副ＤＢＭＳ１１１に伝える方法としては、前述したように８０２時点で最後に適用したログのＬＳＮをＣＰ情報ファイル８０４に書き込む手法が考えられる。しかし、この手法を用いた場合、副ＤＢＭＳ１１１ではｕｎｄｏを行うために、８０２以前に読み戻らなければならない。また、８０２時点でサブセット５００でのログ適用状況を完全に再現できないため、ＤＢＭＳ１１１の制限つき再開ができないという問題がある。ここで、副ＤＢＭＳ１１１の立ち上げ時のログ読込み位置より前に読み戻ることを防止すること、及び、最終的に未決着なＴｒのリソース情報を副ＤＢＭＳ１１１で正しく生成させるためには、Ｆ．Ｏまたは停止指示を受けた時点で、最終的に未決着となる可能性のあるＴｒの開始ログを擬似ＣＰとすればよい。
【００６２】
すなわち、指示を受けた時点８０２で未決着なＴｒ（８０５，８０６，８０７）の内、最も早く開始されたＴｒ（８０７）の開始ログ（８０８）のＬＳＮを擬似ＣＰファイルに登録すればよい。その結果、副ＤＢＭＳ１１１には、最終的にｕｎｄｏされる可能性のあるＴｒの情報が読み込まれているため、開始地点より前に読み戻る必要はない。また、制限つき再開を行うことも可能となる。ただし、同一ログ１１６を複数回適用することを防ぐため、データページ等に適用したログＬＳＮを記録しておき、ログ適用を行うときには、適用しようとするログＬＳＮとデータページに書かれるＬＳＮと比較するといった処理が必要となる。
【００６３】
このような擬似ＣＰを実現するためには、サブセット５００でのログ適用の過程で未決着Ｔｒ情報を管理する必要がある。例えば、Ｔｒテーブル８０３を管理すればよい。このＴｒテーブル８０３により、Ｆ．Ｏまたは停止指示を受けた時点で、未決着なＴｒを知ることが出来る。
【００６４】
サブセット５００で行われ、Ｔｒを考慮する場合の擬似ＣＰ生成フローを図５に示す。Ｆ．Ｏまたは停止指示を受けると、ステップ１００４においてＴｒテーブル８０３をスキャンし、開始ログのＬＳＮをソートし、ステップ１００５においては未決着で最も古く始まったＴｒを見つけ、最後にステップ１００６において、検出した未決着ＴｒのＬＳＮをＣＰ情報ファイル８０４に登録する。このような擬似ＣＰ処理により、ＤＢ回復処理を引き継いだ副ＤＢＭＳ１１１では、最終的に未決着となる可能性のあるＴｒを、その開始ログから読むことが保証できる。その結果、ログ読込み位置から読み戻る必要もなく、また、未決着Ｔｒが使用するリソースを完全な形で管理できるため、ｒｅｄｏが完了した段階で制限つき業務再開を行うことが可能となる。
【００６５】
＜サブセットから副サーバへの切り替え−２＞
これまでに説明した擬似ＣＰを用いることにより、サブセット５００の回復処理の中途での引き継ぎを可能とするサブセットの処理フローを図６に示す。
【００６６】
最初にステップ９０１において、ＣＰ情報ファイルを読み込み、ステップ９０２において、ログ読込み位置を決定する。この時の、ＣＰ情報ファイルは正サイト１で生成したＣＰ情報ファイルであってもよいし、サブセット５００で生成した（擬似ＣＰを含む）ＣＰ情報ファイルであってもよい。
【００６７】
ここで、擬似ＣＰは、ＤＢ管理者や監視プログラムから指示があった場合だけでなく、一定期間を経過した場合、あるいは、一定量の処理を行った場合などのイベントを契機にして生成することが可能である。このように定期的に擬似ＣＰを発生しておくことにより、サブセット５００に障害が起こり、サブセット５００のリスタートが必要となった場合であっても、障害発生から近い時点よりログ適用を開始することができる。
【００６８】
ここでは、一定数のログを適用した場合に擬似ＣＰを行う例を示す。そのための変数をｂｌｋ＿ｎｕｍとし、その閾値をＰとする。このｂｌｋ＿ｎｕｍをステップ９０３において初期化する。また、ここでは後述するｉflagも初期化しておく。
【００６９】
サブセット５００は、中断指示、復帰指示、Ｆ．Ｏ指示、停止指示といった指令を管理装置２００などから受信するＩ／Ｆを持つものである。管理装置２００などからの中断指令は、ログ適用を中断し、待機状態になることを意味し、復帰指令は、待機状態から回復し、再びログ適用を再開することを意味する。図６では、中断／復帰はｉflagという変数で制御しており、ステップ９０５、９０７では、受けた指示に従い、制御変数であるｉflagを変更し（９０６、９０８）、Ｓ１へ復帰し、中断または復帰を行う。
【００７０】
ステップ９０９では、Ｆ．Ｏ指示の有無を判定し、Ｆ．Ｏ指示がある場合には、ステップ９１０において、上述のように擬似ＣＰを行いてＣＰ情報ファイルを生成し、ステップ９１１において処理を終了する。生成したＣＰ情報ファイルにより、副ＤＢＭＳ１１１はサブセットからＤＢ回復を引き継ぐことが可能となる。
【００７１】
Ｆ．Ｏ指示がない場合には、ステップ９１２において、ｉflagのチェックを行い、中断指示がされており、かつ、復帰指示がなされていない場合は、ステップ９１３においてループすることになる。
【００７２】
一方、中断指示がなされていない場合は、ステップ９１４において、適用すべきログ１１６が存在するかどうかをチェックする。未適用のログ１１６が存在しない場合は、ステップ９０４に戻りループを行う。未適用ログが存在する場合は、ステップ９１５においてログ１１６及びトランザクションテーブル３００（図１７参照）を読み込み、ステップ９１６においてそのログ１１６を適用する。この時、トランザクションテーブル３００を管理しながらログ適用を行う。
【００７３】
ステップ９１７では、停止指示の有無の判定を行う。メンテナンスなどにより停止指示がなされている場合には、ステップ９１８において擬似ＣＰ処理を行い、サブセット５００の処理を終了する。ここで、回復の中途で上位サーバに引き継ぎを行う場合には、サブセット５００でｕｎｄｏ処理を行わないため、Ｆ．Ｏ指示と停止指示で行うべき処理は同一となる。
【００７４】
停止指示がなかった場合は、ステップ９２０において、ｂｌｋ＿ｎｕｍをチェックする。ｂｌｋ＿ｎｕｍが予め定めた閾値Ｐ以上のログ１１６を処理していた場合には、ステップ９２１において擬似ＣＰ処理を行い、ステップ９２２においてｂｌｋ＿ｎｕｍを初期化し、ステップ９２３においてステップ９０４に戻りループする。なお、このときの擬似ＣＰを行う理由としては、サブセット自身に障害があり、リスタートする必要がある場合に対応することが考えられる。その場合、サブセット５００のリスタート時は、ステップ９０１において、正サイト１で生成されたＣＰ情報ファイルではなく、サブセット５００自身が障害発生前に生成したＣＰ情報ファイルが読み込まれることになる。
【００７５】
一方、Ｂｌｋ＿ｎｕｍが閾値Ｐを超えていなかった場合には、ステップ９２４においてｂｌｋ＿ｎｕｍをインクリメントし、ステップ９２５において、ステップ９０４（Ｓ１）まで戻る。
【００７６】
ここで擬似ＣＰ処理方法としては、図３、図５のどちらの手順を用いてもよい。ただし、Ｔｒを考慮しない手順（図３）を用いた場合は、副ＤＢＭＳ１１１において制限つき業務開始を行えないため、業務再開間での時間が遅くなる。一方、Ｔｒを考慮する場合（図５）は、制限つき業務開始が行えるため、いち早く業務を再開することが可能となる。
【００７７】
＜サブセットから副サーバへの切り替え−３＞
次に、サブセット５００での回復の中途で、副ＤＢＭＳへ処理を引き継ぐ手順としては、ＣＰ情報ファイルではなく、全く新たなＩ／Ｆを定義する手法がある。例えば、Ｆ．Ｏ／停止指示を受けた時点のサブセット５００の状態を上位サーバ（副サーバ１１０）に引き継げばよい。このときの状態には、未決着なＴｒとそのＴｒが使用するリソースの情報が含まれている必要がある。例えば、図７に示すようなＴｒ管理テーブル３１０で、未決着Ｔｒ情報を管理している場合は、このＴｒ管理テーブル３１０を引き継げばよい。引継ぎ方法としては、ファイルでもよいし、プロセス間通信を行ってもよい。このトランザクション管理テーブル３１０は、Ｔｒの識別子であるＴｒ−ｉｄ３１１毎に、そのＴｒを構成するログの情報３１３（ＬＳＮ３２０、ログの種類３２１、使用リソース３２３）のチェインを管理するもので、Ｔｒが決着した場合には、該当するＴｒをテーブルから削除する。この操作により、全てのログを適用した段階で、未決着なＴｒの一覧が得られる。
【００７８】
ファイルでサブセット５００の状態を引き継ぐ場合の、サブセット５００で行われる処理のフローチャートを図８に示す。基本的なフローは擬似ＣＰを用いた場合（上記図６）と同一となる。ただし、ステップ９０９においてＦ．Ｏ指示がなされていることが判断されたら、ステップ１５００においてＴｒ表の内容をファイルへ出力するとする。ここで、停止指示の場合は、上位サーバへの引継ぎはなく、サブセットのリスタートが主な目的であるため、擬似ＣＰを生成するとする。
【００７９】
新Ｉ／Ｆを定義した場合は、副ＤＢＭＳ１１１の起動フローを修正する必要がある。この起動フローを図９に示す。ステップ２０１、２０２で、副ストレージ１１３の設定ファイル５１２内のＣＰ情報ファイルからログ読込み位置を決定した後、ステップ２１０において、サブセット５００が出力したファイル（Ｔｒテーブルの情報が含まれる）があればそれを読み込む。続いて、ステップ２１１において、このファイルから未決着Ｔｒの情報を再構築する。すなわち、未決着Ｔｒが使用するリソースを明らかにし、そのリソースに関し、排他制御をかける。続いて、ステップ２０３以降で、ログ適用を開始する。このとき、Ｔｒテーブルの管理や未決着Ｔｒに関する排他情報の管理を行いながら、ログ適用する。ログ１１６の終端まで達した段階で、そのとき構築されている排他情報をもとに業務を制限付きで開始する。つまり、未決着Ｔｒへのアクセスを禁止して他のトランザクションを処理する。そして、ステップ２０５以降では、業務再開と並行してｕｎｄｏ処理を実施する。すべてのｕｎｄｏが終了した段階で、制限を解除して完全に業務を再開する。
【００８０】
＜サブセットから副サーバへの切り替え−４  完全回復後＞
次に、副サイト２内でサブセット５００から副サーバ１１０に切り替える手順としては、上述したサブセット５００における回復の中途で上位サーバ（副サーバ１１０）へ引き継ぐ手順の他に、サブセット５００内で全ての回復を完了させてから上位サーバ（副サーバ１１０）へ引き継ぐ方法がある。以下、サブセット５００内で全ての回復処理を回復させてから上位サーバへ引き継ぐ場合について説明する。
【００８１】
図１０に、サブセット５００と副サーバ１１０の間の引継ぎのフローを示す。
【００８２】
最初にステップ７００において、管理装置２００などでＦ．Ｏの指示を決定する。この決定は、ＤＢ管理者が行ってもよいし監視プログラムにより自動的に決定されてもよい。サブセット５００では、ステップ７０１においてＦ．Ｏの指示を受信する。この受信は、プロセス間通信、あるいは、ファイル経由で与えてもよい。
【００８３】
次に、ステップ１１００においてＤＢ１１７がＴｒ的に整合性の取れている状態になっており、すべての回復処理が完了していることを確認する。続いて、ステップ１１０１において、設定ファイル５１２内のＣＰ情報ファイルを初期化する。これは、全ての回復が完了しており、上位サーバは回復処理を継続する必要がないためである。
【００８４】
次に、ステップ７０５において、サブセット５００のディスク制御権を放棄し、ステップ７０６において回復が完了したことを上位サーバ（副サーバ１１０）へ通知する。
【００８５】
副サーバ１１０においては、Ｆ．Ｏが決定されると、ステップ７１１において、ＤＢＭＳ１１１が起動されていない場合は、ＤＢＭＳ１１１の起動から開始する。この起動では、ディスクアクセスの手前まで起動された状態となる。続いて、ステップ７１２において、サブセットからの回復完了通知を待ち受ける。通知手段としては、ファイル連携、プロセス間通信、あるいは、ＤＢ管理者によるコマンド経由といった方法が考えられる。回復完了を確認したら、ステップ７１３においてディスク制御権を獲得し、ステップ７１４において、副ストレージ１１３を副サーバ１１０にマウントするとともに、各ファイルをよみこみ、ステップ７１６において業務受付を再開する。
【００８６】
なお、上記サブセット５００内でＤＢ回復を完了させる手順としては、通常のＤＢサーバで行われる回復処理と同様にログの終端までｒｅｄｏを行った後、ｕｎｄｏを行う手法がある。あるいは、サブセット５００でのログ適用の過程でＴｒを考慮しながらログ適用を行う手法がある。すなわち、Ｔｒの決着／未決着を管理し、決着したＴｒのみｒｅｄｏすることにより、ｕｎｄｏ処理を不要とすることが可能となる。
【００８７】
＜サブセットでのＤＢ回復処理１＞
図１１に決着したＴｒのみをｒｅｄｏする場合の概念図を示す。図１１はサブセット５００でのログ適用の時系列的な過程を表しており、丸付きの線が、それぞれ並行して処理されるトランザクションＴｒを表している。サブセット５００は、ログ１１６をバッファリングし、バッファリングされたログ１１６を解析し、決着したＴｒに関するログのみｒｅｄｏする。
【００８８】
図１１では、時刻１２００から時刻１２０１のログ１１６がバッファリングされている様子を表している。バッファリングされたログ１１６はＴｒレベルで解析され、この期間で決着するＴｒ１２０２、１２０３、１２０４のみがｒｅｄｏされる。なお、時刻１２０１以降に決着するＴｒは、それ以降のバッファリング及び解析でｒｅｄｏされる。
【００８９】
以下に、サブセット５００内でＤＢ回復を完了させる場合の、サブセット５００内の処理フローを説明する。
【００９０】
最初に、通常通りログ１１６の終端までｒｅｄｏを行った後、ｕｎｄｏまで行う場合の処理フローについて図１２を用いて説明する。
【００９１】
最初にステップ９０１、９０２においてＣＰ情報ファイルにアクセスすることにより、ログ読みこみ位置を決定する。続いて、ステップ９０３において、擬似ＣＰ処理を行うための変数等を初期化する。なお、以下の例では、一定数のログを処理すると擬似ＣＰを発行する例を示すが、擬似ＣＰは、一定期間を経過した場合など別のタイミングで発行してもよい。
【００９２】
続いて、ステップ９０５、９０７において中断／復帰指示があるかどうかを確認する。中断指示がある場合にはｉflagに値をセットする。このｉflagがＯＮ（＝１）の間は上記図６と同様にループすることになり、ログ適用処理が中断する。復帰指示がされた場合には、ｉflagが０にセットされるため、ループから抜け以降の処理が実行される。
【００９３】
中断状態でない場合は、ステップ１３００において未適用のログ１１６があるかどうかをチェックする。未適用ログがある場合は、ステップ１３０１においてログを読み込み、ステップ１３０２においてログ適用を行いＤＢを更新する。このとき、Ｔｒ表の更新も同時に行う。次に、ステップ１３０３において停止指示があるかどうかをチェックする。停止指示がある場合は、ステップ１３０７において、擬似ＣＰ処理を行い、ステップ１３０５において、サブセットの処理を終了する。ここでの停止は、例えばサブセットが動作するハードウェアの交換など運用上の理由により、一時的にサブセットを終了させる必要がある場合が想定される。
【００９４】
停止指示がない場合には、ステップ１３０６において、一定数のログ適用処理が行われているかどうかをチェックする。一定数のログ適用処理が行われている場合には、ステップ１３０７において擬似ＣＰ処理を行い、ステップ１３０８において、変数を初期化する。そうでない場合は、ステップ１３１０において、変数をインクリメントし、ステップ９０４に戻る。
【００９５】
未適用ログがなく、ステップ１３１２においてＦ．Ｏ指示があることが確認された場合は、ステップ１３１３にてログ１１６の終端までログ適用が完了したかを判定して、完了していればステップ１３１４において、未決着Ｔｒのｕｎｄｏ処理を行う。Ｕｎｄｏ処理が完了した後、ＣＰ情報ファイルを初期化する。なお、ログ適用がログ１１６の終端まで達していない場合には１３０１に移行してログ適用を完了させる。
【００９６】
＜サブセットでのＤＢ回復処理２＞
次に、サブセット内でＤＢ回復を完了させる手順として、ログ適用の過程でＴｒの決着／未決着を管理し、決着したＴｒのみｒｅｄｏする場合の処理フローを図１３に示す。基本的なフローは図１２と同一となる。図１２との差異は、未適用ログがあった場合の処理であり、ステップ１３０１でログを読み込んだ後（バッファリングし）、ステップ１４００においてＴｒ解析を実施し決着したＴｒを判定する。次に、ステップ１４０１において決着したＴｒのみｒｅｄｏする。
【００９７】
また、Ｆ．Ｏ指示を受けた時点での処理も異なる。ステップ１３１２でＦ．Ｏ指示がなされたことが判断されると、ステップ１３１３でログ１１６の終端まで達したか否かを判定し、ステップ１４０２においてＣＰ情報ファイルの初期化を行って処理を終了する。読み込まれたログ１１６までに関しては、それまでに決着したＴｒがログ適用されており、さらに、未決着のＴｒに関わるログは適用されていないため、ｕｎｄｏすることなく、すぐに処理を終了することが可能となる。また、副ＤＢＭＳ１１１ではＤＢ回復処理を行う必要がないので、ＣＰ情報ファイルは初期状態にしておけばよい。
【００９８】
＜まとめ＞
以上のように、正／副の２つのサイト１、２を設け、平常時から正サイト１のデータを副サイト２にコピーするディザスタリカバリシステムにおいて、正サイト１のログ１０６のみをストレージ１０３のリモートコピー機能により、副サイト２の副ストレージ１１３へコピーしておく。ここで、副サイト２には副ストレージ１１３を制御する専用装置５０１を設けておき、専用装置５０１上ではＤＢＭＳの一部（例えば、ログ適用機能）のみを有するサブセット５００を稼動させる。サブセット５００は、リモートコピーを行った副サイト２の副ストレージ１１３に格納されたログ１１６から副サイトのＤＢ１１７はコピーされるログ１１６より回復する。
【００９９】
これにより、正常時には副サーバ１１０は不要となって、ログ適用を行うことが可能なリソースを備える専用装置５０１を運用すればよいので、副サーバ１１０のようにトランザクションを処理する能力は不要となり、専用装置５０１を小型の計算機で構成することで平常時の運用コストを低減することができる。
【０１００】
フェイルオーバ時には、副サーバ１１０を副サイト２へ加えるとともに、サブセット５００から回復完了後のＤＢ１１７またはＤＢ１１７の回復処理を副サーバ１１０で起動したＤＢＭＳ１１１へ引き継ぐことで、サービスの再開を行うことができる。
【０１０１】
災害時等には、平常時に正サイト１で行っていた業務と同等の処理を副サイト２で行うために、業務は上位の副サーバ１１０上の副ＤＢＭＳ１１１で行う。そのためには、従来から行われているサイト間系切り替え１３０に加えて、副サイト内系切り替え５０５が必要となる。
【０１０２】
このサイト間系切り替え１３０の実現のために、サブセット５００には、そのためのサイト内系切り替え機構５０５を設ける。
【０１０３】
副サイト２内のサブセット５００から副サーバ１１０への切り換えは、以上の説明をまとめると以下のようになる。
１．サブセット５００での回復（サイト内フェイルオーバ）の中途で上位サーバ（副サーバ１１０）への引き継ぎ
１−１  Ｔｒの実行状況を考慮しない擬似ＣＰ情報ファイルによる引き継ぎ
１−２  Ｔｒの実行状況を考慮して擬似ＣＰを生成し、ＣＰ情報ファイルを更新
１−３  Ｔｒ管理テーブル３１０による引き継ぎ。
２．サブセット５００で全てのＤＢ１１７の回復完了後に上位サーバへ引き継ぎ。
【０１０４】
２−１  ログの終端までｒｅｄｏを行った後、ｕｎｄｏを行う。
【０１０５】
２−２  Ｔｒを考慮しながらログ適用を行い、決着したＴｒのみをｒｅｄｏする。
【０１０６】
上記１では、サブセット５００の回復途中で、疑似ＣＰやトランザクション管理テーブル３１０を介して副サーバ１１０へ引き継ぐことにより、サブセット５００が稼動する専用装置５０１よりも処理能力の高い副サーバ１１０へ速やかに引き継ぐことにより、ＤＢの回復をいち早く行って業務再開までのオーバーヘッドを短縮できる。
【０１０７】
一方、上記２では、フェイルオーバ指示があった時点でログ適用がログ１１６の終端に達していれば、即座に副サーバ１１０へ引き継ぐことができる。
【０１０８】
以上のように、同期対象がログのみなので広域災害を考慮した場合であって、データ保護と主サイト１のオンライン性能維持を両立することが可能となり、さらに、ログ適用装置を中間層の専用装置５０１にオフロードすることにより、平常時はサーバレスとすることできるため、より少ないコストで広域災害に対応したＤＲシステムを構築可能。
【０１０９】
サブセット５００と副ＤＢＭＳの間の切替え機構を用意することにより、平常時は安価な構成をとりながら、災害時や計画停止時には、サブセットから副サーバへ制御を切り替えることにより、災害時や計画停止の間であっても、平常時と同等の処理量の業務を副サイト２でこなすことが可能となる。
【０１１０】
副サイト２において、正サイト１とは独立してＣＰ情報を管理することにより、副サーバ１１０は、サブセット５００での回復が中途の状態で、引継ぎを行うことが可能となり、その結果、残りの回復は、リッチなリソースを有する副サーバ１１０で行うことができ、さらに、制限つき回復が可能となることから、業務再開までの時間を短縮することが可能となる。
【０１１１】
さらに、サブセット５００内でＴｒ管理を行い、Ｔｒ的に整合性のとれた状態に回復させることにより、引き継ぎ時にｕｎｄｏする必要がなく、また、上位サーバでは全く回復処理を行う必要がないため、上位サーバの運用が容易となる。
【０１１２】
＜第２実施形態＞
図１４は、第２の実施形態を示し、前記第１実施形態のサブセットを中間層の専用装置ではなく、副ストレージ１１３の中に配置したものである。
【０１１３】
図中サブセット６００は、前記第１実施形態と同様に副サイト２のＤＢＭＳ１１１の一部の機能（ログ回復機能）のみを有する。そして、副ストレージ１１３は、図示しないＣＰＵ及びメモリを備え、これらのリソースを用いてサブセット６００が実行される。
【０１１４】
サブセット６００を副ストレージ１１３の中に配置することにより、副ストレージ１１３内の高速ネットワーク（ストレージ間ネットワーク１２０）が利用可能なため、ログ適用処理の高速化が可能となる。
【０１１５】
また、前記第１実施形態のようにサブセットを運用する専用装置５０１を用いる場合は、副ストレージ１１３と専用装置５０１の間を、例えば、ＦＣスイッチ等を介して接続する必要あるのに対し、サブセット６００を副ストレージ１１３内に配置する場合には、そのような接続は不要であり、システムの構成及びセットアップを簡略化することが可能となる。さらに、ＤＢ１１７レベルまで考慮した回復がストレージ内で可能となるため、ユーザから見るとＤＢ回復処理が不要となり、運用のさらなる容易化が実現されることなる。
【０１１６】
この場合も、平常時は副サーバ１１０が不要であり低コスト運用が可能となる。しかし、災害時には、副サイト２で業務を継続する必要があるので、災害前と同等の処理量をこなすためには、ストレージ内のサブセットでの業務継続は困難である。また、サブセット６００がログ適用のみに限定されている場合は、そもそも業務を受け付けることはできない。そこで、災害時には、正サイト１と同等の副サーバ１１０を立ち上げて、この副サーバ１１０で業務を継続する必要がある。そのためには、従来から行われている正サイトから副サイトの間のサイト間系切り替え１３０だけでなく、サブセット６００から副サーバ１１０への副サイト内の切り替え６０３（サブセットがストレージにオフロードされる）が必要となる。
【０１１７】
このサイト内切り換え６０３については、前記第１実施形態と同様であり、上記１．の１−１及び１−２のようにサブセット６００での回復（サイト内フェイルオーバ）の中途で上位サーバ（副サーバ１１０）への引き継ぎを行ったり、上記２．のサブセット６００で全てのＤＢ１１７の回復完了後に上位サーバへ引き継ぐことができる。
【０１１８】
この実施形態では、前記第１実施形態のような専用装置５０１も不要となるので、正常時には副ストレージ１１３のみを副サイト２で稼動させるだけで良く、副サイト２の運用コストをさらに低減できるのである。
【０１１９】
また、副ストレージ１１３としてはＮＡＳ（Network Attached Storage）等を採用することができる。
【０１２０】
なお、上記請求項１の発明において、第１の系と第２の系は、前記第１のストレージと第２のストレージとを接続するストレージ間ネットワークと、前記第１の計算機と中間装置または第２の計算機とを接続するサーバ間ネットワークと、を介して接続される。
【産業上の利用可能性】
【０１２１】
以上のように、本発明によれば、副サイトの運用コストを抑えて、金融業や大企業などに採用されるディザスタリカバリシステムに適用することができる。
【図面の簡単な説明】
【０１２２】
【図１】本発明の一実施形態を示し、２つのサイトでディザスタリカバリを行う場合のシステム構成図。
【図２】フェイルオーバ時のサブセットと副ＤＢＭＳにおける処理の一例を示すフローチャート。
【図３】サブセットで行われるＣＰ情報ファイル処理を示すフローチャート。
【図４】トランザクションの実行状況を考慮して擬似ＣＰを生成し、ＣＰ情報ファイルを更新する場合の説明図である。
【図５】サブセットで行われるＣＰ情報ファイルの処理を示すフローチャート。
【図６】サブセットで行われる引き継ぎ処理の一例を示すフローチャート。
【図７】トランザクション管理テーブルの構成を示す説明図である。
【図８】サブセットで行われる引き継ぎ処理の一例を示し、ファイルを介して副サーバに引き継ぐ場合のフローチャート。
【図９】副サーバで行われる副ＤＢＭＳを起動するフローチャート。
【図１０】フェイルオーバ時のサブセットと副ＤＢＭＳにおける処理の一例を示し、サブセットでＤＢの回復を完了する場合のフローチャート。
【図１１】決着したトランザクションのみをｒｅｄｏする場合の説明図。
【図１２】サブセットで行われる回復及び引き継ぎ処理の一例を示すフローチャート。
【図１３】サブセットで行われる回復及び引き継ぎ処理の他の例を示すフローチャート。
【図１４】第２実施形態を示し、２つのサイトでディザスタリカバリを行う場合のシステム構成図で、サブセットをストレージ内に実装した例を示す。
【図１５】従来例を示し、リモートコピーを用いたディザスタリカバリシステムの構成図。
【図１６】従来例を示し、チェックポイントを機転とするＤＢ回復処理を示すフローチャート。
【図１７】トランザクション管理テーブルの一例を示す説明図。
【図１８】従来例を示し、ログの転送機能をＤＢＭＳに組み込んだ場合のシステム構成図。
【符号の説明】
【０１２３】
１  主サイト
２  副サイト
１００  主サーバ
１０１  主ＤＢＭＳ
１０３  主ストレージ
１０６、１１６  ログ
１１０  副サーバ
１１１  副ＤＢＭＳ
１１３  副ストレージ
５００、６００  サブセット
５０１  専用装置
５０２、５１２  設定ファイル
【図１】
2006004147.tif 000003
【図２】
2006004147.tif 000004
【図３】
2006004147.tif 000005
【図４】
2006004147.tif 000006
【図５】
2006004147.tif 000007
【図６】
2006004147.tif 000008
【図７】
2006004147.tif 000009
【図８】
2006004147.tif 000010
【図９】
2006004147.tif 000011
【図１０】
2006004147.tif 000012
【図１１】
2006004147.tif 000013
【図１２】
2006004147.tif 000014
【図１３】
2006004147.tif 000015
【図１４】
2006004147.tif 000016
【図１５】
2006004147.tif 000017
【図１６】
2006004147.tif 000018
【図１７】
2006004147.tif 000019
【図１８】
2006004147.tif 000020