RMANのデータ修復の概要

14 RMANのデータ修復の概要

この章では、データ修復を実行するために理解しておく必要がある一般的な概念について説明します。この章のトピックは、次のとおりです:

14.1 RMANのデータ修復の概要

「データ保護について」で説明されているように、バックアップおよびリカバリ計画の主な目的はデータの保護です。効果的で効率的な計画を立案するために重要な点は、データ修復の基本的な方法を理解することです。

14.1.1 データ修復が必要な問題について

Oracle Databaseの正常な稼働を停止させたり、データベースのI/O処理に影響を与える問題はいくつかありますが、通常、ユーザー・エラー、アプリケーション・エラーおよびメディア障害が発生した場合にのみDBAが介入する必要があります。

14.1.1.1 ユーザー・エラーについて

ユーザー・エラーは、アプリケーション・ロジックのエラーまたは誤操作のため、データベースのデータが誤って変更または削除された場合に発生します。

たとえば、ユーザーが間違ったデータベースにログインしてデータベースの表を削除した場合などです。ユーザー・エラーは、データベースの停止時間を発生させる最も大きな原因であるとみなされています。

14.1.1.2 アプリケーション・エラーについて

ソフトウェアの障害によってデータ・ブロックが破損する場合もあります。物理的な破損(メディア破損とも呼ばれる)の場合、ブロックがデータベースで認識されません。

14.1.1.3 メディア障害について

メディア障害は、通常の操作中に、データベースの外部の問題によってファイルに対する読取りまたは書込みができなくなった場合に発生します。

典型的なメディア障害としては、ディスク障害、データベース・ファイルの削除などがあります。メディア障害は、ユーザー・エラーまたはアプリケーション・エラーほど一般的ではありませんが、バックアップおよびリカバリ計画では、メディア障害に対する準備をしておく必要があります。

14.1.2 RMANのデータ修復方法について

RMANには、データ修復に複数の方法が用意されています。

予測する状況に基づいて、データの消失に対処するために次の表に示されている各オプションを組み込むことを検討した後、これらのオプションを使用できるようにデータベースを設定します。

表14-1 RMANのデータ修復方法

データ修復方法	説明	追加情報
データ・リカバリ・アドバイザ	このOracle Databaseインフラストラクチャを使用すると、障害を診断して対応する方法を提示し、自動的にその障害を修復できます。	「データ・リカバリ・アドバイザの概要」
論理フラッシュバック機能	このOracleフラッシュバック技術機能のサブセットを使用すると、過去の時点の個々のデータベース・オブジェクトまたはトランザクションを表示したり、個々のデータベース・オブジェクトまたはトランザクションを過去の時点まで巻き戻すことができます。この機能では、RMANを使用する必要はありません。	「Oracleフラッシュバック技術およびデータベースのPoint-in-Timeリカバリの概要」
Oracle Flashback Database	フラッシュバック・データベースとは、メディア・リカバリに類似したブロックレベルのリカバリ・メカニズムのことですが、通常、高速で、リストアするバックアップは必要としません。事前にフラッシュバック・ロギングを有効にすると、データファイルの古いコピーをバックアップからリストアせずに、データベース全体を前の状態に戻すことができます。データベースのフラッシュバック・ロギング用または保証付きリストア・ポイント用に高速リカバリ領域を構成しておく必要があります。	「Point-in-Timeリカバリおよびフラッシュバック機能の基本的な概念」
データファイル・メディア・リカバリ	この形式のメディア・リカバリでは、データファイルのバックアップをリストアし、アーカイブREDOログまたは増分バックアップを適用して、消失した変更をリカバリできます。データベース全体またはデータベースのサブセットのいずれかをリカバリすることができます。データファイルのメディア・リカバリは、最も汎用的な形式のリカバリで、物理的な破損および論理的な破損の両方から保護できます。	「データベースの完全リカバリの実行」「データベースのPoint-in-Timeリカバリの実行」
ブロック・メディア・リカバリ	この形式のメディア・リカバリでは、データファイル全体ではなく、データファイル内の個々のブロックをリストアできます。	「ブロック・メディア・リカバリの概要」
表領域のPoint-in-Timeリカバリ(TSPITR)	これは特別な形式のPoint-in-Timeリカバリで、1つ以上の表領域をデータベースの残りの部分より前の時点までリカバリします。	「RMANのTSPITRの概要」

