JP4731975B2 - データベース管理方法、およびストレージシステム - Google Patents

Description

本発明は、ログ転送によるディザスタリカバリ技術に関し、特に、ファイルより細かい粒度でログの読み込み・適用を行い、かつ、ログの読み込み・適用処理の中で、ログの再読み込み、あるいは、リモートコピーと連携した読み込みを行うディザスタリカバリ技術に適用して有効な技術に関する。

近年、ＩＴはビジネスの基盤となっており、その重要性はますます高まっている。そのため、システムダウンが及ぼす影響は非常に大きく、例えば金融業の場合は、時間当たり数百万ドルの損失があると言われている。以上のような背景から、災害であってもビジネスを継続させることを目的にデータを遠隔地にバックアップするディザスタリカバリ（以下、ＤＲと呼ぶ）が注目を集めている。

ＤＲシステムで、サイト間の転送を実現する方式としては、リモートコピー機能を有する高機能ストレージを用いた方式が注目されている。リモートコピーを用いた方式の利点としては、サーバのリソースを消費することなくサイト間の転送を実現することが挙げられる。

テロや広域災害を受けて法規制の動向もあり、リモートコピーを用いるＤＲシステムでも、（１）災害時にもデータ欠損なく、副サイトでビジネスを再開できること、（２）広域災害に対応し、副サイトを数百ｋｍ以上離れた遠隔地に配置した場合であっても正サイトのオンライン性能を維持すること、の課題を同時に解決することが求められている。

現状では、ＤＲシステムは、金融業や大企業を中心に導入が進められている。しかし、今後は、リスク回避、格付け等の理由で、中小企業に対してもＤＲシステムの導入が求められると考えられる。中小企業に適用範囲を広げるためには、前述の２つの課題に加えて、ＤＲシステムコストの削減が重要な課題となる。ここで、現在のＤＲシステムは、信頼性・セキュリティの観点から、専用線が用いられることが多い。広帯域幅の専用線の構築・維持は膨大な費用を要するため、ＤＲシステムコストを削減するためには、回線コストの削減が必須となる。

以上の課題を解決する方式として、データベース処理システム（以下、ＤＢＭＳと呼ぶ）のログファイルのみをリモートコピーで転送し、データベース（以下、ＤＢと呼ぶ）ファイルは副サイトでログから回復するＤＲ方式が注目されている。この方式では、ＤＢファイルの転送が不要となるため、大幅な回線コストの削減が可能となる。近年は、ログを転送するＤＲ方式においては、災害時の切り替えや計画的な切り替えの高速化、あるいは、運用容易性が求められている。

例えば、ログファイルをリモートコピーで転送し、副サイトでＤＢファイル（ＤＢボリューム：以下、ボリュームをＶＯＬと呼ぶ）を回復する方式としては、従来方式１（非特許文献１）、従来方式２（特許文献１）の２つの方式が知られている。

（従来方式１）
この従来方式１を図１５に示す。図１５は、従来方式１を適用したシステムの構成の一例を示す図である。図１５において、１０１は正サイトのサーバ１００内のＤＢＭＳ、１４００は副サイトのサーバ内のＤＢＭＳ、１２０は正サイトのストレージ、１３０は副サイトのストレージ、１２８，１３８はログ用ＶＯＬ、１２９，１３９はＤＢ用ＶＯＬ、１４０１，１４１１はアーカイブログ用ＶＯＬ、１４０２はネットワークをそれぞれ示す。また、１４０３はリモートコピー、１４０４はサーバ間転送、１４０５はログ読み込み、１４０６はログ適用、１４０７はアーカイブをそれぞれ示す処理ルートである。

一般に、ＤＢへの更新差分であるログが記録されるログファイル（ログ用ＶＯＬ）は、複数のログファイルを世代管理する運用がとられ、容量超過などのイベント契機で切り替えながらログを追記していく。このとき、ログファイルは繰り返し上書きされていくため、切り替え元のログファイルの内容を保存しておくことを目的に、アーカイブログファイル（アーカイブログ用ＶＯＬ）を作成する。

図１５の方式は、ログをリモートコピーで転送すると共に、アーカイブログをサーバ間で転送する。副サイトの計算機では、スタンバイＤＢＭＳがアーカイブログを受信し、受信したアーカイブログを適用することでＤＢ（ＤＢ用ＶＯＬ）を回復する。

（従来方式２）
この従来方式２を図１６に示す。図１６は、従来方式２を適用したシステムの構成の一例を示す図である。図１６において、１６００はアーカイブを示す処理ルートであり、図１５と同一のものには同一の符号を付している。

図１６の方式では、ログのみをリモートコピーで転送する。副サイトでは、正サイトのアーカイブログファイル生成を監視しておき、アーカイブログファイル生成を検出すると、副サイトでも独立してアーカイブログファイルを生成する。アーカイブログファイルを生成したら、そのファイルを適用することで、ＤＢを更新する。
米国特許第５６４０５６１号明細書 ＳＡＮＲＩＳＥ Ｓｏｌｕｔｉｏｎ Ｓｕｉｔｅ ｗｉｔｈ Ｏｒａｃｌｅ（ｈｔｔｐ：／／ｗｗｗ．ｈｉｔａｃｈｉ．ｃｏ．ｊｐ／Ｐｒｏｄ／ｃｏｍｐ／ｓｔｏｒａｇｅ／ｄｉｓｋａｒｒａｙ／ｔｅｃｈ／ｗｈｉｔｅｐａｐｅｒ／ｐｄｆ／ｔｅｃｈ＿ｄｉｓａｓｔｅｒ．ｐｄｆ）

ところで、前記のような従来方式では、正サイトで書き込み中の最新のログファイルではなく、１世代以上前のログをファイル単位で適用している。これは、リモートコピーで書き込み中のＶＯＬをそのまま読むと、読み込んだ内容の整合性が保障されないためである。これらの方式には、以下のような課題が考えられる。

（課題１：迅速なＦＯ（ｆａｉｌｏｖｅｒ：サイト間切り替え）が困難）
一般に、運用を容易化する観点から、頻繁にログファイルのアーカイブを行う運用は好まれず、ログファイルのサイズは拡大する傾向がある。そのため、ファイル単位で回復を行う方式は、災害／計画ＦＯ時にも、サイズの大きいファイルの先頭からログ適用を開始しなければならず、ＦＯ完了までに多くの処理時間を要し、迅速なサービス再開が行えない。

（課題２：正サイトのオンライン性能維持とＤＢ整合性保証の両立）
ＦＯ時間を高速化するためには、ログファイル単位ではなく、正サイトが使用中のログファイルを読み込み対象として、ファイルより細かい粒度でログの読み込み・適用を実施すればよい。ここで、ＤＢを正しく回復するには、ログが正しく読まれている事が保証されていなければならない。しかし、リモートコピーで書き込みが行われている最中に、そのログファイルを読むと、不正にログを読み込んでしまう場合がある。以下に、ログファイルの構造を説明した後、不正にログを読み込む場合について説明する。

