JP4744804B2 - 強化されたエラー検出及び復元を備えた情報複製システム - Google Patents

Description

本発明は概してデータ記憶に関し、より詳しくはデータ複製システムに関する。

本願は２００１年６月２８日出願の米国特許出願第０９／８９４４２２号の一部継続出願であり、参照として本明細書に援用する。
当技術分野で既知のように、多量のデータを処理し、記憶するコンピュータ・システムは、一般的に、データが記憶された共有データ記憶システムと通信する１つ以上の処理装置を含む。データ記憶システムは、ディスク・ドライブ等の1つ以上の記憶装置を含むことができる。データ喪失を最小限にするために、コンピュータ・システムは、主処理装置及びデータ記憶システムと通信するバックアップ記憶システムを含むことも可能である。

既知のバックアップ記憶システムは、記憶装置へデータを配置し、かつ記憶装置からのデータを復元するためのシステムとともに、（テープ記憶装置又は他の記憶機構等の）バックアップ記憶装置を含むことができる。バックアップを実行するため、ホストは、共有記憶システムからバックアップ記憶システムへとネットワークを経由してデータをコピーする。従って、実データ・ファイルはネットワークを介してバックアップ記憶装置へ送信される。

共有記憶システムは実際の物理記憶装置に対応する。ホストがバックアップ・データをネットワークを介してバックアップ記憶システムに書き込むために、ホストはまず、バックアップ・データをファイル・データに変換する。即ち、ホストは物理記憶システム・レベルからデータを読み出し、論理ボリューム・マネージャ・レベル、ファイル・システム・レベル、及びアプリケーション・レベルを経て、データをアプリケーション・レベル・フォーマット（例えば、ファイル）に変換する。バックアップ記憶装置がデータ・ファイルを受け取ると、バックアップ記憶システムはアプリケーション・レベル・データ・ファイルを取り込み、それをバックアップ記憶システムに適したフォーマットに変換する。バックアップ記憶システムがテープ・ベース装置である場合は、データはブロック又はセグメントのシリアル・フォーマットに変換される。

ＥＤＭユーザ・ガイド（ネットワーク）「ベーシックＥＤＭプロダクト・マニュアル」を含む、マサチューセッツ州、ホプキントンのＥＭＣから入手可能な多数の出版物に記載されているように、ＥＭＣデータ・マネージャ（ＥＤＭ）は、ネットワークを介してそのようなバックアップ及び修復が可能である。共有記憶システムとバックアップ記憶システムとの間で直接的な接続が確立されている典型的な従来のバックアップ記憶アーキテクチャは、本願の譲受人に譲渡された米国特許第６０４７２９４号「コンピュータ記憶システムにおける物理バックアップからの論理修復」に記載され、参照として本明細書に援用する。

大規模データベースに対して、公知技術のテープ・ベース・データ・バックアップ及び修復システムを利用することができる。一般的に、ファイル及びデータベース等は選択された時間にテープ・メディアにコピーされる。概して、ソフトウェア・エラー、人的エラー、ハードウェアの不具合に起因するデータの喪失を防止するために、データは定期的にバックアップされる。オンライン・データベースでエラーが検出された場合は、例えば、バックアップされたデータを修復してデータを復元することができる。修復はバックアップされたデータを入手することに言及し、データ復元は、アプリケーションが読み出されたデータにアクセスして利用することが可能な全体の処理に言及する。バックアップ後のトランザクションは、所謂リドゥ（ｒｅｄｏ）・ログを利用して再生される。

テープ・ベース・バックアップ及び修復システムには多数の不都合がある。例えば、テープに対してデータをバックアップし、修復することに関係する多くの時間及び負荷に起因して、そのような動作は比較的稀にしか実行されない。例えば、エラーの発生したポイントを決定することがより困難になる等の理由により、バックアップと修復との間隔が長くなれば長くなるほど、全体の復元処理がより複雑となり、かつその処理に費やす時間が増加する。加えて、より速いテープ・アクセス・タイム等のデータ修復処理における改良を行うことにより、全体的なデータ復元処理の付加的な進展のみが提供される。

更に、テープ上のデータは、それがディスクに修復されるまでアクセスすることができない。データが修復されたときだけ、ホスト・コンピュータはデータを検査することができる。データをテープとディスクとの間の各移行に対して再フォーマットしなければならず、このことで、かなりの処理リソース及び経過時間が必要となる。

テープ・ベース・データ記憶システムに関係する更なる不都合は、データ復元処理それ自体に関係する。例えば、エラー発生後、データベース管理者等のオペレータは、エラーを的確に発見しようとエラーを評価する。しかしながら、管理者はテープ・ベース記憶装置の性質により賦課された制限を処理しなくてはならない。大規模なミッション・クリティカル・データベースにとっては、データベースが停止して、テープから修復を実行することは非常に高価である。もし可能であるならば、管理者はデータベースを修理することを試みるであろう。しかしながら、データベース全体が壊れること、付加的なエラーが発生すること、及びエラーの訂正に失敗することのリスクはかなりのものである。

加えて、いつデータベースが壊れたかが常に分かるわけではない。データがテープから修復されるべきケースでは、エラーの訂正は、反復的かつ時間のかかる処理となる。管理者は修復のために第１の組のテープを選択した後、エラーが訂正されたかどうかを決定するためにデータベースを検査することができる。訂正されていない場合は、通常は、より以前のパックアップである別の組のテープが修復されるべきである。データ検査ステップはエラーが訂正されるまで実行される。

１度エラーが訂正されても、過去のバックアップ・トランザクションがリドゥ・ログからデータベースに加えられるのに伴って、エラーがデータベース内へ再び導入される可能性がある。エラーが発生したポイントは識別されなければならない。反復的なテープ修復及びエラー識別にかかる時間及び労力はかなりのものとなり得る。

エラーを識別するための既知の試みでは、所謂データ・スクラッビング・ツールを含む。定期的に実行可能なこれらのツールは、可能な限りエラーを検出する目的で利用される。このようなツールはエラーを検出するかもしれないが、インターネット・ベースのベンダによって使用されるような多数のプロダクション・データベースはミッション・クリティカルであり、そのようなツールに要求されるローディングに対処できない。多くのアプリケーションでは、データ・スクラッビング・ツールは実用的なオプションではない。

加えて、データベースの一部だけを復元させることが望ましいときがある。しかしながら、既知のシステムでは、データベース全体に満たないものを容易に復元することはできない。データベースの一部が、従来のデータ・バックアップ及び修復システムで可能であったとしても、データベースの一部を手動で復元することについては高度な技術が要求される。

従って、上記及び他の不都合を克服することが望まれる。

本発明は、従来のデータ・バックアップ・システムと比較してエラー検出及び訂正を十分に強化し、マウント可能なデータ・ボリュームの複製を有するデータ復元システムを提供する。本発明をデータベースの復元に関連して示し、記載するが、本発明は、格納されたデータからエラーを検出し、除去することが所望される場合に、他のシステムに適用可能であることが理解されよう。

本発明の一態様では、情報復元システムは１つ以上のオリジナル・データ・ボリュームを複製し、複製された若しくはオリジナルのデータ・ボリュームの完全性を検査する。エラーを検出した場合は、システムは、修理及び／又はデータ修復によりエラーを訂正するために利用される。エラー検出が成功した後、エラーの存在するボリュームを訂正することができる。

本発明の更なる態様では、情報復元システムは、１つ以上の選択された表スペース等の部分的データベースの複製をマウントすることを提供する。このシステムを用いて、ユーザはオリジナル・データベースの複製から復元のための表スペースを選択することができる。一実施形態では、様々なモードで部分的なマウンティングを開始可能である。

