ヘッダーをスキップ

Oracle Database バックアップおよびリカバリ・ユーザーズ・ガイド
11g リリース1（11.1）
E05700-03
目次
目次		 索引
索引

戻る 次へ

15 データベース・ファイルおよびバックアップの検証

この章では、データベース・ファイルおよびバックアップの整合性をチェックする方法について説明します。この章の内容は、次のとおりです。

Recovery Managerの検証の概要

この項では、Recovery Managerで検証を行う場合の基本的な概念およびタスクについて説明します。

Recovery Managerの検証の目的

Recovery Managerの検証は、ブロックが破損していないか、およびファイルが欠落していないかどうかを確認することを主に目的としています。また、Recovery Managerを使用して、バックアップがリストア可能かどうかを確認することもできます。Recovery Managerの次のコマンドを使用すると、検証を実行できます。

Recovery Managerの検証の基本的な概念

バックアップ・ファイルが使用できなくなったり、リストアされたデータファイルが破損する可能性がある操作は防止されます。データベースは、自動的に次の処理を実行します。

チェックサムおよび破損ブロック

破損ブロックとは、変更が行われたため、Oracle Databaseでの検出時に予測される内容とは異なる内容になっているブロックのことです。ブロックの破損は、次に示す様々な障害によって発生する可能性があります。ただし、原因はこれらに限定されるわけではありません。

DB_BLOCK_CHECKSUMは、（バックアップ内ではなく）データベース内のデータファイルおよびオンラインREDOログ・ファイルのブロックに対するチェックサムの書込みを制御するデータベース初期化パラメータです。DB_BLOCK_CHECKSUMがtypicalに設定されている場合、データベースは、通常の操作中に各ブロックのチェックサムを計算し、ヘッダーにその値を格納してからブロックをディスクに書き込みます。データベースは、後でディスクからブロックを読み取る場合、チェックサムを再計算し、格納されている値と比較します。値が一致しなかった場合、そのブロックは破損しています。

デフォルトでは、BACKUPコマンドは、各ブロックのチェックサムを計算し、その値をバックアップに格納します。DB_BLOCK_CHECKSUMは、バックアップ内ではなくデータベース内のデータファイルに適用される初期化パラメータであるため、BACKUPコマンドではこの値は無視されます。

物理的および論理的なブロック破損

物理的な破損（メディア破損とも呼ばれます）の場合、ブロックがデータベースで認識されません。チェックサムが無効か、ブロック内容がすべて0（ゼロ）か、またはブロックのヘッダーとフッターが一致していません。

注意:

デフォルトでは、BACKUPコマンドは、各ブロックのチェックサムを計算し、その値をバックアップに格納します。NOCHECKSUMオプションを指定すると、バックアップの作成時にRecovery Managerはブロックのチェックサムを実行しません。 

論理的な破損の場合、ブロックの内容は論理的に一貫性のない状態になっています。論理的な破損の例としては、行ピースまたは索引エントリの破損などがあります。Recovery Managerは、論理的な破損を検出すると、アラート・ログおよびサーバー・セッションのトレース・ファイルにそのブロックを記録します。

デフォルトでは、Recovery Managerは、論理的な破損を確認しません。ただし、BACKUPコマンドでCHECK LOGICALを指定すると、Recovery Managerは、データおよび索引ブロックをテストして、行ピースまたは索引エントリの破損などの論理的な破損がないかどうかを調べ、その結果を自動診断リポジトリ内のアラート・ログに記録します。ファイルのバックアップ時またはリストア時に、Recovery Managerを次の構成で使用すると、Recovery Managerは、検出可能なすべてのタイプのブロック破損を検出します。

Recovery Managerバックアップの破損ブロックの制限

SET MAXCORRUPTコマンドを使用すると、1つのファイルでRecovery Managerバックアップに許容される破損の合計数を設定できます。デフォルトは0（ゼロ）です。つまり、Recovery Managerはいずれの種類の破損ブロックも許容しません。