最初に、ログファイルの構造と読み込み／書き込み方式について説明する。ここで、行への更新差分情報そのものはログレコードと呼ぶものとする。正サイトのＤＢＭＳでは、更新を行う時には必ずログレコードを生成する。しかし、ログレコードを生成する度に、ストレージに出力するとオンライン性能への影響が大きいため、内部でバッファリングしておき、複数のレコードからなるログブロック単位で出力を行う。ログブロックには、ヘッダとトレイラが付加されており、両者とも正常に書かれていることにより、ブロックの整合性が保障できる。そのためには、副サイトでログを読み込む場合も、ブロック単位で読み込み、そのヘッダとトレイラにより整合性を検証することができる。

しかし、広域災害を考慮したＤＲシステムに適用する場合には、上記の処理だけでは整合性が検証できないケースが生じる。サイト間が長距離で転送遅延が大きい場合には、転送遅延の影響を最小限にするために、ブロックのサイズは大きく、転送回数を少なくすることが望ましい。しかし、このブロックサイズがストレージのキャッシュ管理単位（読み込み単位）より大きくなると、ログブロックの整合性検証が正しく行えないケースが生じる。このような不正な整合性検証は、ログ適用が正サイトのオンライン処理に完全に追いついており、正サイトでまさに書き込みを行っている領域を、副サイトのログ適用機能が読もうとしている場合に生じる。

図１７に例を示す。図１７は、ログ読み込みが正常に行えない場合の一例を説明する図である。図１７において、１５００はログブロック、１５０１は書き込み（１）領域、１５０２は読み込み（１）領域、１５０３は書き込み（２）領域、１５０４は読み込み（２）領域、１５０５はログ適用部に読み込まれたログブロックをそれぞれ示す。

正サイトのＤＢＭＳはログブロック全体を書き込むが、ＯＳ層で複数のＩＯに分割される場合がある。図１７では２個のＩＯに分割されており、それぞれがリモートコピーで転送される。副サイトでは、ログ適用機能を持つログ適用部が正サイトのＩＯとは独立に読み込み処理を行う。このとき、ストレージ内ではキャッシュ管理単位でデータ管理を行っており、読み込みもこのキャッシュ管理単位で行われる。

図１７では、正サイトのＤＢＭＳの１回の書き込みがＯＳ層で２回の書き込みに分割されており、１回目の書き込みだけが完了している時に、ログ適用の１度目の読み込みが行われている（ｔ→ｔ＋２）。続いて、２回目の書き込みが終わり、ブロック全体の書き込みが完了した後、ログ適用部が２回目の読み込みを行っている（ｔ＋３→ｔ＋４）。その結果、ログ適用部が読み込んだログブロック１５０５は図１７のように、中抜けの状態となる。この場合、先頭／後尾（ヘッダ／トレイラ）は正しく読み込まれているため、ログブロックは正しいと判断され、ログ適用が行われる。その結果、副サイトのＤＢが破壊されてしまう。

以上のように、回線コスト削減のためにログをリモートコピーで転送し、ＤＢはログ適用で回復するＤＲ方式においては、（１）ログファイル単位で読み込み・適用を行う場合には迅速なＦＯが行えない、（２）迅速なＦＯを行うために、ファイルより細かい粒度で適用を行うと、不正なログを読み込み適用してしまうことでＤＢを破壊してしまうことがある、という問題が生じる。

そこで、本発明の目的は、ファイルより細かい粒度でログの読み込み・適用を行うことでＦＯの高速化を実現し、かつ、ログの読み込み・適用処理の中で、ログの再読み込み、あるいは、リモートコピーと連携した読み込みを行うことで、正サイトのログ書き込み単位が大きい場合でも正しくログ読み込みを行うことができるＤＲ技術を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。

本発明は、ＦＯの高速化のために、ファイルより細かい粒度でログの読み込み・適用を行い、かつ、正サイトのログ書き込み単位が大きい場合でも正しくログ読み込みを行うために、ログの読み込み・適用処理の中で、ログの再読み込み、あるいは、リモートコピーと連携した読み込みを行うものである。すなわち、本発明において、正サイトのＤＢＭＳのデータを遠隔地に配置された副サイトにコピーするＤＲ方法およびＤＲシステム、第１のストレージ（正ストレージ）に加えられた更新を遠隔地に配置された第２のストレージ（副ストレージ）に反映するリモートコピー方法およびストレージシステムにおいては、以下のような特徴を有するものである。

（１）正サイトでは正ストレージのリモートコピーでログを転送し、副サイトでは転送されるログを適用して副ストレージのＤＢを回復するログ適用処理において、正サイトで複数のログレコードからなるログブロック単位で書き込みを行い、副サイトでログ適用を行う際には、以下の処理を行う。副ストレージからログブロックを読み込み、整合性を検証する。ログブロックの読み込み時に、読み込み処理とリモートコピーによる書き込み処理とが競合していないかを判定する。判定により、競合がないと判定されたログブロックのみをＤＢに適用する。

（２）ログの再読み込みを行う方式において、副サイトでログ適用を行う際には、副ストレージからログブロックを読み込み、整合性を検証する。読み込んだログブロックの内、最後の１つを除いたログブロックについては読み込み処理とリモートコピーによる書き込み処理とが競合していないと判定する。最後のログブロックを除いたログブロックについては再読み込みを行った上で適用する。これにより、読み込みが正しく行えたかを確認しながらログ適用を行い、正サイトから読み込むべきログを指定するための通信や処理を行うことなく、副サイトで独立してログ適用してＤＢを回復することができる。

（３）リモートコピーと連携した読み込みを行う方式において、副サイトでログ適用を行う際には、第２のコピーを中断する。第２のボリュームからログブロックを読み込む。読み込んだログブロックを適用する。読み込めるログがなくなった場合にはログ適用処理を中断した後に第２のコピーを再開する。これにより、ログ読み込み時には第２のコピーを中断状態とすることで、ログ読み込みとリモートコピーによる書き込みが競合することを回避し、正サイトから読み込むべきログを指定するための通信や処理を行うことなく、副サイトで独立してログ適用してＤＢを回復することができる。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

（１）ログを同期転送する場合には欠損がないことが保証可能である。また、リモートコピー利用により、サーバリソースを消費することなく転送が可能なので、正サイトのオンライン性能への影響が小さい。

（２）更新量の多いＤＢファイルの転送が不要なため、狭帯域幅回線でも実現でき、回線コストの削減が可能となる。

