10gリリース2（10.2）
B19193-02
 目次 |
 索引 |
| Oracle Database バックアップおよびリカバリ基礎 10gリリース2（10.2） B19193-02 |
|
この章では、データベースをバックアップからリカバリするためにRecovery Managerで使用可能なツールについて説明します。この章では、次の項目について説明します。
この章では、データベースが正常に稼働するために必要な1つ以上のデータベース・ファイルが消失した場合に、Recovery ManagerおよびRecovery Managerで作成したバックアップを使用して、データベースを正常な稼働状態に戻す方法について説明します。Recovery Managerでバックアップし、リカバリできるデータベース・ファイルには、制御ファイル、サーバー・パラメータ・ファイル、データ・ファイルおよびアーカイブREDOログ・ファイルがあります。
この章の内容は次のとおりです。
データベースのリカバリで使用するRecovery Managerコマンドで重要なものは次の2つです。
RESTORE。Recovery Managerリポジトリの内容に基づいて、Recovery Managerバックアップからファイルを取得します。
RECOVER。使用可能なデータ・ファイルおよびREDOログを使用して、完全またはPoint-in-Timeメディア・リカバリを実行します。
通常、データのリカバリ操作の実行に適するようにデータベースの状態を設定し、ディスクおよびメディア・マネージャとの通信に必要なチャネルの割当てまたは構成を行った後、一連のRESTOREおよびRECOVERコマンドを実行します。Recovery Managerは、すべての必要なファイルをバックアップから取得し、リストアしたすべてのデータ・ファイルに対してメディア・リカバリを実行してデータベースを正常な状態に戻します。
この章では、リストアおよびリカバリの最も一般的な使用例で共通して使用される方法について説明します。リストアおよびリカバリを実行する場合は、この章で説明されていない複雑な状況の場合でも、この章で説明する方法について理解しておく必要があります。ただし、この章での説明は次の内容に制限されています。
参照:
Enterprise Managerを使用すると、Recovery Managerで提供されるデータベースのリストアおよびリカバリ機能の大部分を、一連のリカバリ・ウィザードによって実行できます。このウィザードによって、DBAは、データベースの分析、使用可能なバックアップおよびデータ・リカバリの目的に基づいて様々なリカバリ作業を実行できます。
Enterprise Managerを介してRecovery Managerを使用すると、この章で説明する、より簡単なリストアおよびリカバリの使用例を実行できます。また、メディア障害およびユーザー・エラーの両方を効率的に修復できる、より高度なリストアおよびリカバリ方法（Point-in-Timeリカバリ、Oracleデータベースのフラッシュバック機能の使用など）を実行できます。
基礎となる機能は同じですが、コマンドライン・クライアントは、多くの一般的な状況でより柔軟に使用でき、Recovery Managerのリストアおよびリカバリ機能に対して使用するEnterprise Managerインタフェースは、Recovery Managerコマンドライン・クライアントを直接使用するより簡単に使用できます。
Enterprise Managerのリストアおよびリカバリ機能の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
「データベースのリストアおよびリカバリの準備および計画」および「Recovery ManagerのRESTORE: 消失したデータベース・ファイルのバックアップからのリストア」で説明する手順を使用して、ほぼすべてのデータ消失のリカバリ方法を計画できます。ただし、ここで詳細に説明するのは、データベースのリストアおよびリカバリの最も一般的な使用例の一部です。
ここで説明する手順によって、データベース全体または個々の表領域が元の場所にリストアされます。
この項のすべての手順を実行するには、次の要件が満たされている必要があります。
自動チャネルが構成されている場合は、Recovery Managerによって、使用可能なデバイス・タイプ用に構成されているすべてのチャネルが並列化の設定に応じて割り当てられます。自動チャネルが構成されていない場合は、RESTOREおよびRECOVERコマンドをRUNブロックで囲み、適切なDISKまたはsbtチャネルを手動で割り当てて開始する必要があります。この手動操作を行わない場合は、RESTOREコマンドを実行しても、デバイスからバックアップを取得することはできません。
ここでは、現行の制御ファイルおよびSPFILEは存在しているが、すべてのデータ・ファイルが破損または消失している場合の使用例を示します。データベース全体をリストアおよびリカバリする必要があります。
この例で使用するデータベースには、1つの読取り専用表領域historyが含まれています。この表領域は、バックアップからリストアする必要がありますが、メディア・リカバリは必要ありません。
現行の制御ファイルが使用可能な場合にデータベースをリストアおよびリカバリする方法
RMAN> STARTUP MOUNT
SHOW ALLコマンドを使用して、バックアップ・デバイスにアクセスするために構成されるチャネルを表示します。自動チャネルが構成されていない場合は、手動で1つ以上のチャネルを割り当てます。
RESTORE DATABASEコマンドを使用してデータベースをリストアし、RECOVER DATABASEコマンドを使用してそのデータベースをリカバリします。
次の例では、自動チャネルを使用して、データベースのリストアおよびリカバリを実行します。
RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE DELETE ARCHIVELOG MAXSIZE 25M;
ここで使用しているRECOVER DATABASEコマンドには、次の2つの有効なオプションがあります。
DELETE ARCHIVELOGを指定すると、Recovery Managerによって、リストアしたログ・ファイルがデータ・ファイルに適用された後に削除され、ディスク領域を節約できます。
MAXSIZE 25Mを指定すると、常に、リストアしたログに使用される領域が25MBに制限されます。これによって、リストアしたログに使用されるディスク領域の量を制御できます。単一のアーカイブREDOログが指定したMAXSIZEの値を超えると、エラーが発生します。MAXSIZEの値を増やして、コマンドを再実行する必要があります。
読取り専用表領域では、リストアおよびリカバリ処理で特別な処理が必要となる場合があります。デフォルトのリストア処理では、読取り専用表領域はスキップされます。読取り専用表領域が、バックアップからリストアされた後に読取り専用となったSCNに存在する場合、データベースの残りがリカバリされる際、この表領域にREDOは適用されません。CHECK READONLYオプションを指定してRESTOREコマンドを実行すると、読取り専用表領域に属するデータ・ファイルで欠落しているものをRecovery Managerでリストアできます。
RMAN> RESTORE DATABASE CHECK READONLY; RMAN> RECOVER DATABASE DELETE ARCHIVELOG;
Recovery Managerによるリカバリがエラーを戻さずに終了した場合は、データベースをオープンできます。
RMAN> ALTER DATABASE OPEN;
データベース全体のリストアおよびリカバリが実行された後、データベースをオープンすると、Recovery Managerリポジトリの制御ファイルのバージョンに記録され、欠落している一時表領域は、以前の作成時のサイズ（AUTOEXTENDおよびMAXSIZE属性）で再作成されます。
一時ファイルが最初にOracle管理ファイルとして作成された場合、現行のDB_CREATE_FILE_DESTに再作成されます。その他の場合は、その以前の場所に再作成されます。
Recovery ManagerがI/Oエラーまたは他の原因でファイルを再作成できない場合、エラーがアラート・ログにレポートされ、データベースのオープン操作が続行されます。
ここでは、データベースがオープンしていて、いくつかのデータ・ファイル（すべてではない）が破損している場合の使用例を示します。破損している表領域のリストアおよびリカバリは、残りのデータベースを使用可能な状態にしておくために、データベースをオープンしたまま行います。
「リストアまたはリカバリするデータベース・ファイルの決定」で説明した手順でリカバリに必要なデータ・ファイルを特定するとします。破損しているファイルが表領域usersからのものであることが示されます。
次の例では、構成済のチャネルを使用し、また、表領域、必要とされる増分バックアップおよびログをディスクまたはテープからリストアする際に使用するバックアップをRecovery Managerで選択して、表領域をリストアおよびリカバリします。
ALTER TABLESPACE ... OFFLINE IMMEDIATEを実行してオフラインにします。
RMAN> SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE';
RESTOREコマンドで表領域またはデータベースをリストアし、RECOVERコマンドでリカバリします。（構成済のチャネルを使用したり、必要に応じて、RUNブロックを使用してチャネルを割り当て、RESTOREおよびRECOVERコマンドのパフォーマンスを向上させます。）
RMAN> RESTORE TABLESPACE users; RMAN> RECOVER TABLESPACE users;
RMAN> SQL 'ALTER TABLESPACE users ONLINE';
この時点で、このプロセスは完了します。
Recovery Managerを使用すると、データベースのリストアおよびリカバリ作業が簡単になりますが、消失しているデータベース・ファイルおよびリカバリの目的に基づいて、データベースのリストアおよびリカバリ操作を計画する必要があります。
Recovery Managerを使用して、リストア処理に関する重要な決定の大部分を行うことができますが、その決定を確認し、変更する必要がある場合もあります。たとえば、テープがサイト外に格納されているか、またはデバイスがアクセス不可能なため、指定したバックアップが使用できない場合は、リストア処理中にそのバックアップを使用しないように指定できます。
Recovery Managerでは、リストアで使用するバックアップを確認できるツール、およびバックアップの内容を検証してそれらが将来のリストア操作で使用可能であることを確認できるツールが提供されています。
Recovery Managerを使用したリストアおよびリカバリの基本的な実行手順は次のとおりです。
RESTOREコマンドを使用して、消失したデータベース・ファイルをバックアップからリストアします。ファイルは、元の場所にリストアできます。また、ディスクで障害が発生した場合などは他の場所にリストアする必要があります。制御ファイルの場所を変更した場合はSPFILEを、データ・ファイルまたはREDOログの場所を変更した場合は制御ファイルを更新する必要もあります。
RECOVERコマンドを使用して、リストアしたデータ・ファイルにリカバリを実行します。
ここでは、様々な使用例を広範囲にわたって説明しています。状況によっては、説明した手順の一部が適用されない場合があります。（たとえば、バックアップからリストアしたファイルがSPFILEのみの場合は、メディア・リカバリを実行する必要はありません。）ユーザーは、状況に応じて最終的なリカバリ計画を検討する必要があります。
リストアまたはリカバリする必要があるファイルを決定する方法は、消失したファイルのタイプによって異なります。この項では次の項目を取り上げます。
一般的に、データベースの制御ファイルをリストアする必要があるタイミングは明確です。制御ファイルのコピーのいずれかにアクセスできなくなると、すぐにデータベースが停止します。初期化パラメータCONTROL_FILESに指定されているそれぞれの場所に有効な制御ファイルがないままデータベースを起動すると、エラーが報告されます。
制御ファイルの一部またはすべてのコピーが消失しても、バックアップから制御ファイルをリカバリする必要はありません。制御ファイルの1つのコピーが消失した場合、データベースは自動的に停止します。破損または欠落している制御ファイルに破損していない制御ファイルのコピーを上書きコピーするか、あるいは破損または欠落している制御ファイルが参照されないようにパラメータ・ファイルを更新できます。破損せずに存在している制御ファイルのコピーのみがCONTROL_FILESパラメータによって参照された後、データベースを再起動できます。
制御ファイルをバックアップからリストアした場合は、データベース全体のメディア・リカバリを実行した後、データ・ファイルをリストアする必要がない場合でもOPEN RESETLOGSを実行します。
リカバリを実行するタイミングと方法は、データベースの状態とデータ・ファイルの場所によって異なります。メディア・リカバリが必要なファイル（存在する場合）を判別するには、次の手順を実行します。
trgtに接続します。
% sqlplus 'SYS/oracle@trgt AS SYSDBA'
SELECT STATUS FROM V$INSTANCE;
状態がOPENの場合、データベースはオープン状態です。ただし、一部のデータ・ファイルにはメディア・リカバリが必要です。
V$DATAFILE_HEADERビューを問い合せて、データ・ファイルの状態を確認します。次のSQL文を実行して、データ・ファイルのヘッダーを確認します。
COL FILE# FORMAT 999 COL STATUS FORMAT A7 COL ERROR FORMAT A10 COL TABLESPACE_NAME FORMAT A10 COL NAME FORMAT A30 SELECT FILE#, STATUS, ERROR, RECOVER, TABLESPACE_NAME, NAME FROM V$DATAFILE_HEADER WHERE RECOVER = 'YES' OR (RECOVER IS NULL AND ERROR IS NOT NULL);
戻される各行には、メディア・リカバリが必要なデータ・ファイルか、またはリストアの必要のあるエラーが発生したデータ・ファイルが示されます。RECOVERおよびERROR列を確認します。RECOVERには、ファイルにメディア・リカバリが必要かどうかが示され、ERRORには、データ・ファイルのヘッダーの読取り時および検証時にエラーが発生したかどうかが示されます。
ERRORがNULLでない場合は、データ・ファイルのヘッダーの読取りおよび検証は実行できません。エラーの原因となるハードウェアまたはオペレーティング・システムの一時的な問題を確認します。問題がない場合は、ファイルをリストアしてコピーに切り替える必要があります。
ERROR列がNULLで、RECOVER列がYESの場合、ファイルにはメディア・リカバリが必要です（バックアップからリストアする必要がある場合もあります）。
また、V$RECOVER_FILEを問い合せて、リカバリが必要なデータ・ファイルをそれらの状態とエラー情報とともにデータ・ファイル番号ごとに表示することもできます。
SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME FROM V$RECOVER_FILE;
データ・ファイルおよび表領域の名前を検出するために、データ・ファイル番号、V$DATAFILEおよびV$TABLESPACEビューを使用して、有効な結合を実行することもできます。次に例を示します。
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列で、リカバリが必要な各ファイルに関する問題を識別します。
クラッシュ・リカバリまたはインスタンス・リカバリの際、読取り専用表領域ではリカバリを行う必要はありません。リカバリでは、起動時に読取り専用の各オンライン・データ・ファイルにメディア・リカバリの必要がないことが検証されます。これは、ファイルが、読取り専用に設定される前に作成されたバックアップからリストアされていないかどうかをチェックして行われます。
自動バックアップからSPFILEまたは制御ファイルをリカバリする必要がある場合（すべてのデータベース・ファイルが消失して障害時リカバリを実行する場合など）は、DBIDを使用する必要があります。「ARCHIVELOGおよびNOARCHIVELOGモードの決定」で説明したように、DBIDは、データベースの基本情報とともに記録する必要があります。
データベースのDBIDのレコードがない場合は、次の2つの場面でデータベースをオープンせずにDBIDを確認できます。
% rman TARGET / Recovery Manager: Release 10.2.0.1.0 - Production on Sun Jun 12 02:41:03 2005 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: RDBMS (DBID=774627068) RMAN>
RESTOREコマンドはPREVIEWオプションをサポートします。PREVIEWオプションを使用すると、Recovery Managerリポジトリの情報に基づいて、特定のリストア操作を実行するのに必要なバックアップ（ディスク、テープなどのシーケンシャル・メディア上にある、バックアップ・セットまたはイメージ・コピー）を特定できます。 リストアおよびリカバリ操作を計画する場合は、RESTORE...PREVIEWを使用して、すべての必要なバックアップが使用可能であることを確認し、Recovery Managerで特定のバックアップを使用する状況または避ける状況を識別します。
たとえば、RESTORE... PREVIEWの出力には、RESTORE操作時に、一時的に使用できないテープからのバックアップがリストア処理中にRecovery Managerによって要求されることが示されます。 その後、CHANGE... UNAVAILABLEコマンド（「バックアップ状態のマーク付け」を参照）を実行して、バックアップの状態をUNAVAILABLEに設定できます。 次に、RESTORE... PREVIEWを再度実行すると、使用不可能なバックアップを使用しないでリストア操作を実行するために、Recovery Managerで使用するバックアップが表示されます。
バックアップがAVAILABLEと表示されても、実際は他の場所に格納されていている場合があります。つまり、他の場所に格納されているため、リストアに使用するには、取得する必要がある場合があります。Recovery Managerがこのようなバックアップをリストア操作で使用するために選択した場合、この操作は失敗し、エラーが表示されます。 RESTORE... PREVIEWを使用すると、他の場所に格納されているバックアップを識別することができ、RESTORE...PREVIEW RECALLを使用すると、RESTORE操作で必要ではあるが他の場所に格納されているバックアップを、リモートの記憶域から再呼出しするように要求できます。
RESTORE ...PREVIEWは、すべてのRESTORE処理に適用できます。RESTOREを使用すると、要求されたRESTORE処理で使用される各バックアップの詳細なレポート、およびRESTORE処理の完了後のリカバリに必要なターゲットSCNを作成できます。次に、PREVIEWオプションを使用したRESTOREコマンドの例を示します。
RESTORE DATABASE PREVIEW; RESTORE TABLESPACE users PREVIEW; RESTORE DATAFILE 3 PREVIEW; RESTORE ARCHIVELOG FROM LOGSEQ 200 PREVIEW; RESTORE ARCHIVELOG FROM TIME 'SYSDATE-7' PREVIEW; RESTORE ARCHIVELOG FROM SCN 234546 PREVIEW;
RESTORE...PREVIEWの出力方式は、LISTコマンドによる出力と同じです。 RESTORE...PREVIEWの出力の解釈は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
RESTORE... PREVIEWによって生成される詳細なレポートが必要以上の情報を表示する場合は、RESTORE... PREVIEW SUMMARYオプションを使用して、リストア処理で使用されるファイルおよび影響を受けるファイルに関する多くの詳細を非表示にできます。次に、PREVIEW SUMMARYオプションを使用したRESTOREの例を示します。
RESTORE DATABASE PREVIEW SUMMARY; RESTORE TABLESPACE users PREVIEW SUMMARY; RESTORE DATAFILE 3 PREVIEW SUMMARY; RESTORE ARCHIVELOG FROM SCN 234546 PREVIEW SUMMARY;
RESTORE... PREVIEW SUMMARYのレポート形式は、LIST SUMMARYコマンドによる出力と同じです。 RESTORE...PREVIEW SUMMARYの出力の解釈は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』 を参照してください。
必要なバックアップが他の場所に格納されているために、リストアが失敗するような場合、RESTORE... PREVIEW RECALLは、いずれのRESTORE操作でも使用できます。
RESTORE ... PREVIEWによって、必要なバックアップが他の場所に格納されていることが示されている場合の出力を次に示します。
RMAN> restore archivelog all preview; Starting restore at 10-JUN-05 using channel ORA_DISK_1 using channel ORA_SBT_TAPE_1 List of Backup Sets =================== BS Key Size Device Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------------- 31 12.75M SBT_TAPE 00:00:02 10-JUN-05 BP Key: 33 Status: AVAILABLE Compressed: NO Tag: TAG20050610T152755 Handle: 15gmknbs Media: /v1,15gmknbs List of Archived Logs in backup set 31 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 1 221154 06-JUN-05 222548 06-JUN-05 1 2 222548 06-JUN-05 222554 06-JUN-05 1 3 222554 06-JUN-05 222591 06-JUN-05 1 4 222591 06-JUN-05 246629 07-JUN-05 1 5 246629 07-JUN-05 262451 10-JUN-05 BS Key Size Device Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------------- 32 256.00K SBT_TAPE 00:00:01 10-JUN-05 BP Key: 34 Status: AVAILABLE Compressed: NO Tag: TAG20050610T153105 Handle: 17gmknhp_1_1 Media: /v1,17gmknhp_1_1 List of Archived Logs in backup set 32 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 6 262451 10-JUN-05 262547 10-JUN-05 1 7 262547 10-JUN-05 262565 10-JUN-05 List of remote backup files ============================ Handle: 15gmknbs Media: /v1,15gmknbs
この出力の最後の「List of remote backup files」には、他の場所に格納されているバックアップが示されます。このような場合は、RESTOREARCHIVELOG ALL PREVIEW RECALLを使用すると、リモートのバックアップに対する再呼出しが行われ、次のような出力が生成されます。
RMAN> restore archivelog all preview recall; Starting restore at 10-JUN-05 using channel ORA_DISK_1 using channel ORA_SBT_TAPE_1 List of Backup Sets =================== BS Key Size Device Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------------- 31 12.75M SBT_TAPE 00:00:02 10-JUN-05 BP Key: 33 Status: AVAILABLE Compressed: NO Tag: TAG20050610T152755 Handle: 15gmknbs Media: /v1,15gmknbs List of Archived Logs in backup set 31 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 1 221154 06-JUN-05 222548 06-JUN-05 1 2 222548 06-JUN-05 222554 06-JUN-05 1 3 222554 06-JUN-05 222591 06-JUN-05 1 4 222591 06-JUN-05 246629 07-JUN-05 1 5 246629 07-JUN-05 262451 10-JUN-05 BS Key Size Device Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------------- 32 256.00K SBT_TAPE 00:00:01 10-JUN-05 BP Key: 34 Status: AVAILABLE Compressed: NO Tag: TAG20050610T153105 Handle: 17gmknhp_1_1 Media: /v1,17gmknhp_1_1 List of Archived Logs in backup set 32 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 6 262451 10-JUN-05 262547 10-JUN-05 1 7 262547 10-JUN-05 262565 10-JUN-05 Initiated recall for the following list of remote backup files ========================================================== Handle: 15gmknbs Media: /v1,15gmknbs Finished restore at 10-JUN-05
RESTORE... PREVIEWコマンドは、リストアに必要なバックアップがリモートとして報告されなくなるまで繰り返すことができます。
RECALLは、いずれのRESTORE... PREVIEW コマンドにも追加できます。次に例を示します。
RESTORE TABLESPACE users PREVIEW RECALL; RESTORE DATAFILE 3 PREVIEW RECALL;
RESTORE ...VALIDATEおよびVALIDATE BACKUPSETコマンドを使用すると、バックアップからリストアできるかどうかをテストできます。目的のRESTORE操作に使用可能なバックアップの可用性、またはRESTORE操作に使用する特定のバックアップの内容をテストできます。バックアップの内容の実際の読取りと、破損の検証が行われ、リストアするオブジェクトがそのバックアップからリストアできることが確認されます。次のオプションがあります。
RESTORE ... VALIDATEは、Recovery Managerがバックアップから特定のオブジェクトをリストアできるかをテストします。Recovery Managerによって、使用するバックアップが選択されます。
VALIDATE BACKUPSETは、指定するバックアップ・セットの妥当性をテストします。VALIDATE句を指定して任意の有効なRESTOREコマンドを入力すると、そのRESTORE操作に使用可能なバックアップが使用可能かどうかをテストできます。 データベースをマウントまたはオープンした状態でも、RESTORE... VALIDATEを実行してバックアップを検査できます。
次の例では、バックアップ制御ファイル、SYSTEM表領域およびすべてのアーカイブ・ログのリストアを検査します。
RESTORE CONTROLFILE VALIDATE; RESTORE TABLESPACE SYSTEM VALIDATE; RESTORE ARCHIVELOG ALL VALIDATE; RESTORE DATAFILE 4,5,6 VALIDATE;
エラー・メッセージおよび次のメッセージが表示された場合は、Recovery Managerを使用して、1つ以上の指定したファイルを、使用可能なバックアップからリストアすることはできません。
RMAN-06026: some targets not found - aborting restore
次のようなエラー・メッセージのスタックおよび出力が表示された場合は、指定したバックアップの読取り中にRecovery Managerで問題が発生しています。
RMAN-03009: failure of restore command on c1 channel at 12-DEC-01 23:22:30 ORA-19505: failed to identify file "oracle/dbs/1fafv9gl_1_1" ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3
エラー・スタックが表示されない場合は、使用可能なバックアップからの指定したオブジェクトのリストアがRecovery Managerで正常に検査され、Recovery Managerは、実際のリストアおよびリカバリ操作の実行中にこれらのオブジェクトを正常にリストアできます。
BACKUP VALIDATEコマンドには、検査するバックアップ・セットの主キーが必要です。
検査するバックアップ・セットを指定する方法
LISTコマンドを実行し、主キーに注意しながら、確認する必要のあるバックアップ・セットを検索します。次に例を示します。
LIST BACKUP;
バックアップ・セットを主キーごとに参照して、バックアップ・セットのリストアを検査します。次の例では、バックアップ・セット56および57を検査します。
VALIDATE BACKUPSET 56,57;
出力に「validation complete」メッセージが含まれている場合、Recovery Managerは指定したバックアップ・セットのリストアを正常に検査しました。次に例を示します。
using channel ORA_DISK_1 channel ORA_DISK_1: starting validation of archive log backupset channel ORA_DISK_1: restored backup piece 1 piece handle=/oracle/dbs/0mdg9v8l_1_1 tag=TAG20020208T155604 params=NULL channel ORA_DISK_1: validation complete
この項では、Recovery Managerによってバックアップされた様々なタイプのデータベース・ファイルをリストアする方法について説明します。データベースの消失した部分をリストアする計画全体を作成した後に、その計画の個々の作業を実行する方法については、この項を参照してください。
この項では次の項目を取り上げます。
制御ファイルのすべてのコピーが消失または破損した場合は、制御ファイルをバックアップからリストアする必要があります。制御ファイルをリストアするには、RESTORE CONTROLFILEコマンドを使用します。
|
注意:
データベースの制御ファイルをバックアップからリストアした後、データベースの完全メディア・リカバリ（「リストア済データベース、表領域またはデータ・ファイルのメディア・リカバリの実行」を参照）を実行し、RESETLOGSオプションを指定してデータベースをオープンします。ただし、「新しい場所への制御ファイルのリストア」で説明する場合は例外です。この場合は、 |
Recovery Managerでは、RESTORE CONTROLFILE... TO destinationオプションを指定して、デフォルトの場所（次の項で説明する規則に従って決定）または1つ以上の任意の場所に制御ファイルをリストアできます。
制御ファイルをリストアする場合、デフォルトのリストア先は、CONTROL_FILES初期化パラメータに定義されているすべての場所です。CONTROL_FILES初期化パラメータを設定しないと、データベースは、CONTROL_FILESパラメータが設定されていない場合に制御ファイルを作成するときと同じ規則を使用して、リストアされた制御ファイルの格納先を決定します。これらの規則については、『Oracle Database SQLリファレンス』のCREATE CONTROLFILE文の説明を参照してください。
リカバリ・カタログを使用していない場合、制御ファイルは、自動バックアップからリストアする必要があります。制御ファイルを自動バックアップからリストアする場合は、データベースをNOMOUNT状態にする必要があります。データベースのDBIDを設定した後で、RESTORE CONTROLFILE FROM AUTOBACKUPコマンドを実行します。
RMAN> SET DBID 320066378; RMAN> RUN { SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'autobackup_format'; RESTORE CONTROLFILE FROM AUTOBACKUP; }
Recovery Managerでは、制御ファイルの自動バックアップを検出するために自動バックアップ書式およびDBIDが使用されます。自動バックアップが検出されると、Recovery Managerによって、制御ファイルがそのバックアップからCONTROL_FILES初期化パラメータに記録されているすべての制御ファイルの場所にリストアされます。
autobackup_formatの適切な値を判断する方法については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のCONFIGURE用のエントリ内のCONFIGURE CONTROLFILE AUTOBACKUP FORMATについての説明を参照してください。
DBIDを決定する方法については、「DBIDの決定」を参照してください。
制御ファイルのリストアに使用するコマンドは、フラッシュ・リカバリ領域を使用しているかどうかに関係なく同じです。ただし、フラッシュ・リカバリ領域を使用している場合は、Recovery Managerによって、バックアップからリストアされた制御ファイルが更新されます。これは、制御ファイルに記録されているすべてのディスクベースのバックアップおよびイメージ・コピーが暗黙的にクロスチェックされ、リストアされた制御ファイルに記録されていないフラッシュ・リカバリ領域内のすべてのバックアップがカタログに追加されることで行われます。その結果、リストアされた制御ファイルには、フラッシュ・リカバリ領域内のすべてのバックアップの完全かつ正確なレコードと、バックアップ時に制御ファイルに認知されていた他のバックアップが含まれます。これによって、リストアされた制御ファイルを有効に使用して、データベースの残りをリストアできます。
テープ・バックアップは、制御ファイルをリストアした後、自動的にクロスチェックされません。テープ・バックアップを使用している場合は、制御ファイルをリストアしてデータベースをマウントした後、テープ上でバックアップのクロスチェックを行う必要があります。次に例を示します。
RMAN> CROSSCHECK BACKUP DEVICE TYPE SBT;
消失した制御ファイルを自動バックアップからリストアする場合は、Recovery Managerリポジトリを格納するために制御ファイルのみを使用するよりも、リカバリ・カタログを使用した方が簡単になります。リカバリ・カタログには、制御ファイルのバックアップなど、バックアップの完全なレコードが含まれています。したがって、DBIDや制御ファイルの自動バックアップ書式を指定する必要はありません。
制御ファイルをリストアするには、Recovery Managerをターゲット・データベースとリカバリ・カタログに接続して、データベースをNOMOUNT状態にします。その後で、パラメータを指定しないでRESTORE CONTROLFILEコマンドを発行します。次に例を示します。
% rman TARGET rman/rman CATALOG catdb/catdb RMAN> RESTORE CONTROLFILE;
リストアされた制御ファイルは、CONTROL_FILES初期化パラメータに定義されているすべての場所に書き込まれます。
様々な状況でのRESTORE CONTROLFILEの使用制限の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のRESTORE CONTROLFILEの説明を参照してください。
次の書式のコマンドを使用して、制御ファイルの既知のコピーから制御ファイルをリストアできます。
RMAN> RESTORE CONTROLFILE from 'filename';
filenameに指定された場所で検出された制御ファイルのコピーは、CONTROL_FILES初期化パラメータに定義されているすべての場所に書き込まれます。
1つ以上の新しい場所に制御ファイルをリストアするには、CONTROL_FILES初期化パラメータを変更した後、引数を指定せずにRESTORE CONTROLFILEを実行して制御ファイルをデフォルトの場所にリストアする方法があります。たとえば、CONTROL_FILESに定義されている場所の一部がディスク障害によって使用できなくなった後に制御ファイルをリストアする場合は、CONTROL_FILESで障害ディスクへの参照を別のディスクへのパス名に置き換えた後、引数を指定せずにRESTORE CONTROLFILEを実行します。
RESTORE CONTROLFILE TO 'filename' [FROM AUTOBACKUP]という書式を使用して、CONTROL_FILESに定義されている以外の任意の場所に制御ファイルをリストアすることもできます。
RESTORE CONTROLFILE TO '/tmp/my_controlfile';
この操作は、現在使用中の制御ファイルを上書きしないため、NOMOUNT、MOUNTまたはOPEN状態のデータベースで実行できます。'filename'という名前のすべての既存ファイルが上書きされます。制御ファイルを新しい場所にリストアした後、CONTROL_FILES初期化パラメータを更新して新しい場所を追加定義できます。
バックアップ制御ファイルを使用してデータベースをリストアした後、データベースに対してRECOVER DATABASEおよびOPEN RESETLOGSを実行する必要があります。
様々な状況（リカバリ・カタログを使用する場合、特定のバックアップからリストアする場合など）でRESTORE CONTROLFILEを使用する場合の制限の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のRESTORE CONTROLFILEの説明を参照してください。
サーバー・パラメータ・ファイル（SPFILE）が消失した場合は、Recovery Managerを使用してデフォルトの場所または任意の場所にリストアできます。
制御ファイルが消失した場合とは異なり、SPFILEが消失してもインスタンスはすぐに停止はしません。SPFILEをリストアした後にインスタンスを停止して再起動する必要がありますが、インスタンスは継続して稼働します。
SPFILEをリストアする際は、次の事項に注意してください。
TO句が使用されていなければ、Recovery ManagerはSPFILEをデフォルトの場所にリストアします。デフォルトの場所はプラットフォーム固有です（Linuxの場合は ?/dbs/spfile.ora）。
Recovery Managerでは、SPFILEのバックアップに基づいてクライアント側の初期化パラメータ・ファイルも作成できます。
サーバー・パラメータ・ファイル（SPFILE）をリストアする方法
% rman TARGET /
SPFILEが消失したときにデータベースが起動されておらず、リカバリ・カタログが使用されていない場合は、ターゲット・データベースのDBIDを設定する必要があります。 DBIDを決定する方法については、「DBIDの決定」を参照してください。
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RESTORE SPFILE FROM AUTOBACKUP;
デフォルト以外の場所にリストアする場合は、次の例のようなコマンドを実行します。
RMAN> RESTORE SPFILE TO '/tmp/spfileTEMP.ora' FROM AUTOBACKUP;
SPFILE=new_locationを使用して、新しいクライアント側の初期化パラメータ・ファイルを作成します。new_locationには、リストアしたサーバー・パラメータ・ファイルのパス名を指定します。次に、クライアント側の初期化パラメータ・ファイルを使用してインスタンスを再起動します。 たとえば、単一行を含む/tmp/init.oraファイルを作成します。
SPFILE=/tmp/spfileTEMP.ora
次に、次のRecovery Managerコマンドを使用して、格納されたSPFILEに基づいてインスタンスを再起動します。
RMAN> STARTUP FORCE PFILE=/tmp/init.ora; # startup with /tmp/spfileTEMP.ora
制御ファイルの自動バックアップが構成済の場合、SPFILEは、自動バックアップが行われるたびに制御ファイルを使用してバックアップされます。
自動バックアップからSPFILEをリストアする場合は、データベースのDBIDを設定した後で、RESTORE SPFILE FROM AUTOBACKUPコマンドを実行します。この手順は、自動バックアップから制御ファイルをリストアする場合と同様です。データベースのDBIDを設定した後で、RESTORE CONTROLFILE FROM AUTOBACKUPコマンドを実行します。
RMAN> SET DBID 320066378; RMAN> RUN { SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'autobackup_format'; RESTORE SPFILE FROM AUTOBACKUP; }
Recovery Managerでは、自動バックアップ書式およびDBIDを使用して制御ファイルの自動バックアップを検索し、制御ファイルの自動バックアップが検出されると、そのバックアップからデフォルトの場所にSPFILEをリストアします。
autobackup_formatの適切な値を判断する方法については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のCONFIGURE用のエントリ内のCONFIGURE CONTROLFILE AUTOBACKUP FORMATについての説明を参照してください。
DBIDを決定する方法については、「DBIDの決定」を参照してください。
サーバー・パラメータ・ファイルは、TO PFILE 'filename'句を使用してクライアント側の初期化パラメータ・ファイルとしてリストアすることもできます。指定するファイル名は、Recovery Managerクライアントが実行されているホストからアクセス可能なファイル・システム上に存在している必要があります。このファイルは、インスタンスを実行しているホストから直接アクセス可能である必要はありません。このコマンドを実行すると、Recovery Managerクライアントを実行しているシステム上に/tmp/initTEMP.oraというPFILEが作成されます。
RMAN> RESTORE SPFILE TO PFILE '/tmp/initTEMP.ora';
クライアント側のPFILEを使用してインスタンスを再起動するには、次のコマンドを実行して同じクライアント・マシン上で再度Recovery Managerを実行します。
RMAN> STARTUP FORCE PFILE='/tmp/initTEMP.ora';
元の場所への表領域のリストアと、その場所でのメディア・リカバリの実行については、「個々の表領域またはデータ・ファイルのリストアおよび完全リカバリ: 使用例」を参照してください。ただし、データ・ファイルの元の場所を含むディスクで障害が発生した場合などは、元の場所以外にデータ・ファイルをリストアする必要があります。
バックアップから新しい場所にデータ・ファイルをリストアする場合、制御ファイルにデータ・ファイルの新しい場所を反映することが重要です。次の例では、Recovery ManagerのSET NEWNAMEコマンドを使用して新しい名前を指定し、SWITCHコマンドを使用して制御ファイルを更新し、それらの新しい名前でデータベースの参照を開始します。
バックアップから元の場所にデータ・ファイルをリストアする場合と同様に、バックアップから新しい場所にデータ・ファイルをリストアする場合もリストア開始時に影響を受けた表領域をオフラインにする必要があります。
その後、RUNブロックを作成してRESTOREおよびRECOVERコマンドを囲みます。新しい場所に移動する各ファイルに対して、SET NEWNAMEコマンドを使用してそのファイルの新しい場所を指定します。
次に、RUNブロック内で、通常どおりRESTORE TABLESPACEまたはRESTORE DATAFILEを実行します。Recovery Managerを使用して、元の場所ではなくSET NEWNAMEで指定した場所に各データ・ファイルをリストアします。
RUNブロックのRESTOREコマンドとRECOVERコマンドの間でSWITCHコマンドを使用して、データ・ファイルの新しいファイル名で制御ファイルを更新します。SWITCHコマンドは、SQL文ALTER DATABASE RENAME FILEと同じ処理を実行します。SWITCH DATAFILE ALLを実行すると、制御ファイルに、RUNブロックでSET NEWNAMEが発行されているすべてのデータ・ファイルの新しい名前が反映されます。
次の例では、表領域usersおよびtoolsにあるデータ・ファイルを新しい場所にリストアして、リカバリを実行します。古いデータ・ファイルはディレクトリ/olddiskに格納され、新しいデータ・ファイルは/newdiskに格納されているとします。
RUN { SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE'; SQL 'ALTER TABLESPACE tools OFFLINE IMMEDIATE'; # specify the new location for each datafile SET NEWNAME FOR DATAFILE '/olddisk/users01.dbf' TO '/newdisk/users01.dbf'; SET NEWNAME FOR DATAFILE '/olddisk/tools01.dbf' TO '/newdisk/tools01.dbf'; # to restore to an ASM disk group named dgroup, use: # SET NEWNAME FOR DATAFILE '/olddisk/trgt/tools01.dbf' # TO '+dgroup'; RESTORE TABLESPACE users, tools; SWITCH DATAFILE ALL; # update control file with new filenames RECOVER TABLESPACE users, tools; }
正常にリカバリされたら、表領域をオンラインにします。
SQL 'ALTER TABLESPACE users ONLINE'; SQL 'ALTER TABLESPACE tools ONLINE';
メディア・リカバリは、アーカイブREDOログ、オンラインREDOログ、およびバックアップからリストアされたデータ・ファイルからのすべての変更に再適用されます。
メディア・リカバリを簡単な方法で実行するには、引数を指定せずにRECOVER DATABASEコマンドを使用します。
RMAN> RECOVER DATABASE;
次の例に示すとおり、個々の表領域またはデータ・ファイルのメディア・リカバリを実行したり、データベースの残りのリカバリ中に特定の表領域をスキップすることもできます。
RMAN> RECOVER DATABASE SKIP TABLESPACE users; RMAN> RECOVER TABLESPACE users, tools; RMAN> RECOVER DATAFILE '/newdisk/users01.dbf','/newdisk/tools01.dbf'; RMAN> RECOVER DATAFILE 4;
Recovery Managerでは、リカバリ処理中に必要なアーカイブREDOログがバックアップからリストアされます。バックアップがメディア・マネージャに格納されている場合は、前もってチャネルを構成する必要があること、ALLOCATE CHANNELコマンドでRUNブロックを使用して、そこに格納されているバックアップへのアクセスを有効にする必要があることに注意してください。
リストアされたこれらのファイルに関連付けられたディスク領域を管理する場合に有効なオプションの1つとして、DELETE ARCHIVELOGオプションがあります。リストアしたアーカイブREDOログは、RECOVER処理で不要になると、このオプションによってディスクから削除されます。
RMAN> RECOVER TABLESPACE users, tools DELETE ARCHIVELOG;
Recovery Managerを使用して、RECOVER処理を実行するためにフラッシュ・リカバリ領域にアーカイブREDOログ・ファイルをリストアすると、DELETE ARCHIVELOGオプションを使用しない場合でも、リストアしたログは、データ・ファイルに適用された後自動的に削除されます。
RECOVERコマンドのオプションの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
この手順では、単一のデータ・ファイルを新しい場所にリストアして、その場所でメディア・リカバリを実行します。この手順を使用すると、メディア障害などの問題のために、以前の場所にアクセスできない場合でも、リストアおよびリカバリを実行できます。
RUN { SET NEWNAME FOR DATAFILE 3 to 'new_location'; RESTORE DATAFILE 3; SWITCH DATAFILE 3; RECOVER DATAFILE 3; }
データ・ファイルを新しいOracle Managed Filesの場所に格納する場合は、次のような書式のコマンドを使用できます。
RUN { SET NEWNAME FOR DATAFILE 3 to NEW; RESTORE DATAFILE 3; SWITCH DATAFILE 3; RECOVER DATAFILE 3; }
リストアしたファイルは、OracleによってOMFの場所に格納され、ファイル名が付けられます。
アーカイブREDOログ・ファイルは、リカバリを実行する必要がある場合にRecovery Managerによってバックアップから自動的にリストアされます。
ただし、RECOVERコマンド実行時にアーカイブREDOログ・ファイルのリストアにかかる時間を短縮する必要がある場合、またはアーカイブREDOログ・ファイルを新しい場所に格納する場合、これらのアーカイブREDOログ・ファイルは手動でリストアすることもできます。
デフォルトでは、Recovery Managerは、ターゲット・データベースのLOG_ARCHIVE_FORMATおよびLOG_ARCHIVE_DEST_1パラメータを使用して構成された名前でアーカイブREDOログをリストアします。これらのパラメータはプラットフォーム固有の方式で組み合され、リストアしたアーカイブ・ログの名前を構成します。
SET ARCHIVELOG DESTINATIONコマンドを使用すると、リストアしたアーカイブREDOログのデフォルトの名前を上書きできます。このコマンドは、データベースのリストア中、様々な場所に手動でアーカイブ・ログをリストアします。リカバリ中、Recovery Managerは新しくリストアされたアーカイブ・ログの検出場所を認識します。このため、アーカイブ・ログは、初期化パラメータ・ファイルで指定されている場所にある必要はありません。
アーカイブREDOログを新しい場所へリストアする方法
RUNブロック内で次の操作を実行します。
次の例では、すべてのバックアップ・アーカイブ・ログを新しい場所へリストアします。
RUN { SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore'; RESTORE ARCHIVELOG ALL; # restore and recover datafiles as needed . . . }
アーカイブ・ログのリストア先を1つのRUNブロックに複数回指定して、リストアしたログを複数のリストア先に分散できます。（ただし、同時に複数のリストア先を指定して、リストア操作時に同じログの複数のコピーを生成することはできません。）この機能を使用して、リストアしたログを格納するために使用するディスク領域を管理できます。
次の例では、バックアップから300のアーカイブREDOログをリストアし、ディレクトリ /fs1/tmp、/fs2/tmpおよび/fs3/tmpに分散します。
RUN { # Set a new location for logs 1 through 100. SET ARCHIVELOG DESTINATION TO '/fs1/tmp'; RESTORE ARCHIVELOG FROM SEQUENCE 1 UNTIL SEQUENCE 100; # Set a new location for logs 101 through 200. SET ARCHIVELOG DESTINATION TO '/fs2/tmp'; RESTORE ARCHIVELOG FROM SEQUENCE 101 UNTIL SEQUENCE 200; # Set a new location for logs 201 through 300. SET ARCHIVELOG DESTINATION TO '/fs3/tmp'; RESTORE ARCHIVELOG FROM SEQUENCE 201 UNTIL SEQUENCE 300; # restore and recover datafiles as needed . . . }
RECOVERコマンドを発行すると、リストアした必要なアーカイブ・ログがリストア先で自動的に検出され、データ・ファイルに適用されます。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|