本発明の別の態様では、情報復元システムは自動化された複製の記憶構成（ｓｔｏｒａｇｅ）の選択を提供する。この機能により、情報復元システムは、データベース管理者が手動で記憶構成を識別する必要性がなくなるように、存在するデータベース等のデータ・ボリュームを複製すべく利用可能性のある記憶位置を自動的に発見し、予め決定された要求に合致する記憶構成を選択する。本発明を主に、オラクル・データベース等のデータベースをディスクへ複製することに関連付けて示し、記載するが、その後の修復のためにデジタル情報を種々の複製技術によりバックアップすることが所望される場合は、本発明を一般的な記憶システムに適用することができる。

一実施形態では、ＩＲサーバは、複製されることを要求された、ＢＣＶ等の可能性のある複製の記憶構成の位置、スタンダード・ボリューム等のプロダクション・データ・ボリュームのリストを得る。ユーザは、ユーザにより以前に構成されたＢＣＶ記憶構成のように、あるＢＣＶが特定の基準を持つべきであることを決定することができる。そして、システムは各スタンダード・ボリュームに対して可能性のあるＢＣＶを選択し、各スタンダード／ＢＣＶペアを評価する。一実施形態では、ペア・スコアは、スタンダード／ＢＣＶペアに対して、ディスク・スピンドル、バス等のリソースの競合のレベルに基づいて決定される。リソースを、リソースの競合に起因する機能低下のレベルを反映して重み付けすることができる。グループ・スコアは受入可能な記憶構成の解決方法が発見されたかどうかを評価するためにペア・スコアから決定される。

ＢＣＶ、スタンダード・ボリューム等の特定の専門用語は本発明の理解を円滑にするために使用されているのであり、本発明を限定するものと解釈すべきではないことが理解されよう。

概して、本発明の情報復元システムは、データベース及びメール・システム等の論理オブジェクトを複製し、複製されたオブジェクトを即座に、即ち基本的な記憶技術サポートと同等の速さで修復する性能を利用者に提供する。本発明を、主に、マサチューセッツ州、ホプキントンのＥＭＣコーポレーションによるシンメトリックス（Ｓｙｍｍｅｔｒｉｘ）として知られる典型的な記憶技術に関連して示し、記載するが、本発明は多種の記憶技術及びオペレーティング・システムに適用可能である。

一実施形態では、情報修復システムは、オラクル及びＳＱＬサーバ・データベース等の各種データベースを対象とする。システムにより、ユーザは、複製のために、例えば１つ以上の表スペースといったデータベース又はその一部を構成できるようになる。構成されたデータベースの一部は、複製オブジェクト（ＲＯ）と呼ばれる。即ち、ＲＯは複製されるべきアプリケーションを記述する。各ＲＯに対して、１つ以上の作業（Ａｃｔｉｖｉｔｉｅｓ）が、ＲＯの複製がどのように実行されるべきであるかを記述する。典型的な情報は、例えば、オンライン又はオフライン、プリ及びポスト・スクリプト、マウンティング及び復元オプション、及び記憶構成の選択基準といった、データベースとやり取りする方法を含む。作業は、要求に応じて若しくは予定された所定の時間に実行される。どこで、どのようにというようなマウンティングの詳細を作業の作成の間に規定することが可能である。

システムは様々な方法で作業のための記憶構成を選択できる。例えば、システムは、自由な若しくは以前に確立された記憶ビジネス・コンティニュアンス・ボリューム（ＢＣＶ）を探索可能である。ここで用いられるように、ビジネス・コンティニュアンス・ボリュームは、データベースの一部であるスタンダード・ボリュームのミラーのことをいう。また、ユーザはＢＣＶの属性を定義して、記憶プールを作成し、作業の属性に基づいて記憶構成を選択することができる。ユーザはＢＣＶをスタンダード装置（ＳＴＤ）に明示的に割り当てることも可能である。

図１は、本発明に従う典型的な情報修復システム１００を示す。永続的記憶装置１０４を含むＩＲサーバ１０２は、デスクトップ・マシン１０８上のＩＲユーザからの作業要求を処理する。ウェブ・サーバ１０２ａは、ローカル・エリア・ネットワーク（ＬＡＮ）１０６へのインターフェースを備え、例えば、ユーザ・デスクトップ・マシン１０８との通信を可能にする。ユーザ・デスクトップ・マシン１０８は、例えば、ブラウザ１０８ａ及び／又はコマンド・ライン・インターフェース（ＣＬＩ）１０８ｂ及びＩＲアプリケーション１０８ｃ等のユーザ・インターフェースを含むことができる。ＩＲサーバ１０２は、個々のアプリケーション・ホストから利用可能である記憶エリア・ネットワーク（ＳＡＮ）１１０内の記憶ユニット１１０ａに対して複製作業を制御、調整するＩＲ複製ポリシー・マネージャ１０２ｂもＩＲデーモン１０２ｃ内に含む。ＩＲサーバ１０２は、任意の複製のためにどの記憶構成を使用するかについての決定を実行することができるように、各サポートされた複製技術のための複製ポリシー・マネージャ又はエンジン１０２ｂも含むことができる。一実施形態では、ポリシー・エンジン１０２ｂはＩＲデーモンとリンクされたダイナミック・ライブラリとして提供される。存在する複製及び対応する記憶構成に関する定常状態の情報は、ＳＱＬサーバ・データベースとして提供可能なＩＲデータベース１０４内に記憶される。

システム１００はアプリケーション・エージェント１１２ｂ及び記憶サービス・モジュール１１２ｃを介してクライアント・コントロール１１２ａ下にあるアプリケーション・ホスト１１２、例えば、オラクル・データベース・サーバ・ホストを更に含む。ＩＲアプリケーション・クライアント内のアプリケーション・エージェント１１２ｂは、記憶エリア・ネットワーク１１０内に存在するユーザ・データベースを処理する。デーモンとして提供可能なこのクライアント・コントロール・モジュール１１２ａはクライアント操作を処理し、ディスパッチする。各サポートされたアプリケーションのためのアプリケーション・エージェント１１２、例えばプラグイン、は仕事要求を処理する。ＩＲアプリケーション・クライアント１１２は、サード・パーティーの製品を駆動して、例えばユーザ・データベースの複製をバックアップするためにコール・アウトを介してサード・パーティー・ベンダと通信することも可能である。複製をマウントするのに使用されるホストを、アプリケーション・ホスト１１２とすることも可能であることが理解されよう。

３つの別々のホストとして示されているが、１以上のユーザ、アプリケーション・クライアント及びＩＲサーバが単一のホスト又はマシン上に存在可能であることが理解される。本実施形態、アーキテクチャ及び構成が、本発明から逸脱することなく、特定用途の要求を満たすように当業者により容易に変更可能であることが理解されよう。

図２に、本発明に従う情報復元システムのためのＩＲコントロール・パネルの典型的なスクリーン・ディスプレイ１５０を示す。ディスプレイ１５０は、例えば、ユーザ、アプリケーション・ホスト、アプリケーション、記憶構成、スケジュール、及び複製オブジェクト（ＲＯ）等のＩＲシステムのオブジェクト１５２の階層を含む。図示のディスプレイでは、「パーツ ＤＢ／ＴＳ１／ＴＳ２」１５４と名づけられた複製オブジェクトが展開されて、この複製の作業１５６及びインスタンス１５８が表示されている。作業は「ジュニパー上にＣＫＰを作成」項目１６０ａ、「災害ＣＫＰ」項目１６０ｂ、及び「通常の予定」項目１６１ｃを含む。インスタンス１５８は、ＲＯに関して作成されたチェックポイント又は複製を表示する。

概して、ホスト及びアプリケーションはインストール時にシステムに対して利用可能となる。ホスト及びアプリケーションがインストールされたとき、それらはＩＲデーモン・データベースに登録される。

