1. バックアップおよびリカバリ・ユーザーズ・ガイド
  2. ユーザー管理のバックアップおよびリカバリの実行
  3. ユーザー管理のデータベースのフラッシュバックおよびリカバリの実行

30 ユーザー管理のデータベースのフラッシュバックおよびリカバリの実行

ユーザー管理のバックアップおよびリカバリ計画は、RMANを必要としない方法です。ユーザー管理のバックアップおよびリカバリ計画では、Oracle Databaseのフラッシュバック機能を使用します。

30.1 SQL*Plusでのデータベースのフラッシュバックの実行

SQL*Plusを使用して、マルチテナント・コンテナ・データベース(CDB)およびプラガブル・データベース(PDB)でフラッシュバック・データベース操作を実行できます。Oracle Flashback Databaseを使用すると、バックアップからファイルをリストアせずに、データベース全体またはPDB全体を元の状態に戻すことができます。

フラッシュバック・データベースを使用する場合は、データベース用の高速リカバリ領域を作成し、フラッシュバック・ログの収集を有効にする必要があります。フラッシュバック・データベースの要件および準備は、RMANを使用する場合でも、SQL*Plusを使用する場合でも同じです。

関連項目:

30.1.1 SQL*PlusでのCDBのデータベースのフラッシュバックの実行

SQL*Plus FLASHBACK DATABASEコマンドを使用して、マルチテナント・コンテナ・データベース(CDB)全体を前の状態に戻します。このコマンドは、RMANのFLASHBACK DATABASEコマンドと同じ機能を実行します。

前提条件:

フラッシュバック・データベース操作を実行する前提条件は、フラッシュバック・データベースおよびリストア・ポイントの前提条件で説明しています。

SQL*Plusを使用してCDB全体のフラッシュバックを実行する手順は次のとおりです。
  1. SYSDBA権限またはSYSBACKUP権限を持つ共通ユーザーとして、SQL*Plusをrootに接続します。
  2. ターゲット・データベースを問い合せて、フラッシュバックのSCNの範囲を確認します。次のSQL*Plus問合せを実行して、フラッシュバック・ウィンドウの最初と最後のSCNを示します。
    SELECT CURRENT_SCN FROM V$DATABASE;

SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME 
FROM   V$FLASHBACK_DATABASE_LOG;
  3. 必要に応じて他のフラッシュバック機能を使用し、データベースに対する不要な変更のSCNまたは時刻を確認します。
  4. ターゲット・データベースがマウントされていることを確認します。

    次のコマンドで、データベースをMOUNTモードで起動します。 

    SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
  5. FLASHBACK DATABASEコマンドを実行して、CDBを以前のタイムスタンプ、SCNまたはリストア・ポイントに戻します。

    CDBでのフラッシュバック操作の例をいくつか次に示します。

    FLASHBACK DATABASE TO RESTORE POINT cdb_grp;
FLASHBACK DATABASE TO SCN 34468;
FLASHBACK DATABASE TO TIMESTAMP '2013-11-05 14:00:00';
FLASHBACK DATABASE 
  TO TIMESTAMP to_timestamp('2013-11-11 16:00:00', 'YYYY-MM-DD HH24:MI:SS');
  6. 操作が完了したら、データベースを読取り専用でオープンし、問合せを実行して必要なデータがリカバリされていることを確認します。

    選択した目標時点が十分に前の時点でなかった場合は、別のFLASHBACK DATABASE文を使用します。それ以外の場合は、RECOVER DATABASEを使用してデータベースを現在の時点に戻し、別のFLASHBACK DATABASE文を実行します。

  7. 結果が適切である場合は、RESETLOGSオプションを指定してデータベースをオープンします。

    必要に応じて、データ・ポンプ・エクスポートを使用して消失したデータを保存し、RECOVER DATABASEでデータベースを現在の状態に戻して、消失したオブジェクトを再インポートすることもできます。

  8. プラガブル・データベース(PDB)は、CDBがオープンされたときに自動的にはオープンしないため、PDBをオープンします。

    次のコマンドは、rootに接続している場合、すべてのPDBをオープンします。

    ALTER PLUGGABLE DATABASE ALL OPEN;

    いくつかのPDBのみをオープンするには、各PDBを個別にオープンすることもできます。次のコマンドは、rootに接続するとPDB my_pdbをオープンします。 

    ALTER PLUGGABLE DATABASE my_pdb OPEN;

関連項目:

フラッシュバック・データベース機能の動作、フラッシュバック・データベースの使用要件およびフラッシュバック・データベースに必要なフラッシュバック・ログの収集を有効にする方法の詳細は、「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照

30.1.2 SQL*PlusでのPDBのデータベースのフラッシュバックの実行

SQL*PlusのFLASHBACK DATABASEコマンドを使用して、特定のプラガブル・データベース (PDB)を前の状態に戻します。マルチテナント・コンテナ・データベース(CDB)に残っているPDBは、単一のPDBに対するフラッシュバック操作の影響を受けません。

SQL*PlusのFLASHBACK DATABASEコマンドの機能は、RMANのFLASHBACK DATABASEコマンドと同じです。
フラッシュバック・データベース操作を実行する前提条件は、「フラッシュバック・データベースおよびリストア・ポイントの前提条件」で説明しています。

SQL*Plusを使用してPDBのフラッシュバックを実行する手順

  1. SQL*PlusをSYSDBA権限を持つ共通ユーザーとしてrootに接続します。
  2. CDBが開いていることを確認します。

    rootに接続すると、次のコマンドによって、CDBがオープンになっているモードが表示されます。

    SELECT open_mode from V$DATABASE;
  3. FLASHBACK DATABASEコマンドに必要なSCN、リストア・ポイントまたは時点を決定します。
    V$RESTORE_POINTビューを問い合せて、PDBリストア・ポイントのリストを取得します。V$FLASHBACK_DATABASE_LOGは、フラッシュバック操作を実行できる最も古いSCNを表示します。
  4. フラッシュバック・データベース操作を実行する必要のあるPDBがクローズされていることを確認します。他のPDBは、オープンで操作可能な状態でもかまいません。

    rootに接続すると、次のALTER PLUGGABLE DATABASEコマンドがmy_pdbというPDBをクローズします。 

    ALTER PLUGGABLE DATABASE my_pdb CLOSE;
  5. 指定したPDBで、目標時点のフラッシュバック・データベース操作を実行します。

    PDBでのフラッシュバック・データベース操作の例をいくつか次に示します。

    • ローカルUNDOを使用するPDBに対しては次のとおりです。

      FLASHBACK PLUGGABLE DATABASE my_pdb TO SCN 24368;
FLASHBACK PLUGGABLE DATABASE my_pdb TO RESTORE POINT guar_rp;

    • 共有UNDOを使用するPDBで、クリーンPDBリストア・ポイントに対してPDBをフラッシュバックしている場合、フラッシュバック操作の実行にはSQL*Plusのみを使用できます。次に例を示します。 

      FLASHBACK PLUGGABLE DATABASE my_pdb TO RESTORE POINT before_appl_changes;
  6. RESETLOGS付きでPDBをオープンします。

    次のコマンドは、my_pdbという名前のPDBをRESETLOGS付きでオープンします。 

    ALTER PLUGGABLE DATABASE my_pdb OPEN RESETLOGS;

注意:

プロキシPDBでのフラッシュバック操作はサポートされていません。

関連項目:

フラッシュバック・データベース機能の動作、フラッシュバック・データベースの使用要件およびフラッシュバック・データベースに必要なフラッシュバック・ログの収集を有効にする方法の詳細は、「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照

30.2 ユーザー管理のメディア・リカバリの概要

この項では、SQL*Plusを使用したリカバリの概要について説明します。この項では、次の項目について説明します。

30.2.1 ユーザー管理のリストアおよびリカバリ

通常、メディア障害またはユーザー・エラーによって1つ以上のデータファイルが破損したり削除された場合に、ファイルをリストアします。ユーザー管理のリストア操作では、オペレーティング・システムのユーティリティを使用してファイルのバックアップをリストアします。

メディア障害がデータファイルに影響を与えた場合、リカバリの手順は次の条件によって異なります。

  • データベースのアーカイブ・モード(ARCHIVELOGまたはNOARCHIVELOG)

  • メディア障害のタイプ

  • メディア障害によって影響されるファイル(データファイル、制御ファイル、アーカイブREDOログおよびサーバー・パラメータ・ファイルはすべてリストア操作の対象となります。)

永続的または一時的なメディア障害によって、NOARCHIVELOGモードで実行しているデータベースのデータファイルが影響を受けた場合、データベースは自動的に停止します。メディア障害が一時的な場合は、原因となっている問題を解決し、データベースを再起動します。通常、クラッシュ・リカバリによって、コミット済のすべてのトランザクションがオンラインREDOログを使用してリカバリされます。メディア障害が永続的な場合は、「NOARCHIVELOGモードでのデータベースのリカバリ」の説明に従ってデータベースをリカバリします。

表30-1に、ARCHIVELOGモードで実行されているデータベースでファイルを消失した場合に実行するメディア・リカバリについての説明を示します。

表30-1 ユーザー管理のリストア操作

消失したもの 対応

SYSTEM表領域内のデータファイルまたはアクティブなUNDOセグメントを持つデータファイル

データベースは自動的に停止します。ハードウェアの問題が一時的な場合には、問題を解決し、データベースを再起動します。通常、クラッシュ・リカバリによって、消失したトランザクションがリカバリされます。ハードウェアの問題が永続的な場合は、「クローズしているデータベースのリカバリの実行」の説明に従って、バックアップからデータファイルをリストアし、データベースをリカバリします。

SYSTEM表領域内のものではないデータファイル、またはアクティブなロールバック・セグメントまたはUNDOセグメントを含まないデータファイル

