RECOVER

用途

RECOVERコマンドを使用すると、次の個々のタスクのいずれかを実行できます。

• データベース全体、またはリストアされた1つ以上のデータファイルの完全リカバリを実行します。

• データベース(DBPITR)、プラガブル・データベース(PDB)、表領域(TSPITR)、表または表パーティションのPoint-in-Timeリカバリを実行します。

• 適宜ロールフォワードするように、増分バックアップをデータファイルのイメージ・コピー(リストアされたデータファイルではなく)に適用します。

• データファイル内の破損したデータ・ブロックまたはその集合をリカバリします。

関連項目:

データファイルのリカバリ方法は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

前提条件

リカバリに必要なすべてのREDOまたは増分の変更は、ディスクまたはSBTに存在している必要があります。RMANでリカバリ中に増分バックアップまたはアーカイブREDOログ・ファイルをリストアする必要がある場合は、構成済の自動チャネルを使用するか、またはそのバックアップを作成したものと同じタイプのチャネルを手動で割り当てる必要があります。

暗号化されている表領域に対してメディア・リカバリを実行する場合は、この表領域のメディア・リカバリを実行するときにOracleキーストアがオープンしている必要があります。暗号化されている表領域については、『Oracle Database管理者ガイド』を参照してください。

RECOVER BLOCKに固有の前提条件

RECOVER BLOCKには次の前提条件が適用されます。

• ターゲット・データベースは、ARCHIVELOGモードで実行され、現行の制御ファイルを使用してオープンまたはマウントされている必要があります。

• RMANでのリカバリ実行対象は、メディア破損マークが付いているブロックのみです。V$DATABASE_BLOCK_CORRUPTIONビューは、ファイルに対して最新のBACKUPまたはBACKUP ... VALIDATEコマンドの実行以降にファイル内で破損としてマークされたブロックを示します。

• 破損ブロックを含むデータファイルのバックアップは、プロキシ・バックアップではなく、全体バックアップである必要があります。プロキシ・バックアップしか存在しない場合に、それをディスク上のデフォルト以外の場所にリストアすると、RMANではリストアされたファイルがデータファイルのコピーとして認識されます。このデータファイルのコピーを、ブロック・メディア・リカバリに使用できます。

• RMANでリカバリに使用できるのはアーカイブREDOログ・ファイルのみです。ブロック・メディア・リカバリでは、欠落しているかアクセス不能なログは残りませんが、欠落しているかアクセス不能なレコードは残る場合があります(『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照)。

• RMANでフラッシュバック・ログを検索して破損ブロックの正常なコピーを見つけられるようにする場合は、ターゲット・データベースに対してフラッシュバック・データベースを有効にする必要があります。

• RMANでスタンバイ・データベースを検索して破損ブロックの正常なコピーを見つけられるようにする場合は、ターゲット・データベースがData Guard環境のフィジカル・スタンバイ・データベースに関連付けられている必要があります。また、フィジカル・スタンバイ・データベースが読取り専用の管理リカバリ・モードでオープンされている必要があります。

注意:

この操作を実行するには、アクティブなData Guardライセンスが必要です。

使用上の注意

デフォルトでは、RMANは完全なリカバリを実行します。Point-in-Timeリカバリの場合は、RUNコマンドのRESTOREとRECOVERの両方のコマンドの前にSET UNTILコマンドを入力して、両方のコマンドにUNTILの時刻が適用されるようにすることをお薦めします。データベースのリストア後にSET UNTILを実行すると、リストア済ファイルのタイムスタンプがターゲット時刻より後になるため、ターゲット時刻にデータベースのリカバリを実行できない場合があります。

注意:

不完全リカバリまたはバックアップ制御ファイルを使用したリカバリの後は、RESETLOGSオプションを指定してデータベースをオープンする必要があります。

増分バックアップおよびアーカイブREDOログ・ファイル

RECOVER BLOCKの場合を除き、RMANではリカバリに増分バックアップとアーカイブREDOログ・ファイルの両方を使用できます。RMANでは、次の検索順序を使用します。

1. ディスクまたはテープへの増分バックアップ・セット

2. ディスク上のアーカイブREDOログ・ファイル

3. ディスク上のアーカイブREDOログのバックアップ

4. テープ上のアーカイブREDOログのバックアップ・セット

RMANでアーカイブREDOログ・ファイルのリストア先を選択するときは、次の優先順位を使用します。

1. SET ARCHIVELOG DESTINATION

2. 値がLOCATION=USE_DB_RECOVERY_FILE_DESTに設定されているLOG_ARCHIVE_DEST_nパラメータ

3. LOG_ARCHIVE_DEST_1

RMANでは、増分バックアップからリストアされなかったデータファイルに増分バックアップを適用できます。増分バックアップのオーバーラップしているレベルが存在する場合は、RMANによって、最も長い期間をカバーしているレベルが自動的に選択されます。

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

ストレージ・スナップショットの最適化により、サード・パーティのテクノロジを使用して、データベースまたは関連データファイルをBACKUPモードにしなくても、ストレージ・スナップショットを作成できます。ストレージ・スナップショットを使用してデータベースをリカバリする場合は、SNAPSHOT TIMEオプションを指定します。

関連項目:

スナップショット時間の指定の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

リカバリ操作に使用する場合、スナップショットは次の要件に準拠する必要があります。コンプライアンスの保証をベンダーに依頼します。

• データベースは、スナップショットの間、クラッシュ一貫性が保持される。

• スナップショットは、各ファイルの書込み順序を保持する。

• スナップショット・テクノロジによって、スナップショットが完了した時間が格納される。

注意:

データベース・スナップショットが使用可能であることを確認してください。スナップショットの間に構造変更が行われた場合、Oracle Databaseはリカバリにスナップショットを使用しません。SQL操作の中には、データベースの構造を変更できるものがあり、そのようなSQLはスナップショットの途中では使用しないでください。そのような操作のいくつかの例は、OFFLINE、ONLINE、READONLY、DROP、RENAME、SHRINKおよびADD句です。

関連項目:

データベース構造を変更する句の詳細は、『Oracle Database SQL言語リファレンス』のALTER DATABASEコマンドおよびALTER TABLESPACEコマンドを参照してください

RESETLOGSを介したリカバリ

データファイルのリカバリを行う前に、RESTOREする必要があります。リカバリするデータファイルが親インカネーション由来のものである場合、RMANでは、RESETLOGS操作を介して透過的にリカバリできます。必要に応じて、RECOVERコマンドを使用して、以前のデータベース・インカネーションからアーカイブREDOログ・ファイルと増分バックアップをリストアおよび適用できます(これらのログが以前のリリースのOracle Databaseで生成されている場合でも)。