バックアップ中に破損ブロックが検出された際にMAXCORRUPTの制限を超えていると、Recovery Managerはバックアップを終了します。これ以外の場合、Recovery Managerは、ブロックが破損とマークされていることを示す特別なヘッダーを付けて、破損ブロックをバックアップに書き込みます。VALIDATEコマンドを使用すると、破損とマークされているブロックを特定できます。

Recovery Managerは、バックアップ内のブロック破損を容認できるため、ブロック破損が含まれていると認識されるデータファイルをリストアできます。リストアしたデータファイルをバックアップする場合、Recovery Managerは、MAXCORRUPTを超えているかどうかを計算するときに、すでに破損のマークが付けられているブロックは考慮しません。

参照:

SET MAXCORRUPT構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 

ブロック破損の検出

Oracle Databaseでは、ブロックの破損を検出、修復および監視する様々な方法がサポートされています。方法は、破損がブロック間の破損かブロック内の破損かによって異なります。ブロック内の破損は、ブロック自体内で発生します。この破損は、物理的な破損または論理的な破損のいずれかです。ブロック間の破損の場合、論理的な破損のみがブロック間で発生します。

たとえば、V$DATABASE_BLOCK_CORRUPTIONビューではブロック内の破損が記録され、自動診断リポジトリではすべてのタイプの破損が追跡されます。表15-1に、データベースで様々なタイプのブロック破損を処理する方法を示します。

表15-1    ブロックの破損の検出、修復および監視 
対策  ブロック内の破損  ブロック間の破損 

検出 

Recovery Manager（BACKUPコマンドなど）、DBVERIFYユーティリティなどのすべてのデータベース・ユーティリティによって、ブロック内の破損が検出されます。データベース・プロセスでORA-1578エラーが発生すると、破損が検出され、監視されます。 

DBVERIFYおよびANALYZE文でのみ、ブロック間の破損が検出されます。 

追跡 

V$DATABASE_BLOCK_CORRUPTIONビューに、Recovery Managerコマンド、ANALYZE、dbv、SQL問合せなどのOracle Databaseコンポーネントによって破損とマークされたブロックが表示されます。ブロック内の破損を検出したプロセスでは、このビューおよびADRにブロック破損が記録されます。 

データベースは、ADRでこのタイプのブロック破損を監視します。 

修復 

修復方法には、ブロック・メディア・リカバリ、データファイルのリストア、増分バックアップによるリカバリおよびブロックの新規作成などがあります。ブロック・メディア・リカバリでは、物理的な破損は修復できますが、論理的な破損は修復できません。

修復を行うかブロックが修復されたことを検出するすべてのRecovery Managerコマンドによって、V$DATABASE_BLOCK_CORRUPTIONが更新されます。たとえば、Recovery Managerは、ブロック・メディア・リカバリが正常に実行された後にリポジトリを更新します。BACKUP、RESTOREまたはVALIDATEコマンドによって、ブロックの破損がなくなったことが検出された場合、修正済のブロックがビューから削除されます。 

ブロック間の破損は、オブジェクトの削除、索引の再構築などの手動による方法で修正する必要があります。 

参照:

 

VALIDATEコマンドによるブロック破損の確認

VALIDATEコマンドを使用すると、データベース・ファイル内の物理的および論理的な破損を手動で確認できます。このコマンドでは、BACKUP VALIDATEと同じタイプのチェックが実行されますが、VALIDATEでは、より広範囲のオブジェクトをチェックできます。たとえば、VALIDATE DATAFILE ... BLOCKコマンドを使用すると、個々のブロックを検証できます。

すべてのファイルを検証する場合、Recovery Managerによって、入力ファイルのすべてのブロックが確認されます。バックアップの検証によって破損ブロックが検出された後、Recovery Managerは、破損を示している行を反映して、V$DATABASE_BLOCK_CORRUPTIONビューを更新します。