影響を受けたデータファイルがオフライン化されますが、データベースはオープンしたままです。データベースの影響を受けていない部分を使用可能なままにしておく必要がある場合には、データベースを停止しないでください。一時オプションを使用して、問題が発生したデータファイルを含む表領域をオフラインにした後、「オープンしているデータベースのリカバリの実行」の説明に従ってリカバリします。

現行の制御ファイルのすべてのコピー

バックアップ制御ファイルをリストアし、RESETLOGSオプションを指定してデータベースをオープンする必要があります。

バックアップがない場合には、制御ファイルを再作成してください。可能であれば、ALTER DATABASE BACKUP CONTROLFILE TO TRACEの出力に含まれるスクリプトを使用します。制御ファイルの構造を現在のデータベース構造と一致させるために追加作業が必要になることがあります。

多重制御ファイルの1つのコピー

影響を受けていない多重制御ファイルの1つを破損または欠落した制御ファイルの場所にコピーして、データベースをオープンします。元の場所に制御ファイルをコピーできない場合は、初期化パラメータ・ファイルを編集して新しい場所を反映するか、または破損した制御ファイルを削除します。その後、データベースをオープンします。

メディア・リカバリに必要な1つ以上のアーカイブ・ログ

リカバリを実行するには、これらのアーカイブ・ログのバックアップをリストアする必要があります。デフォルトの場所またはデフォルト以外の場所にリストアできます。バックアップがない場合には、欠落している最初のREDOログの前のSCNまで不完全リカバリを実行し、RESETLOGSでオープンする必要があります。

サーバー・パラメータ・ファイル(SPFILE)

サーバー・パラメータ・ファイルのバックアップがある場合には、これをリストアします。また、クライアント側の初期化パラメータ・ファイルのバックアップがある場合には、このファイルのバックアップをリストアし、インスタンスを起動した後、サーバー・パラメータ・ファイルを再作成できます。

注意:

Oracle Managed Filesのリストアおよびリカバリは、ユーザーが名前を付けたファイルのリストアおよびリカバリと同じです。

メディア・リカバリの実行には、SQL*PlusのRECOVER文を使用することをお薦めします。SQL文のALTER DATABASE RECOVERも使用できますが、通常、RECOVER文を使用した方が簡単です。どのような種類のメディア・リカバリを開始する場合でも、次の制約に従う必要があります。

  • 管理者権限が必要です。

  • すべてのリカバリ・セッションが互換である必要があります。

  • 別のセッションが不完全メディア・リカバリを実行しているときに、もう1つのセッションで完全メディア・リカバリを開始することはできません。

  • 共有サーバー・プロセスを使用してデータベースに接続している場合は、メディア・リカバリを開始できません。

30.2.2 RECOVERコマンドを使用した自動リカバリ

SQL*Plusを使用してメディア・リカバリを実行する場合、最も簡単な方法は、SQL*PlusのRECOVERコマンドで自動リカバリを実行する方法です。自動リカバリでは、個々のアーカイブREDOログの適用についてSQL*Plusの手動プロンプトなしに、リカバリが開始されます。

SQL*Plusを使用する場合は、リカバリ時に必要となるアーカイブREDOログのデフォルト・ファイル名の適用を自動化するために、次のオプションを使用できます。

  • RECOVERコマンドを発行する前にSET AUTORECOVERY ONを発行する。デフォルトであるSET AUTORECOVERY OFFを実行した場合は、ファイル名を手動で入力するか、[Enter]キーを押して、提示されたファイル名を受け入れる必要があります。

  • RECOVERコマンドのオプションとしてAUTOMATICキーワードを指定する。

いずれの場合にも、必要なファイルが正しい場所に正しい名前で存在しているかぎりRECOVERコマンドを発行したときに介入は必要ありません。データベースでREDOログ・ファイルが正常に適用された場合は、次のメッセージが戻されます。 

Log applied.

その後、順序内の次のREDOログを求めるプロンプトが表示されます。最後に適用されたログが最後の必要なログである場合は、リカバリが終了します。

自動リカバリに使用されるファイル名は、LOG_ARCHIVE_FORMATの値とLOG_ARCHIVE_DEST_nの値を連結して導出されます。このnは、有効なすべてのローカル出力先の中で最大の値です。たとえば、データベース・インスタンスで初期化パラメータの次のような設定が有効になっているとします。 

LOG_ARCHIVE_DEST_1 = "LOCATION=/arc_dest/loc1/" 
LOG_ARCHIVE_DEST_2 = "LOCATION=/arc_dest/loc2/"
LOG_ARCHIVE_DEST_STATE_1 = DEFER 
LOG_ARCHIVE_DEST_STATE_2 = ENABLE 
LOG_ARCHIVE_FORMAT = arch_%t_%s_%r.arc

この場合、SQL*Plusは自動的に/arc_dest/loc2/arch_%t_%s_%r.arcというファイル名を提示します(この%tはスレッド、%sは順序、%rはRESETLOGのIDです)。

関連項目:

30.2.2.1 SET AUTORECOVERYを使用した自動リカバリ

データファイル・バックアップをリストアした後、SET AUTORECOVERY ONコマンドを実行すると、自動リカバリが有効になります。たとえば、SQL*Plusに次のコマンドを入力すると、自動リカバリを実行し、データベースをオープンできます。 

STARTUP MOUNT
SET AUTORECOVERY ON
RECOVER DATABASE
ALTER DATABASE OPEN;

注意:

SQL*PlusのRECOVERコマンドを発行した後で、リカバリで考慮されたすべてのファイルをV$RECOVERY_FILE_STATUSビューで表示できます。V$RECOVERY_STATUSビューで、各ファイルのステータス情報にアクセスできます。これらのビューは、リカバリ・セッションの終了後はアクセスできません。

30.2.2.2 RECOVERコマンドのAUTOMATICオプションを使用した自動リカバリ

SET AUTORECOVERYを使用して自動リカバリを有効にする他にも、RECOVERコマンドでAUTOMATICキーワードを指定することもできます。たとえば、SQL*Plusに次のコマンドを入力すると、自動リカバリを実行し、データベースをオープンできます。 

STARTUP MOUNT
RECOVER AUTOMATIC DATABASE
ALTER DATABASE OPEN;

Oracle Real Application Clusters構成を使用しているとき、ユーザーが不完全リカバリを実行するか、またはバックアップ制御ファイルを使用する場合は、最初のREDOスレッドから最初のアーカイブREDOログ・ファイルの名前を算出することのみが可能です。その他のREDOスレッドからは、最初のログ・ファイルを手動で適用する必要があります。特定のスレッド内の最初のログ・ファイルが提供されると、データベースは、このスレッド内の後続のログの名前を提示できます。

30.2.3 アーカイブ・ログがデフォルトの場所にある場合のリカバリ

アーカイブREDOログ・ファイルがデフォルトの場所にある場合、リカバリを実行するために必要な追加設定はありません。

リカバリ中、ログが必要になると、データベースによってファイル名が提示されます。SQL*Plusを使用して、自動ではないメディア・リカバリを実行する場合には、出力は次の形式で表示されます。

ORA-00279: change 53577 generated at 11/26/02 19:20:58 needed for thread 1
ORA-00289: suggestion : /oracle/oradata/trgt/arch/arcr_1_802.arc
ORA-00280: change 53577 for thread 1 is in sequence #802
Specify log: [<RET> for suggested | AUTO | FROM logsource | CANCEL ]

ALTER DATABASE ... RECOVER文を使用した場合にも、同様のメッセージが戻されます。ただし、プロンプトは表示されません。

初期化パラメータLOG_ARCHIVE_DEST_n(このnは有効なすべてのローカル出力先の中で最大の値)およびLOG_ARCHIVE_FORMATの現在の値を連結し、制御ファイルのログ履歴情報を使用して、提示されるアーカイブ・ログのファイル名が構築されます。次のような設定が可能です。 

LOG_ARCHIVE_DEST_1 = 'LOCATION = /oracle/oradata/trgt/arch/'
LOG_ARCHIVE_FORMAT = arcr_%t_%s.arc

SELECT NAME FROM V$ARCHIVED_LOG;

NAME
----------------------------------------
/oracle/oradata/trgt/arch/arcr_1_467.arc
/oracle/oradata/trgt/arch/arcr_1_468.arc
/oracle/oradata/trgt/arch/arcr_1_469.arc

このため、すべての必要なアーカイブ・ログ・ファイルがLOG_ARCHIVE_DEST_1という出力先に置かれ、LOG_ARCHIVE_FORMATの値が変更されていない場合は、データベースによってログ・ファイルが提示および適用され、メディア・リカバリが自動的に実行されます。

30.2.4 アーカイブ・ログがデフォルト以外の場所にある場合のリカバリ

アーカイブREDOログ・ファイルがデフォルトではない場所に格納されている場合、メディア・リカバリを実行するには、アーカイブREDOログ・ファイルの場所を指定する必要があります。

アーカイブ・ログがデフォルトの場所にない場合、メディア・リカバリを実行するときに、次の相互に排他的なオプションがあります。

  • アーカイブREDOログの場所を指定するLOG_ARCHIVE_DEST_nパラメータを編集し、通常どおりにリカバリします。

    このタスクについては、「アーカイブ・ログの場所の再設定」を参照してください。

  • リカバリ前にSQL*PlusのSET文を使用してデフォルト以外のログの場所を指定するか、RECOVERコマンドのLOGFILEパラメータを使用します。

    このタスクについては、「アーカイブ・ログの場所の変更」を参照してください。

30.2.4.1 アーカイブ・ログの場所の再設定

初期化パラメータ・ファイルを編集するか、ALTER SYSTEM文を発行して、アーカイブREDOログのデフォルトの場所を変更できます。

