| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース2(11.2) B56269-05 |
|
 前 |
 次 |
この章では、データ修復を実行するために理解しておく必要がある一般的な概念について説明します。この章の内容は次のとおりです。
「データ保護」で説明されているように、バックアップおよびリカバリ計画の主な目的はデータの保護です。効果的で効率的な計画を立案するために重要な点は、データ修復の基本的な方法を理解することです。
Oracle Databaseの正常な稼働を停止させたり、データベースのI/O処理に影響を与える問題はいくつかありますが、通常、ユーザー・エラー、アプリケーション・エラーおよびメディア障害が発生した場合にのみDBAが介入する必要があります。
ユーザー・エラーは、アプリケーション・ロジックのエラーまたは誤操作のため、データベースのデータが誤って変更または削除された場合に発生します。たとえば、ユーザーが間違ったデータベースにログインしてデータベースの表を削除した場合などです。ユーザー・エラーは、データベースの停止時間を発生させる最も大きな原因であるとみなされています。
メディア障害は、通常の操作中に、データベースの外部の問題によってファイルに対する読取りまたは書込みができなくなった場合に発生します。典型的なメディア障害としては、ディスク障害、データベース・ファイルの削除などがあります。メディア障害は、ユーザー・エラーまたはアプリケーション・エラーほど一般的ではありませんが、バックアップおよびリカバリ計画では、メディア障害に対する準備をしておく必要があります。
予測する状況に基づいて、データの消失に対処するために次の各オプションを組み込むことを検討した後、これらのオプションを使用できるようにデータベースを設定します。
このOracle Databaseインフラストラクチャを使用すると、障害を診断して対応する方法を提示し、自動的にその障害を修復できます。
データ・リカバリ・アドバイザの基本的な概念については、「データ・リカバリ・アドバイザの概要」を参照してください。
このOracleフラッシュバック技術機能のサブセットを使用すると、過去の時点の個々のデータベース・オブジェクトまたはトランザクションを表示したり、個々のデータベース・オブジェクトまたはトランザクションを過去の時点まで巻き戻すことができます。この機能では、RMANを使用する必要はありません。
論理フラッシュバック機能の基本的な概念および(必要に応じた)参照先については、「Oracleフラッシュバック技術およびデータベースのPoint-in-Timeリカバリの概要」を参照してください。
フラッシュバック・データベースとは、メディア・リカバリに類似したブロックレベルのリカバリ・メカニズムのことですが、通常、高速で、リストアするバックアップは必要としません。事前にフラッシュバック・ロギングを有効にしているかぎり、データファイルの古いコピーをバックアップからリストアせずに、データベース全体を前の状態に戻すことができます。データベースのフラッシュバック・ロギング用または保証付きリストア・ポイント用に高速リカバリ領域を構成しておく必要があります。
フラッシュバック・データベースの基本的な概念については、「Point-in-Timeリカバリおよびフラッシュバック機能の基本的な概念」を参照してください。
この形式のメディア・リカバリでは、データファイルのバックアップをリストアし、アーカイブREDOログまたは増分バックアップを適用して、消失した変更をリカバリできます。データベース全体またはデータベースのサブセットのいずれかをリカバリすることができます。データファイルのメディア・リカバリは、最も汎用的な形式のリカバリで、物理的な破損および論理的な破損の両方から保護できます。
データファイルのメディア・リカバリの基本的な概念については、この章で説明します。方法については、第17章「データベースの完全リカバリの実行」および「データベースのPoint-in-Timeリカバリの実行」を参照してください。
この形式のメディア・リカバリでは、データファイル全体ではなく、データファイル内の個々のブロックをリストアできます。
ブロック・メディア・リカバリの基本的な概念については、「ブロック・メディア・リカバリの概要」を参照してください。
これは特別な形式のPoint-in-Timeリカバリで、1つ以上の表領域をデータベースの残りの部分より前の時点までリカバリします。
TSPITRの基本的な概念については、「RMANのTSPITRの概要」を参照してください。
通常、前述の修復方法を使用するために必要な概念は、その方法とともに説明されています。この章では、RMANのいくつかのデータ修復方法に共通の概念について説明します。
RMANのリストア操作では、リストアされるファイルを選択してからRESTOREコマンドを実行します。通常は、メディア・リカバリの準備としてファイルをリストアします。次のタイプのファイルをリストアできます。
データベース(すべてのデータファイル)
表領域
制御ファイル
アーカイブREDOログ
サーバー・パラメータ・ファイル
リストアされるデータファイルおよび制御ファイルには、デフォルトの場所または新しい場所を指定できます。デフォルトの場所にリストアする場合、RMANは、現在その場所に存在する同じ名前のすべてのファイルを上書きします。また、SET NEWNAMEコマンドを使用して、リストアされるデータファイルに対して新しい場所を指定することもできます。その後、SWITCHコマンドを実行して、新しい場所にあるリストアされたファイルが現行のデータファイルであることを示すように制御ファイルを更新できます。
|
参照: RESTOREの構文および前提条件については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』 |
RMANは、RMANリポジトリに存在する使用可能なバックアップ・セットまたはイメージ・コピーのレコードを使用して、リストア操作に使用する最適なバックアップを選択します。使用可能な最新のバックアップ、またはRESTOREコマンドで指定したUNTIL句を満たす最新のバックアップが選択されます。同じ時点の2つのバックアップが存在する場合、RMANはバックアップ・セットよりイメージ・コピーを選択します。これは、バックアップ・セットよりイメージ・コピーからのリストアの方が高速に実行できるためです(特に、テープ上に格納されている場合)。
RMANでバックアップをリストアする前に、RESTOREコマンドのすべての仕様を満たす必要があります。DEVICE TYPE句で制限していないかぎり、RESTOREコマンドでは、構成されたチャネルのすべてのデバイス・タイプでバックアップが検索されます。指定したすべての基準を満たす使用可能なバックアップがリポジトリに存在しない場合は、ファイルがリストアできないことを示すエラーが戻されます。
手動で割り当てたチャネルのみを使用する場合、チャネルを割り当てたメディアに使用可能なバックアップが存在しないと、バックアップ・ジョブが失敗する場合があります。自動チャネルを構成すると、指定した基準を満たすバックアップがRMANによって検索およびリストアされる可能性が高くなります。
バックアップ・セットがバックアップの暗号化で保護されている場合、RMANは、バックアップ・セットの内容をリストアする際にバックアップ・セットを自動的に復号化します。透過的に暗号化されたバックアップは、Oracleウォレットがオープンしていて使用可能な場合にかぎり、ユーザーが介入せずにリストアできます。パスワード暗号化バックアップをリストアするには、正しいパスワードを入力する必要があります。
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ログのリストアでエラーが発生した場合にも使用されます。
自動ストレージ管理(ASM)ディスク・グループが使用されている場合、インカーネーションを含むデータ・ファイルの完全名が既存のデータ・ファイル名と一致しない場合のみ、RMANリストア操作によってデータ・ファイルの新規コピーが作成されます。完全修飾ASMファイル名の形式は+diskgroup/dbname/filetype/filetypetag.file.incarnationです。最初に制御ファイルをリストアしてから他のデータベース・ファイルをリストアする際、制御ファイル内のデータ・ファイルの名前が既存のデータ・ファイル名と一致しないために、データ・ファイルが再作成されることがあります。
次のいずれかの方法を使用して、リストアまたは複製操作中に、既存のデータ・ファイルが再作成されないようにします。
制御ファイルでは、各データ・ファイルに別名を使用します。別名にASMインカーネーション番号を含めることはできません。
制御ファイルのリストア後、他のデータベース・ファイルをリストアする前に、CATALOGコマンドを使用して、既存のデータ・ファイルがリストアされた制御ファイル内にカタログ化されていることを確認します。次に、SWITCHコマンドを使用して、リストアされた制御ファイルが既存のデータ・ファイルを指すようにします。
SET NEWNAMEを使用して、データ・ファイルをリストアする前および制御ファイルをリストアした後に、データ・ファイルの名前を変更します。
RMANは、可能な場合、バックアップからデータファイルがリストアされないようにリストアの最適化を使用します。データファイルが適切な場所に存在し、そのヘッダーに予測された情報が含まれている場合、RMANはそのデータファイルをバックアップからリストアしません。
|
注意: リストアの最適化では、データファイルのヘッダーのみがチェックされます。データファイルのボディに破損ブロックがあるかどうかはスキャンされません。 |
RESTOREコマンドのFORCEオプションを使用すると、この動作を無効にして、目的のファイルを無条件でリストアできます。
リストアの最適化は、複数のデータファイルをリストアする操作が中断された場合に特に有効です。たとえば、データベース全体のリストアで、1つ以外のすべてのデータファイルがリストアされた後に停電が発生したと想定します。同じRESTOREコマンドを再度実行した場合、RMANは、前回のリストア中にリストアされなかった1つのデータファイルのみをリストアします。
リストアの最適化は、データベースの複製時にも使用されます。複製にあるデータファイルが適切な場所に存在し、ヘッダーの内容が適切である場合、そのデータファイルは複製されません。ただし、RESTOREとは異なり、DUPLICATEではFORCEオプションがサポートされていません。リストアの最適化によってスキップされたデータファイルをRMANで強制的に複製するには、複製からこのデータファイルを削除した後、DUPLICATEコマンドを実行します。
|
関連項目: Oracle RAC構成のRESTOREの動作の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』 |
メディア・リカバリでは、RMANは、リストアされたデータに変更を適用してそのデータを任意の時点にロールフォワードします。RMANでは、データファイルのメディア・リカバリまたはブロック・メディア・リカバリのいずれかを実行できます。
データファイルのメディア・リカバリは、現在または指定した他の時間に更新するための、リストアされたデータファイルに対するREDOログまたは増分バックアップのアプリケーションです。『Oracle Database概要』で説明されているように、RMANを使用して完全リカバリ、データベースのPoint-in-Timeリカバリ(DBPITR)または表領域のPoint-in-Timeリカバリ(TSPITR)を実行できます。RESTOREコマンドを使用して、消失または破損したデータファイルまたは制御ファイルのバックアップをリストアし、RECOVERコマンドを使用して、メディア・リカバリを実行することができます。
ブロック・メディア・リカバリとは、データファイル全体ではなく、個々のデータ・ブロックのリカバリのことです。ここでは、データファイルのメディア・リカバリについてのみ説明します。メディア・リカバリの特殊な形式であるブロック・メディア・リカバリについては、「ブロック・メディア・リカバリの概要」を参照してください。
メディア・リカバリは、RMANによって自動化されています。RMANは、増分バックアップおよびアーカイブREDOログを最適な組合せで自動的にリストアし、適用します。
必要なログ順序番号のコピーがディスク上に存在しないことがRMANリポジトリに示されている場合、RMANは、必要なログをバックアップから自動的にリストアします。デフォルトでは、アーカイブ先がUSE_DB_RECOVERY_FILE_DESTに設定されている場合、RMANは、アーカイブ・ログを高速リカバリ領域にリストアします。その他の場合は、初期化パラメータ・ファイルで指定された最初のローカルのアーカイブ先に、アーカイブREDOログをリストアします。
|
関連項目: CROSSCHECKの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』 |
RESETLOGSオプションを使用してデータベースをオープンするたびに、データベース・インカネーションが作成されます。リカバリが完了すると、OPEN RESETLOGSを使用せずに通常の操作を再開できます。ただし、バックアップ制御ファイルを使用したDBPITRまたはリカバリの後は、RESETLOGSオプションを使用してデータベースをオープンする必要があります。これによって、データベースの新しいインカネーションが作成されます。異なる時刻に発生した2つの異なるREDOストリームのSCNが同じになっている場合は、混同を回避するために、データベースに新しいインカネーションが必要となります。間違ったREDOをデータベースに適用すると、データベースは破損します。
1つのデータベースに複数のインカネーションが存在するかどうかによって、RMANによる現行のインカネーション・パスに存在しないバックアップの処理方法が決まります。通常、使用に適したインカネーションは現行のデータベース・インカネーションです。ただし、データベースを以前のインカネーションにリセットする方法が最適な場合もあります。たとえば、実行したPoint-in-Timeリカバリの結果が適切でなく、データベースをRESETLOGSより前の時点に戻す必要がある場合があります。データベース・インカネーションを理解することによって、そのような状況に備えることができます。
RESETLOGSオプションを指定してデータベースをオープンすると、データベースによって次の処理が実行されます。
現行のオンライン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つ以上の制御ファイル(現行のファイル、バックアップまたは作成したファイル)が必要です。
データベース・インカネーションは、相互に次の関係を持つことができます。
現行のインカネーションは、データベースで現在操作されているインカネーションです。
OPEN RESETLOGS操作によって、あるインカネーションから現行のインカネーションが分岐している場合、そのインカネーションを、現行のインカネーションの親インカネーションといいます。
親インカネーションの親は、祖先インカネーションです。また、祖先インカネーションのすべての親も現行インカネーションの祖先です。
現行インカネーションの直系祖先パスは、最も古いインカネーションで始まり、現行インカネーションの祖先、親インカネーションまたは現行インカネーションへのブランチのみを含みます。
REDOのストリームを一意にタグ付けして識別するために、インカネーション番号が使用されます。図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コマンドを暗黙的に実行します。
|
関連項目:
|
データベースが複数のインカネーションを持つ場合、一部のバックアップは孤立したバックアップの可能性があります。孤立したバックアップとは、直系祖先パス内にないデータベースのインカネーションで作成されたバックアップのことです。
図14-1の例を想定します。インカネーション3が現行インカネーションの場合、次のバックアップが孤立します。
SCN 1000より後のインカネーション1のすべてのバックアップ
SCN 2000より後のインカネーション2のすべてのバックアップ
これに対して、次のバックアップは、直系祖先パス内にあるため孤立しません。
SCN 1000より前のインカネーション1のすべてのバックアップ
SCN 2000より前のインカネーション2のすべてのバックアップ
インカネーション3のすべてのバックアップ
直系祖先パス内にないSCNまでデータベースをリストアする場合は、孤立したバックアップを使用できます。RMANは、OPEN RESETLOGS操作が実行された場合でも、最も古いバックアップからリカバリする時点までのアーカイブ・ログが連続して存在しているかぎり、親および祖先のインカネーションからバックアップをリストアして、現在の時点までリカバリすることができます。また、RMANは、バックアップに示されている変更が取り消されたことがないインカネーションから制御ファイルをリストアする場合、孤立したバックアップを使用してリストアおよびリカバリを実行できます。
