11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、データベースをリストアおよびリカバリする方法、およびユーザー管理のバックアップおよびリカバリ計画（Recovery Managerを必要としない計画）を使用する場合にOracleフラッシュバック機能を使用する方法について説明します。
この章の内容は、次のとおりです。
Oracle Flashback Databaseを使用すると、バックアップからファイルをリストアせずに、データベース全体を元の状態に戻すことができます。SQL*PlusのFLASHBACK DATABASEコマンドの機能は、Recovery ManagerのFLASHBACK DATABASEコマンドと同じです。このコマンドを実行すると、データベースが元の状態に戻されます。
フラッシュバック・データベースを使用する場合は、データベース用のフラッシュ・リカバリ領域を作成し、フラッシュバック・ログの収集を有効にする必要があります。フラッシュバック・データベース機能の動作、フラッシュバック・データベースの使用要件およびフラッシュバック・データベースに必要なフラッシュバック・ログの収集を有効にする方法の詳細は、第16章「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照してください。Recovery ManagerまたはSQL*Plusのいずれを使用する場合でも、要件および準備は同じです。
SQL*Plusでデータベースのフラッシュバックを実行する手順
SELECT CURRENT_SCN FROM V$DATABASE; SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME FROM V$FLASHBACK_DATABASE_LOG;
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でデータベースを現在の状態に戻して、消失したオブジェクトを再インポートすることもできます。
この項では、SQL*Plusを使用したリカバリの概要について説明します。この項の内容は、次のとおりです。
通常、メディア障害またはユーザー・エラーによって1つ以上のデータファイルが破損したり削除された場合に、ファイルをリストアします。ユーザー管理のリストア操作では、オペレーティング・システムのユーティリティを使用してファイルのバックアップをリストアします。
メディア障害がデータファイルに影響を与えた場合、リカバリの手順は次の条件によって異なります。
ARCHIVELOGまたはNOARCHIVELOG）
永続的または一時的なメディア障害によって、NOARCHIVELOGモードで実行しているデータベースのデータファイルが影響を受けた場合、データベースは自動的に停止します。メディア障害が一時的な場合は、原因となっている問題を解決し、データベースを再起動します。通常、クラッシュ・リカバリによって、コミット済のすべてのトランザクションがオンラインREDOログを使用してリカバリされます。メディア障害が永続的な場合は、「NOARCHIVELOGモードでのデータベースのリカバリ」の説明に従ってデータベースをリカバリします。
表28-1に、ARCHIVELOGモードで実行されているデータベースでファイルを消失した場合に実行するメディア・リカバリについての説明を示します。
| 消失したもの | 説明 |
|---|---|
|
|
データベースは自動的に停止します。ハードウェアの問題が一時的な場合には、問題を解決し、データベースを再起動します。通常、クラッシュ・リカバリによって、消失したトランザクションがリカバリされます。ハードウェアの問題が永続的な場合は、「クローズしているデータベースのリカバリの実行」の説明に従って、バックアップからデータファイルをリストアし、データベースをリカバリします。 |
|
|
影響を受けたデータファイルがオフライン化されますが、データベースはオープンしたままです。データベースの影響を受けていない部分を使用可能なままにしておく必要がある場合には、データベースを停止しないでください。一時オプションを使用して、問題が発生したデータファイルを含む表領域をオフラインにした後、「オープンしているデータベースのリカバリの実行」の説明に従ってリカバリします。 |
|
現行の制御ファイルのすべてのコピー |
バックアップ制御ファイルをリストアし、
バックアップがない場合には、制御ファイルを再作成してください。可能であれば、 |
|
多重制御ファイルの1つのコピー |
影響を受けていない多重制御ファイルの1つを破損または欠落した制御ファイルの場所にコピーして、データベースをオープンします。元の場所に制御ファイルをコピーできない場合は、初期化パラメータ・ファイルを編集して新しい場所を反映するか、または破損した制御ファイルを削除します。その後、データベースをオープンします。 |
|
メディア・リカバリに必要な1つ以上のアーカイブ・ログ |
リカバリを実行するには、これらのアーカイブ・ログのバックアップをリストアする必要があります。デフォルトの場所またはデフォルト以外の場所にリストアできます。バックアップがない場合には、欠落している最初のREDOログの前のSCNまで不完全リカバリを実行し、 |
|
サーバー・パラメータ・ファイル（SPFILE） |
サーバー・パラメータ・ファイルのバックアップがある場合には、これをリストアします。また、クライアント側の初期化パラメータ・ファイルのバックアップがある場合には、このファイルのバックアップをリストアし、インスタンスを起動した後、サーバー・パラメータ・ファイルを再作成できます。 |
メディア・リカバリの実行には、SQL*PlusのRECOVER文を使用することをお薦めします。SQL文のALTER DATABASE RECOVERも使用できますが、ほとんどの場合、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です）。
データファイル・バックアップをリストアした後、SET AUTORECOVERY ONコマンドを実行すると、自動リカバリが有効になります。たとえば、SQL*Plusに次のコマンドを入力すると、自動リカバリを実行し、データベースをオープンできます。
STARTUP MOUNT SET AUTORECOVERY ON RECOVER DATABASE ALTER DATABASE OPEN;
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の値が変更されていない場合は、ログ・ファイルが提示および適用され、メディア・リカバリが自動的に実行されます。
アーカイブ・ログがデフォルトの場所にない場合にメディア・リカバリを実行するには、追加の処理が必要です。次のいずれかの方法を選択します。
LOG_ARCHIVE_DEST_nパラメータを編集し、通常どおりにリカバリします。
SET文を使用してデフォルト以外のログの場所を指定するか、RECOVERコマンドのFROMパラメータを使用します。
初期化パラメータ・ファイルを編集するか、ALTER SYSTEM文を発行して、アーカイブREDOログのデフォルトの場所を変更できます。
リカバリ前にアーカイブ・ログのデフォルトの場所を変更する手順
% cp /backup/arch/* /tmp/
ALTER SYSTEM文を発行するか、初期化パラメータ・ファイルを編集した後にデータベース・インスタンスを起動します。たとえば、インスタンスの停止中にパラメータ・ファイルを次のように編集します。
LOG_ARCHIVE_DEST_1 = 'LOCATION=/tmp/' LOG_ARCHIVE_FORMAT = arcr_%t_%s.arc
STARTUP MOUNT
RECOVER DATABASE
場合によっては、アーカイブの出力先パラメータの現在の設定を変更して、アーカイブ・ログ・ファイルの入力元を変更することもできます。
SET LOGSOURCEを使用して、デフォルト以外の場所のアーカイブ・ログをリカバリする手順
% cp $ORACLE_HOME/oradata/trgt/arch/* /tmp
SET文のLOGSOURCEパラメータまたはALTER DATABASE文のRECOVER ... FROM句を使用します。たとえば、SQL*Plusを起動して次のように実行します。
SET LOGSOURCE "/tmp"
usersをリカバリするには、次のコマンドを実行します。
RECOVER AUTOMATIC TABLESPACE users
SET LOGSOURCEを実行せずに、次のコマンドを実行することもできます。
RECOVER AUTOMATIC TABLESPACE users FROM "/tmp"
メディア・リカバリを開始した後で中断する必要がある場合は、REDOログ・ファイルのプロンプトに対してCANCELと入力します。また、個々のデータファイルのリカバリの実行時または自動リカバリの実行時に終了する必要がある場合は、オペレーティング・システムの割込みシグナルを使用します。リカバリが取り消された後、RECOVERコマンドを使用してリカバリを再開できます。リカバリは、取り消された位置から再開されます。
Oracleは、メディア・リカバリのロールフォワード・フェーズのパフォーマンスを向上するために、デフォルトでパラレル・メディア・リカバリを使用しますパラレル・メディア・リカバリでは、ロールフォワード時に各データ・ブロックに別のプロセスを割り当てる分業体制を使用することで、処理の効率を高めています。使用されるプロセスの数は、CPU_COUNT初期化パラメータで指定されます。これは、デフォルトではシステム上のCPUの数と同じです。たとえば、CPU_COUNTが4のシステム上でパラレル・リカバリを実行した場合、リカバリ対象のデータファイルが1つのみである場合には、4つの起動されたプロセスがアーカイブ・ログからブロックを読み取り、REDOを適用します。
一般的に、メディア・リカバリはデータ・ブロックの読取りおよび書込みによって制限されます。パラレル・リカバリでは、パフォーマンスを向上させるために、システムで利用可能なI/O帯域幅がすべて使用されます。システムのI/Oボトルネックが存在するか、非同期I/Oが十分にサポートされていない場合を除いて、パラレル・リカバリによってリカバリのパフォーマンスが向上する可能性があります。
パラレル・リカバリが実行されるデフォルトの動作を変更するには、NOPARALLELオプションを指定してRECOVERを使用するか、またはRECOVER PARALLEL 0を使用します。RECOVERY_PARALLELISM初期化パラメータでは、インスタンス・リカバリまたはクラッシュ・リカバリのみが制御されます。メディア・リカバリは、RECOVERY_PARALLELISMで使用される値の影響を受けません。
通常、メディア障害によって1つ以上のデータファイルにアクセスできなくなった場合に、データベースの完全リカバリを実行します。V$RECOVER_FILEビューに、リカバリが必要なファイルが示されます。データベースの完全リカバリを実行する場合は、使用可能なすべてのREDOを使用し、データベースを現行のSCNまでリカバリします。
状況に応じて、データベース全体で一度にリカバリを実行することも、個々の表領域またはデータファイルでリカバリを実行することもできます。完全リカバリの場合は、RESETLOGSオプションを指定してデータベースをオープンする必要はないため、最初に一部のデータファイルのリカバリを行ってから、後で残りのデータファイルのリカバリを行うこともできます。
この項の手順では、次のことが想定されています。
この項では、完全メディア・リカバリ操作に必要な手順について説明します。この項の内容は、次のとおりです。
この項では、データベースをオープンしていないときに完全リカバリを実行する手順について説明します。破損したすべてのデータファイルに対して一度にリカバリ操作を実行することも、破損した個々のデータファイルに対して個別にリカバリ操作を実行することもできます。
破損または欠落しているデータファイルをリストアおよびリカバリする手順
V$RECOVER_FILEを問い合せ、リカバリする必要があるデータファイルおよびリカバリする必要がある理由を確認します。Point-in-Timeリカバリではなく完全リカバリの実行を計画している場合は、データベース全体ではなくリカバリが必要なデータファイルのみをリカバリすることができます。Point-in-Timeリカバリでは、TSPITRを実行しないかぎり、すべてのデータファイルをリストアおよびリカバリする必要があることに注意してください（第20章「Recovery Managerの表領域のPoint-in-Timeリカバリ（TSPITR）の実行」を参照）。また、フラッシュバック・データベースも使用できますが、すべてのデータファイルが影響を受けるため、データベース全体が過去の状態に戻ります。
V$RECOVER_FILEを問い合せると、リカバリが必要なデータファイルを、そのステータス情報とエラー情報とともにデータファイル番号で表示できます。
SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME FROM 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ログのみが表示されます。V$RECOVERY_LOGビューでは、LOG_ARCHIVE_FORMATを使用して、考えられるファイルの名前も表示されます。
一部のアーカイブ・ログをリストアする必要があるときに、使用可能な領域が十分にある場合は、LOG_ARCHIVE_DEST_1で指定された場所に必要なアーカイブREDOログ・ファイルをリストアします。メディア・リカバリ中に正しいログが必要になると、自動的にログが検索されます。たとえば、LinuxまたはUNIXでは、次のコマンドを入力します。
% cp /disk2/arch/* $ORACLE_HOME/oradata/trgt/arch
使用可能な領域が十分にない場合は、必要なアーカイブREDOログ・ファイルの一部またはすべてを別の場所にリストアします。
SHUTDOWN IMMEDIATE
メディア障害の原因であるハードウェアの問題が一時的なもので、データが破損していない場合（ディスクやコントローラの停電など）は、メディア・リカバリは必要ありません。データベースを起動して、通常の操作を再開します。
問題を解決できない場合は、次の手順に進みます。
たとえば、破損したファイルがORACLE_HOME/oradata/trgt/users01.dbfのみであり、このファイルの最新のバックアップが/backup/users01_10_24_02.dbfであるとします。特定のデータファイルのバックアップがない場合には、リカバリするための空の置換ファイルを作成できます。
users01.dbfをデフォルトの場所にリストアする場合は、次のコマンドを入力できます。
% cp /backup/users01_10_24_06.dbf $ORACLE_HOME/oradata/trgt/users01.dbf
次のガイドラインに従って、データファイルのバックアップをリストアする場所を決定します。
ALTER DATABASE RENAME FILEを使用して、これらのファイルの新しい場所を制御ファイルで指定します。必要に応じて、『Oracle Database管理者ガイド』を参照してください。
STARTUP MOUNT
usersのデータファイルのファイル名を変更するには、次のように入力します。
ALTER DATABASE RENAME FILE '?/oradata/trgt/users01.dbf' TO '/disk2/users01.dbf';
V$DATAFILEビューを問い合せて、すべてのデータファイルのデータファイル名およびステータスを取得します。たとえば、次のように入力します。
SELECT NAME,STATUS FROM V$DATAFILE;
/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
SETコマンドのLOGSOURCEパラメータを使用して、メディア・リカバリの前の場所を特定できます。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。
SET LOGSOURCE /tmp
あるいは、次の手順を実行して、RECOVERコマンドでFROMパラメータを使用します。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。
RECOVER AUTOMATIC FROM '/tmp' DATABASE
RECOVERコマンドを入力します。
RECOVER AUTOMATIC DATABASE # whole database RECOVER AUTOMATIC TABLESPACE users # specific tablespace RECOVER AUTOMATIC DATAFILE '?/oradata/trgt/users01.dbf'; # specific datafile
アーカイブREDOログの適用を自動化しない場合は、ログが提示されるたびに、そのログを適用するかどうかを選択する必要があります。リカバリを自動化した場合は、ログは自動的に適用されます。必要なすべてのアーカイブおよびオンラインREDOログが、リストアされたデータファイルに適用されるまで、リカバリは続行されます。メディア・リカバリが完了すると、次のように通知されます。
Media recovery complete.
完全メディア・リカバリにアーカイブREDOログ・ファイルが必要でない場合は、必要なすべてのオンラインREDOログ・ファイルが適用され、リカバリが終了します。
ALTER DATABASE OPEN;
% rm /tmp/*.arc
|
参照:
データ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。メディア・リカバリ時のログの適用の概要は、「ユーザー管理のメディア・リカバリの概要」を参照してください。 |
データベースをオープンしているときにメディア障害が発生した場合は、破損していないデータファイルはオンラインのまま使用できる場合があります。データベース・ライターがファイルに書き込めない場合は、破損したファイルは自動的にオフラインにされますが、破損したファイルを含む表領域はオフラインにされません。破損したファイルを読み取れない問合せはエラーを戻しますが、問合せが失敗したためにデータファイルがオフラインにされることはありません。たとえば、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表領域のデータファイルが破損した場合は、データベースは自動的に停止します。
オープン状態のデータベースでデータファイルをリストアする手順
usersおよびtoolsに含まれている場合は、次のSQL文を実行します。
ALTER TABLESPACE users OFFLINE TEMPORARY; ALTER TABLESPACE tools OFFLINE TEMPORARY;
TEMPORARYを指定すると、Oracle Databaseによって、表領域内のすべてのオンライン・データファイルに対してチェックポイントが実行されることに注意してください。この文の発行時にオフラインであるファイルでは、表領域をオンラインに戻す前に、メディア・リカバリが必要な場合があります。IMMEDIATEを指定すると、表領域をオンラインに戻す前に、表領域に対してメディア・リカバリを実行する必要があります。
DBVERIFYユーティリティを使用すると、オフライン・データファイルに対して整合性チェックを実行できます（「DBVERIFYユーティリティの実行」を参照）。
メディア障害の原因であるハードウェアの問題が一時的なもので、データが破損していない場合、メディア・リカバリは必要ありません。オフライン表領域をオンラインにし、通常の操作を再開することができます。問題を解決できない場合、またはDBVERIFYによって破損ブロックがレポートされた場合は、次の手順に進みます。
users01.dbfをリストアするには、LinuxまたはUNIXでcpコマンドを次のように実行します。
% cp /disk2/backup/users01.dbf $ORACLE_HOME/oradata/trgt/users01.dbf
ハードウェアの問題が解決され、データファイルを元の場所にリストアできる場合は、その場所にリストアします。それ以外の場合は、代替のストレージ・デバイスにデータファイルをリストアします。破損していないデータファイル、オンラインREDOログまたは制御ファイルはリストアしないでください。
usersのデータファイルのファイル名を変更するには、次のように入力します。
ALTER DATABASE RENAME FILE '?/oradata/trgt/users01.dbf' TO '/disk2/users01.dbf';
SETコマンドのLOGSOURCEパラメータを使用して、メディア・リカバリの前の場所を特定できます。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。
SET LOGSOURCE /tmp
あるいは、次の手順を実行して、RECOVERコマンドでFROMパラメータを使用します。たとえば、ログが/tmp内にステージングされている場合は、次のコマンドを入力できます。
RECOVER AUTOMATIC FROM '/tmp' TABLESPACE users, tools;
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;
通常、次のような場合にデータベースのPoint-in-Timeリカバリ（DBPITR）を実行します。
データベースをARCHIVELOGモードで実行しているときに、アーカイブREDOログ・ファイルの唯一のコピーが破損した場合には、破損したファイルが、データベースの現在の動作に影響を与えることはありません。表28-2に、REDOログが書き込まれた場合、およびデータファイルをバックアップした場合に応じて発生する可能性がある状況を示します。
DBPITRでの方法は、特定の時刻またはSCNを指定するか、あるいはCANCELと入力することによって終了する点以外は、「クローズしているデータベースのリカバリの実行」に示す方法と非常に類似しています。取消しベースのリカバリでは、アーカイブREDOログ・ファイルの推奨ファイル名がプロンプトに表示されます。ユーザーがファイル名のかわりにCANCELを指定するか、すべてのREDOがデータファイルに適用されると、リカバリは停止します。リカバリを終了するアーカイブ・ログをユーザーが制御する場合は、取消しベースのリカバリが最適です。
この項の手順では、次のことが想定されています。
この項の内容は、次のとおりです。
取消しベースのリカバリでは、ユーザーに対してアーカイブREDOログ・ファイルのファイル名を提示するプロンプトを表示して、リカバリが進行していきます。ユーザーがファイル名のかわりにCANCELを指定するか、すべてのREDOがデータファイルに適用されると、リカバリは停止します。
取消しベースのリカバリを実行する手順
RECOVER DATABASE UNTIL CANCEL
リストアしたデータファイルを再構築するために必要なREDOログ・ファイルが適用されます。データベースは、LOG_ARCHIVE_DEST_1から検索する名前を提示します。ユーザーは、そのログ・ファイルを適用するかどうかの決定を求められます。制御ファイルがバックアップの場合は、オンラインREDOログの変更を適用する場合、オンラインREDOログの名前を指定する必要があります。
CANCEL
リカバリが成功したかどうかが示されます。すべてのデータファイルが整合性のあるSCNまでリカバリされる前にリカバリを取り消し、その後データベースをオープンしようとすると、さらにリカバリが必要な場合は、ORA-1113エラーが表示されます。V$RECOVER_FILEを問い合せると、さらにリカバリが必要かどうか、または不完全リカバリの開始前にデータファイルのバックアップがリストアされていなかったかどうかを確認できます。
RESETLOGSオプションを指定してデータベースをオープンします。不完全リカバリまたはバックアップ制御ファイルを使用したリカバリの後は、ログをリセットする必要があります。たとえば、次のように入力します。
ALTER DATABASE OPEN RESETLOGS;
ログのリセットが不適切な状況でOPEN RESETLOGSを試行した場合、またはログをリセットする必要がある状況でログをリセットしなかった場合はエラーが戻され、データベースはオープンされません。問題を解決して再試行してください。
RESETLOGSオプションを使用してデータベースをオープンした後、アラート・ログを確認します。RESETLOGSオプションを指定してオープンした場合は、リカバリが完全か不完全かによって、戻されるメッセージが異なります。完全リカバリの場合は、アラート・ログに次のメッセージが表示されます。
RESETLOGS after complete recovery through change scn
不完全リカバリの場合は、アラート・ログに次のメッセージが表示されます。ここで、scnは、不完全リカバリの終了位置を表します。
RESETLOGS after incomplete recovery UNTIL CHANGE scn
また、アラート・ログも確認して、データ・ディクショナリと制御ファイルの間の矛盾がデータベースで検出されていないかを調べます。表28-3に、2つの例を示します。
この項では、リカバリの終了位置に対してSCNまたは時刻を指定する方法について説明します。データベースが季節的な時間変更（たとえば夏時間）の影響を受ける場合には、REDOログの中に1つの時間が2度出現し、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'
メディア障害によって、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';
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';
RECOVER DATABASE UNTIL CANCEL CANCEL
RESETLOGSモードでデータベースをオープンします。このコマンドによって、オンラインREDOログが消去され、ログ順序が1にリセットされます。
ALTER DATABASE OPEN RESETLOGS;
NOARCHIVELOGモードのデータベースのバックアップをリストアした後、ログをリセットすると、バックアップが作成されてから障害が発生するまでの間にデータベースに対して行われたすべての変更が廃棄されます。
この項では、ユーザー管理のメディア・リカバリ（Recovery Managerを使用しないで実行するメディア・リカバリ）のトラブルシューティングの方法について説明します。この項の内容は、次のとおりです。
表28-4「メディア・リカバリの問題」に、メディア・リカバリ中に発生する可能性がある問題を示します。
| 問題 | 説明 |
|---|---|
|
アーカイブ・ログの欠落または名前の誤り |
制御ファイルに記録されたアーカイブ・ログが見つからないため、リカバリは停止します。 |
|
データベースをオープンしようとすると、 |
このエラーの一般的な原因は次のとおりです。
|
|
REDOレコードの問題 |
2つの状況が考えられます。
|
|
アーカイブ・ログの破損 |
格納中またはストレージ・システム間でコピーされるときに、ログが破損した可能性があります。 |
|
互換性のないパラレルREDOフォーマットによるアーカイブ・ログ |
パラレルREDO機能を有効にした場合、REDOログが新規のフォーマットで生成されます。以前のリリースのOracleでは、パラレルREDOログを適用できません。ただし、Oracle9i リリース2（9.2）より前のリリースでは、パラレルREDOフォーマットを検出し、エラー・メッセージ「 |
|
データ・ブロックの破損 |
データファイルのバックアップに破損したデータ・ブロックが含まれているか、リカバリ中またはバックアップにコピーされるときにデータ・ブロックが破損しました。 |
|
その他の問題 |
リカバリ中には、メモリーの破損や、その他の一時的な問題が発生することがあります。 |
メディア・リカバリの問題は通常、リカバリ中に通知される外部エラーまたは内部エラーとして出現します。たとえば、外部エラーは、REDOブロックまたはデータ・ブロックでチェックサム検証チェックが失敗したことを示します。内部エラーは、データベースの不具合か、基礎となるオペレーティング・システムおよびハードウェアに起因するエラーによって発生する可能性があります。
メディア・リカバリで、データベース・バックアップのリカバリ中に問題が発生した場合は、スタック・リカバリの問題またはREDO適用中の問題であるかどうかに関係なく、データベースは常に停止し、リカバリ中のデータファイルを一貫性のある状態、つまり、障害前の一貫性のあるSCNのままにします。次のいずれかを実行できます。
RESETLOGSオプションを指定してデータベースをオープンします（RESETLOGSのオープンの要件が満たされている場合）。スタンバイ・データベースはメディア・リカバリの形態で更新されるため、RESETLOGSの制限は、フィジカル・スタンバイ・データベースをオープンする場合にも適用されます。
一般に、データベースを読取り専用でオープンしたり、RESETLOGSオプションを指定してオープンする場合には、すべてのオンライン・データファイルを同じSCNまでリカバリする必要があります。この要件が満たされない場合は、ユーザーがオープンを試行すると、ORA-1113またはその他のエラーが通知されることがあります。ORA-1113の一般的な原因については、表28-4「メディア・リカバリの問題」を参照してください。
一般に、メディア・リカバリの問題には、次のように対処します。
RESETLOGSオプションを指定してデータベースをオープンします。シリアル・メディア・リカバリを実行した場合は、データベースには、破損が発生したSCNの前までのすべての変更が含まれています。このSCN以降の変更は、データベースのリカバリされた部分に含まれていません。オンライン・バックアップをリストアした場合は、RESETLOGSによるオープンは、REDOストリーム中のすべてのALTER ... END BACKUP操作までリカバリが完了している場合にのみ成功します。
メディア・リカバリで問題が発生した場合は、リカバリが停止した後、できるだけ多くの情報を入手してください。解決する問題を誤って時間を消費し、さらに問題を悪化させることを防ぐためです。
最初に、問題の原因が、設定の誤り、REDOログの破損、データ・ブロックの破損、メモリーの破損、またはその他の原因のどれかを確認します。データ・ブロックのチェックサムにエラーがある場合には、データ・ブロックが破損しています。REDOログ・ブロックのチェックサムにエラーがある場合には、REDOログが破損しています。
リカバリの問題の原因は、特定するのが困難な場合があります。問題の原因が完全にはわからない場合でも、この章に示す方法を使用すると、データベースのリカバリを迅速に実行できます。
メディア・リカバリの問題を調査する手順
alert.logを調べて、エラー・メッセージに問題の性質についての一般的な情報が記載されているかを確認します。たとえば、alert_SID.logにチェックサムのエラーが示されているかどうかを確認します。また、メディア・リカバリを続行するためにデータ・ブロックの破損を許可する必要があることが示されているかどうかを確認します。
メディア・リカバリの問題のタイプに応じて、いくつかの解決方法があります。表28-5に示す方法の1つ、あるいはその組合せを使用できます。これらの方法は比較的安全なものです。ほとんどの場合、データベースに対する害はありません。
| 発生した可能性がある問題 | 説明 |
|---|---|
|
アーカイブREDOログの欠落または名前の誤り |
ファイル名が正しく入力されているかを確認します。正しく入力されていた場合には、オペレーティング・システムからログが欠落しているかを確認します。欠落している場合に、バックアップがあれば、バックアップをリストアし、ログを適用します。バックアップがない場合には、可能であれば、欠落したログの時点まで不完全リカバリを実行します。 |
|
|
表28-4「メディア・リカバリの問題」で、このエラーの原因を検討します。リカバリが必要なすべての読取り/書込みデータファイルがオンラインにされていることを確認します。 リカバリにバックアップ制御ファイルを使用した場合には、制御ファイルとデータファイルのSCNに一貫性がないかぎり、データベースをオープンできません。必要なREDOがない場合には、制御ファイルを再作成する必要があります。 |
|
アーカイブ・ログの破損 |
ログREDOブロックのチェックサム検証が失敗したときには、ログが破損しています。リカバリ・セッション中、またはデータベースがREDOを生成したときに
|
|
互換性のないパラレルREDOフォーマットによるアーカイブ・ログ |
Oracle9i リリース2（9.2）より前のOracleリリースを実行している場合、パラレルREDOフォーマットで作成されたREDOログを適用するには、次の手順に従う必要があります。 |
|
メモリーの破損または一時的な問題 |
データベースを停止してリカバリを再開すると、問題を解決できる場合があります。2回目の試行も失敗した場合は、データベースを一貫性のある状態のままにしておく必要があります。 |
|
データ・ブロックの破損 |
ユーザー管理の方法を使用して、データファイルのリストアおよびリカバリを再度実行するか、またはRecovery Managerの
データ・ブロックのチェックサム検証が失敗した場合は、データ・ブロックが破損しています。 |
表28-5に示す方法で問題を解決できない場合は、データを消失せずに、簡単に問題を解決できる方法がない可能性があります。次のようなオプションがあります。
RESETLOGSオプションを指定してデータベースをオープンします（データベース全体のリカバリのため）。この解決方法では、REDOの問題が発生した時点以降のすべての変更が廃棄されますが、データベースの論理的一貫性は保証されます。
このオプションは、アラート・ログに、データ・ブロックを破損させることを許可すればリカバリを続行できることが示されている場合にのみ成功します。これはほとんどのリカバリの問題に当てはまります。データベースを迅速に起動し、すべての変更をリカバリする必要がある場合は、このオプションが最適です。このオプションを検討する場合は、「リカバリでブロックの破損を許可するかどうかの決定: フェーズ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文を使用します。
これらの調査を実行した後、表28-6のガイドラインに従って、リカバリでブロックの破損を許可するかどうかを決定します。
リカバリの続行のために、ブロックの破損を許可することを決定した場合には、ALLOW n CORRUPTION句を指定してRECOVERコマンドを実行します。このnは、破損させることを許可するブロックの数です。
RECOVERコマンドを実行します。たとえば、次のように入力します。
RECOVER DATABASE ALLOW 5 CORRUPTION
スタック・リカバリなどの問題が発生した場合、判断が困難な場合があります。ブロックが比較的重要でなく、問題が分離されている場合は、通常、ブロックを破損させます。ただし、問題が分離されていない場合は、RESETLOGSオプションを指定してデータベースをオープンする方がよい場合があります。
このため、Oracle Databaseでは、試行リカバリがサポートされています。試行リカバリは、通常のメディア・リカバリと同じ方法で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句を指定すると、試行リカバリの実行時にメモリー内で破損させることができるデータ・ブロックの数を制限できます。
試行リカバリのコマンドは、通常リカバリのコマンドを使用できるすべての場合に使用できます。ただし、試行リカバリを実行する必要があるのは、リカバリで問題が発生する場合のみです。
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|