11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、Recovery Managerの表領域のPoint-in-Timeリカバリを実行する方法について説明します。この章では、次の項目について説明します。
この項では、Recovery Managerの表領域のPoint-in-Timeリカバリに含まれる基本的な概念およびタスクについて説明します。
Recovery Managerで自動化されるTSPITRを使用すると、データベースの1つ以上の表領域をデータベースの残りの表領域およびオブジェクトには影響を及ぼさずに、過去の時点まで迅速にリカバリできます。
Recovery ManagerのTSPITRは、次の場合に最も有効です。
ordersおよびpersonnel表領域に論理データベースを保持している場合などです。不正なバッチ・ジョブまたはDML文を実行すると、いずれかの表領域にのみ存在するデータが破損します。
PURGEオプションを使用して表を削除した後、その表をリカバリする場合。
フラッシュバック・データベースを使用してデータを巻き戻すこともできますが、サブセットのみでなくデータベース全体を巻き戻す必要があります。また、TSPITRとは異なり、フラッシュバック・データベース機能ではフラッシュバック・ログを保持するオーバーヘッドが伴います。データベースのフラッシュバックが可能な期間は、TSPITRの期間より限られています。TSPITRの期間は、最も古いリカバリ可能なバックアップまでの期間となります。
TSPITRは、Recovery ManagerのRECOVER TABLESPACEコマンドを使用して実行します。ターゲット・インスタンスには、目標時点までリカバリする表領域が含まれています。目標時点とは、TSPITRが完了した後の表領域の過去の時刻またはSCNのことです。
補助インスタンスとは、リカバリ・プロセスで使用され、リカバリ作業を実行するデータベース・インスタンスのことです。補助インスタンスには制御ファイル、パラメータ・ファイル、オンライン・ログなどの他のファイルが関連付けられますが、これらのファイルは補助セットの一部ではありません。
リカバリ・セットには、リカバリする表領域のデータファイルが含まれています。補助セットにはリカバリ・セットのTSPITRに必要なデータファイルが含まれていますが、そのデータファイル自体はリカバリ・セットの一部ではありません。通常、補助セットには次のものが含まれます。
補助の格納場所とは、TSPITRの実行中に補助インスタンスの補助セットのデータファイル、制御ファイルおよびオンラインREDOログの格納に使用できる、ディスク上の任意の場所のことです。ここに格納されたファイルは、TSPITRの完了後に削除できます。
最も簡単な形式のTSPITR（「完全に自動化されたRecovery ManagerのTSPITRの実行」を参照）では、リカバリ・セットの表領域および目標時点を指定します。Recovery Managerによって次の処理が自動的に実行されます。
SYS.TS_PITR_CHECKを実行します。問合せが行を戻す場合、Recovery ManagerはTSPITRを続行しません。
各ファイルに指定した場所、またはファイルの元の場所（リカバリ・セット・ファイルの場合）か補助の格納場所（補助セット・ファイルの場合で、RECOVER TABLESPACEにAUXILIARY DESTINATION引数を使用したとき）のいずれかにファイルをリストアします。
RESETLOGSオプションを使用して補助データベースをオープンします。
SWITCHコマンドを発行します。これによって、ターゲット・データベースの制御ファイルが、補助インスタンスでリカバリされたリカバリ・セットのデータファイルを指すようになります。
この時点でTSPITRは完了です。リカバリ・セットのデータファイルは、指定した時点の内容に戻り、ターゲット・データベースに属します。
TSPITRを実行する前に、「TSPITRの前提条件および結果」を参照して、TSPITRが実行可能かどうかを確認します。TSPITRを実行する場合は、「TSPITRの計画および準備」で説明されている準備段階に進むことができます。
TSPITRを実際に実行する準備ができた場合、基本手順は使用する方法によって異なります。選択できる方法の詳細は、次の項を参照してください。
補助の格納場所を指定し、Recovery ManagerでTSPITRのすべての手順を管理します。これがTSPITRの最も簡単な方法です。特に操作を制御する必要がないかぎり、この方法をお薦めします。
補助の格納場所を使用して、完全に自動化されたTSPITRの動作に基づいてTSPITRを構成します。ただし、動作の1つ以上の設定をカスタマイズします。たとえば、補助セットまたはリカバリ・セット・ファイルの場所を指定するか、またはRecovery Managerによって作成および管理される補助インスタンスの初期化パラメータまたはチャネル構成を指定できます。
この方法では、TSPITRで使用する補助インスタンスの設定、起動、停止およびクリーンアップを独自に行います。また、自動補助インスタンスを使用したカスタマイズTSPITRで使用可能ないくつかの方法でも、TSPITRのプロセスを管理できます。
TSPITRでは解決できないデータベースの問題も多くあります。次に、TSPITRを実行できない場合のTSPITRの前提条件のリストを示します。
NOARCHIVELOGモードで実行されている場合は、TSPITRを実行できません。
この場合、表領域名が変更される前の時点までデータベース全体をリカバリする必要があります。表領域は、その時点で付けられていた名前で検出されます。
tbs1の表の制約が表領域tbs2に含まれている場合、tbs2をリカバリせずにtbs1をリカバリすることはできません。
TSPITRが完了した後、Recovery Managerは、リカバリ・セットのデータファイルを目標時点までリカバリします。TSPITRの結果は、次のとおりです。
TSPITRの完了後に新しい統計情報を収集する必要があります。
この表領域に対して、時刻t以前の時点までTSPITRを再実行することはできません。また、現行の制御ファイルを使用して、データベースを時刻t以前の時点までリカバリすることもできません。そのため、TSPITRの完了直後にリカバリした表領域をバックアップする必要があります。
TSPITRの実行時にリカバリ・カタログを使用しない場合は、次の特別な考慮事項があります。
CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータを十分に大きい値に設定して、TSPITRに必要な制御ファイル・レコードが確実に保持されるようにします。）
この項では、「TSPITRの前提条件および結果」を参照済であると想定しています。TSPITRの準備では、次の手順を実行する必要があります。
TSPITRでの正しい目標時点またはSCNを選択することは、非常に重要です。「TSPITRの前提条件および結果」で説明されているように、TSPITRの実行後に表領域をオンラインにすると、それより前の時点のバックアップは使用できなくなります。つまり、最初に誤った目標時点を選択すると、リカバリ・カタログを使用していないかぎり、TSPITRを再試行できません。
リカバリ・カタログを使用している場合は、表領域の履歴情報がカタログに格納されているため、TSPITR操作を異なる目標時点まで繰り返し実行できます。ただし、Recovery Managerで制御ファイルのみが使用される場合、表領域の履歴は存在しません。この場合、Recovery Managerは現行の表領域のセットのみを認識します。TSPITRが実行された表領域の作成時刻は、オンラインになった時点になります。
リカバリ・カタログを使用しない状況を想定します。表領域に対してTSPITRを実行し、金曜日の午後5時に表領域をオンラインにします。金曜日の午後5時より前に作成された表領域のバックアップは、現行の制御ファイルでのリカバリには使用できません。この表領域に対して、金曜日の午後5時より前の目標時点を指定してTSPITRを再実行することはできません。また、現行の制御ファイルを使用して、データベースを金曜日の午後5時より前の時点までリカバリすることもできません。リストアした制御ファイルを使用して、データベース全体のPoint-in-Timeリカバリを実行する必要があります。
TSPITRの目標時点を指定するためにデータの過去の状態を調べるには、Oracle Flashback Query、Oracle Flashback Transaction QueryおよびOracle Flashback Version Queryを使用して、データベースに不要な変更が発生した時点を検索します。
最初、リカバリ・セットには、リカバリする表領域のデータファイルが含まれています。ただし、必要な表領域内のオブジェクトが他の表領域内のオブジェクトと関係（制約など）を持つ場合、TSPITRを実行する前にこの関係を処理する必要があります。このような関係に対応するには、次のいずれかの方法を選択します。
TS_PITR_CHECKビューでは、リカバリ・セットの境界にまたがるオブジェクト間の関係を確認できます。このビューの問合せ時に行が戻された場合は、問題を調査および解決する必要があります。TS_PITR_CHECKビューでリカバリ・セットに含まれていない表領域に対して行が戻されない場合にのみ、TSPITRを続行します。TSPITRの完了後に一時解消または削除した関係を再作成できるように、この手順で実行するすべての処理を記録します。
例20-1の問合せでは、TS_PITR_CHECKビューの使用方法を示します。たとえば、toolsおよびusersで構成される最初のリカバリ・セットを使用し、次のようにTS_PITR_CHECKに対してSELECT文を実行します。
SELECT * FROM SYS.TS_PITR_CHECK WHERE ( TS1_NAME IN ('USERS','TOOLS') AND TS2_NAME NOT IN ('USERS','TOOLS') ) OR ( TS1_NAME NOT IN ('USERS','TOOLS') AND TS2_NAME IN ('USERS','TOOLS') );
データベース内のすべての表領域（リカバリ・セットの表領域のみではなく）に対して、TSPITRを実行できるかどうかを完全に確認するには、例20-2の問合せを実行します。
SELECT * FROM SYS.TS_PITR_CHECK WHERE ( 'SYSTEM' IN (TS1_NAME, TS2_NAME) AND TS1_NAME <> TS2_NAME AND TS2_NAME <> '-1' ) OR ( TS1_NAME <> 'SYSTEM' AND TS2_NAME = '-1' );
TS_PITR_CHECKビューの列の列数および列幅のため、問合せの実行時に列を次のように調整する必要がある場合があります。
SET LINESIZE 120 COLUMN OBJ1_OWNER HEADING "own1" COLUMN OBJ1_OWNER FORMAT a6 COLUMN OBJ1_NAME HEADING "name1" COLUMN OBJ1_NAME FORMAT a5 COLUMN OBJ1_SUBNAME HEADING "subname1" COLUMN OBJ1_SUBNAME FORMAT a8 COLUMN OBJ1_TYPE HEADING "obj1type" COLUMN OBJ1_TYPE FORMAT a8 word_wrapped COLUMN TS1_NAME HEADING "ts1_name" COLUMN TS1_NAME FORMAT a6 COLUMN OBJ2_NAME HEADING "name2" COLUMN OBJ2_NAME FORMAT a5 COLUMN OBJ2_SUBNAME HEADING "subname2" COLUMN OBJ2_SUBNAME FORMAT a8 COLUMN OBJ2_TYPE HEADING "obj2type" COLUMN OBJ2_TYPE FORMAT a8 word_wrapped COLUMN OBJ2_OWNER HEADING "own2" COLUMN OBJ2_OWNER FORMAT a6 COLUMN TS2_NAME HEADING "ts2_name" COLUMN TS2_NAME FORMAT a6 COLUMN CONSTRAINT_NAME HEADING "cname" COLUMN CONSTRAINT_NAME FORMAT a5 COLUMN REASON HEADING "reason" COLUMN REASON FORMAT a25 word_wrapped
パーティション表tpに、p1およびp2の2つのパーティションが含まれ、それらがそれぞれ表領域usersおよびtoolsに存在するとします。また、パーティション索引tpindがtpに定義され、その索引にid1およびid2の2つのパーティション（それぞれ表領域id1およびid2に存在する）が存在するとします。この場合、例20-1の問合せを実行すると、例20-3に示す出力が表示されます。
own1 name1 subname1 obj1type ts1_name name2 subname2 obj2type own2 ts2_name cname reason
--- ---- ----- ------ ------- ---- ------ -------- --- -------- --- ------
SYSTEM TP P1 TABLE USER TPIND IP1 INDEX PARTITION PARTITION SYS ID1 Partitioned Objects not fully contained in the recovery set
SYSTEM TP P2 TABLE TOOLS TPIND IP2 INDEX PARTITION PARTITION SYS ID2 Partitioned Objects not fully contained in the recovery set
例20-3は、SYSTEM.tpが表領域id1のip1および表領域id2のip2の2つのパーティションから構成されるパーティション索引tpindを持っていることを示しています。TSPITRを実行するには、tpindを削除するか、またはid1およびid2をリカバリ・セットに含める必要があります。
表領域に対してRecovery ManagerのTSPITRを実行すると、リカバリの目標時点より後に作成されたオブジェクトは消失します。このようなオブジェクトを確認した場合は、TSPITRの実行前にデータ・ポンプ・エクスポート・ユーティリティを使用してそれらをエクスポートし、後でデータ・ポンプ・インポートを使用して再インポートすることで、それらのオブジェクトを保存できます。
TSPITRを実行すると消失するオブジェクトを確認するには、プライマリ・データベースでTS_PITR_OBJECTS_TO_BE_DROPPEDビューを問い合せます。表20-1に、このビューの内容を示します。
| 列名 | 意味 |
|---|---|
|
|
削除されるオブジェクトの所有者 |
|
|
TSPITRを実行した結果、消失するオブジェクトの名前 |
|
|
オブジェクトの作成タイムスタンプ |
|
|
オブジェクトを含む表領域の名前 |
CREATION_TIMEがTSPITRの目標時点より後であるオブジェクトのビューをフィルタ処理します。たとえば、usersおよびtoolsで構成されるリカバリ・セットを使用し、リカバリの目標時点が2007年11月2日午前7:03:11の場合は、例20-4の文を発行します。
SELECT OWNER, NAME, TABLESPACE_NAME, TO_CHAR(CREATION_TIME, 'YYYY-MM-DD:HH24:MI:SS') FROM TS_PITR_OBJECTS_TO_BE_DROPPED WHERE TABLESPACE_NAME IN ('USERS','TOOLS') AND CREATION_TIME > TO_DATE('02-NOV-06:07:03:11','YY-MON-DD:HH24:MI:SS') ORDER BY TABLESPACE_NAME, CREATION_TIME;
TO_CHARおよびTO_DATEファンクションを使用すると、国によって異なる日付書式を使用した場合の問題を回避できます。ユーザーは、ユーザー自身の作業では現地の日付書式を使用できます。
完全に自動化されたTSPITRを実行すると、プロセス全体がRecovery Managerによって管理されます。
Recovery ManagerのTSPITRは、ターゲット・データベースでの構成にできるかぎり基づきます。TSPITRの実行中、リカバリ・セットのデータファイルはターゲット・データベースの現行の場所に書き込まれます。バックアップからファイルをリストアする場合は、ターゲット・データベースで有効なチャネル構成と同じ構成が補助インスタンスで使用されます。ただし、補助セットのデータファイルおよび補助インスタンスの他のファイルは、補助の格納場所に格納されます。
Recovery Managerで補助セットのデータファイルおよび補助インスタンスの他のファイルを格納する補助の格納場所を設定するには、AUXILIARY DESTINATIONパラメータを使用します。補助の格納場所は、補助セットのデータファイルを格納するための領域が十分にあるディスク上の場所にする必要があります。他の方法を使用して一部またはすべての補助セットのデータファイル名を変更した場合でも、AUXILIARY DESTINATIONパラメータを指定すると、名前が指定されていない補助セットのデータファイルにデフォルトの場所が提供されます。補助セットの一部のデータファイルに名前を指定しなかった場合でも、TSPITRは正常に実行されます。
自動化されたTSPITRでRecovery Managerクライアントを起動する場合は、補助インスタンスに接続しないでください。Recovery Managerは、
注意:
RECOVER TABLESPACEを実行するときに補助インスタンスに接続していると、「独自の補助インスタンスを使用したRecovery ManagerのTSPITRの実行」で説明されているように、ユーザー独自の補助インスタンスを管理しようとしていると判断し、接続している補助インスタンスをTSPITRに使用します。
補助インスタンスでは、TSPITRの実行時に、ターゲット・インスタンスと同じチャネル構成が使用されます。
UNTIL句およびAUXILIARY DESTINATIONパラメータを指定して、RECOVER TABLESPACEコマンドを実行します。例20-5では、usersおよびtools表領域をログ順序番号1300まで戻し、補助インスタンスのファイルを/disk1/auxdestディレクトリに格納します。
RECOVER TABLESPACE users, tools UNTIL LOGSEQ 1300 THREAD 1 AUXILIARY DESTINATION '/disk1/auxdest';
この次の手順は、RECOVERコマンドの結果によって異なります。
表領域は、Recovery Managerによってオフラインにされ、バックアップからリストアされて補助インスタンスで目標時点までリカバリされた後、ターゲット・データベースに再インポートされます。表領域はオフラインのままです。補助セットのすべてのデータファイルおよび補助インスタンスの他のファイルは、補助の格納場所から削除されます。
補助セットのデータファイルおよび補助インスタンスの他のファイルは、補助の格納場所に残され、トラブルシューティングに使用できます。リカバリ・セット・ファイルの状態は、エラーのタイプによって決まります。問題の解決後、TSPITRを再試行できます。
たとえば、次のコマンドを入力します。
BACKUP TABLESPACE users, tools;
表領域に対してTSPITRを実行した後、TSPITRが完了し、表領域がオンラインになるまで、その表領域のバックアップは使用できません。バックアップを作成せずにリカバリした表領域を使用すると、これらの表領域の使用可能なバックアップが存在しない状態でデータベースを実行することになります。
たとえば、次のコマンドを入力します。
RMAN> SQL "ALTER TABLESPACE users, tools ONLINE";
これで、リカバリした表領域を使用できます。
Recovery ManagerのTSPITRでは、多くの操作で「完全に自動化されたRecovery ManagerのTSPITRの実行」の手順に従う必要がありますが、次のタスクはカスタマイズできます。
このタスクについては、「TSPITRでのOracle Managed Filesの名前の変更」を参照してください。
このタスクについては、「SET NEWNAMEを使用したTSPITRのリカバリ・セットのデータファイル名の変更」を参照してください。
このタスクについては、「TSPITRの補助セットのデータファイル名の指定」を参照してください。
このタスクについては、「イメージ・コピーを使用したRecovery ManagerのTSPITRの高速化」を参照してください。
このタスクについては、「TSPITRにおける自動補助インスタンスの初期化パラメータのカスタマイズ」を参照してください。
データファイルまたはオンラインREDOログ・ファイルがOracle Managed Files（OMF）形式であるときにTSPITRをカスタマイズする場合は、次の方法でファイル名を変更できます。名前の指定方法を推奨順に示します。
DB_CREATE_FILE_DEST、DB_RECOVERY_FILE_DEST、およびDB_CREATE_ONLINE_LOG_DEST_nを1つ以上使用して格納場所を指定します。DB_FILE_NAME_CONVERTまたはLOG_FILE_NAME_CONVERT初期化パラメータは設定しないでください。
DB_FILE_NAME_CONVERTおよびLOG_FILE_NAME_CONVERT初期化パラメータを設定します。ASMでOracle Managed Filesを使用すると、Recovery Managerは、ASMディスク・グループ名のみを変換するパターンを使用して、変換されたディスク・グループの有効なOMFファイル名を生成します。
リカバリ・セットのデータファイルは、元の場所にリストアおよびリカバリしない方がよい場合があります。SET NEWNAMEコマンドを使用すると、新しい格納場所を指定できます。CONFIGURE AUXNAMEを使用してリカバリ・セットのデータファイルの名前を変更することもできますが、その影響は異なります。CONFIGURE AUXNAMEの詳細は、「イメージ・コピーを使用したRecovery ManagerのTSPITRの高速化」を参照してください。
リカバリ・セットの新しいファイル名を指定するには、RUNブロックを作成し、そのブロック内でSET NEWNAMEコマンドを使用します。複数のファイル名が相互に競合しない名前、または現行のデータファイル名と競合しない名前を割り当ててください。例20-6に、基本的な方法を示します。
RUN { . . . SET NEWNAME FOR DATAFILE 'ORACLE_HOME/oradata/trgt/users01.dbf' TO '/newfs/users01.dbf'; ...other setup commands... RECOVER TABLESPACE users, tools UNTIL SEQUENCE 1300 THREAD 1; }
TSPITRの実行中に、指定した各データファイルが新しい場所にリストアされ、その場所でリカバリされます。また、制御ファイルが更新され、制御ファイル内の古いデータファイルが新しくリカバリしたデータファイルに置き換えられます。Recovery Managerは、新しく指定した場所で検出されたデータファイルの既存のイメージ・コピー・バックアップを上書きします。
Recovery Managerは、リカバリを実際に実行するまで、SET NEWNAMEで設定された名前とターゲット・データベースの現行のデータファイル名の間の競合を検出しません。Recovery Managerが競合を検出すると、TSPITRは失敗し、Recovery Managerはエラーをレポートします。有効なデータファイルは上書きされません。
通常は元の場所に格納されるリカバリ・セットのデータファイルとは異なり、補助セットのデータファイルは、ターゲット・データベース内の対応する元のファイルを上書きできません。元の場所とは異なる補助セット・ファイルの格納場所を指定しない場合、TSPITRは失敗します。Recovery Managerが元のデータベース内の対応するファイルの上書きを試行し、そのファイルが使用中であることを検出した場合、障害が発生します。
補助セットのデータファイルの格納場所には、TSPITRの補助の格納場所を指定する方法が最も簡単です。ただし、Recovery Managerでは、補助セットのデータファイルの場所を制御するための代替方法がサポートされています。表20-2に、それらの方法を優先順位に従って示します。
| 順位 | 方法 | 参照先 |
|---|---|---|
|
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
2つの設定が同時に適用された場合、優先順位の高い設定が優先順位の低い設定より優先されます。たとえば、補助セットの一部のデータファイルの補助名がCONFIGURE AUXNAMEで構成されているときにターゲット・データベースでRECOVER TABLESPACE... AUXILIARY DESTINATIONを実行した場合などです。
前述のいずれかの方法を使用して特定のファイルの格納場所を指定する場合でも、RECOVER TABLESPACEにAUXILIARY DESTINATION引数を指定することをお薦めします。これによって、補助セットのデータファイル名を変更し忘れた場合でも、TSPITRが正常に実行されます。名前を変更していないファイルは、補助の格納場所に格納されます。
補助セットのデータファイルに新しい名前を指定するには、RECOVER TABLESPACEコマンドをRUNブロックに含め、SET NEWNAMEコマンドをRUNブロック内で使用してファイル名を変更します。例20-7に、基本的な方法を示します。
RUN { SET NEWNAME FOR DATAFILE '?/oradata/prod/system01.dbf' TO '/disk1/auxdest/system01.dbf'; SET NEWNAME FOR DATAFILE '?/oradata/prod/sysaux01.dbf' TO '/disk1/auxdest/sysaux01.dbf'; SET NEWNAME FOR DATAFILE '?/oradata/prod/undotbs01.dbf' TO '/disk1/auxdest/undotbs01.dbf'; RECOVER TABLESPACE users, tools UNTIL LOGSEQ 1300 THREAD 1 AUXILIARY DESTINATION '/disk1/auxdest'; }
この結果は、RECOVER TABLESPACEの実行時に/disk1/auxdest/system01.dbfが存在するかどうかによって異なります。?/oradata/system01.dbfが指定した場所に存在し、TSPITRのUNTILの時点より前のSCNで作成されている場合、動作は「補助セットのイメージ・コピーでのSET NEWNAMEおよびCONFIGURE AUXNAMEの使用」で説明されているとおりになります。それ以外の場合、Recovery Managerは、デフォルトの場所ではなくNEWNAMEで指定した場所に補助セットのデータファイルをリストアします。補助セットのデータファイルが格納される場所のみを制御する場合は、TSPITRの実行前にSET NEWNAMEで指定した場所にファイルが格納されていないことを確認します。
補助セットのすべてのデータファイルには補助の格納場所を使用せず、すべてのデータファイルには個々に名前も指定しない場合を想定します。この場合、補助インスタンスで使用される初期化パラメータ・ファイルに、DB_FILE_NAME_CONVERT初期化パラメータを含めることができます。この方法は、次の場合にのみ使用できます。
補助インスタンス内のDB_FILE_NAME_CONVERT初期化パラメータによって、ターゲット・データベース・インスタンス内の対応するファイルの元の名前から補助インスタンスのファイルの名前を導出する方法が指定されます。このパラメータは、文字列のペアのリストで構成されます。ペアの1つ目の文字列を含むファイル名の場合、補助インスタンスの一致するファイル名は、ペアの2つ目の文字列を元のファイル名に置き換えることによって生成されます。
たとえば、ターゲット・インスタンスに次のファイルが含まれているとします。
SYSTEM表領域の?/oradata/trgt/system01.dbf
SYSAUX表領域の?/oradata/trgt/sysaux01.dbf
undotbs表領域の?/oradata/trgt/undotbs01.dbf
補助インスタンス内の対応するファイルを/bigtmp内に配置する場合は、次の行を補助インスタンスのパラメータ・ファイルに追加します。
DB_FILE_NAME_CONVERT=('?/oradata/trgt', '/bigtmp')
対応する補助インスタンス・ファイルの新しいファイル名は、/bigtmp/trgt/system01.dbf、/bigtmp/trgt/sysaux01.dbfおよび/bigtmp/trgt/undotbs01.dbfです。
最も重要な点は、補助インスタンスのパラメータ・ファイルにDB_FILE_NAME_CONVERTを含める必要があることです。補助インスタンスを手動で作成した場合は、その補助インスタンスのパラメータ・ファイルにDB_FILE_NAME_CONVERTを追加します。
SET NEWNAMEまたはCONFIGURE AUXNAMEを使用して、補助セットの個々のデータファイル名を変更することもできます。また、DB_FILE_NAME_CONVERTで指定したパターンと一致しないファイルの名前は変更されません。RECOVER TABLESPACEのAUXILIARY DESTINATIONパラメータを使用して、補助セットのすべてのデータファイルが格納場所に転送されていることを確認することをお薦めします。使用した名前の変更方法によって補助インスタンスの新しいファイル名が提供されない場合、TSPITRは失敗します。
Oracle Managed Files（OMF）は、ASMストレージまたは非ASMストレージで使用できます。DB_FILE_NAME_CONVERT初期化パラメータが設定されている場合は、OMFのストレージがASMであるかどうかによって、TSPITRで実行される名前の変換方法が異なります。ASMに格納されているOMFファイルの場合は、データベースによってディスク・グループ名のみが+DISK1から+DISK2などように変換されます。ASMに格納されていないOMFファイルの場合は、データベースによってDB_FILE_NAME_CONVERT格納場所に格納され、部分文字列が置き換えられます。ターゲット・インスタンスのOMFファイル名の部分文字列を置き換えることによって、補助インスタンスに有効な非ASMのOMFファイル名を生成することはできません。そのため、DB_FILE_NAME_CONVERTを使用して、この状況で新しい名前の生成を制御することはできません。
この問題を回避するために、OMFファイル（ASMに格納されているファイルを含む）の名前を生成するためにサポートされているその他のオプションのいずれかを使用します。
DB_CREATE_FILE_DEST初期化パラメータを使用して、SET NEWNAMEまたはCONFIGURE AUXNAMEでは新しい名前が指定されないすべての補助インスタンス・ファイルの場所を指定します。
SET NEWNAMEを使用して、個々のファイルを補助インスタンスからアクセスできる固有のディスク・グループにリダイレクトできます（また、データベースではディスク・グループ内でファイル名を生成できます）。たとえば、次のように入力します。
RUN { SET NEWNAME FOR DATAFILE 1 TO "+DISK2"; SET NEWNAME FOR DATAFILE 2 TO "+DISK3"; RECOVER TABLESPACE users, tools UNTIL LOGSEQ 1300 THREAD 1 AUXILIARY DESTINATION '/disk1/auxdest'; }
一時ファイルは、データベースの補助セットの一部とみなされます。補助インスタンスのインスタンス化時に、Recovery Managerは、ターゲット・データベースの一時表領域を再作成し、補助データファイル名の通常の規則に従って名前を生成します。
SET NEWNAME FOR TEMPFILE、DB_FILE_NAME_CONVERTまたはAUXILIARY DESTINATIONコマンドを使用すると、一時ファイルの名前を変更できます。補助インスタンスのオープン時に、Recovery Managerは、名前の変更規則に従って一時ファイルを再作成します。補助インスタンスを削除すると、残りの補助インスタンス・ファイルとともに一時ファイルが削除されます。
リカバリ・セットおよび補助セットのデータファイルの既存のイメージ・コピーをRecovery Managerが使用するようにリダイレクトすることによって、TSPITRのパフォーマンスを向上させることができます。この場合、Recovery Managerはバックアップからデータファイルをリストアする必要がありません。次の方法を使用して、データファイルのイメージ・コピーの存在をRecovery Managerに認識させることができます。
CONFIGURE AUXNAMEコマンドを使用します。
SET NEWNAMEコマンドを使用します。
通常、指定した場所で適切なイメージ・コピーが使用可能な場合は、そのイメージ・コピーがRecovery Managerによってターゲット・インスタンスのRecovery Managerリポジトリのカタログから削除され、補助インスタンスの制御ファイルのカタログに追加されます。このイメージ・コピーを使用して、補助インスタンスでPoint-in-Timeリカバリが実行されます。詳細は、使用するコマンド、およびファイルが補助セット・ファイルかリカバリ・セット・ファイルかによって異なります。
TSPITRの実行中、Recovery Managerは、AUXNAMEで指定した場所でデータファイルを検索します。また、目標時点までリカバリ可能な古いデータファイル・チェックポイントSCNを持つデータファイルのイメージ・コピー・バックアップが存在するかどうかを確認します。使用可能なイメージ・コピーが検出されると、Recovery Managerは、そのイメージ・コピーをTSPITRで使用します。検出されない場合、Recovery Managerは、データファイルをリストアし、元の場所でリカバリします。AUXNAMEで指定した場所のファイルは変更または削除されません。例20-8に、この方法を示します。
CONFIGURE AUXNAME FOR DATAFILE 'ORACLE_HOME/oradata/trgt/users01.dbf' TO '/newfs/users1.dbf'; ...other RMAN commands, if any... RECOVER TABLESPACE users, tools UNTIL SEQUENCE 1300 THREAD 1;
CONFIGURE AUXNAMEは、主にリストア時間を削減してTSPITRを高速化するために使用されます。TSPITRを実行する可能性がある表領域が存在する場合は、影響を受けるデータファイルのイメージ・コピー・セットをバックアップ・ルーチンで保持し、そのデータファイルのイメージ・コピーをTSPITRを実行する可能性がある最も早い目標時点まで定期的に更新できます。予測される実行手順のモデルは、次のとおりです。
AUXNAMEを1回構成します。
BACKUP AS COPY DATAFILE n FORMAT auxnameを定期的に実行して、更新されたイメージ・コピーを保持します。パフォーマンスを向上させるために、増分更新バックアップ方法を使用して、データファイルの全体バックアップを実行せずにイメージ・コピーを最新に保ちます。
イメージ・コピーが必要な表領域が事前にわからない場合があることに注意してください。「リカバリ・セットの決定」で説明されているように、リカバリする表領域と他の表領域の間に関係が存在すると、最後のリカバリ・セットに表領域を追加する必要がある場合があります。また、補助セット内に別の表領域が残る場合もあります。リカバリ・セットに含める可能性がある各データファイルに対してAUXNAMEを構成し、すべてのデータファイルのイメージ・コピーを頻繁に更新する必要があります。
すべての表領域がリカバリ・セットに含まれることを正しく予測できない場合があります。また、オーバーヘッドを考慮して、リカバリ・セットに含まれる可能性があるすべての表領域のコピーを保持しないでおく場合もあります。いずれの場合も、データファイルのサブセットのみを準備できます。TSPITRのプロセスは同じです。Recovery Managerは、元の場所にイメージ・コピーがないリカバリ・セットのデータファイルがリカバリされる必要があるため、プロセスには時間がかかります。
ネーミング・メソッドの優先順位は、CONFIGURE AUXNAMEを使用してリカバリ・セット・ファイルの名前を変更する場合にも適用されることに注意してください。TSPITRコマンドの一部としてのリカバリ・セット・ファイルに対するSET NEWNAMEは、同じファイルに対するCONFIGURE AUXNAMEコマンドより優先されます。このインスタンスの動作は、「SET NEWNAMEを使用したTSPITRのリカバリ・セットのデータファイル名の変更」での説明のとおりになります。リカバリ・セット・ファイルで使用されるSET NEWNAMEでは、イメージ・コピーは参照されません。
リカバリ・セットのデータファイルと同様に、CONFIGURE AUXNAMEを使用すると、補助セットのデータファイルのイメージ・コピーの永続的な代替格納場所を設定できます。一方、SET NEWNAMEを使用すると、RUNコマンド実行中の代替格納場所を設定できます。ただし、Recovery Managerは、リカバリ・セットのデータファイルとは異なる方法で補助セットのデータファイルの値を処理します。つまり、補助セットのファイルでは、常にAUXNAMEまたはNEWNAMEが使用されますが、リカバリ・セットのファイルでは、有効なコピーが存在する場合にのみAUXNAMEまたはNEWNAMEが使用されます。
SET NEWNAMEまたはCONFIGURE AUXNAMEを使用して、補助セットのデータファイルの新しい格納場所を指定するとします。また、TSPITRで使用可能なSCNを持つイメージ・コピーがその場所に存在するとします。この場合、Recovery Managerはイメージ・コピーを使用します。ただし、使用可能なイメージ・コピーがその場所に存在しない場合、Recovery Managerは、使用可能なコピーをバックアップからリストアします。（イメージ・コピーは存在するが、SCNがTSPITRの目標時点より後の場合は、リストアしたファイルによってデータファイルが上書きされます。）
すべての補助セットのファイルと同様に、TSPITRが正常に実行されると、ファイルは削除されます。TSPITRが失敗すると、トラブルシューティングで使用するために、ファイルは削除されません。そのファイルが、TSPITRの実行前に作成されたイメージ・コピーであるか、TSPITRの実行中にRecovery Managerによってバックアップからリストアされたかに関係なく、このように動作します。
TSPITRで使用するデータベース全体のイメージ・コピーを保存するための十分なディスク領域があるとします。TSPITRを実行する必要がある場合の準備として、次の手順を実行します。
AUXNAMEを構成します。
CONFIGURE AUXNAME FOR DATAFILE n TO auxname_n;
BACKUP AS COPY DATAFILE n FORMAT auxname_n
すべてのイメージ・コピーがディスクの同じ場所に格納され、元のデータファイルに類似した名前が付けられている場合は、すべてのデータファイルのバックアップが個々に実行されないようにできます。かわりに、BACKUPコマンドのFORMATまたはDB_FILE_NAME_CONVERTオプションを指定して、BACKUP AS COPY DATABASEを使用できます。たとえば、構成した補助名が場所maindiskをauxdiskに変換したものである場合は、次のコマンドを使用できます。
BACKUP AS COPY DATABASE DB_FILE_NAME_CONVERT (maindisk, auxdisk);
これで、バックアップからリストアせずにTSPITRの準備が完了します。たとえば、2007年11月15日19:00:00に誤ったバッチ・ジョブが開始され、これによって表領域partsの表が不正に更新された場合、次のコマンドを使用して、表領域partsでTSPITRを実行できます。
RECOVER TABLESPACE parts UNTIL TIME 'November 15 2007, 19:00:00';
AUXNAMEの場所を構成すると、TSPITRの目標時点より前のSCN以降のデータファイルのコピーを参照するため、補助セットおよびリカバリ・セットのデータファイルは、バックアップからリストアされません。かわりに、データファイルのコピーはリカバリに直接使用され、リストアのオーバーヘッドが解消されます。
TSPITRの完了時に、表領域partsのデータファイルが元のデータファイルの場所には格納されていないことに注意してください。かわりに、それらのデータファイルはAUXNAMEの場所に格納されます。補助セットにAUXNAMEの場所のみを使用する場合は、リカバリ・セットのファイルにCONFIGURE AUXNAME ... CLEARを実行してから、TSPITRを開始します。この場合、Recovery Managerはデータファイルをリストアする必要があります。
自動補助インスタンスでは、オペレーティング・システム依存のファイルで初期化パラメータが検索されます。TSPITRの実行時、Recovery Managerでは、常に、自動補助インスタンスのデフォルト・パラメータが検索されます。ファイルが検出されない場合でも、Recovery Managerでエラーは発生しません。かわりに、Recovery Managerは、自動補助インスタンスに対して表20-3の基本初期化パラメータを定義します。
ほとんどの場合、特にRECOVER TABLESPACEにAUXILIARY DESTINATION引数を指定している場合は、パラメータ・ファイルを変更する必要はあません。表20-3の初期化パラメータのいずれかを不適切な値で上書きすると、補助インスタンスで問題が発生し、TSPITRが失敗する場合があります。ただし、これらの基本パラメータ以外に、その他のパラメータも必要に応じて追加できます。たとえば、DB_FILE_NAME_CONVERTを使用して補助セットのデータファイルの名前を指定できます。
自動補助インスタンスのパラメータを指定するもう1つの方法として、ファイルに初期化パラメータを指定する方法があります。この場合、TSPITRを実行する前にSET AUXILIARY INSTANCE PARAMETER FILEコマンドを使用して、このファイルの場所を指定できます。SET AUXILIARY INSTANCE PARAMETERを使用して指定したパスは、ターゲット・インスタンスまたは補助インスタンスではなく、Recovery Managerクライアントが実行されるシステム上のパスであることに注意してください。
初期化パラメータ・ファイルを使用すると、補助インスタンスの制御ファイルに対して独自の格納場所を指定できます。CONTROL_FILES初期化パラメータを設定して、制御ファイルの格納場所を指定します。
制御ファイルの格納場所を明示的に指定しない場合、TSPITR実行時にAUXILIARY DESTINATIONパラメータを使用すると、Recovery Managerは、そのファイルを補助格納場所に格納します。AUXILIARY DESTINATIONを使用しない場合、補助インスタンスの制御ファイルは、オペレーティング・システム固有の場所に格納されます
格納場所にかかわらず、補助インスタンスの制御ファイルは、TSPITR操作が正常に実行された後に削除されます。制御ファイルはサイズが比較的小さいため、補助制御ファイルの作成時に問題が発生することはほとんどありません。ただし、制御ファイルを作成するための十分な領域がない場合、TSPITRは失敗します。
補助インスタンスのパラメータ・ファイルでLOG_FILE_NAME_CONVERT初期化パラメータを指定すると、このパラメータによってオンラインREDOログの格納場所が決定されます。このパラメータを指定しない場合、Recovery Managerによって補助の格納場所が使用され、補助インスタンスが管理されているときは、補助格納場所にオンラインREDOログが作成されます。
LOG_FILE_NAME_CONVERTまたはAUXILIARY DESTINATIONを使用してオンラインREDOログの格納場所を指定しない場合は、TSPITRでオンラインREDOログが作成されません。初期化パラメータ・ファイルにDB_CREATE_FILE_DESTまたはLOG_FILE_CREATE_DESTが指定されている場合でも、TSPITRの実行時に、補助インスタンスのオンラインREDOログの作成は制御されません。
通常、Recovery ManagerのTSPITRの実行時に使用する補助インスタンスの作成および削除は、Recovery Managerによって管理する必要があります。ただし、ユーザーは、独自の補助インスタンスを作成および使用することもできます。
ユーザー独自のインスタンスを作成する理由の1つとして、TSPITRで使用されるチャネルを制御できることがあげられます。自動補助インスタンスでは、ターゲット・データベースの構成済チャネルが、補助インスタンスで構成されてリストア中に使用されるチャネルの基本チャネルとして使用されます。ターゲット・データベースの設定を変更するために、CONFIGUREを使用せずに異なるチャネルを設定する必要がある場合があります。この場合、独自の補助インスタンスを使用できます。
補助インスタンスとしての使用に適したOracleインスタンスを作成するには、次のすべての手順を実行する必要があります。
Oracleパスワード・ファイルを作成およびメンテナンスする方法については、『Oracle Database管理者ガイド』を参照してください。
テキスト・エディタを使用して、ターゲット・データベース・ホストで補助インスタンスの初期化パラメータ・ファイルを作成します。たとえば、パラメータ・ファイルが/tmp/initAux.oraに格納されていると想定します。表20-4で説明するように、パラメータを設定します。
| パラメータ | 必須かどうか | 値 |
|---|---|---|
|
|
必須 |
ターゲット・データベースと同じ名前。 |
|
|
必須 |
同じOracleホーム内のいずれのデータベースとも異なる値。簡略化するために、 |
|
|
必須 |
|
|
|
必須 |
ターゲット・データベースのパラメータと同じ値。 |
|
|
必須 |
補助インスタンスと同じ値（この初期化パラメータがターゲット・データベースで設定されている場合）。 |
|
|
必須 |
補助データベースのオンラインREDOログのファイル名を生成するパターン。ターゲット・データベースのオンラインREDOログ名に基づきます。 補助インスタンスのオンラインREDOログの名前は、このパラメータでのみ指定できます。このパラメータを指定しない場合は、オンライン・ログを作成できないため、補助インスタンスのオープン時にTSPITRが失敗します。
注意: 末尾にスラッシュ（
参照: OMFファイル名を使用した |
|
|
任意 |
補助データベースのデータファイルのファイル名を変換するパターン。このパラメータを使用すると、
注意: 末尾にスラッシュ（ 参照: 「DB_FILE_NAME_CONVERTを使用した補助セットのデータファイル名の指定」を参照してください。 |
|
|
任意 |
ターゲット・インスタンス（または他の既存のファイル）の制御ファイル名と競合しないファイル名。 |
Oracle Netを介してSYSDBAとして接続するためのパラメータを含めて、その他のパラメータを必要に応じて設定します。
次に、TSPITRの補助インスタンスで設定可能な初期化パラメータの例を示します。
DB_NAME=trgt DB_UNIQUE_NAME=_trgt CONTROL_FILES=/tmp/control01.ctl DB_FILE_NAME_CONVERT=('/oracle/oradata/trgt/','/tmp/') LOG_FILE_NAME_CONVERT=('/oracle/oradata/trgt/redo','/tmp/redo') REMOTE_LOGIN_PASSWORDFILE=exclusive COMPATIBLE =11.0.0 DB_BLOCK_SIZE=8192
補助インスタンスには、有効なネット・サービス名が必要です。先に進む前に、SQL*Plusを使用して補助インスタンスにSYSDBAで接続できることを確認します。
独自の補助インスタンスを実行すると、TSPITRに必要な一連のコマンドが長くなる場合があります。この状況は、バックアップからのリストアに複雑なチャネル構成を割り当てたり、DB_FILE_NAME_CONVERTを使用せずにファイル名を指定した場合に発生する可能性があります。
TSPITRに使用する一連のコマンドは、Recovery Managerのコマンド・ファイルに格納できます。コマンド・ファイルにエラーがないかを慎重に確認します。このコマンド・ファイルをRecovery Managerに読み込むには、@コマンド（またはRecovery Managerの起動時にCMDFILEコマンドライン引数）を使用します。
次の例では、/tmp/tspitr.rmanというコマンド・ファイルを実行します。
@/tmp/tspitr.rman;
結果は、前述の例と同じになります。
独自の補助インスタンスを実行すると、デフォルトでターゲット・インスタンスの自動チャネル構成が使用されます。ただし、独自のチャネル構成を割り当てる場合は、RUNブロックにALLOCATE AUXILIARY CHANNELコマンドおよびTSPITR用のRECOVER TABLESPACEコマンドを含めます。必要に応じてこれらのコマンドの使用を計画し、TSPITRに使用する一連のコマンドに追加します。
SET NEWNAMEコマンドを使用して、補助セット・ファイルの既存のイメージ・コピーを参照してTSPITRのパフォーマンスを向上させるか、またはTSPITRの実行後にリカバリ・セット・ファイルに新しい名前を割り当てることができます。必要に応じてこれらのコマンドの使用を計画し、TSPITRに使用する一連のコマンドに追加します。
準備およびTSPITRコマンドの計画が完了すると、TSPITRを実行できます。次の手順を実行する必要があります。
Recovery ManagerのTSPITRを開始する前に、SQL*Plusを起動してSYSOPER権限で補助インスタンスに接続します。
補助インスタンスをNOMOUNTモードで起動し、必要に応じてパラメータ・ファイルを指定します。たとえば、次のSQL*Plusコマンドを入力します。
SQL> STARTUP NOMOUNT PFILE='/tmp/initAux.ora'
PFILEを指定する場合は、PFILEのパスに、SQL*Plusを実行するホスト上のクライアント側のパスを指定することに注意してください。
補助インスタンスに制御ファイルがないため、このインスタンスはNOMOUNTモードでのみ起動できます。制御ファイルを作成したり、TSPITR用の補助インスタンスをマウントまたはオープンしないでください。
Recovery Managerを起動し、ターゲット・データベースおよび手動で作成した補助インスタンスに接続します。
最も簡単な方法は、Recovery ManagerプロンプトでRECOVER TABLESPACE ... UNTILコマンドを実行する方法です。
RECOVER TABLESPACE ts1, ts2... UNTIL TIME 'time';
ALLOCATE AUXILIARY CHANNELコマンドまたはSET NEWNAMEコマンドを使用する場合は、RUNコマンドでRECOVER TABLESPACEコマンドの前にこれらのコマンドを指定します。次に、この方法の例を示します。
RUN { ALLOCATE AUXILIARY CHANNEL c1 DEVICE TYPE DISK; ALLOCATE AUXILIARY CHANNEL c2 DEVICE TYPE sbt; # and so on... RECOVER TABLESPACE ts1, ts2 UNTIL TIME 'time'; }
この項では、RECOVER TABLESPACE... UNTIL操作の実行例を示します。この実行例では、Recovery ManagerのTSPITRの次の機能について説明します。
SET NEWNAMEを使用した補助セットのデータファイルのリカバリ可能なイメージ・コピーの使用
SET NEWNAMEを使用したリカバリ・セットのデータファイルの新しい名前の指定
次の手順を実行するとします。
/bigtmp/init_tspitr_prod.oraを次のように設定します。
DB_NAME=PROD DB_UNIQUE_NAME=tspitr_PROD CONTROL_FILES=/bigtmp/tspitr_cntrl.dbf' DB_FILE_NAME_CONVERT=('?/oradata/prod', '/bigtmp') LOG_FILE_NAME_CONVERT=('?/oradata/prod', '/bigtmp') COMPATIBLE=11.0.0 BLOCK_SIZE=8192 REMOTE_LOGIN_PASSWORD=exclusive
pitprodを作成し、接続性を確認します。
SYSOPER権限で補助インスタンスに接続します。インスタンスをNOMOUNTモードで起動します。
SQL> STARTUP NOMOUNT PFILE=/bigtmp/init_tspitr_prod.ora
RUNブロック内で入力し、TSPITRを設定および実行します。
RUN { # Specify NEWNAMES for recovery set datafiles SET NEWNAME FOR DATAFILE '?/oradata/prod/clients01.dbf' TO '?/oradata/prod/clients01_rec.dbf'; SET NEWNAME FOR DATAFILE '?/oradata/prod/clients02.dbf' TO '?/oradata/prod/clients02_rec.dbf'; SET NEWNAME FOR DATAFILE '?/oradata/prod/clients03.dbf' TO '?/oradata/prod/clients03_rec.dbf'; SET NEWNAME FOR DATAFILE '?/oradata/prod/clients04.dbf' TO '?/oradata/prod/clients04_rec.dbf'; # Specified newnames for some of the auxiliary set # datafiles that have a valid image copy to avoid restores: SET NEWNAME FOR DATAFILE '?/oradata/prod/system01.dbf' TO '/backups/prod/system01_monday_noon.dbf'; SET NEWNAME FOR DATAFILE '?/oradata/prod/system02.dbf' TO '/backups/prod/system02_monday_noon.dbf'; SET NEWNAME FOR DATAFILE '?/oradata/prod/sysaux01.dbf' TO '/backups/prod/sysaux01_monday_noon.dbf'; SET NEWNAME FOR DATAFILE '?/oradata/prod/undo01.dbf' TO '/backups/prod/undo01_monday_noon.dbf'; # Specified the types of channels to use ALLOCATE AUXILIARY CHANNEL c1 DEVICE TYPE DISK; ALLOCATE AUXILIARY CHANNEL t1 DEVICE TYPE sbt; # Recovered the clients tablespace to 24 hours ago: RECOVER TABLESPACE clients UNTIL TIME 'sysdate-1'; }
コマンド・ファイルにこの一連のコマンドを格納し、コマンド・ファイルを実行することを検討してください。
TSPITR操作が正常に実行されると、結果は次のようになります。
SET NEWNAMEで指定した名前およびTSPITRの目標時点の内容で、ターゲット・データベースの制御ファイルに登録されます。
TSPITR操作が失敗すると、トラブルシューティングのために補助ファイルがディスクに残されます。Recovery Managerによって補助インスタンスが作成された場合、その補助インスタンスは停止します。それ以外の場合は、TSPITR操作が失敗したときの状態のまま残されます。
プロセスの完了前に、次のような様々な問題でTSPITRが失敗する可能性があります。
SET NEWNAMEまたはCONFIGURE AUXNAMEコマンドで割り当てられたファイル名と、DB_FILE_NAME_CONVERTパラメータの影響で生成されたファイル名の間で、名前の競合が発生する場合があります。
SET NEWNAME、CONFIGURE AUXNAMEおよびDB_FILE_NAME_CONVERTを使用したため、補助セットまたはリカバリ・セット内の複数のファイルに同じ名前が指定されたとします。この場合、Recovery Managerは、TSPITRの実行中にエラーをレポートします。この問題を解決するには、これらのパラメータに異なる値を使用して、重複する名前を排除します。
TSPITRの実行時、Recovery Managerには、TSPITRの目標時点においてどの表領域にUNDOセグメントが含まれていたかの情報が必要です。リカバリ・カタログが使用されている場合、通常、この情報はリカバリ・カタログから取得できます。
リカバリ・カタログが存在していないか、またはリカバリ・カタログで情報が検出されない場合を想定します。この場合、Recovery Managerは、目標時点でUNDOセグメントが含まれていた表領域のセットが、現在UNDOセグメントが含まれている表領域のセットと同じであるとみなします。この仮定が正しくない場合、TSPITRは失敗してエラーが表示されます。この場合は、UNDO TABLESPACE句を使用して、目標時点でのUNDOセグメントを表領域のリストに含めます。
独自の補助インスタンスを管理している場合に、TSPITRで障害が発生したとします。TSPITRを再試行する前に、補助インスタンスを停止し、TSPITRを中断させた問題を解決する必要があります。その後、補助インスタンスをNOMOUNTモードで起動してからTSPITRを再試行します。
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|