通常、前述の修復方法を使用するために必要な概念は、その方法とともに説明されています。この章では、RMANのいくつかのデータ修復方法に共通の概念について説明します。

14.2 RMANのリストア操作について

RMANのリストア操作では、リストアされるファイルを選択してからRESTOREコマンドを実行します。通常は、メディア・リカバリの準備としてファイルをリストアします。

次のタイプのファイルをリストアできます。

データベース(すべてのデータファイル)
表領域
制御ファイル
アーカイブREDOログ
サーバー・パラメータ・ファイル

リストアされるデータファイルおよび制御ファイルには、デフォルトの場所または新しい場所を指定できます。デフォルトの場所にリストアする場合、RMANは、現在その場所に存在する同じ名前のすべてのファイルを上書きします。また、SET NEWNAMEコマンドを使用して、リストアされるデータファイルに対して新しい場所を指定することもできます。その後、SWITCHコマンドを実行して、新しい場所にあるリストアされたファイルが現行のデータファイルであることを示すように制御ファイルを更新できます。

関連項目:

RESTOREの構文および前提条件については、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。
SET NEWNAMEの構文については、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。
SWITCHの構文については、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

14.2.1 RMANバックアップの選択について

RMANは、RMANリポジトリに存在する使用可能なバックアップ・セットまたはイメージ・コピーのレコードを使用して、リストア操作に使用する最適なバックアップを選択します。

使用可能な最新のバックアップ、またはRESTOREコマンドで指定したUNTIL句を満たす最新のバックアップが選択されます。同じ時点の2つのバックアップが存在する場合、RMANはバックアップ・セットよりイメージ・コピーを選択します。これは、バックアップ・セットよりイメージ・コピーからのリストアの方が高速に実行できるためです(特に、テープ上に格納されている場合)。

RMANでバックアップをリストアする前に、RESTOREコマンドのすべての仕様を満たす必要があります。DEVICE TYPE句で制限していないかぎり、RESTOREコマンドでは、構成されたチャネルのすべてのデバイス・タイプでバックアップが検索されます。指定したすべての基準を満たす使用可能なバックアップがリポジトリに存在しない場合は、ファイルがリストアできないことを示すエラーが戻されます。

手動で割り当てたチャネルのみを使用する場合、チャネルを割り当てたメディアに使用可能なバックアップが存在しないと、バックアップ・ジョブが失敗する場合があります。自動チャネルを構成すると、指定した基準を満たすバックアップがRMANによって検索およびリストアされる可能性が高くなります。

関連項目:

「高度なチャネル・オプションの構成」

14.2.2 RMANリストア・フェイルオーバーについて

RMANは、自動的にリストア・フェイルオーバーを使用し、破損したバックアップまたはアクセスできないバックアップをスキップして使用可能なバックアップを検索します。バックアップが検出されなかった場合、または破損したデータがバックアップに含まれている場合、RMANは、目的のファイルをリストアするための別のバックアップを自動的に検索します。

RMANは、実行しているフェイルオーバーのタイプを示すメッセージを生成します。たとえば、RMANは、同じファイルの別のバックアップにフェイルオーバーする場合、次のようなメッセージを表示します。

failover to piece handle=/u01/backup/db_1 tag=BACKUP_031009

使用可能なコピーが存在しない場合は、RMANによって以前のバックアップが検索されます。次に、表示されるメッセージの例を示します。

ORA-19624: operation failed, retry possible
ORA-19505: failed to identify file "/u01/backup/db_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
failover to previous backup

