| Oracle® Databaseバックアップおよびリカバリ・リファレンス 11gリリース2(11.2) B56270-05 |
|
 前 |
 次 |
用途
RECOVERコマンドを使用すると、次の個々のタスクのいずれかを実行できます。
データベース全体、またはリストアされた1つ以上のデータファイルの完全リカバリを実行します。
データベースのPoint-in-Timeリカバリ(DBPITR)または表領域のPoint-in-Timeリカバリ(TSPITR)を実行します。
適宜ロールフォワードするように、増分バックアップをデータファイルのイメージ・コピー(リストアされたデータファイルではなく)に適用します。
データファイル内の破損したデータ・ブロックまたはその集合をリカバリします。
|
関連項目: データファイルのリカバリ方法は、『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によって、最も長い期間をカバーしているレベルが自動的に選択されます。
RESETLOGSを介したリカバリ
データファイルのリカバリを行う前に、RESTOREする必要があります。リカバリするデータファイルが親インカネーション由来のものである場合、RMANでは、RESETLOGS操作を介して透過的にリカバリできます。必要に応じて、RECOVERコマンドを使用して、以前のデータベース・インカネーションからアーカイブREDOログ・ファイルと増分バックアップをリストアおよび適用できます(これらのログが以前のリリースのOracle Databaseで生成されている場合でも)。
OPEN RESETLOGSを使用してリカバリを行う場合は、リカバリに必要なすべてのログが揃っていることを確認します。以前のデータベース・インカネーションでは、バックアップの時点からRESETLOGS SCNより番号が1少ないSCNまでのログが含まれている必要があります。また、このインカネーションの表には、データベース・バックアップの作成時からのRESETLOGS操作の完全な履歴が含まれている必要があります。V$DATABASE_INCARNATIONに完全なメタデータが見つからない場合は、欠落しているインカネーションからアーカイブREDOログ・ファイルにCATALOGを使用して、このメタデータを再作成できます。
|
関連項目: アーカイブREDOログ・ファイルをリストアするデフォルトの位置については、RESTOREコマンドを参照してください。高速リカバリ領域にログをステージングする場合、RMANは自動的にMAXSIZEオプションを指定します。 |
構文
recover::=
(deviceSpecifier::=、recoverObject::=、recoverOptionList::=)
recoverSpec::=
(recoverObject::=、blockObject::=、recoverOptionList::=)
(dbObject::=、blockObject::=、untilClause::=)
dbObject::=
blockObject::=
セマンティクス
| 構文要素 | 説明 |
|---|---|
DEVICE TYPE deviceSpecifier |
指定したデバイス・タイプ専用の自動チャネルを割り当てます。たとえば、自動ディスクおよびテープ・チャネルを構成してRECOVER DEVICE TYPE DISKを発行すると、RMANではディスク・チャネルのみが割り当てられます。
注意: チャネルを手動で割り当ててから、 関連項目: |
recoverSpec |
リカバリされるオブジェクトのタイプを指定します。 |
| 構文要素 | 説明 |
|---|---|
recoverObject |
リカバリされるオブジェクトのタイプを指定します。 |
blockObject |
ブロック・メディア・リカバリを使用してリカバリするブロックを指定します。 |
recoverOptionList |
リカバリ・オプションを指定します。 |
この副次句は、リカバリするファイルを指定します。構文図は、「recoverObject::=」を参照してください。
| 構文要素 | 説明 |
|---|---|
COPY OF dbObject |
ファイルの最近の増分バックアップと同じ時刻またはそれ以前の時刻にロールフォワードするために、増分バックアップを指定したイメージ・コピーに適用します。既存のイメージ・コピーは上書きされ、リカバリ中はファジー状態になります。RMANでは、イメージ・コピーのリカバリ後に自動バックアップを実行します。
このコマンドを使用すると、データファイル・コピーが更新されますが、このコマンドは、現行のデータファイルのメディア・リカバリではありません。このコマンドを 次の要件が満たされている必要があります。
操作を適用できる増分バックアップに対象となるコピーが複数ある場合は、RMANによって、適切なコピーが1つ選択される。 注意: RMANでは、指定された時刻にリカバリできない場合、エラーではなく警告が発行されます。これは、増分バックアップを使用できないためです。 |
WITH TAG tag_name |
ロールフォワードするイメージ・コピーを識別するタグ名を指定します。 |
DATAFILECOPY 'filename' |
増分バックアップを指定したデータファイルのイメージ・コピーに適用します(例3-4を参照)。RECOVER COPY OFの説明を参照してください。 |
dbObject |
リカバリを必要とするデータ・ブロックを指定します。
関連項目: |
SKIP |
メディア・リカバリ開始前に、指定された表領域にあるデータファイルをオフラインにします。これらのファイルは、メディア・リカバリが完了した後もオフラインのままです。
このオプションは、一時データのみが含まれている表領域のリカバリを行わないようにしたり、いくつかの表領域のリカバリを延期する場合に有効です。 |
FOREVER |
DROPオプションを使用してデータファイルをオフラインにします(例3-3を参照)。RESETLOGSオプションを使用してデータベースをオープンした後に、指定された表領域を削除する場合は、SKIP FOREVER TABLESPACEを使用します。
注意: 不完全リカバリを実行する場合は、 |
TABLESPACE tablespace_name |
オフラインにする表領域の名前を指定します。 |
TO RESTORE POINTrestore_point_name |
リストア・ポイントを作成した時点のSCNを上限として(上限値を含む)、RECOVERコマンドを終了するリストア・ポイントを指定します。上限値が含まれるため、RMANは、リストア・ポイントに対応するSCNまでリカバリできるファイルのみを選択します。 |
untilClause |
RECOVERコマンドを終了する過去の時刻、SCN、またはログ順序番号を指定します。
1つ以上の表領域で使用する場合、この句は指定された表領域のPoint-in-Timeリカバリ(TSPITR)操作を示します。また、 関連項目: |
この副次句は、データベースまたはデータベースのサブセットのいずれのリカバリを行うのかを指定します。構文図は、「dbObject::=」を参照してください。
| 構文要素 | 説明 |
|---|---|
DATABASE |
データベース全体のリカバリを指定します(例3-3を参照)。データベースはマウントする必要がありますが、オープンはしないでください。
デフォルトでは、 制御ファイルを失った後にリカバリを行う場合は、RMANでは、ディスク上のデータファイルの実際の位置を指すように制御ファイルを自動的に更新します(例3-5を参照)。 注意: RMANは、データファイルの追加用のREDOを検出すると、追加されるデータファイルを含む表領域がリカバリ中にスキップされないかぎり、新しいデータファイルを自動的に作成します。この自動作成は、バックアップの制御ファイルがリカバリされる前にリストアされ、バックアップの制御ファイルに最近追加されたデータファイルのレコードが存在しない場合に実行されます。 |
DATAFILE datafileSpec |
リカバリする1つ以上のデータファイルのリストをファイル名または絶対データファイル番号で指定します。ターゲット・データベースはマウントまたはオープン状態である必要があります。データベースがオープン状態の場合は、リカバリするデータファイルがオフラインである必要があります。
リカバリ・カタログを使用していない場合、ファイル名は制御ファイルに記録されているデータファイルの名前にする必要があります。リカバリ・カタログを使用している場合、制御ファイル内の名前が最近更新されている場合でも、データファイルのファイル名はカタログに記録された最新の名前にする必要があります。たとえば、制御ファイルでデータファイル名を変更後、カタログを再同期化する前にインスタンスで障害が発生したとします。 注意: データベース全体をある1つの時点にリカバリしたり、表領域をデータベースの残りの表領域とは異なるある時点にリカバリ(TSPITR)することはできますが、個々のデータファイルを異なる時点へ任意にリカバリすることはできません。TSPITRの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』で説明する手順を参照してください。 関連項目: |
TABLESPACEtablespace_name |
リカバリする1つ以上の表領域のリストを指定します(例3-1と例3-2を参照)。ターゲット・データベースはマウントまたはオープン状態である必要があります。データベースがオープン状態の場合は、リカバリする表領域がオフラインである必要があります。
注意: RMANは、データファイルの追加用のREDOを検出すると、新しいデータファイルを自動的に作成します。この自動作成は、バックアップの制御ファイルがリカバリされる前にリストアされ、バックアップの制御ファイルに最近追加されたデータファイルのレコードが存在しない場合に実行されます。 |
この副次句は、リカバリを必要とするデータ・ブロックを指定します。構文図は、「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リカバリなどの代替リカバリ方法、または影響を受けたオブジェクトの削除と再作成によって破損を修復する場合があります。
このビューには、ブロックとセグメント間の関係を検証して検出できても、個々のブロックのチェックでは検出できない破損については記録されません。 注意: ブロックが修復されたことを確定または検出するRMANコマンドはいずれも、 |
DATAFILE datafileSpecBLOCK integer TO integer |
データファイル内の個々のデータ・ブロックまたはその集合をリカバリします。スタンバイまたはプライマリ・データベースからブロックをコピーできます。TOの範囲は上限値および下限値を含むため、BLOCK 10 TO BLOCK 20の場合ブロック10とブロック20の両方とも含まれます。
ブロック・メディア・リカバリは、データ消失や破損がデータファイル全体ではなく少数のブロックに適用される場合に役立ちます。通常、ブロックの破損は
メディア破損マークが付いているブロックには、リカバリが完了するまでアクセスできません。 注意: 個々のブロックについて実行できるのは、完全リカバリのみです。つまり、すべてのREDOをブロックに適用する前に、リカバリを停止することはできません。 関連項目: |
TABLESPACE tablespace_nameDBA integer |
破損ブロックを含む表領域の名前または番号、および破損ブロックのデータ・ブロック・アドレス(DBA)を指定します。ブロック・メディア・リカバリの実行対象は、破損ブロックのみです。
注意: データファイルのヘッダー・ブロック(ブロック1)はリカバリできません。 |
この副次句は、各種のリカバリ・オプションを指定します。構文図は、「recoverOptionList::=」を参照してください。
| 構文要素 | 説明 |
|---|---|
ALLOW integer CORRUPTION |
リカバリ処理中に許容可能な破損ブロックの数を指定できます。REDOログが破損した場合に備えて、このパラメータを設定できます。 |
ARCHIVELOG TAG tag_name |
リカバリ中に使用するアーカイブ・ログ・バックアップ用のタグを指定します。タグ名には大/小文字区別がなく、すべて大文字で表示されます。リカバリに必要なすべてのアーカイブREDOログ・ファイルがタグ付きのバックアップに含まれていなければ、RMANは使用可能なバックアップから必要に応じてログまたは増分バックアップを使用します。 |
AUXILIARY DESTINATION'location' |
個々のファイルに対して別の位置が明示的に指定されていない場合は、TSPITRの実行中に作成される補助セットのデータファイル、制御ファイルおよびオンラインREDOログが作成された位置を指定します。
TSPITRで 関連項目: 補助の宛先の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のTSPITRに関する章を参照してください。 |
CHECK LOGICAL |
物理的な破損チェックを通過したデータ・ブロックと索引ブロックについて、行ピースまたは索引エントリの破損などの論理的な破損がないかどうか調べます。RMANは論理的な破損を見つけると、alert.logとサーバー・セッション・トレース・ファイルにそのブロックのログを書き込みます。
あるファイルで検出された物理的な破損と論理的な破損の合計数が |
DELETE ARCHIVELOG |
不要になったバックアップまたはコピーからリストアされたアーカイブREDOログ・ファイルを削除します。RMANは、RESTOREコマンドの開始前にディスク上に存在していたアーカイブREDOログ・ファイルは削除しません。MAXSIZEを指定しない場合、RMANでは、リストアされたアーカイブREDOログ・ファイルは適用後に削除されます。
注意: アーカイブREDOログ・ファイルを高速リカバリ領域にリストアする場合は、デフォルトで |
MAXSIZE sizeSpec |
リストアされたアーカイブREDOログ・ファイルには、sizeSpec以内のディスク領域を使用してください。リカバリにMAXSIZE値より大きいログのリストアが必要な場合は、MAXSIZE値を増やす必要があることを示すエラーがレポートされます。MAXSIZEがログを含むバックアップ・セットより小さい場合、RMANはログを抽出するためにバックアップ・セットを複数回読み込む必要があります。この場合、RMANによって、MAXSIZEを増やす必要があることを示す警告が発行されます。 |
EXCLUDE FLASHBACK LOG |
リストアするブロックを見つける場合にフラッシュバック・ログを検索しないように指定します。デフォルトでは、フラッシュバック・データベースが有効である場合に、RMANでフラッシュバック・ログを検索します。 |
EXCLUDE STANDBY |
リストアするブロックを見つける場合にフィジカル・スタンバイ・データベースを検索しないように指定します。Data Guard環境では、RMANはデフォルトでフィジカル・スタンバイ・データベースのブロックを検索します。 |
FROM BACKUPSET |
バックアップ・セットのみをリストアするように指定します。 |
FROM DATAFILECOPY |
データファイル・イメージ・コピーのみをリストアするように指定します。 |
FROM TAG tag_name |
リカバリ中に使用する増分バックアップ用のタグを指定します。リカバリに必要なすべての増分がタグ付きのバックアップに含まれていなければ、RMANは使用可能なバックアップから必要に応じてログまたは増分バックアップを使用します。タグ名には大/小文字区別がなく、すべて大文字で表示されます。
関連項目: 多重化バックアップ・セットの個別コピーにタグを適用する方法と、バックアップ・タグのデフォルトのファイル名形式については、 |
NOPARALLEL |
メディア・リカバリをパラレルで実行しないように指定します。RECOVERのデフォルトはパラレル実行です(RECOVER ... PARALLELオプションの説明を参照)。 |
NOREDO |
リカバリ中のREDOログの適用を抑止します。増分バックアップのみを適用します。
このオプションは、増分バックアップを使用して 注意: また、スタンバイ・データベースまたは複製データベースを更新する場合も使用できます。 |
PARALLEL |
パラレル・リカバリ(デフォルト)を指定します。
デフォルトでは、データベースでパラレルのメディア・リカバリを使用して、メディア・リカバリのロールフォワード・フェーズのパフォーマンスを向上させます。パラレル・リカバリのデフォルトの動作をオーバーライドするには、 メディアのパラレル・リカバリでは、ロールフォワード時に各データ・ブロックに別のプロセスを割り当てる分業体制を使用することで、操作の効率を高めています。プロセスの数は、 通常、リカバリはデータ・ブロックに対する読取りと書込み時にI/Oバウンドとなります。ブロック・レベルでパラレル化すると、リカバリによりI/O合計が増加する場合に、非同期I/Oでのオペレーティング・システム制限をなくすことなどによって、リカバリのパフォーマンスが改善されます。効率的な非同期I/Oが行われるシステムでは、パラレル・メディア・リカバリを使用してもあまりメリットはありません。 注意: 関連項目: |
integer |
並列度としてintegerを指定します。
各パラレル・スレッドでは、1つまたは2つのパラレル実行サーバーを使用します。通常、並列度は指定する必要がありません。 |
SKIP READONLY |
リカバリから読取り専用ファイルを除外します。 |
TEST |
試行リカバリを開始します。
試行リカバリは、標準リカバリの手順で問題が発生した場合に役立ちます。試行リカバリを使用すると、データベースでREDOの適用後を予測し、発生する可能性のある問題を検出できます。試行リカバリでは、標準リカバリと同じ方法でREDOを適用しますが、ディスクへの変更書込みは行わず、試行リカバリの後に変更をロールバックします。 注意: 最後の |
UNDO TABLESPACEtablespace_name |
ターゲット時刻にUNDOセグメントを持つ表領域のリストを指定します。RECOVER TABLESPACEでのみ使用可能です。
TSPITR中は、RMANではTSPITRターゲット時刻にUNDOセグメントがあったのはどの表領域かという情報が必要です。通常、この情報は、リカバリ・カタログを使用している場合はそのリカバリ・カタログにあります。 リカバリ・カタログがないか、リカバリ・カタログ内に情報がない場合、RMANでは、ターゲット時刻にUNDOセグメントを持つ一連の表領域が現在UNDOセグメントを持つ一連の表領域と同一である場合に続行します。これ以外の場合、TSPITRは失敗してエラーを返します。この場合は、 |
VALIDATE HEADER |
RMANがリカバリに必要なファイルのリストアに使用できるバックアップをレポートして検証します(リストアは行いません)。
関連項目: |
例3-1 オープン状態のデータベースでの表領域のリカバリ
表領域usersのデータファイルを格納しているディスクが、ハードウェアのエラーが原因で使用できなくなり、数分後に修復されたとします。この例では、表領域usersをオフラインにし、自動チャネルを使用してデータファイルをデフォルト位置にリストアしてリカバリ(テープからリストアされたログを削除)してから、この表領域をオンラインに戻します。
SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE"; RESTORE TABLESPACE users; RECOVER TABLESPACE users DELETE ARCHIVELOG MAXSIZE 2M; SQL "ALTER TABLESPACE users ONLINE";
例3-2 リストアしたデータファイルの新しい位置へのリカバリ
この例では、事前構成済のディスク・チャネルを使用し、ディスク上のデータファイルのコピーおよびテープのバックアップを使用するために1つのメディア管理チャネルを手動で割り当て、表領域usersにあるデータファイルを別の場所にリストアします。
RUN
{
ALLOCATE CHANNEL ch1 DEVICE TYPE sbt;
SQL "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;
SQL "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-07 Starting recover at 19-FEB-07 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-07 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-07 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-07
