説明/参照：
Explanation:
ブロックメディアリカバリの概要（リンク）
ブロックメディアリカバリの基本概念
ブロックの破損が自動的に検出されるたびに、RECOVER ... BLOCKコマンドを使用してブロックメディアのリカバリを手動で実行できます。デフォルトでは、Recovery Managerはまず、リアルタイム問合せフィジカル・スタンバイ・データベースで良好なブロックを検索し、ログをフラッシュバックした後、完全またはレベル0の増分バックアップでブロックします。
腐敗したブロックの特定
V $ DATABASE_BLOCK_CORRUPTIONビューには、データベースによって破損したブロックが表示されます

Recovery Manager、ANALYZE、dbvおよびSQL問合せなどのコンポーネント物理的な破損（メディアの破損とも呼ばれます）データベースはブロックを認識しません。チェックサムが無効であるか、ブロックがすべてゼロを含んでいるか、ブロックヘッダーが破損しています。物理的な破損チェックは、デフォルトで有効になっています。 BACKUPコマンドのNOCHECKSUMオプションを指定してチェックサムチェックをオフにすることはできますが、ブロックヘッダーとフッタのチェックなどの他の物理的一貫性チェックは無効にできません。
ブロックには有効なチェックサム、ヘッダーとフッターの一致などがありますが、内容は論理的に矛盾しています。ブロックメディアリカバリは、すべての論理ブロック破損を修復することができない場合があります。このような場合、表領域のポイント・イン・タイム・リカバリや影響を受けたオブジェクトの削除や再作成などの代替リカバリ方法では、破損を修復できます。論理破損チェックは、デフォルトでは無効になっています。 BACKUP、RESTORE、RECOVER、およびVALIDATEコマンドのCHECK LOGICALオプションを指定することでオンにすることができます。
データベースは、ブロックとセグメント間の関係を検証することによっていくつかの破損を検出できますが、個々のブロックのチェックでは検出できません。 V $ DATABASE_BLOCK_CORRUPTIONビューは、この粒度レベルで記録しません。
ブロックメディアリカバリの前提条件（リンク）
RECOVER ... BLOCKコマンドには、次の前提条件が適用されます。
ターゲットデータベースはARCHIVELOGモードで実行し、現在のコントロールでオープンまたはマウントする必要があります

ファイル。
ターゲット・データベースがスタンバイ・データベースの場合は、一貫性のある状態でなければならず、リカバリは不可能です

そのバックアップは破損したファイルより古い必要があります。
壊れたブロックを含むデータファイルのバックアップは、完全バックアップまたはレベル0バックアップでなければならず、

プロキシコピー。
プロキシ・コピー・バックアップのみが存在する場合は、それらをディスク上の非デフォルト位置にリストアできます。この場合、RMANはデータ・ファイルのコピーを考慮し、ブロック・メディア・リカバリ中にブロックを検索します。
RMANは、リカバリにアーカイブREDOログのみを使用できます。 RMANはレベル1の増分を使用できません

バックアップ。ブロック・メディア・リカバリは、失われたREDOログまたはアクセスできないアーカイブREDOログには適用されません。
RMANがフラッシュバック・ログを検索するには、ターゲット・データベースでフラッシュバック・データベースを有効にする必要があります

壊れたブロックの良好なコピーのために。
フラッシュバック・ロギングが有効で、破損していない古いバージョンの破損ブロックが含まれている場合、Recovery Managerはこれらのブロックを使用してリカバリを高速化できます。ターゲット・データベースは、RMANが破損したブロックの良好なコピーをデータベースで検索するために、リアルタイム問合せフィジカル・スタンバイ・データベースに関連付けられている必要があります。