RMANは、すべての使用可能なバックアップを使い切るまでリストア・フェイルオーバーを繰り返し実行します。すべてのバックアップを使用できない場合またはバックアップが存在しない場合、RMANはデータファイルの再作成を試行します。リストア・フェイルオーバーは、RECOVER、RECOVER ... BLOCKおよびFLASHBACK DATABASEコマンドの実行中、アーカイブREDOログのリストアでエラーが発生した場合にも使用されます。

14.2.3 暗号化バックアップのRMANリストアについて

RMANは、バックアップ・セットのコンテンツをリストアするときに、バックアップの暗号化を使用して保護されているバックアップ・セットを自動的に復号化します。追加のステップは(ある場合)、バックアップを暗号化するために使用された技術によって異なります。

Oracleキーストアが使用可能な場合、自動ログイン・ソフトウェア・キーストアを使用したバックアップの透過的暗号化は介入を必要としません。

バックアップが作成されたソース・ホストとは異なるホストでバックアップをリストアする場合は、ソース・データベースから宛先ホストにOracleキーストアを手動でコピーします。
パスワードベースのキーストアを使用したバックアップの透過的暗号化では、開くためのキーストアが必要です。

Oracleソフトウェア・キーストアを、バックアップをリストアする宛先ホストに手動でコピーし、キーストアを開くために必要なパスワードを指定します。SET DECRYPTION WALLET OPEN IDENTIFIED BYコマンドでパスワードを指定します。
パスワード暗号化バックアップをリストアするには、正しいパスワードを入力する必要があります。

SET DECRYPTION IDENTIFIED BYコマンドを使用して、暗号化されたバックアップを復号化するために使用する必要があるパスワードを指定します。
デュアルモード暗号化バックアップは、Oracleソフトウェア・キーストアを使用して透過的にリストアするか、復号化のパスワードを指定してリストアできます。

TDEマスター・キーおよび透過的に暗号化されたバックアップ

TDEマスター暗号化キーをリセット(またはローテーション、再設定)するときに、RMANは、以前のTDEマスター暗号化キーを使用して暗号化されたバックアップを引き続きリストアできます。これは、Oracleキーストアが、使わなくなったTDEマスター暗号化キーすべての履歴を保存しているためです。

ノート:

TDEマスター・キーが含まれるOracleキーストアが失われて、再作成が必要な場合は、以前のTDEマスター・キーを使用して暗号化されたすべてのバックアップは無効化されて、使用できなくなります。

関連項目:

Oracle Database Advanced Securityガイド

14.2.4 RMANのリストア操作およびASMについて

自動ストレージ管理(ASM)ディスク・グループが使用されている場合、インカーネーションを含むデータ・ファイルの完全名が既存のデータ・ファイル名と一致しない場合のみ、RMANリストア操作によってデータ・ファイルの新規コピーが作成されます。

完全修飾ASMファイル名の形式は+diskgroup/dbname/filetype/filetypetag.file.incarnationです。最初に制御ファイルをリストアしてから他のデータベース・ファイルをリストアする際、制御ファイル内のデータ・ファイルの名前が既存のデータ・ファイル名と一致しないために、データ・ファイルが再作成されることがあります。

次のいずれかの方法を使用して、リストアまたは複製操作中に、既存のデータ・ファイルが再作成されないようにします。

制御ファイルでは、各データ・ファイルに別名を使用します。別名にASMインカーネーション番号を含めることはできません。
制御ファイルのリストア後、他のデータベース・ファイルをリストアする前に、CATALOGコマンドを使用して、既存のデータ・ファイルがリストアされた制御ファイル内にカタログ化されていることを確認します。次に、SWITCHコマンドを使用して、リストアされた制御ファイルが既存のデータ・ファイルを指すようにします。
SET NEWNAMEを使用して、データ・ファイルをリストアする前および制御ファイルをリストアした後に、データ・ファイルの名前を変更します。

14.2.5 RMANリストアの最適化について

RMANは、可能な場合、バックアップからデータファイルがリストアされないようにリストアの最適化を使用します。データファイルが適切な場所に存在し、そのヘッダーに予測された情報が含まれている場合、RMANはそのデータファイルをバックアップからリストアしません。

ノート:

