10gリリース2（10.2）
B19193-02
 目次 |
 索引 |
| Oracle Database バックアップおよびリカバリ基礎 10gリリース2（10.2） B19193-02 |
|
この章では、効果的なバックアップおよびリカバリ計画を立案するにあたっての、指針および考慮点について説明します。
この章では、次の項目について説明します。
バックアップ計画を決定するには、まずデータ・リカバリ要件およびデータ・リカバリ計画を検討します。データ・リカバリのタイプごとに、特定のタイプのバックアップを実行する必要があります。
障害には、ユーザー・エラーから、データ・ファイル・ブロック破損、メディア障害、データ・センターを完全に失うような状況まで、様々な種類があります。データベースの正常な稼働をいかにすばやく回復できるかは、計画に含めるリストアおよびリカバリ方式の種類に関係します。リストアおよびリカバリ方式によって、バックアップの作成、保存および管理に使用するOracleデータベースの機能を含めて、バックアップ計画の要件が決まります。
リカバリ計画を検討するときは、次の点を確認してください。
BLOCKRECOVERコマンドが役に立ちます。 また、リカバリのトラブルシューティングには、SQL*PlusのRECOVER ... TESTコマンドを使用します。
これらの要件に留意しながら、バックアップおよびリカバリに関する機能を活用する方法を決定し、各機能をバックアップ計画の要件に合わせる方法を検討します。次に例を示します。
リカバリ計画で使用する機能を決定したら、次の点を確認することで、バックアップ計画を立案できます。
OPEN RESETLOGSを実行した後や、REDOログには記録されないNOLOGGING操作などデータベースを変更した後などです。また、監査目的またはデータベース・リカバリとは関連のない理由でバックアップを必要とする、ビジネス上の要件もあります。
これらは、検討すべき項目の一部にすぎません。使用可能なリソース（ハードウェア、メディア、スタッフ、予算など）も判断要素となります。
データ・リカバリ計画には、データベース障害への対処方法をできるだけ多く含める必要があります。効果的で効率のよい計画を立案するために重要なのは、障害の状態を想定し、その障害の状態に役立つOracleデータベースのリカバリ方式およびツールを対応付けて、そのリカバリ方式をサポートするために必要なバックアップのタイプを組み込むことです。
各障害の状態の解決に役立つリカバリ方式については、次の項を参照してください。
ユーザーまたはアプリケーションが、誤った更新、表の内容の削除、データベース・オブジェクトの削除などの、データベースに不要な変更を加える可能性があります。適切なバックアップおよびリカバリ計画は、Oracleデータベースの多くの機能を使用して、データベースの可用性に及ぼす影響およびDBAへの負担を最小限に抑え、データベースを目的の状態に戻します。
予測する状況に基づいて、データの消失に対処するために次の各オプションを組み込むことを検討した後、これらのオプションを使用できるようにデータベースを設定します。
Oracle Flashback Databaseを使用すると、データ・ファイルの以前のコピーをバックアップからリストアせずに、データベース全体を過去のある時点の状態に戻すことができます。ただし、これは前もってデータベースのフラッシュバック・ロギングを有効にしている場合にかぎります。
フラッシュバック・ロギングを有効にして、使用可能なフラッシュバック・ログが許容する範囲内で過去の任意のSCNに戻せるようにしたり、またはデータベースの大規模な更新前など、特定のSCNで保証付きリストア・ポイントを作成し、Oracle Flashback Databaseを使用してデータベースを特定の時点の状態に確実に戻せるようにすることができます。
データベースのフラッシュバック・ロギング用または保証付きリストア・ポイント用にフラッシュ・リカバリ領域を構成しておく必要があります。
前述のとおり、保証付きリストア・ポイントでは、Oracle Flashback Databaseを使用して確実にデータベースを以前の特定の時点に戻すことが可能です。 通常のリストア・ポイントでは、データの保護は行われませんが便利です。これは、通常のリストア・ポイントを作成することで、Point-in-TimeリカバリまたはOracle Flashback Tableを使用したリカバリの操作を行う前にデータベースのSCNを記録する必要がなくなったり、適切なSCNを特定する操作を行った後に調査する必要がなくなるためです。
通常のリストア・ポイントを使用するには特別な設定は必要ありませんが、リストア・ポイントが必要になる前に作成を計画する必要があります。
Point-in-Timeリカバリを実行すると、1つの表領域またはデータベース全体を、エラーが発生する前の状態に戻すことができます。いずれの場合も、エラーが発生する前の状態のバックアップに加えて、バックアップ時からエラー発生時までのREDOログが必要です。
影響を受けた表の内容をエクスポートして論理バックアップを実行した場合、そのデータを再び表にインポートできることがあります。この方式は、データの論理バックアップを定期的にエクスポートすることと、エクスポート間での変更は重要でないことが前提となります。
|
注意: Oracleのフラッシュバック・テクノロジは、様々な状況でのメディア・リカバリにおいて、高速かつ確実な手段を提供します。
これらの機能の詳細は、第7章「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照してください。このマニュアルでは、これらの機能についての有効な情報および参照先を示しています。これらの機能は非常に有効であり、また一部高度な計画が必要になるため、バックアップおよびリカバリ計画を作成する前にこれらの機能についてよく理解しておいてください。 |
メディア障害は、データベースの外部の問題によって、データベースの操作中にOracleのファイル読取りまたは書込みが妨げられた場合に発生します。通常、メディア障害には、ヘッド・クラッシュ、データベース・ファイルの上書き、削除、破損などの、物理的な障害が含まれます。メディア障害は、ユーザー・エラーまたはアプリケーション・エラーほど一般的ではありませんが、バックアップおよびリカバリ計画では、メディア障害への対策を準備しておく必要があります。
メディア障害のタイプによって、使用するリカバリ方式が決まります。たとえば、破損データ・ファイルのリカバリ方法と、消失した制御ファイルのリカバリ方法は異なります。
オンライン・ログ・グループの全メンバーの消失からリカバリする方法は、次のように多数の要因によって異なります。
次に例を示します。
OPEN RESETLOGSを使用してオープンする必要があります。消失したログに含まれていたトランザクションはすべて失われます。OPEN RESETLOGSを実行した後は、データベースの新規の全体バックアップを即時に行う必要があります。OPEN RESETLOGSを実行する前のバックアップは、ログが消失しているため、以降のリカバリには使用できません。
OPEN RESETLOGSを実行できます。ただし、データベースの新規の全体バックアップを行う必要があります。OPEN RESETLOGSを実行する前のバックアップは、ログが消失しているため、以降のリカバリには使用できません。
ALTER DATABASE CLEAR LOGFILE文を使用してグループ内のすべてのメンバーを再作成できます。トランザクションは消失しません。消失したREDOログ・グループが消失前にアーカイブされていた場合は、これ以上の操作は必要ありません。ただし、データベースの新規の全体バックアップを即時に行う必要があります。ログが消失する前のバックアップは、ログが消失しているため、以降のリカバリには使用できません。
1つ以上のデータ・ファイル内の少数のブロックが破損した場合、それらのファイルをバックアップからリストアして完全なメディア・リカバリを実行するかわりに、ブロック・メディア・リカバリを使用できます。Recovery ManagerのBLOCKRECOVERコマンドを使用すると、データベースをオープンし、破損データ・ファイルがオンラインのときに、指定したデータ・ブロックをリストアおよびリカバリできます。
立案したデータ・リカバリ計画は、バックアップ計画の立案の基礎となります。ここでは、データベースのバックアップを実行する時期、データベース内のバックアップが必要な部分、Oracleが提供するバックアップ用のツール、および確実性を高めバックアップおよびリカバリを簡易にするためのデータベースの構成方法を決定するために役立つ、一般的なガイドラインについて説明します。計画の詳細は、コスト、リソース、要員、その他の要因について、リストア計画の要件に合わせて調整する必要があります。
Oracleデータベースを障害からリカバリする際に必要なファイルである、データ・ファイル、制御ファイル、オンラインREDOログをまとめて冗長性セットと呼びます。冗長性セットに含まれるものは次のとおりです。
tnsnames.ora、listener.oraなどの構成ファイルのコピーこのため、最小限の実働レベルのデータベースでも少なくとも2つのディスク・ドライブが必要で、一方は冗長性セットのファイル保存に、もう一方はデータベース・ファイルの保存に使用します。冗長性セットとプライマリ・ファイルは、別々のボリューム、別々のファイル・システム、別々のRAIDデバイスなど、可能なかぎり様々な方法で分離して保管することをお薦めします。
最も簡易な冗長性セットの管理方法は、フラッシュ・リカバリ領域を使用して、使用中のファイルのセットとは別のデバイス上に置くことです。ただし、フラッシュ・リカバリ領域の使用の有無にかかわらず、次の事例に従うことをお薦めします。
多重化されたファイルは、異なるディスク・コントローラにマウントされた、別のディスクに保存することをお薦めします。フラッシュ・リカバリ領域は、これらのファイルの1つをコピーするために最適な場所です。
オンラインREDOログおよび現行の制御ファイルは、オペレーティング・システム・レベルまたはハードウェア・レベルでミラー化することもできますが、これはデータベース・レベルの多重化の代替手段にはなりません。
ディスク・バックアップおよびアーカイブREDOログを含む、できるだけ多くのバックアップおよびリカバリ関連ファイルを格納するために、フラッシュ・リカバリ領域を使用することをお薦めします。
Oracleデータベースのバックアップおよびリカバリ機能（Oracle Flashback Database、保証付きリストア・ポイントなど）には、フラッシュ・リカバリ領域を使用する必要があるものがあります。ただし、これらの機能が使用するフラッシュ・リカバリ領域を確保していても、この領域を使用してすべてのリカバリ関連ファイルを格納する必要はありません。
フラッシュ・リカバリ領域を使用する必要がない場合でも、フラッシュ・リカバリ領域にはディスク上のその他のバックアップ記憶域の方式よりもメリットがあります。フラッシュ・リカバリ領域からテープに移動したバックアップは、その他の必須ファイル用の領域が必要になるまでディスク上に残るため、テープからバックアップをリストアする必要性が少なくなります。同時に、リカバリ可能性の目的に合わなくなった不要なファイル、およびテープにバックアップされているファイルは削除対象となり、領域が不足した際に削除されます。DBAが古いバックアップを手動で削除する必要はなくなり、DBAが誤って冗長性セット・ファイルを削除する可能性も低くなります。
データベースのREDOログは、そのデータベースのデータ・ファイルに対する変更の完全な記録を提供します（ダイレクト・パス・ロードなどの、一部の例外はあります）。
データベースは、ARCHIVELOGモードまたはNOARCHIVELOGモードのいずれかで稼働します。ARCHIVELOGモードでは、使用済のオンラインREDOログ・グループは、1つ以上のアーカイブ先にコピーされた後に再利用できるようになります。REDOログをアーカイブすると、そのログに保存されたすべてのトランザクションが保持されるので、後でリカバリ操作に使用できます。NOARCHIVELOGモードでは、オンラインREDOログ・グループは、ログが再利用されるときに単純に上書きされます。このREDOログ・グループに保存されたトランザクションに関する情報は、すべて消失します。
データベースをNOARCHIVELOGモードで稼働することは、バックアップおよびリカバリ計画に対する厳しい制約になります。
NOARCHIVELOGモードでデータベースを稼働していて、ディスク障害によって破損したデータ・ファイルをリカバリする必要がある場合には、主に次の2つのリカバリ方式で対処します。
データが消失した後、より柔軟なリカバリ・オプション（データベースや一部の表領域のPoint-in-Timeリカバリなど）を使用できるため、ほとんどの場合は、NOARCHIVELOGモードでの稼働よりARCHIVELOGモードでの稼働をお薦めします。ただし、ARCHIVELOGモードで稼働すると、次のコストがかかります。
パフォーマンスが要求される場合や、ディスク領域の制限が厳しい場合に、リカバリ・オプションに制約があっても、NOARCHIVELOGモードで稼働する方が適切な場合があります。
Oracleのフラッシュバック機能を使用すると、データベースでの不要な変更による影響を修復する場合に、データベースの可用性が向上します。論理レベルのフラッシュバック機能を使用すると、影響を受けていないオブジェクトを使用可能な状態のままにすることができ、Oracle Flashback Databaseを使用すると、Point-in-Timeリカバリよりもデータベース全体のリカバリ時間を短くすることができます。
Oracleの論理レベルのフラッシュバック機能を利用する場合は、データベースでどのようにUNDOデータが管理されているかを考慮する必要があります。UNDOデータおよび自動UNDO管理の詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。
Oracle Flashback Databaseまたは保証付きリストア・ポイントを計画に組み込む場合は、フラッシュ・リカバリ領域を有効にするとともに、適切な時点で保証付きリストア・ポイントを作成するか、またはフラッシュバック・ロギングを構成する必要があります。これらの機能がデータ保護計画で果たす役割と、これらの機能を個別または同時に使用するための要件については、第5章「リストア・ポイントおよびOracle Flashback Databaseを使用したデータ保護」を参照してください。
バックアップ保存方針とは、リカバリおよびその他の要件を満たすために（ディスク上またはその他のバックアップ・メディアのいずれかに）残す必要のあるバックアップを判断するための規則です。
バックアップ保存方針は、冗長性またはリカバリ期間に基づいて設定できます。冗長性ベースの保存方針には、数値nを指定します。これによって、データベース内の各ファイルのバックアップが、常にn種類以上保持されるようになります。リカバリ期間ベースの保存方針では、過去の期間（1週間、1か月など）を指定します。指定した期間内の任意の時点までのPoint-in-Timeリカバリを実行できるように、必要なすべてのバックアップが保持されます。
バックアップ保存方針に合わなくなったバックアップを、不要バックアップと呼びます。
Recovery Managerは、バックアップ保存方針の実装を自動化します。これには、次のコマンドを使用します。
CONFIGURE RETENTION POLICYコマンドを使用すると、すべてのデータベース・ファイルにデフォルトで適用する保存方針を設定できます。
REPORT OBSOLETEコマンドを使用すると、現在ディスク上にある、保存方針に合わなくなった不要バックアップの一覧を表示できます。また、パラメータを指定して、どのファイルが別のバックアップ保存方針に合わなくなったかを参照することもできます。
DELETE OBSOLETEコマンドは、REPORT OBSOLETEで不要と報告されたファイルを削除します。
CHANGE... KEEPコマンドを使用すると、アーカイブ用に保存されている長期バックアップなど、特定のバックアップに対して個別の保存方針を設定できます。指定したバックアップを任意の時間まで保存することも、または永続的に保存することも可能です。 CHANGE... NOKEEPコマンドを使用すると、以前CHANGE... KEEPによって保護されたバックアップに対して保存方針を適用できます。
バックアップの保存にフラッシュ・リカバリ領域を使用すると、新しいバックアップ、アーカイブ・ログおよびその他のファイル用のディスク領域が不足したときに、データベースが自動的に不要バックアップを削除します。バックアップをフラッシュ・リカバリ領域の外部のディスクまたはテープ上に格納する場合は、定期的にDELETE OBSOLETEコマンドを実行して不要なバックアップを削除する必要があります。
リカバリ期間ベースの保存方針を使用すると、指定した日数までは、過去の任意の時点へのPoint-in-Timeリカバリを実行できることが保証されます。保存方針に設定された、データベースをリカバリできる最も古い時点を、リカバリ可能ポイントと呼びます。リカバリ可能ポイントまでのリカバリまたはPoint-in-Timeリカバリに必要なすべてのバックアップが、保持されます。
ビジネス上の要件で、指定期間内に検出されたデータベースのすべての論理破損が修復されるように要求されている場合、リカバリ期間ベースの保存方針を使用します。リカバリ期間をその期間に設定します。
通常、リカバリ期間ベースの保存方針を満たすには、リカバリ期間の開始時点より古いバックアップを保持する必要があることに注意してください。リカバリ期間の開始時点までのPoint-in-Timeリカバリでは、この古いバックアップからリストアした後で、バックアップ作成時とリカバリ可能ポイント間のすべての変更を適用します。たとえば、リカバリ期間を3日間に設定するには、次のコマンドを実行します。
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
データベースの最後の全体バックアップを作成したのが6日前だとすると、Recovery Managerは、6日前の古いバックアップ、データベースをリカバリ期間の開始時点である3日前までロールフォワードするために必要なすべてのREDOログと、さらにデータベースを3日間のリカバリ期間のすべての時点までリカバリするために必要なバックアップおよびREDOログを保持しています。
リカバリ期間ベースのバックアップ保存方針は、最も確実なデータのリカバリ可能性を提供します。この方法の欠点は、ディスク領域の計画をより慎重に検討する必要があることです。これは、リカバリ期間を保証するために保持する必要のあるデータ・ファイルのバックアップおよびアーカイブ・ログがいくつ作成されるかわからないためです。
冗長性ベースのバックアップ保存方針は、現在ディスク上にあるバックアップの数に基づいて、バックアップが不要かどうかを判断します。たとえば、冗長性レベルを3に設定するには、次のコマンドを実行します。
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
この場合、Recovery Managerはデータベース・ファイルごとに3つのバックアップを保持し、保存されたすべてのデータ・ファイルをリカバリするために必要なすべてのREDOログを現時点の状態までバックアップします。古いバックアップは不要とみなされます。
たとえば、データ・ファイルを月曜日から毎日バックアップするとします。木曜日にデータ・ファイルの4つ目のバックアップを作成します。火曜日、水曜日、木曜日からのバックアップがあるため、月曜日からのバックアップは不要となります。金曜日には、水曜日、木曜日、金曜日からのバックアップがあるため、火曜日からのバックアップは不要となります。
データ・ファイルおよびアーカイブ・ログの古いバックアップを保存する理由はいくつかあります。
現在のリカバリ可能ポイントより前の時点をターゲットとするPoint-in-Timeリカバリを実行するには、ターゲットとする時点より前に完了したデータベースのバックアップと、バックアップの開始からターゲットとする時点までに作成されたすべてのアーカイブ・ログが必要です。たとえば、2月1日（SCN 10000）および2月14日の午前1時（SCN 20000）にバックアップを開始してデータベースの全体バックアップを作成し、2月28日の時点でPoint-in-Timeリカバリを実行して2月7日午前9時（SCN 13500）の状態のデータベースに戻すことを決定した場合は、2月1日のバックアップと、バックアップ開始時（SCN 10000）から2月7日午前9時（SCN 13500）までの変更を含むすべてのREDOログが必要になります。
リカバリ計画においては、頻繁なバックアップが重要です。バックアップの頻度は、データベースの次のような変更の割合または頻度に基づいて決定します。
データベースを更新する頻度が高いほど、データベースのバックアップをより頻繁に実行する必要があります。データベースを毎週バックアップする場合の例は、「ブロックが頻繁に変更される場合のバックアップ・スクリプト」を参照してください。
データベースの更新の頻度が比較的低い場合は、データベース全体のバックアップの頻度も低くして、増分バックアップで補足することができます（変更されたブロックがわずかなので、サイズがより小さくなります）。単一のデータベース全体のバックアップに基づいてバックアップ計画を立てる方法の例は、「少数のデータ・ブロックが変更される場合のバックアップ・スクリプト」を参照してください。
通常のバックアップ・スケジュールに関係なく、データベースのバックアップを作成する必要がある場合があります。次に示すような構造上の変更をする場合は、変更の直前および変更完了の直後に、データベースの該当部分のバックアップを作成してください。
データベースをNOARCHIVEモードで稼働している場合は、このような変更を行った後、データベースを停止して、一貫性のあるデータベース全体のバックアップを実行する必要があります。ARCHIVELOGモードで稼動している場合は、このような変更を行った後、Recovery ManagerのBACKUP CONTROLFILEコマンドまたはSQLのALTER DATABASE BACKUP CONTROLFILE文のいずれかを使用して、制御ファイルのバックアップを作成する必要があります。
ARCHIVELOGモードで稼働している場合は、個々の表領域のバックアップを作成することも、1つのデータ・ファイルのみのバックアップを作成することもできます。SYSTEM表領域および自動UNDO表領域のように、データベースで更新回数が多い1つ以上の表領域に対してこの操作を実行できます。
よく使用されるデータ・ファイルをより頻繁にバックアップすることで、リカバリに要する時間を短縮できる場合があります。ほとんどの更新がわずかな表領域に限定されているデータベースがあるとします。毎週日曜日にデータベースの全体バックアップを行うとすると、金曜日に最も頻繁に更新される表領域に影響を与えるメディア障害からのリカバリを行うには、大量のREDOを再適用する必要があります。頻繁に更新される表領域のバックアップを毎日作成すると、データベースの全体バックアップを毎日行わなくても、適用するREDOの量を削減できます。
データベースを移入するためにダイレクト・パス・ロードを実行する場合、これらのデータベース変更に関するREDOデータは記録されません。バックアップからのリストア後に、従来のメディア・リカバリを使用して、これらの変更をリカバリすることはできません。同様に、表および索引をNOLOGGINGとして作成した場合、データベースはこれらのオブジェクトに関するREDOデータを記録しないため、既存のバックアップからこれらのオブジェクトをリカバリすることはできません。そのため、REDOデータが記録されない操作を実行した後は、データ・ファイルをバックアップする必要があります。
Oracleデータベースのインポート・ユーティリティおよびエクスポート・ユーティリティは、データベースからデータベース・オブジェクト（表、ストアド・プロシージャなど）をエクスポートして、ファイルとして格納し、それらのファイルからオブジェクトを再インポートします。エクスポートは、エクスポートを実行した時点のオブジェクトの論理レベルのスナップショットを、ソース・データベースまたはその他のデータベースにインポートできるバイナリ・ファイルとして提供します。データベースのバックアップ計画において保護と柔軟性を強化するために、データベースの一部または全部のエクスポートを検討してください。
データベースのエクスポートは、有用ではありますが、データベースの全体バックアップの代替手段にはなりません。エクスポートは、物理レベルのバックアップの完全なリカバリ機能は提供できません。たとえば、アーカイブ・ログを論理バックアップに適用して、失われた変更を更新することはできません。
オンラインREDOログは、アーカイブ・ログとは異なり、バックアップされることはありません。オンラインREDOログをバックアップすることの最大の問題は、そのバックアップを意図せず誤ってリストアして、データベースが破損する可能性があることです。
また、次の理由から、オンラインREDOログのバックアップは特に有効でもありません。
ARCHIVELOGモードでデータベースを稼働している場合は、アーカイバが自動的に、一杯になったREDOログをすでにアーカイブしています。
NOARCHIVELOGモードの場合、実行できる物理バックアップは、クローズ状態で、一貫性のある、データベース全体のバックアップのみです。このタイプのバックアップのファイルは一貫性があり、リカバリの必要がないため、オンライン・ログはバックアップからのリストア後は有効ではありません。
メディア障害からオンライン・ログを保護する最適な方法は、各グループのログ・メンバーを複数にし、それぞれ異なるディスク・コントローラに接続された異なるディスクに保持して、オンライン・ログを多重化することです。
リカバリが必要な状況では、必要な情報をすべて揃えておくことが重要です。このことは、識別できない問題が発生してオラクル社カスタマ・サポート・センターへの問合せが必要になった場合に特に該当します。次のハードウェア構成に関するドキュメントが必要です。
さらに、次のソフトウェア構成に関するドキュメントが必要です。
これらの情報は、電子的な形式とハードコピーの両方で保持してください。たとえば、これらの情報をネットワーク上のテキスト・ファイルや電子メールに保存していると、システム全体が停止したときに利用できなくなる場合があります。
特に、これはDBIDのレコードを保持するために重要です。データベース（SPFILEと制御ファイルの消失を含む）をリストアおよびリカバリする必要がある場合は、リカバリ処理中にDBIDが必要になります。リカバリ中のDBIDの使用方法については、「データベースのリストアおよびリカバリの基本使用例」を参照してください。
本番システムへの移行前と移行後に、作成したバックアップおよびリカバリ方法をテスト環境で実行してください。これにより、計画が完全なものであるかどうかを判断でき、実際の環境における問題を最小限に抑えることができます。テスト・リカバリを定期的に実行することにより、アーカイブおよびバックアップ、リカバリ作業の動作を確認できます。また、リカバリ作業に日頃から慣れておくことにもなるので、実際に緊急事態が起こった場合にもミスをする危険性が少なくなります。
Recovery Managerを使用している場合は、選択肢の1つとして、本番データベースのバックアップを使用してDUPLICATEコマンドでテスト・データベースを作成できます。ユーザー管理のバックアップとリカバリを実行する場合は、バックアップをテストするために、新しいデータベース、スタンバイ・データベースまたは既存のデータベースのコピーのいずれかを作成できます。
Recovery ManagerのBACKUP... VALIDATEコマンドを使用すると、Recovery Managerは出力として実際にバックアップを作成せずに、指定されたすべてのデータベース・ファイルを読み取ります。これらのファイルは特定のバックアップ・タスクで入力されたものです。たとえば、BACKUP DATABASE VALIDATEを使用すると、Recovery Managerはデータベース全体のバックアップ時にバックアップされたすべてのファイルを読み取り、これらが正常で損失のない状態であることを確認します。入力ファイルのすべてのデータ・ブロックが、実際のバックアップを実行したときと同様に検査されます。このプロセスによって、データベースに対し有効な整合性チェックを行うことができます。
Recovery ManagerのVALIDATEおよびRESTORE VALIDATEコマンドは、リカバリ計画の継続的なテストの一部にする必要があります。VALIDATEでは、Recovery Managerはディスクまたはテープに格納されている指定されたバックアップを読み取り、これらが正常な状態で、リストア操作に使用できるかどうかをレポートします。 RESTORE... VALIDATEでは、Recovery Managerは使用可能なバックアップのセットが指定されたデータベース・オブジェクトをリストアするのに十分かどうかをチェックします。たとえば、RESTORE TABLESPACE TBS_1 VALIDATEは、Recovery Managerが実際のリストア操作で行うのと同じように、指定された表領域のリストアに十分なバックアップを選択して、そのバックアップを読み取り、存在していること、および損失がないことを確認します。
異なるハードウェアでリストアおよびリカバリ計画の完全テストを実行して、バックアップをテストすることもできます。テストで使用するハードウェアおよびソフトウェア構成は、実際の障害時リカバリの際に使用可能な環境とできるかぎり同じようにすることをお薦めします。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|