図３に、新規の複製オブジェクト（ＯＲ）を作成するための、実例のスクリーン・ディスプレイ２００を示す。新規の複製オブジェクトを作成するために、ユーザはプル・ダウン・メニューを作動し、「ファイル」、「新規」、「複製オブジェクト」を選択して新たなＲＯディスプレイ２００に到達する。そして、ユーザは、アプリケーション・ホスト領域２０２ａにおけるアプリケーション・ホストを特定し、インストールされたアプリケーション・ホストのＩＲデーモン・データベースからの情報に基づいて構成されるべきアプリケーションをアプリケーション領域２０２ｂから特定する。任意のホスト及びアプリケーションに対して、アプリケーションの各インスタンスがインスタンス領域２０２ｃに表示される。ユーザはインスタンスを選択し、名前領域２０２ｄにおいて、新規の複製オブジェクトへ名前を割り当てる。

付加的なスクリーン・ディスプレイ（図示せず）は、ユーザに付加的な情報を問い合わせることができる。例えば、付加的なスクリーン・ディスプレイは、データベースのどの部分、例えばデータベース全体、オラクル・データベースの表スペース等、をバックアップするかということとともに、データベースへのアクセスの方法（ユーザ名及びパスワード）といった複製オブジェクトに関するアプリケーション特有の情報をユーザに催促することができる。別のスクリーン・ディスプレイは、ユーザがＲＯに対する作業を作成することを可能にする。個別に若しくは特定時間に対して計画的に実行可能な多数の作業が存在し得る。より詳細には、作業では定期的に指定された複製が提供され、決定支援データベースが作成され、災害復元が支援される。

一実施形態では、複製又はチェックポイントは満了期間、即ち、複製の有効時間を有する。ユーザは、チェックポイント（複製されたデータベース）がマウントされることが見込まれるかどうかを指示できる。この情報は複製技術（ＲＴ）選択時に要求されてもよく、この理由は、全ての複製技術がチェックポイントのコピーをマウント可能であるわけではないからである。上記したように、記憶の選択を定義するとき、ユーザは、複製技術を選択することが可能であるか、若しくはシステムがＲＴを選択できるようにすることが可能である。

加えて、各作業に対して、ユーザは、マウント、記憶及びアプリケーションに固有の属性をもたせることができる。マウント属性は、マウントされたときに、オブジェクトに何をさせるべきかを規定し、例えば、データベースを復元すること、検査プログラムを実行すること、及びテープ・バックアップを行うことが挙げられる。記憶属性は複製を行うためにどの記憶構成が使用されるべきかを規定する。アプリケーション属性は、いつ複製が実行されるか、アプリケーション特有の実行する必要があるものは何であるか、例えば、データベースをオンライン・バックアップ・モードにすること、データベースをシャット・ダウンするためにユーザ・スクリプトを使用すること等を規定する。

複製オブジェクトに関するマウント・オプションを選択することにより、ユーザは、複製がなされた後に複製に対して行われるべきことを指定することができる。ユーザが複製をマウントすることを手動で選択した場合は、この同じセットのオプションがユーザに対して表示される。ユーザが持つ一つのオプションは、複製をマウント及び修復するかどうか、及びそれをどこで利用可能にするかである。作業を実行することは複製をマウントすることを含み、複製の全部又は一部をマウントすることができる。

アプリケーションがどのようにマウントされるべきかを選択した後、ユーザは、アプリケーションに関係して行うこと、例えば、どのプログラムを実行するかを選択すること、バックアップを実行すること、完了後にアプリケーションをマウントすること等を選択できる。複数のプログラム又はバックアップを実行するように選択可能である。マウント解除はアプリケーションを停止することと、ターゲット・オペレーティング・システム上で複製を使用可能にするために作成されたあらゆる記憶リファレンスを削除することとを含む。

属性を割り当てることにより、若しくはスタンダードを複製の記憶構成に明示的に関係付けることにより、記憶構成をＩＲシステムに明示的に知らせることができる。一つの特定の実施形態では、定義属性記憶構成スクリーンにおいて、ユーザには、クライアント・マシンに搭載されたデータ記憶装置、例えばシンメトリックスに存在したＢＣＶのリストが提供される。ユーザは１つ以上のＢＣＶを選択し、それに属性を割り当てることが可能である。

本発明に従うデータ記憶システム３０２を含む情報復元システム３００の更なる詳細を図４に示す。一実施形態では、（図１の記憶エリア・ネットワーク１１０に配置可能な）データ記憶システム３０２はマサチューセッツ州、ホプキントンのＥＭＣコーポレーションから入手可能なシンメトリック・インテグレイテッド・キャッシュ・ディスク・アレイ（Ｓｙｍｍｅｔｒｉｘ Ｉｎｔｅｇｒａｔｅｄ Ｃａｃｈｅ Ｄｉｓｋ Ａｒｒａｙ）システムをベースとすることが可能である。そのようなデータ記憶システム及びその実施例は、２０００年８月８日発行の米国特許第６１０１４９７号、１９９３年４月２７日発行の米国特許第５２０６９３９号に詳細に記載されており、それらは本発明の譲受人であるＥＭＣに譲渡されており、本明細書において参照として援用する。

概して、ローカル・ボリュームはビジネス・コンティニュアンス・ボリューム（ＢＣＶ）に複製される。ミラーリングを採用しているローカル・システムは、本明細書で援用された‘４９７特許にも記載されているバックアップを実行しつつ、プロダクション・ボリュームへのアクセスを可能にする。。データ記憶システム３０２はシステム・メモリ３０４と、組の若しくは複数の、多重データ記憶装置又はデータ記憶装置３０６ａ，ｂとを含む。典型的な実施形態では、システム・メモリ３０４はバッファ又はキャッシュ・メモリを含む。記憶装置３０６は、ディスク記憶装置、光学記憶装置等からなる。しかしながら、典型的な実施形態では、記憶装置はディスク記憶装置である。記憶装置３０６は、種々の既知の構成を有する記憶装置のアレイに相当する。

ホスト・アダプタ（ＨＡ）３０８ａ，ｂはホスト・システム３１０ａ，ｂとシステム・メモリ３０４との間の通信を提供し、ディスク・アダプタ（ＤＡ）３１２ａ，ｂはシステム・メモリ１１４と記憶装置のセット３０６ａ，ｂとの間の経路を提供する。バス３１４は、システム・メモリ３０４、ホスト・アダプタ３０８及びディスク・アダプタ３１２を相互接続する。各システム・メモリは、情報を伝送してそれぞれのホスト・アダプタ及びディスク・アダプタ間で相互に作用すべく、各システム内の各種素子により使用される。

任意のバックアップ記憶システム３５０をデータ記憶システム３０２に接続可能である。バックアップ記憶システムは、ＥＭＣコーポレーションから入手可能であり、シンメトリック・コネクト・ユーザ・ガイド、Ｐ／Ｎ２００−１１３−５９１、Ｒｅｖ．Ｃ、１９９７年１２月に記載されているようなデータ記憶システムと接続されたＥＭＣデータ・マネージャ（ＥＤＭ）として提供可能である。共有記憶システムとバックアップ記憶システムとの直接的な接続は、例えば、ＳＣＳＩケーブル又は１つ以上のファイバ・チャネル・ケーブル等の高速データ・チャネル３５２により提供される。本システムでは、ネットワーク又は直接接続を介してデータをバックアップすることをユーザが許可してもよい。

バックアップ・システム３５０はバックアップ／修復サーバ３５４と、サーバの一部としてのロジック３５６と、好適なＥＤＮシステムで利用可能なようにデープ・メディア（図示せず）及びロボティック・ピッカー・メカニズム（図示せず）を含み得るテープ・ライブラリ・ユニット３５８とを含む。