リカバリ前にアーカイブ・ログのデフォルトの場所を変更する手順

  1. オペレーティング・システム・ユーティリティを使用して、アーカイブ・ログをデフォルト以外の場所にリストアします。たとえば、次のように入力します。
    % cp /backup/arch/* /tmp/
  2. アーカイブ・ログ・パラメータの値を、デフォルト以外の場所に変更します。インスタンスが起動されているときにALTER SYSTEM文を発行するか、初期化パラメータ・ファイルを編集した後にデータベース・インスタンスを起動します。たとえば、インスタンスの停止中にパラメータ・ファイルを次のように編集します。
    LOG_ARCHIVE_DEST_1 = 'LOCATION=/tmp/'
LOG_ARCHIVE_FORMAT = arcr_%t_%s.arc
  3. SQL*Plusを使用して、編集済の初期化パラメータ・ファイルを指定して新しいインスタンスを起動した後、データベースをマウントします。たとえば、次のように入力します。
    STARTUP MOUNT
  4. 通常どおりにメディア・リカバリを開始します。たとえば、次のように入力します。
    RECOVER DATABASE
30.2.4.2 アーカイブ・ログの場所の変更

場合によっては、アーカイブの出力先パラメータの現在の設定を変更して、アーカイブ・ログ・ファイルの入力元を変更することもできます。

SET LOGSOURCEを使用して、デフォルト以外の場所のアーカイブ・ログをリカバリする手順

  1. オペレーティング・システム・ユーティリティを使用して、アーカイブREDOログを代替の場所にコピーします。たとえば、次のように入力します。
    % cp $ORACLE_HOME/oradata/trgt/arch/* /tmp
  2. SQL*Plus内でリカバリ操作のための代替場所を指定します。SET文のLOGSOURCEパラメータを使用します。たとえば、SQL*Plusを起動して次のように実行します。
    SET LOGSOURCE "/tmp"
  3. オフライン表領域をリカバリします。たとえば、オフライン表領域usersをリカバリするには、次のコマンドを実行します。
    RECOVER AUTOMATIC TABLESPACE users
  4. また、SET LOGSOURCEを実行せずに、次のコマンドを実行することもできます。
    RECOVER AUTOMATIC TABLESPACE users FROM "/tmp"

注意:

REDOログのソースを変更しても、アーカイブされているオンラインREDOログ・グループのアーカイブREDOログの出力先は影響を受けません。

30.2.5 ストレージ・スナップショットの最適化を使用したリカバリ

ストレージ・スナップショットの最適化では、データベースがバックアップ・モードでないときに取得したデータベースのサード・パーティ・スナップショットを使用して、現在の時点またはスナップショットが作成された後の指定した時点のいずれかにデータベースをリカバリできます。ストレージ・スナップショットが作成されたときにデータベースがバックアップ・モードでなかった場合は、スナップショットがOracle要件に準拠している場合のみ、このスナップショットを使用してリカバリを実行できます。「サード・パーティのスナップショット・テクノロジを使用したバックアップの作成」を参照してください。これらの条件を満たす場合、RMANまたはSQL*Plusを使用して、他のバックアップ方法と同じ基本的なリカバリ・ステップに従うことができます。

ストレージ・スナップショットが、ストレージ・スナップショットの最適化を使用するための要件に準拠しない場合は、データファイルをバックアップ・モードにしてスナップショットを作成します。このようなスナップショットを使用してリカバリを実行するには、SQL*Plusを使用したデータベースの完全リカバリの実行またはデータベースの不完全リカバリの実行で説明する手順を使用します。

スナップショット・リカバリの時間の指定

データベースがバックアップ・モードでないときにストレージ・スナップショットが作成された場合は、データベースのリカバリにこのスナップショットを使用する際にSNAPSHOT TIMEオプションを指定する必要があります。SNAPSHOT TIMEオプションは、RMANおよびSQL*PlusのRECOVERコマンドの両方で使用できます。SNAPSHOT TIMEオプションを使用して指定する時間は、スナップショットの完了直後の時間である必要があります。間違った時間を指定した場合、データベースが修復不能な状態で破損する可能性があります。

スナップショットが実行されるストレージ・アレイとOracle Databaseをホストしているマシンのタイム・クロックが完全に同期していない可能性があるため、SNAPSHOT TIMEオプションで指定する時間に数秒追加することをお薦めします。これにより、スナップショットが取得された時点より前の時点にリカバリされることでファイルが一貫性のない状態になる可能性を避けるのに役立ちます。

SNAPSHOT TIME句を含むRECOVERコマンドで指定するすべての時間は、Oracle Databaseホストのタイム・ゾーンに存在することを想定しています。ただし、ストレージ・アレイのタイム・クロックはOracle Databaseホストとは異なるタイムゾーンに存在することはできます。ストレージ・アレイが異なるタイムゾーンでのスナップショット時間をレポートしている場合、SNAPSHOT TIMEオプションで時間を指定する際に、違いを考慮する必要があります。

注意:

UNTILオプションで指定したリカバリ・ポイントは、SNAPSHOT TIMEより早い時間を指定できません。

例: ストレージ・スナップショットを使用したリカバリ

この項の例では、RECOVER DATABASEコマンドを使用して、スナップショットを使用したリカバリを実行します。RECOVER DATABASEコマンドは、RMANまたはSQL*Plusから使用できます。ただし、UNTIL CANCEL句はSQL*Plusでのみ有効です。

データベースを完全にリカバリするには、次の手順を実行します。

RECOVER DATABASE;

特定のスナップショットを使用してデータベースをリカバリするには、次の手順を実行します。

この例では、8月15日午後2時に作成されたスナップショットを使用して、データベースをリカバリしています。UNTIL TIME句には、スナップショット後の任意の時間を指定できます。 

RECOVER DATABASE UNTIL TIME '10/15/2012 15:00:00' SNAPSHOT TIME '10/15/2012 14:00:00';

アーカイブREDOログ・ファイルを使用して部分的なリカバリを実行するには、次の手順を実行します。

この例では、8月15日午後2時に作成したスナップショットからのログ・ファイルを使用します。 

RECOVER DATABASE UNTIL CANCEL SNAPSHOT TIME '10/15/2012 14:00:00';

30.2.6 ユーザー管理のリカバリ中のリカバリの取消し

メディア・リカバリを開始した後で中断する必要がある場合は、REDOログ・ファイルのプロンプトに対してCANCELと入力します。また、個々のデータファイルのリカバリの実行時または自動リカバリの実行時に終了する必要がある場合は、オペレーティング・システムの割込みシグナルを使用します。 リカバリが取り消された後、RECOVERコマンドを使用してリカバリを再開できます。リカバリは、取り消された位置から再開されます。

30.2.7 パラレル・メディア・リカバリ

Oracle Databaseは、メディア・リカバリのロールフォワード・フェーズのパフォーマンスを向上するために、デフォルトでパラレル・メディア・リカバリを使用します。メディアのパラレル・リカバリでは、ロールフォワード時に各データ・ブロックに別のプロセスを割り当てる分業体制を使用することで、処理の効率を高めています。使用されるプロセスの数は、CPU_COUNT初期化パラメータで指定されます。これは、デフォルトではシステム上のCPUの数と同じです。たとえば、CPU_COUNTが4のシステム上でパラレル・リカバリを実行した場合、リカバリ対象のデータファイルが1つのみである場合には、4つの起動されたプロセスがアーカイブ・ログからブロックを読み取り、REDOを適用します。

一般的に、メディア・リカバリはデータ・ブロックの読取りおよび書込みによって制限されます。パラレル・リカバリでは、パフォーマンスを向上させるために、システムで利用可能なI/O帯域幅がすべて使用されます。システムのI/Oボトルネックが存在するか、非同期I/Oが十分にサポートされていない場合を除いて、パラレル・リカバリによってリカバリのパフォーマンスが向上する可能性があります。

パラレル・リカバリが実行されるデフォルトの動作を変更するには、NOPARALLELオプションを指定してSQL*PlusのRECOVERコマンドを使用するか、またはRECOVER PARALLEL 0を使用します。RECOVERY_PARALLELISM初期化パラメータでは、インスタンス・リカバリまたはクラッシュ・リカバリのみが制御されます。メディア・リカバリは、RECOVERY_PARALLELISMで使用される値の影響を受けません。

関連項目:

SQL*PlusのRECOVER ... PARALLELおよびNOPARALLELコマンドの詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください。

30.3 SQL*Plusを使用したデータベースの完全リカバリの実行

通常、メディア障害によって1つ以上のデータファイルにアクセスできなくなった場合に、データベースの完全リカバリを実行します。データベースの完全リカバリを実行中に、使用可能なすべてのREDOを使用し、データベースを現行のSCNまでリカバリします。

V$RECOVER_FILEビューに、リカバリが必要なファイルが示されます。状況に応じて、データベース全体でリカバリを実行することも、個々の表領域またはデータファイルでリカバリを実行することもできます。完全リカバリの場合は、RESETLOGSオプションを指定してデータベースをオープンする必要はないため、最初に一部のデータファイルのリカバリを行ってから、後で残りのデータファイルのリカバリを行うこともできます。

この項のトピックでは、完全メディア・リカバリ操作に必要なステップについて説明します。

関連項目:

30.3.1 クローズしているデータベースのリカバリの実行

データベースがオープン状態でないときに完全リカバリを実行すると、1回の操作ですべての破損したデータファイルをリカバリしたり、個別の操作で破損した各データファイルの個別のリカバリを実行できます。

この手順の前提条件は次のとおりです:

  • 現行の制御ファイルが使用可能です。

  • 必要なすべてのデータファイルのバックアップがあります。

  • 必要なすべてのアーカイブREDOログが使用可能です。

破損または欠落しているデータファイルをリストアおよびリカバリする手順

  1. データベースがオープンしている場合は、V$RECOVER_FILEを問い合せ、リカバリする必要があるデータファイルおよびリカバリする必要がある理由を確認します。

    Point-in-Timeリカバリではなく完全リカバリの実行を計画している場合は、データベース全体ではなくリカバリが必要なデータファイルのみをリカバリすることができます。Point-in-Timeリカバリの場合、RMAN TSPITRを実行しないかぎり、すべてのデータファイルをリストアおよびリカバリする必要があります。また、フラッシュバック・データベースも使用できますが、すべてのデータファイルが影響を受けるため、データベース全体が過去の状態に戻ります。

    V$RECOVER_FILEビューを問い合せると、リカバリが必要なデータファイルを、そのステータス情報とエラー情報とともにデータファイル番号で表示できます。 

    SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME 
FROM V$RECOVER_FILE;

    注意:

    V$RECOVER_FILEは、バックアップからリストアされた制御ファイル、またはデータファイルに影響を及ぼすメディア障害の発生後に再作成された制御ファイルには使用できません。リストアされた制御ファイルまたは再作成された制御ファイルには、V$RECOVER_FILEを正確に更新するために必要な情報が含まれていません。

    データファイル番号とV$DATAFILEおよびV$TABLESPACEビューを使用することによって便利な結合を実行して、データファイルおよび表領域の名前を取得することもできます。

    ERROR列で、リカバリが必要な各ファイルに関する問題を識別します。

  2. V$ARCHIVED_LOGおよびV$RECOVERY_LOGビューを問い合せて、必要なアーカイブREDOログ・ファイルを確認します。

    V$ARCHIVED_LOGには、すべてのアーカイブREDOログのファイル名が表示されます。V$RECOVERY_LOGには、データベースでメディア・リカバリを実行する必要があるアーカイブREDOログのみが表示されます。 後者のビューには、LOG_ARCHIVE_FORMATパラメータを使用して指定したネーミング規則に基づいて、考えられるファイルの名前も表示されます。

    注意:

    V$RECOVERY_LOGは、データファイルのメディア・リカバリが必要な場合にのみ移入されます。このため、ユーザー・エラーからのリカバリなど、計画されたリカバリにはこのビューは役に立ちません。

    データファイルのリカバリが必要な場合に、データファイルのバックアップが存在しないときは、データベースにデータファイルが追加された後に生成されたすべてのREDOが必要です。

  3. デフォルトの場所ですべてのアーカイブ・ログが使用可能な場合は、ステップ4にスキップします。

    一部のアーカイブ・ログをリストアする必要があるときに、使用可能な領域が十分にある場合は、LOG_ARCHIVE_DEST_1で指定された場所に必要なアーカイブREDOログ・ファイルをリストアします。メディア・リカバリ中に正しいログが必要になると、自動的にログが検索されます。たとえば、LinuxまたはUNIXでは、次のコマンドを入力します。 

    % cp /disk2/arch/* $ORACLE_HOME/oradata/trgt/arch

    使用可能な領域が十分にない場合は、必要なアーカイブREDOログ・ファイルの一部またはすべてを別の場所にリストアします。

  4. データベースがオープンしている場合は、データベースを停止します。次に例を示します。
    SHUTDOWN IMMEDIATE
  5. メディアを検査して問題の原因を確認します。

    メディア障害の原因であるハードウェアの問題が一時的なもので、データが破損していない場合(ディスクやコントローラの停電が発生した場合など)は、メディア・リカバリは必要ありません。データベースを起動して、通常の操作を再開します。

    問題を解決できない場合は、ステップ6に進みます。

  6. ファイルが永続的な損傷を受けた場合には、破損したファイルの最新のバックアップを識別します。メディア障害によって破損したデータファイルのみをリストアします。破損していないデータファイルまたはオンラインREDOログ・ファイルはリストアしないでください。

    たとえば、破損したファイルがORACLE_HOME/oradata/trgt/users01.dbfのみであり、このファイルの最新のバックアップが/backup/users01_10_24_02.dbfであるとします。特定のデータファイルのバックアップがない場合には、リカバリするための空の置換ファイルを作成できます。

  7. オペレーティング・システム・ユーティリティを使用して、デフォルトの場所または新しい場所にデータファイルをリストアします。たとえば、LinuxまたはUNIXユーザーがusers01.dbfをデフォルトの場所にリストアする場合は、次のコマンドを入力できます。
    % cp /backup/users01_10_24_06.dbf $ORACLE_HOME/oradata/trgt/users01.dbf

    次のガイドラインに従って、データファイルのバックアップをリストアする場所を決定します。

    • ハードウェアの問題が解決され、デフォルトの場所にデータファイルをリストアできる場合は、デフォルトの場所にデータファイルをリストアし、メディア・リカバリを開始します。

    • ハードウェアの問題が持続し、元の場所にデータファイルをリストアできない場合は、代替のストレージ・デバイスにデータファイルをリストアします。ALTER DATABASE RENAME FILE文を使用して、これらのファイルの新しい場所を制御ファイルで指定します。『Oracle Database管理者ガイド』を参照してください。

    • データファイルをRAWディスクまたはRAWパーティションにリストアする場合の方法は、ファイル・システム上のファイルにリストアする場合と基本的に同じです。ただし、RAWデバイス上のファイルのネーミング規則(オペレーティング・システムよって異なる)に注意して、RAWデバイスをサポートするオペレーティング・システム・ユーティリティを使用する必要があります。

  8. 管理者権限でデータベースに接続します。新しいインスタンスを起動して、データベースをマウントします(ただし、オープンはしません)。たとえば、次のように入力します。
    STARTUP MOUNT
  9. 1つ以上の破損したデータファイルを代替の場所にリストアした場合は、データベースの制御ファイルを更新して、新しいデータファイル名を反映させます。たとえば、表領域usersのデータファイルのファイル名を変更するには、次のように入力します。
    ALTER DATABASE RENAME FILE '?/oradata/trgt/users01.dbf' TO
                           '/disk2/users01.dbf';
  10. 現行の制御ファイルに通常付随するデータファイルのリストを調べるか、V$DATAFILEビューを問い合せて、すべてのデータファイルのデータファイル名およびステータスを取得します。たとえば、次のように入力します。
    SELECT NAME,STATUS FROM V$DATAFILE;
  11. リカバリが必要なすべてのデータファイルがオンラインにされていることを確認します。唯一の例外は、NORMALモードでオフラインにされたオフライン表領域内のデータファイルまたは読取り専用表領域内のデータファイルです。たとえば、/oracle/dbs/tbs_10.fという名前のデータファイルを確実にオンラインにするには、次のように入力します。
    ALTER DATABASE DATAFILE '/oracle/dbs/tbs_10.f' ONLINE;

    指定されたデータファイルがすでにオンラインにされている場合は、この文は無視されます。必要に応じて、次の例に示すように、すべてのデータファイルを同時にオンラインにするスクリプトを作成します。

    SPOOL onlineall.sql
SELECT 'ALTER DATABASE DATAFILE '''||name||''' ONLINE;' FROM V$DATAFILE;
SPOOL OFF

SQL> @onlineall
  12. アーカイブREDOログを代替格納場所にリストアした場合は、SQL*Plusで SETコマンドのLOGSOURCEパラメータを使用して、メディア・リカバリの前の場所を特定できます。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。
    SET LOGSOURCE /tmp

    あるいは、ステップ12をスキップして、ステップ13に示すようにRECOVERコマンドでFROMパラメータを使用します。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。 

    RECOVER AUTOMATIC FROM '/tmp' DATABASE

    注意:

    REDOログのソースを変更しても、アーカイブされているオンラインREDOログ・グループのアーカイブREDOログの出力先は影響を受けません。

  13. データベース、表領域またはデータファイルのリカバリのための文を発行します。たとえば、次のいずれかのRECOVERコマンドを入力します。
    RECOVER AUTOMATIC DATABASE   # whole database
RECOVER AUTOMATIC TABLESPACE users   # specific tablespace
RECOVER AUTOMATIC DATAFILE '?/oradata/trgt/users01.dbf'; # specific data file

    アーカイブREDOログの適用を自動化しない場合は、ログが提示されるたびに、そのログを適用するかどうかを選択する必要があります。リカバリを自動化した場合は、ログは自動的に適用されます。必要なすべてのアーカイブおよびオンラインREDOログが、リストアされたデータファイルに適用されるまで、リカバリは続行されます。メディア・リカバリが完了すると、次のように通知されます。

    Media recovery complete.

    完全メディア・リカバリにアーカイブREDOログ・ファイルが必要でない場合は、必要なすべてのオンラインREDOログ・ファイルが適用され、リカバリが終了します。

  14. リカバリ完了後に、データベースをオープンして使用します。
    ALTER DATABASE OPEN;
  15. アーカイブ・ログを適用し、オフライン・ストレージに各アーカイブ・ログ・グループのコピーがまだ存在していることを確認した後、アーカイブREDOログ・ファイルのリストアされたコピーを削除してディスク領域を解放します。次に例を示します。
    % rm /tmp/*.arc

    関連項目:

30.3.2 オープンしているデータベースのリカバリの実行

データベースがオープン状態のときにデータベースのSYSTEM以外のデータファイルの完全リカバリを実行できます。

この手順の前提条件は次のとおりです:

  • 現行の制御ファイルが使用可能です。

  • 必要なすべてのデータファイルのバックアップがあります。

  • 必要なすべてのアーカイブREDOログが使用可能です。

データベースをオープンしているときにメディア障害が発生した場合は、破損していないデータファイルはオンラインのまま使用できる場合があります。データベース・ライターがファイルに書き込めない場合は、破損したファイルは自動的にオフラインにされますが、破損したファイルを含む表領域はオフラインにされません。データベース・ライターがデータファイルをオープンできない場合は、引き続きエラーが戻されます。破損したファイルを読み取れない問合せはエラーを戻しますが、問合せが失敗したためにデータファイルがオフラインにされることはありません。たとえば、SQL問合せを実行すると、次のような出力が表示される場合があります。

ERROR at line 1:
ORA-01116: error in opening database file 3
ORA-01110: data file 11: '/oracle/oradata/trgt/cwmlite02.dbf'
ORA-27041: unable to open file
SVR4 Error: 2: No such file or directory
Additional information: 3

注意:

データベースのオープン中は、この項の手順を使用してSYSTEM表領域の完全メディア・リカバリを実行することはできません。メディア障害によってSYSTEM表領域のデータファイルが破損した場合は、データベースは自動的に停止します。

オープン状態のデータベースでデータファイルをリストアする手順

  1. 「クローズしているデータベースのリカバリの実行」のステップ 1から3を実行します。
  2. データベースがオープンしている場合は、破損したデータファイルを含むすべての表領域をオフラインにします。たとえば、破損したデータファイルが表領域USERSおよびTOOLSに含まれている場合は、次のSQL文を実行します。
    ALTER TABLESPACE users OFFLINE TEMPORARY;
ALTER TABLESPACE tools OFFLINE TEMPORARY;

    TEMPORARYを指定すると、Oracle Databaseによって、表領域内のすべてのオンライン・データファイルに対してチェックポイントが作成されます。この文の発行時にオフラインであるファイルでは、表領域をオンラインに戻す前に、メディア・リカバリが必要な場合があります。IMMEDIATEを指定すると、表領域をオンラインに戻す前に、表領域に対してメディア・リカバリを実行する必要があります。

  3. メディアを検査して問題の原因を確認します。

    DBVERIFYユーティリティを使用して、オフライン・データファイルの整合性チェックを実行できます。

    メディア障害の原因であるハードウェアの問題が一時的なもので、データが破損していない場合、メディア・リカバリは必要ありません。オフライン表領域をオンラインにし、通常の操作を再開することができます。問題を解決できない場合、またはDBVERIFYによって破損ブロックがレポートされた場合は、ステップ4に進みます。

  4. ファイルが永続的に破損された場合は、オペレーティング・システム・コマンドを使用して、メディア障害によって破損されたデータファイルのみの最新のバックアップ・ファイルをリストアします。たとえば、データファイルusers01.dbfをリストアするには、LinuxまたはUNIXでcpコマンドを次のように実行します。
    % cp /disk2/backup/users01.dbf $ORACLE_HOME/oradata/trgt/users01.dbf

    ハードウェアの問題が解決され、データファイルを元の場所にリストアできる場合は、その場所にリストアします。それ以外の場合は、代替のストレージ・デバイスにデータファイルをリストアします。破損していないデータファイル、オンラインREDOログまたは制御ファイルはリストアしないでください。

    注意:

    状況によっては、特定のデータファイルのバックアップがない場合に、ALTER DATABASE CREATE DATAFILE文を使用して、リカバリ可能な空の置換ファイルを作成できることもあります。

  5. 1つ以上の破損したデータファイルを代替の場所にリストアした場合は、データベースの制御ファイルを更新して、新しいデータファイル名を反映させます。たとえば、表領域usersのデータファイルのファイル名を変更するには、次のように入力します。
    ALTER DATABASE RENAME FILE '?/oradata/trgt/users01.dbf' TO
                           '/disk2/users01.dbf';
  6. アーカイブREDOログを代替格納場所にリストアした場合は、SQL*Plusで SETコマンドのLOGSOURCEパラメータを使用して、メディア・リカバリの前の場所を特定できます。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。
    SET LOGSOURCE /tmp

    あるいは、ステップ6をスキップして、ステップ7に示すようにRECOVERコマンドでFROMパラメータを使用します。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。 

    RECOVER AUTOMATIC FROM '/tmp' TABLESPACE users, tools;

    注意:

    REDOログのソースを変更しても、アーカイブされているオンラインREDOログ・グループのアーカイブREDOログの出力先は影響を受けません。

  7. 管理者権限を使用してデータベースに接続します。一度のステップで、1つ以上のオフライン表領域の破損したすべてのデータファイルについて、オフライン表領域のリカバリを開始します。 たとえば、usersおよびtoolsのリカバリを行うには、次のように入力します。
    RECOVER AUTOMATIC TABLESPACE users, tools;

    必要なアーカイブREDOログおよびオンラインREDOログが適用され、リストアしたデータファイルが再構築されて、メディア・リカバリのロールフォワード・フェーズが開始されます。RECOVER AUTOMATICまたはSET AUTORECOVERY ONによってファイルの適用が自動化されていないかぎり、必要なREDOログ・ファイルごとにプロンプトが表示されます。

    必要なすべてのアーカイブ・ログがデータファイルに適用されるまで、リカバリは続行されます。次に、オンラインREDOログがリストアされたデータファイルに自動的に適用され、メディア・リカバリが完了します。完全メディア・リカバリにアーカイブREDOログが必要ない場合は、プロンプトは表示されません。かわりに、必要なすべてのオンラインREDOログが適用され、メディア・リカバリが完了します。

  8. 破損した表領域をメディア障害が発生した時点までリカバリできたら、オフラインの表領域をオンラインにします。たとえば、表領域USERSおよびTOOLSをオンラインにするには、次の文を発行します。
    ALTER TABLESPACE users ONLINE;
ALTER TABLESPACE tools ONLINE;

関連項目:

30.3.3 CDBのクラッシュおよびインスタンス・リカバリの実行

Oracle Databaseは、マルチテナント・コンテナ・データベース(CDB).全体に対して、クラッシュおよびインスタンス・リカバリを実行します個々のプラガブル・データベース(PDB)をリカバリすることはできません。

この手順の前提条件は次のとおりです:

  • 現行の制御ファイルが使用可能です。

  • 必要なすべてのデータファイルのバックアップがあります。

  • 必要なすべてのアーカイブREDOログが使用可能です。

CDBのクラッシュおよびインスタンス・リカバリを実行するには、次の手順を実行します。

  1. SQL*PlusなどのSQLクライアントを開きます。
  2. ALTER PLUGGABLE DATABASEシステム権限を持つ共通ユーザーとしてrootに接続します。
  3. 「クローズしているデータベースのリカバリの実行」の手順に従います。

    特定のPDBをリカバリしない場合は、そのファイルをオフラインにします。

関連項目:

30.4 データベースの不完全リカバリの実行

不完全リカバリは、データベースのPoint-in-Timeリカバリとも呼ばれます。

通常、次のような場合にデータベースのPoint-in-Timeリカバリ(DBPITR)を実行します。

  • ユーザー・エラーまたは管理エラーの前のSCNまでデータベースをリカバリする場合。

  • データベースに破損ブロックが含まれている場合。

  • 必要なすべてのアーカイブREDOログが使用可能ではなかったためデータベースの完全リカバリに失敗した場合。

  • 本番データベース・バックアップからテスト・データベースまたはレポート・データベースを作成する場合。

データベースをARCHIVELOGモードで実行しているときに、アーカイブREDOログ・ファイルの唯一のコピーが破損した場合には、破損したファイルが、データベースの現在の動作に影響を与えることはありません。表30-2に、REDOログが書き込まれた場合およびデータファイルをバックアップした場合に応じて発生する可能性がある状況を示します。

表30-2 アーカイブREDOログの消失

バックアップ対象 対応

一杯になったオンラインREDOログ・グループ(現在アーカイブされている)が書き込まれた後のすべてのデータファイル

完全メディア・リカバリに、一杯になったオンラインREDOログ・グループのアーカイブされたバージョンは必要ありません。

一杯になったオンラインREDOログ・グループが書き込まれる前の特定のデータファイル

対応するデータファイルが永続的なメディア障害によって破損した場合は、破損したデータファイルの最新のバックアップを使用して、破損したアーカイブREDOログ・ファイルに至るまで、破損したデータファイルの表領域のPoint-in-Timeリカバリを実行します。

注意:

アーカイブREDOログ・グループが破損したことがわかっている場合は、破損したアーカイブREDOログを必要としない、データベース全体のバックアップを作成するために、すぐにすべてのデータファイルをバックアップします。

DBPITRでの方法は、特定の時刻またはSCNを指定するか、あるいはCANCELと入力することによって終了する点以外は、クローズしているデータベースのリカバリの実行方法と非常に類似しています。取消しベースのリカバリでは、アーカイブREDOログ・ファイルの推奨ファイル名がプロンプトに表示されます。ユーザーがファイル名のかわりにCANCELを指定するか、すべてのREDOがデータファイルに適用されると、リカバリは停止します。リカバリを終了するアーカイブ・ログを制御する場合は、取消しベースのリカバリが最適な方法です。

関連項目:

30.4.1 取消しベースの不完全リカバリの実行

取消しベースのリカバリでは、ユーザーに対してアーカイブREDOログ・ファイルのファイル名を提示するプロンプトを表示して、リカバリが進行していきます。ユーザーがファイル名のかわりにCANCELを指定するか、すべてのREDOがデータファイルに適用されると、リカバリは停止します。

この手順の前提条件は次のとおりです:

  • 現行の制御ファイルが使用可能です。

  • 必要なすべてのデータファイルのバックアップがあります。

取消しベースのリカバリを実行する手順

  1. 「クローズしているデータベースのリカバリの実行」のステップ 1から8を実行します。
  2. SQL*Plusで次のコマンドを発行し、取消しベースのリカバリを開始します。
    RECOVER DATABASE UNTIL CANCEL

    注意:

    RECOVERコマンドのUNTIL句を指定しなかった場合は、完全リカバリを実行するとみなされ、すべてのREDOが適用されるまではデータベースをオープンできません。

    リストアしたデータファイルを再構築するために必要なREDOログ・ファイルが適用されます。 データベースは、LOG_ARCHIVE_DEST_1から検索する名前を提示します。ユーザーは、そのログ・ファイルを適用するかどうかの決定を求められます。制御ファイルがバックアップの場合は、オンラインREDOログの変更を適用する場合、オンラインREDOログの名前を指定する必要があります。

  3. リストアされたデータファイルに最後のログが適用されるまで、REDOログ・ファイルの適用を続けた後、次のコマンドを実行して、リカバリを取り消します。
    CANCEL

    リカバリが成功したかどうかが示されます。すべてのデータファイルが整合性のあるSCNまでリカバリされる前にリカバリを取り消し、その後データベースをオープンしようとすると、さらにリカバリが必要な場合は、ORA-1113エラーが表示されます。V$RECOVER_FILEを問い合せると、さらにリカバリが必要かどうか、または不完全リカバリの開始前にデータファイルのバックアップがリストアされていなかったかどうかを確認できます。

  4. RESETLOGSオプションを指定してデータベースをオープンします。不完全リカバリまたはバックアップ制御ファイルを使用したリカバリの後は、ログをリセットする必要があります。次に例を示します。
    ALTER DATABASE OPEN RESETLOGS;

    ログのリセットが不適切な状況でOPEN RESETLOGSを使用しようとした場合、またはログをリセットする必要がある状況でログをリセットしなかった場合はエラーが戻され、データベースはオープンされません。問題を解決して再試行してください。

  5. RESETLOGSオプションを使用してデータベースをオープンした後、アラート・ログを確認します。

    注意:

    トレース・ファイルおよびアラート・ログの場所を特定する最も簡単な方法は、SQL問合せSELECT NAME, VALUE FROM V$DIAG_INFOを実行する方法です。

    RESETLOGSオプションを指定してオープンした場合は、リカバリが完全か不完全かによって、戻されるメッセージが異なります。完全リカバリの場合は、アラート・ログに次のメッセージが表示されます。 

    RESETLOGS after complete recovery through change scn

    不完全リカバリの場合は、アラート・ログに次のメッセージが表示されます。ここで、scnは、不完全リカバリの終了位置を表します。 

    RESETLOGS after incomplete recovery UNTIL CHANGE scn

    また、アラート・ログも確認して、データ・ディクショナリと制御ファイルの間の矛盾がデータベースで検出されていないかを調べます。表30-3に、2つの例を示します。

    表30-3 データ・ディクショナリと制御ファイルの間の矛盾

    制御ファイルに示されているデータファイル データ・ディクショナリに示されているデータファイル 結果

    はい

    いいえ

    示されていないデータファイルへの参照が、制御ファイルから削除されます。アラート・ログのメッセージに、検出された内容が表示されます。

    いいえ

    はい

    制御ファイルのMISSINGnnnnnの項(nnnnnは10進数で示したファイル番号)に、プレースホルダ・エントリが作成されます。制御ファイルでMISSINGnnnnnには、オフラインで、メディア・リカバリが必要であるとのフラグが付けられます。MISSINGnnnnnにALTER DATABASE RENAME FILEを使用して、データファイルをポイントするようにすると、MISSINGnnnnnに対応するデータファイルをアクセス可能にできます。このデータファイルのバックアップがない場合は、表領域を削除します。

関連項目:

30.4.2 時間ベースまたは変更ベースの不完全リカバリの実行

不完全リカバリの終了位置のSCNまたは時間を指定できます。

データベースが季節的な時間変更(たとえば夏時間)の影響を受ける場合には、REDOログの中に1つの時間が2度出現し、2番目の、つまり後の時間までリカバリを行う場合に、問題が発生します。時間の変更を処理するには、取消しベースまたは変更ベースのリカバリを実行します。

この手順の前提条件は次のとおりです:

  • 現行の制御ファイルが使用可能です。

  • 必要なすべてのデータファイルのバックアップがあります。

変更ベースまたは時間ベースのリカバリを実行する手順

  1. 「クローズしているデータベースのリカバリの実行」のステップ1から8を実行します。
  2. RECOVER DATABASE UNTIL文を発行して、リカバリを開始します。特定のSCNまでリカバリする場合は、引用符を付けずに10進数を指定します。たとえば、SCN 10034までリカバリするには、次のコマンドを発行します。
    RECOVER DATABASE UNTIL CHANGE 10034;

    特定の時刻までリカバリする場合は、一重引用符で区切った書式('YYYY-MM-DD:HH24:MI:SS')で時刻を指定します。次の文は、指定された時刻までデータベースのリカバリを行います。 

    RECOVER DATABASE UNTIL TIME '2000-12-31:12:47:30'
  3. リストアされたデータファイルのリカバリに必要なREDOログ・ファイルを適用します。正しい時刻になるとリカバリは自動的に停止し、リカバリが成功したかどうかを示すメッセージが戻されます。

    注意:

    リカバリが自動化されていないかぎり、名前はLOG_ARCHIVE_DEST_1から提示され、各ログを適用するかどうかの決定を求められます。制御ファイルがバックアップの場合は、アーカイブ・ログを適用した後で、オンライン・ログの名前を指定する必要があります。

  4. 「取消しベースの不完全リカバリの実行」のステップ4および5を実行します。

関連項目:

30.5 NOARCHIVELOGモードでのデータベースのリカバリ

メディア障害によって、NOARCHIVELOGモードのデータベースのデータファイルが破損した場合は、通常、一貫性のあるデータベース全体のバックアップをリストアすることによってのみリカバリできます。Oracle Data Pump Exportで作成した論理バックアップを使用して通常の物理バックアップを補完している場合は、データベースのエクスポートされたバックアップを、再作成したデータベースまたは古いバックアップからリストアしたデータベースにインポートして、データベースのリストアを試行することもできます。

最新のデータベース全体のバックアップをリストアおよびリカバリする手順

  1. データベースがオープンしている場合は、データベースを停止します。たとえば、次のように入力します。
    SHUTDOWN IMMEDIATE
  2. 可能であれば、メディアの問題を解決して、バックアップ・データベース・ファイルを元の場所にリストアできるようにします。
  3. オペレーティング・システム・コマンドを使用して、最新のデータベース全体のバックアップをリストアします。破損したファイルのみでなく、データベース全体のバックアップの、すべてのデータファイルおよび制御ファイルをリストアします。ハードウェアの問題が解決できず、データベース・ファイルの一部またはすべてを代替の場所にリストアする必要がある場合は、データベース全体のバックアップを新しい場所にリストアします。次の例は、データベース全体のバックアップをデフォルトの場所にリストアします。
    % cp /backup/*.dbf $ORACLE_HOME/oradata/trgt/
  4. 必要に応じて、リストアされた初期化パラメータ・ファイルを編集して、制御ファイルの新しい場所を示します。次に例を示します。
    CONTROL_FILES = "/new_disk/oradata/trgt/control01.dbf"
  5. リストアして編集したパラメータ・ファイルを使用してインスタンスを起動し、データベースをマウントします(ただし、オープンはしません)。次に例を示します。
    STARTUP MOUNT
  6. リストアされたデータファイルのファイル名が異なる場合(同じノードまたは異なるノードの異なるファイル・システムまたはディレクトリにリストアする場合など)、制御ファイルを更新して新しいデータファイルの場所を反映させます。たとえば、データファイル1の名前を変更するには、次のように入力します。
    ALTER DATABASE RENAME FILE '?/oradata/trgt/system01.dbf' TO
                           '/new_disk/oradata/system01.dbf';
  7. オンラインREDOログが破損したディスク上にある場合、ハードウェアの問題が解決されないときには、影響を受けた各オンライン・ログの新しい場所を指定します。たとえば、次のように入力します。
    ALTER DATABASE RENAME FILE '?/oradata/trgt/redo01.log' TO
                           '/new_disk/oradata/redo_01.log';
ALTER DATABASE RENAME FILE '?/oradata/trgt/redo02.log' TO
                           '/new_disk/oradata/redo_02.log';
  8. オンラインREDOログはバックアップされないため、データファイルおよび制御ファイルとともにリストアすることはできません。データベースでオンラインREDOログをリセットできるように、まず不完全リカバリを行う必要があります。
    RECOVER DATABASE UNTIL CANCEL
CANCEL
  9. RESETLOGSモードでデータベースをオープンします。このコマンドによって、オンラインREDOログが消去され、ログ順序が1にリセットされます。
    ALTER DATABASE OPEN RESETLOGS;

    NOARCHIVELOGモードのデータベースのバックアップをリストアした後、ログをリセットすると、バックアップが作成されてから障害が発生するまでの間にデータベースに対して行われたすべての変更が廃棄されます。

関連項目:

データファイルの名前の変更および場所の変更の詳細は、『Oracle Database管理者ガイド』を参照し、ALTER DATABASE RENAME FILEについては、『Oracle Database SQL言語リファレンス』を参照してください。

30.6 メディア・リカバリのトラブルシューティング

この項では、ユーザー管理のメディア・リカバリ(Recovery Manager (RMAN)を使用しないで実行するメディア・リカバリ)のトラブルシューティングの方法について説明します。この項の内容は、次のとおりです。

30.6.1 ユーザー管理のメディア・リカバリの問題

表30-4に、メディア・リカバリ中に発生する可能性がある問題を示します。

表30-4 メディア・リカバリの問題

問題 説明

アーカイブ・ログの欠落または名前の誤り

制御ファイルに記録されたアーカイブ・ログが見つからないため、リカバリは停止します。

データベースをオープンしようとすると、ORA-1113エラーが、データファイルのメディア・リカバリが必要であることを示す。

このエラーの一般的な原因は次のとおりです。

  • 不完全リカバリを実行していますが、必要なすべてのデータファイル・バックアップがリストアされていません。

  • データファイルが一貫性のあるSCNに達する前に、不完全リカバリが停止しました。

  • オンライン・バックアップからデータファイルのリカバリを行っていますが、データファイルを一貫性のある状態にするための十分なREDOが適用されていません。

  • バックアップ制御ファイルを使用してリカバリを行っていますが、必要なオンラインREDOログの場所が指定されていません。

  • ユーザーがデータベースをオープンしようとしたときに、データファイルに対してメディア・リカバリが実行されていました。

  • リカバリの必要なデータファイルは、RECOVER DATABASEコマンドの実行前にオンラインにされていなかったため、リカバリが行われていません。

REDOレコードの問題

2つの状況が考えられます。

  • 一貫性チェックが失敗したためにリカバリが停止しました。スタック・リカバリと呼ばれる問題です。スタック・リカバリは、基礎となるオペレーティング・システムまたはストレージ・システムで、データベースの通常稼働中に発行された書込みが消失した場合に発生することがあります。

  • REDOを適用するときに内部エラーが通知されました。この問題は、Oracle Databaseの不具合によって発生することがあります。チェックサム検証が使用されていない場合は、REDOまたはデータ・ブロックの破損によってエラーが発生することもあります。

アーカイブ・ログの破損

格納中またはストレージ・システム間でコピーされるときに、ログが破損した可能性があります。DB_BLOCK_CHECKSUMが有効になっている場合は、通常、チェックサム・エラーが通知されます。チェックサム・チェックが無効になっている場合、ログの破損がREDOの問題として表示されることがあります。

互換性のないパラレルREDOフォーマットによるアーカイブ・ログ

パラレルREDO機能を有効にした場合、REDOログが新規のフォーマットで生成されます。以前のリリースのOracleでは、パラレルREDOログを適用できません。ただし、Oracle9i Databaseリリース2(9.2)より前のリリースでは、パラレルREDOフォーマットを検出し、エラー・メッセージ「External error 00303, 00000, "パラレルREDOは処理できません"」によって非一貫性の存在を確認できます。

データ・ブロックの破損

データファイルのバックアップに破損したデータ・ブロックが含まれているか、リカバリ中またはバックアップにコピーされたときにデータ・ブロックが破損しました。DB_BLOCK_CHECKSUMが有効になっている場合、データベースは、通常の操作時にチェックサムを各ブロックで計算し、ブロックに保存してからディスクに書き込みます。データベースは、後でディスクからブロックを読み取る場合、チェックサムを再計算し、格納されている値と比較します。一致しない場合は、チェックサム・エラーを通知します。チェックサム・チェックが無効になっている場合は、問題がREDOの破損として表示されることがあります。

その他の問題

リカバリ中には、メモリーの破損や、その他の一時的な問題が発生することがあります。

メディア・リカバリの問題は通常、リカバリ中に通知される外部エラーまたは内部エラーとして出現します。たとえば、外部エラーは、REDOブロックまたはデータ・ブロックでチェックサム検証チェックが失敗したことを示します。内部エラーは、データベースの不具合か、基礎となるオペレーティング・システムおよびハードウェアに起因するエラーによって発生する可能性があります。

メディア・リカバリで、データベース・バックアップのリカバリ中に問題が発生した場合は、スタック・リカバリの問題またはREDO適用中の問題であるかどうかに関係なく、データベースは常に停止し、リカバリ中のデータファイルを一貫性のある状態、つまり、障害前の一貫性のあるSCNのままにします。次のいずれかを実行できます。

  • データベースを読取り専用でオープンし、問題を調査します。

  • RESETLOGSオプションを指定してデータベースをオープンします(RESETLOGSのオープンの要件が満たされている場合)。スタンバイ・データベースはメディア・リカバリの形態で更新されるため、RESETLOGSの制限は、フィジカル・スタンバイ・データベースをオープンする場合にも適用されます。

一般に、データベースを読取り専用でオープンしたり、RESETLOGSオプションを指定してオープンする場合には、すべてのオンライン・データファイルを同じSCNまでリカバリする必要があります。この要件が満たされない場合は、ユーザーがオープンを試行すると、ORA-1113またはその他のエラーが通知されることがあります。ORA-1113の一般的な原因については、表30-4を参照してください。

一般に、メディア・リカバリの問題には、次のように対処します。

  1. 問題の原因を確認します。必要に応じて試行リカバリを実行します。

  2. 問題がREDOログの欠落に関係するか、REDOログ、メモリーまたはデータ・ブロックが破損している可能性がある場合は、表30-5に示す方法で問題の解決を試みます。

  3. 表30-5に示す方法を使用しても問題を解決できない場合は、次のいずれかを実行します。

    • データベース全体のバックアップのリカバリを行う場合は、RESETLOGSオプションを指定してデータベースをオープンします。シリアル・メディア・リカバリを実行した場合は、データベースには、破損が発生したSCNの前までのすべての変更が含まれています。このSCN以降の変更は、データベースのリカバリされた部分に含まれていません。オンライン・バックアップをリストアした場合は、RESETLOGSによるオープンは、REDOストリーム中のすべてのALTER ... END BACKUP操作までリカバリが完了している場合にのみ成功します。

    • データ・ブロックを破損させることをメディア・リカバリに許可して、リカバリを続行します。メディア・リカバリが完了した後、RMANを使用してブロック・メディア・リカバリを実行してください。

    • それでも問題が解決しない場合は、Oracleサポート・サービスに連絡します。

      関連項目:

      ブロック・メディア・リカバリについては、「障害リカバリの実行」を参照してください。

30.6.2 メディア・リカバリの問題の調査: フェーズ1

メディア・リカバリで問題が発生した場合は、リカバリが停止した後、できるだけ多くの情報を入手してください。解決する問題を誤って時間を消費し、さらに問題を悪化させることを防ぐためです。

最初に、問題の原因が、設定の誤り、REDOログの破損、データ・ブロックの破損、メモリーの破損、またはその他の原因のどれかを確認します。データ・ブロックのチェックサムにエラーがある場合には、データ・ブロックが破損しています。REDOログ・ブロックのチェックサムにエラーがある場合には、REDOログが破損しています。

リカバリの問題の原因は、特定するのが困難な場合があります。問題の原因が完全にはわからない場合でも、この項に示す方法を使用すると、データベースのリカバリを迅速に実行できます。

メディア・リカバリの問題を調査する手順

  1. alert.logを調べて、エラー・メッセージに問題の性質についての一般的な情報が記載されているかを確認します。たとえば、alert_SID.logにチェックサムのエラーが示されているかどうかを確認します。また、メディア・リカバリを続行するためにデータ・ブロックの破損を許可する必要があることが示されているかどうかを確認します。
  2. リカバリ中にOracle Databaseによって生成されたトレース・ファイルを調べます。追加のエラー情報が含まれていることがあります。

30.6.3 ブロックを破損させない修正の試行: フェーズ2

メディア・リカバリの問題のタイプに応じて、いくつかの解決方法があります。表30-5に示す方法の1つ、あるいはその組合せを使用できます。これらの解決方法は、一般的な修復方法です。比較的安全に、ほとんどのメディア・リカバリの問題を解決できます。

表30-5 メディア・リカバリの解決方法

発生した可能性がある問題 対応

アーカイブREDOログの欠落または名前の誤り

ファイル名が正しく入力されているかを確認します。正しく入力されていた場合には、オペレーティング・システムからログが欠落しているかを確認します。欠落している場合に、バックアップがあれば、バックアップをリストアし、ログを適用します。バックアップがない場合には、可能であれば、欠落したログの時点まで不完全リカバリを実行します。

ALTER DATABASE OPENでのORA-1113

表30-4で、このエラーの原因を検討します。リカバリが必要なすべての読取り/書込みデータファイルがオンラインにされていることを確認します。

リカバリにバックアップ制御ファイルを使用した場合には、制御ファイルとデータファイルのSCNに一貫性がないかぎり、データベースをオープンできません。必要なREDOがない場合には、制御ファイルを再作成する必要があります。

アーカイブ・ログの破損

ログREDOブロックのチェックサム検証が失敗したときには、ログが破損しています。リカバリ・セッション中、またはデータベースがREDOを生成したときにDB_BLOCK_CHECKSUMが有効になっていなかった場合には、リカバリの問題の原因としてログの破損が考えられます。ログが破損し、破損したログの代替コピーが使用できる場合には、このコピーを適用して、問題が修正されるかどうかを確認します。

DB_BLOCK_CHECKSUM初期化パラメータは、REDOログおよびデータ・ブロックに対してチェックサムを計算するかどうかを決定します。

互換性のないパラレルREDOフォーマットによるアーカイブ・ログ

Oracle9i Databaseリリース2より前のOracle Databaseリリースを実行している場合、パラレルREDOフォーマットで作成されたREDOログを適用するには、次のステップを実行する必要があります。

  1. データベースをより新しいリリースにアップグレードします。

  2. メディア・リカバリを実行します。

  3. データベースを一貫した状態で停止し、バックアップを行います。

  4. データベースを元のリリースにダウングレードします。

メモリーの破損または一時的な問題

データベースを停止してリカバリを再開すると、問題を解決できる場合があります。2回目の試行も失敗した場合は、データベースを一貫性のある状態のままにしておく必要があります。

データ・ブロックの破損

ユーザー管理の方法を使用して、データファイルのリストアおよびリカバリを再度実行するか、またはRMANのRECOVER ...BLOCKコマンドを使用して、個々のデータ・ブロックのリストアおよびリカバリを行います。この方法で問題が解決される場合もあります。

データ・ブロックのチェックサム検証が失敗した場合は、データ・ブロックが破損しています。DB_BLOCK_CHECKINGが無効である場合は、データ・ブロックの破損の問題が、REDOの問題として表示されることがあります。メディア・リカバリを続行する必要がある場合は、この時点ではブロックを破損とマークできるようにしてリカバリを続け、後でRMANを使用してブロック・メディア・リカバリを実行できます。

表30-5に示す方法で問題を解決できない場合は、データを消失せずに、簡単に問題を解決できる方法がない可能性があります。次のようなオプションがあります。

  • RESETLOGSオプションを指定してデータベースをオープンします(データベース全体のリカバリのため)。

    この解決方法では、REDOの問題が発生した時点以降のすべての変更が廃棄されますが、データベースの論理的一貫性は保証されます。

  • メディア・リカバリで1つ以上のデータ・ブロックを破損させることを許可して、続行します。

    このオプションは、アラート・ログに、データ・ブロックを破損させることを許可すればリカバリを続行できることが示されている場合にのみ成功します。これはほとんどのリカバリの問題に当てはまります。データベースを迅速に起動し、すべての変更をリカバリする必要がある場合は、このオプションが最適です。 このオプションを検討する場合は、「リカバリでブロックの破損とマークできるようにするかどうかの決定: フェーズ3」に進みます。

    関連項目:

    RECOVER ... BLOCKコマンドを使用してブロック・メディア・リカバリを実行する方法については、「ブロック・メディア・リカバリの実行」を参照してください。

30.6.4 リカバリでブロックの破損とマークできるようにするかどうかの決定: フェーズ3

メディア・リカバリで問題が発生した場合、問題の原因となっているデータ・ブロックを破損とマークできるようにすればリカバリを続行できることが、アラート・ログに示されていることがあります。アラート・ログには、ブロックに関する情報(ブロック・タイプ、ブロック・アドレス、所属する表領域など)が含まれています。ユーザー・データを含むブロックの場合は、データ・オブジェクト番号もアラート・ログで報告されることがあります。

この場合、問題のブロックに破損というマークを付けることが許可されれば、リカバリを続行できます。ただし、この方法は常に成功するとはかぎりません。たとえば、SYSTEM表領域の中の重要なブロックに破損というマークを付けると、最終的にはリカバリ済のデータベースをオープンできなくなる可能性があります。もう1つ考慮すべき点は、リカバリの問題を分離できるかどうかです。この問題の直後に、REDOストリームでその他の多数の問題が発生する場合は、RESETLOGSオプションを指定してデータベースをオープンする方がよい場合があります。

ユーザー・データを含むブロックの場合は、通常、データベースを問い合せて、そのブロックを所有するオブジェクトまたは表を確認できます。データベースがオープンしていない場合には、データベース全体のバックアップのリカバリ中であっても、データベースを読取り専用でオープンできます。次の例はリカバリを取り消して、データベースを読取り専用でオープンします。

CANCEL
ALTER DATABASE OPEN READ ONLY;

alert_SID.logで報告されているデータ・オブジェクト番号が8031であるとします。次の問合せを発行して、所有者、オブジェクト名およびオブジェクト型を確認できます。 

SELECT OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_TYPE
FROM DBA_OBJECTS
WHERE DATA_OBJECT_ID = 8031;

リカバリの問題が分離されているかどうかを確認するために、診断用の試行リカバリを実行できます。試行リカバリでは、REDOストリームをスキャンして問題が検索されますが、リカバリされたデータベースに対して実際の変更は行いません。試行リカバリでリカバリの問題が検出された場合、alert_SID.logで報告されます。試行リカバリを起動するには、「RECOVER ... TEST文の実行」で説明するように、RECOVER ... TEST文を使用します。

これらの調査を実行した後、表30-6のガイドラインに従って、リカバリでブロックの破損を許可するかどうかを決定します。

表30-6 リカバリでブロックの破損を許可するためのガイドライン

問題の状態 ブロック 対応

分離されていない

  

RESETLOGSオプションを指定して、データベースをオープンできます。スタック・リカバリはオペレーティング・システムまたはストレージ・システムで書込みが消失したために発生することがあるため、この対応はスタック・リカバリの問題にとって重要です。オペレーティング・システムまたはストレージ・システムで予期せぬエラーが発生した場合には、複数のブロックでスタック・リカバリの問題が発生する可能性があります。

分離されている

SYSTEM表領域内

最終的にデータベースをオープンできなくなる可能性があるため、ブロックは破損させないでください。ただし、SYSTEM表領域の中のデータが重要でない場合もあります。SYSTEMブロックを破損させ、すべての変更のリカバリを行う必要がある場合には、Oracleサポート・サービスに連絡してください。

分離されている

索引データ

データベースのリカバリ後に索引を再作成できるため、索引ブロックを破損させることを検討してください。

分離されている

ユーザー・データ

データの重要性に基づいて決定します。データファイルのリカバリを続行し、ブロックを破損させると、ブロック内のデータが消失します。ただし、データファイルのリカバリが完了した後で、RMANを使用してブロック・メディア・リカバリを実行できます。RESETLOGSでオープンすると、データベースは一貫性のあるものになりますが、リカバリが停止された時点以降のすべての変更は失われます。

分離されている

ロールバックまたはUNDOデータ

すべてのトランザクションがコミットされる場合は、ロールバックまたはUNDOブロックを破損させることを検討します。UNDOを生成したトランザクションをロールバックしない場合は、データベースに害はありません。ただし、これらのトランザクションをロールバックする場合は、UNDOブロックを破損させると問題が発生する可能性があります。判断できない場合は、Oracleサポート・サービスに連絡してください。

関連項目:

試行リカバリの実行方法については、「試行リカバリの実行」を参照してください。リカバリでブロックの破損を許可するように決定した場合は、「リカバリでのブロックの破損の許可: フェーズ4」を参照してください。

30.6.5 リカバリでのブロックの破損の許可: フェーズ4

リカバリの続行のために、ブロックの破損を許可することを決定した場合には、ALLOW n CORRUPTION句を指定してRECOVERコマンドを実行します。このnは、破損させることを許可するブロックの数です。

リカバリでブロックを破損させることを許可する手順

  1. リカバリの通常の前提条件がすべて満たされていることを確認します。たとえば、データベースがオープンしている場合には、リカバリを試みる前に、表領域をオフライン化します。
  2. 次の例に示すように、RECOVERコマンドを実行します。
    RECOVER DATABASE ALLOW 5 CORRUPTION

30.6.6 試行リカバリの実行

スタック・リカバリなどの問題が発生した場合、判断が困難な場合があります。ブロックが比較的重要でなく、問題が分離されている場合は、通常、ブロックを破損させます。ただし、問題が分離されていない場合は、RESETLOGSオプションを指定してデータベースをオープンする方がよい場合があります。

このため、Oracle Databaseでは、試行リカバリがサポートされています。試行リカバリは、通常のメディア・リカバリと同じ方法でREDOを適用しますが、ディスクに変更を書き込むことはなく、必ず変更をロールバックします。試行リカバリはメモリー内でのみ発生します。

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

関連項目:

「リカバリでのブロックの破損の許可: フェーズ4」

30.6.6.1 試行リカバリの仕組み

デフォルトでは、試行リカバリでスタック・リカバリやその他の問題が検出されると、常に、メモリー内でデータ・ブロックに破損しているというマークが付けられます(このアクションによってリカバリを続行できる場合)。試行リカバリ中に生成されたエラーは、アラート・ファイルに書き込まれます。これらのエラーは、テスト実行のエラーであることが明示されます。

試行リカバリでは、通常のメディア・リカバリと同様に、アーカイブ・ログのファイル名を指定するプロンプトが表示され、ユーザーは、ログを適用するかどうかを判断するように求められます。試行リカバリは次の場合に終了します。

  • 試行リカバリ用に使用できるメモリー内の最大バッファ数がすべて使用された場合

  • リカバリ不能なエラー(データ・ブロックを破損させても解決できないエラー)が通知された場合

  • ユーザーがリカバリ・セッションを取り消したか中断した場合

  • REDOストリーム内の次のREDOレコードによって制御ファイルが変更された場合

  • 必要なREDOがすべて適用された場合

試行リカバリが終了すると、アラート・ファイル内のエラー・メッセージを除き、テスト実行のすべての影響がシステムから削除されます。試行リカバリ中にインスタンスの障害が発生した場合は、試行リカバリが変更をディスクに書き込むことはないため、試行リカバリのすべての影響がシステムから削除されます。

試行リカバリを使用することによって、通常のリカバリを続行した場合に発生する可能性のある問題を予測できます。進行中のメモリーの破損を原因とする問題の場合は、試行リカバリと通常のリカバリで発生するエラーが異なることがあります。

30.6.6.2 RECOVER... TEST文の実行

TESTオプションはすべてのRECOVERコマンドで使用できます。たとえば、SQL*Plusを起動して次のコマンドのいずれかを発行できます。 

RECOVER DATABASE TEST
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL TEST
RECOVER TABLESPACE users TEST
RECOVER DATABASE UNTIL CANCEL TEST

デフォルトでは、試行リカバリを実行すると、メモリー内でブロックの破損が常に試行されます(このアクションによって試行リカバリを続行できる場合)。試行リカバリはデフォルトで、いくつでもデータ・ブロックを破損させることができます。RECOVER ... TEST文でALLOW n CORRUPTION句を指定すると、試行リカバリの実行時にメモリー内で破損させることができるデータ・ブロックの数を制限できます。

試行リカバリのコマンドは、通常リカバリのコマンドを使用できるすべての場合に使用できます。ただし、試行リカバリを実行する必要があるのは、リカバリで問題が発生する場合のみです。

関連項目:

試行リカバリの仕組み