バックアップ・セット内の1つ以上のバックアップ・ピースが欠落または破損している可能性がある場合は、VALIDATE BACKUPSETを使用します。このコマンドでは、バックアップ・セット内のすべてのブロックがチェックされ、バックアップがリストア可能かどうかが確認されます。ブロックの破損が検出されると、エラーが発行されて検証が停止されます。VALIDATE BACKUPSETでは、ユーザーがチェック対象のバックアップを選択できます。これに対して、RESTOREコマンドのVALIDATEオプションでは、Recovery Managerによって選択が行われます。

VALIDATEを使用してデータベース・ファイルおよびバックアップを確認する手順
  1. Recovery Managerを起動し、ターゲット・データベースに接続します。

  2. 必要なオプションを指定してVALIDATEコマンドを実行します。

    たとえば、データファイル、制御ファイルおよび（使用されている場合は）サーバー・パラメータ・ファイルをすべて検証するには、次のコマンドをRecovery Managerのプロンプトで実行します。

    RMAN> VALIDATE DATABASE;

    また、次の例に示すコマンド形式を使用すると、特定のバックアップ・セットを検証することもできます（出力例も示します）。

    RMAN> VALIDATE BACKUPSET 22;

Starting validate at 17-AUG-06
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=89 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
channel ORA_DISK_1: starting validation of datafile backup set
channel ORA_DISK_1: reading from backup piece 
/disk1/oracle/work/orcva/RDBMS/backupset/2007_08_16/o1_mf_nnndf_TAG20070816T153034_
2g774bt2_.bkp
channel ORA_DISK_1: piece 
handle=/disk1/oracle/work/orcva/RDBMS/backupset/2007_08_16/o1_mf_nnndf_TAG20070816T
153034_2g774bt2_.bkp tag=TAG20070816T153034
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
Finished validate at 17-AUG-06

    次の例に、データファイル内の個々のデータ・ブロックを調べて破損を確認する方法を示します。

    RMAN> VALIDATE DATAFILE 1 BLOCK 10;
 
Starting validate at 17-AUG-06
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00001 name=/disk1/oracle/dbs/tbs_01.f
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1    OK     0              2            127             481907
  File Name: /disk1/oracle/dbs/tbs_01.f
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              36
  Index      0              31
  Other      0              58

Finished validate at 17-AUG-06

データファイルの検証のパラレル化

大規模なデータファイルを検証する必要がある場合、Recovery Managerは、そのファイルを複数のセクションに分割し、各ファイル・セクションをパラレルに処理することによって、作業をパラレル化できます。複数のチャネルが構成されているか、または割り当てられている場合にチャネルで検証をパラレル化するには、VALIDATEコマンドのSECTION SIZEパラメータを指定します。

ファイルのサイズより大きいセクション・サイズを指定した場合、Recovery Managerはファイル・セクションを作成しません。小さなセクション・サイズを指定した結果、セクションの数が256を超えると、Recovery Managerは、正確に256になる値までセクション・サイズを増やします。

データファイルの検証をパラレル化する手順
  1. Recovery Managerを起動し、ターゲット・データベースに接続します。ターゲット・データベースは、マウントまたはオープンされている必要があります。

  2. SECTION SIZEパラメータを指定してVALIDATEを実行します。

    次の例では、2つのチャネルを割り当て、大規模なデータファイルを検証します。セクション・サイズは1200MBです。

    RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
  ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
  VALIDATE DATAFILE 1 SECTION SIZE 1200M;
}

    参照:

     

BACKUP VALIDATEを使用したデータベース・ファイルの検証

BACKUP VALIDATEコマンドを使用すると、次の操作を実行できます。

BACKUP VALIDATEを実行すると、Recovery Managerは、実際のバックアップ時と同様に、バックアップするファイル全体を読み取ります。ただし、実際には、バックアップ・セットもイメージ・コピーも作成しません。