リストアの最適化では、データファイルのヘッダーのみがチェックされます。データファイルのボディに破損ブロックがあるかどうかはスキャンされません。

RESTOREコマンドのFORCEオプションを使用すると、この動作を無効にして、目的のファイルを無条件でリストアできます。

リストアの最適化は、複数のデータファイルをリストアする操作が中断された場合に特に有効です。たとえば、データベース全体のリストアで、1つ以外のすべてのデータファイルがリストアされた後に停電が発生したと想定します。同じRESTOREコマンドを再度実行した場合、RMANは、前回のリストア中にリストアされなかった1つのデータファイルのみをリストアします。

リストアの最適化は、データベースの複製時にも使用されます。複製にあるデータファイルが適切な場所に存在し、ヘッダーの内容が適切である場合、そのデータファイルは複製されません。ただし、RESTOREとは異なり、DUPLICATEではFORCEオプションがサポートされていません。リストアの最適化によってスキップされたデータファイルをRMANで強制的に複製するには、複製からこのデータファイルを削除した後、DUPLICATEコマンドを実行します。

関連項目:

Oracle RAC構成でのRESTOREの動作の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。

14.3 RMANのメディア・リカバリについて

メディア・リカバリでは、RMANは、リストアされたデータに変更を適用してそのデータを任意の時点にロールフォワードします。

RMANでは、データファイルのメディア・リカバリまたはブロック・メディア・リカバリのいずれかを実行できます。

データファイルのメディア・リカバリは、現在または指定した他の時間に更新するための、リストアされたデータファイルに対するREDOログまたは増分バックアップのアプリケーションです。Oracle Database概要で説明されているように、RMANを使用して完全リカバリ、データベースのPoint-in-Timeリカバリ(DBPITR)または表領域のPoint-in-Timeリカバリ(TSPITR)を実行できます。RESTOREコマンドを使用して、消失または破損したデータファイルまたは制御ファイルのバックアップをリストアし、RECOVERコマンドを使用して、メディア・リカバリを実行することができます。

ブロック・メディア・リカバリとは、データファイル全体ではなく、個々のデータ・ブロックのリカバリのことです。ここでは、データファイルのメディア・リカバリについてのみ説明します。メディア・リカバリの特殊な形式であるブロック・メディア・リカバリについては、「ブロック・メディア・リカバリの概要」を参照してください。

14.3.1 増分バックアップおよびアーカイブREDOログの選択について

メディア・リカバリは、RMANによって自動化されています。RMANは、増分バックアップおよびアーカイブREDOログを最適な組合せで自動的にリストアし、適用します。

必要なログ順序番号のコピーがディスク上に存在しないことがRMANリポジトリに示されている場合、RMANは、必要なログをバックアップから自動的にリストアします。デフォルトでは、アーカイブ先がUSE_DB_RECOVERY_FILE_DESTに設定されている場合、RMANは、アーカイブ・ログを高速リカバリ領域にリストアします。その他の場合、RMANは初期化パラメータ・ファイルで指定された最初のローカルのアーカイブ先にログをリストアします。

関連項目:

CROSSCHECKの構文については、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

14.3.2 データベース・インカネーションについて

RESETLOGSオプションを使用してデータベースをオープンするたびに、データベース・インカネーションが作成されます。

リカバリが完了すると、OPEN RESETLOGS を使用せずに通常の操作を再開できます。ただし、バックアップ制御ファイルを使用したDBPITRまたはリカバリの後は、RESETLOGSオプションを使用してデータベースをオープンする必要があります。これによって、データベースの新しいインカネーションが作成されます。異なる時刻に発生した2つの異なるREDOストリームのSCNが同じになっている場合は、混同を回避するために、データベースに新しいインカネーションが必要となります。間違ったREDOをデータベースに適用すると、データベースは破損します。

1つのデータベースに複数のインカネーションが存在するかどうかによって、RMANによる現行のインカネーション・パスに存在しないバックアップの処理方法が決まります。通常、使用に適したインカネーションは現行のデータベース・インカネーションです。ただし、データベースを以前のインカネーションにリセットする方法が最適な場合もあります。たとえば、実行したPoint-in-Timeリカバリの結果が適切でなく、データベースをRESETLOGSより前の時点に戻す必要がある場合があります。データベース・インカネーションを理解することによって、そのような状況に備えることができます。

14.3.2.1 RMANのOPEN RESETLOGS操作について

RESETLOGSオプションを使用してデータベースをオープンすると、RMANにより特定のアクションが実行されます。

実行されるアクションは次のとおりです。

現行のオンラインREDOログがアーカイブされ(アクセス可能な場合)、オンラインREDOログの内容が消去されて、ログ順序番号が1にリセットされます。

たとえば、現行のオンラインREDOログの順序が1000および1001である場合、RESETLOGSでデータベースをオープンすると、ログ1000および1001がアーカイブされ、オンライン・ログは順序1および2にリセットされます。
現在存在していない場合は、オンラインREDOログ・ファイルが作成されます。
制御ファイル内のREDOスレッド・レコードおよびオンラインREDOログ・レコードが、新しいデータベース・インカネーションの開始時点の状態に初期化されます。

具体的には、REDOスレッドのステータスがCLOSEDに、REDOスレッド・レコード内の現行のスレッド順序が1に、各REDOスレッドのスレッド・チェックポイントがログ順序の最初である1に設定され、各スレッドからREDOログが1つ選択され、その順序が1に初期化されます。
すべての現行のデータファイル、オンラインREDOログおよび後続のアーカイブREDOログが、新しいRESETLOGS SCNおよびタイムスタンプによって更新されます。

RESETLOGS SCNとタイムスタンプが一致しないかぎり、データファイルにアーカイブREDOログは適用されません。そのため、RESETLOGS要件を指定すると、現行のインカネーションの直接の親インカネーションのものではないアーカイブ・ログによってデータファイルが破損されることを回避できます。インカネーション間の関係については、後続の項で説明します。

以前のリリースでは、OPEN RESETLOGSの直後にデータベースをバックアップすることが推奨されていました。今回のリリースでは、他のバックアップと同様にRESETLOGSの実行前のバックアップを簡単にリカバリできるため、新しいデータベースのバックアップを作成するかどうかは任意です。RESETLOGSを介したリカバリを実行するには、最後のバックアップ以降に生成されたすべてのアーカイブ・ログおよび1つ以上の制御ファイル(現行のファイル、バックアップまたは作成したファイル)が必要です。

14.3.2.2 データベース・インカネーション間の関係

データベース・インカネーションは、相互に次の関係を持つことができます。

現行のインカネーションは、データベースで現在操作されているインカネーションです。
OPEN RESETLOGS操作によって、あるインカネーションから現行のインカネーションが分岐している場合、そのインカネーションを、現行のインカネーションの親インカネーションといいます。
親インカネーションの親は、祖先インカネーションです。また、祖先インカネーションのすべての親も現行インカネーションの祖先です。
現行インカネーションの直系祖先パスは、最も古いインカネーションで始まり、現行インカネーションの祖先、親インカネーションまたは現行インカネーションへのブランチのみを含みます。

REDOのストリームを一意にタグ付けして識別するために、インカネーション番号が使用されます。図14-1に、複数のインカネーションを持つデータベースを示します。各インカネーションに、異なるインカネーション番号が付けられています。

図14-1 データベース・インカネーションの履歴

「図14-1 データベース・インカネーションの履歴」の説明

データベースのインカネーション1はSCN 1で始まり、SCN 1000からSCN 2000まで続いています。インカネーション1のSCN 2000で、Point-in-Timeリカバリを実行してSCN 1000まで戻り、RESETLOGSオプションを指定してデータベースをオープンするとします。これによって、インカネーション2はSCN 1000で始まり、SCN 3000まで続きます。この例では、インカネーション1はインカネーション2の親となります。