データ記憶システム３０２は、ホスト・アダプタ３０８を介したホスト・システム１１３からの命令に応答して動作する。ホスト・アダプタ３０８は、システム・メモリ３０４の一部であるコマンド・バッファに命令を伝達する。コマンド・バッファはデータ構造を記憶し、ディスク・アダプタが生成する要求を書き込む。ディスク・アダプタ３１２は、コマンド・バッファ内の情報を用いて対応する動作を有効化することにより応答する。そして、選択されたディスク・アダプタはデータ処理を開始する。ホスト・システム１１３がデータ書き込み動作を開始すると、読み取り動作では、データが記憶装置３０６ａ，ｂからシステム・メモリ３０４へ、対応するディスク・アダプタ３１２ａ、ｂを介して伝送され、その後、データがシステム・メモリ３０４から対応するホスト・アダプタ３０８ａ，ｂへと伝送される。

コンピュータ・ホスト・システム３１０はいずれの従来のコンピューティング・システムでもよく、各々がオペレーティング・システム、例えばサン・マイクロシステムから入手可能なシステム等を備えてもよく、各ホスト・システムはソラリス・オペレーティング・システム（Ｕｎｉｘのバージョン）、ＨＰ−ＵＸ（Ｕｎｉｘオペレーティング・システムのヒューレットパッカード・バージョンを実行するヒューレットパッカード・クライアント）を実行するＨＰシステム、又は、ＡＩＸオペレーティング・システム（ＵｎｉｘのＩＢＭバージョン）を実行するＩＢＭシステム又はＷＩＮＤＯＷＳ ＮＴオペレーティング・システム等の関連するオペレーティング・システムを含む他のシステムを実行してもよいことが理解されよう。上記したように、記憶システムは、シンメトリックス記憶システムを含む、どの従来の記憶システムでもよい。

本発明の理解に有用な概念及び当技術分野の既知の技術に関する簡単な説明を行う。物理ディスクは、ＥＭＣより入手可能な論理ボリューム・マネージャ（ＬＶＭ）等のマネージメント・ソフトウェアによる利用のために、「物理ボリューム」にフォーマット化される。各物理ボリュームは、物理パーティションまたは物理拡張と呼ばれる別個の塊に分割される。物理ボリュームは「ボリューム・グループ」に組合わされる。従って、ボリューム・グループはディスクの集合であり、１つの大きな記憶領域として扱われる。「論理ボリューム」は、単一のボリューム・グループから割り当てられたいくつかの物理パーティション／拡張からなる。「ファイルシステム」とはファイル構造又はファイル集合に言及する。

以下に、援用された‘４９７特許を参照した、より詳細に理解され得る他の有用な技術について簡単に説明する。ミラーが「確立」されたとき、データ記憶システム１１９はソース又はスタンダード・ボリュームの、ミラー・イメージ（コピー又は複製）を作成する。好適なシンメトリックスを使用した場合、そのようなミラーは、ビジネス・コンテニュアンス・ボリューム（ＢＣＶ）として示され、また、一般的な言葉ではミラー化されたディスク、そして、このようなコンテキストではＢＣＶ装置と呼ばれる。スタンダード・ボリュームのデータが変更される場合は、同一の変更がミラーされたディスクに即座に適用される。

ミラーが「分割」されたとき、シンメトリックス・データ記憶システムはディスクのミラー化されたバージョンを独立させ、ミラー化されたボリュームにはそれ以上の変更を適用しない。分割完了後、プライマリ・ディスクは変更され続けるが、ミラーは分割されたときに存在したその時点の時間データを保存する。ミラーはどちらかの方向（即ち、ＢＣＶからスタンダードへ、若しくはその逆）で「同期」可能である。例えば、ミラーへの分割後に発生するスタンダード・ボリュームからの変更は、ＢＣＶ又はミラー化されたディスクに適用することができる。このことにより、ミラーされたディスクが現在のスタンダード・ボリュームと同期する。他の方法で同期される場合は、プライマリ・ディスクをミラーに一致するようにすることが可能である。これは、しばしば、修復の最終ステップで行われる。

ＢＣＶ装置と、その対応する１つ又は複数のＢＣＶボリュームとの動作は、論理ボリュームに記憶されたデータ・セットという形でより容易に理解され、本発明の理解に役立つ。いずれかの任意の論理ボリュームは、１つの物理ディスク・ドライブの一部若しくは全体、又は２つ以上のディスク・ドライブに記憶される。

図５に示すように、本実施形態では、一連の物理ディスクの動作は論理ボリュームという形でで制御される。物理ディスクを論理ボリュームへとセグメント化又はハイパー化することは当該技術分野で公知である。ディスク・アダプタ（図示せず）は、データ記憶システム・バスのインターフェースとなる論理ボリューム３６０とインターフェースをとる。これらボリューム３６０の各々は、ビジネス・コンティニュエイション・ボリュームとして定義され、ＢＣＶ装置として指定される。各ＢＣＶ装置は、スタンダード・ディスク・コントローラと、アプリケーションを独立にサポートして処理するように構成された、関連するディスク記憶装置とを備える。これらＢＣＶ装置の利用により、以後「ソース」ホスト・コンピュータ・システムとして記載するホスト３１０ａ等のホストは、スタンダード・ボリューム３６２内のデータの瞬間コピーを利用できるようになる。従来の処理では、データ・セットを同時に処理する各ホスト装置に割り当てられた少なくとも１つのＢＣＶボリュームが通常、存在する。しかしながら、以下に説明するように、１つのホストによる使用のために確立されたＢＣＶボリュームは、以後「ターゲット」ホスト・コンピュータ・システムとして記載するホスト３１０ｂ等の別のホストによって利用されてもよい。

ソース・ホスト３１０ａは、スタンダード・ボリューム３６２へ影響又は負荷を与えることなく、オンライン・トランザクション処理（データベース・トランザクション処理等）又は他の処理を継続してもよく、ＢＣＶ３６０上のその個々のミラー・イメージは、バックアップ・システム３０２と共同して、データのバックアップに利用される。しかしながら、ＢＣＶは、全工程でオペレータの介入を要求するというよりは、概ね自動的にコンピュータ・プログラムの制御下にある、別のホストでの利用のために確立されてもよい。

バックアップのためのデータ・フローの方向は、矢印３６４により示されるように、データ記憶システム３０２からバックアップ・システム３５０へというものである。修復のためのデータ・フローの方向は、反対方向であるデータ記憶システムへというものであるが、ＢＣＶ３６０は、本発明の方法に従って当初に確立されたもの以外の別のホストにマウントされてもよい。

ＥＤＭシステム等の任意のバックアップ・システム３５０は、バックアップ又は修復の前後にミラー動作を制御するための複数のオプションを提供する。ミラー・ポリシーは当業者にとって周知である。典型的なプリ・バックアップ・ミラー・オプションは、ミラーを停止すること、ミラーが停止していることを確認すること、必要な場合はミラーを停止すること、及び確立後にミラーを停止することを含み、ポスト・バックアップ・オプションは、ミラーを起動すること、ミラーを停止状態にしておくこと、及びミラーをそのままにしておくことを含む。

システムは、１つ以上のデータ・ボリューム（スタンダード・ボリューム）のコピーである１つ以上のミラー化されたデータ・コピー（ＢＣＶ）を確立する。ＢＣＶは援用された‘４９７特許に記載されたように従来の方法で確立される。ＢＣＶは、従来の方法で、各１つ以上のデータ・ボリュームから分離若しくは分割され、そのことについても、援用された‘４９７特許に記載されている。

