ブロック・メディア・リカバリの実行

19 ブロック・メディア・リカバリの実行

データ・ファイル内の個々のデータ・ブロックをリストアおよびリカバリできます。

関連項目:

RECOVERの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
V$DATABASE_BLOCK_CORRUPTIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

19.1 ブロック・メディア・リカバリの概要

ブロック・メディア・リカバリでは、破損データ・ブロックをリカバリすることで、平均リカバリ時間(MTTR)が短くなります。

この項では、次の項目について説明します。

19.1.1 ブロック・メディア・リカバリの目的

ブロック・メディア・リカバリを使用して、データ・ファイル内の1つ以上の破損データ・ブロックをリカバリします。

ブロック・メディア・リカバリには、データファイルのメディア・リカバリにはない次のようなメリットがあります。

リカバリが必要なブロックのみがリストアおよびリカバリされるため、平均リカバリ時間(MTTR)が短くなります。
リカバリ中、影響を受けるデータファイルをオンラインのままにしておくことができます。

ブロック・メディア・リカバリを使用しないと、1つのブロックが破損した場合でも、データファイルをオフラインにしてデータファイルのバックアップをリストアする必要があります。バックアップの作成後にデータファイルに対して生成されたすべてのREDOを適用する必要があります。メディア・リカバリが完了するまで、ファイル全体が使用不可となります。ブロック・メディア・リカバリを使用すると、実際にリカバリされているブロックのみがリカバリ中に使用不可となります。

ブロック・メディア・リカバリは、ブロックが少数でその数がわかっている場合に発生する物理的な破損の問題に特に有効です。ブロックレベルのデータ消失は、通常、広範囲なデータ消失は引き起こさない断続的でランダムなI/Oエラーや、破損したメモリーがディスクに書き込まれることが原因で発生します。ブロック・メディア・リカバリは、データの消失または破損の程度が不明で、データファイル全体のリカバリが必要な場合には適していません。このような場合は、データファイルのメディア・リカバリが最適です。

19.1.2 ブロック・メディア・リカバリの基本的な概念

通常、データベースは、破損が最初に発生したときに、ブロックをメディア破損とマークし、ディスクに書き込みます。それ以降のブロックの読取りは、ブロックがリカバリされるまで正常に実行できません。ブロック・リカバリは、破損とマークされたブロックまたは破損チェックが失敗したブロックに対してのみ実行できます。

通常、ブロック破損は次の場所に表示されます。

LIST FAILURE、VALIDATEまたはBACKUP ... VALIDATEコマンドの結果
V$DATABASE_BLOCK_CORRUPTIONビュー
標準出力のエラー・メッセージ
アラート・ログ
ユーザー・トレース・ファイル
SQLコマンドANALYZE TABLEおよびANALYZE INDEXの結果
DBVERIFYユーティリティの結果
サード・パーティのメディア管理の出力

たとえば、ユーザー・トレース・ファイルに次のメッセージが表示される場合があります。