（３）ファイルより細かい単位で適用を行うため、切り替え時にも迅速にサービスを再開することが可能となる。

（４）正サイトのオンライン性能維持のため、ログのＩＯ単位が大きい場合であっても、再読み込み処理／リモートコピー連携処理により、不正読み込みによるＤＢ破壊を防止することが可能となる。従って、広域災害を考慮して副サイトが数百ｋｍ以上離れた構成にも対応可能となる。

（５）正サイトに、ログの読み込み位置を決定するための処理、あるいは、通信を新たに加えることなく、副サイトのログ適用部だけで独立してログ適用処理を行い、ＤＢを回復することが可能となる。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の構成要素には原則として同一の符号を付し、その繰り返しの説明は省略する。

（実施の形態１）
本発明の実施の形態１におけるＤＲシステムを、図１〜図６を用いて説明する。

まず、図１により、本実施の形態におけるＤＲシステムの構成の一例を説明する。図１はＤＲシステムの構成の一例を示す図である。

本実施の形態のＤＲシステムは、ログの再読み込みを行う方式を適用し、正サイトと、副サイトから構成される。正サイトは、ＤＢＭＳが稼動する計算機からなるサーバ１００と、ＤＢＭＳのログファイルとＤＢファイルが保存されるストレージ１２０から構成される。副サイトは、ログ適用処理を行う副ＤＢＭＳ、あるいは、ログ適用に特化された機能（ログ適用機能）が稼動する計算機からなるサーバ１１０と、ストレージ１３０から構成される。正サイトのストレージ１２０と副サイトのストレージ１３０とは、ネットワーク１５０を通じて接続されている。

正サイトにおいて、サーバ１００では、ＤＢＭＳ１０１が稼働し、このＤＢＭＳ１０１には、ＤＢバッファ１０２、ログバッファ１０３、ＤＢアクセス制御部１０４、ログ管理部１０５が設けられている。正サイトのストレージ１２０には、ストレージ制御処理部１２１、キャッシュ１２６、ディスクアクセス制御部１２７、ログ用ＶＯＬ（Ｌｏｇ）１２８、ＤＢ用ＶＯＬ（ＤＢ）１２９が設けられている。ストレージ制御処理部１２１には、コマンド処理部１２２、コピー処理制御部１２３、リモートコピー処理部１２４が設けられている。

副サイトにおいて、サーバ１１０では、ログ適用部１１１が動作し、このログ適用部１１１には、ＤＢバッファ１１２、ログバッファ１１３、ログ適用制御部１１４、ログ読み込み整合性検証部１１５、適用部１１６が設けられている。副サイトのストレージ１３０には、ストレージ制御処理部１３１、キャッシュ１３６、ディスクアクセス制御部１３７、ログ用ＶＯＬ（Ｌｏｇ）１３８、ＤＢ用ＶＯＬ（ＤＢ）１３９が設けられている。ストレージ制御処理部１３１には、コマンド処理部１３２、コピー処理制御部１３３、リモートコピー処理部１３４が設けられている。

正サイトのサーバ１００では、ＤＢＭＳ１０１が稼働する。ＤＢＭＳ１０１はＵＡＰ（ユーザアプリケーション）からの指示に従い、ストレージ１２０内のＤＢ用ＶＯＬ１２９に格納されるデータを参照、あるいは、更新する。ＤＢＭＳ１０１は、ＤＢ用ＶＯＬ１２９に対して更新を行う場合には、まず、更新差分をログとして、ストレージ１２０内のログ用ＶＯＬ１２８へ格納する。なお、ＤＢＭＳ１０１は、ログ管理部１０５とＤＢアクセス制御部１０４を有し、それぞれがＤＢバッファ１０２、ログバッファ１０３を介してストレージ１２０内のデータをアクセスする。

正サイトのストレージ１２０は、リモートコピー機能を有する。同様に、副サイトのストレージ１３０も、リモートコピー機能を有し、（）内に併記して説明する。サーバ１００（１１０）からのＩＯ要求があった場合、コマンド処理部１２２（１３２）が要求を受け付ける。要求が書き込み要求であった場合は、キャッシュ１２６（１３６）上にデータがあれば、キャッシュ１２６（１３６）上でデータを更新する。キャッシュ１２６（１３６）にない場合は、ディスクアクセス制御部１２７（１３７）に該当データを依頼し、ＶＯＬを構成するディスクからキャッシュ１２６（１３６）にコピーしてから書き込みを行う。また、書き込んだデータは、ディスクアクセス制御部１２７（１３７）により非同期でディスクへ書き戻される。

ここでは、リモートコピーの対象となっているＶＯＬへの書き込みが行われた場合は、キャッシュ１２６（１３６）への書き込みに続いて、リモートコピー処理部１２４（１３４）が副サイトのストレージ１２０の対応する領域（キャッシュ１３６）にも書き込みを行うものとする。また、コピー処理制御部１２３（１３３）へ指示を行うことで、コピーの開始／停止（切断）／中断といったリモートコピーの状態制御が可能であるものとする。なお、本実施の形態では、正／副サイトのストレージ１２０（１３０）のログ用ＶＯＬ１２８（１３８）がリモートコピーの対象になっているものとする。

副サイトのサーバ１１０では、ログ適用部１１１が動作する。ログ適用部１１１は、リモートコピーで転送されるログ用ＶＯＬ１３８を読み込み、ＤＢ用ＶＯＬ１３９に含まれるデータを更新する。ログ読み込み整合性検証部１１５は、ログ用ＶＯＬ１３８からログを読み込み、読み込んだログの整合性を検証する。ログ適用部１１１は、読み込んだログを適用し、ＤＢ用ＶＯＬ１３９上のデータを更新する。ログ適用制御部１１４は、ログ読み込み整合性検証部１１５、適用部１１６を制御することでＤＢを回復する。なお、ログ適用部１１１も、ＤＢＭＳ１０１と同様に、ＤＢバッファ１１２、ログバッファ１１３を介してＶＯＬ上のデータをアクセスする。

本実施の形態のＤＲシステムにおいて、ログ適用を行うために副ＤＢＭＳではなく、ログ適用機能を利用する場合は、切り替え後にサービスを継続する副ＤＢＭＳは、この副サイトのサーバで動作してもよいし、別のサーバで動作してもよい。以下では、ログ適用機能を用いる場合について説明する。正サイトのストレージ１２０と副サイトのストレージ１３０は、ストレージ間ネットワーク１５０で結合されており、ログファイルのみがリモートコピーで転送される設定になっている。

副サイトのログ適用機能は、図２に示すような、リモートコピーにより転送が行われるログ用ＶＯＬ２００上に存在するログファイル２０１を直接読んで適用する。図２は、ログファイルの構造の一例を示す図である。

