用途
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では、次の検索順序を使用します。
ディスクまたはテープへの増分バックアップ・セット
ディスク上のアーカイブ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全体をリストアする必要がある場合があります。
構文
(deviceSpecifier::=, recoverObject::=, recoverOptionList::=)
(recoverObject::=, blockObject::=, recoverOptionList::=)
(remapTableList::=, sizeSpec::=)
remapTableList::=
セマンティクス
recover
構文要素 | 説明 |
---|---|
|
指定したデバイス・タイプ専用の自動チャネルを割り当てます。たとえば、自動ディスクおよびテープ・チャネルを構成して
注意: チャネルを手動で割り当ててから、 関連項目: 「 |
リカバリされるオブジェクトのタイプを指定します。 |
recoverSpec
構文要素 | 説明 |
---|---|
リカバリされるオブジェクトのタイプを指定します。 |
|
ブロック・メディア・リカバリを使用してリカバリするブロックを指定します。 |
|
リカバリ・オプションを指定します。 |
recoverObject
この副次句は、リカバリするファイルを指定します。構文図は、「recoverObject::=」を参照してください。
構文要素 | 説明 |
---|---|
|
ファイルの最近の増分バックアップと同じ時刻またはそれ以前の時刻にロールフォワードするために、増分バックアップを指定したイメージ・コピーに適用します。既存のイメージ・コピーは上書きされ、リカバリ中はファジー状態になります。RMANでは、イメージ・コピーのリカバリ後に自動バックアップを実行します。 このコマンドを使用すると、データファイル・コピーが更新されますが、このコマンドは、現行のデータファイルのメディア・リカバリではありません。このコマンドを 次の要件が満たされている必要があります。
操作を適用できる増分バックアップに対象となるコピーが複数ある場合は、RMANによって、適切なコピーが1つ選択される。 注意: RMANでは、指定された時刻にリカバリできない場合、エラーではなく警告が発行されます。これは、増分バックアップを使用できないためです。 |
|
ロールフォワードするイメージ・コピーを識別するタグ名を指定します。 |
|
増分バックアップを指定したデータファイルのイメージ・コピーに適用します(例3-4を参照)。 |
リカバリを必要とするデータ・ブロックを指定します。 |
|
|
増分バックアップを適用することによって一貫性のある状態にする必要がある外部データファイル・コピーの名前を指定します。これらの外部データファイル・コピーは、 |
|
FOREIGN DATAFILECOPYファイル名句を使用して指定された外部データファイル・コピーに適用する必要があるクロス・プラットフォーム増分バックアップを含むバックアップ・セットの名前を指定します。 クロス・プラットフォーム増分バックアップを適用するには、次の条件を満たす必要があります。
これらの条件が満たされない場合はエラーが発生し、クロス・プラットフォーム増分バックアップが外部データファイル・コピーに適用されません。 注意: 複数のバックアップ・セットで構成された増分バックアップを外部データファイルのセットに適用することはできません。 |
|
リカバリする必要がある表または表パーティションを指定します。ターゲット・データベースは、読取り/書込みモードである必要があります。
リカバリされた表をターゲット・データベースにインポートするときに、ターゲット・データベース内に同じ名前の表が存在する場合、エラー・メッセージが表示され、 パーティション表から特定のパーティションのみをリカバリした場合、各パーティションは別々の表としてターゲット・データベースにインポートされます。 例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)操作を示します。この句を 関連項目:「 |
dbObject
この副次句は、データベースまたはデータベースのサブセットのいずれのリカバリを行うのかを指定します。構文図は、「dbObject::=」を参照してください。
構文要素 | 説明 |
---|---|
|
データベース全体を指定します(例3-3を参照)。CDBの場合は、CDB全体を指定します。 CDBで、CDB全体をリカバリします。「CDBおよびPDBへの接続」の説明に従って、rootに接続し、CDB全体をバックアップします。 デフォルトでは、 制御ファイルを失った後にリカバリを行う場合は、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への接続」を参照してください。 |
|
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はデフォルトでフィジカル・スタンバイ・データベースのブロックを検索します。 |
|
バックアップ・セットのみをリストアするように指定します。この句は、ブロック・メディア・リカバリ実行時のみサポートされます。ブロック・メディア・リカバリを実行するには、 |
|
データファイルのイメージ・コピーのみをリストアします。 この句は、ブロック・メディア・リカバリ実行時のみサポートされます。ブロック・メディア・リカバリを実行するには、 |
|
クロス・プラットフォーム・バックアップが作成されたソース・プラットフォームの名前を指定します。指定したプラットフォーム名がクロス・プラットフォーム・バックアップ・ヘッダーに格納されているプラットフォーム識別子と一致する必要があります。 宛先データベースで変換が実行される場合、この句が必要です。( 注意: バックアップ・セットを使用するクロス・プラットフォーム・データ・トランスポートは、Oracle Database 12cリリース1 (12.1)以上でサポートされます。 FOREIGN DATAFILECOPY 'ファイル名'を参照してください。 関連項目: ソースおよび宛先プラットフォーム変換の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
リモート・データベースからネットワークを介して転送されたバックアップ・セットを使用してデータファイルをリカバリします。 「リモート・ホストからのファイルを使用したデータファイルと制御ファイルのリストア」を参照してください。 |
|
リカバリ中に使用する増分バックアップ用のタグを指定します。リカバリに必要なすべての増分がタグ付きのバックアップに含まれていなければ、RMANは使用可能なバックアップから必要に応じてログまたは増分バックアップを使用します。タグ名には大/小文字区別がなく、すべて大文字で表示されます。 関連項目: 多重化バックアップ・セットの個別コピーにタグを適用する方法と、バックアップ・タグのデフォルトのファイル名形式については、 |
|
メディア・リカバリをパラレルに実行しません。 |
|
リカバリ中のREDOログの適用を抑止します。増分バックアップのみを適用します。 このオプションは、増分バックアップを使用して 注意: また、スタンバイ・データベースまたは複製データベースを更新する場合も使用できます。 |
|
リカバリされた表または表パーティションをRMANがターゲット・データベースにインポートする必要がないことを指定します。 リカバリされたオブジェクトは、 必要に応じて、エクスポート・ダンプ・ファイルに含まれる表または表パーティションを明示的にターゲット・データベースにインポートする必要があります。データ・ポンプ・インポート・ユーティリティを使用して、リカバリされたオブジェクトをインポートします。 注意: |
|
パラレル・リカバリ(デフォルト)を指定します。 デフォルトでは、データベースでパラレルのメディア・リカバリを使用して、メディア・リカバリのロールフォワード・フェーズのパフォーマンスを向上させます。パラレル・リカバリのデフォルトの動作をオーバーライドするには、 メディアのパラレル・リカバリでは、ロールフォワード時に各データ・ブロックに別のプロセスを割り当てる分業体制を使用することで、操作の効率を高めています。プロセスの数は、 通常、リカバリはデータ・ブロックに対する読取りと書込み時にI/Oバウンドとなります。ブロック・レベルでパラレル化すると、リカバリによりI/O合計が増加する場合に、非同期I/Oでのオペレーティング・システム制限をなくすことなどによって、リカバリのパフォーマンスが改善されます。効率的な非同期I/Oが行われるシステムでは、パラレル・メディア・リカバリを使用してもあまりメリットはありません。 注意: 関連項目: |
|
並列度として 各パラレル・スレッドでは、1つまたは2つのパラレル実行サーバーを使用します。オプションです。 |
|
ターゲット・データベース内のリカバリされた表または表パーティションの名前を変更します。 パーティション表をリカバリするときに、表の一部のパーティションのみを再マップした場合、すべての表パーティションは別々の表としてインポートされます。 REMAPオプションを使用する場合、名前付きの制約と索引はインポートされません。 |
|
リカバリされた表または表パーティションを、それらがソース・データベース内で属した表領域とは異なる表領域にインポートします。
REMAPオプションを使用する場合、名前付きの制約と索引はインポートされません。 |
|
各ファイルを指定のセクション・サイズに分割して、検証をパラレル化します。 「SECTION SIZE sizeSpec」を参照してください。 |
|
リカバリから読取り専用ファイルを除外します。 |
|
試行リカバリを開始します。 試行リカバリは、標準リカバリの手順で問題が発生した場合に役立ちます。試行リカバリを使用すると、データベースでREDOの適用後を予測し、発生する可能性のある問題を検出できます。試行リカバリでは、標準リカバリと同じ方法でREDOを適用しますが、ディスクへの変更書込みは行わず、試行リカバリの終了時に変更をロールバックします。 注意: 最後の |
UNDO TABLESPACE tablespace_name |
ターゲット時刻にUNDOセグメントを持つ表領域のリストを指定します。 TSPITR中は、RMANではTSPITRターゲット時刻にUNDOセグメントがあったのはどの表領域かという情報が必要です。通常、この情報は、リカバリ・カタログを使用している場合はそのリカバリ・カタログにあります。 リカバリ・カタログがないか、リカバリ・カタログ内に情報がない場合、RMANでは、ターゲット時刻にUNDOセグメントを持つ一連の表領域が現在UNDOセグメントを持つ一連の表領域と同一である場合に続行します。この仮定が正しくない場合、TSPITRは失敗してエラーが表示されます。この場合は、 |
|
|
|
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
表領域に含まれていました。ただし、リカバリ操作後、これらはターゲット・データベース内の表領域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';