システムは、ソース・コンピュータ・システム３１０ａ上のボリューム・グループの一部であるスタンダード・ボリュームに関する論理情報を発見する。ソース・コンピュータ・システム上の物理装置に対する論理情報のマップが作成される。一実施形態では、マップをＸＭＬメッセージとして提供できる。あるいは、マップは、論理情報の迅速な検証のためのツリー構造に変換可能なフラット・ファイルの形式をとる。マップは、好ましくは論理情報が論理情報のツリー構造の構成を用いて検証された後で、ターゲット・コンピュータ・システム３１０ｂ上に実質的に同一な論理構成を構築するために利用される。

論理構成はＢＣＶの複製をターゲット・コンピュータ・システム上にマウントするために利用される（マウントされたターゲットＢＣＶとして示される）。そして、新規にマウントされたターゲットＢＣＶはターゲット・コンピュータ・システム３１０ｂ上の第２ボリューム・グループの一部となる。

データ伝送に先立って、バックアップ・システムは一連の機能を実行する。発見／マッピング機能はソース・ホスト３１０ａ上の論理対物理装置を発見してマップを作成し、かつ、物理及び論理ボリューム、ボリューム・グループ、及びファイル・システム情報等の情報を含む。確立／分割機能は、ソース・ホスト３１０ａで有効なプリ及びポスト・ポリシーに依存して、ＢＣＶを確立する、若しくはスタンダード・ボリュームからＢＣＶを分割する。

構築／マウント機能は、ソース・ホスト３１０ａで確立されたＢＣＶをターゲット・ホスト３１０ｂへエクスポートする。これにより、ボリューム・グループ、論理ボリューム、及びファイル・システム・オブジェクトがターゲット・ホスト・コンピュータ・システム上に作成される。

任意のバックアップ／修復機能は、ソース・ホストからエクスポート若しくは移動されたターゲット・ホストＢＣＶデータのバックアップを実行する。マウント解除／クリーンアップ機能は、全てのボリューム・グループ、論理ボリューム、及びファイルシステム・オブジェクトをターゲット・ホストから削除する。

全体的な複製マウント処理の概要を図６に示す。ステップ４００では、システムはソース・ホスト上の論理対物理装置をマップする。ステップ４０２では、ロジックは、ソース・ホストで有効なミラー・ポリシーに従って、スタンダードをＢＣＶへと構築し、その後に分割する（これはデータ記憶システムの別の機能への要請により行われてもよい）。ステップ４０４では、システムはターゲット・ホスト上で構築及びマウントを行い、ＢＣＶがターゲット・ホストへエクスポート若しくは移動される。ステップ４０８はクリーンアップ・ステップであり、全てのボリューム・グループ、論理ボリューム、及びファイル・システム・オブジェクトがターゲット・サーバから削除される。

マッピング及び発見処理のステップの概要を図７に示す。ステップ５００では、発見／マッピング処理がソース・ホスト上で開始される。ステップ５０２では、ファイルシステムがソース・ホスト上で発見され、ステップ５０４では、論理ボリュームが発見される。ボリューム・グループ情報は、ステップ５０６において、ソース・ホスト上で発見される。ステップ５０８では、マップが、情報をコンパイルし、利用するために、フラット・ファイル、又は他の比較的有効なデータ構造として作成される。

図８に示すように、一実施形態では、ステップ６００において、フラット・ファイルに対応可能な、発見された論理ボリューム情報がツリー構造を作成するのに利用される。この構造は、上記のマッピング・ファイル内の情報からのｕｎｉｘ機能コール（ｃａｌｌ）により構築可能である。それは、ターゲット・ホスト・コンピュータ・システム及びソース・ホスト・コンピュータ・システムの両方で構築されてもよい。それがツリーと呼ばれる理由は、ボリューム・グループ情報はツリーの根として位置付けられ、枝がグループ内の装置情報及びグループ内の論理ボリュームを表すからである。ステップ６０２で、マップ・ファイルがターゲット・ホストへ送信される前に、マップ・ファイルの正確さを検証するためにツリー構造が利用される。ステップ６０４で、ツリーは、マップ好ましくはフラット・ファイル、として変換される。そして、ステップ６０６で、このフラット・ファイル・マップはターゲットに返信される。

あるいは、発見はＥＭＣデータ・マネージャ（ＥＤＭ）により実行されるものと類似の方法でもよく、それは当業者にとって周知である。一実施形態では、マップはＸＭＬメッセージとして送信される。

図９に示すように、バックアップ・システムを用いた確立／分割の処理はステップ７００で開始される。もし存在するのであれば、ミラー・ポリシーがステップ７０２でチェックされる。ステップ７０４で問い合わせが提起され、ミラー・ポリシーに従ってＢＣＶが確立されているかどうかが判断される。答えがノーの場合はステップ７０６でＢＣＶが確立される。ステップ７０８で、ＢＣＶがソース・ホストから分割される。ステップ７１０で、ＢＣＶがホストに対して準備されていないものとされる。

図１０に示すように、ＢＣＶがターゲットにマウントされる、論理情報の構築／マウントの開始の処理がステップ８００で開始される。ステップ８０２で、ボリューム・グループがターゲット上に作成される。ステップ８０４で、論理ボリュームがターゲット上で検証される。ステップ８０６で、ファイルシステムがターゲット上でチェックされ、活性化される。ステップ８０８で、装置マウントが、ターゲット・ホスト上のＢＣＶに関係するこの論理情報を用いて直ちに完了されてもよい。

図１１に示すように、ステップ９００で、新規にマウントされたターゲットＢＣＶが、直ちに任意的にテープにバックアップされてもよい。ステップ９０２で、アプリケーションがターゲット上で停止される。そして、ターゲットＢＣＶのバックアップに続いて、クリーンアップ・ステップ及び通知がステップ９０４で実行される。

ソース・ホスト内のターゲット・ホスト上のソフトウェア・アプリケーションがデータベースである場合は、データに関係する情報もバックアップしてもよく、結果として、基本的にデータベース全体がバックアップされる。データベースからの重要な情報は、データベース処理により行われるするあらゆるトランザクション・データ、及び関係するコントロール・ファイル、表スペース、及びアーカイブ／リドゥ・ログを含む。

データベースに関連して、これから更なる専門用語を明確にする。オラクル・データベースに関する専門用語を使用するが、当業者は、本発明を逸脱することなく他のデータベースを利用してもよいことを認識するであろう。

コントロール・ファイルは、データファイル及びログ・ファイルが存在するインスタンスを記述する情報を含むオラクル・データベースに関する情報を含む。データファイルはオペレーティング・システム・ファイルシステムのファイルであってもよい。表スペースは、オラクル・データ記憶構造の最も低い論理層である。表スペースは１つ以上のデータファイルを含む。表スペースは、データをデータファイルに配置するのに最良の精度を提供する。

データベース内には、リドゥ・ログ・ファイル又は単にリドゥ・ログとして知られるアーカイブ・ファイルが存在する。これには復元されるべき全情報が保存されている。リドゥ・ログ・ファイルがない場合は、システム障害によってデータが復元不能となるであろう。ログ・スイッチが発生するとき、アーカイブすることが可能な場合は、満杯のリドゥ・ログ・ファイル中のログ・レコードはアーカイブ・ログ・ファイルにコピーされる。

図１２に示すように、ソース・スタンダード・ボリュームを修復するための処理は、任意のバックアップ・システムに対して、ステップ１０００で開始される。ステップ１００２では、システムは質問を提起して、修復がターゲットのＢＣＶからなされるべきか、若しくは他のどこかからなされるべきであるかを決定する。その回答に従って、例えば、ステップ１００４又は１００６において、スタンダード・ボリュームは、ＢＣＶがマウントされたターゲット又はテープと同期する。ステップ１００８では、図１１で概して説明される通知及びクリーンアップ・ステップが開始される。