BACKUPSETパラメータ、MAXCORRUPTパラメータまたはPROXYパラメータは、BACKUP VALIDATEを指定して使用することはできません。特定のバックアップ・セットを検証するには、VALIDATEコマンドを実行します。

BACKUP VALIDATEコマンドを使用してファイルを検証する手順
  1. Recovery Managerを起動し、ターゲット・データベースおよびリカバリ・カタログ（使用している場合）に接続します。

  2. BACKUP VALIDATEコマンドを実行します。

    たとえば、次の例のようにコマンドを実行すると、すべてのデータベース・ファイルおよびアーカイブ・ログがバックアップ可能かどうかを検証できます。このコマンドは物理的な破損のみ確認します。

    BACKUP VALIDATE 
  DATABASE 
  ARCHIVELOG ALL;

    物理的な破損に加えて論理的な破損も確認するには、前述のコマンドを次のように少し変更して実行します。

    BACKUP VALIDATE 
  CHECK LOGICAL 
  DATABASE 
  ARCHIVELOG ALL;

    前述の例では、Recovery Managerクライアントは、実際にファイルをバックアップしたときと同じ出力を表示します。Recovery Managerは、ファイルを1つもバックアップできない場合、エラー・メッセージを発行します。たとえば、次のように表示されます。

    RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 08/29/2007 14:33:47
ORA-19625: error identifying file /oracle/oradata/trgt/arch/archive1_6.dbf
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

    参照:

     

リストアする前のバックアップの検証

RESTORE ... VALIDATEを実行すると、Recovery Managerで特定のファイルまたはファイル・セットをバックアップからリストアできるかどうかがテストされます。Recovery Managerによって、使用するバックアップが選択されます。

このコマンドでは、データベースがマウントまたはオープンされている必要があります。データファイルのリストアの検証時にデータファイルをオフラインにする必要はありません。データファイルのバックアップの検証は、バックアップを読み取るのみで、本番データファイルには影響しないためです。

ディスクまたはテープのファイルを検証する場合、Recovery Managerは、バックアップ・ピースまたはイメージ・コピー内のすべてのブロックを読み取ります。また、Recovery Managerは、オフサイトのバックアップの検証も行います。この検証は、Recovery Managerによって出力ファイルが書き込まれないことを除き、実際のリストア操作と同じです。

注意:

RECOVER ... TESTコマンドを使用して、試行リカバリを実行するテスト方法もあります。試行リカバリでは、通常のリカバリと同じ方法でREDOが適用されますが、これはメモリー内のみで行われ、変更は試行後にロールバックされます。 

RESTOREコマンドを使用してバックアップを検証する手順
  1. VALIDATEオプションを指定してRESTOREコマンドを実行します。

    次に、データベースおよびすべてのアーカイブREDOログのリストアの検証例を示します。

    RESTORE DATABASE VALIDATE;
RESTORE ARCHIVELOG ALL VALIDATE;

    Recovery Managerのエラー・スタックが表示されない場合は、後続の手順をスキップします。エラー・メッセージが表示されないということは、実際のリストアおよびリカバリ中にこれらのバックアップを正常に使用できることがRecovery Managerで確認されたということを意味しています。

  2. 出力内にエラー・メッセージおよびRMAN-06026メッセージが表示された場合は、問題の原因を調査します。可能な場合は、Recovery Managerによるバックアップの検証を妨げている問題を解決し、検証を再試行します。

    次のエラーは、Recovery Managerが、指定した1つ以上のファイルを使用可能なバックアップからリストアできないことを意味します。

    RMAN-06026: some targets not found - aborting restore

    次の出力例は、指定したバックアップの読取りでRecovery Managerが問題を検出したことを示しています。

    RMAN-03009: failure of restore command on c1 channel at 12-DEC-06 23:22:30
ORA-19505: failed to identify file "oracle/dbs/1fafv9gl_1_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

    参照:

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

戻る 次へ
Oracle
Copyright © 2003, 2008, Oracle Corporation.
All Rights Reserved.
目次
目次		 索引
索引