ORA-01578: ORACLE data block corrupted (file # 7, block # 3)
ORA-01110: data file 7: '/oracle/oradata/trgt/tools01.dbf'
ORA-01578: ORACLE data block corrupted (file # 2, block # 235)
ORA-01110: data file 2: '/oracle/oradata/trgt/undotbs01.dbf'

関連項目:

RECOVER ... BLOCKの構文については、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください

19.1.2.1 ブロック・リカバリおよびスタンバイ・データベースについて

ブロック・リカバリの動作は、データ・ブロックの破損がプライマリ・データベースまたはフィジカル・スタンバイ・データベースのどちらで検出されたかによって異なります。

破損が発生したデータベースがリアルタイム問合せのフィジカル・スタンバイ・データベースに関連付けられている場合、データベースは、自動的にブロック・メディア・リカバリを実行します。プライマリ・データベースは、スタンバイ・データベースで完全な状態に近いブロックのコピーを検索し、見つかった場合は、破損ブロックが発生した問合せに影響を与えることなくブロックを修復します。データベースが破損を修復できない場合のみ、Oracle Databaseの物理ブロック破損のメッセージ(ORA-1578)が表示されます。

ブロックの破損が自動的に検出されると、RECOVER ... BLOCKコマンドを使用してブロック・メディア・リカバリを手動で実行できます。デフォルトでは、RMANは、リアルタイム問合せのフィジカル・スタンバイ・データベース内の完全な状態に近いブロックを検索し、次にフラッシュバック・ログを検索してから、全体またはレベル0の増分バックアップ内のブロックを検索します。

注意:

ブロック・メディア・リカバリを自動的に機能させるには、フィジカル・スタンバイ・データベースをリアルタイム問合せモードにする必要があります。Oracle Active Data Guardライセンスが必要です。

リアルタイム問合せのフィジカル・スタンバイ・データベースで破損データ・ブロックが検出された場合、サーバーは、プライマリ・データベースからブロックのコピーを取得することによって破損の修復を試行します。修復はバックグラウンドで行われ、正常に実行されると、それ以降の問合せが正常に実行されます。スタンバイ・データベースに、次のデータベース初期化パラメータが説明のように構成されている場合、自動ブロック修復が試行されます。

LOG_ARCHIVE_CONFIGパラメータがDG_CONFIGリスト付きで構成され、LOG_ARCHIVE_DEST_nパラメータがDB_UNIQUE_NAME属性付きでプライマリ・データベース用に構成されている

または
FAL_SERVERパラメータが構成され、その値にプライマリ・データベース用のOracle Netサービス名が含まれている

注意:

RMANのVALIDATEコマンドなどによって、検証中に破損ブロックが検出された場合、リカバリは自動的に開始されません。

関連項目:

RECOVER ... BLOCKの構文については、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください
スタンバイ・データベースのリアルタイム問合せオプションの詳細は、Oracle Data Guard概要および管理を参照してください。

19.1.2.2 破損ブロックの識別について

V$DATABASE_BLOCK_CORRUPTIONビューに、RMAN、ANALYZE、SQL問合せなどのデータベース・コンポーネントによって破損とマークされたブロックが表示されます。

次のタイプの破損が、このビューに行として追加されます。

物理的な破損(メディア破損とも呼ばれる)

ブロックがデータベースで認識されません。チェックサムが無効か、ブロックの内容がすべて0(ゼロ)か、またはブロック・ヘッダーが破損しています。

物理的な破損のチェックは、デフォルトで有効になっています。BACKUPコマンドのNOCHECKSUMオプションを指定することによってチェックサムのチェックを無効にすることはできますが、ブロック・ヘッダーやフッターのチェックなどの他の物理的な一貫性チェックを無効にすることはできません。
論理的な破損

ブロックのチェックサムが有効で、ヘッダーとフッターが一致している点などは正常ですが、内容が論理的に一貫性のない状態になっています。ブロック・メディア・リカバリでは、すべての論理ブロック破損を修復できない場合があります。これらの場合、表領域のPoint-in-Timeリカバリなどの代替リカバリ方法、または影響を受けたオブジェクトの削除と再作成によって破損を修復する場合があります。

論理的な破損のチェックは、デフォルトでは無効になっています。BACKUP、RESTORE、RECOVERおよびVALIDATEコマンドのCHECK LOGICALオプションを指定することによって、有効にすることができます。

データベースは、ブロックとセグメント間の関係を検証することによって一部の破損を検出することはできますが、個々のブロックのチェックによって検出することはできません。V$DATABASE_BLOCK_CORRUPTIONビューには、この粒度レベルでは記録されません。

19.1.2.3 ブロック・リカバリ時に欠落しているREDOについて

ブロック・メディア・リカバリでは、リカバリされるブロックの破損していないREDO変更のセットのみが必要です。これは、リカバリの開始から終了までの一連の破損していないREDO変更が必要なデータ・ファイル・リカバリとは異なります。

データファイルのメディア・リカバリと同様に、ブロック・メディア・リカバリでも通常は、アーカイブ・ログが欠落しているか、またはアクセスできない場合はリカバリを実行できません。ただし、アーカイブREDOログ・ファイルの使用可能なコピーが検出された場合は、リストア・フェイルオーバーが試行されます。また、ブロック・メディア・リカバリでは、チェックサム障害となる物理的なREDOの破損がある場合はリカバリを実行できません。ただし、ブロック・メディア・リカバリでは、REDOストリームが連続していない場合に、欠落または破損しているREDOレコードがリカバリするブロックに影響しなければ、リカバリを実行できます。

注意:

ブロック・メディア・リカバリ中、各ブロックは別々にリカバリされるため、一部のブロックでのみリカバリが正常に行われる場合があります。

RMANは、ブロック・メディア・リカバリ中に欠落または破損しているREDOレコードを初めて検出した際、すぐにはエラーを通知しません。これは、リカバリ中のブロックによってこの後のREDOストリームでブロックが作成される場合があるためです。ブロックが再作成されると、それ以前のREDOはブロックの古いインカネーションに適用されていたことになるため、それまでのすべてのREDOは無関係になります。たとえば、ユーザーが表を削除するか、または切り捨ててから、ブロックを他のデータに対して使用した場合、データベースは新しいブロックを作成します。

図19-1に示すように、メディア・リカバリがブロック13で実行されるとします。

図19-1 RMANのメディア・リカバリの実行

「図19-1 RMANのメディア・リカバリの実行」の説明

ブロック・リカバリの開始後、RMANは、変更120がREDOストリームから欠落していることを検出します。ログ・ブロックが破損しているか、またはログを検出できないためです。ブロック13がこの後のREDOストリームで再作成される場合、RMANはリカバリを続行します。変更140で、ユーザーが、ブロック13に格納されているemployees表を削除し、このブロックで新しい表を割り当て、新しい表にデータを挿入したとします。この時点で、データベースはブロック13を新しいブロックとしてフォーマットします。これで、再作成操作の前の一部のREDOが欠落していた場合でも、このブロックでリカバリを続行できるようになります。

関連項目:

RMANリストア・フェイルオーバーについて

19.2 ブロック・メディア・リカバリの前提条件

RECOVER ... BLOCKコマンドを使用してブロック・メディア・リカバリを実行する前に、特定の前提条件を満たす必要があります。

次の前提条件があります。

ターゲット・データベースがARCHIVELOGモードで実行されており、現行の制御ファイルを使用してオープンまたはマウントされている必要があります。
ターゲット・データベースがスタンバイ・データベースの場合は、データベースが一貫性のある状態で、リカバリが開始されておらず、バックアップは破損したファイルよりも古いものである必要があります。
破損ブロックが含まれているデータファイルのバックアップは、全体またはレベル0のバックアップである必要があります。プロキシ・コピーまたは増分バックアップは使用できません。

プロキシ・コピー・バックアップのみが存在する場合は、それらをディスク上のデフォルト以外の場所にリストアできます。この場合、RMANは、プロキシ・バックアップをデータファイルのコピーとみなして、ブロック・メディア・リカバリ中にプロキシ・バックアップ内のブロックを検索します。
RMANは、リカバリでアーカイブREDOログのみを使用できます。

RMANは、レベル1の増分バックアップを使用できません。ブロック・メディア・リカバリでは、アーカイブREDOログが欠落しているか、またはアクセスできない場合はリカバリを実行できません。ただし、REDOレコードが欠落している場合はリカバリを実行できる場合もあります。
RMANがフラッシュバック・ログで破損ブロックの完全な状態に近いコピーを検索するには、フラッシュバック・データベースがターゲット・データベースで有効になっている必要があります。

破損していない古いバージョンの破損ブロックが含まれている場合にフラッシュバック・ロギングが有効になっていると、RMANは、それらのブロックを使用し、リカバリに必要な時間を短縮できます。
RMANがデータベースで破損ブロックの完全な状態に近いコピーを検索するには、ターゲット・データベースがリアルタイム問合せのフィジカル・スタンバイ・データベースに関連付けられている必要があります。

19.3 個々のブロックのリカバリ

データ・ファイル内の個々の破損ブロックをリカバリするには、RECOVER...BLOCKコマンドを使用します。

19.3.1 RECOVER...BLOCKコマンドを使用する個々のブロックのリカバリ

リカバリが必要なブロックを識別し、使用可能なすべてのバックアップを使用してこれらのブロックをリストアおよびリカバリします。

RECOVER...BLOCKコマンドを使用して特定のデータ・ブロックをリカバリするには:

破損ブロックのデータファイル番号およびブロック番号を取得します。
トレース・ファイルおよびアラート・ログを検索する最も簡単な方法は、SQL*Plusをターゲット・データベースに接続し、次の問合せを実行する方法です。
```
SELECT NAME, VALUE FROM V$DIAG_INFO;
```
RMANを開始し、RMANによるデータベース接続の確立の説明に従って、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてターゲット・データベースのルートに接続します。
ターゲット・データベースがマウントまたはオープンされていることを確認します。
SHOW ALLコマンドを実行して、適切なチャネルが事前構成されていることを確認します。
RMANプロンプトで、ファイルおよび破損ブロックのブロック番号を指定してRECOVER ... BLOCKコマンドを実行します。
次の例では、2つのブロックをリカバリします。
```
RECOVER 
  DATAFILE 8 BLOCK 13 
  DATAFILE 2 BLOCK 19;
```
RMANの動作を制御する様々なオプションを指定することもできます。次の例は、ブロックの検索時にタグmondayamが含まれているバックアップのみが使用されることを示しています。FROM BACKUPSETオプションを使用して、RMANによって検索されるバックアップのタイプを制限できます。または、EXCLUDE FLASHBACK LOGオプションを使用して、RMANによるフラッシュバック・ログの検索を制限できます。
```
RECOVER 
  DATAFILE 8 BLOCK 13 
  DATAFILE 2 BLOCK 199
  FROM TAG mondayam;
```

19.3.2 例: データ・リカバリ・アドバイザを使用した個々のブロックのリカバリ

データ・リカバリ・アドバイザを使用して、データ・ブロックの破損による障害を診断および修復できます。この例では、VALIDATE DATABASEコマンドの実行時に破損データ・ブロックが検出されました。

自動修復オプションを生成し、データ・リカバリ・アドバイザを使用して障害を修復するには:

RMANを開始し、RMANによるデータベース接続の確立の説明に従って、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてターゲット・データベースのルートに接続します。
ターゲット・データベースがマウントまたはオープンされていることを確認します。

次のコマンドを使用して、データ・リカバリ・アドバイザで記録された障害を表示します。

LIST FAILURE;

Database Role: PRIMARY

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
5720       HIGH     OPEN      24-APR-14     Datafile 14:
 '/home1/oracle/dbs/tbs_32.f' contains one or more corrupt blocks

ステップ3で表示された障害に対して、修復オプションを生成します。

次のコマンドにより、修復オプションが生成され、自動修復タスクを実行する修復スクリプトが作成されます。

ADVISE FAILURE;

Database Role: PRIMARY

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
---------- -------- --------- ------------- -------
5720       HIGH     OPEN      24-APR-14     Datafile 14:
 '/home1/oracle/dbs/tbs_32.f' contains one or more corrupt blocks

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
no manual actions available

Automated Repair Options
========================
Option Repair Description
------ ------------------
1      Perform block media recovery of block 20 in file 14  
  Strategy: The repair includes complete media recovery with no data loss
  Repair script: /home1/oracle/log/diag/rdbms/db12/hm/reco_287949467.hm

データ・リカバリ・アドバイザによって推奨された自動修復を実行します。

RMANはADVISE FAILUREコマンドで生成された修復スクリプトを使用して、必要な修復を実行します。

REPAIR FAILURE;

Strategy: The repair includes complete media recovery with no data loss
Repair script: /home1/oracle/log/diag/rdbms/db12/hm/reco_287949467.hm
contents of repair script:   
# block media recovery   recover datafile 14 block 20;
Do you really want to execute the above repair (enter YES or NO)? 
yes
executing repair script
Starting recover at 24-APR-14
using channel ORA_DISK_1
channel ORA_DISK_1: restoring block(s)channel 
ORA_DISK_1: specifying block(s) to restore from backup setrestoring blocks of datafile 00014
channel ORA_DISK_1: reading from backup piece /backups/DB121/backupset/2014_04_24/o1_mf_nnndf_TAG20140424T213309_9omsd7vb_.bkp
channel ORA_DISK_1: piece handle=/backups/DB121/backupset/2014_04_24/o1_mf_nnndf_TAG20140424T213309_9omsd7vb_.bkp tag=TAG20140424T213309
channel ORA_DISK_1: restored block(s) from backup piece 1
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:01
starting media recovery
media recovery complete, elapsed time: 00:00:03
Finished recover at 24-APR-14repair failure complete

LIST FAILUREコマンドで複数の障害が表示された場合、特定の障害に対してのみ修復アクションを実行できます。ADVISE FAILUREコマンド出力の自動修復オプション・セクションに表示されたオプション番号を使用して、特定の修復アクションを実行します。

次のコマンドは、自動修復オプション・セクションのオプション2に表示された修復アクションのみを実行します。

REPAIR FAILURE USING ADVISE OPTION 2;

関連項目:

19.4 V$DATABASE_BLOCK_CORRUPTION内のすべてのブロックのリカバリ

RMANはV$DATABASE_BLOCK_CORRUPTIONビューに表示されているすべてのブロックを自動的にリカバリできます。

V$DATABASE_BLOCK_CORRUPTIONに記録されているすべてのブロックをリカバリする手順

SQL*Plusを起動し、ターゲット・データベースに接続します。
V$DATABASE_BLOCK_CORRUPTIONを問い合せて、破損ブロックが存在するかどうかを確認します。たとえば、次の文を実行します。
```
SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
```
RMANを開始し、RMANによるデータベース接続の確立の説明に従ってターゲット・データベースに接続します。
V$DATABASE_BLOCK_CORRUPTION内の破損とマークされたすべてのブロックをリカバリします。
次のコマンドを実行すると、ビューに記録された物理的に破損しているすべてのブロックが修復されます。
```
RMAN> RECOVER CORRUPTION LIST;
```
ブロックは、修復された後、データベースによってV$DATABASE_BLOCK_CORRUPTIONから削除されます。

関連項目:

RECOVER ... BLOCKコマンドの詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください