データベースクラスタリカバリ方法及び装置
【課題】データベースクラスタリカバリ方法及び装置を提供する。
【解決手段】
本発明にかかる方法及び装置は、ディスクアレイキャッシュ（２０４）にＲＥＤＯログブロックを保持すること、データブロック書き込みフラグ（ＤＢＷＦ）を使用して前記ＲＥＤＯログブロックをフィルタリングすること、及び、障害のあった（failed）データベースインスタンスによって生成されたＲＥＤＯログレコードのサブセットであるリカバリセットを前記ディスクアレイキャッシュ（２０４）に生成することを含む。
【解決手段】
本発明にかかる方法及び装置は、ディスクアレイキャッシュ（２０４）にＲＥＤＯログブロックを保持すること、データブロック書き込みフラグ（ＤＢＷＦ）を使用して前記ＲＥＤＯログブロックをフィルタリングすること、及び、障害のあった（failed）データベースインスタンスによって生成されたＲＥＤＯログレコードのサブセットであるリカバリセットを前記ディスクアレイキャッシュ（２０４）に生成することを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースクラスタリカバリ方法及び装置に関する。
【背景技術】
【０００２】
データベースクラスタは、ローカルエリアネットワーク（ＬＡＮ）を介して相互に接続された、共有ディスクアーキテクチャを使用する１群の独立したサーバを含む。データベースクラスタは、異なるサーバで実行するプロセス間の個々の高速相互接続を使用して、データを交換し、キャッシュ同期を行う。このようなデータベースクラスタの一例は、Ｏｒａｃｌｅリアルアプリケーションクラスタ（ＲＡＣ（real application cluster））である。ＯｒａｃｌｅインスタンスがＲＡＣデータベースクラスタで開始されるごとに、システムグローバルエリア（ＳＧＡ（system global area））と呼ばれるメモリ領域が割り当てられ、１組のバックグラウンドプロセスが開始される。ＳＧＡとプロセスとを結合したものは、Ｏｒａｃｌｅデータベースインスタンス又は単にインスタンスと呼ばれる。ＲＡＣは複数のインスタンスから成り、各インスタンスは個々のノード（単一のサーバ又は対称型マルチプロセシング（ＳＭＰ（symmetric multiprocessing））システム等）に存在する。インスタンスのメモリ及びプロセスは、データベースのデータを効率的に管理するように機能し、データベースのそのインスタンスに関連した１人又は複数のユーザのために働く。ＲＡＣは、単一ノードのＯｒａｃｌｅデータベースインスタンスでは満たされない可能性のある処理負荷に対する拡張性のあるソリューションを提供するために相互に協働する１組のＯｒａｃｌｅインスタンスである。ＲＡＣのノードは、単一の中央演算処理装置（ＣＰＵ）とすることもできるし、単一のインスタンスを実行するＳＭＰとすることもできる。ＲＡＣは、異なるタイプの障害（failure）を有する可能性があり、その結果、ＲＡＣは、媒体リカバリ及びインスタンスリカバリを含む異なるタイプのＲＡＣリカバリをサポートすることができる。
【０００３】
データベースインスタンスの障害は、多くの状況によって引き起こされる可能性がある。この多くの状況は、データベースがインスタンスを停止させたり、サーバがシャットダウンしたり、サーバがリブートしたり、インスタンスが自動開始されなかったり等である。インスタンスの障害が発生すると、Ｏｒａｃｌｅインスタンスリカバリプロセスは、インスタンスの起動時にデータベースを自動的にリカバリさせることができる。障害が発生した時にコミットされたトランザクションは、リカバリされるか、又は、ロールフォワードされ、その時点で処理中のすべてのトランザクションはロールバックされる。
【０００４】
ＲＡＣアーキテクチャ内のキャッシュフュージョンアーキテクチャは、アプリケーションの要求を満たすために、異なるインスタンスのローカルバッファキャッシュの総量を、ＲＡＣシステム全体に利用可能な１つの大きな仮想キャッシュに「仮想化」することによって改善された拡張性を提供する。キャッシュフュージョンは、プロセス間通信（ＩＰＣ）を使用してインスタンスのローカルバッファキャッシュ間でデータブロックを転送するのに、高速インターコネクト（たとえば、ギガビットイーサネット（登録商標）等）を使用する。キャッシュフュージョンは、アプリケーションのコードにも設計にも何ら影響を与えることなく、複数のバッファキャッシュを１つの結合したグローバルキャッシュとして取り扱うことによって、複数のインスタンスのデータブロックの一貫性を提供する。
【０００５】
グローバルキャッシュサービス（ＧＣＳ）は、キャッシュフュージョンによって導入され、ＧＣＳのインスタンスプロセスであるロックマネージャサーバプロセス（ＬＭＳｎ（lock manager server））を含む１組のプロセスとして実施され、グローバルエンキューデーモン（ＬＭＤ）は、エンキューマネージャサービス要求を調整するＧＥＳ（global enqueue service）のロックエージェントプロセスである。ＧＣＳ及びＧＥＳは、リソース（データブロック）及びエンキューに関する情報を記録するためのグローバルリソースディレクトリ（ＧＲＤ（global resource directory））を保持する。ＧＲＤはメモリに存在し、そのディレクトリリソースの一部はＲＡＣのあらゆるインスタンスによって管理される。クラスタ全体にわたるリソースがエンキュー及び／又はロックである状況では、ＧＣＳは、データブロックの変更又は読み込みが可能となる前に、当該クラスタ全体にわたるリソースを獲得するようにインスタンスに要求する。
【０００６】
マルチノードＲＡＣの場合、データブロックは、インスタンスのいずれかに存在することができるか、又は、どのインスタンスも、ユーザアプリケーションによる必要に応じてデータブロックをフェッチすることができる。キャッシュフュージョンは、複数のインスタンスにおいてデータブロックのキャッシュされたものの間の一貫性を維持する上で重要な役割を果たす。インスタンスがデータブロックにアクセスする必要がある場合、そのインスタンスは、ＲＡＣのどのインスタンス（ＬＭＳ）がそのデータブロックを管理しているかを、ローカルオペレーションを通じて見つけ出すことができる。この複製されたデータは、比較的静的なデータであり、インスタンスに障害があった時にのみ変更を行う必要があり、障害のあったインスタンスによって管理された該当するデータブロックは、ＲＡＣの残りのインスタンスに割り当てる必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
データベースクラスタリカバリ方法及び装置を提供する。
【課題を解決するための手段】
【０００８】
本発明にかかる方法及び装置は、ディスクアレイキャッシュ（２０４）にＲＥＤＯログブロックを保持すること、データブロック書き込みフラグ（ＤＢＷＦ）を使用して前記ＲＥＤＯログブロックをフィルタリングすること、及び、障害のあった（failed）データベースインスタンスによって生成されたＲＥＤＯログレコードのサブセットであるリカバリセットを前記ディスクアレイキャッシュ（２０４）に生成することを含む。
【発明を実施するための最良の形態】
【０００９】
次に、本発明の例示の実施の形態を詳細に説明するために、添付図面を参照する。
【００１０】
［表記及び専門語］
以下の説明全体及び特許請求の範囲を通じて特定のシステムコンポーネントを指すのに一定の用語が使用される。当業者には理解されるように、異なる企業／業界は、コンポーネントを異なる名前で指すことがある。この文書は、名前が異なるが機能は異ならないコンポーネントを区別するように意図されていない。以下の説明及び特許請求の範囲では、用語「含む」及び「備える」は、オープンエンドな形式で使用され、したがって、「含むが、これらに限定されるものではない」との意味に解釈されるべきである。また、用語「連結する」は、間接的な電気接続又は直接的な電気接続のいずれかを意味するように意図されている。したがって、第１のデバイスが第２のデバイスに連結する場合、その接続は、直接的な電気接続によるものである場合もあるし、他のデバイス又は接続を介した間接的な電気接続によるものである場合もある。
【００１１】
［詳細な説明］
以下の説明は、本発明のさまざまな実施の形態を対象にする。これらの実施の形態の１つ又は複数は好ましいものとすることができるが、開示した実施の形態は、特許請求の範囲を含めて、開示の範囲を限定するものとして解釈されるべきでなく、それ以外に使用されるべきでない。これに加えて、以下の説明は幅広い用途を有すること、どの実施の形態の説明も、その実施の形態の例示にすぎないことが意図されていること、及び、特許請求の範囲を含めて開示の範囲はその実施の形態に限定されることを暗示するようには意図されていないことが当業者には理解されよう。
【００１２】
ディスクアレイストレージサブシステムで利用可能な大きなキャッシュ及び処理能力を利用することによって、本発明の実施の形態は、サーバインスタンスリカバリを改善することを援助する。このような機能の結果、データベースがアプリケーションにアクセス不能となる時間（前述したリカバリのフェーズ１）が削減され、それによって、全体的なデータベースの可用性が増大する。
【００１３】
一実施の形態では、改善されたインスタンスリカバリを提供する、Ｏｒａｃｌｅ ＲＡＣ等用のディスクアレイが提供される。本発明の実施の形態は、適切なキャッシュ及び処理能力を有するあらゆるデータベースクラスタ又はディスクアレイと共に使用することができる。
【００１４】
ＲＥＤＯログレコード（redo log record）は、タイムスタンプ、ディスクブロックアドレス（ＤＢＡ（disk block address））、データブロック書き込みフラグ（ＤＢＷＦ（Data Block Written Flag））等を含む複数のフィールドを含む。このＲＥＤＯログレコードは、データベースクラスタに対して行われたすべての変更を記録する。インスタンスリカバリに関する限り、ＤＢＷＦが設定されている場合、同じＤＢＡについての以前のすべてのＲＥＤＯログレコードが必要とされないことを示し、このプロセスは「フィルタリング」と呼ばれる。すべてのＲＥＤＯログレコードをスキャンして、フィルタリングを実行することの純粋な（net）効果によって、リカバリセットが生成される。
【００１５】
例示として、データベースクラスタの一例は、１００個のブロック及び数個のインスタンスを含む。リカバリの例示として、ここではインスタンス１と呼ぶ１つだけのインスタンスの実行時の振る舞いのみに注目することにする。このインスタンス１は、所与のアプリケーションを実行しているデータベースクラスタの一部である。この例では、インスタンス１は、以下のオペレーションを実行したものである。
−ＲＥＤＯログレコード１を生成したブロックＤＢＡ１を読み込み、次いで更新した。
−ＲＥＤＯログレコード２を生成したブロックＤＢＡ２を読み込み、次いで更新した。
−ＲＥＤＯログレコード３を生成したブロックＤＢＡ３を読み込み、次いで更新した。
−ブロックＤＢＡ１を更新し、この更新したブロックをディスクに書き込み、ＤＢＷＦフラグセット（Ｏｒａｃｌｅ ＲＡＣシステムの場合、ＢＷＲフラグ）が設定されたＲＥＤＯログレコード４を生成する。
インスタンスリカバリ中、すなわち、インスタンス１に障害があった後、生存している選ばれたインスタンス（たとえばインスタンス２）は、インスタンス１のＲＥＤＯログを読み出す。このＲＥＤＯログは、レコード１、レコード２、レコード３、及びレコード４を含む。ＤＢＷＦフラグセットが設定されたＲＥＤＯログレコード４の読み込み時に、レコード４、及び、ＤＢＡ１に属する以前のすべてのＲＥＤＯログレコード（すなわち、上記例ではレコード１）の双方がトスされる（tossed away）。ＲＥＤＯログレコードをスキャンして適切なレコードを捨てる（throwing away）プロセスは、「フィルタリング」と呼ばれる。この時点における「リカバリセット」は、２つのＲＥＤＯログレコード（レコード２、レコード３）である。フェーズ１の終了時には、データベースは、「リカバリセット」のメンバであるブロック（ＤＢＡ）を除いて、アプリケーションに利用可能になる。リカバリのフェーズ２では、リカバリインスタンスは、「リカバリセット」のＲＥＤＯログレコードをデータベースに適用し、その結果、障害が発生した時以後のデータベースの状態をリカバリさせる。フェーズ２の完了時には、データベースは、データベースクラスタのアプリケーションに完全に利用可能となる。データベースクラスタ全体が利用可能でないリカバリのフェーズ１は、全インスタンスリカバリ時間の約１０％程度の時間を要し、通常、３分から３時間に及ぶことがある。他方、リカバリのフェーズ２は、非常に長い時間を要する可能性がある。
【００１６】
図１を参照して、本発明の一実施の形態によるデータベースクラスタリカバリ技術を強調したフロー図が示されている。１０２において、入力したＲＥＤＯログブロックがディスクアレイキャッシュに保存されて処理される。また、これらのブロックは、１０４において、通常通り、安定したストレージエリアにも書き込まれる。１０６において、好ましくはバックグラウンドオペレーションとして、アレイプロセッサが、ディスクアレイキャッシュの個々の領域で「リカバリセット」を徐々に増加させながら動的に生成して保持する。この「リカバリセット」の生成は、ＲＥＤＯログレコード自体の物理的なコピーを意味するものではない。「リカバリセット」は、データブロック書き込みフラグ（ＤＢＷＦ）セットが設定されたレコードのＲＥＤＯログブロックをアレイプロセッサにスキャンさせることによって生成することができる。ＤＢＷＦフィールドは、インスタンスがグローバルリソースによってカバーされたブロックを書き込んだ時又は廃棄した時にＲＥＤＯログバッファに設定される。Ｏｒａｃｌｅ環境の場合、ＤＢＷＦフィールドは、ブロック書き込みレコード（ＢＷＲ（Block Written Record））フィールドに対応する。これによって、インスタンスから得られたＲＥＤＯログをフィルタリングすることが援助される。一実施の形態では、ＤＢＷＦセットが設定されたあらゆるＲＥＤＯログレコードは通常のアレイキャッシュに残され、ＲＥＤＯログレコード及び（タイムスタンプ情報に基づく）以前のレコードはリカバリセットの一部ではない。
【００１７】
ＤＢＷＦフィールド（たとえば、ＢＷＲ）セットが設定されたレコードの値よりも前のタイムスタンプを有するすべてのレコードは、リカバリセットの一部とはならず、残りのＲＥＤＯログレコードのみがリカバリセットの一部となる一方、すべてのＲＥＤＯログレコードが、１１０において、通常のディスクアレイキャッシュに含められる。Ｏｒａｃｌｅ環境の場合、タイムスタンプは、システム変更番号（ＳＣＮ）を備えることができる。リカバリセットの一部であるＲＥＤＯログレコードは、１１２において、自身のタイムスタンプによって自身をソートすることが可能で、且つ、ソートされた「リカバリセット」を要求に応じてインスタンスに戻すことが可能なデータ構造体によって管理される。次に、このルーチンは、ステップ１０６にループバックする。
【００１８】
一インプリメンテーションは、リカバリセットのあらゆるＲＥＤＯログレコードにつきヘッダデータ構造体を作成することを含む。これらのヘッダデータ構造体は、そのディスクブロックアドレス（ＤＢＡ）に基づいてハッシュテーブルに挿入することができる。このようにして、レコードは、アクセス可能になり、場合によっては、後に「リカバリセット」から除去することができる。ＲＥＤＯログレコードのタイムスタンプ（たとえば、ＯｒａｃｌｅのＳＣＮ）に基づいてソートされた当該ＲＥＤＯログレコードを反映するように、リンクをあらゆるヘッダに追加して、これらのヘッダをリンクすることを可能にすることができる。「リカバリセット」の要求に応じて、ディスクアレイは、上述したリンクを使用してリンクリストを辿ることによって、ＳＣＮによりソートされたインスタンスに「リカバリセット」を返す。
【００１９】
インスタンスの障害が発生するときは常に、選ばれた「リカバリインスタンス」が、その障害のあったインスタンスのＲＥＤＯログ全体の代わりに「リカバリセット」を要求する。「リカバリセット」を要求することは、データベースがその間アプリケーションによってアクセス可能ではない経過時間を削減することに対する、以下の見込まれるプラスの効果の１つ又は複数を有する。すなわち、「リカバリセット」を要求することによって、ストレージアレイからＯｒａｃｌｅリカバリインスタンスへ送り返すのに必要なデータ量が数ギガバイト（ＧＢ）から数メガバイト（ＭＢ）へ削減される；数ＧＢではなく数ＭＢのデータを返すことは、リカバリインスタンスのページングを削減することに大きな影響を与え、このことは、次に、フェーズ１のリカバリ時間に大きな影響を与える；ディスクアレイキャッシュは、オプションとして、ＲＡＣの異なるスレッド／インスタンスのＲＥＤＯログの共有メモリとして機能する唯一の機会を提供し、プロセッサは、必要とされないＲＥＤＯログエントリをさらに取り除くことができ、それによって、「リカバリセット」のサイズをさらに削減することができる；「リカバリセット」を要求することによって、リカバリインスタンスプロセッサにより必要とされる処理時間が節減されて、データベースがアクセス可能でない時間を削減するのを援助する「リカバリセット」が作成される；「リカバリセット」を要求することによって、タイムスタンプ（たとえば、ＳＣＮ値）に基づいてＲＥＤＯログをソート又はマージ／ソートする機会が提供され、これが効果的であるためには、（たとえば、Ｏｒａｃｌｅの）「リカバリインスタンス」は、返されたＲＥＤＯログレコードがすでにソートされたものであることを知っている必要があり、そうでない場合、「リカバリインスタンス」はそれらを再びソートすることになり、これは、「ＮＯＯＰ」オペレーション（ノーオペレーション）となる。
【００２０】
Ｏｒａｃｌｅインスタンスは、そのＲＥＤＯログレコードをディスクアレイのＲＥＤＯログデバイスに書き込む。製造（production）システムは、通常、低いアレイ利用率（たとえば、５０％未満の利用率）で構成される。これは、提案したアルゴリズムを実行するのに十分な処理サイクルがあることを意味する。データがディスクアレイキャッシュで得られている間、上述したフィルタリング及びソートのルーチンは、一般にリアルタイムで実行されるが、このルーチンは、非リアルタイムで実行することもできるし、ほぼリアルタイムで実行することもできる。ディスクアレイにおけるＣＰＵサイクルの可用性は問題ではないと予想されるが、これらのサイクルのスケジューリングは、最適な性能を確保するために慎重に行われる（be handled）べきである。ディスクアレイの通常のオペレーションのように、入ってくるＲＥＤＯログを処理することは、通常のＲＥＤＯログオペレーションの性能に影響を与えることを回避するために、フィルタリング／ソートオペレーションを実行することに優先されるべきである。したがって、ディスクアレイサイクルがアイドルである間にバックグラウンドでフィルタリング／ソートを実行できることが望ましい。上記手法の代替的なものとしては、通常はリアルタイムＯＳを実行する従来のディスクアレイＣＰＵが、ＲＥＤＯログレコードのフィルタリング／ソート及び汎用ＯＳの実行を行うが、そうする代わりに、これらのオペレーションを汎用ＣＰＵが実行するように汎用ＣＰＵを専用化するものがある。
【００２１】
単一のインスタンスの障害では、オプションとして、ＲＥＤＯログレコードをディスクアレイキャッシュに恒久的に保持することができ、これによって、すでにディスクに書き込まれているブロックに関連したＲＥＤＯログレコードを、たとえばＤＢＷＦフラグを使用して取り除くことができる。その結果、ＲＥＤＯログレコードのサブセットのみを返すことができる。ＲＥＤＯログレコード全体をネットワーク上で返し、大部分が必要とされなかったことを後に知っても意味がない。その結果、リカバリセットのサイズは削減されており、ＲＥＤＯログ全体のサイズよりも小さい。リカバリセットのリソースは、障害のあったセットでは変更されているが、障害のあったインスタンスによってディスクにまだ書き込まれていない１組のブロックを含む。
【００２２】
次に図２を参照して、本発明の一実施の形態によるディスクアレイ２００が示されている。一実施の形態では、ディスクアレイ２００は、本明細書で説明したデータベースクラスタリカバリルーチンを含むＨＰ ＳｕｒｅＳｔｏｒｅ Ｅ ＸＰファミリーのディスクアレイ等、Hewlett-Packard社（HP）のＳｔｏｒａｇｅＷｏｒｋｓディスクアレイＸＰを含むことができる。本発明の実施の形態は、多くのタイプのディスクアレイと共に使用でき、開示した実施の形態は単に例示にすぎないことに留意すべきである。
【００２３】
ディスクアレイは、複数のディスクストレージアレイ２０２、データキャッシュ２０４、共有メモリ２０６、クロスバースイッチ／共有メモリインターコネクト２０８、最大４つまでのチップホストインターフェースプロセッサ（ＣＨＩＰ）対２１０〜２１６、データキャッシュ２０４及び共有メモリ２０６の双方に直接アクセスできるだけでなく、ファイバチャネルを通じてディスクストレージアレイ２０２にアクセスできる複数のアレイ制御プロセッサ（ＡＣＰ）２１８を含む。ＣＨＩＰ２１０〜２１６は、アレイ２００へのホスト接続のための接続ポイントを提供する。ＣＨＩＰ２１０〜２１６は、コマンド及び信号をＡＣＰ２１８に送信し、ディスクに対してキャッシュメモリの読み込み／書き込みを行う。追加されたＣＨＩＰ機能は、キャッシュトラックディレクトリにアクセスして当該キャッシュトラックディレクトリを更新すること、データアクセスパターンを監視すること、ホストデバイスタイプをエミュレートすること、及び、アレイ間の複製のための接続ポイントを提供することである。データ制御ブロック２２０は、ＡＣＰ２１８とクロスバスイッチ／共有メモリインターコネクト２０８との間の相互接続を提供する。
【００２４】
本発明の一実施の形態では、ディスクアレイキャッシュ２０４は、データベースクラスタにおける異なるスレッド／インスタンスのＲＥＤＯログの共有メモリとして機能する唯一の機会を提供する。ＣＨＩＰのＣＰＵは、必要とされないＲＥＤＯログエントリをさらに取り除くことができ、それによって、「リカバリセット」のサイズをさらに削減することができる。リカバリセットの削減によって、アプリケーションによるデータベースへのアクセスが不能となる時間、及び、ネットワーク上のデータトラフィック量を削減することが援助される。ＲＥＤＯログレコードがインスタンスによって生成されている間、ＣＨＩＰプロセッサ２１０〜２１６は、前述したようなクラスタリカバリ技術を非同期に実行することができる。
【００２５】
また、本発明の実施の形態は、ＳＣＮ値を使用することによること等、タイムスタンプに基づいてＲＥＤＯログをソート又はマージ／ソートする機会も提供する。Ｏｒａｃｌｅ環境の場合、Ｏｒａｃｌｅリカバリインスタンスは、返されたＲＥＤＯログレコードがすでにソートされたものであることを知っている必要があり、そうでない場合、Ｏｒａｃｌｅリカバリインスタンスはそれらを再びソートすることになる。
【００２６】
図３には、本発明の一実施の形態によるインスタンスリカバリの第１フェーズが示されている。３０２において、ディスクアレイから「リカバリセット」を得るための要求がリカバリインスタンスによって行われる。ステップ３０４において、リカバリセットが、ディスクアレイＣＰＵによって管理され、ＲＥＤＯログレコードのタイムスタンプによって当該ＲＥＤＯログエントリをフィルタリング／ソートする。ステップ３０６において、「リカバリセット」がリカバリインスタンスに返される。Ｏｒａｃｌｅ環境の例示として、リカバリセットは、リカバリを行うＯｒａｃｌｅインスタンスに返される。
【００２７】
本発明で行われるように、いくつかのリカバリ機能をディスクアレイキャッシュ等のインテリジェントなストアに移すことによって、データベースがアクセス不能となる時間中におけるリカバリ時間を削減することが援助され、改善されたデータベース可用性を提供することが援助される。この開示で提示した方法及び装置は、他のデータベース機能にも適用可能であり、一般に、ソート能力及び／又は検索能力を必要とする機能に適用可能である。このような機能をインテリジェントなディスクアレイに移すことは、性能の観点から非常に有益となる可能性がある。
【００２８】
上記説明は、本発明の原理及びさまざまな実施の形態の例示であるように意図されている。当業者には、上記開示を十分に理解すると、多数の変形及び変更が明らかとなるであろう。
【図面の簡単な説明】
【００２９】
【図１】本発明の一実施の形態によるデータベースクラスタリカバリフローを強調したフローチャートである。
【図２】本発明の一実施の形態によるデータベースクラスタのブロック図である。
【図３】本発明の一実施の形態によるインスタンスリカバリの第１フェーズを強調したフローチャートである。
【符号の説明】
【００３０】
２０２・・・ディスクアレイ
２０４・・・データキャッシュ
２０６・・・共有メモリ
２０８・・・クロスバースイッチ／共有メモリインターコネクト
２２０・・・データ制御
【技術分野】
【０００１】
本発明は、データベースクラスタリカバリ方法及び装置に関する。
【背景技術】
【０００２】
データベースクラスタは、ローカルエリアネットワーク（ＬＡＮ）を介して相互に接続された、共有ディスクアーキテクチャを使用する１群の独立したサーバを含む。データベースクラスタは、異なるサーバで実行するプロセス間の個々の高速相互接続を使用して、データを交換し、キャッシュ同期を行う。このようなデータベースクラスタの一例は、Ｏｒａｃｌｅリアルアプリケーションクラスタ（ＲＡＣ（real application cluster））である。ＯｒａｃｌｅインスタンスがＲＡＣデータベースクラスタで開始されるごとに、システムグローバルエリア（ＳＧＡ（system global area））と呼ばれるメモリ領域が割り当てられ、１組のバックグラウンドプロセスが開始される。ＳＧＡとプロセスとを結合したものは、Ｏｒａｃｌｅデータベースインスタンス又は単にインスタンスと呼ばれる。ＲＡＣは複数のインスタンスから成り、各インスタンスは個々のノード（単一のサーバ又は対称型マルチプロセシング（ＳＭＰ（symmetric multiprocessing））システム等）に存在する。インスタンスのメモリ及びプロセスは、データベースのデータを効率的に管理するように機能し、データベースのそのインスタンスに関連した１人又は複数のユーザのために働く。ＲＡＣは、単一ノードのＯｒａｃｌｅデータベースインスタンスでは満たされない可能性のある処理負荷に対する拡張性のあるソリューションを提供するために相互に協働する１組のＯｒａｃｌｅインスタンスである。ＲＡＣのノードは、単一の中央演算処理装置（ＣＰＵ）とすることもできるし、単一のインスタンスを実行するＳＭＰとすることもできる。ＲＡＣは、異なるタイプの障害（failure）を有する可能性があり、その結果、ＲＡＣは、媒体リカバリ及びインスタンスリカバリを含む異なるタイプのＲＡＣリカバリをサポートすることができる。
【０００３】
データベースインスタンスの障害は、多くの状況によって引き起こされる可能性がある。この多くの状況は、データベースがインスタンスを停止させたり、サーバがシャットダウンしたり、サーバがリブートしたり、インスタンスが自動開始されなかったり等である。インスタンスの障害が発生すると、Ｏｒａｃｌｅインスタンスリカバリプロセスは、インスタンスの起動時にデータベースを自動的にリカバリさせることができる。障害が発生した時にコミットされたトランザクションは、リカバリされるか、又は、ロールフォワードされ、その時点で処理中のすべてのトランザクションはロールバックされる。
【０００４】
ＲＡＣアーキテクチャ内のキャッシュフュージョンアーキテクチャは、アプリケーションの要求を満たすために、異なるインスタンスのローカルバッファキャッシュの総量を、ＲＡＣシステム全体に利用可能な１つの大きな仮想キャッシュに「仮想化」することによって改善された拡張性を提供する。キャッシュフュージョンは、プロセス間通信（ＩＰＣ）を使用してインスタンスのローカルバッファキャッシュ間でデータブロックを転送するのに、高速インターコネクト（たとえば、ギガビットイーサネット（登録商標）等）を使用する。キャッシュフュージョンは、アプリケーションのコードにも設計にも何ら影響を与えることなく、複数のバッファキャッシュを１つの結合したグローバルキャッシュとして取り扱うことによって、複数のインスタンスのデータブロックの一貫性を提供する。
【０００５】
グローバルキャッシュサービス（ＧＣＳ）は、キャッシュフュージョンによって導入され、ＧＣＳのインスタンスプロセスであるロックマネージャサーバプロセス（ＬＭＳｎ（lock manager server））を含む１組のプロセスとして実施され、グローバルエンキューデーモン（ＬＭＤ）は、エンキューマネージャサービス要求を調整するＧＥＳ（global enqueue service）のロックエージェントプロセスである。ＧＣＳ及びＧＥＳは、リソース（データブロック）及びエンキューに関する情報を記録するためのグローバルリソースディレクトリ（ＧＲＤ（global resource directory））を保持する。ＧＲＤはメモリに存在し、そのディレクトリリソースの一部はＲＡＣのあらゆるインスタンスによって管理される。クラスタ全体にわたるリソースがエンキュー及び／又はロックである状況では、ＧＣＳは、データブロックの変更又は読み込みが可能となる前に、当該クラスタ全体にわたるリソースを獲得するようにインスタンスに要求する。
【０００６】
マルチノードＲＡＣの場合、データブロックは、インスタンスのいずれかに存在することができるか、又は、どのインスタンスも、ユーザアプリケーションによる必要に応じてデータブロックをフェッチすることができる。キャッシュフュージョンは、複数のインスタンスにおいてデータブロックのキャッシュされたものの間の一貫性を維持する上で重要な役割を果たす。インスタンスがデータブロックにアクセスする必要がある場合、そのインスタンスは、ＲＡＣのどのインスタンス（ＬＭＳ）がそのデータブロックを管理しているかを、ローカルオペレーションを通じて見つけ出すことができる。この複製されたデータは、比較的静的なデータであり、インスタンスに障害があった時にのみ変更を行う必要があり、障害のあったインスタンスによって管理された該当するデータブロックは、ＲＡＣの残りのインスタンスに割り当てる必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
データベースクラスタリカバリ方法及び装置を提供する。
【課題を解決するための手段】
【０００８】
本発明にかかる方法及び装置は、ディスクアレイキャッシュ（２０４）にＲＥＤＯログブロックを保持すること、データブロック書き込みフラグ（ＤＢＷＦ）を使用して前記ＲＥＤＯログブロックをフィルタリングすること、及び、障害のあった（failed）データベースインスタンスによって生成されたＲＥＤＯログレコードのサブセットであるリカバリセットを前記ディスクアレイキャッシュ（２０４）に生成することを含む。
【発明を実施するための最良の形態】
【０００９】
次に、本発明の例示の実施の形態を詳細に説明するために、添付図面を参照する。
【００１０】
［表記及び専門語］
以下の説明全体及び特許請求の範囲を通じて特定のシステムコンポーネントを指すのに一定の用語が使用される。当業者には理解されるように、異なる企業／業界は、コンポーネントを異なる名前で指すことがある。この文書は、名前が異なるが機能は異ならないコンポーネントを区別するように意図されていない。以下の説明及び特許請求の範囲では、用語「含む」及び「備える」は、オープンエンドな形式で使用され、したがって、「含むが、これらに限定されるものではない」との意味に解釈されるべきである。また、用語「連結する」は、間接的な電気接続又は直接的な電気接続のいずれかを意味するように意図されている。したがって、第１のデバイスが第２のデバイスに連結する場合、その接続は、直接的な電気接続によるものである場合もあるし、他のデバイス又は接続を介した間接的な電気接続によるものである場合もある。
【００１１】
［詳細な説明］
以下の説明は、本発明のさまざまな実施の形態を対象にする。これらの実施の形態の１つ又は複数は好ましいものとすることができるが、開示した実施の形態は、特許請求の範囲を含めて、開示の範囲を限定するものとして解釈されるべきでなく、それ以外に使用されるべきでない。これに加えて、以下の説明は幅広い用途を有すること、どの実施の形態の説明も、その実施の形態の例示にすぎないことが意図されていること、及び、特許請求の範囲を含めて開示の範囲はその実施の形態に限定されることを暗示するようには意図されていないことが当業者には理解されよう。
【００１２】
ディスクアレイストレージサブシステムで利用可能な大きなキャッシュ及び処理能力を利用することによって、本発明の実施の形態は、サーバインスタンスリカバリを改善することを援助する。このような機能の結果、データベースがアプリケーションにアクセス不能となる時間（前述したリカバリのフェーズ１）が削減され、それによって、全体的なデータベースの可用性が増大する。
【００１３】
一実施の形態では、改善されたインスタンスリカバリを提供する、Ｏｒａｃｌｅ ＲＡＣ等用のディスクアレイが提供される。本発明の実施の形態は、適切なキャッシュ及び処理能力を有するあらゆるデータベースクラスタ又はディスクアレイと共に使用することができる。
【００１４】
ＲＥＤＯログレコード（redo log record）は、タイムスタンプ、ディスクブロックアドレス（ＤＢＡ（disk block address））、データブロック書き込みフラグ（ＤＢＷＦ（Data Block Written Flag））等を含む複数のフィールドを含む。このＲＥＤＯログレコードは、データベースクラスタに対して行われたすべての変更を記録する。インスタンスリカバリに関する限り、ＤＢＷＦが設定されている場合、同じＤＢＡについての以前のすべてのＲＥＤＯログレコードが必要とされないことを示し、このプロセスは「フィルタリング」と呼ばれる。すべてのＲＥＤＯログレコードをスキャンして、フィルタリングを実行することの純粋な（net）効果によって、リカバリセットが生成される。
【００１５】
例示として、データベースクラスタの一例は、１００個のブロック及び数個のインスタンスを含む。リカバリの例示として、ここではインスタンス１と呼ぶ１つだけのインスタンスの実行時の振る舞いのみに注目することにする。このインスタンス１は、所与のアプリケーションを実行しているデータベースクラスタの一部である。この例では、インスタンス１は、以下のオペレーションを実行したものである。
−ＲＥＤＯログレコード１を生成したブロックＤＢＡ１を読み込み、次いで更新した。
−ＲＥＤＯログレコード２を生成したブロックＤＢＡ２を読み込み、次いで更新した。
−ＲＥＤＯログレコード３を生成したブロックＤＢＡ３を読み込み、次いで更新した。
−ブロックＤＢＡ１を更新し、この更新したブロックをディスクに書き込み、ＤＢＷＦフラグセット（Ｏｒａｃｌｅ ＲＡＣシステムの場合、ＢＷＲフラグ）が設定されたＲＥＤＯログレコード４を生成する。
インスタンスリカバリ中、すなわち、インスタンス１に障害があった後、生存している選ばれたインスタンス（たとえばインスタンス２）は、インスタンス１のＲＥＤＯログを読み出す。このＲＥＤＯログは、レコード１、レコード２、レコード３、及びレコード４を含む。ＤＢＷＦフラグセットが設定されたＲＥＤＯログレコード４の読み込み時に、レコード４、及び、ＤＢＡ１に属する以前のすべてのＲＥＤＯログレコード（すなわち、上記例ではレコード１）の双方がトスされる（tossed away）。ＲＥＤＯログレコードをスキャンして適切なレコードを捨てる（throwing away）プロセスは、「フィルタリング」と呼ばれる。この時点における「リカバリセット」は、２つのＲＥＤＯログレコード（レコード２、レコード３）である。フェーズ１の終了時には、データベースは、「リカバリセット」のメンバであるブロック（ＤＢＡ）を除いて、アプリケーションに利用可能になる。リカバリのフェーズ２では、リカバリインスタンスは、「リカバリセット」のＲＥＤＯログレコードをデータベースに適用し、その結果、障害が発生した時以後のデータベースの状態をリカバリさせる。フェーズ２の完了時には、データベースは、データベースクラスタのアプリケーションに完全に利用可能となる。データベースクラスタ全体が利用可能でないリカバリのフェーズ１は、全インスタンスリカバリ時間の約１０％程度の時間を要し、通常、３分から３時間に及ぶことがある。他方、リカバリのフェーズ２は、非常に長い時間を要する可能性がある。
【００１６】
図１を参照して、本発明の一実施の形態によるデータベースクラスタリカバリ技術を強調したフロー図が示されている。１０２において、入力したＲＥＤＯログブロックがディスクアレイキャッシュに保存されて処理される。また、これらのブロックは、１０４において、通常通り、安定したストレージエリアにも書き込まれる。１０６において、好ましくはバックグラウンドオペレーションとして、アレイプロセッサが、ディスクアレイキャッシュの個々の領域で「リカバリセット」を徐々に増加させながら動的に生成して保持する。この「リカバリセット」の生成は、ＲＥＤＯログレコード自体の物理的なコピーを意味するものではない。「リカバリセット」は、データブロック書き込みフラグ（ＤＢＷＦ）セットが設定されたレコードのＲＥＤＯログブロックをアレイプロセッサにスキャンさせることによって生成することができる。ＤＢＷＦフィールドは、インスタンスがグローバルリソースによってカバーされたブロックを書き込んだ時又は廃棄した時にＲＥＤＯログバッファに設定される。Ｏｒａｃｌｅ環境の場合、ＤＢＷＦフィールドは、ブロック書き込みレコード（ＢＷＲ（Block Written Record））フィールドに対応する。これによって、インスタンスから得られたＲＥＤＯログをフィルタリングすることが援助される。一実施の形態では、ＤＢＷＦセットが設定されたあらゆるＲＥＤＯログレコードは通常のアレイキャッシュに残され、ＲＥＤＯログレコード及び（タイムスタンプ情報に基づく）以前のレコードはリカバリセットの一部ではない。
【００１７】
ＤＢＷＦフィールド（たとえば、ＢＷＲ）セットが設定されたレコードの値よりも前のタイムスタンプを有するすべてのレコードは、リカバリセットの一部とはならず、残りのＲＥＤＯログレコードのみがリカバリセットの一部となる一方、すべてのＲＥＤＯログレコードが、１１０において、通常のディスクアレイキャッシュに含められる。Ｏｒａｃｌｅ環境の場合、タイムスタンプは、システム変更番号（ＳＣＮ）を備えることができる。リカバリセットの一部であるＲＥＤＯログレコードは、１１２において、自身のタイムスタンプによって自身をソートすることが可能で、且つ、ソートされた「リカバリセット」を要求に応じてインスタンスに戻すことが可能なデータ構造体によって管理される。次に、このルーチンは、ステップ１０６にループバックする。
【００１８】
一インプリメンテーションは、リカバリセットのあらゆるＲＥＤＯログレコードにつきヘッダデータ構造体を作成することを含む。これらのヘッダデータ構造体は、そのディスクブロックアドレス（ＤＢＡ）に基づいてハッシュテーブルに挿入することができる。このようにして、レコードは、アクセス可能になり、場合によっては、後に「リカバリセット」から除去することができる。ＲＥＤＯログレコードのタイムスタンプ（たとえば、ＯｒａｃｌｅのＳＣＮ）に基づいてソートされた当該ＲＥＤＯログレコードを反映するように、リンクをあらゆるヘッダに追加して、これらのヘッダをリンクすることを可能にすることができる。「リカバリセット」の要求に応じて、ディスクアレイは、上述したリンクを使用してリンクリストを辿ることによって、ＳＣＮによりソートされたインスタンスに「リカバリセット」を返す。
【００１９】
インスタンスの障害が発生するときは常に、選ばれた「リカバリインスタンス」が、その障害のあったインスタンスのＲＥＤＯログ全体の代わりに「リカバリセット」を要求する。「リカバリセット」を要求することは、データベースがその間アプリケーションによってアクセス可能ではない経過時間を削減することに対する、以下の見込まれるプラスの効果の１つ又は複数を有する。すなわち、「リカバリセット」を要求することによって、ストレージアレイからＯｒａｃｌｅリカバリインスタンスへ送り返すのに必要なデータ量が数ギガバイト（ＧＢ）から数メガバイト（ＭＢ）へ削減される；数ＧＢではなく数ＭＢのデータを返すことは、リカバリインスタンスのページングを削減することに大きな影響を与え、このことは、次に、フェーズ１のリカバリ時間に大きな影響を与える；ディスクアレイキャッシュは、オプションとして、ＲＡＣの異なるスレッド／インスタンスのＲＥＤＯログの共有メモリとして機能する唯一の機会を提供し、プロセッサは、必要とされないＲＥＤＯログエントリをさらに取り除くことができ、それによって、「リカバリセット」のサイズをさらに削減することができる；「リカバリセット」を要求することによって、リカバリインスタンスプロセッサにより必要とされる処理時間が節減されて、データベースがアクセス可能でない時間を削減するのを援助する「リカバリセット」が作成される；「リカバリセット」を要求することによって、タイムスタンプ（たとえば、ＳＣＮ値）に基づいてＲＥＤＯログをソート又はマージ／ソートする機会が提供され、これが効果的であるためには、（たとえば、Ｏｒａｃｌｅの）「リカバリインスタンス」は、返されたＲＥＤＯログレコードがすでにソートされたものであることを知っている必要があり、そうでない場合、「リカバリインスタンス」はそれらを再びソートすることになり、これは、「ＮＯＯＰ」オペレーション（ノーオペレーション）となる。
【００２０】
Ｏｒａｃｌｅインスタンスは、そのＲＥＤＯログレコードをディスクアレイのＲＥＤＯログデバイスに書き込む。製造（production）システムは、通常、低いアレイ利用率（たとえば、５０％未満の利用率）で構成される。これは、提案したアルゴリズムを実行するのに十分な処理サイクルがあることを意味する。データがディスクアレイキャッシュで得られている間、上述したフィルタリング及びソートのルーチンは、一般にリアルタイムで実行されるが、このルーチンは、非リアルタイムで実行することもできるし、ほぼリアルタイムで実行することもできる。ディスクアレイにおけるＣＰＵサイクルの可用性は問題ではないと予想されるが、これらのサイクルのスケジューリングは、最適な性能を確保するために慎重に行われる（be handled）べきである。ディスクアレイの通常のオペレーションのように、入ってくるＲＥＤＯログを処理することは、通常のＲＥＤＯログオペレーションの性能に影響を与えることを回避するために、フィルタリング／ソートオペレーションを実行することに優先されるべきである。したがって、ディスクアレイサイクルがアイドルである間にバックグラウンドでフィルタリング／ソートを実行できることが望ましい。上記手法の代替的なものとしては、通常はリアルタイムＯＳを実行する従来のディスクアレイＣＰＵが、ＲＥＤＯログレコードのフィルタリング／ソート及び汎用ＯＳの実行を行うが、そうする代わりに、これらのオペレーションを汎用ＣＰＵが実行するように汎用ＣＰＵを専用化するものがある。
【００２１】
単一のインスタンスの障害では、オプションとして、ＲＥＤＯログレコードをディスクアレイキャッシュに恒久的に保持することができ、これによって、すでにディスクに書き込まれているブロックに関連したＲＥＤＯログレコードを、たとえばＤＢＷＦフラグを使用して取り除くことができる。その結果、ＲＥＤＯログレコードのサブセットのみを返すことができる。ＲＥＤＯログレコード全体をネットワーク上で返し、大部分が必要とされなかったことを後に知っても意味がない。その結果、リカバリセットのサイズは削減されており、ＲＥＤＯログ全体のサイズよりも小さい。リカバリセットのリソースは、障害のあったセットでは変更されているが、障害のあったインスタンスによってディスクにまだ書き込まれていない１組のブロックを含む。
【００２２】
次に図２を参照して、本発明の一実施の形態によるディスクアレイ２００が示されている。一実施の形態では、ディスクアレイ２００は、本明細書で説明したデータベースクラスタリカバリルーチンを含むＨＰ ＳｕｒｅＳｔｏｒｅ Ｅ ＸＰファミリーのディスクアレイ等、Hewlett-Packard社（HP）のＳｔｏｒａｇｅＷｏｒｋｓディスクアレイＸＰを含むことができる。本発明の実施の形態は、多くのタイプのディスクアレイと共に使用でき、開示した実施の形態は単に例示にすぎないことに留意すべきである。
【００２３】
ディスクアレイは、複数のディスクストレージアレイ２０２、データキャッシュ２０４、共有メモリ２０６、クロスバースイッチ／共有メモリインターコネクト２０８、最大４つまでのチップホストインターフェースプロセッサ（ＣＨＩＰ）対２１０〜２１６、データキャッシュ２０４及び共有メモリ２０６の双方に直接アクセスできるだけでなく、ファイバチャネルを通じてディスクストレージアレイ２０２にアクセスできる複数のアレイ制御プロセッサ（ＡＣＰ）２１８を含む。ＣＨＩＰ２１０〜２１６は、アレイ２００へのホスト接続のための接続ポイントを提供する。ＣＨＩＰ２１０〜２１６は、コマンド及び信号をＡＣＰ２１８に送信し、ディスクに対してキャッシュメモリの読み込み／書き込みを行う。追加されたＣＨＩＰ機能は、キャッシュトラックディレクトリにアクセスして当該キャッシュトラックディレクトリを更新すること、データアクセスパターンを監視すること、ホストデバイスタイプをエミュレートすること、及び、アレイ間の複製のための接続ポイントを提供することである。データ制御ブロック２２０は、ＡＣＰ２１８とクロスバスイッチ／共有メモリインターコネクト２０８との間の相互接続を提供する。
【００２４】
本発明の一実施の形態では、ディスクアレイキャッシュ２０４は、データベースクラスタにおける異なるスレッド／インスタンスのＲＥＤＯログの共有メモリとして機能する唯一の機会を提供する。ＣＨＩＰのＣＰＵは、必要とされないＲＥＤＯログエントリをさらに取り除くことができ、それによって、「リカバリセット」のサイズをさらに削減することができる。リカバリセットの削減によって、アプリケーションによるデータベースへのアクセスが不能となる時間、及び、ネットワーク上のデータトラフィック量を削減することが援助される。ＲＥＤＯログレコードがインスタンスによって生成されている間、ＣＨＩＰプロセッサ２１０〜２１６は、前述したようなクラスタリカバリ技術を非同期に実行することができる。
【００２５】
また、本発明の実施の形態は、ＳＣＮ値を使用することによること等、タイムスタンプに基づいてＲＥＤＯログをソート又はマージ／ソートする機会も提供する。Ｏｒａｃｌｅ環境の場合、Ｏｒａｃｌｅリカバリインスタンスは、返されたＲＥＤＯログレコードがすでにソートされたものであることを知っている必要があり、そうでない場合、Ｏｒａｃｌｅリカバリインスタンスはそれらを再びソートすることになる。
【００２６】
図３には、本発明の一実施の形態によるインスタンスリカバリの第１フェーズが示されている。３０２において、ディスクアレイから「リカバリセット」を得るための要求がリカバリインスタンスによって行われる。ステップ３０４において、リカバリセットが、ディスクアレイＣＰＵによって管理され、ＲＥＤＯログレコードのタイムスタンプによって当該ＲＥＤＯログエントリをフィルタリング／ソートする。ステップ３０６において、「リカバリセット」がリカバリインスタンスに返される。Ｏｒａｃｌｅ環境の例示として、リカバリセットは、リカバリを行うＯｒａｃｌｅインスタンスに返される。
【００２７】
本発明で行われるように、いくつかのリカバリ機能をディスクアレイキャッシュ等のインテリジェントなストアに移すことによって、データベースがアクセス不能となる時間中におけるリカバリ時間を削減することが援助され、改善されたデータベース可用性を提供することが援助される。この開示で提示した方法及び装置は、他のデータベース機能にも適用可能であり、一般に、ソート能力及び／又は検索能力を必要とする機能に適用可能である。このような機能をインテリジェントなディスクアレイに移すことは、性能の観点から非常に有益となる可能性がある。
【００２８】
上記説明は、本発明の原理及びさまざまな実施の形態の例示であるように意図されている。当業者には、上記開示を十分に理解すると、多数の変形及び変更が明らかとなるであろう。
【図面の簡単な説明】
【００２９】
【図１】本発明の一実施の形態によるデータベースクラスタリカバリフローを強調したフローチャートである。
【図２】本発明の一実施の形態によるデータベースクラスタのブロック図である。
【図３】本発明の一実施の形態によるインスタンスリカバリの第１フェーズを強調したフローチャートである。
【符号の説明】
【００３０】
２０２・・・ディスクアレイ
２０４・・・データキャッシュ
２０６・・・共有メモリ
２０８・・・クロスバースイッチ／共有メモリインターコネクト
２２０・・・データ制御
【特許請求の範囲】
【請求項１】
ディスクアレイキャッシュ（２０４）にＲＥＤＯログブロックを保持すること、
データブロック書き込みフラグ（ＤＢＷＦ）を使用して前記ＲＥＤＯログブロックをフィルタリングすること、及び、
障害のあった（failed）データベースインスタンスによって生成されたＲＥＤＯログレコードのサブセットであるリカバリセットを前記ディスクアレイキャッシュ（２０４）に生成すること、
を含む、データベースクラスタリカバリ方法。
【請求項２】
前記ＤＢＷＦは、ブロック書き込みレコード（ＢＷＲ）フィールドを備える、請求項１に記載のデータベースクラスタリカバリ方法。
【請求項３】
前記ＲＥＤＯログレコードのタイムスタンプによって前記ＲＥＤＯログレコードを前記ディスクアレイキャッシュ（２０４）内でソートすること、
をさらに含む、請求項１に記載のデータベースクラスタリカバリ方法。
【請求項４】
前記ソートしたリカバリセットを、要求に応じて、前記リカバリを行う、障害のあったデータベースインスタンスに戻すこと、
をさらに含む、請求項３に記載のデータベースクラスタリカバリ方法。
【請求項５】
前記ＲＥＤＯログレコードのタイムスタンプによって前記ＲＥＤＯログレコードをソートすることは、システム変更番号（ＳＣＮ）を使用して前記ＲＥＤＯログレコードをソートすることを含む、請求項３に記載のデータベースクラスタリカバリ方法。
【請求項６】
データベースクラスタリカバリを提供するデータベースクラスタであって、
ディスクアレイと、
前記ディスクアレイに連結されたディスクアレイキャッシュ（２０４）と、
前記ディスクアレイキャッシュにＲＥＤＯログブロックを保存し、データブロック書き込みフラグ（ＤＢＷＦ）フィールドを使用して該ＲＥＤＯログレコードをフィルタリングし、且つ、リカバリセットを表す、該ＲＥＤＯログブロックの小さなサブセットを前記ディスクアレイキャッシュ（２０４）に設けるためのディスクアレイコントローラ（２１８）と、
を備える、データベースクラスタ。
【請求項７】
前記ディスクアレイコントローラ（２１８）は、前記ＲＥＤＯログブロックのタイムスタンプによって前記ＲＥＤＯログブロックをソートする、請求項６に記載のデータベースクラスタ。
【請求項８】
前記リカバリセットは、前記ディスクアレイキャッシュ（２０４）内の、前記ＲＥＤＯログブロックが格納されている（be stored）場所とは別個の領域に格納される、請求項７に記載のデータベースクラスタ。
【請求項９】
前記ディスクアレイコントローラ（２１８）は、前記リカバリセットを動的に作成して保持する、請求項６に記載のデータベースクラスタ。
【請求項１０】
前記ディスクアレイコントローラ（２１８）は、前記リカバリセットの一部である前記ＲＥＤＯログレコードを管理するためのデータ構造体を含む、請求項６に記載のデータベースクラスタ。
【請求項１】
ディスクアレイキャッシュ（２０４）にＲＥＤＯログブロックを保持すること、
データブロック書き込みフラグ（ＤＢＷＦ）を使用して前記ＲＥＤＯログブロックをフィルタリングすること、及び、
障害のあった（failed）データベースインスタンスによって生成されたＲＥＤＯログレコードのサブセットであるリカバリセットを前記ディスクアレイキャッシュ（２０４）に生成すること、
を含む、データベースクラスタリカバリ方法。
【請求項２】
前記ＤＢＷＦは、ブロック書き込みレコード（ＢＷＲ）フィールドを備える、請求項１に記載のデータベースクラスタリカバリ方法。
【請求項３】
前記ＲＥＤＯログレコードのタイムスタンプによって前記ＲＥＤＯログレコードを前記ディスクアレイキャッシュ（２０４）内でソートすること、
をさらに含む、請求項１に記載のデータベースクラスタリカバリ方法。
【請求項４】
前記ソートしたリカバリセットを、要求に応じて、前記リカバリを行う、障害のあったデータベースインスタンスに戻すこと、
をさらに含む、請求項３に記載のデータベースクラスタリカバリ方法。
【請求項５】
前記ＲＥＤＯログレコードのタイムスタンプによって前記ＲＥＤＯログレコードをソートすることは、システム変更番号（ＳＣＮ）を使用して前記ＲＥＤＯログレコードをソートすることを含む、請求項３に記載のデータベースクラスタリカバリ方法。
【請求項６】
データベースクラスタリカバリを提供するデータベースクラスタであって、
ディスクアレイと、
前記ディスクアレイに連結されたディスクアレイキャッシュ（２０４）と、
前記ディスクアレイキャッシュにＲＥＤＯログブロックを保存し、データブロック書き込みフラグ（ＤＢＷＦ）フィールドを使用して該ＲＥＤＯログレコードをフィルタリングし、且つ、リカバリセットを表す、該ＲＥＤＯログブロックの小さなサブセットを前記ディスクアレイキャッシュ（２０４）に設けるためのディスクアレイコントローラ（２１８）と、
を備える、データベースクラスタ。
【請求項７】
前記ディスクアレイコントローラ（２１８）は、前記ＲＥＤＯログブロックのタイムスタンプによって前記ＲＥＤＯログブロックをソートする、請求項６に記載のデータベースクラスタ。
【請求項８】
前記リカバリセットは、前記ディスクアレイキャッシュ（２０４）内の、前記ＲＥＤＯログブロックが格納されている（be stored）場所とは別個の領域に格納される、請求項７に記載のデータベースクラスタ。
【請求項９】
前記ディスクアレイコントローラ（２１８）は、前記リカバリセットを動的に作成して保持する、請求項６に記載のデータベースクラスタ。
【請求項１０】
前記ディスクアレイコントローラ（２１８）は、前記リカバリセットの一部である前記ＲＥＤＯログレコードを管理するためのデータ構造体を含む、請求項６に記載のデータベースクラスタ。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２００６−１５５６２３（Ｐ２００６−１５５６２３Ａ）
【公開日】平成１８年６月１５日（２００６．６．１５）
【国際特許分類】
【出願番号】特願２００５−３４４０２３（Ｐ２００５−３４４０２３）
【出願日】平成１７年１１月２９日（２００５．１１．２９）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
【公開日】平成１８年６月１５日（２００６．６．１５）
【国際特許分類】
【出願日】平成１７年１１月２９日（２００５．１１．２９）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
[ Back to top ]