OPEN RESETLOGSを使用してリカバリを行う場合は、リカバリに必要なすべてのログが揃っていることを確認します。以前のデータベース・インカネーションでは、バックアップの時点からRESETLOGS SCNより番号が1少ないSCNまでのログが含まれている必要があります。また、このインカネーションの表には、データベース・バックアップの作成時からのRESETLOGS操作の完全な履歴が含まれている必要があります。V$DATABASE_INCARNATIONに完全なメタデータが見つからない場合は、欠落しているインカネーションからアーカイブREDOログ・ファイルにCATALOGを使用して、このメタデータを再作成できます。

関連項目:

アーカイブREDOログ・ファイルをリストアするデフォルトの位置については、RESTOREコマンドを参照してください。高速リカバリ領域にログをステージングする場合、RMANは自動的にMAXSIZEオプションを指定します。

CDBおよびPDBのリカバリ

RMANでは、マルチテナント・コンテナ・データベース(CDB)全体、root、1つ以上のPDB、およびrootまたはPDBの表領域をリカバリできます。PDBおよびCDBでは完全リカバリまたはPoint-in-Timeリカバリを実行できます。ただし、rootを特定の時点にリカバリすることはできません。

CDBおよびPDBのリカバリ手順は、非CDBの場合に似ています。違いは、CDBまたはPDBへの接続手順と使用するコマンドです。CDB全体、root、または複数のPDBをリカバリするには、rootに接続します。特定のPDBをリカバリするには、そのPDBに接続します。PDBをリカバリするには、RECOVER PLUGGABLE DATABASEコマンドを使用します。CDB全体をリカバリするには、RECOVER DATABASEコマンドを使用し、rootをリカバリするには、RECOVER DATABASE ROOTコマンドを使用します。

関連項目:

CDBおよびPDBへの接続の詳細は、「CONNECT」を参照してください

関連項目:

CDBおよびPDBのリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

Data Guard環境では、スタンバイ・データベースがプライマリ・データベースに追いつくように、プライマリ・データベースのPoint-in-Timeリカバリの後、CDB全体をリストアする必要がある場合があります。

構文

recover::=

図GUID-B0C02F16-077C-471A-BFC7-77448F879B78-print.epsの説明

(deviceSpecifier::=, recoverObject::=, recoverOptionList::=)

recoverSpec::=

図GUID-DC01C95D-2F3B-4444-BF4C-CAE836BBC4BC-print.epsの説明

(recoverObject::=, blockObject::=, recoverOptionList::=)

recoverObject::=

図GUID-5DB380A7-9329-45A9-89F5-3C3906971002-print.epsの説明

(dbObject, untilClause::=)

dbObject::=

図GUID-2019A0F8-3C0F-47D4-8512-3A3D8E33B579-print.epsの説明

blockObject::=

図GUID-C2E37654-1AB6-4B49-8A50-2C968BE4B7CF-print.epsの説明

(datafileSpec::=)

recoverOptionList::=

図GUID-AC4D94FA-9C1B-4B80-9798-7686C34C60C0-print.epsの説明

(remapTableList::=, sizeSpec::=)

remapTableList::=

図GUID-D3878820-F94A-4431-93AA-215E40B150E3-print.epsの説明

セマンティクス

recover

構文要素	説明
DEVICE TYPE deviceSpecifier	指定したデバイス・タイプ専用の自動チャネルを割り当てます。たとえば、自動ディスクおよびテープ・チャネルを構成してRECOVER DEVICE TYPE DISKを発行すると、RMANではディスク・チャネルのみが割り当てられます。 DEVICE TYPEオプションを指定する前に、CONFIGURE DEVICE TYPEコマンドを使用してデバイス・タイプを構成します(事前構成されるDISK以外)。 注意: チャネルを手動で割り当ててから、RECOVER DEVICE TYPEを実行することはできません。 関連項目: 「deviceSpecifier」を参照してください
recoverSpec	リカバリされるオブジェクトのタイプを指定します。

recoverSpec

構文要素	説明
recoverObject	リカバリされるオブジェクトのタイプを指定します。
blockObject	ブロック・メディア・リカバリを使用してリカバリするブロックを指定します。
recoverOptionList	リカバリ・オプションを指定します。

recoverObject

この副次句は、リカバリするファイルを指定します。構文図は、「recoverObject::=」を参照してください。

構文要素	説明
COPY OF dbObject	ファイルの最近の増分バックアップと同じ時刻またはそれ以前の時刻にロールフォワードするために、増分バックアップを指定したイメージ・コピーに適用します。既存のイメージ・コピーは上書きされ、リカバリ中はファジー状態になります。RMANでは、イメージ・コピーのリカバリ後に自動バックアップを実行します。 このコマンドを使用すると、データファイル・コピーが更新されますが、このコマンドは、現行のデータファイルのメディア・リカバリではありません。このコマンドをBACKUP... FOR RECOVER OF COPY構文と組み合せて使用すると、増分更新バックアップで計画が実装されます。 次の要件が満たされている必要があります。 リカバリする各データファイルのコピーが1つ以上存在する必要がある。 リカバリするイメージ・コピーより後に取られた増分バックアップが存在する必要がある。 操作を適用できる増分バックアップに対象となるコピーが複数ある場合は、RMANによって、適切なコピーが1つ選択される。 注意: RMANでは、指定された時刻にリカバリできない場合、エラーではなく警告が発行されます。これは、増分バックアップを使用できないためです。
WITH TAG tag_name	ロールフォワードするイメージ・コピーを識別するタグ名を指定します。
DATAFILECOPY 'filename'	増分バックアップを指定したデータファイルのイメージ・コピーに適用します(例3-4を参照)。RECOVER COPY OFの説明を参照してください。
dbObject	リカバリを必要とするデータ・ブロックを指定します。
FOREIGN DATAFILECOPY 'filename'	増分バックアップを適用することによって一貫性のある状態にする必要がある外部データファイル・コピーの名前を指定します。これらの外部データファイル・コピーは、ALLOW INCONSISTENT句とともにCONVERTまたはBACKUPコマンドを使用して、一貫性がないクロス・プラットフォーム・バックアップの間に作成されました。
FROM BACKUPSET 'filename'	FOREIGN DATAFILECOPYファイル名句を使用して指定された外部データファイル・コピーに適用する必要があるクロス・プラットフォーム増分バックアップを含むバックアップ・セットの名前を指定します。 クロス・プラットフォーム増分バックアップを適用するには、次の条件を満たす必要があります。 クロス・プラットフォーム増分バックアップの各データファイルの開始SCNは、外部データファイル・コピーの現在のチェックポイントSCNより小さい必要があります。 外部データファイル・コピーは変更できません。 たとえば、ターゲット・データベースに組み込み、読取り/書込みモードに変更してから、読取り専用モードに戻すことが行われていない必要があります。これにより、外部データファイル・コピー・ヘッダー内のデータベースIDとファイル番号が変更されます。 これらの条件が満たされない場合はエラーが発生し、クロス・プラットフォーム増分バックアップが外部データファイル・コピーに適用されません。 注意: 複数のバックアップ・セットで構成された増分バックアップを外部データファイルのセットに適用することはできません。
TABLE schema.table[:partition]	リカバリする必要がある表または表パーティションを指定します。ターゲット・データベースは、読取り/書込みモードである必要があります。 REMAP TABLEオプションを使用して、ターゲット・データベースにあるリカバリされた表または表パーティションに新しい名前を割り当てることができます。 リカバリされた表をターゲット・データベースにインポートするときに、ターゲット・データベース内に同じ名前の表が存在する場合、エラー・メッセージが表示され、REMAP TABLE句を使用して表の名前を変更する必要があることが示されます。 パーティション表から特定のパーティションのみをリカバリした場合、各パーティションは別々の表としてターゲット・データベースにインポートされます。REMAP TABLEを使用してリカバリされたオブジェクトの名前を変更しなかった場合は、表名とパーティション名の組合せを使用することで、RMANによって各表の名前が指定されます。リカバリされたオブジェクトの表名は、tablename_partitionnameという書式です。その名前を持つ表がターゲット・データベース内に存在する場合は、RMANによって、生成された表名の最後に_1が追加されます。その名前を持つ表も存在する場合、RMANでは、表名の最後に_2が追加されます(以降も同様です)。 例3-8を参照してください。
OF PLUGGABLE DATABASE pdb_name	CDB内の、リカバリする必要がある表または表パーティションが存在するPDBの名前。PDB内の表または表パーティションをリカバリするには、「CDBおよびPDBへの接続」の説明に従ってrootに接続する必要があります。
SKIP	メディア・リカバリ開始前に、指定された表領域にあるデータファイルをオフラインにします。これらのファイルは、メディア・リカバリが完了した後もオフラインのままです。 このオプションは、一時データのみが含まれている表領域のリカバリを行わないようにしたり、いくつかの表領域のリカバリを延期する場合に有効です。
FOREVER	DROPオプションを使用してデータファイルをオフラインにします(例3-3を参照)。RESETLOGSオプションを使用してデータベースをオープンした後に、指定された表領域を削除する場合は、SKIP FOREVER TABLESPACEを使用します。 注意: 不完全リカバリを実行する場合は、SKIPにFOREVERオプションが必要になります。
TABLESPACE tablespace_name	オフラインにする表領域の名前を指定します。
TABLESPACE pdb_name:tablespace_name	PDB内の表領域の名前。
SNAPSHOT TIME 'date_string'	Storage Snapshot Optimizationを使用して作成されたスナップショット・バックアップからの時間ベースのリカバリを指定します。date_stringはスナップショットが完了した時間で、RMANのTIME書式(NLS_DATE_FORMAT環境変数で定義)で指定します。 SNAPSHOT TIMEをUNTIL TIMEまたはUNTIL SCNと組み合せて、データベースのPoint-in-Timeリカバリ(DBPITR)を実行できます。ただし、特定の時刻またはSCNまでのDBPITRは、これらの時刻またはSCNが、指定したスナップショット完了時刻より後の場合にのみ実行できます。 関連項目: スナップショット・システムの要件およびスナップショット時間を指定する方法の詳細は、「ストレージ・スナップショットを使用したリカバリ」を参照してください。
TO RESTORE POINT restore_point_name	リストア・ポイントを作成した時点のSCNを上限として(上限値を含む)、RECOVERコマンドを終了するリストア・ポイントを指定します。上限値が含まれるため、RMANは、リストア・ポイントに対応するSCNまでリカバリできるファイルのみを選択します。
untilClause	RECOVERコマンドを終了する過去の時刻、SCN、またはログ順序番号を指定します。 1つ以上の表領域で使用する場合、この句は指定された表領域のPoint-in-Timeリカバリ(TSPITR)操作を示します。この句をRECOVER DATAFILEとともに、またはRECOVER DATABASEに使用しないでください(「使用上の注意」を参照)。データベースのPoint-in-Timeリカバリ(DBPITR)の後は、RESETLOGSオプションを指定してデータベースをオープンする必要があります。 関連項目:「untilClause」を参照してください

dbObject

この副次句は、データベースまたはデータベースのサブセットのいずれのリカバリを行うのかを指定します。構文図は、「dbObject::=」を参照してください。

構文要素	説明
DATABASE	データベース全体を指定します(例3-3を参照)。CDBの場合は、CDB全体を指定します。 CDBで、CDB全体をリカバリします。「CDBおよびPDBへの接続」の説明に従って、rootに接続し、CDB全体をバックアップします。 デフォルトでは、RECOVER DATABASEコマンドは、リカバリされる時点でNORMALモードでオフラインにされているファイルのリカバリは行いません。RMANは、NORMALモードでオフラインにされたファイルをそれ以上のチェックはしないで、除外します。 制御ファイルを失った後にリカバリを行う場合は、RMANでは、ディスク上のデータファイルの実際の位置を指すように制御ファイルを自動的に更新します(例3-5を参照)。 RMANは、データファイルの追加用のREDOを検出すると、追加されるデータファイルを含む表領域がリカバリ中にスキップされないかぎり、新しいデータファイルを自動的に作成します。これは、バックアップの制御ファイルがリカバリされる前にリストアされ、バックアップの制御ファイルに最近追加されたデータファイルのレコードが存在しない場合に実行されます。
DATABASE ROOT	CDB内のrootのみを指定します。「CDBおよびPDBへの接続」の説明に従って、rootに接続します。
PLUGGABLE DATABASE pdb_name	CDB内の1つ以上のPDBを指定します。他のPDBは影響を受けず、オープンして操作可能な状態のままにできます。複数のPDBを指定する場合は、カンマ区切りのリストを使用してください。この句を使用するには、rootに接続する必要があります。 完全リカバリを実行する場合は、rootに接続する必要はありません。PDBに対してPoint-In-Timeリカバリ、表のリカバリ、TSPITR、または複製のいずれかの操作を実行するには、rootに接続します。rootまたはPDBに接続するには、「CDBおよびPDBへの接続」を参照してください。
DATAFILE datafileSpec	1つ以上のデータファイルのリストをファイル名または絶対データファイル番号で指定します。 ターゲット・データベースはマウントまたはオープン状態である必要があります。データベースがオープン状態の場合は、リカバリするデータファイルがオフラインである必要があります。 リカバリ・カタログを使用していない場合、ファイル名は制御ファイルに記録されているデータファイルの名前にする必要があります。リカバリ・カタログを使用している場合、制御ファイル内の名前が最近更新されている場合でも、データファイルのファイル名はカタログに記録された最新の名前にする必要があります。たとえば、制御ファイルでデータファイル名を変更後、カタログを再同期化する前にインスタンスで障害が発生したとします。RECOVERコマンドでは、カタログに記録されている古いデータファイル名を指定する必要があります。 注意: データベース全体をある1つの時点にリカバリしたり、表領域をデータベースの残りの表領域とは異なるある時点にリカバリ(TSPITR)することはできますが、個々のデータファイルを異なる時点へ任意にリカバリすることはできません。TSPITRの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』で説明する手順を参照してください。 関連項目: 「datafileSpec」を参照してください
TABLESPACE tablespace_name	1つ以上の表領域のリストを指定します。ターゲット・データベースはマウントまたはオープン状態である必要があります。データベースがオープン状態の場合は、リカバリする表領域がオフラインである必要があります。 CDBのrootに接続している場合は、rootの表領域を指定します。PDBに接続している場合は、PDBの表領域の名前を指定します。 CDBでは、rootに接続している場合は、rootの表領域の名前を指定し、PDBに接続している場合は、PDBの表領域の名前を指定します。 注意: RMANは、データファイルの追加用のREDOを検出すると、新しいデータファイルを自動的に作成します。これは、バックアップの制御ファイルがリカバリされる前にリストアされ、バックアップの制御ファイルに最近追加されたデータファイルのレコードが存在しない場合に実行されます。
TABLESPACE pdb-name:tablespace_name	PDB内の表領域の名前。同じ名前の表領域が複数のPDBにある場合があります。名前の前の修飾子によって、表領域が一意に識別されます。この構文は、rootに接続している場合にのみ必要です。PDBに直接接続している場合は、TABLESPACE tablespace_nameを使用します。pdb-nameはPDBの名前です。 一般的な情報については、前述のTABLESPACEに関する説明を参照してください。

blockObject

この副次句は、リカバリを必要とするデータ・ブロックを指定します。構文図は、 「blockObject::=」を参照してください。ブロック・メディア・リカバリに固有の前提条件については、「RECOVER BLOCKに固有の前提条件」を参照してください。

RECOVER CORRUPTION LISTを使用してV$DATABASE_BLOCK_CORRUPTIONビューに示されたすべてのブロックをリカバリするか、またはデータファイル番号とブロック番号または表領域とデータ・ブロック・アクセス(DBA)を指定できます。RMANで個々のブロックに対して実行できるのは、完全リカバリのみです。

デフォルトでは、フラッシュバック・データベースが有効である場合に、RMANはフラッシュバック・ログを検索して破損ブロックの正常なコピーを見つけます。デフォルトでは、ターゲット・データベースがData Guard環境に存在する場合、RECOVER BLOCKコマンドによってフィジカル・スタンバイ・データベースからプライマリ・データベース(またはその逆)にブロックを自動的に取得できます。

構文要素	説明
CORRUPTION LIST	V$DATABASE_BLOCK_CORRUPTIONビューに一覧表示された物理破損ブロックをすべてリカバリします。ブロック・メディア・リカバリでは、一覧されているすべての論理破損ブロックを修復できない場合があります。これらの場合、表領域のPoint-in-Timeリカバリなどの代替リカバリ方法、または影響を受けたオブジェクトの削除と再作成によって破損を修復する場合があります。 V$DATABASE_BLOCK_CORRUPTIONビューに、RMANコマンド、ANALYZE、SQL問合せなどのOracle Databaseコンポーネントによって破損とマークされたブロックが表示されます。つまり、ORA-1578エラーが発生したプロセスはすべて、このビューにブロック破損が記録されます。このビューに行が追加されるのは、次の種類の破損の場合です。 物理的な破損(メディア破損と呼ばれることもあります)。データベースがブロックをまったく認識しない状態。チェックサムは無効になり、ブロック内はすべてゼロになるか、またはブロックのヘッダーとフッターが一致しません。 論理的な破損。ブロックには有効なチェックサムがあり、ヘッダーとフッターは一致しますが、内容に論理的な一貫性がありません。 このビューには、ブロックとセグメント間の関係を検証して検出できても、個々のブロックのチェックでは検出できない破損については記録されません。 注意: ブロックが修復されたことを確定または検出するRMANコマンドはいずれも、V$DATABASE_BLOCK_CORRUPTIONを更新します。たとえば、RMANは、ブロック・メディア・リカバリが正常に実行された後にリポジトリを更新します。BACKUP、RESTOREまたはVALIDATEコマンドは、ブロックが修復されていることを検出すると、修復されたブロックをビューから削除します。
DATAFILE datafileSpec BLOCK integer TO integer	データファイル内の個々のデータ・ブロックまたはその集合をリカバリします。スタンバイまたはプライマリ・データベースからブロックをコピーできます。TOの範囲は上限値および下限値を含むため、BLOCK 10 TO BLOCK 20の場合ブロック10とブロック20の両方とも含まれます。 ブロック・メディア・リカバリは、データ消失や破損がデータファイル全体ではなく少数のブロックに適用される場合に役立ちます。通常、ブロックの破損はADVISE FAILUREコマンドまたはトレース・ファイル内のエラー・メッセージによってレポートされます。ブロック・レベルのデータ消失の原因は、次のとおりです。 I/Oエラーによる軽度のデータ消失 ディスクに書き込まれるメモリーの破損 recoverOptionListからオプションを指定しない場合に、データベースでフラッシュバック・データベースが有効化されているときは、RECOVER BLOCKを使用して、最初にフラッシュバック・ログ、次にバックアップを検索し、リストアするブロックの正常なバージョンを見つけます。 メディア破損マークが付いているブロックには、リカバリが完了するまでアクセスできません。 注意: 個々のブロックについて実行できるのは、完全リカバリのみです。つまり、すべてのREDOをブロックに適用する前に、リカバリを停止することはできません。 関連項目: 「datafileSpec」を参照してください
TABLESPACE tablespace_name DBA integer	破損ブロックを含む表領域の名前または番号、および破損ブロックのデータ・ブロック・アドレス(DBA)を指定します。ブロック・メディア・リカバリの実行対象は、破損ブロックのみです。 注意: データファイルのヘッダー・ブロック(ブロック1)はリカバリできません。
TABLESPACE pdb-name:tablespace_name DBA integer	PDB内の表領域の名前。同じ名前の表領域が複数のPDBにある場合があります。名前の前の修飾子によって、表領域が一意に識別されます。pdb-nameはPDBの名前です。 一般的な情報については、前述のTABLESPACEに関する説明を参照してください。

recoverOptionList

この副次句は、各種のリカバリ・オプションを指定します。構文図は、「recoverOptionList::=」を参照してください。

構文要素	説明
ALLOW integer CORRUPTION	リカバリ処理中に許容可能な破損ブロックの数を指定します。REDOログが破損したときのためにこのパラメータを設定できます。
ARCHIVELOG TAG tag_name	リカバリ中に使用するアーカイブ・ログ・バックアップ用のタグを指定します。タグ名には大/小文字区別がなく、すべて大文字で表示されます。リカバリに必要なすべてのアーカイブREDOログ・ファイルがタグ付きのバックアップに含まれていなければ、RMANは使用可能なバックアップから必要に応じてログまたは増分バックアップを使用します。
AUXILIARY DESTINATION 'location'	個々のファイルに対して別の位置が明示的に指定されていない場合は、TSPITRの実行中に作成される補助セットのデータファイル、制御ファイルおよびオンラインREDOログが作成された位置を指定します。 TSPITRでAUXILIARY DESTINATIONを指定しない場合は、UNTIL句を使用してRECOVER TABLESPACEを実行する前に、補助セット・データファイル、制御ファイルおよびオンラインREDOログのそれぞれの名前を指定する必要があります。指定しない場合、TSPITRは失敗します。 PDBのPoint-In-Timeリカバリの実行中に補助の宛先が指定されていない場合、補助の宛先として高速リカバリ領域が使用されます。補助の宛先が指定されておらず、高速リカバリ領域も構成されていない場合、PDBのリカバリは失敗します。 関連項目: 補助の宛先の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のTSPITRに関する章を参照してください。
CHECK LOGICAL	物理的な破損チェックを通過したデータ・ブロックと索引ブロックについて、行ピースまたは索引エントリの破損などの論理的な破損がないかどうか調べます。RMANは論理的な破損を見つけると、alert.logとサーバー・セッション・トレース・ファイルにそのブロックのログを書き込みます。 SET MAXCORRUPTの設定値によって、ファイルに許容される物理的および論理的な破損の合計数が指定されます。デフォルトでは、MAXCORRUPTは0であるため、破損ブロックが存在する場合、メディア・リカバリは正常に実行されません。破損ブロックを含むリカバリを許容する場合は、MAXCORRUPTをメディア・リカバリが正常に実行されなくなる最小破損ブロック数に設定します。たとえば、1つの破損ブロックを許容するには、MAXCORRUPTを1に設定します。 あるファイルで検出された物理的な破損と論理的な破損の合計数がMAXCORRUPTの設定値以下の場合、RMANのコマンドは完了し、破損ブロック範囲がV$DATABASE_BLOCK_CORRUPTIONに移入されます。そうでない場合、このコマンドは、V$DATABASE_BLOCK_CORRUPTIONに移入を行わずに終了します。
DATAPUMP DESTINATION 'datapump_destination'	RMANバックアップからリカバリされる表または表パーティションを含むデータ・ポンプ・エクスポート・ダンプ・ファイルの場所を指定します。 データ・ポンプの格納場所を指定しない場合、RMANは、AUXILARY DESTINATIONで指定された格納場所にエクスポート・ダンプ・ファイルを作成します。補助の宛先が指定されていない場合、RMANはオペレーティング・システム固有のデフォルトの場所にダンプ・ファイルを作成します。Linuxでは、デフォルトの場所は$ORACLE_HOME/dbsです。Windowsでは、デフォルトの場所は%ORACLE_HOME\databaseです。
DELETE ARCHIVELOG	不要になったバックアップまたはコピーからリストアされたアーカイブREDOログ・ファイルを削除します。RMANは、RESTOREコマンドの開始前にディスク上に存在していたアーカイブREDOログ・ファイルは削除しません。MAXSIZEを指定しない場合、RMANでは、リストアされたアーカイブREDOログ・ファイルは適用後に削除されます。 注意: アーカイブREDOログ・ファイルを高速リカバリ領域にリストアする場合は、デフォルトでDELETE ARCHIVELOGオプションが使用可能になります。
MAXSIZE sizeSpec	リストアされたアーカイブREDOログ・ファイルには、sizeSpec以内のディスク領域を使用してください。リカバリにMAXSIZE値より大きいログのリストアが必要な場合は、RMANでは、MAXSIZE値を増やす必要があることを示すエラーがレポートされます。MAXSIZEがログを含むバックアップ・セットより小さい場合、RMANはログを抽出するためにバックアップ・セットを複数回読み込む必要があります。この場合、RMANによって、MAXSIZEを増やすように示す警告が発行されます。
DUMP FILE 'filename'	リカバリされた表または表パーティションを含むデータ・ポンプ・エクスポート・ダンプ・ファイルの名前を指定します。ダンプ・ファイルの名前を指定しない場合、RMANによってターゲット・データベースのオペレーティング・システムに基づくデフォルト名が割り当てられます。デフォルト名はtspitr_SID-of-clone_n.dmpです(SID-of-cloneはRMANによってリカバリに使用される補助データベースのOracle SID、nはランダムに生成された数です)。DATAPUMP DESTINATIONで指定された場所にダンプ・ファイルが作成されます。 DATAPUMP DESTINATIONに、DUMP FILEで指定されている名前のファイルが含まれる場合、リカバリ・プロセスは失敗します。 「DATAPUMP DESTINATION」も参照。
EXCLUDE FLASHBACK LOG	リストアするブロックを見つける場合にフラッシュバック・ログを検索しません。デフォルトでは、フラッシュバック・データベースが有効である場合に、RMANでフラッシュバック・ログを検索します。
EXCLUDE STANDBY	リストアするブロックを見つける場合にフィジカル・スタンバイ・データベースを検索しません。Data Guard環境では、RMANはデフォルトでフィジカル・スタンバイ・データベースのブロックを検索します。
FROM BACKUPSET	バックアップ・セットのみをリストアするように指定します。この句は、ブロック・メディア・リカバリ実行時のみサポートされます。ブロック・メディア・リカバリを実行するには、RECOVER ... BLOCKコマンドを使用します。
FROM DATAFILECOPY	データファイルのイメージ・コピーのみをリストアします。 この句は、ブロック・メディア・リカバリ実行時のみサポートされます。ブロック・メディア・リカバリを実行するには、RECOVER ... BLOCKコマンドを使用します。
FROM PLATFORM 'platform'	クロス・プラットフォーム・バックアップが作成されたソース・プラットフォームの名前を指定します。指定したプラットフォーム名がクロス・プラットフォーム・バックアップ・ヘッダーに格納されているプラットフォーム識別子と一致する必要があります。 宛先データベースで変換が実行される場合、この句が必要です。(BACKUPコマンドでTO PLATFORM句を使用することで)変換がソース・データベースで実行される場合、この句はオプションです。この句を省略した場合でも、FOREIGN DATAFILECOPY句とともにFROM BACKUPSET句を指定することで、クロス・プラットフォーム・バックアップをリカバリできます。 注意: バックアップ・セットを使用するクロス・プラットフォーム・データ・トランスポートは、Oracle Database 12cリリース1 (12.1)以上でサポートされます。 FOREIGN DATAFILECOPY 'ファイル名'を参照してください。 関連項目: ソースおよび宛先プラットフォーム変換の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
FROM SERVICE service_name	リモート・データベースからネットワークを介して転送されたバックアップ・セットを使用してデータファイルをリカバリします。service_nameは、リモート・データベースのサービス名を指定します。 「リモート・ホストからのファイルを使用したデータファイルと制御ファイルのリストア」を参照してください。
FROM TAG 'tag_name'	リカバリ中に使用する増分バックアップ用のタグを指定します。リカバリに必要なすべての増分がタグ付きのバックアップに含まれていなければ、RMANは使用可能なバックアップから必要に応じてログまたは増分バックアップを使用します。タグ名には大/小文字区別がなく、すべて大文字で表示されます。 関連項目: 多重化バックアップ・セットの個別コピーにタグを適用する方法と、バックアップ・タグのデフォルトのファイル名形式については、「BACKUP」を参照してください。
NOPARALLEL	メディア・リカバリをパラレルに実行しません。RECOVERのデフォルトはパラレル実行です(RECOVER ... PARALLELオプションの説明を参照)。
NOREDO	リカバリ中のREDOログの適用を抑止します。増分バックアップのみを適用します。 このオプションは、増分バックアップを使用してNOARCHIVELOGデータベースの全体バックアップを更新する場合に使用できます(例3-6を参照)。REDOログが使用できない場合は、NOREDOオプションが必須です。NOARCHIVELOGモードで運用されているデータベースのリカバリ時にNOREDOを指定しない場合、RMANはリカバリを終了してエラー・メッセージを発行します。 注意: NOARCHIVELOGモードで運用されているデータベースの増分バックアップは、一貫性のある停止後にのみ実行できます。 また、スタンバイ・データベースまたは複製データベースを更新する場合も使用できます。BACKUP INCREMENTAL FROM SCNコマンドで作成した増分バックアップは、スタンバイ・データベースまたは複製データベースで適用できます。スタンバイ・データベースの手順については、『Oracle Data Guard概要および管理』を参照してください。
NOTABLEIMPORT	リカバリされた表または表パーティションをRMANがターゲット・データベースにインポートする必要がないことを指定します。 リカバリされたオブジェクトは、DUMP FILEおよびDATAPUMP DESTINATIONを使用して指定されたデータ・ポンプ・エクスポート・ダンプ・ファイルに格納されます。これらの句が省略されている場合、エクスポート・ダンプ・ファイルはデフォルトの場所に作成されます。 必要に応じて、エクスポート・ダンプ・ファイルに含まれる表または表パーティションを明示的にターゲット・データベースにインポートする必要があります。データ・ポンプ・インポート・ユーティリティを使用して、リカバリされたオブジェクトをインポートします。 注意: NOTABLEIMPORTは、REMAP TABLE句やREMAP TABLESPACE句とともに使用できません。
PARALLEL	パラレル・リカバリ(デフォルト)を指定します。 デフォルトでは、データベースでパラレルのメディア・リカバリを使用して、メディア・リカバリのロールフォワード・フェーズのパフォーマンスを向上させます。パラレル・リカバリのデフォルトの動作をオーバーライドするには、NOPARALLELオプションを指定したRECOVERまたはRECOVER PARALLEL 0を使用します。 メディアのパラレル・リカバリでは、ロールフォワード時に各データ・ブロックに別のプロセスを割り当てる分業体制を使用することで、操作の効率を高めています。プロセスの数は、CPU_COUNT初期化パラメータで指定されます(デフォルトでは、システム上のCPUの数と同じです)。たとえば、パラレル・リカバリをCPU_COUNTが4のシステム上で実行して、1つのデータファイルのみがリカバリされた場合、生成された4つのプロセスがデータファイルからブロックを読み取り、REDOを適用します。 通常、リカバリはデータ・ブロックに対する読取りと書込み時にI/Oバウンドとなります。ブロック・レベルでパラレル化すると、リカバリによりI/O合計が増加する場合に、非同期I/Oでのオペレーティング・システム制限をなくすことなどによって、リカバリのパフォーマンスが改善されます。効率的な非同期I/Oが行われるシステムでは、パラレル・メディア・リカバリを使用してもあまりメリットはありません。 注意: RECOVERY_PARALLELISM初期化パラメータは、インスタンス・リカバリまたはクラッシュ・リカバリのみを制御します。メディア・リカバリは、RECOVERY_PARALLELISMに使用する値による影響は受けません。 関連項目: 『Oracle Database SQL言語リファレンス』のCREATE TABLEのPARALLEL句に関する説明を参照してください。
integer	並列度としてintegerを指定します。 各パラレル・スレッドでは、1つまたは2つのパラレル実行サーバーを使用します。オプションです。
REMAP TABLE	ターゲット・データベース内のリカバリされた表または表パーティションの名前を変更します。RECOVERコマンドのTABLE句にリストされていない表またはパーティションは再マップできません。 パーティション表をリカバリするときに、表の一部のパーティションのみを再マップした場合、すべての表パーティションは別々の表としてインポートされます。 REMAPオプションを使用する場合、名前付きの制約と索引はインポートされません。
REMAP TABLESPACE source_tablespace_name:target_tablespace_name	リカバリされた表または表パーティションを、それらがソース・データベース内で属した表領域とは異なる表領域にインポートします。 source_tablespace_nameは、ソース・データベース内で表または表パーティションが存在した表領域の名前を指し、target_tablespace_nameは、表または表パーティションのインポート先の表領域の名前を指します。 REMAPオプションを使用する場合、名前付きの制約と索引はインポートされません。
SECTION SIZE sizeSpec	各ファイルを指定のセクション・サイズに分割して、検証をパラレル化します。 「SECTION SIZE sizeSpec」を参照してください。
SKIP READONLY	リカバリから読取り専用ファイルを除外します。
TEST	試行リカバリを開始します。 試行リカバリは、標準リカバリの手順で問題が発生した場合に役立ちます。試行リカバリを使用すると、データベースでREDOの適用後を予測し、発生する可能性のある問題を検出できます。試行リカバリでは、標準リカバリと同じ方法でREDOを適用しますが、ディスクへの変更書込みは行わず、試行リカバリの終了時に変更をロールバックします。 注意: 最後のRESETLOGS操作以降に実行したバックアップをリストアする場合にのみ、この句を使用できます。それ以外の場合、データベースはエラーを戻します。
UNDO TABLESPACE tablespace_name	ターゲット時刻にUNDOセグメントを持つ表領域のリストを指定します。RECOVER TABLESPACEでのみ使用可能です。 TSPITR中は、RMANではTSPITRターゲット時刻にUNDOセグメントがあったのはどの表領域かという情報が必要です。通常、この情報は、リカバリ・カタログを使用している場合はそのリカバリ・カタログにあります。 リカバリ・カタログがないか、リカバリ・カタログ内に情報がない場合、RMANでは、ターゲット時刻にUNDOセグメントを持つ一連の表領域が現在UNDOセグメントを持つ一連の表領域と同一である場合に続行します。この仮定が正しくない場合、TSPITRは失敗してエラーが表示されます。この場合は、UNDO TABLESPACEを使用できます。
USING [COMPRESSED] BACKUPSET	USING COMPRESSED BACKUPSETが使用されている場合、リカバリされるファイルが、圧縮されたバックアップ・セットとしてリモート・データベースから転送される必要があることを指定します。デフォルトでは、RMANはバックアップ・セットとしてファイルを転送します。したがって、USING BACKUPSET句を使用しない場合でも、ファイルはバックアップ・セットとして転送されます。圧縮の実行には、RMAN構成の圧縮アルゴリズムが使用されます。RECOVERコマンドの前にSET COMPRESSION ALGORITHMを実行することによって、異なる圧縮アルゴリズムを使用できます。
VALIDATE HEADER	RMANがリカバリに必要なファイルのリストアに使用できるバックアップをレポートして検証します(リストアは行いません)。 RECOVERをVALIDATE HEADERとともに実行すると、RMANは、RESTORE ... PREVIEWオプションを指定した場合と同じ機能を実行します。ただし、RMANは、リストアおよびリカバリに必要なファイルのリストに加えて、バックアップ・ファイルのヘッダーを検証し、ファイルがディスク上にあるか、またはRMANリポジトリのメタデータに対応するメディア管理カタログにあるかを判別します。 関連項目: RESTORE ... PREVIEWオプションの説明を参照してください。

remapTableList

構文要素	説明
schema	ソース・データベース内のスキーマの名前
old_tablename	ソース・データベース内の表の名前
partition	ソース・データベース内の表パーティションの名前
new_tablename	表をリカバリした後のターゲット・データベース内の表の名前

例

例3-1 オープン状態のデータベースでの表領域のリカバリ

表領域usersのデータファイルを格納しているディスクが、ハードウェアのエラーが原因で使用できなくなり、数分後に修復されたとします。この例では、表領域usersをオフラインにし、自動チャネルを使用してデータファイルをデフォルト位置にリストアしてリカバリ(テープからリストアされたログを削除)してから、この表領域をオンラインに戻します。

ALTER TABLESPACE users OFFLINE IMMEDIATE;
RESTORE TABLESPACE users;
RECOVER TABLESPACE users DELETE ARCHIVELOG MAXSIZE 2M;
ALTER TABLESPACE users ONLINE;

例3-2 リストアしたデータファイルの新しい位置へのリカバリ

この例では、事前構成済のディスク・チャネルを使用し、ディスク上のデータファイルのコピーおよびテープのバックアップを使用するために1つのメディア管理チャネルを手動で割り当て、表領域USERSにあるデータファイルを別の場所にリストアします。

RUN
{  
  ALLOCATE CHANNEL ch1 DEVICE TYPE sbt;  
  ALTER TABLESPACE users OFFLINE IMMEDIATE;  
  SET NEWNAME FOR DATAFILE '/disk1/oradata/prod/users01.dbf' 
    TO '/disk2/users01.dbf';
  RESTORE TABLESPACE users;
  SWITCH DATAFILE ALL;
  RECOVER TABLESPACE users;
  ALTER TABLESPACE users ONLINE;
}

例3-3 バックアップ制御ファイルとリカバリ・カタログを使用したDBPITRの実行

すべてのデータファイル、すべての制御ファイル、およびアーカイブREDOログ58が、ディスク障害により消失したと仮定します。また、増分バックアップを取っていないと仮定します。使用可能なアーカイブREDOログ・ファイルでデータベースをリカバリする必要があります。表領域TOOLSは、最後にバックアップが実行される前から読取り専用であったため、リストアする必要はありません。RMANをターゲット・データベースおよびリカバリ・カタログに接続した後は、次のコマンドを発行します。

STARTUP FORCE NOMOUNT;
RUN
{  
  SET UNTIL SEQUENCE 40 THREAD 1;  # Recover database until log sequence 40 
  RESTORE CONTROLFILE;
  ALTER DATABASE MOUNT;
  RESTORE DATABASE SKIP TABLESPACE tools;
  RECOVER DATABASE SKIP TABLESPACE tools;
}
ALTER DATABASE OPEN RESETLOGS;

RMANは、データファイル8 (読取り専用表領域のデータファイル)のリストアおよびリカバリを自動的にスキップします。出力例の次の部分がスキップを示します。

using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=104 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
 
skipping datafile 8; already restored to file /disk1/oradata/prod/tools01.dbf
channel ORA_DISK_1: starting datafile backup set restore
.
.
.
Finished restore at 19-FEB-13 

