バックアップのライフサイクル: シナリオ

この項では、図2-1に示すリカバリ・アプライアンス環境でのバックアップの流れにそって、バックアップのライフサイクルを説明します。このサンプル・シナリオでは、各保護データベースは必須である最初のレベル0増分バックアップをリカバリ・アプライアンスにすでに格納しています。基本的なデータ・フローは次のとおりです。

保護データベース、またはこのデータベースを保護しているスタンバイ・データベースが、レベル1増分バックアップをリカバリ・アプライアンスに送信します。

リカバリ・アプライアンスが他のバックアップ・ソリューションと異なる点は、データ・ファイルごとにレベル0バックアップが1つしか必要ないことです。レベル1増分バックアップは、変更時にデータ・ブロックのみがバックアップされるため最も効率的です。

累積レベル1増分バックアップの作成をお薦めします(『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照)。各累積レベル1バックアップでは、ベースラインとして最新の仮想レベル0バックアップが使用されます。通常、この仮想レベル0バックアップは、最新のレベル1バックアップに相当します。

ノート:

レベル1累積バックアップをリカバリ・アプライアンスに組み込めない場合(記憶域の破損などにより)、次のレベル1バックアップが同じ仮想レベル0ベースラインを持つため、リカバリ・アプライアンスは新しいレベル1増分バックアップをシームレスに組み込めます。このため、累積バックアップは、差分バックアップよりも多いオーバーヘッドを持つことはほとんどありません。
リカバリ・アプライアンスが増分バックアップを受信します。

受信したバックアップをすぐに取り出すことができますが、リカバリ・アプライアンスがまだインデックスを付けていません。したがって、対応する仮想完全バックアップはまだありません。リカバリ・アプライアンスがインデックスを付ける前に、保護データベースのリカバリにこのバックアップが必要になった場合、RMANは前の仮想完全バックアップを自動的にリストアし、この増分バックアップを適用します。
リカバリ・アプライアンスが増分バックアップを処理します。

次の操作は非同期で行われます。
- リカバリ・アプライアンスが、バックアップ収集を実行します。リカバリ・アプライアンスは次のようにバックアップを処理します。
  - 保護データベースから送信されたバックアップをスキャンします。
  - 少数のブロックからなるグループに分割して、各データ・ファイルのブロックを個別のデルタ・プールに割り当てます
  - データベースの保護ポリシ-に応じて、グループを適切な記憶域の場所に書き込みます
  - 仮想バックアップ・セットが作成されたら、元のバックアップ・セットを削除します。
    
    ノート:
    
    リカバリ・アプライアンスが、仮想バックアップの作成と同時に元のバックアップを削除できない場合があります。このため、元のバックアップと仮想バックアップの両方が、リカバリ・カタログ内で2つのコピーとして短時間同時に存在する可能性があります。
  バックアップ収集時に、リカバリ・アプライアンスはバックアップのインデックスを付けます。この処理では、各データ・ブロックの内容と物理的な場所に関する情報をメタデータ・データベースに格納します。リカバリ・アプライアンスは保護データベースのリカバリ・カタログを含むため、これで新たにインデックス付けした仮想完全バックアップをRMANが使用できるようになります(リカバリで必要となる場合)。
- リカバリ・アプライアンス・レプリケーションが構成されている場合、リカバリ・アプライアンスはバックアップをダウンストリーム・リカバリ・アプライアンスに転送します。
  
  様々なレプリケーション構成が可能です。図2-1には、1対1の構成が示されています。中央のリカバリ・アプライアンスがアップストリーム・リカバリ・アプライアンス(バックアップの送信側)として、ダウンストリーム・リカバリ・アプライアンス(バックアップの受信側)として機能する別のリカバリ・アプライアンスにバックアップを転送します。図2-1には、ダウンストリーム・リカバリ・アプライアンスがバックアップを第3のリカバリ・アプライアンスに転送するカスケード・レプリケーションも示されます。
- 自動のcopy-to-tapeポリシーが有効になっている場合、リカバリ・アプライアンスがバックアップをテープにアーカイブします。
  
  図2-1では、中央のリカバリ・アプライアンスがOracle Secure Backupソフトウェアを使用してテープ・デバイスと通信しています。また、レプリケーション・スキームで最もダウンストリーム側にあるリカバリ・アプライアンスもバックアップをテープにアーカイブしています。この方法には次のメリットがあります。
  - 冗長性を実現するために、同一のバックアップが2つのテープ・デバイスに存在します。図2-1では、プライマリ・リカバリ・アプライアンスと最もダウンストリーム側のリカバリ・アプライアンスがテープにアーカイブしています。
  - ダウンストリーム・リカバリ・アプライアンスがテープにバックアップすることで、アップストリーム・リカバリ・アプライアンスのテープ・アーカイブ処理の負担を軽減できます。
- リカバリ・アプライアンスは、バックアップおよびREDOが有効であることを定期的に確認します。
  
  リカバリ・アプライアンスは、ディスクにあるバックアップを、インバウンド・レプリケーションとアウトバウンド・レプリケーション中に自動的に検証します。リカバリ・アプライアンスは、テープ・バックアップのクロスチェックを自動的に実行します。データ・ファイルのバックアップの場合と同じように、リカバリ・アプライアンスは、すべての操作においてREDOログ・ブロックの整合性を検証します。これには、保護されたデータベースからREDOを受信し、これを圧縮されたアーカイブ・ログのバックアップ・セットに格納する処理が含まれます。RMAN VALIDATEコマンドを手動で実行する必要はありません。
- リカバリ・アプライアンスが、自動デルタ・プール領域管理を実行します。
  
  このフェーズでは、ディスクとテープ両方で不要になったバックアップや期限切れになったバックアップの削除や、デルタ・プールの最適化が行われます。