このログファイル２０１は、ログレコード２０３を束ねたブロック単位で読み書きされる。すなわち、正サイトのＤＢＭＳは、ブロック単位でログファイルに書き込みを行い、一方、ログ適用機能はブロック単位で読み込みを行う。このログブロック２０２には、先頭にヘッダ２０４、後尾にトレイラ２０５が付加されており、それぞれに含まれるマジックワードにより、ブロック全体の整合性検証が行える。

ただし、前述のように、ログブロック２０２のサイズが大きく、かつ、ログ適用が正サイトのログ書き出しに追いついている場合、リモートコピーによる書き込みとログ適用機能の読み込みが競合する場合には、このヘッダ／トレイラによる整合性検証だけでは整合性が保証できないので、図３に示すようなスケジュールで読み込み・適用を行う。図３は、ログブロックの読み込み・適用スケジュールの一例を示す図である。

すなわち、あるログブロック（ｂｌｏｃｋ（ｉ））の読み込み・適用を行う際（３００）には、そのブロック（ｂｌｏｃｋ（ｉ））に対して読み込みと書き込みが競合しないことを保証するために、次のログロック（ｂｌｏｃｋ（ｉ＋１））が読めるかどうかを最初に確認する（３０１）。次のブロック（ｂｌｏｃｋ（ｉ＋１））が読み込める場合には、先のログブロック（ｂｌｏｃｋ（ｉ））を再読み込みした上で、適用を行う（３０２）。ログはシーケンシャルに追記されるため、ログブロック（ｂｌｏｃｋ（ｉ＋１））が書かれていれば、ログブロック（ｂｌｏｃｋ（ｉ））の書き込みは正常に完了していることが判断でき、ログブロックの整合性を保証することが可能となる。

次に、図４〜図６により、本実施の形態のＤＲシステムにおいて、ログ読み込み・適用処理のフローの一例を説明する。それぞれ、図４は平常時、図５は切り替え時、図６は平常時（ＳＺ（サイズ）判定有り）のフローの一例を示す図である。

なお、本実施の形態においては、ブロックを１個ごとに読んでいるが、１度に複数のブロックを読み込んでもよい。複数のブロックを読み込んだ場合は、最後のブロック以前のブロックを適用対象とし、再読み込みを行った上で、適用を行う。

図４において、ログ読み込み・適用処理（平常時）では、最初に、ログの読み込み位置を決定する（Ｓ４０１）。ここで、ＤＢＭＳは、チェックポイント等のタイミングで、適用が完了しているログの通番（ＬＳＮ）やその時に使用しているログファイルやＤＢファイルなどの内部情報をＤＢＭＳ状態ファイルに出力する。

ログの読み込み位置決定では、ＤＢＭＳ状態ファイルからＬＳＮや使用しているログファイルを読み込み、最初に読み込むべきブロックを決定する（Ｓ４０２）。ここでは、ポインタ（ｐｔｒ）が指すブロックから読み込みを開始する。

読み込み位置を決定したら、以降は、管理者やアプリケーションからのＦＯ／停止指示があるか否かを判定し（Ｓ４０３）、ＦＯ／停止指示がある場合（Ｙ）は停止／ＦＯ処理に移行し、ＦＯ／停止指示がない場合（Ｎ）には、ＦＯ／停止指示があるまで、ログ読み込み・適用処理を繰り返す。

初めに、ｐｔｒが指すブロック（以降、ブロック（ｐｔｒ）とする）を読み込み（Ｓ４０４）、続いて、ヘッダとトレイラによりブロック（ｐｔｒ）の整合性検証を行う。ここでは、ブロック（ｐｔｒ）は整合性があるか否かを判定し（Ｓ４０５）、整合性がない場合（Ｎ）はＳ１へ戻り、整合性がある場合（Ｙ）、すなわち正しく読み込めた場合にはＳ２へ移行する。

そして、再び、ＦＯ／停止指示があるか否かを判定し（Ｓ４０６）、ＦＯ／停止指示がある場合（Ｙ）は停止／ＦＯ処理に移行し、ＦＯ／停止指示がない場合（Ｎ）には、次のブロック（ｐｔｒ＋１）の読み込みと整合性検証を行う。まず、次のブロック（ｐｔｒ＋１）を読み込み（Ｓ４０７）、続いて、ブロック（ｐｔｒ＋１）は整合性があるか否かを判定し（Ｓ４０８）、整合性がない場合（Ｎ）はＳ２へ戻り、整合性がある場合（Ｙ）、すなわち整合性が検証されたら、ブロック（ｐｔｒ）の再読み込みを行った上で適用を行い（Ｓ４０９，Ｓ４１０）、ｐｔｒを１つ進めて（Ｓ４１１）、Ｓ２へ戻る。

以降、ｐｔｒ＋１が指すブロックの読み込み・検証を行い、問題がなければ、ｐｔｒが指すブロックの再読み込み・適用を実施する。

図５において、管理者から、ＦＯ／停止指示を受けた場合の処理を説明する。

このログ読み込み・適用処理（切り替え時）では、最初に、停止指示かＦＯ指示かを判定し（Ｓ５０１）、停止指示であった場合（停止）は、ログ適用の進捗情報としてｐｔｒ情報をＤＢ状態ファイルに書き出して処理を終了する（Ｓ５０２）。一方、ＦＯ指示であった場合（ＦＯ）には、最初にリモートコピーの状態制御を行う（Ｓ５０３）。例えば、災害時のＦＯであれば、リモートコピーを切断状態とし、以降に正サイトからの書き込みが行われる事を抑止する。一方、計画的なＦＯであれば、コピーの向きを逆向きに設定する。

次に、ブロック（ｐｔｒ）の読み込みと整合性検証を行い、以降は終端と判定されるまでログの読み込み、適用処理を繰り返す。すなわち、ブロック（ｐｔｆ）の読み込みを行った上で適用を行い（Ｓ５０４，Ｓ５０５）、終端か否かを判定する（Ｓ５０６）。なお、ここではリモートコピーの状態制御実施後であり、リモートコピーと読み込みが競合することがないため、ログの再読み込み処理は不要となる。

そして、終端でない場合（Ｎ）はｐｔｒを１つ進めて（Ｓ５０７）、Ｓ３へ戻り、終端と判定された場合（Ｙ）、すなわち読み込むべきブロックがなくなったら、未決着トランザクションのキャンセル処理（ｕｎｄｏ処理）を実施する（Ｓ５０８）。ここで、ログ適用処理内で決着トランザクションだけを適用するような場合は、キャンセル処理は不要となる。続いて、状態ファイルにＤＢファイルが整合性のとれた状態になっていることを書き出し（Ｓ５０９）、副ＤＢＭＳを起動して（Ｓ５１０）、処理を終了する。

