3.1 RECOVER
目的
RECOVER
コマンドを使用すると、次の個々のタスクのいずれかを実行できます。
-
データベース全体、またはリストアされた1つ以上のデータファイルの完全リカバリを実行します。
-
データベース(DBPITR)、プラガブル・データベース(PDB)、表領域(TSPITR)、表または表パーティションのPoint-in-Timeリカバリを実行します。
-
適宜ロールフォワードするように、増分バックアップをデータファイルのイメージ・コピー(リストアされたデータファイルではなく)に適用します。
-
データファイル内の破損したデータ・ブロックまたはその集合をリカバリします。
関連項目:
データファイルのリカバリ方法を学習するには、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
前提条件
リカバリに必要なすべてのREDOまたは増分の変更は、ディスクまたはSBTに存在している必要があります。RMANでリカバリ中に増分バックアップまたはアーカイブREDOログ・ファイルをリストアする必要がある場合は、構成済の自動チャネルを使用するか、またはそのバックアップを作成したものと同じタイプのチャネルを手動で割り当てる必要があります。
暗号化されているデータベースまたは表領域に対してメディア・リカバリを実行する場合は、メディア・リカバリを実行するときにOracleキーストアがオープンしている必要があります。暗号化されている表領域について学習するには、『Oracle Database管理者ガイド』を参照してください。
プリプラグイン・バックアップを使用して宛先CDB内のリカバリを実行するには、rootがオープンしている必要があります。また、SYSDBA
権限またはSYSBACKUP
権限を持つ共通ユーザーとしてrootに接続する必要があります。
共有のUNDOを使用するCDBの場合、1つ以上のPDBのPoint-in-Timeリカバリを実行するには、リストされたPDBを格納しているCDBのルートとシード・データベースのバックアップが使用できる必要があります。
PDB内の表領域のTSPITRを実行するには、PDBを格納しているCDBのルートとシード・データベース(PDB$SEED
)のバックアップが使用できる必要があります。
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では、次の検索順序を使用します。
-
ディスクまたはテープへの増分バックアップ・セット
-
ディスク上のアーカイブREDOログ・ファイル
-
ディスク上のアーカイブREDOログのバックアップ
-
テープ上のアーカイブREDOログのバックアップ・セット
RMANでアーカイブREDOログ・ファイルのリストア先を選択するときは、次の優先順位を使用します。
-
SET
ARCHIVELOG DESTINATION
-
値が
LOCATION=USE_DB_RECOVERY_FILE_DEST
に設定されているLOG_ARCHIVE_DEST_
n
パラメータ -
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
オプションを指定します。
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全体をリストアする必要がある場合があります。
疎データベースのリカバリ
COMPATIBLE
初期化パラメータが12.2以上に設定されている場合、RMANを使用して、マルチテナントおよび非CDBの疎データベースのPoint-in-Timeリカバリを実行することもできます。完全リカバリの場合、RMANはアーカイブREDOログ・ファイルおよびオンラインREDOログを適用して、データ・ファイルをリカバリします。したがって、FROM SPARSE
およびFROM NONSPARSE
句は完全リカバリに適用されません。Point-in-Timeリカバリの場合、RMANはまずデータ・ファイルをリストアしてから、それらをリカバリします。したがって、FROM SPARSE
およびFROM NONSPARSE
句はPITRに適用されます。
構文
(deviceSpecifier::=、recoverObject::=、recoverOptionList::=)
(recoverObject::=、blockObject::=、recoverOptionList::=)
(remapTableList::=、sizeSpec::=)
remapTableList::=
セマンティクス
recover
構文要素 | 説明 |
---|---|
|
指定したデバイス・タイプ専用の自動チャネルを割り当てます。たとえば、自動ディスクおよびテープ・チャネルを構成して
ノート: チャネルを手動で割り当ててから、 関連項目: |
リカバリされるオブジェクトのタイプを指定します。 |
recoverSpec
構文要素 | 説明 |
---|---|
リカバリされるオブジェクトのタイプを指定します。 |
|
ブロック・メディア・リカバリを使用してリカバリするブロックを指定します。 |
|
リカバリ・オプションを指定します。 |
recoverObject
この副次句は、リカバリするファイルを指定します。構文図は、「recoverObject::=」を参照してください。
構文要素 | 説明 |
---|---|
|
ファイルの最近の増分バックアップと同じ時刻またはそれ以前の時刻にロールフォワードするために、増分バックアップを指定したイメージ・コピーに適用します。既存のイメージ・コピーは上書きされ、リカバリ中はファジー状態になります。RMANでは、イメージ・コピーのリカバリ後に自動バックアップを実行します。 このコマンドを使用すると、データファイル・コピーが更新されますが、このコマンドは、現行のデータファイルのメディア・リカバリではありません。このコマンドを 次の要件が満たされている必要があります。
操作を適用できる増分バックアップに対象となるコピーが複数ある場合は、RMANによって、適切なコピーが1つ選択される。 ノート: RMANでは、指定された時刻にリカバリできない場合、エラーではなく警告が発行されます。これは、増分バックアップを使用できないためです。 |
|
ロールフォワードするイメージ・コピーを識別するタグ名を指定します。 |
|
増分バックアップを指定したデータファイルのイメージ・コピーに適用します(例3-4を参照)。 |
リカバリを必要とするデータ・ブロックを指定します。 |
|
|
増分バックアップを適用し、ロールフォワードしてから、フィジカル・スタンバイ・データベースを再起動します。リフレッシュする必要のあるスタンバイ・データベースを使用しているプライマリ・データベースは、 ターゲットとしてフィジカル・スタンバイ・データベースに接続し、 ノート: |
|
増分バックアップを適用することによって一貫性のある状態にする必要がある外部データ・ファイル・コピーの名前を指定します。これらの外部データ・ファイル・コピーは、 |
|
FOREIGN DATAFILECOPYファイル名句を使用して指定された外部データファイル・コピーに適用する必要があるクロス・プラットフォーム増分バックアップを含むバックアップ・セットの名前を指定します。 クロス・プラットフォーム増分バックアップを適用するには、次の条件を満たす必要があります。
これらの条件が満たされない場合はエラーが発生し、クロス・プラットフォーム増分バックアップが外部データ・ファイル・コピーに適用されません。 ノート: 複数のバックアップ・セットで構成される増分バックアップを外部データ・ファイルのセットに適用することはできません。 |
|
リカバリする必要がある表または表パーティションを指定します。ターゲット・データベースは、読取り/書込みモードである必要があります。 リカバリを実行する前に、RMANはリカバリ中に使用される補助インスタンスのファイルを格納するのに十分なスペースがターゲット・ホストにあるかをチェックします。十分なスペースがない場合、RMANはエラー・メッセージを表示して終了します。
リカバリされた表をターゲット・データベースにインポートするときに、ターゲット・データベース内に同じ名前の表が存在する場合、エラー・メッセージが表示され、 パーティション表から特定のパーティションのみをリカバリした場合、各パーティションは別々の表としてターゲット・データベースにインポートされます。 例3-8を参照してください |
|
CDB内の、リカバリする必要がある表または表パーティションが存在するPDBの名前。PDB内の表または表パーティションをリカバリするには、「CDBおよびPDBへの接続」の説明に従ってrootに接続する必要があります。 |
|
メディア・リカバリ開始前に、指定された表領域にあるデータファイルをオフラインにします。これらのファイルは、メディア・リカバリが完了した後もオフラインのままです。 このオプションは、一時データのみが含まれている表領域のリカバリを行わないようにしたり、いくつかの表領域のリカバリを延期する場合に有効です。 |
|
ノート: 不完全リカバリを実行する場合は、 |
TABLESPACE tablespace_name |
オフラインにする表領域の名前を指定します。 |
|
PDB内の表領域の名前。 |
|
Storage Snapshot Optimizationを使用して作成されたスナップショット・バックアップからの時間ベースのリカバリを指定します。date_stringはスナップショットが完了した時間で、RMANの
関連項目: スナップショット・システムの要件およびスナップショット時間を指定する方法の詳細は、「ストレージ・スナップショットを使用したリカバリ」を参照してください。 |
TO RESTORE POINT restore_point_name |
リストア・ポイントを作成した時点のSCNを上限として(上限値を含む)、 |
1つ以上の表領域で使用する場合、この句は指定された表領域のPoint-in-Timeリカバリ(TSPITR)操作を示します。この句を 関連項目: |
|
|
使用可能な最新のアーカイブREDOログおよびオンラインREDOログを特定し、ログが失われた時点にデータベースをリカバリします。
このオプションは、データベース全体のリカバリを実行する場合にのみ使用できます。 PDBのPoint-in-Timeリカバリを実行するには、SCNを指定してリカバリする必要があります。 |
dbObject
この副次句は、データベースまたはデータベースのサブセットのいずれのリカバリを行うのかを指定します。構文図は、「dbObject::=」を参照してください。
構文要素 | 説明 |
---|---|
|
データベース全体を指定します(例3-3を参照)。CDBの場合は、CDB全体を指定します。 CDBで、CDB全体をリカバリします。CDBおよびPDBへの接続の説明に従って、rootに接続し、CDB全体をバックアップします。 アプリケーション・コンテナで、アプリケーション・コンテナ全体を特定の時点にリカバリします。これには、アプリケーション・ルートに加え、このアプリケーション・ルートに属するすべてのアプリケーションPDBが含まれます。 デフォルトでは、 制御ファイルを失った後にリカバリを行う場合は、RMANでは、ディスク上のデータファイルの実際の位置を指すように制御ファイルを自動的に更新します(例3-5を参照)。 RMANは、データファイルの追加用のREDOを検出すると、追加されるデータファイルを含む表領域がリカバリ中にスキップされないかぎり、新しいデータファイルを自動的に作成します。これは、バックアップの制御ファイルがリカバリされる前にリストアされ、バックアップの制御ファイルに最近追加されたデータファイルのレコードが存在しない場合に実行されます。 |
|
CDB内のrootのみを指定します。「CDBおよびPDBへの接続」の説明に従って、rootに接続します。 アプリケーション・コンテナで、アプリケーション・ルートに属するオンライン・データ・ファイルをすべてリカバリします。 |
|
CDB内の1つ以上のPDBを指定します。他のPDBは影響を受けず、オープンして操作可能な状態のままにできます。複数のPDBを指定する場合は、カンマ区切りのリストを使用してください。この句を使用するには、rootに接続する必要があります。 完全リカバリを実行する場合は、rootに接続する必要はありません。PDBに対してPoint-In-Timeリカバリ、表のリカバリ、TSPITR、または複製のいずれかの操作を実行するには、rootに接続します。rootまたはPDBに接続するには、CDBおよびPDBへの接続を参照してください。 アプリケーション・コンテナで、 アプリケーションPDBをリカバリするには、 |
|
1つ以上のデータファイルのリストをファイル名または絶対データファイル番号で指定します。 ターゲット・データベースはマウントまたはオープン状態である必要があります。データベースがオープン状態の場合は、リカバリするデータファイルがオフラインである必要があります。 リカバリ・カタログを使用していない場合、ファイル名は制御ファイルに記録されているデータファイルの名前にする必要があります。リカバリ・カタログを使用している場合、制御ファイル内の名前が最近更新されている場合でも、データファイルのファイル名はカタログに記録された最新の名前にする必要があります。たとえば、制御ファイルでデータファイル名を変更後、カタログを再同期化する前にインスタンスで障害が発生したとします。 ノート: データベース全体をある1つの時点にリカバリしたり、表領域をデータベースの残りの表領域とは異なるある時点にリカバリ(TSPITR)することはできますが、個々のデータファイルを異なる時点へ任意にリカバリすることはできません。TSPITRの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』で説明する手順を参照してください。 関連項目: |
TABLESPACE tablespace_name |
1つ以上の表領域のリストを指定します。ターゲット・データベースはマウントまたはオープン状態である必要があります。データベースがオープン状態の場合は、リカバリする表領域がオフラインである必要があります。 CDBのrootに接続している場合は、rootの表領域を指定します。PDBに接続している場合は、PDBの表領域の名前を指定します。 CDBでは、rootに接続している場合は、rootの表領域の名前を指定し、PDBに接続している場合は、PDBの表領域の名前を指定します。 ノート: RMANは、データファイルの追加用のREDOを検出すると、新しいデータファイルを自動的に作成します。これは、バックアップの制御ファイルがリカバリされる前にリストアされ、バックアップの制御ファイルに最近追加されたデータファイルのレコードが存在しない場合に実行されます。 |
|
PDB内の表領域の名前。同じ名前の表領域が複数のPDBにある場合があります。名前の前の修飾子によって、表領域が一意に識別されます。この構文は、rootに接続している場合にのみ必要です。PDBに直接接続している場合は、 一般的な情報については、前述の |
blockObject
この副次句は、リカバリを必要とするデータ・ブロックを指定します。構文図は、 「blockObject::=」を参照してください。ブロック・メディア・リカバリに固有の前提条件については、「RECOVER BLOCKに固有の前提条件」を参照してください。
RECOVER CORRUPTION LIST
を使用してV$DATABASE_BLOCK_CORRUPTION
ビューに示されたすべてのブロックをリカバリするか、またはデータファイル番号とブロック番号または表領域とデータ・ブロック・アクセス(DBA)を指定できます。RMANで個々のブロックに対して実行できるのは、完全リカバリのみです。
デフォルトでは、フラッシュバック・データベースが有効である場合に、RMANはフラッシュバック・ログを検索して破損ブロックの正常なコピーを見つけます。デフォルトでは、ターゲット・データベースがData Guard環境に存在する場合、RECOVER BLOCK
コマンドによってフィジカル・スタンバイ・データベースからプライマリ・データベース(またはその逆)にブロックを自動的に取得できます。
構文要素 | 説明 |
---|---|
このビューには、ブロックとセグメント間の関係を検証して検出できても、個々のブロックのチェックでは検出できない破損については記録されません。 ノート: ブロックが修復されたことを確定または検出するRMANコマンドはいずれも、 |
|
|
データファイル内の個々のデータ・ブロックまたはその集合をリカバリします。スタンバイまたはプライマリ・データベースからブロックをコピーできます。 ブロック・メディア・リカバリは、データ消失や破損がデータファイル全体ではなく少数のブロックに適用される場合に役立ちます。通常、ブロックの破損は
メディア破損マークが付いているブロックには、リカバリが完了するまでアクセスできません。 ノート: 個々のブロックについて実行できるのは、完全リカバリのみです。つまり、すべてのREDOをブロックに適用する前に、リカバリを停止することはできません。 関連項目: |
TABLESPACE tablespace_name DBA integer |
破損ブロックを含む表領域の名前または番号、および破損ブロックのデータ・ブロック・アドレス(DBA)を指定します。ブロック・メディア・リカバリの実行対象は、破損ブロックのみです。 ノート: データファイルのヘッダー・ブロック(ブロック1)はリカバリできません。 |
|
PDB内の表領域の名前。同じ名前の表領域が複数のPDBにある場合があります。名前の前の修飾子によって、表領域が一意に識別されます。 一般的な情報については、前述の |
recoverOptionList
この副次句は、各種のリカバリ・オプションを指定します。構文図は、「recoverOptionList::=」を参照してください。
構文要素 | 説明 |
---|---|
|
リカバリ処理中に許容可能な破損ブロックの数を指定します。REDOログが破損したときのためにこのパラメータを設定できます。 |
|
リカバリ中に使用するアーカイブ・ログ・バックアップ用のタグを指定します。タグ名には大/小文字区別がなく、すべて大文字で表示されます。リカバリに必要なすべてのアーカイブREDOログ・ファイルがタグ付きのバックアップに含まれていなければ、RMANは使用可能なバックアップから必要に応じてログまたは増分バックアップを使用します。 |
AUXILIARY DESTINATION ' location ' |
個々のファイルに対して別の位置が明示的に指定されていない場合は、TSPITRの実行中に作成される補助セットのデータファイル、制御ファイルおよびオンラインREDOログが作成された位置を指定します。 TSPITRで PDBのPoint-In-Timeリカバリの実行中に補助の宛先が指定されていない場合、補助の宛先として高速リカバリ領域が使用されます。補助の宛先が指定されておらず、高速リカバリ領域も構成されていない場合、PDBのリカバリは失敗します。 関連項目: 補助の宛先の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のTSPITRに関する章を参照してください。 |
|
物理的な破損チェックを通過したデータ・ブロックと索引ブロックについて、行ピースまたは索引エントリの破損などの論理的な破損がないかどうか調べます。RMANは論理的な破損を見つけると、
あるファイルで検出された物理的な破損と論理的な破損の合計数が |
|
RMANバックアップからリカバリされる表または表パーティションを含むデータ・ポンプ・エクスポート・ダンプ・ファイルの場所を指定します。 データ・ポンプの格納場所を指定しない場合、RMANは、 |
|
不要になったバックアップまたはコピーからリストアされたアーカイブREDOログ・ファイルを削除します。RMANは、 ノート: アーカイブREDOログ・ファイルを高速リカバリ領域にリストアする場合は、デフォルトで |
|
リストアされたアーカイブREDOログ・ファイルには、 |
|
リカバリされた表または表パーティションを含むデータ・ポンプ・エクスポート・ダンプ・ファイルの名前を指定します。ダンプ・ファイルの名前を指定しない場合、RMANによってターゲット・データベースのオペレーティング・システムに基づくデフォルト名が割り当てられます。デフォルト名は
|
|
リストアするブロックを見つける場合にフラッシュバック・ログを検索しません。デフォルトでは、フラッシュバック・データベースが有効である場合に、RMANでフラッシュバック・ログを検索します。 |
|
リストアするブロックを見つける場合にフィジカル・スタンバイ・データベースを検索しません。Data Guard環境では、RMANはデフォルトでフィジカル・スタンバイ・データベースのブロックを検索します。 |
|
バックアップ・セットのみをリストアするように指定します。この句は、ブロック・メディア・リカバリ実行時のみサポートされます。ブロック・メディア・リカバリを実行するには、 |
|
データファイルのイメージ・コピーのみをリストアします。 この句は、ブロック・メディア・リカバリ実行時のみサポートされます。ブロック・メディア・リカバリを実行するには、 |
FROM SPARSE |
選択された疎バックアップからデータ・ファイルをリストアした後、アーカイブ・ログおよびREDOログからデータ・ファイルをリカバリします。RMANはまず疎バックアップからデータ・ファイルをリストアしてから、データ・ファイルをリカバリします。
ノート: この句は、Point-in-Timeリカバリを実行する場合にのみ使用できます。 |
FROM NONSPARSE |
特定の非疎データベースに対して従来の完全リカバリを実行します。最初に非疎バックアップからデータ・ファイルをリストアしてから、リカバリを行います。 ノート: この句は、Point-in-Timeリカバリを実行する場合にのみ使用できます。 |
|
クロス・プラットフォーム・バックアップが作成されたソース・プラットフォームの名前を指定します。指定したプラットフォーム名がクロス・プラットフォーム・バックアップ・ヘッダーに格納されているプラットフォーム識別子と一致する必要があります。 宛先データベースで変換が実行される場合、この句が必要です。( ネットワーク経由でリモート・データベースに接続してクロス・プラットフォームの表領域トランスポートを実行するには、 FOREIGN DATAFILECOPY 'ファイル名'を参照してください。 関連項目: ソースおよび宛先プラットフォーム変換の詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。 |
|
プリプラグイン増分バックアップとプリプラグイン・アーカイブREDOログ・バックアップを使用してPDBをリカバリします。PDBは、ソース非CDBまたは現在のCDBに接続されたPDBになります。 |
|
リモート・データベースからネットワークを介して転送されたバックアップ・セットを使用してデータファイルをリカバリします。 「リモート・ホストからのファイルを使用したデータファイルと制御ファイルのリストア」を参照してください。 ネットワーク経由でリモート・データベースに接続してクロス・プラットフォームの表領域トランスポートを実行するには、 |
NONLOGGED BLOCK |
物理スタンバイ・データベースで実行されると、
ターゲット・データベースが自動メモリー管理を使用せず、 関連項目: Oracle Data Guard概要および管理 関連項目: 『Oracle Database管理者ガイド』 関連項目: 『Oracle Databaseリファレンス』 |
|
リカバリ中に使用する増分バックアップ用のタグを指定します。リカバリに必要なすべての増分がタグ付きのバックアップに含まれていなければ、RMANは使用可能なバックアップから必要に応じてログまたは増分バックアップを使用します。タグ名には大/小文字区別がなく、すべて大文字で表示されます。 関連項目: 多重化バックアップ・セットの個別コピーにタグを適用する方法と、バックアップ・タグのデフォルトのファイル名形式について学習するには、「 |
|
メディア・リカバリをパラレルに実行しません。 |
|
リカバリ中のREDOログの適用を抑止します。増分バックアップのみを適用します。 このオプションは、増分バックアップを使用して ノート: また、スタンバイ・データベースまたは複製データベースを更新する場合も使用できます。 |
|
リカバリされた表または表パーティションをRMANがターゲット・データベースにインポートする必要がないことを指定します。 リカバリされたオブジェクトは、 必要に応じて、エクスポート・ダンプ・ファイルに含まれる表または表パーティションを明示的にターゲット・データベースにインポートする必要があります。データ・ポンプ・インポート・ユーティリティを使用して、リカバリされたオブジェクトをインポートします。 ノート: |
|
パラレル・リカバリ(デフォルト)を指定します。 デフォルトでは、データベースでパラレルのメディア・リカバリを使用して、メディア・リカバリのロールフォワード・フェーズのパフォーマンスを向上させます。パラレル・リカバリのデフォルトの動作をオーバーライドするには、 メディアのパラレル・リカバリでは、ロールフォワード時に各データ・ブロックに別のプロセスを割り当てる分業体制を使用することで、操作の効率を高めています。プロセスの数は、 通常、リカバリはデータ・ブロックに対する読取りと書込み時にI/Oバウンドとなります。ブロック・レベルでパラレル化すると、リカバリによりI/O合計が増加する場合に、非同期I/Oでのオペレーティング・システム制限をなくすことなどによって、リカバリのパフォーマンスが改善されます。効率的な非同期I/Oが行われるシステムでは、パラレル・メディア・リカバリを使用してもあまりメリットはありません。 ノート: 関連項目: 『Oracle Database SQL言語リファレンス』の |
|
並列度として 各パラレル・スレッドは、1、2個のパラレル実行サーバーを使用します。オプションです。 |
|
宛先CDBへのPDBのクロス・プラットフォーム・トランスポート中に、ソースCDB上のデータベース・ファイル名を宛先CDB上の対応するファイルにマッピングする方法を指定します。 ファイル名の変換に使用される文字列のペアを指定します。必要な数のソースと宛先の置換文字列のペアを使用できます。たとえば、次のように値を文字列パターンとして設定できます。
|
|
ターゲット・データベース内のリカバリされた表または表パーティションの名前を変更します。 リカバリされた表または表パーティションは最初に存在していたのとは異なるターゲット・データベース・スキーマにマッピングできます。表または表パーティションを別のスキーマにリカバリする際に、オブジェクトの名前を変更するか、または元のオブジェクト名を保持することもできます。指定されたすべてのオブジェクトを同じターゲット・スキーマにインポートするか別々のターゲット・スキーマにインポートすることもできます。 単一 パーティション表をリカバリするときに、表の一部のパーティションのみを再マップした場合、すべての表パーティションは別々の表としてインポートされます。 ノート: |
|
リカバリされた表または表パーティションを、それらがソース・データベース内で属した表領域とは異なる表領域にインポートします。
REMAPオプションを使用する場合、名前付きの制約と索引はインポートされません。 |
|
各ファイルを指定のセクション・サイズに分割して、検証をパラレル化します。 「SECTION SIZE sizeSpec」を参照してください。 |
|
リカバリから読取り専用ファイルを除外します。 |
|
試行リカバリを開始します。 試行リカバリは、標準リカバリの手順で問題が発生した場合に役立ちます。試行リカバリを使用すると、データベースでREDOの適用後を予測し、発生する可能性のある問題を検出できます。試行リカバリでは、標準リカバリと同じ方法でREDOを適用しますが、ディスクへの変更書込みは行わず、試行リカバリの終了時に変更をロールバックします。 ノート: 最後の |
UNDO TABLESPACE tablespace_name |
ターゲット時刻にUNDOセグメントを持つ表領域のリストを指定します。 TSPITR中は、RMANではTSPITRターゲット時刻にUNDOセグメントがあったのはどの表領域かという情報が必要です。通常、この情報は、リカバリ・カタログを使用している場合はそのリカバリ・カタログにあります。 リカバリ・カタログがないか、リカバリ・カタログ内に情報がない場合、RMANでは、ターゲット時刻にUNDOセグメントを持つ一連の表領域が現在UNDOセグメントを持つ一連の表領域と同一である場合に続行します。この仮定が正しくない場合、TSPITRは失敗してエラーが表示されます。この場合は、 |
|
|
|
PDBのクロス・プラットフォーム・トランスポートを異なる宛先CDBに対して実行します。PDBを宛先CDBに組み込むために必要なメタデータが含まれるXMLファイルは、 |
|
RMANがリカバリに必要なファイルのリストアに使用できるバックアップをレポートして検証します(リストアは行いません)。
関連項目: |
remapTableList
この副次句は、リカバリする必要がある表または表パーティションを指定します。
構文要素 | 説明 |
---|---|
|
リカバリされている表または表パーティションが含まれているスキーマの名前。 |
|
リカバリする必要がある表の名前。 |
|
リカバリする必要がある表パーティションの名前。 |
|
表および表パーティションをリカバリする必要がある対象のスキーマの名前。 |
|
ターゲット・データベース内のリカバリされた表または表パーティションの名前。 |
例
例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_TBS
表領域に含まれていました。ただし、リカバリ操作後、これらはターゲット・データベース内の表領域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_TBS':'MY_TBS';
例3-11 複数表の別々のスキーマへのリカバリ
この例では、表HR.EMPLOYEES
およびSH.CHANNELS
表を指定したSCNまでリカバリします。リカバリされたEMPLOYEES
表はEXAMPLESスキーマにマッピングされ、リカバリされたCHANNELS表はTEST
スキーマにマッピングされます。これらのスキーマはすでにターゲット・データベースに作成されています。CHANNELS
表はSALES_TBS
表領域に格納されていました。表は、リカバリされた後、表領域NEW_SALES_TBS
にマッピングされます。表リカバリ・プロセスの一部として作成された一時データベース・ファイルを格納するために補助の宛先が使用されます。
この表をリカバリするには、SYSTEM
、SYSAUX
、UNDO、HR
およびSH
表領域のバックアップが必要です。バックアップが作成されたときには、データベースをARCHIVELOG
モードにしておく必要があります。
RECOVER TABLE hr.employees, sh.channels UNTIL SCN 3456 REMAP TABLE hr.employees:examples.employees, sh.channels:test.channels REMAP TABLESPACE 'SALES_TBS':'NEW_SALES_TBS' AUXILIARY DESTINATION '/tmp/auxdest';
例3-12 表パーティションの別のスキーマへのリカバリ
この例では、SH
スキーマ内のパーティションSALES_H1_1997
およびSALES_H2_1997
を、SCNを使用して指定された特定の時点にリカバリします。パーティションの名前はそれぞれhistoric_sales_h1_1997
およびhistoric_sales_h2_1997
に変更されます。リカバリされたパーティションは、スキーマnew_sh
にインポートされ、ターゲット・データベースに置かれます。
パーティションがリカバリされるため、COMPATIBLE
は11.1.0以上に設定されます。指定したリカバリSCNでのSYSTEM
、SYSAUX
、UNDO
およびSH
表領域のバックアップが存在します。バックアップが作成されたときには、データベースをARCHIVELOG
モードにしておく必要があります。
RECOVER TABLE sh.sales:sales_h1_1997, sh.sales:sales_h2_1997 UNTIL SCN 810234878 REMAP TABLE sh.sales:sales_h1_1997:sh.historic_sales_h1_1997, sh.sales:sales_h2_1997:sh.historic_sales_h2_1997 AUXILIARY DESTINATION '/tmp/auxdest/';
例3-13 宛先CDBに対するPDBのクロス・プラットフォーム・バックアップのリカバリ
この例では、PDB pdb2
のクロス・プラットフォーム一貫性増分レベル1バックアップを宛先データベースにリカバリします。宛先CDBおよびソースCDBは異なるプラットフォーム上にありますが、同じエンディアン形式を使用しています。
USING
句は、PDBを宛先CDBに組み込むために必要なメタデータが含まれるXMLファイルの名前を指定します。FOREIGN DATAFILECOPY
句は、このPDBのデータ・ファイルがリストアされたときに作成されたデータ・ファイルをすべてリストします。リカバリは、これらすべてのデータ・ファイルに対して実行する必要があります。FILE_NAME_CONVERT
句は、ソースCDB上のファイル名を宛先CDB上で変更する方法を指定します
RECOVER
FROM PLATFORM 'Linux x86 64-bit’
USING '/u02/backup_restore/metadata_pdb2.xml’
FILE_NAME_CONVERT = ('/u01/oradata','/u02/oradata/cdb')
FOREIGN DATAFILECOPY '/u02/oradata/pdb1.dbf’,’/u02/oradata/pdb1_tmp.dbf’
FROM BACKUPSET '/u02/backup_restore/bkup_level1_pdb1.bck’;