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