| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース2(11.2) B56269-05 |
|
 前 |
 次 |
この章では、データベースをリストアおよびリカバリする方法、およびユーザー管理のバックアップおよびリカバリ計画でOracle Databaseのフラッシュバック機能を使用する方法について説明します。ユーザー管理のバックアップおよびリカバリ計画は、RMANを必要としない方法です。
Oracle Flashback Databaseを使用すると、バックアップからファイルをリストアせずに、データベース全体を元の状態に戻すことができます。SQL*PlusのFLASHBACK DATABASEコマンドの機能は、RMANのFLASHBACK DATABASEコマンドと同じです。このコマンドを実行すると、データベースが元の状態に戻されます。
フラッシュバック・データベースを使用する場合は、データベース用の高速リカバリ領域を作成し、フラッシュバック・ログの収集を有効にする必要があります。フラッシュバック・データベース機能の動作、フラッシュバック・データベースの使用要件およびフラッシュバック・データベースに必要なフラッシュバック・ログの収集を有効にする方法の詳細は、第18章「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照してください。RMANまたはSQL*Plusのいずれを使用する場合でも、要件および準備は同じです。
SQL*Plusでデータベースのフラッシュバックを実行する手順
ターゲット・データベースを問い合せて、フラッシュバックのSCNの範囲を確認します。次のSQL*Plus問合せを実行して、フラッシュバック・ウィンドウの最初と最後のSCNを示します。
SELECT CURRENT_SCN FROM V$DATABASE; SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME FROM V$FLASHBACK_DATABASE_LOG;
必要に応じて他のフラッシュバック機能を使用し、データベースに対する不要な変更のSCNまたは時刻を確認します。
管理者権限を使用してSQL*Plusを起動し、データベースをマウントします(ただし、オープンはしません)。
FLASHBACK DATABASE文を実行し、データベースを以前のTIMESTAMPまたはSCNまで戻します。次に例を示します。
FLASHBACK DATABASE TO SCN 46963;
FLASHBACK DATABASE TO TIMESTAMP '2002-11-05 14:00:00';
FLASHBACK DATABASE
TO TIMESTAMP to_timestamp('2002-11-11 16:00:00', 'YYYY-MM-DD HH24:MI:SS');
操作が完了したら、データベースを読取り専用でオープンし、問合せを実行して必要なデータがリカバリされていることを確認します。
選択した目標時点が十分に前の時点でなかった場合は、別のFLASHBACK DATABASE文を使用します。それ以外の場合は、RECOVER DATABASEを使用してデータベースを現在の時点に戻し、別のFLASHBACK DATABASE文を実行します。
結果が適切である場合は、RESETLOGSオプションを指定してデータベースをオープンします。
必要に応じて、データ・ポンプ・エクスポートを使用して消失したデータを保存し、RECOVER DATABASEでデータベースを現在の状態に戻して、消失したオブジェクトを再インポートすることもできます。
|
関連項目: Oracle Flashback Query、Oracle Flashback Transaction Queryなどの関連フラッシュバック機能の使用方法については、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 |
この項では、SQL*Plusを使用したリカバリの概要について説明します。この項の内容は、次のとおりです。
通常、メディア障害またはユーザー・エラーによって複数のデータファイルが破損したり削除された場合に、ファイルをリストアします。ユーザー管理のリストア操作では、オペレーティング・システムのユーティリティを使用してファイルのバックアップをリストアします。
メディア障害がデータファイルに影響を与えた場合、リカバリの手順は次の条件によって異なります。
データベースのアーカイブ・モード(ARCHIVELOGまたはNOARCHIVELOG)
メディア障害のタイプ
メディア障害によって影響されるファイル(データファイル、制御ファイル、アーカイブREDOログおよびサーバー・パラメータ・ファイルはすべてリストア操作の対象となります。)
永続的または一時的なメディア障害によって、NOARCHIVELOGモードで実行しているデータベースのデータファイルが影響を受けた場合、データベースは自動的に停止します。メディア障害が一時的な場合は、原因となっている問題を解決し、データベースを再起動します。通常、クラッシュ・リカバリによって、コミット済のすべてのトランザクションがオンラインREDOログを使用してリカバリされます。メディア障害が永続的な場合は、「NOARCHIVELOGモードでのデータベースのリカバリ」の説明に従ってデータベースをリカバリします。
表29-1に、ARCHIVELOGモードで実行されているデータベースでファイルを消失した場合に実行するメディア・リカバリについての説明を示します。
表29-1 ユーザー管理のリストア操作
| 消失したもの | 現在の状態 |
|---|---|
|
|
データベースは自動的に停止します。ハードウェアの問題が一時的な場合には、問題を解決し、データベースを再起動します。通常、クラッシュ・リカバリによって、消失したトランザクションがリカバリされます。ハードウェアの問題が永続的な場合は、「クローズしているデータベースのリカバリの実行」の説明に従って、バックアップからデータファイルをリストアし、データベースをリカバリします。 |
|
|
影響を受けたデータファイルがオフライン化されますが、データベースはオープンしたままです。データベースの影響を受けていない部分を使用可能なままにしておく必要がある場合には、データベースを停止しないでください。一時オプションを使用して、問題が発生したデータファイルを含む表領域をオフラインにした後、「オープンしているデータベースのリカバリの実行」の説明に従ってリカバリします。 |
|
現行の制御ファイルのすべてのコピー |
バックアップ制御ファイルをリストアし、 バックアップがない場合には、制御ファイルを再作成してください。可能であれば、 |
|
多重制御ファイルの1つのコピー |
影響を受けていない多重制御ファイルの1つを破損または欠落した制御ファイルの場所にコピーして、データベースをオープンします。元の場所に制御ファイルをコピーできない場合は、初期化パラメータ・ファイルを編集して新しい場所を反映するか、または破損した制御ファイルを削除します。その後、データベースをオープンします。 |
|
メディア・リカバリに必要な1つ以上のアーカイブ・ログ |
リカバリを実行するには、これらのアーカイブ・ログのバックアップをリストアする必要があります。デフォルトの場所またはデフォルト以外の場所にリストアできます。バックアップがない場合には、欠落している最初のREDOログの前のSCNまで不完全リカバリを実行し、 |
|
サーバー・パラメータ・ファイル(SPFILE) |
サーバー・パラメータ・ファイルのバックアップがある場合には、これをリストアします。また、クライアント側の初期化パラメータ・ファイルのバックアップがある場合には、このファイルのバックアップをリストアし、インスタンスを起動した後、サーバー・パラメータ・ファイルを再作成できます。 |
|
注意: Oracle Managed Filesのリストアおよびリカバリは、ユーザーが名前を付けたファイルのリストアおよびリカバリと同じです。 |
メディア・リカバリの実行には、SQL*PlusのRECOVER文を使用することをお薦めします。SQL文のALTER DATABASE RECOVERも使用できますが、通常、RECOVER文を使用した方が簡単です。どのような種類のメディア・リカバリを開始する場合でも、次の制約に従う必要があります。
管理者権限が必要です。
すべてのリカバリ・セッションが互換である必要があります。
別のセッションが不完全メディア・リカバリを実行しているときに、もう1つのセッションで完全メディア・リカバリを開始することはできません。
共有サーバー・プロセスを使用してデータベースに接続している場合は、メディア・リカバリを開始できません。
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です)。
データファイル・バックアップをリストアした後、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ビューで、各ファイルのステータス情報にアクセスできます。これらのビューは、リカバリ・セッションの終了後はアクセスできません。 |
SET AUTORECOVERYを使用して自動リカバリを有効にする他にも、RECOVERコマンドでAUTOMATICキーワードを指定することもできます。たとえば、SQL*Plusに次のコマンドを入力すると、自動リカバリを実行し、データベースをオープンできます。
STARTUP MOUNT RECOVER AUTOMATIC DATABASE ALTER DATABASE OPEN;
Oracle Real Application Clusters構成を使用しているとき、ユーザーが不完全リカバリを実行するか、またはバックアップ制御ファイルを使用する場合は、最初のREDOスレッドから最初のアーカイブREDOログ・ファイルの名前を算出することのみが可能です。その他の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の値が変更されていない場合は、ログ・ファイルが提示および適用され、メディア・リカバリが自動的に実行されます。
アーカイブ・ログがデフォルトの場所にない場合にメディア・リカバリを実行するには、追加の処理が必要です。次のいずれかの方法を選択します。
アーカイブREDOログの場所を指定するLOG_ARCHIVE_DEST_nパラメータを編集し、通常どおりにリカバリします。
リカバリ前にSQL*PlusのSET文を使用してデフォルト以外のログの場所を指定するか、RECOVERコマンドのLOGFILEパラメータを使用します。
初期化パラメータ・ファイルを編集するか、ALTER SYSTEM文を発行して、アーカイブREDOログのデフォルトの場所を変更できます。
リカバリ前にアーカイブ・ログのデフォルトの場所を変更する手順
オペレーティング・システム・ユーティリティを使用して、アーカイブ・ログをデフォルト以外の場所にリストアします。たとえば、次のように入力します。
% cp /backup/arch/* /tmp/
アーカイブ・ログ・パラメータの値を、デフォルト以外の場所に変更します。インスタンスが起動されているときにALTER SYSTEM文を発行するか、初期化パラメータ・ファイルを編集した後にデータベース・インスタンスを起動します。たとえば、インスタンスの停止中にパラメータ・ファイルを次のように編集します。
LOG_ARCHIVE_DEST_1 = 'LOCATION=/tmp/' LOG_ARCHIVE_FORMAT = arcr_%t_%s.arc
SQL*Plusを使用して、編集済の初期化パラメータ・ファイルを指定して新しいインスタンスを起動した後、データベースをマウントします。たとえば、次のように入力します。
STARTUP MOUNT
通常どおりにメディア・リカバリを開始します。たとえば、次のように入力します。
RECOVER DATABASE
場合によっては、アーカイブの出力先パラメータの現在の設定を変更して、アーカイブ・ログ・ファイルの入力元を変更することもできます。
SET LOGSOURCEを使用して、デフォルト以外の場所のアーカイブ・ログをリカバリする手順
オペレーティング・システム・ユーティリティを使用して、アーカイブREDOログを代替の場所にコピーします。たとえば、次のように入力します。
% cp $ORACLE_HOME/oradata/trgt/arch/* /tmp
SQL*Plus内でリカバリ操作のための代替場所を指定します。SET文のLOGSOURCEパラメータを使用します。たとえば、SQL*Plusを起動して次のように実行します。
SET LOGSOURCE "/tmp"
オフライン表領域をリカバリします。たとえば、オフライン表領域usersをリカバリするには、次のコマンドを実行します。
RECOVER AUTOMATIC TABLESPACE users
また、SET LOGSOURCEを実行せずに、次のコマンドを実行することもできます。
RECOVER AUTOMATIC TABLESPACE users FROM "/tmp"
|
注意: REDOログのソースを変更しても、アーカイブされているオンラインREDOログ・グループのアーカイブREDOログの出力先は影響を受けません。 |
メディア・リカバリを開始した後で中断する必要がある場合は、REDOログ・ファイルのプロンプトに対してCANCELと入力します。また、個々のデータファイルのリカバリの実行時または自動リカバリの実行時に終了する必要がある場合は、オペレーティング・システムの割込みシグナルを使用します。リカバリが取り消された後、RECOVERコマンドを使用してリカバリを再開できます。リカバリは、取り消された位置から再開されます。
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コマンドの詳細は、 |
通常、メディア障害によって1つ以上のデータファイルにアクセスできなくなった場合に、データベースの完全リカバリを実行します。V$RECOVER_FILEビューに、リカバリが必要なファイルが示されます。データベースの完全リカバリを実行する場合は、使用可能なすべてのREDOを使用し、データベースを現行のSCNまでリカバリします。
状況に応じて、データベース全体で一度にリカバリを実行することも、個々の表領域またはデータファイルでリカバリを実行することもできます。完全リカバリの場合は、RESETLOGSオプションを指定してデータベースをオープンする必要はないため、最初に一部のデータファイルのリカバリを行ってから、後で残りのデータファイルのリカバリを行うこともできます。
この項の手順では、次のことが想定されています。
現行の制御ファイルが使用可能です。制御ファイルをリストアまたは再作成する必要がある場合は、「現行の制御ファイルがすべて消失した場合のリカバリ」および「制御ファイルの再作成」を参照してください。
必要なすべてのデータファイルのバックアップがあります。データファイルのバックアップが欠落している場合は、「バックアップが利用できない場合のデータファイルの再作成」を参照してください。
必要なすべてのアーカイブREDOログが使用可能です。データベースを完全にリカバリするために必要なREDOが欠落している場合は、データベースのPoint-in-Timeリカバリを実行する必要があります。詳細は、「データベースの不完全リカバリの実行」を参照してください。
この項では、完全メディア・リカバリ操作に必要な手順について説明します。この項の内容は、次のとおりです。
この項では、データベースをオープンしていないときに完全リカバリを実行する手順について説明します。破損したすべてのデータファイルに対して一度にリカバリ操作を実行することも、破損した個々のデータファイルに対して個別にリカバリ操作を実行することもできます。
破損または欠落しているデータファイルをリストアおよびリカバリする手順
データベースがオープンしている場合は、V$RECOVER_FILEを問い合せ、リカバリする必要があるデータファイルおよびリカバリする必要がある理由を確認します。
Point-in-Timeリカバリではなく完全リカバリの実行を計画している場合は、データベース全体ではなくリカバリが必要なデータファイルのみをリカバリすることができます。Point-in-Timeリカバリでは、TSPITRを実行しないかぎり、すべてのデータファイルをリストアおよびリカバリする必要があります(第21章「RMANの表領域のPoint-in-Timeリカバリ(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ビューを使用することによって便利な結合を実行して、データファイルおよび表領域の名前を取得することもできます。次のSQL*Plusコマンドを使用して、問合せの出力の書式を設定します。
COL DF# FORMAT 999
COL DF_NAME FORMAT A35
COL TBSP_NAME FORMAT A7
COL STATUS FORMAT A7
COL ERROR FORMAT A10
COL CHANGE# FORMAT 99999999
SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name,
d.STATUS, r.ERROR, r.CHANGE#, r.TIME
FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# = r.FILE#;
ERROR列で、リカバリが必要な各ファイルに関する問題を識別します。
V$ARCHIVED_LOGおよびV$RECOVERY_LOGビューを問い合せて、必要なアーカイブREDOログ・ファイルを確認します。
V$ARCHIVED_LOGには、すべてのアーカイブREDOログのファイル名が表示されます。V$RECOVERY_LOGには、データベースでメディア・リカバリを実行する必要があるアーカイブREDOログのみが表示されます。後者のビューには、LOG_ARCHIVE_FORMATパラメータを使用して指定したネーミング規則に基づいて、考えられるファイルの名前も表示されます。
|
注意: V$RECOVERY_LOGは、データファイルのメディア・リカバリが必要な場合にのみ移入されます。このため、ユーザー・エラーからのリカバリなど、計画されたリカバリにはこのビューは役に立ちません。
データファイルのリカバリが必要な場合に、データファイルのバックアップが存在しないときは、データベースにデータファイルが追加された後に生成されたすべてのREDOが必要です。 |
デフォルトの場所ですべてのアーカイブ・ログが使用可能な場合は、手順4にスキップします。
一部のアーカイブ・ログをリストアする必要があるときに、使用可能な領域が十分にある場合は、LOG_ARCHIVE_DEST_1で指定された場所に必要なアーカイブREDOログ・ファイルをリストアします。メディア・リカバリ中に正しいログが必要になると、自動的にログが検索されます。たとえば、LinuxまたはUNIXでは、次のコマンドを入力します。
% cp /disk2/arch/* $ORACLE_HOME/oradata/trgt/arch
使用可能な領域が十分にない場合は、必要なアーカイブREDOログ・ファイルの一部またはすべてを別の場所にリストアします。
データベースがオープンしている場合は、データベースを停止します。次に例を示します。
SHUTDOWN IMMEDIATE
メディアを検査して問題の原因を確認します。
メディア障害の原因であるハードウェアの問題が一時的なもので、データが破損していない場合(ディスクやコントローラの停電が発生した場合など)は、メディア・リカバリは必要ありません。データベースを起動して、通常の操作を再開します。
問題を解決できない場合は、手順6に進みます。
ファイルが永続的な損傷を受けた場合には、破損したファイルの最新のバックアップを識別します。メディア障害によって破損したデータファイルのみをリストアします。破損していないデータファイルまたはオンラインREDOログ・ファイルはリストアしないでください。
たとえば、破損したファイルがORACLE_HOME/oradata/trgt/users01.dbfのみであり、このファイルの最新のバックアップが/backup/users01_10_24_02.dbfであるとします。特定のデータファイルのバックアップがない場合には、リカバリするための空の置換ファイルを作成できます。
オペレーティング・システム・ユーティリティを使用して、デフォルトの場所または新しい場所にデータファイルをリストアします。たとえば、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デバイスをサポートするオペレーティング・システム・ユーティリティを使用する必要があります。
管理者権限でデータベースに接続します。新しいインスタンスを起動して、データベースをマウントします(ただし、オープンはしません)。たとえば、次のように入力します。
STARTUP MOUNT
1つ以上の破損したデータファイルを代替の場所にリストアした場合は、データベースの制御ファイルを更新して、新しいデータファイル名を反映させます。たとえば、表領域usersのデータファイルのファイル名を変更するには、次のように入力します。
ALTER DATABASE RENAME FILE '?/oradata/trgt/users01.dbf' TO
'/disk2/users01.dbf';
現行の制御ファイルに通常付随するデータファイルのリストを調べるか、V$DATAFILEビューを問い合せて、すべてのデータファイルのデータファイル名およびステータスを取得します。たとえば、次のように入力します。
SELECT NAME,STATUS FROM V$DATAFILE;
リカバリが必要なすべてのデータファイルがオンラインにされていることを確認します。唯一の例外は、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
アーカイブREDOログを代替格納場所にリストアした場合は、SQL*Plusで SETコマンドのLOGSOURCEパラメータを使用して、メディア・リカバリの前の場所を特定できます。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。
SET LOGSOURCE /tmp
あるいは、手順12をスキップして、手順13に示すようにRECOVERコマンドでFROMパラメータを使用します。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。
RECOVER AUTOMATIC FROM '/tmp' DATABASE
|
注意: REDOログのソースを変更しても、アーカイブされているオンラインREDOログ・グループのアーカイブREDOログの出力先は影響を受けません。 |
データベース、表領域またはデータファイルのリカバリのための文を発行します。たとえば、次のいずれかの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ログ・ファイルが適用され、リカバリが終了します。
リカバリ完了後に、データベースをオープンして使用します。
ALTER DATABASE OPEN;
アーカイブ・ログを適用し、オフライン・ストレージに各アーカイブ・ログ・グループのコピーがまだ存在していることを確認した後、アーカイブREDOログ・ファイルのリストアされたコピーを削除してディスク領域を解放します。たとえば、次のように入力します。
% rm /tmp/*.arc
データベースをオープンしているときにメディア障害が発生した場合は、破損していないデータファイルはオンラインのまま使用できる場合があります。データベース・ライターがファイルに書き込めない場合は、破損したファイルは自動的にオフラインにされますが、破損したファイルを含む表領域はオフラインにされません。データベース・ライターがデータファイルをオープンできない場合は、引き続きエラーが戻されます。破損したファイルを読み取れない問合せはエラーを戻しますが、問合せが失敗したためにデータファイルがオフラインにされることはありません。たとえば、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から3を実行します。
データベースがオープンしている場合は、破損したデータファイルを含むすべての表領域をオフラインにします。たとえば、破損したデータファイルが表領域usersおよびtoolsに含まれている場合は、次のSQL文を実行します。
ALTER TABLESPACE users OFFLINE TEMPORARY; ALTER TABLESPACE tools OFFLINE TEMPORARY;
TEMPORARYを指定すると、Oracle Databaseによって、表領域内のすべてのオンライン・データファイルに対してチェックポイントが作成されます。この文の発行時にオフラインであるファイルでは、表領域をオンラインに戻す前に、メディア・リカバリが必要な場合があります。IMMEDIATEを指定すると、表領域をオンラインに戻す前に、表領域に対してメディア・リカバリを実行する必要があります。
メディアを検査して問題の原因を確認します。
DBVERIFYユーティリティを使用すると、オフライン・データファイルに対して整合性チェックを実行できます(「DBVERIFYユーティリティの実行」を参照)。
メディア障害の原因であるハードウェアの問題が一時的なもので、データが破損していない場合、メディア・リカバリは必要ありません。オフライン表領域をオンラインにし、通常の操作を再開することができます。問題を解決できない場合、またはDBVERIFYによって破損ブロックがレポートされた場合は、手順4に進みます。
ファイルが永続的に破損された場合は、オペレーティング・システム・コマンドを使用して、メディア障害によって破損されたデータファイルのみの最新のバックアップ・ファイルをリストアします。たとえば、データファイルusers01.dbfをリストアするには、LinuxまたはUNIXでcpコマンドを次のように実行します。
% cp /disk2/backup/users01.dbf $ORACLE_HOME/oradata/trgt/users01.dbf
ハードウェアの問題が解決され、データファイルを元の場所にリストアできる場合は、その場所にリストアします。それ以外の場合は、代替のストレージ・デバイスにデータファイルをリストアします。破損していないデータファイル、オンラインREDOログまたは制御ファイルはリストアしないでください。
|
注意: 状況によっては、特定のデータファイルのバックアップがない場合に、ALTER DATABASE CREATE DATAFILE文を使用して、リカバリ可能な空の置換ファイルを作成できることもあります。 |
1つ以上の破損したデータファイルを代替の場所にリストアした場合は、データベースの制御ファイルを更新して、新しいデータファイル名を反映させます。たとえば、表領域usersのデータファイルのファイル名を変更するには、次のように入力します。
ALTER DATABASE RENAME FILE '?/oradata/trgt/users01.dbf' TO
'/disk2/users01.dbf';
アーカイブREDOログを代替格納場所にリストアした場合は、SQL*Plusで SETコマンドのLOGSOURCEパラメータを使用して、メディア・リカバリの前の場所を特定できます。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。
SET LOGSOURCE /tmp
あるいは、手順6をスキップして、手順7に示すようにRECOVERコマンドでFROMパラメータを使用します。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。
RECOVER AUTOMATIC FROM '/tmp' TABLESPACE users, tools;
|
注意: REDOログのソースを変更しても、アーカイブされているオンラインREDOログ・グループのアーカイブREDOログの出力先は影響を受けません。 |
管理者権限を使用してデータベースに接続します。一度の手順で、1つ以上のオフライン表領域の破損したすべてのデータファイルについて、オフライン表領域のリカバリを開始します。 たとえば、usersおよびtoolsのリカバリを行うには、次のように入力します。
RECOVER AUTOMATIC TABLESPACE users, tools;
必要なアーカイブREDOログおよびオンラインREDOログが適用され、リストアしたデータファイルが再構築されて、メディア・リカバリのロールフォワード・フェーズが開始されます。RECOVER AUTOMATICまたはSET AUTORECOVERY ONによってファイルの適用が自動化されていないかぎり、必要なREDOログ・ファイルごとにプロンプトが表示されます。
必要なすべてのアーカイブ・ログがデータファイルに適用されるまで、リカバリは続行されます。次に、オンラインREDOログがリストアされたデータファイルに自動的に適用され、メディア・リカバリが完了します。完全メディア・リカバリにアーカイブREDOログが必要ない場合は、プロンプトは表示されません。かわりに、必要なすべてのオンラインREDOログが適用され、メディア・リカバリが完了します。
破損した表領域をメディア障害が発生した時点までリカバリできたら、オフラインの表領域をオンラインにします。たとえば、表領域usersおよびtoolsをオンラインにするには、次の文を発行します。
ALTER TABLESPACE users ONLINE; ALTER TABLESPACE tools ONLINE;
|
関連項目: データファイルを作成する方法については、『Oracle Database管理者ガイド』を参照してください。ALTER DATABASERENAME FILEについては、 |
通常、次のような場合にデータベースのPoint-in-Timeリカバリ(DBPITR)を実行します。
ユーザー・エラーまたは管理エラーの前のSCNまでデータベースをリカバリする場合。
データベースに破損ブロックが含まれている場合。
必要なすべてのアーカイブREDOログが使用可能ではなかったためデータベースの完全リカバリに失敗した場合。
本番データベース・バックアップからテスト・データベースまたはレポート・データベースを作成する場合。
データベースをARCHIVELOGモードで実行しているときに、アーカイブREDOログ・ファイルの唯一のコピーが破損した場合には、破損したファイルが、データベースの現在の動作に影響を与えることはありません。表29-2に、REDOログが書き込まれた場合、およびデータファイルをバックアップした場合に応じて発生する可能性がある状況を示します。
表29-2 アーカイブREDOログの消失
| バックアップ対象 | 現在の状態 |
|---|---|
|
一杯になったオンラインREDOログ・グループ(現在アーカイブされている)が書き込まれた後のすべてのデータファイル |
完全メディア・リカバリに、一杯になったオンラインREDOログ・グループのアーカイブされたバージョンは必要ありません。 |
|
一杯になったオンラインREDOログ・グループが書き込まれる前の特定のデータファイル |
対応するデータファイルが永続的なメディア障害によって破損した場合は、破損したデータファイルの最新のバックアップを使用して、破損したアーカイブREDOログ・ファイルに至るまで、破損したデータファイルの表領域のPoint-in-Timeリカバリを実行します。 |
|
注意: アーカイブREDOログ・グループが破損したことがわかっている場合は、破損したアーカイブREDOログを必要としない、データベース全体のバックアップを作成するために、すぐにすべてのデータファイルをバックアップします。 |
DBPITRでの方法は、特定の時刻またはSCNを指定するか、あるいはCANCELと入力することによって終了する点以外は、「クローズしているデータベースのリカバリの実行」に示す方法と非常に類似しています。取消しベースのリカバリでは、アーカイブREDOログ・ファイルの推奨ファイル名がプロンプトに表示されます。ユーザーがファイル名のかわりにCANCELを指定するか、すべてのREDOがデータファイルに適用されると、リカバリは停止します。リカバリを終了するアーカイブ・ログを制御する場合は、取消しベースのリカバリが最適な方法です。
この項の手順では、次のことが想定されています。
現行の制御ファイルが使用可能です。制御ファイルをリストアまたは再作成する必要がある場合は、「現行の制御ファイルがすべて消失した場合のリカバリ」を参照してください。
必要なすべてのデータファイルのバックアップがあります。データファイルのバックアップが欠落している場合は、「バックアップが利用できない場合のデータファイルの再作成」を参照してください。
この項の内容は、次のとおりです。
取消しベースのリカバリでは、ユーザーに対してアーカイブREDOログ・ファイルのファイル名を提示するプロンプトを表示して、リカバリが進行していきます。ユーザーがファイル名のかわりにCANCELを指定するか、すべてのREDOがデータファイルに適用されると、リカバリは停止します。
取消しベースのリカバリを実行する手順
「クローズしているデータベースのリカバリの実行」の手順1から8を実行します。
SQL*Plusで次のコマンドを発行し、取消しベースのリカバリを開始します。
RECOVER DATABASE UNTIL CANCEL
|
注意: RECOVERコマンドのUNTIL句を指定しなかった場合は、完全リカバリを実行するとみなされ、すべてのREDOが適用されるまではデータベースをオープンできません。 |
リストアしたデータファイルを再構築するために必要なREDOログ・ファイルが適用されます。 データベースは、LOG_ARCHIVE_DEST_1から検索する名前を提示します。ユーザーは、そのログ・ファイルを適用するかどうかの決定を求められます。制御ファイルがバックアップの場合は、オンラインREDOログの変更を適用する場合、オンラインREDOログの名前を指定する必要があります。
リストアされたデータファイルに最後のログが適用されるまで、REDOログ・ファイルの適用を続けた後、次のコマンドを実行して、リカバリを取り消します。
CANCEL
リカバリが成功したかどうかが示されます。すべてのデータファイルが整合性のあるSCNまでリカバリされる前にリカバリを取り消し、その後データベースをオープンしようとすると、さらにリカバリが必要な場合は、ORA-1113エラーが表示されます。V$RECOVER_FILEを問い合せると、さらにリカバリが必要かどうか、または不完全リカバリの開始前にデータファイルのバックアップがリストアされていなかったかどうかを確認できます。
RESETLOGSオプションを指定してデータベースをオープンします。不完全リカバリまたはバックアップ制御ファイルを使用したリカバリの後は、ログをリセットする必要があります。次に例を示します。
ALTER DATABASE OPEN RESETLOGS;
ログのリセットが不適切な状況でOPEN RESETLOGSを使用しようとした場合、またはログをリセットする必要がある状況でログをリセットしなかった場合はエラーが戻され、データベースはオープンされません。問題を解決して再試行してください。
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
また、アラート・ログも確認して、データ・ディクショナリと制御ファイルの間の矛盾がデータベースで検出されていないかを調べます。表29-3に、2つの例を示します。
表29-3 データ・ディクショナリと制御ファイルの間の矛盾
| 制御ファイルに示されているデータファイル | データ・ディクショナリに示されているデータファイル | 結果 |
|---|---|---|
|
あり |
なし |
示されていないデータファイルへの参照が、制御ファイルから削除されます。アラート・ログのメッセージに、検出された内容が表示されます。 |
|
なし |
あり |
制御ファイルの |
この項では、リカバリの終了位置に対してSCNまたは時刻を指定する方法について説明します。データベースが季節的な時間変更(たとえば夏時間)の影響を受ける場合には、REDOログの中に1つの時間が2度出現し、2番目の、つまり後の時間までリカバリを行う場合に、問題が発生します。時間の変更を処理するには、取消しベースまたは変更ベースのリカバリを実行します。
変更ベースまたは時間ベースのリカバリを実行する手順
「クローズしているデータベースのリカバリの実行」の手順1から8を実行します。
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'
リストアされたデータファイルのリカバリに必要なREDOログ・ファイルを適用します。正しい時刻になるとリカバリは自動的に停止し、リカバリが成功したかどうかを示すメッセージが戻されます。
「取消しベースの不完全リカバリの実行」の手順4および5を実行します。
メディア障害によって、NOARCHIVELOGモードのデータベースのデータファイルが破損した場合は、通常、一貫性のあるデータベース全体のバックアップをリストアすることによってのみリカバリできます。Oracle Data Pump Exportで作成した論理バックアップを使用して通常の物理バックアップを補完している場合は、データベースのエクスポートされたバックアップを、再作成したデータベースまたは古いバックアップからリストアしたデータベースにインポートして、データベースのリストアを試行することもできます。
最新のデータベース全体のバックアップをリストアおよびリカバリする手順
データベースがオープンしている場合は、データベースを停止します。たとえば、次のように入力します。
SHUTDOWN IMMEDIATE
可能であれば、メディアの問題を解決して、バックアップ・データベース・ファイルを元の場所にリストアできるようにします。
オペレーティング・システム・コマンドを使用して、最新のデータベース全体のバックアップをリストアします。破損したファイルのみでなく、データベース全体のバックアップの、すべてのデータファイルおよび制御ファイルをリストアします。ハードウェアの問題が解決できず、データベース・ファイルの一部またはすべてを代替の場所にリストアする必要がある場合は、データベース全体のバックアップを新しい場所にリストアします。次の例は、データベース全体のバックアップをデフォルトの場所にリストアします。
% cp /backup/*.dbf $ORACLE_HOME/oradata/trgt/
必要に応じて、リストアされた初期化パラメータ・ファイルを編集して、制御ファイルの新しい場所を示します。次に例を示します。
CONTROL_FILES = "/new_disk/oradata/trgt/control01.dbf"
リストアして編集したパラメータ・ファイルを使用してインスタンスを起動し、データベースをマウントします(ただし、オープンはしません)。次に例を示します。
STARTUP MOUNT
リストアされたデータファイルのファイル名が異なる場合(同じノードまたは異なるノードの異なるファイル・システムまたはディレクトリにリストアする場合など)、制御ファイルを更新して新しいデータファイルの場所を反映させます。たとえば、データファイル1の名前を変更するには、次のように入力します。
ALTER DATABASE RENAME FILE '?/oradata/trgt/system01.dbf' TO
'/new_disk/oradata/system01.dbf';
オンライン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';
オンラインREDOログはバックアップされないため、データファイルおよび制御ファイルとともにリストアすることはできません。データベースでオンラインREDOログをリセットできるように、まず不完全リカバリを行う必要があります。
RECOVER DATABASE UNTIL CANCEL CANCEL
RESETLOGSモードでデータベースをオープンします。このコマンドによって、オンラインREDOログが消去され、ログ順序が1にリセットされます。
ALTER DATABASE OPEN RESETLOGS;
NOARCHIVELOGモードのデータベースのバックアップをリストアした後、ログをリセットすると、バックアップが作成されてから障害が発生するまでの間にデータベースに対して行われたすべての変更が廃棄されます。
|
関連項目: データファイルの名前の変更および場所の変更の詳細は、『Oracle Database管理者ガイド』を参照し、ALTER DATABASERENAME FILEについては、 |
この項では、ユーザー管理のメディア・リカバリ(Recovery Manager (RMAN)を使用しないで実行するメディア・リカバリ)のトラブルシューティングの方法について説明します。この項の内容は、次のとおりです。
表29-4に、メディア・リカバリ中に発生する可能性がある問題を示します。
表29-4 メディア・リカバリの問題
| 問題 | 説明 |
|---|---|
|
アーカイブ・ログの欠落または名前の誤り |
制御ファイルに記録されたアーカイブ・ログが見つからないため、リカバリは停止します。 |
|
データベースをオープンしようとすると、 |
このエラーの一般的な原因は次のとおりです。
|
|
2つの状況が考えられます。
|
|
|
格納中またはストレージ・システム間でコピーされるときに、ログが破損した可能性があります。 |
|
|
パラレルREDO機能を有効にした場合、REDOログが新規のフォーマットで生成されます。以前のリリースのOracleでは、パラレルREDOログを適用できません。ただし、Oracle9i Databaseリリース2(9.2)より前のリリースでは、パラレルREDOフォーマットを検出し、エラー・メッセージ「 |
|
|
データファイルのバックアップに破損したデータ・ブロックが含まれているか、リカバリ中またはバックアップにコピーされたときにデータ・ブロックが破損しました。 |
|
|
その他の問題 |
リカバリ中には、メモリーの破損や、その他の一時的な問題が発生することがあります。 |
メディア・リカバリの問題は通常、リカバリ中に通知される外部エラーまたは内部エラーとして出現します。たとえば、外部エラーは、REDOブロックまたはデータ・ブロックでチェックサム検証チェックが失敗したことを示します。内部エラーは、データベースの不具合か、基礎となるオペレーティング・システムおよびハードウェアに起因するエラーによって発生する可能性があります。
メディア・リカバリで、データベース・バックアップのリカバリ中に問題が発生した場合は、スタック・リカバリの問題またはREDO適用中の問題であるかどうかに関係なく、データベースは常に停止し、リカバリ中のデータファイルを一貫性のある状態、つまり、障害前の一貫性のあるSCNのままにします。次のいずれかを実行できます。
データベースを読取り専用でオープンし、問題を調査します。
RESETLOGSオプションを指定してデータベースをオープンします(RESETLOGSのオープンの要件が満たされている場合)。スタンバイ・データベースはメディア・リカバリの形態で更新されるため、RESETLOGSの制限は、フィジカル・スタンバイ・データベースをオープンする場合にも適用されます。
一般に、データベースを読取り専用でオープンしたり、RESETLOGSオプションを指定してオープンする場合には、すべてのオンライン・データファイルを同じSCNまでリカバリする必要があります。この要件が満たされない場合は、ユーザーがオープンを試行すると、ORA-1113またはその他のエラーが通知されることがあります。ORA-1113の一般的な原因については、表29-4を参照してください。
一般に、メディア・リカバリの問題には、次のように対処します。
問題の原因を確認します。必要に応じて試行リカバリを実行します。
問題がREDOログの欠落に関係するか、REDOログ、メモリーまたはデータ・ブロックが破損している可能性がある場合は、表29-5に示す方法で問題の解決を試みます。
表29-5に示す方法を使用しても問題を解決できない場合は、次のいずれかを実行します。
データベース全体のバックアップのリカバリを行う場合は、RESETLOGSオプションを指定してデータベースをオープンします。シリアル・メディア・リカバリを実行した場合は、データベースには、破損が発生したSCNの前までのすべての変更が含まれています。このSCN以降の変更は、データベースのリカバリされた部分に含まれていません。オンライン・バックアップをリストアした場合は、RESETLOGSによるオープンは、REDOストリーム中のすべてのALTER ... END BACKUP操作までリカバリが完了している場合にのみ成功します。
データ・ブロックを破損させることをメディア・リカバリに許可して、リカバリを続行します。メディア・リカバリが完了した後、RMANを使用してブロック・メディア・リカバリを実行してください。
それでも問題が解決しない場合は、Oracleサポート・サービスに連絡します。
メディア・リカバリで問題が発生した場合は、リカバリが停止した後、できるだけ多くの情報を入手してください。解決する問題を誤って時間を消費し、さらに問題を悪化させることを防ぐためです。
最初に、問題の原因が、設定の誤り、REDOログの破損、データ・ブロックの破損、メモリーの破損、またはその他の原因のどれかを確認します。データ・ブロックのチェックサムにエラーがある場合には、データ・ブロックが破損しています。REDOログ・ブロックのチェックサムにエラーがある場合には、REDOログが破損しています。
リカバリの問題の原因は、特定するのが困難な場合があります。問題の原因が完全にはわからない場合でも、この項に示す方法を使用すると、データベースのリカバリを迅速に実行できます。
メディア・リカバリの問題を調査する手順
alert.logを調べて、エラー・メッセージに問題の性質についての一般的な情報が記載されているかを確認します。たとえば、alert_SID.logにチェックサムのエラーが示されているかどうかを確認します。また、メディア・リカバリを続行するためにデータ・ブロックの破損を許可する必要があることが示されているかどうかを確認します。
リカバリ中にOracle Databaseによって生成されたトレース・ファイルを調べます。追加のエラー情報が含まれていることがあります。
メディア・リカバリの問題のタイプに応じて、いくつかの解決方法があります。表29-5に示す方法の1つ、あるいはその組合せを使用できます。これらの解決方法は、一般的な修復方法です。比較的安全に、ほとんどのメディア・リカバリの問題を解決できます。
表29-5 メディア・リカバリの解決方法
| 発生した可能性がある問題 | 現在の状態 |
|---|---|
|
アーカイブREDOログの欠落または名前の誤り |
ファイル名が正しく入力されているかを確認します。正しく入力されていた場合には、オペレーティング・システムからログが欠落しているかを確認します。欠落している場合に、バックアップがあれば、バックアップをリストアし、ログを適用します。バックアップがない場合には、可能であれば、欠落したログの時点まで不完全リカバリを実行します。 |
|
|
表29-4で、このエラーの原因を検討します。リカバリが必要なすべての読取り/書込みデータファイルがオンラインにされていることを確認します。 リカバリにバックアップ制御ファイルを使用した場合には、制御ファイルとデータファイルのSCNに一貫性がないかぎり、データベースをオープンできません。必要なREDOがない場合には、制御ファイルを再作成する必要があります。 |
|
アーカイブ・ログの破損 |
ログREDOブロックのチェックサム検証が失敗したときには、ログが破損しています。リカバリ・セッション中、またはデータベースがREDOを生成したときに
|
|
互換性のないパラレルREDOフォーマットによるアーカイブ・ログ |
Oracle9i Databaseリリース2より前のOracle Databaseリリースを実行している場合、パラレルREDOフォーマットで作成されたREDOログを適用するには、次の手順を実行する必要があります。
|
|
メモリーの破損または一時的な問題 |
データベースを停止してリカバリを再開すると、問題を解決できる場合があります。2回目の試行も失敗した場合は、データベースを一貫性のある状態のままにしておく必要があります。 |
|
データ・ブロックの破損 |
ユーザー管理の方法を使用して、データファイルのリストアおよびリカバリを再度実行するか、またはRMANの データ・ブロックのチェックサム検証が失敗した場合は、データ・ブロックが破損しています。 |
表29-5に示す方法で問題を解決できない場合は、データを消失せずに、簡単に問題を解決できる方法がない可能性があります。次のようなオプションがあります。
RESETLOGSオプションを指定してデータベースをオープンします(データベース全体のリカバリのため)。
この解決方法では、REDOの問題が発生した時点以降のすべての変更が廃棄されますが、データベースの論理的一貫性は保証されます。
メディア・リカバリで1つ以上のデータ・ブロックを破損させることを許可して、続行します。
このオプションは、アラート・ログに、データ・ブロックを破損させることを許可すればリカバリを続行できることが示されている場合にのみ成功します。これはほとんどのリカバリの問題に当てはまります。データベースを迅速に起動し、すべての変更をリカバリする必要がある場合は、このオプションが最適です。 このオプションを検討する場合は、「リカバリでブロックの破損とマークできるようにするかどうかの決定: フェーズ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文を使用します。
これらの調査を実行した後、表29-6のガイドラインに従って、リカバリでブロックの破損を許可するかどうかを決定します。
表29-6 リカバリでブロックの破損を許可するためのガイドライン
| 問題の状態 | ブロック | 現在の状態 |
|---|---|---|
|
分離されていない |
多くの場合、 |
|
|
分離されている |
|
最終的にデータベースをオープンできなくなる可能性があるため、ブロックは破損させないでください。ただし、 |
|
分離されている |
索引データ |
データベースのリカバリ後に索引を再作成できるため、索引ブロックを破損させることを検討してください。 |
|
分離されている |
ユーザー・データ |
データの重要性に基づいて決定します。データファイルのリカバリを続行し、ブロックを破損させると、ブロック内のデータが消失します。ただし、データファイルのリカバリが完了した後で、RMANを使用してブロック・メディア・リカバリを実行できます。 |
|
分離されている |
ロールバックまたはUNDOデータ |
すべてのトランザクションがコミットされる場合は、ロールバックまたはUNDOブロックを破損させることを検討します。UNDOを生成したトランザクションをロールバックしない場合は、データベースに害はありません。ただし、これらのトランザクションをロールバックする場合は、UNDOブロックを破損させると問題が発生する可能性があります。判断できない場合は、Oracleサポート・サービスに連絡してください。 |
|
関連項目: 試行リカバリの実行方法については、「試行リカバリの実行」を参照してください。リカバリでブロックの破損を許可するように決定した場合は、「リカバリでのブロックの破損の許可: フェーズ4」を参照してください。 |
リカバリの続行のために、ブロックの破損を許可することを決定した場合には、ALLOW n CORRUPTION句を指定してRECOVERコマンドを実行します。このnは、破損させることを許可するブロックの数です。
リカバリでブロックを破損させることを許可する手順
リカバリの通常の前提条件がすべて満たされていることを確認します。たとえば、データベースがオープンしている場合には、リカバリを試みる前に、表領域をオフライン化します。
次の例に示すように、RECOVERコマンドを実行します。
RECOVER DATABASE ALLOW 5 CORRUPTION
スタック・リカバリなどの問題が発生した場合、判断が困難な場合があります。ブロックが比較的重要でなく、問題が分離されている場合は、通常、ブロックを破損させます。ただし、問題が分離されていない場合は、RESETLOGSオプションを指定してデータベースをオープンする方がよい場合があります。
このため、Oracle Databaseでは、試行リカバリがサポートされています。試行リカバリは、通常のメディア・リカバリと同じ方法でREDOを適用しますが、ディスクに変更を書き込むことはなく、必ず変更をロールバックします。試行リカバリはメモリー内でのみ発生します。
デフォルトでは、試行リカバリでスタック・リカバリやその他の問題が検出されると、常に、メモリー内でデータ・ブロックに破損しているというマークが付けられます(このアクションによってリカバリを続行できる場合)。試行リカバリ中に生成されたエラーは、アラート・ファイルに書き込まれます。これらのエラーは、テスト実行のエラーであることが明示されます。
試行リカバリでは、通常のメディア・リカバリと同様に、アーカイブ・ログのファイル名を指定するプロンプトが表示され、ユーザーは、ログを適用するかどうかを判断するように求められます。試行リカバリは次の場合に終了します。
試行リカバリ用に使用できるメモリー内の最大バッファ数がすべて使用された場合
リカバリ不能なエラー(データ・ブロックを破損させても解決できないエラー)が通知された場合
ユーザーがリカバリ・セッションを取り消したか中断した場合
REDOストリーム内の次のREDOレコードによって制御ファイルが変更された場合
必要なREDOがすべて適用された場合
試行リカバリが終了すると、アラート・ファイル内のエラー・メッセージを除き、テスト実行のすべての影響がシステムから削除されます。試行リカバリ中にインスタンスの障害が発生した場合は、試行リカバリが変更をディスクに書き込むことはないため、試行リカバリのすべての影響がシステムから削除されます。
試行リカバリを使用することによって、通常のリカバリを続行した場合に発生する可能性のある問題を予測できます。進行中のメモリーの破損を原因とする問題の場合は、試行リカバリと通常のリカバリで発生するエラーが異なることがあります。
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句を指定すると、試行リカバリの実行時にメモリー内で破損させることができるデータ・ブロックの数を制限できます。
試行リカバリのコマンドは、通常リカバリのコマンドを使用できるすべての場合に使用できます。ただし、試行リカバリを実行する必要があるのは、リカバリで問題が発生する場合のみです。