インカネーション2のSCN 3000で、Point-in-Timeリカバリを実行してSCN 2000まで戻り、RESETLOGSオプションを指定してデータベースをオープンするとします。この例では、インカネーション2はインカネーション3の親となります。インカネーション1はインカネーション3の祖先です。

データベースでDBPITRまたはフラッシュバック・データベースが実行されると、いずれのインカネーションが現行インカネーションであるかによって、SCNが複数の時点を示す場合があります。たとえば、図14-1のSCN 1500は、インカネーション1または2でのSCNを示す場合があります。

RESET DATABASE TO INCARNATIONコマンドを使用すると、SCNが特定のデータベース・インカネーションの参照の範囲にあると解釈されます。FLASHBACK、RESTOREまたはRECOVERを使用して現行以外のデータベース・インカネーションのSCNに戻る場合は、RESET DATABASE TO INCARNATIONコマンドが必要です。ただし、「リカバリ・カタログのデータベース・インカネーションの再設定」で説明するように、RMANはフラッシュバックでRESET DATABASE TO INCARNATIONコマンドを暗黙的に実行します。

関連項目:

「祖先インカネーションへのデータベースのリカバリ」
RESET DATABASEコマンドの詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

14.3.2.3 PDBのインカネーションについて

プラガブル・データベース(PDB)のインカネーションは、マルチテナント・コンテナ・データベース(CDB)のサブインカネーションで、(database_incarnation, pdb_incarnation)として表されます。

たとえば、CDBがインカネーション5で、PDBがインカネーション3の場合、PDBの完全指定のインカネーション番号は(5, 3)になります。PDBの初期インカネーションは、0です。後続のインカネーションは一意ですが、必ずしも後続の番号とはかぎりません。

V$PDB_INCARNATIONビューには、すべてのPDBインカネーションに関する情報が含まれます。次の問合せを使用してPDBの現在のインカネーションを表示します。

SELECT PDB_INCARNATION# FROM V$PDB_INCARNATION
   WHERE STATUS = 'CURRENT' AND CON_ID = PDB_container_id;

14.3.2.4 孤立したバックアップについて

データベースが複数のインカネーションを持つ場合、一部のバックアップは孤立したバックアップの可能性があります。孤立したバックアップとは、直系祖先パス内にないデータベースのインカネーションで作成されたバックアップのことです。

図14-1の例を想定します。インカネーション3が現行インカネーションの場合、次のバックアップが孤立します。

SCN 1000より後のインカネーション1のすべてのバックアップ
SCN 2000より後のインカネーション2のすべてのバックアップ

これに対して、次のバックアップは、直系祖先パス内にあるため孤立しません。

SCN 1000より前のインカネーション1のすべてのバックアップ
SCN 2000より前のインカネーション2のすべてのバックアップ
インカネーション3のすべてのバックアップ

直系祖先パス内にないSCNまでデータベースをリストアする場合は、孤立したバックアップを使用できます。RMANは、OPEN RESETLOGS操作が実行された場合でも、最も古いバックアップからリカバリする時点までのアーカイブ・ログが連続して存在している場合、親および祖先のインカネーションからバックアップをリストアして、現在の時点までリカバリすることができます。また、RMANは、バックアップに示されている変更が取り消されたことがないインカネーションから制御ファイルをリストアする場合、孤立したバックアップを使用してリストアおよびリカバリを実行できます。

14.3.2.5 孤立したPDBバックアップについて

プラガブル・データベース(PDB)でPoint-in-Timeリカバリを実行してから、RESETLOGSオプションを使用してPDBをオープンすると、孤立したPDBのバックアップが発生する可能性があります。

PDBを指定した時点へリカバリした後、RESETLOGSオプションを使用してPDBをオープンすると、PDBの新しいインカネーションが作成されます。孤立したPDBのバックアップは、SCNまたは時間値が、PDBがリカバリされたSCNまたは時間からPDBがRESETLOGSモードでオープンされたSCNまたは時間の間に作成されたバックアップです。V$PDB_INCARNATIONビューのEND_RESETLOGS_SCN列には、PDBがRESETLOGSモードでオープンされたSCNが含まれています。