Starting recover at 19-FEB-13
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1
datafile 8 not processed because file is read-only

例3-4 バックアップの増分更新

バックアップを増分更新することによって、データベースのイメージ・コピーの全体バックアップに伴うオーバーヘッドを避けると同時に、データベースのメディア・リカバリに必要な時間を最小限にすることもできます。この例では、先週中の任意のSCNまでリカバリを行うことができますが、1日分より多くのREDOを適用する必要がないようにできます。

次のスクリプトを毎日実行するとします。初回実行時には、スクリプトによって、指定したタグを使用してディスク上にデータベースのイメージ・コピーのバックアップが作成されます。2回目から7回目の実行では、データベースのレベル1の差分バックアップが作成されます。RMANでは、8回目以降の実行では、レベル1の増分が7日前に作成されたデータファイル・コピーに適用され、前日からの変更を含む新しいレベル1のバックアップが作成されます。

RUN
{
  RECOVER COPY OF DATABASE 
    WITH TAG 'incr_update' 
    UNTIL TIME 'SYSDATE - 7';
  BACKUP
    INCREMENTAL LEVEL 1 
    FOR RECOVER OF COPY WITH TAG 'incr_update'
    DATABASE;
}

例3-5 スタンバイ・データベースで制御ファイルを失った場合のリカバリ

スタンバイ・データベースdgprod3の制御ファイルが、メディア障害によって消失したとします。プライマリ・データベースおよびスタンバイ・データベースは、SBTストレージを共有します。プライマリ・データベースの制御ファイルのバックアップはテープ上に存在します。

RMANクライアントを起動し、TARGETとしてdgprod3に接続して、リカバリ・カタログに接続します。次のRMANコマンドは、スタンバイ・データベースで使用できる制御ファイルをリストアし、ファイル名をディスク上の既存ファイルに更新して、スタンバイ・データベースのリカバリを行います。

RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
RECOVER DATABASE;

これで、スタンバイ・データベースへのREDOの適用を開始できます。

例3-6 NOARCHIVELOGモードで運用されているデータベースのリカバリ

増分バックアップを適用することによって、制限された変更のリカバリをNOARCHIVELOGモードで実行されているデータベースに実行できます。NOARCHIVELOGモードで実行されるデータベースのすべてのバックアップと同様に、増分バックアップは一貫性のあるバックアップである必要があるので、データベースのオープン時にはデータベースをバックアップできません。

リカバリ・カタログを使用してデータベースprodをNOARCHIVELOGモードで実行するとします。日曜日の午後に、データベースを一貫した状態で停止し、テープにデータベースprodのレベル0のバックアップを作成します。水曜日と金曜日の午前3時に、データベースを一貫した状態で停止し、テープにレベル1の差分増分バックアップを作成します。

土曜日にメディア障害が発生し、データファイルの半分とすべてのオンラインREDOログが破損します。オンライン・ログが消失しているため、RECOVERコマンドでNOREDOオプションを指定する必要があります。このオプションを指定しない場合、RMANは、金曜日の増分バックアップを適用した後でREDOログを検索し、REDOログが検出されない場合にはエラー・メッセージを発行します。

RMANをprodおよびカタログ・データベースに接続した後、次のようにリカバリを実行します。

STARTUP FORCE NOMOUNT;
RESTORE CONTROLFILE;      # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE;         # restore data files from consistent backup
RECOVER DATABASE NOREDO;  # specify NOREDO because online redo logs are lost
ALTER DATABASE OPEN RESETLOGS;

リカバリしたデータベースには、金曜日の増分バックアップの時刻までの変更のみ反映されています。アーカイブREDOログ・ファイルが存在しないため、増分バックアップ後の変更をリカバリできません。

例3-7 データベース内のすべての破損ブロックのリカバリ

この例では、バックアップの妥当性チェックを実行してV$DATABASE_BLOCK_CORRUPTIONビューに移入し、このビューに記録された破損ブロックをリカバリします。両方のコマンドの出力例を示します。

RMAN> VALIDATE DATABASE;
 
Starting validate at 19-FEB-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
.
.
.
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1    FAILED 0              4070         57600           555975
  File Name: /disk1/oradata/prod/system01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       1              41550
  Index      0              7677
  Other      0              4303
.
.
.
RMAN> RECOVER CORRUPTION LIST;
 
Starting recover at 19-FEB-13
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=104 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
searching flashback logs for block images until SCN 547548
finished flashback log search, restored 1 blocks
 
starting media recovery
media recovery complete, elapsed time: 00:00:03
 
Finished recover at 19-FEB-13

例3-8 バックアップからの表パーティションのリカバリ

この例では、パーティションsales_2009およびsales_2010を表SALESから、ターゲット・データベースのSCNが34582であった時点までリカバリします。ソース・データベースでは、表はスキーマSHによって所有されています。これらのパーティションをターゲット・データベースにインポートしているときに、パーティションがhistoric_sales_2009およびhistoric_sales_2010という名前の表として作成されます。

RECOVER TABLE SH.SALES:SALES_2009, SH.SALES:SALES_2010
     UNTIL SCN 34582
     AUXILIARY DESTINATION '/tmp/oracle/recover'
     REMAP TABLE 'SH'.'SALES':'SALES_2009':'HISTORIC_SALES_2009', 'SH'.'SALES':'SALES_2010':'HISTORIC_SALES_2010';

例3-9 指定したログ順序への表のリカバリおよび表の名前変更

この例では、補助インスタンスを使用して、表EMPをSCOTTスキーマから、データベースのログ順序番号が5466であった時点までリカバリします。EMPは、リカバリされた後、名前MY_EMPを使用してターゲット・データベースにインポートされます。

RECOVER TABLE SCOTT.EMP
     UNTIL SEQUENCE 5466
     AUXILARY DESTINATION '/tmp/recover'
     REMAP TABLE 'SCOTT'.'EMP':'MY_EMP';

例3-10 指定した時刻までの異なる表領域への表のリカバリ

この例では、表EMPおよびDEPTをUNTIL TIME句で指定された時点までリカバリします。これらの表は、元々EXAMPLE表領域に含まれていました。ただし、リカバリ操作後、これらはターゲット・データベース内の表領域MY_TBSにマップされます。

RECOVER TABLE SCOTT.EMP, SCOTT.DEPT
      UNTIL TIME "TO_CHAR('12/23/2012 12:00:00','mm/dd/yyyy hh24:mi:ss')"
      AUXILIARY DESTINATION '/tmp/oracle/recover'
      REMAP TABLESPACE 'EXAMPLE':'MY_TBS';