エンドツーエンド・データ検証

バックアップおよびリカバリの基本原則は、バックアップを正常にリストアできることです。バックアップされたデータ・ブロックに物理的な破損がないことを保証するために、バックアップを定期的に検証する必要があります。検証には通常、RMAN RESTORE VALIDATEジョブの定期的な実行と、別のマシンへの完全リストアおよびリカバリ操作の定期的な実行が含まれます。

リカバリ・アプライアンスによって提供されるエンドツーエンド・ブロック検証は、ワークフローの次のステージで行われます。

リカバリ・アプライアンス検証

リカバリ・アプライアンスは、バックアップをディスクに書き込む前に、バックアップ収集フェーズでバックアップ・ストリームを自動的に検証します。リカバリ・アプライアンスは、また、リストア・フェーズ中にバックアップを元のまたは代替のデータベース・サーバーに送信する前に、バックアップを検証します。そのため、手動のRESTORE VALIDATEステップは必要ありません。

また、リカバリ・アプライアンスで実行しているバックグラウンド・タスクによって、デルタ・プール内の仮想完全バックアップの整合性が定期的に検証されます(「デルタ・プール」を参照)。このタスクの目標は、保護された各データベースのそれぞれの仮想完全バックアップの各ブロックを確認し、最小アクティビティが発生しているときにバックグラウンドで動作することです。デフォルトで、ディスク上のデータベースのバックアップの現在のセットの検証が最後に完了した後、検証タスクは14日ごとに実行されます。

データ・ファイルのバックアップの場合と同じように、リカバリ・アプライアンスは、すべての操作においてREDOログ・ブロックの整合性を検証します。これには、保護されたデータベースからREDOを受信し、これを圧縮されたアーカイブ・ログのバックアップ・セットに格納する処理が含まれます。
Oracle Automatic Storage Management(ASM)

Oracle ASMはリカバリ・アプライアンスのためにバックアップ・データおよびREDOデータを格納します。Oracle ASMのミラー・コピーによって冗長性が実現します(「リカバリ・アプライアンスの記憶域の場所」を参照)。

プライマリ・ミラーで破損したブロックが読み取られた場合、リカバリ・アプライアンスはブロックをミラー・コピーから自動的に修復します。このメカニズムによって、切り離されたブロック破損ケースのほとんどが解決されます。
テープ・ライブラリ

リカバリ・アプライアンスがブロックを検証するのは、テープにコピーするときと、テープからリストアするときです(「テープ・アーカイブ」を参照)。
レプリケーション構成のダウンストリーム・リカバリ・アプライアンス

レプリケーションを構成すると、ダウンストリーム・リカバリ・アプライアンスがバックアップ収集フェーズとリストア・フェーズでデータを検証します(「ダウンストリーム・リカバリ・アプライアンスによるバックアップの処理方法」を参照)。

ここで説明したバックアップ検証プロセスはどれも本番データベース・ホストでは行われません。本番リソースはよりクリティカルな操作ワークロードのために解放されます。

ノート:

Oracle最大可用性アーキテクチャのベスト・プラクティスでは、定期的な完全データベース・リカバリ・テストを実行して、操作の実践を確認し、メディア・リカバリ中にのみ発生する可能性のある問題を検出することをお薦めしています。