図６において、平常時にＳＺ判定有りの場合の処理を説明する。ブロックがキャッシュ管理サイズより小さく、かつ、一括して書かれる場合は、中抜け状態で読まれることはない。したがって、本処理では、ブロックのサイズがキャッシュ管理サイズより大きい場合にのみ、再読み込みを行う。このログ読み込み・適用処理（平常時、ＳＺ判定有り）では、前記図４の処理にＳＺ判定処理を追加した例であり、ここでは追加部分を主に説明する。

最初に、前記図４と同様に、ログの読み込み位置の決定処理（Ｓ６０１）、ブロック（ｐｔｒ）のログ読み込み位置決定（Ｓ６０２）、ＦＯ／停止指示があるか否かの判定（Ｓ６０３）、ブロック（ｐｔｒ）の読み込み（Ｓ６０４）、ブロック（ｐｔｒ）は整合性があるか否かの判定（Ｓ６０５）、を行った後、整合性がある場合（Ｙ）には、ブロック（ｐｔｒ）のサイズがキャッシュ管理サイズＳＺより大きいか否かを判定する（Ｓ６０６）。ブロック（ｐｔｒ）のサイズがＳＺより大きい場合（Ｙ）はＳ２へ移行し、大きくない場合（Ｎ）には、ブロック（ｐｔｒ）の適用を行い（Ｓ６０７）、ｐｔｒを１つ進めて（Ｓ６０８）、Ｓ１へ戻る。

Ｓ２へ移行したら、前記図４と同様に、ＦＯ／停止指示があるか否かの判定（Ｓ６０９）、ブロック（ｐｔｒ＋１）の読み込み（Ｓ６１０）、ブロック（ｐｔｒ＋１）は整合性があるか否かの判定（Ｓ６１１）、ブロック（ｐｔｒ）の再読み込みと適用（Ｓ６１２，Ｓ６１３）、を行った後、次のブロック（ｐｔｒ＋１）のサイズがキャッシュ管理サイズＳＺより大きいか否かを判定する（Ｓ６１４）。ブロック（ｐｔｒ＋１）のサイズがＳＺより大きい場合（Ｙ）はｐｔｒを１つ進めて（Ｓ６１５）、Ｓ２へ戻り、大きくない場合（Ｎ）には、ブロック（ｐｔｒ＋１）の適用を行い（Ｓ６１６）、ｐｔｒを２つ進めて（Ｓ６１７）、Ｓ１へ戻る。

以上説明したように、本実施の形態のＤＲシステムによれば、以下のような効果を得ることができる。

（１）ログの再読み込みを行う方式を適用し、ログを同期転送する場合には、欠損がないことを保証することが可能となる。また、リモートコピー利用により、サーバリソースを消費することなく転送を行うことができるので、正サイトのオンライン性能への影響を小さくすることが可能となる。

（２）ログの再読み込みを行う方式を適用することで、更新量の多いＤＢファイルの転送が不要なため、狭帯域幅回線でも実現することができるので、回線コストの削減が可能となる。

（３）ファイルより細かいブロック単位で適用を行うため、切り替え時にも迅速にサービスを再開することが可能となる。

（４）正サイトに、ログの読み込み位置を決定するための処理、あるいは、通信を新たに加えることなく、副サイトのログ適用部だけで独立してログ適用処理を行い、ＤＢを回復することが可能となる。

（実施の形態２）
本発明の実施の形態２におけるＤＲシステムを、図７〜図１３を用いて説明する。

まず、図７により、本実施の形態におけるＤＲシステムの構成の一例を説明する。図７はＤＲシステムの構成の一例を示す図である。

本実施の形態のＤＲシステムは、リモートコピーと連携した読み込みを行う方式を適用する。例えば、不正な読み込みが行われるのは、ｒｅａｄ／ｗｒｉｔｅが競合する場合である。そのため、本実施の形態のように、リモートコピーと連携した読み込みを行う方式では、ログ適用機能が読み込みを行う時には、リモートコピーによるｗｒｉｔｅが生じないようにすることで、ｒｅａｄ／ｗｒｉｔｅ競合を回避する。

本実施の形態のＤＲシステムは、前記実施の形態１に対して、正サイトのストレージ１２０にＰｕｌｌ型コピー処理部１２５が追加され、副サイトのストレージ１３０にＰｕｌｌ型コピー処理部１３５およびＪＮＬ ＶＯＬ（ＪＮＬ）１４０が追加されて構成される。

副サイトのストレージ１３０に、図８に示すようなＪＮＬ ＶＯＬ１４０を配置する。図８は、ＪＮＬ ＶＯＬと格納されるデータの構造の一例を示す図である。ＪＮＬ ＶＯＬ１４０には、データ８００、シーケンスＮＯ、反映先アドレスおよびサイズからなるメタデータ８０１、・・・、データ８０２、メタデータ８０３が格納され、ポインタ１（ｈｐｔｒ）８０４がメタデータ８０１のシーケンスＮＯを指し、ポインタ２（ｔｐｔｒ）８０５がメタデータ８０３のシーケンスＮＯを指す。

このＪＮＬ ＶＯＬ１４０を副サイトのストレージ１３０に配置することで、正サイトのログ用ＶＯＬ１２８の情報が副サイトのストレージ１３０のログ用ＶＯＬ１３８に２段階のコピーで伝わるようにする。すなわち、１段目のコピーは、正サイトのログ用ＶＯＬ１２８から、副サイトのＪＮＬ ＶＯＬ１４０にコピーする。このとき、ＪＮＬ ＶＯＬ１４０には、データに通し番号やタイムスタンプなどの情報を付加した上で追記されていく。ＪＮＬ ＶＯＬ１４０からログ用ＶＯＬ１３８へのコピー（Ｐｕｌｌ型コピー）は、非同期に行う。

また、本実施の形態においては、副サイトのストレージ１３０の制御プログラムが、このＪＮＬ ＶＯＬ１４０からのコピーを制御（中断／再開）するインターフェースを有している。ログ適用機能は、ログを読み込もうとするときには、まず、Ｐｕｌｌ型コピーを停止状態とする。その結果、ログ用ＶＯＬ１３８へのｗｒｉｔｅを抑止することができるので、通常の手順で（再読み込みをすることなく）、ログの読み込み・適用を行うことができる。ブロックの読み込みに失敗した場合には、Ｐｕｌｌ型コピーを再開し、新たな情報をログ用ＶＯＬ１３８に反映する。一定時間の経過後、あるいは、Ｐｕｌｌ型コピーのコピー量がある閾値を超えたら、再びＰｕｌｌ型コピーを停止し、ログの読み込み・適用を再開する。