図１３に示すように、クリーンアップ／マウント解除処理はステップ１１００で開始する。ステップ１１０２で、ＢＣＶはターゲットからマウント解除される。これは例えば、ＵＮＩＸマウント解除コマンドを用いて行われてもよい。ステップ１１０４及び１１０６では、ボリューム・グループ、論理ボリューム、及びファイルシステムに関係するオブジェクトがターゲットから削除される。クリーンアップはステップ１１０８で完了する。ステップ１１０８で、ＢＣＶはソース上に再確立される（即ち、ホストの準備がなされる）。

本発明に従う情報復元システムのための典型的なチェックポイント又は複製スケジュールを図１４に示す。８：００頃に、先に詳述したように、例えばオラクル・データベースを含むスタンダード・ボリュームＳＴＤが、対応するＢＣＶ ＣＨＫＰ Ａに複製される。１２：００に、次に予定されたチェックポイントが発生して、スタンダード・ボリュームが更なるＢＣＶ ＣＨＫＰ Ｂに複製される。１：００頃に、例えばデータ・スクラッビング・ツールによりエラーが検出され、２：００頃に、ある評価期間の後、スタンダード・ボリュームがオン・デマンドＢＣＶ ＣＨＫＰ ＯＤに複製される。エラーが訂正されてスタンダード・ボリュームＳＴＤが最新であるならば、次のＢＣＶ ＣＨＫＰ Ｃに対する４：００のチェックポイントは予定通りに発生する。上記したように、更なるオン・デマンド・チェックポイントを必要に応じて発生させることが可能である。

本発明に従う、データベース内のトランザクション・エラー等のデータ・エラーから復元を行うための典型的な処理を図１５に示す。データ・エラーが時刻ｔ_eに発生した後、エラーが潜伏した状態で、即ちデータベース管理者等のシステムオペレータが知らない状態で、システムが時間ＴＬＥの間稼動する。当業者にとって周知であるように、ソフトウェア・エラー、ハードウェア・エラー及び／又は欠陥、及び人的エラーを含む様々な原因によりエラーが発生する。

一実施形態では、データベースのコピー等のデータ・ボリュームの複製はＢＣＶとしてディスク上に存在する。ＢＣＶは遠隔のホストにマウントされ、所謂データ・スクラッビング・ツールを用いて検証される。データの完全性を検査するためのデータ・スクラッビング・ツールは当業者にとっては周知である。例えば、様々なデータ・スクラッビング・ツールを複製の完全性を評価するために使用することができるが、１つの好適なデータ・スクラッビング・ツールがカリフォルニア州、レッドウッド・ショアズのＢＭＣソフトウェアの製品であるパトロール・ファミリーから提供されている。データは、本発明に従ってディスクに記憶されるため、データ・スクラッビングにより潜伏エラー時間、即ちエラーが未発見の間の時間を十分に低減することが可能となる。

対照的に、多くの従来システムでは、例えば、顧客等の人物が、顧客のアカウントの異常に関してデータベースオペレータに問い合わせを行うまで、エラーが発見されない。当業者にとって既知であるように、テープ上に存在するデータを、データ修復及び復元なしで検査することは不可能である。

エラー発生の確認後、時間ＴＥＥが経過する間に、エラーを評価して可能な訂正措置を決定する。例えば、オペレータは、エラーの種類、どのようにエラーが発生したか、どのようにエラーが広がったか、エラーの影響は何か、いつエラーが発生したか、どうしたらエラーを訂正できるかを評価できる。主にオペレータの専門的技術のレベルがエラーの評価に要する時間を決定する。

エラー評価の間、システムは、別のホストにマウントするために、データベースのオン・デマンド複製を作成可能である。これにより、複合評価を１つ以上の評価項目において並行に実行することができる。加えて、破壊的な評価を代わりのホストで実行してもよく、この理由は、プロダクション・データベースを更なる複製のために利用可能であるからである。

概して、エラー評価の後、オペレータは時間ＴＣＥの間にエラーの訂正を決定する。オペレータは、バックアップされたデータ（チェックポイント）を修復するか、若しくはプロダクション・データベースの修復を試みることが可能である。修復の試みに先立って別の複製を作成することにより、オペレータは生のデータベースの修復を自由に試みることができる。即ち、複数のチェックポイントが存在することに起因して、オペレータは危険な「当て推量の」修復を試みることが可能である。オペレータの試みた解決方法がエラーの修復に失敗したか、若しくはエラーを悪化させた場合は、チェックポイントがリドゥ・ログから直ちに修復され、復元され、更新される。更なるデータベースのコピーを、付加的で可能性のある解決方法を試みるために利用可能である。あるいは、プロダクション・データベースの変更に先立って、解決方法がデータベースのコピーで試されてもよい。

修理において修復が選択された場合は、ユーザはどのバックアップが修復されるべきかを決定しなくてはならない。理想的には、それは、データベースが異常となる前の最新のバックアップである。エラーが発生した正確な時間がわからない場合は、ユーザはどのバックアップが修復されるべきかを推測しなくてはならないかもしれない。

従来技術のシステムでは、ユーザは選択されたバックアップから修復を行わなくてはならない。何時間もかかることがある修復の完了後に、ユーザは選択されたバックアップに異常がないかどうかをチェックすることができる。異常がある場合は、ユーザは更なるバックアップからもう一度、修復を行わなくてはならない。このような複数回の修復は、本発明のＩＲシステムによって不要となる。この理由は、ユーザは選択されたバックアップを別のホストにマウントし、バックアップのエラーをチェックできるからである。エラーのないバックアップが発見された場合は、単一の修復が実行される。

多くの従来技術のシステムでは、プロダクション・データベースの所謂サージカル修復は、テープからデータを修復するのにかかる時間及び労力に起因して、好ましいオプションである。テラバイト以上のような比較的大規模なデータベースでは、テープからのデータ修復に何時間も費やされる。加えて、あるミッション・クリティカル・データベースにとっては、データベースを停止することに関る途方もないコストを鑑みると、サージカル修復は事実上、単なるオプションである。しかしながら、エラーの修復を試みることにおいて、そのようなデータベースに被害を与えることの付随するリスクは容易にわかる。

更なる時間ＴＲＦの間、チェックポイントの修復後、ロール・フォーワード処理では、リドゥ・ログＲＬに記録された、データベース・コピーが凍結された後に発生したトランザクションを用いて、データベースを最新情報のものにしようと試みがなされる。記録されたトランザクションがデータベースに投入されるのに伴ってデータベースのエラーがチェックされなくてはならないため、ロール・フォーワード処理は反復的である。逐次にロール・フォーワードすることにより、データベースを別々のポイントで更新することができる。エラーが検出された場合、ロール・フォーワード処理は、エラーがないと分かっている最新のポイントに戻すことのみが必要である。従来のテープ・ベース・システムは、テープ、ディスク間の互換性のないフォーマットに起因して、この機能を備えていない。

特定用途の要求に応じて、オペレータが特定のエラー検出及び訂正ステップを容易に変更できることが理解されよう。例えば、エラー訂正解決方法の発見に利用するために、予定されたチェックポイント及び要求されたチェックポイントを変更してもよい。

