Oracle Flashback Databaseを使用すると、データ・ファイルの以前のコピーをバックアップか
らリストアせずに、データベース全体を過去のある時点の状態に戻すことができます。ただし、
これは前もってデータベースのフラッシュバック・ロギングを有効にしている場合にかぎりま す。
フラッシュバック・ロギングを有効にして、使用可能なフラッシュバック・ログが許容する範 囲内で過去の任意のSCNに戻せるようにしたり、またはデータベースの大規模な更新前など、
特定のSCNで保証付きリストア・ポイントを作成し、Oracle Flashback Databaseを使用して データベースを特定の時点の状態に確実に戻せるようにすることができます。
データベースのフラッシュバック・ロギング用または保証付きリストア・ポイント用にフラッ シュ・リカバリ領域を構成しておく必要があります。
通常のリストア・ポイントと保証付きリストア・ポイントの作成 通常のリストア・ポイントと保証付きリストア・ポイントの作成 通常のリストア・ポイントと保証付きリストア・ポイントの作成 通常のリストア・ポイントと保証付きリストア・ポイントの作成
前述のとおり、保証付きリストア・ポイントでは、Oracle Flashback Databaseを使用して確実 にデータベースを以前の特定の時点に戻すことが可能です。通常のリストア・ポイントでは、
データの保護は行われませんが便利です。これは、通常のリストア・ポイントを作成すること
で、Point-in-TimeリカバリまたはOracle Flashback Tableを使用したリカバリの操作を行う前
にデータベースのSCNを記録する必要がなくなったり、適切なSCNを特定する操作を行った 後に調査する必要がなくなるためです。
通常のリストア・ポイントを使用するには特別な設定は必要ありませんが、リストア・ポイン トが必要になる前に作成を計画する必要があります。
データベースの データベースの データベースの
データベースの Point-in-Time リカバリ リカバリ リカバリ リカバリ
Point-in-Timeリカバリを実行すると、1つの表領域またはデータベース全体を、エラーが発生
する前の状態に戻すことができます。いずれの場合も、エラーが発生する前の状態のバック アップに加えて、バックアップ時からエラー発生時までのREDOログが必要です。
論理バックアップからの消失したオブジェクトのインポート 論理バックアップからの消失したオブジェクトのインポート 論理バックアップからの消失したオブジェクトのインポート 論理バックアップからの消失したオブジェクトのインポート
影響を受けた表の内容をエクスポートして論理バックアップを実行した場合、そのデータを再 び表にインポートできることがあります。この方式は、データの論理バックアップを定期的に エクスポートすることと、エクスポート間での変更は重要でないことが前提となります。
注意注意
注意注意: Oracleのフラッシュバック・テクノロジは、様々な状況でのメ
ディア・リカバリにおいて、高速かつ確実な手段を提供します。
■ Oracle Flashback Databaseは、メディア・リカバリに類似した物理レ
ベルのリカバリ・メカニズムです。ただし、通常、メディア・リカバ リよりも高速で、バックアップからのデータのリストアを必要としま せん。
■ Oracle Flashback TableおよびOracle Flashback Dropは論理レベルで 動作し、DROP TABLE文による処理など、表に対する不要な変更を元 に戻します。
■ Oracle Flashback QueryおよびOracle Flashback Version Queryは、表 の過去の内容を参照したり、論理的な破壊によって、データベースに いつ、どのような影響があったかを調べるのに有効です。
これらの機能の詳細は、第7章「フラッシュバックおよびデータベースの
Point-in-Timeリカバリの実行」を参照してください。このマニュアルで
は、これらの機能についての有効な情報および参照先を示しています。こ れらの機能は非常に有効であり、また一部高度な計画が必要になるため、
バックアップおよびリカバリ計画を作成する前にこれらの機能についてよ く理解しておいてください。
データ・リカバリ計画の立案
メディア障害対策の立案 メディア障害対策の立案 メディア障害対策の立案
メディア障害対策の立案 : リストアおよびメディア・リカバリ リストアおよびメディア・リカバリ リストアおよびメディア・リカバリ リストアおよびメディア・リカバリ
メディア障害は、データベースの外部の問題によって、データベースの操作中にOracleのファ イル読取りまたは書込みが妨げられた場合に発生します。通常、メディア障害には、ヘッド・
クラッシュ、データベース・ファイルの上書き、削除、破損などの、物理的な障害が含まれま す。メディア障害は、ユーザー・エラーまたはアプリケーション・エラーほど一般的ではあり ませんが、バックアップおよびリカバリ計画では、メディア障害への対策を準備しておく必要 があります。
メディア障害のタイプによって、使用するリカバリ方式が決まります。たとえば、破損デー タ・ファイルのリカバリ方法と、消失した制御ファイルのリカバリ方法は異なります。
例 例 例
例 : オンライン オンライン オンライン オンライン REDO ログのリカバリ ログのリカバリ ログのリカバリ ログのリカバリ
オンライン・ログ・グループの全メンバーの消失からリカバリする方法は、次のように多数の 要因によって異なります。
■ データベースの状態（オープン、クラッシュ、一貫性のあるクローズなど）
■ 消失したREDOログ・グループが現行のものかどうか
■ 消失したREDOログ・グループがアーカイブされているかどうか 次に例を示します。
■ 現行のグループが消失し、データベースが一貫性のある状態でクローズされていない場合
（オープン状態またはクラッシュした場合）は、古いバックアップをリストアし、
Point-in-Timeリカバリを実行してから、OPENRESETLOGSを使用してオープンする必要が
あります。消失したログに含まれていたトランザクションはすべて失われます。OPEN RESETLOGSを実行した後は、データベースの新規の全体バックアップを即時に行う必要が あります。OPEN RESETLOGSを実行する前のバックアップは、ログが消失しているため、
以降のリカバリには使用できません。
■ 現行のREDOログ・グループが消失しても、データベースが一貫性のある状態でクローズ されている場合は、トランザクションを失うことなくOPENRESETLOGSを実行できます。
ただし、データベースの新規の全体バックアップを行う必要があります。OPEN
RESETLOGSを実行する前のバックアップは、ログが消失しているため、以降のリカバリ
には使用できません。
■ 現行以外のREDOログ・グループが消失した場合は、ALTERDATABASECLEARLOGFILE 文を使用してグループ内のすべてのメンバーを再作成できます。トランザクションは消失 しません。消失したREDOログ・グループが消失前にアーカイブされていた場合は、これ 以上の操作は必要ありません。ただし、データベースの新規の全体バックアップを即時に 行う必要があります。ログが消失する前のバックアップは、ログが消失しているため、以 降のリカバリには使用できません。
データ・ファイル・ブロック破損に対する対策の立案 データ・ファイル・ブロック破損に対する対策の立案 データ・ファイル・ブロック破損に対する対策の立案
データ・ファイル・ブロック破損に対する対策の立案 : ブロック・メディ ブロック・メディ ブロック・メディ ブロック・メディ ア・リカバリ
ア・リカバリ ア・リカバリ ア・リカバリ
1つ以上のデータ・ファイル内の少数のブロックが破損した場合、それらのファイルをバック アップからリストアして完全なメディア・リカバリを実行するかわりに、ブロック・メディブロック・メディブロック・メディブロック・メディ ア・リカバリ
ア・リカバリ ア・リカバリ
ア・リカバリを使用できます。Recovery ManagerのBLOCKRECOVERコマンドを使用すると、
データベースをオープンし、破損データ・ファイルがオンラインのときに、指定したデータ・
ブロックをリストアおよびリカバリできます。
参照参照
参照参照: Recovery Managerによるブロック・メディア・リカバリの実行
方法は、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・
ユーザーズ・ガイド』を参照してください。
バックアップ計画の立案
バックアップ計画の立案 バックアップ計画の立案 バックアップ計画の立案 バックアップ計画の立案
立案したデータ・リカバリ計画は、バックアップ計画の立案の基礎となります。ここでは、
データベースのバックアップを実行する時期、データベース内のバックアップが必要な部分、
Oracleが提供するバックアップ用のツール、および確実性を高めバックアップおよびリカバリ
を簡易にするためのデータベースの構成方法を決定するために役立つ、一般的なガイドライン について説明します。計画の詳細は、コスト、リソース、要員、その他の要因について、リス トア計画の要件に合わせて調整する必要があります。
冗長性セットの保護 冗長性セットの保護 冗長性セットの保護 冗長性セットの保護
Oracleデータベースを障害からリカバリする際に必要なファイルである、データ・ファイル、
制御ファイル、オンラインREDOログをまとめて冗長性セットと呼びます。冗長性セットに含 まれるものは次のとおりです。
■ 制御ファイルおよびすべてのデータ・ファイルの最終バックアップ
■ 最終バックアップ後に生成された全アーカイブREDOログ
■ Oracleデータベースの多重化機能とオペレーティング・システムのミラー化機能のいずれ
か、またはその両方で生成した現行の制御ファイルおよびオンラインREDOログ・ファイ ルの複製
■ サーバー・パラメータ・ファイル、tnsnames.ora、listener.oraなどの構成ファイル のコピー
このため、最小限の実働レベルのデータベースでも少なくとも2つのディスク・ドライブが必 要で、一方は冗長性セットのファイル保存に、もう一方はデータベース・ファイルの保存に使 用します。冗長性セットとプライマリ・ファイルは、別々のボリューム、別々のファイル・シ ステム、別々のRAIDデバイスなど、可能なかぎり様々な方法で分離して保管することをお薦 めします。
最も簡易な冗長性セットの管理方法は、フラッシュ・リカバリ領域を使用して、使用中のファ イルのセットとは別のデバイス上に置くことです。ただし、フラッシュ・リカバリ領域の使用 の有無にかかわらず、次の事例に従うことをお薦めします。
■ オンラインREDOログ・ファイルおよび現行の制御ファイルは、データベース・レベルで 多重化します。（たとえば、オンライン・ログを2つ以上の保存先に書き込むようにデータ ベースを構成して、オペレーティング・システム・レベルまたはハードウェア・レベルの 冗長性ではなく、各書込みがデータベースの個別の操作として実行されるようにします。） データベース・レベルで多重化すると、I/O障害や書込みの消失が発生しても、コピーの いずれか1つが破損するのみです。
多重化されたファイルは、異なるディスク・コントローラにマウントされた、別のディス クに保存することをお薦めします。フラッシュ・リカバリ領域は、これらのファイルの1 つをコピーするために最適な場所です。
オンラインREDOログおよび現行の制御ファイルは、オペレーティング・システム・レベ ルまたはハードウェア・レベルでミラー化することもできますが、これはデータベース・
レベルの多重化の代替手段にはなりません。
■ ARCHIVELOGモードで稼働している場合は、REDOログを複数の場所にアーカイブしま
す。異なるディスクにアーカイブすることをお薦めします。フラッシュ・リカバリ領域を 使用している場合は、これをアーカイブ先の1つとして使用します。
■ 制御ファイルには、オペレーティング・システムまたはハードウェアのミラー化を使用し ます。データベース・レベルで多重化された制御ファイルのすべてのコピーは、常に使用
注意 注意 注意
注意: 冗長性セットは、データベースのデータ・ファイル、オンライン・ロ グおよび制御ファイルが含まれているディスクには格納しないでください。
同じディスクに格納すると、ディスクはデータベースにおけるシングル・ポ イント障害となります。このディスクに障害が発生した場合は、コミット済 のトランザクションが失われます。