次に、図９〜図１１により、本実施の形態のＤＲシステムにおいて、ログ読み込み・適用処理のフローの一例を説明する。それぞれ、図９は平常時（一定時間経過）、図１０は平常時（更新量超過）、図１１は切り替え時のフローの一例を示す図である。

図９の説明においては、前記実施の形態１の図４に示したログ読み込み・適用処理と異なる部分を主に説明する。

このログ読み込み・適用処理（平常時、一定時間経過）では、最初に、Ｐｕｌｌ型コピーを開始する（Ｓ９０１）。そして、再読み込みを行う場合と同様に、ログの読み込み位置の決定処理（Ｓ９０２）、ブロック（ｐｔｒ）のログ読み込み位置決定（Ｓ９０３）、を行った後、Ｐｕｌｌ型コピーを中断して（Ｓ９０４）、Ｓ１１へ移行する。Ｐｕｌｌ型コピーの中断後は、ログの読み込みに成功する限り（ヘッダ／トレイラ検証に成功する限り）、繰り返し適用を行う。

Ｓ１１へ移行したら、ＦＯ／停止指示があるか否かの判定（Ｓ９０５）、ブロック（ｐｔｒ）の読み込み（Ｓ９０６）、ブロック（ｐｔｒ）は整合性があるか否かの判定（Ｓ９０７）、を行い、整合性がない場合（Ｎ）、すなわち、読み込みに失敗し、これまでに反映済みの部分を読み込み・適用済みとなった場合はＰｕｌｌ型コピーを再開状態に変更する（Ｓ９０８）。続いて、一定時間の経過、あるいは、Ｐｕｌｌ型コピーの反映量が一定量を超過したら、再び、Ｐｕｌｌ型リモートコピーを中断状態とし、ログ読み込み・適用処理を実施する。

すなわち、Ｐｕｌｌ型コピーを再開後、時間Δｔだけｓｌｅｅｐして（Ｓ９０９）、Ｓ１０へ戻り、整合性がある場合（Ｙ）には、ブロック（ｐｔｒ−１）は未適用か否かを判定する（Ｓ９１０）。この判定の結果、未適用でない場合（Ｎ）はｐｔｒを１つ進めて（Ｓ９１１）、Ｓ１１へ戻り、未適用である場合（Ｙ）には、ブロック（ｐｔｒ−１）の適用を行い（Ｓ９１２）、ｐｔｒを１つ進めて（Ｓ９１３）、Ｓ１１へ戻る。

図１０において、ログ読み込み・適用処理（平常時、更新量超過）では、最初に、図９と同様の処理を行い（Ｓ１００１〜Ｓ１００７，Ｓ１０１３〜Ｓ１０１６）、Ｓ１００７の判定の結果、ブロック（ｐｔｒ）は整合性がない場合（Ｎ）には、時間Ｔを０にして（Ｓ１００８）、Ｓ１２へ移行する。Ｓ１２へ移行したら、ストレージに更新量を問い合わせ（Ｓ１００９）、更新量が予め定めた定数Ｐより多いか、あるいは、時間Ｔが一定時間Ｔ１を経過したか否かを判定する（Ｓ１０１０）。

この判定の結果、更新量が定数超過、あるいは、時間が一定時間経過した場合（Ｙ）はＰｕｌｌ型コピーを再開して（Ｓ１０１１）、Ｓ１０へ戻り、それ以外の場合（Ｎ）には、時間Ｔ２だけｓｌｅｅｐして（Ｓ１０１２）、Ｓ１２へ戻る。なお、時間Ｔ２に関しては、ストレージへの問い合わせ回数が多くなり過ぎることを防ぐために、２回目以降の問い合わせは、Ｔ２（＜Ｔ１）時間経過した後に行う。

図１１において、管理者から、ＦＯ／停止指示を受けた場合の処理を説明する。

このログ読み込み・適用処理（切り替え時）では、最初に、停止指示かＦＯ指示かを判定し（Ｓ１１０１）、停止指示であった場合（停止）は、ログ適用の進捗情報としてｐｔｒ情報をＤＢ状態ファイルに書き出して処理を終了する（Ｓ１１０２）。一方、ＦＯ指示であった場合（ＦＯ）には、災害ＦＯであるならばリモートコピーの状態を切断状態とし、計画ＦＯであるならば中断状態とする。すなわち、まずリモートコピーの状態制御（ｓｐｌｉｔ時）を行う（Ｓ１１０３）。

続いて、ログ適用処理を行う。最初に、Ｐｕｌｌ型コピーを停止し（Ｓ１１０４）、ブロック（ｐｔｒ））を読み込み（Ｓ１１０５）、整合性があるか否かを判定し（Ｓ１１０６）、整合性がある限りは適用処理を繰り返す。すなわち、ブロック（ｐｔｒ−１）は未適用か否かを判定し（Ｓ１１０７）、未適用でない場合（Ｎ）はｐｔｒを１つ進めて（Ｓ１１０８）、Ｓ１３へ戻り、未適用の場合（Ｙ）には、ブロック（ｐｔｒ−１）の適用を行い（Ｓ１１０９）、ｐｔｒを１つ進めて（Ｓ１１１０）、Ｓ１３へ戻る。

一方、整合性がなかった場合（Ｎ）は、まずＪＮＬ ＶＯＬに反映すべきデータがあるか否かを判定する（Ｓ１１１１）。反映すべきデータが残っている場合（Ｙ）には、Ｐｕｌｌ型コピーを再開状態にし（Ｓ１１１２）、Δｔだけｓｌｅｅｐして（Ｓ１１１３）、Ｓ１２へ戻り、ログ適用処理を繰り返す。反映するデータがなくなった場合（Ｎ）には、終端までログ適用したことを確認する（Ｓ１１１４）。ここで、計画ＦＯである場合には、逆向きのリモートコピーの設定を行う。

そして、リモートコピーの状態制御（ｔａｋｅｏｖｅｒ時）の実施後（Ｓ１１１５）、未決着なトランザクションのキャンセル処理を実施する（Ｓ１１１６）。なお、ログ適用処理で、決着トランザクションだけを適用している場合には、この処理は不要となる。全てのトランザクションが決着した状態になったら、ＤＢＭＳ状態ファイルに情報を書き出し（Ｓ１１１７）、続いて副ＤＢＭＳを起動して（Ｓ１１１８）、処理を終了する。

なお、ここでは、ブロックを１個ごとに読み込んでいるが、１度に複数のブロックを読み込んでもよい。複数のブロックを読み込んだ場合は、最後のブロック以前のブロックを適用対象として適用を行う。

次に、図１２，図１３により、本実施の形態のＤＲシステムにおいて、副ストレージのコピー処理のフローの一例を説明する。それぞれ、図１２はリモートコピー、図１３はＪＮＬ ＶＯＬからの反映処理のフローの一例を示す図である。