様々なアプリケーション・エージェント、オペレーティング・システム、及び複製技術を敏速にサポートすべく柔軟性を有する、典型的な情報復元システム・アーキテクチャを図１６に示す。概して、ＩＲコアは、ＩＲ可能なアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介して、グラフィカル・ユーザ・インターフェース（ＧＵＩ）又はコマンド・ライン・インターフェース（ＣＬＩ）と通信する。複数のアプリケーション・エージェントＡ、Ｂ、Ｃはエンタープライズ・アプリケーションＡＰＩを介してＩＲコアと通信する。ＩＲコアは複数のオペレーティング・システム及び複製技術をサポート可能である。通常のインターフェースを用いてアプリケーション及び複製技術をコアから分離することにより、コアを変更することなく、新規のアプリケーション及び複製技術の追加が可能となる。例えば、新たなハードウェアを含み得る新規の複製技術、新規のホスト・ベース・ソフトウェア複製、及び／又はＳＣＳＩ ＸＣＯＰＹ等のサード・パーティー・コピー装置を容易に追加できる。新規のデータベース及びアプリケーションを、新規のファイルシステム、新規のリレイション・データベース・マネージメント・システム（ＲＤＢＭＳ）、新規のファイナンシャル・アプリケーション、及びＥメール・アプリケーションを含んで容易に追加することも可能である。そして、新規のユーザ・インターフェース、新規のスクリプティング、及び新規のホスト・プラットホームを容易にサポート可能である。

本発明の更なる態様では、データベースの複製の一部をホスト・コンピュータにマウント可能である。本発明をオラクル・データベースの表スペースと関連付けて説明するが、本発明を更なるデータベースの種類及び構成要素に適用可能であることが理解されよう。加えて、オラクルの用語は本発明の理解を円滑にするために使用されるのであり、本発明を特定のデータベースの種類又は構成に限定するものとして解釈すべきではない。

図１に類似の図１７，１８は、本発明に従う、部分的なデータベース複製のマウントを行う典型的なＩＲシステム１２００を示す。ＩＲサーバ１２０２は、ＩＲユーザ１２０６等のホスト・コンピュータからの複製要求を取り扱うために、ＩＲデーモン１２０４を含む。ＩＲアプリケーション・クライアント１２０８は、記憶エリア・ネットワークＳＡＮ内のボリューム・グループＶＧＳに記憶されたオラクル・データベースのような、アプリケーション用のデータベース・サーバＤＢＳ（図１８参照）として機能する。ＩＲユーザ１２０６又はマウント・ホストＭＨ（図１８参照）は、オリジナル・データベースＯＤＢから複製された複製データベースＲＤＢへの利用可能性を備える。

本実施形態では、プロダクション・データベース又はオリジナル・データベースＯＤＢは、記憶エリア・ネットワークＳＡＮ内に設けられ、かつデータベース・サーバ・ホストＤＢＳで実行される。オリジナル・データベースＯＤＢは、システム情報ＳＹＳに加えて、第１、第２及び第３の表スペースＴＳ１，ＴＳ２，ＴＳ３を含む。オリジナル・データベースＯＤＢの複製ＲＤＢも、対応する表スペースＴＳ１Ｒ，ＴＳ２Ｒ，ＴＳＲ３及びシステム情報ＳＹＳＲを含む。データベース複製の作成は先に詳述されている。複製データベースＯＤＢは、マウント・ホストＭＨ（図１８参照）等のＩＲユーザに対して利用可能である。マウント・ホストＭＨとデータベース・サーバＤＢＳとは、例えば、同一のオペレーティング・システムを実行していること等、実質的に類似していることが理解されよう。

上記したように、ＩＲデーモン１２０４はＩＲサーバ１２０２で実行される。マッピング・ファイル等の複製情報は、ＩＲデータベース１２１０内に含まれる。ＩＲデータベースは複製のマウント及び始動に必要な情報を持つ。上記したように、複製の作成中にこの情報が獲得される。クライアント・コントロール・モジュール又はデーモン１２１２（図１７参照）は、データデース・サーバＤＢＳ及びマウント・ホストＭＨ上で実行される。マウント・ホストで実行されているクライアント・コントロール・モジュールは、他の必要な情報とともにデータ・ボリューム・マッピング・ファイルをＩＲサーバ１２０２から受信し、複製データベースＲＤＢをマウントする。

概して、システムは、例えば上記のようにユーザにより選択された表スペースのような、部分的複製データベースを、様々なモードで始動することができる。例えば、オペレータは第１の表スペースＴＳ１を始動するように選択して、第２及び第３の表スペースＴＳ２，ＴＳ３を無視することが可能である。マウントの後、第１の表スペースＴＳ１が、オペレータによりユーザ利用可能となる。

一実施形態では、第１の表スペースＴＳ１等の部分的複製データベースを、後述する、復元モード、復元読み取り専用モード、及び非復元モードで始動することができる。特定用途の要求に合った更なるモードが、当業者には容易に明らかとなる。

本発明に従う、部分的データベース複製を始動するための典型的な一連のステップを図１９に示す。ステップ１３００では、マウント・ホストは複製データベース・マッピング・ファイルをＩＲデータベースからＩＲサーバを介して受け取る。ステップ１３０２で、複製されたデータベースを制御するデータベース・サーバがマウント・ホスト上で作成される。データベース・サーバを作成することは、例えば、ボリューム・グループをインポートすること、ボリュームを始動すること、及びファイル・システムをマウントすることを含むことができる。ステップ１３０３では、システムは、アーカイブ・ログ、ｉｎｉｔ＜ｓｉｄ＞ファイル及びパスワード・ファイルと同様に、好適なバックアップ・コントロール・ファイルをマウント・ホスト上の要求された位置にコピーする。ステップ１３０４では、複製されたオラクル・データベース等のデータベース・インスタンスが、先に詳述したように、ターゲット・マウント・ホストでマウントされる。複製されたインスタンスがまだ存在していないターゲット・ホストに、複製をマウント可能であることが理解されよう。即ち、システムは、マウント・ホストがインストールされたオラクル・アプリケーションを持つことと、マウントされるべきオブジェクト・インスタンスがホスト上でまだ実行されていないこととを予測する。

一実施形態では、クライアント・コントロール・デーモンのアプリケーション・レイヤは、何が復元されるべきかを記述するマッピング又はツリー・ファイルを受け取る。オリジナル・ツリーは、アプリケーションの複製中に生成され、ＩＲサーバ上のＩＲＤカタログ／データベース内に記憶される。このマッピングは、マウント・ホスト上で実行しているクライアント・コントロールに対して利用可能となる。ツリーは、マウントするために何が必要かということと、ユーザが要求するものから何が構築されるかということとを含んでいる。そして、ユーザはオリジナル・ツリーから部分的なツリーを選択する。この部分的なツリー・ファイルは、複製データベース内に含まれているものを記述するオリジナル・ツリーと比較される。これにより、クライアント・コントロール・デーモンは、復元される必要のない、例えばＴＳ２及びＴＳ３等の、表スペースを決定できる。ｉｎｉｔｉｎｓｔａｎｃｅ．ｏｒａファイル及びオラクル・アプリケーションのための２つのバックアップ・コントロール・ファイル（読み取り専用バージョン及び通常バージョン）等の他の情報ファイルと同様に、ログ・ファイルをターゲット・ホストにコピーできる。

復元モードでの始動に関しては、ステップ１３０６で、データベース・ボリューム・グループ及び／又は生の装置（ｒａｗ ｄｅｖｉｃｅ）はターゲット・マウント・ホスト上で、オリジナル・ホストの名前から新規な名前に改名される。例えば、オラクル・ステイトメントが実行され、それによりオラクル・データベースが名前の変更に気付く。パスワード・ファイルが複製のためにＩＲデータベースから引き渡されることが理解されよう。一実施形態では、オラクルが利用できるように、バックアップ・コントロール・ファイルはリアル・コントロール・ファイルが存在すると推定される位置に自動的にコピーされる。バックアップ・コントロール・ファイルはマウント・ホスト上のアーカイブ・ログ・ディレクトリにコピーされる。コントロール・ファイルは、複製時に、オラクル・アプリケーションのためのアプリケーション・ホストのｉｎｉｔ＜ＳＩＤ＞．ｏｒａファイルにより記述された位置にコピーされる。この位置の記述は、例えばデータベースに問い合わせることにより、複製時に自動的に目録化される。それが読み取り専用復元か、又は復元かのどちらかということにより、適切なバックアップ・コントロール・ファイルが先に特定された位置にコピーされる。コントロール・ファイルをコピーした後、ＩＲアプリケーション・エージェント・ソフトウェアは適切な許諾及び所有権を与える。