図１２において、副ストレージのコピー処理（リモートコピー）では、最初に、ポインタ１（ｈｐｔｒ）、ポインタ２（ｔｐｔｒ）を初期化し（Ｓ１２０１）、反映処理を開始して（Ｓ１２０２）、Ｓ１に移行する。そして、正ストレージから転送があるか否かを判定し（Ｓ１２０３）、転送がない場合（Ｎ）はＳ１へ戻り、転送がある場合（Ｙ）には、追記可能か否かを判定する（Ｓ１２０４）。この判定の結果、不可能な場合（Ｎ）はエラー処理／警告処理を行い（Ｓ１２０５）、可能な場合には、メタデータとデータを登録し（Ｓ１２０６）、ｔｐｔｒを更新して（Ｓ１２０７）、Ｓ１へ戻る。

図１３において、副ストレージのコピー処理（ＪＮＬ ＶＯＬからの反映処理）では、最初に、Ｓ１を経て、中断指示があるか否かを判定し（Ｓ１３０１）、中断指示がない場合（Ｎ）はＳ２へ移行し、ある場合（Ｙ）は続いて再開指示があるか否かを判定する（Ｓ１３０２）。この判定の結果、再開指示がない場合（Ｎ）はＳ１へ戻り、ある場合（Ｙ）にはＳ２へ移行する。Ｓ２へ移行したら、ＪＮＬ ＶＯＬからポインタ１（ｈｐｔｒ）が指すデータを被更新ＶＯＬへ反映し（Ｓ１３０３）、ｈｐｔｒを更新して（Ｓ１３０４）、Ｓ１へ戻る。

以上説明したように、本実施の形態のＤＲシステムによれば、前記実施の形態１と同様の効果（１）〜（４）が得られると共に、リモートコピーと連携した読み込みを行う方式を適用することで、ログのＩＯ単位が大きい場合であっても、再読み込み処理／リモートコピー連携処理により、不正読み込みによるＤＢ破壊を防止することが可能となる。従って、広域災害を考慮して副サイトが数百ｋｍ以上離れた構成にも対応することが可能となる。

（実施の形態３）
本発明の実施の形態３におけるＤＲシステムを、図１４を用いて説明する。

図１４により、本実施の形態におけるＤＲシステムの構成の一例を説明する。図１４はＤＲシステムの構成の一例を示す図である。

本実施の形態のＤＲシステムは、正サイトと、副サイトと、正サイトと副サイトの間を中継する中継サイトから構成される。正サイトのサーバ１００およびストレージ１２０、副サイトのサーバ１１０およびストレージ１３０は、前記実施の形態１の図１、あるいは、前記実施の形態２の図７と同様である。中継サイトは、ストレージ１３００から構成され、ストレージ制御処理部１３０１、ログ用ＶＯＬ１３０２、ＪＮＬ ＶＯＬ１３０３が設けられている。

正サイトのストレージ１２０と中継サイトのストレージ１３００との間、中継サイトのストレージ１３００と副サイトのストレージ１３０との間は、ネットワーク１３０４を通じて接続されている。正サイトのストレージ１２０内のログ用ＶＯＬ１２８から中継サイトのストレージ１３００内のログ用ＶＯＬ１３０２へは第１のコピーであるリモートコピー１３０５が行われ、副サイトのストレージ１３０内のログ用ＶＯＬ１３８と中継サイトのストレージ１３００内のＪＮＬ ＶＯＬ１３０３との間では第２のコピーであるリモートコピー１３０６が行われる。

本実施の形態のＤＲシステムにおいても、前記実施の形態１，２と同様の効果を得ることができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、ログ転送によるＤＲ技術に関し、特に、ファイルより細かい粒度でログの読み込み・適用を行い、かつ、ログの読み込み・適用処理の中で、ログの再読み込み、あるいは、リモートコピーと連携した読み込みを行うＤＲ技術に適用して有効である。

本発明の実施の形態１におけるＤＲシステムの構成の一例を示す図である。 本発明の実施の形態１において、ログファイルの構造の一例を示す図である。 本発明の実施の形態１において、ログブロックの読み込み・適用スケジュールの一例を示す図である。 本発明の実施の形態１において、ログ読み込み・適用処理（平常時）のフローの一例を示す図である。 本発明の実施の形態１において、ログ読み込み・適用処理（切り替え時）のフローの一例を示す図である。 本発明の実施の形態１において、ログ読み込み・適用処理（平常時、ＳＺ判定有り）のフローの一例を示す図である。 本発明の実施の形態２におけるＤＲシステムの構成の一例を示す図である。 本発明の実施の形態２において、ＪＮＬ ＶＯＬと格納されるデータの構造の一例を示す図である。 本発明の実施の形態２において、ログ読み込み・適用処理（平常時、一定時間経過）のフローの一例を示す図である。 本発明の実施の形態２において、ログ読み込み・適用処理（平常時、更新量超過）のフローの一例を示す図である。 本発明の実施の形態２において、ログ読み込み・適用処理（切り替え時）のフローの一例を示す図である。 本発明の実施の形態２において、副ストレージのコピー処理（リモートコピー）のフローの一例を示す図である。 本発明の実施の形態２において、副ストレージのコピー処理（ＪＮＬ ＶＯＬからの反映処理）のフローの一例を示す図である。 本発明の実施の形態３におけるＤＲシステムの構成の一例を示す図である。 本発明に対して、従来方式１を適用したシステムの構成の一例を示す図である。 本発明に対して、従来方式２を適用したシステムの構成の一例を示す図である。 本発明に対して、従来方式１を適用したシステムにおいて、ログ読み込みが正常に行えない場合の一例を説明する図である。

符号の説明

１００…サーバ、１０１…ＤＢＭＳ、１０２…ＤＢバッファ、１０３…ログバッファ、１０４…ＤＢアクセス制御部、１０５…ログ管理部、１１０…サーバ、１１１…ログ適用部、１１２…ＤＢバッファ、１１３…ログバッファ、１１４…ログ適用制御部、１１５…ログ読み込み整合性検証部、１１６…適用部、１２０…ストレージ、１２１…ストレージ制御処理部、１２２…コマンド処理部、１２３…コピー処理制御部、１２４…リモートコピー処理部、１２５…Ｐｕｌｌ型コピー処理部、１２６…キャッシュ、１２７…ディスクアクセス制御部、１２８…ログ用ＶＯＬ、１２９…ＤＢ用ＶＯＬ、１３０…ストレージ、１３１…ストレージ制御処理部、１３２…コマンド処理部、１３３…コピー処理制御部、１３４…リモートコピー処理部、１３５…Ｐｕｌｌ型コピー処理部、１３６…キャッシュ、１３７…ディスクアクセス制御部、１３８…ログ用ＶＯＬ、１３９…ＤＢ用ＶＯＬ、１４０…ＪＮＬ ＶＯＬ、１５０…ネットワーク、２００…ログ用ＶＯＬ、２０１…ログファイル、２０２…ログブロック、２０３…ログレコード、２０４…ヘッダ、２０５…トレイラ、８００…データ、８０１…メタデータ、８０２…データ、８０３…メタデータ、８０４…ポインタ１（ｈｐｔｒ）、８０５…ポインタ２（ｔｐｔｒ）、１３００…ストレージ、１３０１…ストレージ制御処理部、１３０２…ログ用ＶＯＬ、１３０３…ＪＮＬ ＶＯＬ、１３０４…ネットワーク、１３０５…リモートコピー、１３０６…リモートコピー、１４００…ＤＢＭＳ、１４０１…アーカイブログ用ＶＯＬ、１４０２…ネットワーク、１４０３…リモートコピー、１４０４…サーバ間転送、１４０５…ログ読み込み、１４０６…ログ適用、１４０７…アーカイブ、１４１１…アーカイブログ用ＶＯＬ、１５００…ログブロック、１５０１…書き込み（１）領域、１５０２…読み込み（１）領域、１５０３…書き込み（２）領域、１５０４…読み込み（２）領域、１５０５…ログ適用部に読み込まれたログブロック、１６００…アーカイブ。

Claims (4)

1. ネットワークを介して互いに接続される正サイトと副サイトとを有し、前記正サイトのストレージ装置である正ストレージは、前記正ストレージのデータベースを格納する第１のデータベース格納部と、前記正ストレージのデータベースの更新差分である第１のログ情報を格納し、前記第１のログ情報をログブロック単位で管理する第１のログ情報格納部と、を備え、前記副サイトのストレージ装置である副ストレージは、前記副ストレージのデータベースを格納する第２のデータベース格納部と、前記副ストレージのデータベースの更新差分である第２のログ情報を格納し、前記第２のログ情報をログブロック単位で管理する第２のログ情報格納部と、を備えるストレージシステムにおいて、前記正ストレージのデータベースのデータを前記副ストレージのデータベースに複製するデータベース管理方法であって、
   前記正ストレージから前記副ストレージにリモートコピーで前記第１のログ情報を転送し、前記リモートコピーで転送された前記第１のログ情報を前記第２のログ情報格納部に書き込むログ書き込みステップと、
   前記第２のログ情報格納部に前記書き込まれる前記第１のログ情報を前記ログブロック単位で読み込み、前記読み込んだ第１のログブロックを前記副ストレージのデータベースに適用するログ適用ステップと、を有し、
   前記ログ適用ステップにおいて、
   前記第２のログ情報格納部から前記第１のログ情報中の前記ログブロックである第１のログブロックの読み込みを行い、前記第１のログブロックの先頭の情報と後尾の情報の読み込みが完了したことの確認である第１の確認を行い、
   前記第２のログ情報格納部から、前記第１のログブロックに後続する前記第１のログ情報中の前記ログブロックである第２のログブロックの読み込みを行い、前記第２のログブロックの先頭の情報と後尾の情報の読み込みが完了したことの確認である第２の確認を行い、
   前記第１の確認と、前記第２の確認と、が完了したことを契機として、前記第１のログブロックを前記第２のログ情報格納部から再度読み込み、前記再度読み込んだ前記第１のログブロックを前記副ストレージのデータベースに適用する、
   ことを特徴とするデータベース管理方法。
2. 請求項１記載のデータベース管理方法において、さらに、
   前記ログ適用ステップにおいて、
   管理者やアプリケーションからの切り替え指示を受けた場合には、前記リモートコピーの状態変更を行い、新たな書き込みが生じないようにし、
   前記リモートコピーの状態変更確認後は、前記副ストレージからログブロックを読み込み、整合性を検証し、前記読み込んだログブロックを再度読み込みすることなく適用し、
   未決着なトランザクションがある場合には、未決着トランザクションに関わる更新をキャンセルすることを特徴とするデータベース管理方法。
3. ネットワークを介して互いに接続される正サイトと副サイトとを有し、前記正サイトのストレージ装置である正ストレージは、前記正ストレージのデータベースを格納する第１のデータベース格納部と、前記正ストレージのデータベースの更新差分である第１のログ情報を格納し、前記第１のログ情報をログブロック単位で管理する第１のログ情報格納部と、を備え、前記副サイトのストレージ装置である副ストレージは、前記副ストレージのデータベースを格納する第２のデータベース格納部と、前記副ストレージのデータベースの更新差分である第２のログ情報を格納し、前記第２のログ情報をログブロック単位で管理する第２のログ情報格納部と、を備え、前記正ストレージのデータベースのデータを前記副ストレージのデータベースに複製するストレージシステムであって、
   前記正ストレージから前記副ストレージにリモートコピーで前記第１のログ情報を転送し、前記リモートコピーで転送された前記第１のログ情報を前記第２のログ情報格納部に書き込むログ書き込み部と、
   前記第２のログ情報格納部に前記書き込まれる前記第１のログ情報を前記ログブロック単位で読み込み、前記読み込んだ第１のログブロックを前記副ストレージのデータベースに適用するログ適用部と、を有し、
   前記ログ適用部において、
   前記第２のログ情報格納部から前記第１のログ情報中の前記ログブロックである第１のログブロックの読み込みを行い、前記第１のログブロックの先頭の情報と後尾の情報の読み込みが完了したことの確認である第１の確認を行い、
   前記第２のログ情報格納部から、前記第１のログブロックに後続する前記第１のログ情報中の前記ログブロックである第２のログブロックの読み込みを行い、前記第２のログブロックの先頭の情報と後尾の情報の読み込みが完了したことの確認である第２の確認を行い、
   前記第１の確認と、前記第２の確認と、が完了したことを契機として、前記第１のログブロックを前記第２のログ情報格納部から再度読み込み、前記再度読み込んだ前記第１のログブロックを前記副ストレージのデータベースに適用する、
   ことを特徴とするストレージシステム。
4. 請求項３記載のストレージシステムにおいて、さらに、
   前記ログ適用部において、
   管理者やアプリケーションからの切り替え指示を受けた場合には、前記リモートコピーの状態変更を行い、新たな書き込みが生じないようにし、
   前記リモートコピーの状態変更確認後は、前記副ストレージからログブロックを読み込み、整合性を検証し、前記読み込んだログブロックを再度読み込みすることなく適用し、
   未決着なトランザクションがある場合には、未決着トランザクションに関わる更新をキャンセルすることを特徴とするストレージシステム。

Images