修復されたパスワード・ファイルを用いた後、ステップ１３０８で、不要な情報、例えばＴＳ２，ＴＳ３、が削除され、以前にユーザにより復元が選択された表スペースのみ、例えばＴＳ１、が復元される。そして、第１の表スペースＴＳ１の復元はステップ１３１０で実行される。適切なコントロール・ファイルをコピーした後、データベースがマウントされて必要ならば名前が付け替えられる。不要なファイルは削除され（データファイルを削除することによりコントロール・ファイルを更新する）、データベース全体が復元される。オラクルは削除されたデータファイルを無視し、コントロール・ファイルにより規定されたようにマウントすべく選択された表スペースのみを復元させる。ステップ１３１２では、オラクル・データベース・インスタンスは開放され、利用可能となる。

非復元モードでは、オラクル・レイヤは、いずれのオラクル復元命令も出さない。それは、ユーザ利用可能なツールを単に保存するだけである。即ち、ｉｎｉｔｉｎｓｔａｎｃｅ．ｏｒａファイル、ログ、データ・ファイル及びバックアップ・コントロール・ファイルは利用可能である。そして、ユーザはパスワード・ファイルを再び作成し、復元を手動で実行することが可能である。

読み取り専用始動モードでは、システムは、リアル・コントロール・ファイル位置にコピーされたバックアップ・コントロール・ファイルが読み取り専用バージョンであることを除いて復元モードと同様に振舞い、そして、インスタンスが復元し、待機モードで開放される。

当業者は上記の実施形態に基づいて、本発明の更なる特徴及び利点を認識するであろう。従って、添付の特許請求の範囲に記載されたものを除き、本発明は詳細に示され記載されたものにより限定はされない。ここで参照した全ての刊行物及び文献は明示的にそれら全体を本願に参照として援用する。

本発明に従う情報復元システムの概略図。 図１のシステムのための典型的なスクリーン・ディスプレイを示す図。 図１のシステムのための更に典型的なスクリーン・ディスプレイを示す図。 図１のシステムの一部を形成可能なデータ記憶ネットワークの概略ブロック図。 データ記憶ネットワークの更なる詳細を示す概略図。 本発明に従う情報復元システムにおける、バックアップ及び修復のための論理対物理ボリュームをマップする典型的な一連のステップを示すフロー図。 本発明に従う情報復元システムにおける、ボリューム情報をマッッピングし、発見するための典型的な一連のステップを示すフロー図。 本発明に従う情報復元システムのための、発見されたボリューム情報からツリー構造を作成するための典型的な一連のステップを示すフロー図。 本発明に従う情報復元システムにおける、ミラーを確立し、分割するための典型的な一連のステップを示すフロー図。 本発明に従う情報復元システムにおける、論理情報を構築／マウントするための典型的な一連のステップを示すフロー図。 本発明に従う情報復元システムにおいて、データ・ボリュームをバックアップするための典型的な一連のステップを示すフロー図。 本発明に従う情報復元システムにおいて、データ・ボリュームを修復するための典型的な一連のステップを示すフロー図。 本発明に従う情報復元システムにおける、ボリューム・マウント解除／クリーンアップのための典型的な一連のステップを示すフロー図。 本発明に従う情報復元システムにおいて、ボリューム・チェックポイントを時間毎に作成することを示す図。 本発明に従う情報復元システムにおいて、データ・ボリューム内のエラーを検出し、訂正することを示す図。 本発明に従う情報復元システムのための典型的な柔軟性のあるアーキテクチャの図。 本発明に従う部分的データベースの複製のマウンティングを備える情報復元システムの概略図。 本発明に従う、部分的データベース複製をターゲット・マウント・ホスト上にマウントする情報復元システムの更なる概略図。 本発明に従う、部分的複製データベースをマウントするための典型的な一連のステップを示すフロー図。

Claims (14)

1. データ・ボリューム内のエラーを検出する方法であって、
   オリジナル・データ・ボリュームを格納し、
   複数のチェックポイントの各々において前記オリジナル・データ・ボリュームを複製し、
   複製されたデータ・ボリュームを前記オリジナル・データ・ボリュームの潜伏エラーについて検査し、
   前記複製されたデータ・ボリューム内の前記潜伏エラーの検査から取得された情報を用いて、エラーが検出されたチェックポイントにおける前記複製されたデータ・ボリュームを修復し、リドゥ・ログからのデータを用いて、修復されたデータ・ボリュームに対応するオリジナル・データ・ボリュームを更新することで、前記オリジナル・データ・ボリューム内の前記潜伏エラーを訂正することを備える方法。
2. 第１の複数のディスク上に前記オリジナル・データ・ボリュームを格納し、
   第２の複数のディスク上に前記オリジナル・データ・ボリュームを複製することを更に含む、請求項１に記載の方法。
3. 前記複製されたデータ・ボリュームをデータ・スクラッビング・ツールを用いてマウントし、検査することを更に含む、請求項１に記載の方法。
4. エラー訂正方法を決定すべく、前記複製されたデータ・ボリューム内で検出されたエラーの評価を可能にすることを更に含む、請求項３に記載の方法。
5. 前記複製されたデータ・ボリュームの修理を試みることを可能にすることを更に含む、請求項４に記載の方法。
6. 前記第１の複数のディスク上のオリジナル・データ・セットにおける複製されたデータ・ボリュームへの成果のある修理の実施を可能にすることを更に含む、請求項５に記載の方法。
7. 前記修復されたデータ・ボリュームがリドゥ・ログから更新されるのに伴い、前記修復されたデータ・ボリュームをエラーについて逐次、検査することを更に含む、請求項１に記載の方法。
8. エラーが検出されないポイントで、部分的に修復されたデータ・ボリュームを更新することを更に含む、請求項７に記載の方法。
9. 情報及び復元システムであって、
   記憶エリア・ネットワークと、
   前記記憶エリア・ネットワークと接続され、第２のホストによってマウントされるデータ・ボリューム・グループであって、かつ該データ・ボリューム・グループの潜伏エラーについて検査されるデータ・ボリューム・グループを複製すべく、第１のホストからの要求を受信するサーバとを備え、前記サーバは、複数のチェックポイントの各々において第２のホスト上で前記データ・ボリューム・グループを複製し、前記第２のホストは、データ・ボリューム・グループの潜伏エラーについて前記複製されたデータ・ボリューム・グループを検査するとともに、前記複製されたデータ・ボリューム・グループの前記潜伏エラーの検査から取得された情報を用いて、エラーが検出されたチェックポイントにおける前記複製されたデータ・ボリューム・グループを修復し、リドゥ・ログからのデータを用いて、修復されたデータ・ボリューム・グループに対応するデータ・ボリューム・グループを更新することで、前記データ・ボリューム・グループの前記潜伏エラーを訂正するシステム。
10. 複製要求を生成するためのＩＲアプリケーションを更に含む、請求項９に記載のシステム。
11. 前記ＩＲアプリケーションはネットワークを介してサーバと接続されたホスト・コンピュータ上に存在している、請求項１０に記載のシステム。
12. データ・ボリューム・グループがアプリケーション・エージェントにより制御される、請求項９に記載のシステム。
13. 前記アプリケーション・エージェントがオラクル・データベースに対応する、請求項１２に記載のシステム。
14. サーバと接続されたＩＲデータベースを更に含む、請求項９に記載のシステム。

Images