18 フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行

この章では、不要なデータベース変更について調べ、Oracleのフラッシュバック技術およびデータベース・バックアップに基づいた適切なリカバリ計画を選択して実行する方法について説明します。次の項目が含まれます。

• Oracleフラッシュバック技術およびデータベースのPoint-in-Timeリカバリの概要

• フラッシュバック表を使用した表の巻戻し

• フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し

• フラッシュバック・データベースを使用したデータベースの巻戻し

• データベースのPoint-in-Timeリカバリの実行

• フラッシュバックおよびデータベースのPoint-in-Timeリカバリの例

18.1 Oracleフラッシュバック技術およびデータベースのPoint-in-Timeリカバリの概要

この概要では、Oracleフラッシュバック技術およびデータベースのPoint-in-Timeリカバリの目的および基本的な概念について説明します。

18.1.1 フラッシュバックおよびデータベースのPoint-in-Timeリカバリの目的

特定の状況では、Point-in-Timeリカバリまたはフラッシュバック機能を使用して、データベースまたはデータベース・オブジェクトを前の時点の状態に戻すことが適しています。

一般的な状況は次のとおりです。

• ユーザー・エラーまたは破損によって、必要なデータが削除されるか、またはデータが破損された場合。たとえば、ユーザーまたはDBAが誤って1つ以上の表の内容を削除または更新したり、アプリケーションの更新中にまだ必要なデータベース・オブジェクトを削除したり、大規模なバッチ更新を実行して途中で障害が発生した場合などです。

• データベースのアップグレードに失敗するか、アップグレード・スクリプトが消失した場合。

• すべての必要なREDOログまたは増分バックアップがないため、メディア障害後の完全なデータベース・リカバリを正常に実行できない場合。

18.1.2 Point-in-Timeリカバリおよびフラッシュバック機能の基本的な概念

データベースのPoint-in-Timeリカバリ(DBPITR)およびフラッシュバック機能を使用すると、データベースを前の時点にリカバリできます。

DBPITRは、不要なデータベース変更に対する最も基本的な解決方法です。これは、使用可能なすべてのREDOを使用することも、データベースに対するすべての変更をリカバリすることもないため、不完全リカバリとも呼ばれます。この場合は、データベース全体のバックアップをリストアしてから、REDOログまたは増分バックアップを適用して、不要な変更の前の時点までのすべての変更を再作成します。

不要なデータベース変更が大規模ではあるが、特定の表領域に限定されている場合は、 表領域のPoint-in-Timeリカバリ(TSPITR)を使用して、影響を受けない表領域を使用可能な状態にしたまま、これらの表領域を以前のシステム変更番号(SCN)に戻すことができます。

不要なデータベース変更が特定の表または表パーティションに限定されている場合、以前に作成したRMANバックアップを使用して、これらのオブジェクトのみを不要な変更が発生する前の時点まで戻すことができます。

また、Oracle Databaseには、フラッシュバック技術と呼ばれる一連の機能も備えられています。この技術によって、バックアップからデータベースをリストアせずに、データの過去の状態を表示したり、データを任意の時点に戻したり、進めることができます。データベースに対する変更によっては、フラッシュバック技術で、データベースの可用性に与える影響を抑えてより迅速に不要な変更を無効にすることができます。

関連項目:

• RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行

• 表および表パーティションのリカバリ

18.1.2.1 非CDBに対するデータベースのPoint-in-Timeリカバリの基本的な概念

DBPITRは、物理レベルで動作し、データファイルを過去の目標時点の状態に戻します。

RMANのDBPITR操作では、目的のSCN、ログ順序、リストア・ポイントまたは時刻を指定します。RMANは、目標時点以前に作成されたバックアップからデータベースをリストアしてから、増分バックアップおよびログを適用して、データファイルをバックアップした時点とリカバリの終了時点の間のすべての変更を再作成します。終了時点がSCNとして指定されている場合、データベースは、REDOログを適用し、各REDOスレッドの後または指定したSCNのうちの早い方の時点で停止します。終了時点が時刻として指定されている場合、データベースは、指定した時刻に適したSCNを内部的に判別した後、このSCNまでリカバリします。

バックアップ計画が適切に設計され、データベースがARCHIVELOGモードで実行されている場合は、ほぼすべての状況でDBPITRを実行できます。「データベースの不完全リカバリの実行」で説明されているように、RMANのDBPITRは、ユーザー管理のDBPITRと比較すると簡略化されています。目的のSCNを指定すると、データファイルがバックアップからリストアされ、ユーザーの介入なしで効率的にリカバリが行われます。ただし、RMANのDBPITRには、次のデメリットがあります。

• 以前の状態に戻すことができるのはデータベース全体のみであり、選択したオブジェクトを以前の状態に戻すことはできません。

• DBPITRの実行中、データベース全体が使用不可になります。

• RMANはすべてのデータファイルをリストアする必要があるため、DBPITRに時間がかかる可能性があります。また、RMANは、データファイルをリカバリするためにREDOログおよび増分バックアップをリストアする必要がある場合もあります。バックアップがテープ上にある場合は、このプロセスにさらに時間がかかる可能性があります。

18.1.2.2 PDBに対するPoint-in-Timeリカバリの基本的な概念

RMANでは、1つ以上のPDBについてPoint-in-Timeリカバリをサポートします。PDBをリカバリするには、SYSDBA権限またはSYSBACKUP権限を持つユーザーとしてrootに接続する必要があります。リカバリ後、PDBの古いバックアップは有効なままのため、メディア障害が発生した場合に使用できます。

PDBのPITRを実行する場合、このPDBのすべてのデータファイルはインプレースにリカバリされます。ただし、PDBを指定した目標時点にリカバリするには、RMANでは、UNDO表領域が目標時点の状態である必要があります。共有UNDOを使用する場合、UNDO表領域はすべてのPDBで共有されるため、インプレースでリカバリすることはできません。RMANによって、rootのUNDO、SYSTEMおよびSYSAUX表領域が補助データベースにリストアされ、UNDO情報を使用してPDBが目標時点にリカバリされます。

高速リカバリ領域が構成されている場合、Oracle Databaseでは、その領域が補助の宛先として使用されます。高速リカバリ領域が構成されていない場合は、AUXILIARY DESTINATION句を使用して補助データベース・ファイルに使用される場所を指定する必要があります。root表領域およびUNDO表領域を格納するために十分な領域が高速リカバリ領域にあることを確認してください。高速リカバリ領域に必要な領域がない場合は、AUXILIARY DESTINATION句で指定する代替場所を使用します。

Data Guard環境では、PDBが特定の時点にリストアされたプライマリ・データベースにスタンバイ・データベースが続くには、スタンバイ・データベース全体をフラッシュバックするか、PDBをリストアするか、PDBをフラッシュバックする必要があります。

関連項目:

CDBおよびPDBのPoint-in-Timeリカバリの実行

18.1.2.3 フラッシュバック技術の基本的な概念

Oracle Databaseのフラッシュバック機能が使用可能なほとんどの状況では、メディア・リカバリより効率的です。フラッシュバック機能を使用すると、データベースの過去の状態を調べることができます。

18.1.2.3.1 バックアップおよびリカバリで役立つ物理フラッシュバック機能について

Oracle Flashback Databaseは、DBPITRの最も効率的な代替機能です。

他のフラッシュバック機能とは異なり、この機能は物理レベルで動作して、現行のデータファイルが過去の内容に戻されます。結果は、DBPITR(OPEN RESETLOGSを含む)の結果に類似していますが、フラッシュバック・データベースではデータファイルをリストアする必要はなく、メディア・リカバリと比較してREDOの適用が限られているため、通常、はるかに短時間でリカバリが行われます。

フラッシュバック・データベースには高速リカバリ領域が必要です。フラッシュバック・データベースのロギングを有効にするには、DB_FLASHBACK_RETENTION_TARGET初期化パラメータを設定し、ALTER DATABASE FLASHBACK ON文を発行する必要があります。

通常の操作中、データベースによって、フラッシュバック・ログにデータファイル・ブロックの古いイメージが定期的に書き込まれます。フラッシュバック・ログは順次書き込まれ、バルク書込みが行われることも多くあります。フラッシュバック・ロギングは、継続バックアップに類似しています。データベースでは、リカバリ領域に対するフラッシュバック・ログの書込み、削除およびサイズ変更が自動的に行われます。フラッシュバック・ログはアーカイブされません。フラッシュバック・ログは、パフォーマンスを監視したり、フラッシュ・リカバリ領域に対するディスク領域の割当てを決定する場合にのみ確認する必要があります。

フラッシュバック・データベース操作を行う際に、データベースは、過去のバージョンのデータ・ブロックへのアクセスにフラッシュバック・ログを使用し、アーカイブREDOログの一部のデータも使用します。したがって、障害が検出された後はフラッシュバック・データベースを有効にできなくなるため、フラッシュバック・データベースを使用してこの障害発生の前まで巻き戻します。保証付きリストア・ポイントの関連機能を使用すると、危険を伴うデータベースの変更の直前などの特定の時点のデータベースの内容を保護できます。

少量のREDO適用が必要なときにリカバリ不能な操作が発生した場合、論理的に破損したデータ・ブロックが発生します。これにより、そのようなブロックがアクセスされるときに、Oracleエラーが発生することがあります。

関連項目:

• フラッシュバック・データベースを使用したデータベースの巻戻し

• 高速リカバリ領域の構成

• Oracle Database管理者ガイド

18.1.2.3.2 バックアップおよびリカバリで役立つ論理フラッシュバック機能について

論理フラッシュバック機能は、表およびその内容を過去の時点にリカバリするために使用されます。

論理機能は次のとおりです。

• フラッシュバック表

  データベースのいずれの部分もオフラインにすることなく、表または表のセットを過去の指定した時点にリカバリできます。ほとんどの場合、フラッシュバック表を使用すると、より複雑なPoint-in-Timeリカバリ操作を行う必要がなくなります。フラッシュバック表では、表がリストアされ、同時に現在の索引、トリガーおよび制約などの関連する属性が自動的にメンテナンスされるため、ユーザーはアプリケーション固有のプロパティを検索してリストアする必要がありません。

• フラッシュバック・ドロップ

  DROP TABLE文の結果を無効にできます。

フラッシュバック・ドロップ以外のすべての論理フラッシュバック機能では、UNDOデータが使用されます。UNDOレコードは、主に、SQL問合せでの読取り一貫性の提供およびトランザクションのロールバックのために使用されます。このため、UNDOレコードには、過去の時点のデータの再構築、およびその過去の時点以降の変更のレコードの調査に必要な情報が含まれています。

フラッシュバック・ドロップでは、ごみ箱と呼ばれるメカニズムが使用されます。Oracleは、削除されたデータベース・オブジェクトの占める領域が新しいデータのために必要となるまで、ごみ箱を使用してそれらのオブジェクトを管理します。ごみ箱に割り当てられる領域の量は固定されていません。また、削除されたオブジェクトがごみ箱に残される期間については保証されていません。システム・アクティビティに応じて、削除されたオブジェクトがごみ箱に残される期間は、数秒または数か月になる場合があります。

関連項目:

• フラッシュバック表を使用した表の巻戻し

• フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し

• UNDOデータおよび自動UNDO管理の詳細は、Oracle Database管理者ガイドを参照してください

18.1.3 CDBおよびPDBでのフラッシュバック・データベースの実行の基本的な概念

マルチテナント・コンテナ・データベース(CDB)全体または特定のブラガブル・データベース(PDB)に対して、フラッシュバック・データベース操作を実行できます。

CDB全体のフラッシュバック・データベースによって、CDB全体(およびそのPDBすべてを含む)を前の特定の時点に巻き戻すことができます。特定のPDB用のフラッシュバック・データベースによって、そのPDBの論理的なデータ破損またはユーザー・エラーによって生じた不要な変更を巻き戻すことができます。特定のPDBに対してフラッシュバック・データベース操作を実行する際に、他のPDBはオープンして操作することができます。

単一のPDBに対して複数のフラッシュバック・データベース操作を実行できます。ただし、PDBのフラッシュバック操作は祖先インカネーションの1つにしか実行できません。PDBはデータベース・インカネーション全体と互換性のある過去のインカネーション内に常に存在する必要があります。

PDBのフラッシュバック・データベース操作を実行するには、PDBリストア・ポイント、CDBリストア・ポイント、SCNまたは時刻書式を使用して目的の目標時点を指定できます。PDBのCDBリストア・ポイントへのフラッシュバック操作は、PDBでのCDBインカネーションのリストア・ポイントSCNへのフラッシュバック操作と同等です。一般的に、PDBには、PDBリストア・ポイントへのフラッシュバック操作の方がCDBリストア・ポイントへのフラッシュバック操作よりも正確です。これは、PDBリストア・ポイントが、作成された特定の時点のPDBサブインカネーションを表すからです。

プライマリ・データベースでフラッシュバック・データベース操作を実行した後、フィジカル・スタンバイ・データベースのPDBに対して同じ操作を実行することもできます。

PDBのバックアップは、フラッシュバック・データベース操作がそのPDBに対して実行された後も引き続き有効です。メディア障害のケースでは、これらのPDBバックアップをリストアすることで障害からリカバリできます。PDBリカバリのこのタイプは、データベースRESETLOGSおよびPDB RESETLOGSを通じてリカバリできます。

ノート:

rootのみでフラッシュバック操作を実行することはできません。CDB全体でフラッシュバック操作を実行する必要があります。

ノート:

アプリケーション・コンテナでフラッシュバック操作を実行するには、アプリケーションrootおよびアプリケーション・コンテナの一部である個別アプリケーションPDBのすべてに対してフラッシュバック操作を実行する必要があります。アプリケーション・ルートでフラッシュバック操作を実行すると、アプリケーション・ルートが指定された時点まで戻されるだけです。

関連項目:

• CDB全体に対するフラッシュバック・データベース操作の実行

• PDBに対するフラッシュバック・データベース操作の実行

• SQL*Plusでのデータベースのフラッシュバックの実行

18.1.3.1 PDBのフラッシュバック・データベースおよびPITRについて

ローカルのUNDO、データベースPoint-in-Timeリカバリ(PITR)およびフラッシュバック操作を使用するプラガブル・データベース(PDB)はお互いに独立しています。

共有UNDO、データベースのPoint-in-Timeリカバリおよびフラッシュバック操作を使用するPDBは次の注意事項に該当しません。

• PDBのフラッシュバック操作を実行するか、特定の時点にPDBをリカバリすると、Oracle Databaseはその時点ではコミットされていないトランザクションをバックアウトするPDB RESETLOGS操作中にUNDOデータを適用できます。その後マルチテナント・コンテナ・データベース(CDB)全体をPDB RESETLOGS操作中の特定の時点にリカバリすると、一部のPDBがオープンでないという警告を受信する場合があります。そのようなPDBでは、相互に排他的な次の処理のいずれかを実行する必要があります。

  • CDB全体をリカバリするか、CDB全体から別のSCNへのフラッシュバック操作を実行します

  • 影響を受けたすべてのPDBをリカバリするか、影響を受けたすべてのPDBから別のSCNへのフラッシュバック・データベース操作を実行します

関連項目:

• CDBおよびPDBでのフラッシュバック・データベースの実行の基本的な概念

• PDBのUNDOおよびフラッシュバック・データベース操作について

• CDBでのREDOの破損の管理について

18.1.3.2 PDBのUNDOおよびフラッシュバック・データベース操作について

マルチテナント・コンテナ・データベース(CDB)は、共有UNDOまたはローカルUNDOを使用できます。フラッシュバック・データベース操作を実行するためにRMANによって使用される方法は、CDBのUNDO構成のタイプに依存します。

CDBがローカルUNDOを使用する場合、そのPDBに関連するデータファイルのみを変更すればよいため、プラガブル・データベース(PDB)でフラッシュバック・データベース操作の実行は簡単です。

共有UNDOを使用するCDBの場合、1セットの表領域がすべてのPDBで共有されるため、複数のPDBのUNDOデータはUNDO表領域内で組み合され、個々のデータ・ブロック内でも組み合わされる可能性があります。そのため、PDBのフラッシュバック・データベース操作を実行するには、RMANは自動的に補助インスタンスを使用してroot内の共有UNDO表領域および特定の表領域をリストアしてから、必要な時点に対してデータをリカバリします。このプロセスには、比較的少量のデータのバックアップのリストアが含まれます。PDBでクリーンPDBリストア・ポイントに対してフラッシュバック・データベース操作を実行する場合、補助インスタンスまたはバックアップのリストアは必要ありません。

デフォルトでは、補助インスタンスは高速リカバリ領域に作成されます。FLASHBACK DATABASEコマンドでAUXILIARY DESTINATION句を使用して、補助インスタンスに別の場所を指定できます。

関連項目:

• CDBおよびPDBでのフラッシュバック・データベースの実行の基本的な概念

• PDBのフラッシュバック・データベースおよびPITRについて

• CDBでのREDOの破損の管理について

• CDB全体に対するフラッシュバック・データベース操作の実行

• PDBに対するフラッシュバック・データベース操作の実行

18.1.3.3 CDBでのREDOの破損の管理について

RMANには、PDBのデータ・ブロックに対するREDOの破損を管理する方法が用意されています。

まれな状況ですが、マルチテナント・コンテナ・データベース(CDB)内のREDOログが壊れているとします。そのようなシナリオで、影響を受けたデータ・ブロックが1つのプラガブル・データベース(PDB)にのみ存在している場合、次のいずれかを実行できます。

• PDBで、破損前の特定の時点へのフラッシュバック操作を実行してからRESETLOGS付きでPDBをオープンします

• PDBで、破損前の特定の時点へのPoint-in-Timeリカバリを実行してからRESETLOGS付きでPDBをオープンします

PDBでのPITRまたはフラッシュバックの後にプライマリに続くスタンバイを有効化するのに必要なステップを実行した場合、プライマリ・データベースでいずれかのステップを実行した後、このプライマリ・データベースのスタンバイ・データベースも破損されたREDOをスキップできます。

関連項目:

• CDBおよびPDBでのフラッシュバック・データベースの実行の基本的な概念

• プライマリに続くようにスタンバイを有効化するステップは、Oracle Data Guard概要および管理を参照してください

18.2 フラッシュバック表を使用した表の巻戻し

フラッシュバック表では、リストアされたバックアップではなくUNDO表領域の情報を使用して、表を取得します。フラッシュバック表操作を行うと、新しい行が削除され、古い行が再度挿入されます。表のフラッシュバックの実行中、データベースの残りの部分は使用可能のままになります。

表を以前の時点に巻き戻すには:

1. フラッシュバック表の前提条件で説明している前提条件を満たしていることを確認します。

2. フラッシュバック表操作の実行の説明に従って、表に対してフラッシュバック表操作を実行します。

関連項目:

自動UNDO管理の詳細は、Oracle Database管理者ガイドを参照してください

18.2.1 フラッシュバック表の前提条件

フラッシュバック表操作を実行するには、表がフラッシュバックの対象となっており、操作を実行するユーザーに必要な権限が付与されている必要があります。

フラッシュバック表機能を使用するには、次の権限を所有している必要があります。

• FLASHBACK ANY TABLEシステム権限を付与されているか、または表に対するFLASHBACKオブジェクト権限を所有している必要があります。

• 表に対するREADまたはSELECT、INSERT、DELETEおよびALTER権限が必要です。

• 表をリストア・ポイントまでフラッシュバックするには、SELECT ANY DICTIONARYまたはFLASHBACK ANY TABLEシステム権限またはSELECT_CATALOG_ROLEロールを所有している必要があります。

オブジェクトをフラッシュバックするには、そのオブジェクトが次の前提条件を満たしている必要があります。

• オブジェクトが、クラスタの一部である表、マテリアライズド・ビュー、アドバンスト・キューイング(AQ)表、静的データ・ディクショナリ表、システム表、リモート表、オブジェクト表、ネストした表、個々の表パーティションまたは個々の表サブパーティションなどのカテゴリに含まれていないこと。

• 現在の時刻とフラッシュバックの目標時点の間に、表の構造が変更されていないこと。

  表の構造は、表の更新、移動または切捨て、表への制約の追加、クラスタへの表の追加、列の変更または削除、パーティションまたはサブパーティションの追加、削除、マージ、分割、結合または切捨て(レンジ・パーティションの追加を除く)などのデータ定義言語(DDL)操作によって変更されます。

• 行の移動が、表で有効化されていること(フラッシュバックの発生後に行IDが変更されることを意味します)。

  フラッシュバック前の行IDがアプリケーションによって保存された場合、その行IDがフラッシュバック後の同じ行に対応することは保証されないため、この制限が存在します。アプリケーションが行IDに依存している場合は、フラッシュバック表を使用することができません。

• UNDO表領域のUNDOデータの範囲が、フラッシュバック目標時点またはSCNを含む十分な範囲になっていること。

  フラッシュバック表を実行することができる時点は、UNDO保存期間(UNDOデータが再利用されるまで保存される最小時間)および表領域の特性によって決定されます。UNDOデータには、変更前のデータ・ブロックに関する情報が含まれています。フラッシュバック操作では、UNDOを使用して元のデータが再作成されます。

  フラッシュバック表操作でUNDO情報が確実に保持されるように、UNDO表領域のUNDO_RETENTIONパラメータを86400秒(24時間)以上に設定することをお薦めします。

ノート:

FLASHBACK TABLE ... TO BEFORE DROPでは、フラッシュバック表ではなくフラッシュバック・ドロップ機能が使用されるため、これらの前提条件は適用されません。詳細は、「フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し」を参照してください。

18.2.2 フラッシュバック表操作の実行

1つ以上の表でOracle Flashback Table機能を使用するには、目標時点またはSCNでFLASHBACK TABLE SQL文を使用します。

ユーザーが更新を誤って複数回実行した後、hr.temp_employees表のフラッシュバックを実行すると想定します。次のステップを実行します。

1. フラッシュバック表の前提条件で説明している前提条件を満たしていることを確認します。
2. SQL*Plusをターゲット・データベースに接続し、現行のSCNを識別します。

   FLASHBACK TABLE文はロールバックできませんが、別のFLASHBACK TABLE文を発行し、現在の時刻の直前の時刻を指定することができます。このため、現行のSCNを記録することお薦めします。これは、V$DATABASEを次のように問い合せることによって取得できます。

   SELECT CURRENT_SCN FROM V$DATABASE;
   

3. 表を戻す時刻、SCNまたはリストア・ポイントを識別します。

   リストア・ポイントを作成した場合は、次の問合せを実行して、使用可能なリストア・ポイントを表示できます。

   SELECT NAME, SCN, TIME FROM V$RESTORE_POINT;
   

4. 指定した目標時点に表を巻戻すための十分なUNDOデータが存在していることを確認します。

   UNDO_RETENTION初期化パラメータが設定されており、UNDO保存保証が有効になっている場合は、次の問合せを使用して、UNDOデータが保持される期間を確認できます。

   SELECT NAME, VALUE/60 MINUTES_RETAINED
   FROM   V$PARAMETER
   WHERE  NAME = 'undo_retention';
   

5. 行の移動が、フラッシュバック表を使用して巻き戻しているすべてのオブジェクトに対して有効になっていることを確認します。

   次のSQL文を使用して、表の行の移動を有効にできます。

   ALTER TABLE hr.temp_employees ENABLE ROW MOVEMENT;
   

6. フラッシュバック対象の表に、他の表への依存性があるかどうかを確認します。依存性が存在する場合は、それらの表をフラッシュバックするかどうかも決定します。

   次のSQL文を発行し、依存性を確認します。ここで、schema_nameはフラッシュバック対象の表のスキーマ、table_nameは表の名前です。

   SELECT other.owner, other.table_name
   FROM   sys.all_constraints this, sys.all_constraints other
   WHERE  this.owner = schema_name
   AND    this.table_name = table_name
   AND    this.r_owner = other.owner
   AND    this.r_constraint_name = other.constraint_name
   AND    this.constraint_type='R';
   

7. フラッシュバック対象のオブジェクトに対して、FLASHBACK TABLE文を実行します。

   次のSQL文を実行すると、hr.temp_employees表が、temp_employees_updateというリストア・ポイントまでリストアされます。

   FLASHBACK TABLE hr.temp_employees
     TO RESTORE POINT temp_employees_update;
   

   次のSQL文を実行すると、hr.temp_employees表の状態が、SCNで指定された時点のデータベースの状態まで巻き戻されます。

   FLASHBACK TABLE hr.temp_employees
     TO SCN 123456;
   

   次の例に示すように、TO_TIMESTAMPを使用して目標時点を指定することもできます。

   FLASHBACK TABLE hr.temp_employees
     TO TIMESTAMP TO_TIMESTAMP('2013-10-17 09:30:00', 'YYYY-MM-DD HH:MI:SS');

   ノート:

   タイムスタンプとSCNのマッピングは、常に正確であるとはかぎりません。FLASHBACK TABLE文でタイムスタンプを使用した場合、表がフラッシュバックされる時刻とTO_TIMESTAMPで指定される時刻の間で最大3秒異なることがあります。過去の正確な時点が必要な場合は、時刻ではなくSCNを使用します。

8. 必要に応じて、表を問い合せてデータを確認します。

関連項目:

フラッシュバック表中のトリガーの有効状態の保持

18.2.2.1 フラッシュバック表中のトリガーの有効状態の保持

デフォルトでは、データベースによって、FLASHBACK TABLE操作の実行前に、影響を受ける表のトリガーが無効にされます。このトリガーの状態は、操作の終了後、操作前の状態(有効または無効)に戻されます。

表のフラッシュバック中にトリガーを有効な状態のままにするには、FLASHBACK TABLE文にENABLE TRIGGERS句を追加します。

たとえば、HR管理者が17時に、hr.temp_employees表からある従業員が欠落していることに気付いたとします。この従業員は、レポートが最後に実行された14時には表に含まれていました。したがって、この従業員のレコードが誤って削除されたのは、14時から17時の間です。HR管理者は、フラッシュバック表を使用して、hr.temp_employees表に設定されているすべてのトリガーを有効にして、表を午後2時の状態に戻しますが、これには次の例のSQL文を使用します。

FLASHBACK TABLE hr.temp_employees
  TO TIMESTAMP TO_TIMESTAMP('2013-03-03 14:00:00' , 'YYYY-MM-DD HH:MI:SS') 
  ENABLE TRIGGERS;

関連項目:

• フラッシュバック表機能を使用して表をリカバリする方法を学習するには、Oracle Database管理者ガイドを参照してください

• フラッシュバック表の簡単なシナリオは、Oracle Database SQL言語リファレンスを参照してください

18.3 フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し

FLASHBACK TABLE ... TO BEFORE DROP文を使用して、ごみ箱からオブジェクトを取得できます。

この項では、次の項目について説明します。

• フラッシュバック・ドロップ

• フラッシュバック・ドロップの前提条件

• フラッシュバック・ドロップ操作の実行

18.3.1 フラッシュバック・ドロップについて

フラッシュバック・ドロップによって、DROP TABLE操作の結果を無効にできます。フラッシュバック・ドロップは、この状況で使用できる他のリカバリ・メカニズム(Point-in-Timeリカバリなど)より高速です。また、フラッシュバック・ドロップによって、停止時間または最新のトランザクションの消失は発生しません。

表を削除した場合、その表に関連付けられている領域はデータベースによってすぐには削除されません。かわりに、表は、名前を変更され、関連付けられているすべてのオブジェクトとともにごみ箱に配置されます。ごみ箱内のオブジェクトのシステム生成名は一意です。他のオブジェクトを問い合せる場合と同様に、ごみ箱内のオブジェクトを問い合せることができます。

フラッシュバック操作では、ごみ箱から表が取り出されます。削除された表を取得する場合は、ユーザーが指定した表の元の名前またはシステム生成の名前を使用できます。

表を削除すると、表およびそれに依存するすべてのオブジェクトが同時にごみ箱に移動されます。同様に、フラッシュバック・ドロップを実行すると、通常、すべてのオブジェクトが同時に取得されます。リサイクル・ビンから表をリストアすると、索引などの依存オブジェクトは元の名前が復元されず、システム生成のリサイクル・ビンの名前のままになります。Oracle Databaseでは、表に定義されたすべての索引(ビットマップ結合索引を除く)、および表に定義されたすべてのトリガーと制約(他の表を参照する参照整合性制約を除く)が取得されます。

索引などの依存オブジェクトの一部は、領域圧迫のため再利用される場合があります。この場合、再利用された依存オブジェクトは、ごみ箱から取得できません。

18.3.2 フラッシュバック・ドロップの前提条件

フラッシュバック・ドロップ操作を実行する前に、前提条件を満たしている必要があります。

フラッシュバック・ドロップおよびごみ箱に関連する操作に必要なユーザー権限は、次のとおりです。

• DROP

  オブジェクトに対してDROP権限を持つすべてのユーザーは、オブジェクトを削除し、ごみ箱に配置できます。

• FLASHBACK TABLE ... TO BEFORE DROP

  この文に対する権限は、DROP権限に関連付けられています。つまり、オブジェクトを削除できるすべてのユーザーは、フラッシュバック・ドロップを実行して、削除済オブジェクトをごみ箱から取得できます。

• PURGE

  ごみ箱の消去に対する権限は、DROP権限に関連付けられています。DROP TABLE権限、DROP ANY TABLE権限またはPURGE DBA_RECYCLE_BIN権限を持つユーザーは、ごみ箱からオブジェクトを消去できます。

• ごみ箱内のオブジェクトに対するREADまたはSELECTおよびFLASHBACK

  ごみ箱のオブジェクトの問合せを行う場合、ユーザーは、ごみ箱のオブジェクトに対してREADまたはSELECTおよびFLASHBACK権限を所有している必要があります。削除前のオブジェクトに対してREADまたはSELECT権限を所有していたすべてのユーザーは、ごみ箱内のそのオブジェクトに対してREADまたはSELECT権限を継続して所有します。ごみ箱内のオブジェクトは過去の状態のデータベースのオブジェクトであるため、これらのオブジェクトを問い合せるには、ユーザーはFLASHBACK権限が必要です。

ごみ箱からオブジェクトを取得するには、オブジェクトが次の要件を満たしている必要があります。

• システム表領域ではないローカル管理表領域に対してのみごみ箱が使用可能であること。表がシステム表領域ではないローカル管理表領域に含まれていて、その依存セグメント(オブジェクト)がディクショナリ管理表領域に含まれている場合、これらのオブジェクトはごみ箱によって保護されます。

• ファイングレイン監査ポリシー(FGA)およびVirtual Private Database (VPD)ポリシーが定義されている表が、ごみ箱によって保護されていないこと。

• パーティション化された索引構成表が、ごみ箱によって保護されていないこと。

• 領域再利用操作で、ユーザーまたはOracle Databaseのいずれかによって表が削除されていないこと。

18.3.3 フラッシュバック・ドロップ操作の実行

FLASHBACK TABLE ... TO BEFORE DROP文を使用すると、ごみ箱からオブジェクトをリカバリできます。ごみ箱内の表の名前または元の表の名前のいずれかを指定できます。

この項では、誤った表を削除した例を想定しています。テスト・データベースで表の削除を複数回要求されましたが、この場合、かわりに本番データベースに誤って接続し、hr.employee_demoを削除したとします。FLASHBACK TABLEを使用し、削除されたオブジェクトを取得します。

削除された表を取得するには:

1. フラッシュバック・ドロップの前提条件で説明している前提条件を満たしていることを確認します。
2. SQL*Plusをターゲット・データベースに接続し、ごみ箱内の削除された表の名前を取得します。

   SQL*PlusコマンドSHOW RECYCLEBINは、次のように使用できます。

   SHOW RECYCLEBIN;
   
   ORIGINAL NAME    RECYCLEBIN NAME                   TYPE         DROP TIME
   ---------------- --------------------------------- ------------ -------------
   EMPLOYEE_DEMO    BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0  TABLE    2013-04-11:17:08:54
   

   ORIGINAL NAME列には、オブジェクトの元の名前が表示され、RECYCLEBIN NAME列には、ごみ箱内でのオブジェクトの名前が表示されます。

   また、USER_RECYCLEBINまたはDBA_RECYCLEBINを問い合せて表の名前を取得することもできます。次の例では、RECYCLEBINビューを問い合せて、削除されたオブジェクトの元の名前を確認します。

   SELECT object_name AS recycle_name, original_name, type 
   FROM   recyclebin;
   
   RECYCLE_NAME                      ORIGINAL_NAME          TYPE
   --------------------------------  ---------------------  ----------
   BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0  EMPLOYEE_DEMO          TABLE
   BIN$JKS983293M1dsab4gsz/I249==$0  I_EMP_DEMO             INDEX
   

   依存オブジェクトの元の名前を手動でリストアする場合は、表をリストアする前に、各依存オブジェクトのごみ箱内のシステム生成の名前をノートにとっておいてください。

   ノート:

   DBA_TABLESなどのオブジェクト・ビューには、ごみ箱オブジェクトは表示されません。

3. 必要に応じて、ごみ箱内の表を問い合せます。

   問合せでは、オブジェクトの元の名前ではなく、オブジェクトのごみ箱内の名前を使用する必要があります。次の例では、BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0というごみ箱内の名前を持つ表を問い合せます。

   SELECT * 
   FROM  "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0";
   

   ごみ箱内の名前に特殊文字が含まれているため、引用符が必要です。

   ノート:

   必要な権限を所有している場合は、ごみ箱内の表に対してフラッシュバック問合せを使用できますが、表の元の名前ではなく、ごみ箱内の名前を使用する必要があります。ゴミ箱内のオブジェクトにはデータ操作言語(DML)またはDDL文は使用できません。

4. 削除された表を取得します。

   FLASHBACK TABLE ... TO BEFORE DROP文を使用します。次の例では、BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0表をリストアし、その名前をhr.employee_demoに戻して、そのエントリをごみ箱から消去します。

   FLASHBACK TABLE "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0" TO BEFORE DROP;
   

   ごみ箱内のオブジェクト名に特殊文字が含まれる可能性があるため、表の名前が引用符で囲まれています。

   また、次のようにして、表の元の名前を使用することもできます。

   FLASHBACK TABLE HR.EMPLOYEE_DEMO TO BEFORE DROP;
   

   RENAME TO句を指定することによって、リストアされた表に新しい名前を割り当てることもできます。次に例を示します。

   FLASHBACK TABLE "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0" TO BEFORE DROP 
     RENAME TO hr.emp_demo;
   

5. 必要に応じて、すべての依存オブジェクトがごみ箱内のシステム生成の名前を保持していることを確認します。

   次の問合せによって、取得されたhr.employee_demo表の索引の名前を確認します。

   SELECT INDEX_NAME 
   FROM   USER_INDEXES 
   WHERE  TABLE_NAME = 'EMPLOYEE_DEMO';
   
   INDEX_NAME
   ------------------------------
   BIN$JKS983293M1dsab4gsz/I249==$0
   

6. 必要に応じて、取得された索引を元の名前に変更します。

   次の文を実行すると、索引がその元の名前であるi_emp_demoに変更されます。

   ALTER INDEX "BIN$JKS983293M1dsab4gsz/I249==$0" RENAME TO I_EMP_DEMO;
   

7. 取得された表に、ごみ箱に配置される前に参照制約が含まれていた場合は、その参照制約を再作成します。

   ごみ箱では表に対する参照制約が保存されないため、このステップは手動で実行する必要があります。

関連項目:

元の名前が同じオブジェクトが複数存在する場合のフラッシュバック・ドロップを使用したオブジェクトの取出し

18.3.3.1 元の名前が同じオブジェクトが複数存在する場合のフラッシュバック・ドロップを使用したオブジェクトの取出し

複数のオブジェクトを同じ元の名前で作成し、その後削除できます。削除されたすべてのオブジェクトは、ごみ箱に保存されます。

たとえば、次の例のSQL文について考えてみます。

例18-1 同じ名前の複数オブジェクトの削除

CREATE TABLE temp_employees ( ...columns ); # temp_employees version 1
DROP TABLE temp_employees;

CREATE TABLE temp_employees ( ...columns ); # temp_employees version 2
DROP TABLE temp_employees;

CREATE TABLE temp_employees ( ...columns ); # temp_employees version 3
DROP TABLE temp_employees;

temp_employees表が削除されるたびに、ごみ箱の中でそれぞれに一意の名前が割り当てられます。次の例に示すように、FLASHBACK TABLE ... TO BEFORE DROP文は、表の元の名前を指定して使用できます。

FLASHBACK TABLE temp_employees TO BEFORE DROP;

この元の名前で最後に削除された表は、その元の名前でごみ箱から取得されます。

次の例では、前の例で削除された3つすべてのtemp_employees表が、それぞれ新しい名前を割り当てられてごみ箱から取得されています。

例18-2 削除された表の名前の変更

FLASHBACK TABLE temp_employees TO BEFORE DROP 
  RENAME TO temp_employees_VERSION_3;
FLASHBACK TABLE temp_employees TO BEFORE DROP 
  RENAME TO temp_employees_VERSION_2;
FLASHBACK TABLE temp_employees TO BEFORE DROP 
  RENAME TO temp_employees_VERSION_1;

FLASHBACK TABLEでの元の名前はこの名前で最後に削除された表を参照するため、最後に削除された表が最初に取得されます。

また、元の名前が競合している場合でも、ごみ箱内の一意の名前を使用して、すべての表をごみ箱から取得することができます。たとえば、ごみ箱を次のように問い合せます(出力例も示します)。

SELECT object_name, original_name, createtime 
FROM   recyclebin;    

OBJECT_NAME                    ORIGINAL_NAME   CREATETIME
------------------------------ --------------- -------------------
BIN$yrMKlZaLMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES  2013-02-05:21:05:52
BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES  2013-02-05:21:25:13
BIN$yrMKlZaQMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES  2013-02-05:22:05:53

次のコマンドを使用すると、中間の表を取得できます。

FLASHBACK TABLE BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TO BEFORE DROP;

関連項目:

• フラッシュバック・ドロップを使用する方法およびごみ箱を管理する方法を学習するには、Oracle Database管理者ガイドを参照してください

• FLASHBACK TABLE文の詳細は、Oracle Database SQL言語リファレンスを参照してください

18.4 フラッシュバック・データベースを使用したデータベースの巻戻し

フラッシュバック・データベースでは、データベースを前の時点の状態に戻して、不要な変更を元に戻します。

この項では、次の項目について説明します。

• フラッシュバック・データベースの前提条件

• フラッシュバック・データベース操作の実行

• CDB全体に対するフラッシュバック・データベース操作の実行

• PDBに対するフラッシュバック・データベース操作の実行

• フラッシュバック・データベースの監視

18.4.1 フラッシュバック・データベースの前提条件

フラッシュバック・データベースでは、コマンド実行時に存在した、データファイルに対する変更が取り消されます。フラッシュバック・データベース操作を実行するには、前提条件を満たしている必要があります。

FLASHBACK DATABASEコマンドを使用してフラッシュバック・ウィンドウ内の時点にデータベースの内容を戻すには、事前にデータベースをフラッシュバック・ロギング用に構成しておく必要があります。保証付きリストア・ポイントにデータベースを戻すには、保証付きリストア・ポイントを事前に定義しておく必要があります。

重要な前提条件は、次のとおりです。

• 現行のデータファイルが消失または破損していないこと。FLASHBACK DATABASEは、Oracle Databaseで行われたデータファイルに対する変更の巻戻しにのみ使用できます。メディア障害の修復には使用できません。

• データファイルの誤った削除からのリカバリ、データファイルの縮小操作の取消しまたはデータベース名の変更の取消しをしようとしていないこと。

• 制御ファイルのリストアまたは再作成前の時点に戻すためにFLASHBACK DATABASEを使用しようとしていないこと。データベース制御ファイルがバックアップからリストアされるか、または再作成されると、すべての累積フラッシュバック・ログ情報が破棄されます。

• 互換性の変更を取り消すためにFLASHBACK DATABASEを使用しようとしていないこと。

関連項目:

• フラッシュバック・データベース、リストア・ポイントおよび保証付きリストア・ポイントの概要

• 通常のリストア・ポイントと保証付きリストア・ポイントの使用

• FLASHBACK DATABASEのコマンドの前提条件および使用上のノートの完全なリストは、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください

18.4.2 フラッシュバック・データベース操作の実行

フラッシュバック・データベース操作では、FLASHBACK DATABASEコマンドを使用してデータベースを過去の時点に巻き戻します。

このトピックでは、時刻書式、通常のリストア・ポイントまたは保証付きリストア・ポイントの名前、あるいはSCNを使用して目的の目標時点を指定し、データベースのフラッシュバックを実行する基本的な方法について説明します。ここでは、次のことを想定しています。

• 現行のデータベースのインカネーション内の時点までデータベースを巻き戻します。

• FLASHBACK DATABASEコマンドで使用されるSCNは、データベース・インカネーションの直系祖先パス内のSCNを参照します。データベースを以前にRESETLOGSオプションでオープンした後、インカネーションを取り消さなかった場合、インカネーションはこのパス内にあります。

フラッシュバック・データベース操作を実行するには:

1. フラッシュバック・データベースの前提条件で説明している前提条件を満たしていることを確認します。
2. SQL*Plusをターゲット・データベースに接続し、FLASHBACK DATABASEコマンドに必要なSCN、リストア・ポイントまたは時点を確認します。

   次のように入力して、フラッシュバック・データベース・ウィンドウ内の最も古いSCNを取得します。

   SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME
   FROM   V$FLASHBACK_DATABASE_LOG;
   

   フラッシュバック・データベースで到達できる最新のSCNは、データベースの現行のSCNです。次の問合せを実行すると、現行のSCNが戻されます。

   SELECT CURRENT_SCN FROM V$DATABASE;
   

   使用可能な保証付きリストア・ポイントは、次のように問い合せることができます(出力例も示します)。

   SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
          GUARANTEE_FLASHBACK_DATABASE
   FROM   V$RESTORE_POINT
   WHERE  GUARANTEE_FLASHBACK_DATABASE='YES';
    
   NAME                   SCN TIME                  DATABASE_INCARNATION# GUA
   --------------- ---------- --------------------- --------------------- ---
   BEFORE_CHANGES     5753126 04-MAR-12 12.39.45 AM                     2 YES

   ノート:

   フラッシュバック・ウィンドウが目的の目標時点に達する過去の時点まで提供されておらず、その目的の時点での保証付きリストア・ポイントが存在しない場合は、同じ結果を得るために、データベースのPoint-in-Timeリカバリを使用できます。詳細は、「データベースのPoint-in-Timeリカバリの実行」を参照してください。

3. データベースを、一貫性のある状態で停止し、インスタンスによってオープンされていないことを確認してからマウントします。

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   

4. ステップ2で実行した問合せを繰り返します。

   データベースが停止されている場合は、一部のフラッシュバック・ロギング・データが生成されます。高速リカバリ領域での領域圧迫が原因でフラッシュバック・ログが削除された場合は、目的のSCNが取得不可になっている可能性があります。

   ノート:

   目的のSCNがフラッシュバック・ウィンドウの範囲外にある場合にFLASHBACK DATABASEを実行すると、FLASHBACK DATABASEは失敗し、ORA-38729エラーが戻されます。この場合、データベースは変更されません。

5. RMANを開始し、RMANによるデータベース接続の確立の説明に従ってターゲット・データベースに接続します。
6. SHOWコマンドを実行して、事前構成済のチャネルを確認します。

   フラッシュバック操作中、RMANは、バックアップからアーカイブREDOログをリストアする必要がある場合があります。次のコマンドを入力し、自動チャネルが構成されているかどうかを確認します(出力例も示します)。

   SHOW ALL;
   
   RMAN configuration parameters for database with db_unique_name PROD1 are:
   .
   .
   .
   CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
   CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
   CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
   CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  "SBT_LIBRARY=/usr/local/oracle/backup/lib/libobk.so";
   

   必要なデバイスおよびチャネルが構成されている場合、操作は必要ありません。そうでない場合は、CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。

7. RMANのFLASHBACK DATABASEコマンドを実行します。

   次の例に示されるコマンドの形式を使用して、目標時点を指定できます。

   FLASHBACK DATABASE TO SCN 46963;
   
   FLASHBACK DATABASE 
     TO RESTORE POINT BEFORE_CHANGES;
   
   FLASHBACK DATABASE TO TIME   
     "TO_DATE('09/20/12','MM/DD/YY')";
   

   FLASHBACK DATABASEコマンドが完了すると、データベースはマウントされたまま、指定した目標時点にリカバリされています。

8. SQL*Plusを使用してデータベースを読取り専用でオープンし、いくつかの問合せを実行して、データベースの内容を検証します。

   次のように入力して、データベースを読取り専用でオープンします。

   ALTER DATABASE OPEN READ ONLY;
   

   データベースの状態が適切である場合は、ステップ9で手順を終了します。データベースの状態が適切でない場合は、ステップ10に進みます。

9. 結果が適切である場合は、相互に排他的な次の処理のいずれかを実行します。

   • RESETLOGSオプションを指定してデータベースをオープンし、データベースを更新可能な状態にします。データベースが現在読取り専用でオープンされている場合は、SQL*Plusで次のコマンドを実行します。

     SHUTDOWN IMMEDIATE
     STARTUP MOUNT
     ALTER DATABASE OPEN RESETLOGS;

     ノート:

     このOPEN RESETLOGS操作を実行した後、FLASHBACK DATABASEの目的のSCN以降に行われたデータベースへの変更はすべて破棄されます。ただし、「取り消されたインカネーション・ブランチ内のSCNへのデータベースの巻戻し」に示す方法を使用すると、複数のSCNがフラッシュバック・ウィンドウ内にあるかぎり、データベースをそれぞれのSCNの範囲まで戻すことができます。

   • Oracle Data Pump Exportを使用し、破損状態のオブジェクトの論理バックアップを行います。その後、RMANを使用して、データベースを現在の時刻までリカバリします。

     RECOVER DATABASE;
     

     このステップでは、REDOログ内のすべての変更をデータベースに再適用してフラッシュバック・データベースの影響を取り消し、データベースを最新のSCNまで戻します。

     データベースを読取り/書込みで再びオープンした後、データ・ポンプ・インポート・ユーティリティを使用してエクスポートされたオブジェクトをインポートできます。データ・ポンプを使用する方法を学習するには、Oracle Databaseユーティリティを参照してください。

10. フラッシュバックで誤ったリストア・ポイント、時刻またはSCNを使用した場合は、データベースをマウントし、次の相互に排他的ないずれかのオプションを実行します。

    • 選択した目標時点が十分に前の時点でなかった場合は、別のFLASHBACK DATABASEコマンドを使用し、データベースをさらに巻き戻します。

      FLASHBACK DATABASE TO SCN 42963;  #earlier than current SCN 
      

    • 選択した目的のSCNが前過ぎる場合は、RECOVER DATABASE UNTILを使用してデータベースを必要なSCNまで進めます。

      RECOVER DATABASE UNTIL SCN 56963; #later than current SCN 
      

    • FLASHBACK DATABASEコマンドの影響を完全に取り消す必要がある場合は、UNTIL句またはSET UNTILコマンドを指定しないでRECOVER DATABASEコマンドを使用することによって、データベースの完全リカバリを実行できます。

      RECOVER DATABASE;
      

      RECOVER DATABASEコマンドを実行すると、すべての変更がデータベースに再適用され、データベースが最新のSCNまで戻されます。

    関連項目:

    • 最後のOPEN RESETLOGS操作の直前の時点にデータベースを戻すには、フラッシュバック・データベースを使用したOPEN RESETLOGS操作の巻戻しを参照してください。

    • 取り消されたインカネーション内の変更を取得するには、取り消されたインカネーション・ブランチ内のSCNへのデータベースの巻戻しを参照してください。

18.4.3 CDB全体に対するフラッシュバック・データベース操作の実行

FLASHBACK DATABASEコマンドを使用して、マルチテナント・コンテナ・データベース(CDB)全体に対してフラッシュバック・データベース操作を実行できます。

COMPATIBLE初期化パラメータが12.1.0に設定されている場合、まれに、PDB (プラガブル・データベース)のPoint-in-Timeリカバリ(PITR)全体に渡るCDBまたはPDBフラッシュバックでフラッシュバック・データベース操作を実行すると、次のようなエラーになる場合があります。

ORA-39866: 特別な12.1 PDBリセット・ログ全体にわたってフラッシュバックするには、プラガブル・データベース<PDB_name>のデータ・ファイルをオフラインにする必要があります。

このエラーを解決して、PDB PITR全体に渡るCDBまたはPDBフラッシュバックでフラッシュバック操作を実行するには、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド12cリリース1 (12.1)』のPDBがDBPITRを使用してリカバリされた場合のCDB上でのフラッシュバック・データベース操作の実行に関する項で説明しているステップに従います。

CDBのフラッシュバック・データベース操作を実行するステップは非CDBに使用するステップと同様ですが、このトピックで説明する相違点があります。

CDB全体に対するフラッシュバック・データベース操作を実行するには:

1. フラッシュバック・データベースの前提条件で説明している前提条件を満たしていることを確認します。
2. SQL*PlusをターゲットCDBに接続し、FLASHBACK DATABASEコマンドに必要なSCN、リストア・ポイントまたは時点を確認します。

   次のように入力して、フラッシュバック・データベース・ウィンドウ内の最も古いSCNを取得します。

   SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME
   FROM   V$FLASHBACK_DATABASE_LOG;
   

   フラッシュバック・データベースで到達できる最新のSCNは、データベースの現行のSCNです。次の問合せを実行すると、現行のSCNが戻されます。

   SELECT CURRENT_SCN
   FROM   V$DATABASE;
   

   使用可能な保証付きリストア・ポイントは、次のように問い合せることができます(出力例も示します)。

   SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
          GUARANTEE_FLASHBACK_DATABASE
   FROM   V$RESTORE_POINT
   WHERE  GUARANTEE_FLASHBACK_DATABASE='YES';
    
   NAME                   SCN TIME                  DATABASE_INCARNATION# GUA
   --------------- ---------- --------------------- --------------------- ---
   BEFORE_CHANGES     5753126 04-MAR-12 12.39.45 AM                     2 YES

   ノート:

   フラッシュバック・ウィンドウが目的の目標時点に達する過去の時点まで提供されておらず、その目的の時点での保証付きリストア・ポイントが存在しない場合は、同じ結果を得るために、データベースのPoint-in-Timeリカバリを使用できます。詳細は、「CDB全体へのPoint-in-Timeリカバリの実行」を参照してください。

3. データベースを、一貫性のある状態で停止し、インスタンスによってオープンされていないことを確認してからマウントします。

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   

4. ステップ2で実行した問合せを繰り返します。

   データベースが停止されている場合は、一部のフラッシュバック・ロギング・データが生成されます。高速リカバリ領域での領域圧迫が原因でフラッシュバック・ログが削除された場合は、目的のSCNが取得不可になっている可能性があります。

   ノート:

   目的のSCNがフラッシュバック・ウィンドウの範囲外にある場合にFLASHBACK DATABASEを実行すると、FLASHBACK DATABASEは失敗し、ORA-38729エラーが戻されます。この場合、データベースは変更されません。

5. RMANによるデータベース接続の確立の説明に従って、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。
6. 事前構成済のチャネルを確認するには、SHOWコマンドを実行します。

   フラッシュバック操作中、RMANは、バックアップからアーカイブREDOログをリストアする必要がある場合があります。チャネルが構成されているかどうかを確認するには、次のコマンドを入力します(出力例も示します)。

   SHOW ALL;
   

   必要なデバイスおよびチャネルが構成されている場合、操作は必要ありません。そうでない場合は、CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。

7. FLASHBACK DATABASEコマンドを実行して、指定した時点へのCDB全体のフラッシュバック操作を実行します。

   SCN、時刻書式またはCDBリストア・ポイントを使用して目標時点を指定できます。

   次の例は、CDB全体に対するフラッシュバック・データベース操作を実行します。

   FLASHBACK DATABASE TO SCN 345588;
   FLASHBACK DATABASE TO RESTORE POINT cdb_before_upgrade;

8. SQL*Plusを使用してCDBを読取り専用でオープンし、いくつかの問合せを実行して、データベースの内容を検証します。

   次のように入力して、CDBを読取り専用でオープンします。

   ALTER DATABASE OPEN READ ONLY;
   

   データベースの状態が適切である場合は、ステップ9で手順を終了します。データベースの状態が適切でない場合は、ステップ10に進みます。

9. 結果が適切である場合は、相互に排他的な次の処理のいずれかを実行します。

   • RESETLOGSオプションを指定してデータベースをオープンし、データベースを更新可能な状態にします。データベースが読取り専用でオープンされている場合は、SQL*Plusで次のコマンドを実行します。

     SHUTDOWN IMMEDIATE
     STARTUP MOUNT
     ALTER DATABASE OPEN RESETLOGS;

     ノート:

     このOPEN RESETLOGS操作を実行した後、FLASHBACK DATABASEの目的のSCN以降に行われたデータベースへの変更はすべて破棄されます。ただし、「取り消されたインカネーション・ブランチ内のSCNへのデータベースの巻戻し」に示す方法を使用すると、複数のSCNがフラッシュバック・ウィンドウ内にあるかぎり、データベースをそれぞれのSCNの範囲まで戻すことができます。

   • Oracle Data Pump Exportを使用して、破損状態のオブジェクトの論理バックアップを作成します。その後、RMANを使用して、データベースを現在の時刻までリカバリします。

     RECOVER DATABASE;
     

     このステップでは、REDOログ内のすべての変更をデータベースに再適用してフラッシュバック・データベースの影響を取り消し、データベースを最新のSCNまで戻します。

     データベースを読取り/書込みで再びオープンした後、データ・ポンプ・インポート・ユーティリティを使用してエクスポートされたオブジェクトをインポートできます。データ・ポンプを使用する方法を学習するには、『Oracle Databaseユーティリティ』を参照してください。

10. フラッシュバックで誤ったリストア・ポイント、時刻またはSCNを使用した場合は、データベースをマウントし、次の相互に排他的ないずれかのオプションを実行します。

    • 選択した目標時点が十分に前の時点でなかった場合は、別のFLASHBACK DATABASEコマンドを使用し、データベースをさらに巻き戻します。

      FLASHBACK DATABASE TO SCN 42963;  #earlier than current SCN 
      

    • 選択した目的のSCNが前過ぎる場合は、RECOVER DATABASE UNTILを使用してデータベースを必要なSCNまで進めます。

      RECOVER DATABASE UNTIL SCN 56963; #later than current SCN 
      

    • FLASHBACK DATABASEコマンドの影響を完全に取り消す必要がある場合は、UNTIL句またはSET UNTILコマンドを指定しないでRECOVER DATABASEコマンドを使用することによって、データベースの完全リカバリを実行できます。

      RECOVER DATABASE;
      

      RECOVER DATABASEコマンドを実行すると、すべての変更がデータベースに再適用され、データベースが最新のSCNまで戻されます。

11. PDBは、CDBがオープンされたときに自動的にはオープンしないため、PDBをオープンします。

    次のコマンドは、rootに接続している場合、すべてのPDBをオープンします。

    ALTER PLUGGABLE DATABASE ALL OPEN;

    いくつかのPDBのみをオープンするには、各PDBを個別にオープンすることもできます。次のコマンドは、rootに接続するとPDB my_pdbをオープンします。

    ALTER PLUGGABLE DATABASE my_pdb OPEN;

関連項目:

• CDBリストア・ポイントについて

• CDBでのREDOの破損の管理について

• PDBに対するフラッシュバック・データベース操作の実行

18.4.4 PDBに対するフラッシュバック・データベース操作の実行

FLASHBACK DATABASEコマンドを使用して、マルチテナント・コンテナ・データベース(CDB)の単一のプラガブル・データベース(PDB)に対してフラッシュバック・データベース操作を実行できます。

特定のPDBでフラッシュバック・データベース操作を実行すると、そのPDBに関連するデータファイルのみを変更します。CDB内のその他のPDBは影響を受けず、使用できます。

リストア・ポイントを使用する際に、フラッシュバック・データベース操作をCDBリストア・ポイント、PDBリストア・ポイント、PDBクリーン・リストア・ポイントまたはPDB保証付きリストア・ポイントのいずれかに対して実行できます。

PDBに対するフラッシュバック・データベース操作を実行するには:

1. SYSDBA権限またはSYSBACKUP権限を持つ共通ユーザーとして、rootに接続します。

   「RMANによるデータベース接続の確立」を参照してください。

2. CDBが開いていることを確認します。

   rootに接続すると、次のコマンドによって、CDBがオープンになっているモードが表示されます。

   SELECT open_mode from V$DATABASE;

3. フラッシュバック・データベース・コマンドのために、必要なSCN、リストア・ポイントまたは特定の時点を決定します。
   V$RESTORE_POINTビューを問い合せて、PDBリストア・ポイントのリストを取得します。V$FLASHBACK_DATABASE_LOGは、フラッシュバック操作を実行できる最も古いSCNを表示します。
4. フラッシュバック・データベース操作を実行する必要のあるPDBがクローズされていることを確認します。他のPDBは、オープンで操作可能な状態でもかまいません。

   rootに接続すると、次のALTER PLUGGABLE DATABASEコマンドがmy_pdbというPDBをクローズします。

   ALTER PLUGGABLE DATABASE my_pdb CLOSE;

5. 指定したPDBで、希望する特定の時点に対してフラッシュバック・データベース操作を実行します。

   PDBでのフラッシュバック・データベース操作の例をいくつか次に示します。

   • ローカルUNDOを使用するPDBに対しては次のとおりです。

     FLASHBACK PLUGGABLE DATABASE my_pdb TO SCN 24368;
     

     FLASHBACK PLUGGABLE DATABASE my_pdb TO RESTORE POINT guar_rp;

     FLASHBACK PLUGGABLE DATABASE my_pdb TO CLEAN RESTORE POINT clean_rp;

   • 共有UNDOを使用するPDBに対しては、オプションでAUXILIARY DESTINATION句を含め、フラッシュバック・データベース操作の一部としてリストアされたデータファイルを格納する補助インスタンスの場所を指定します。この句を省略した場合、補助インスタンスは高速リカバリ領域に作成されます。

     FLASHBACK PLUGGABLE DATABASE my_pdb TO SCN 24368 AUXILIARY DESTINATION '+data';
     

     FLASHBACK PLUGGABLE DATABASE my_pdb TO RESTORE POINT before_appl_changes AUXILIARY DESTINATION '/temp/aux_dest';

     FLASHBACK PLUGGABLE DATABASE my_pdb TO TIME "TO_DATE('03/20/15','MM/DD/YY')";

6. RESETLOGS付きでPDBをオープンします。

   次のコマンドは、my_pdbという名前のPDBをRESETLOGS付きでオープンします。

   ALTER PLUGGABLE DATABASE my_pdb OPEN RESETLOGS;

ノート:

プロキシPDBでは、フラッシュバック操作はサポートされていません。

ノート:

• PDBでのリストア・ポイントについて

• V$RESTORE_POINTビューを使用したリストア・ポイントの表示

• PDBのUNDOおよびフラッシュバック・データベース操作について

• CDBおよびPDBでのフラッシュバック・データベースの実行の基本的な概念

• CDB全体に対するフラッシュバック・データベース操作の実行

18.4.5 フラッシュバック・データベースの監視

データ・ディクショナリ・ビューには、フラッシュバック・データベースの監視に使用される情報が含まれます。

フラッシュバック・データベースを使用してデータベースを過去の目標時点に巻き戻す場合、目標時点以降に変更されたブロックが判別され、フラッシュバック・ログからリストアされます。これをリストア・フェーズと呼びます。このフェーズの完了後、フラッシュバック・データベースでは、REDOログを使用して、これらのブロックがフラッシュバック・ログに書き込まれた後に行われた変更が再適用されます。これをリカバリ・フェーズと呼びます。

リストア・フェーズ中のフラッシュバック・データベースの進捗状況は、V$SESSION_LONGOPSビューを問い合せることによって監視できます。opnameはFlashback Databaseです。TOTALWORK列の下には、読み取る必要があるフラッシュバック・ログのMB数が表示されます。次の例に示すSOFAR列には、現在までに読み取られたMB数が表示されます。

例18-3 フラッシュバック・データベースの進捗状況の追跡(リストア・フェーズ)

SQL> SELECT sofar, totalwork, units FROM v$session_longops WHERE opname = 'Flashback Database';
 
SOFAR  TOTALWORK  UNITS
-----  ---------- --------------------------------
   17          60 Megabytes

リカバリ・フェーズ中のフラッシュバック・データベースの進捗状況は、V$RECOVERY_PROGRESSビューを問い合せることによって監視できます。

関連項目:

V$RECOVERY_PROGRESSビューの詳細は、Oracle Databaseリファレンスを参照してください

18.5 データベースのPoint-in-Timeリカバリの実行

RMANのDBPITRを実行すると、リカバリの目標時点より前のバックアップからデータベースがリストアされ、増分バックアップおよびREDOを使用してデータベースが目標時点までロールフォワードされます。SCN、時刻、ログ順序番号またはリストア・ポイントまでのリカバリを行うことができます。必要になった場合にPoint-in-Timeリカバリをより管理しやすい状態にしておくために、重要な時刻にリストア・ポイントを作成しておくことをお薦めします。

可能な場合は、データベースのPoint-in-Timeリカバリではなく、フラッシュバック・データベースを実行することをお薦めします。バックアップを使用したメディア・リカバリは、最後に行った変更を取り消すためにフラッシュバックを使用できない場合の最後の手段です。

この項では、次の項目について説明します。

• データベースのPoint-in-Timeリカバリの前提条件

• データベースのPoint-in-Timeリカバリの実行

• CDBおよびPDBのPoint-in-Timeリカバリの実行

• アプリケーションPDBのPoint-in-Timeリカバリの実行

• スパース・データベースのPoint-in-Timeリカバリの実行

18.5.1 データベースのPoint-in-Timeリカバリの前提条件

データベースのPoint-in-Timeリカバリ(DBPITR)を実行するには、特定の前提条件を満たしている必要があります。

次のものが必要となります。

• データベースはARCHIVELOGモードで実行されている必要があります。

• DBPITRの目的のSCNより前のすべてのデータファイルのバックアップ、およびバックアップのSCNと目的のSCNの間の期間のアーカイブ・ログが存在している必要があります。

• バックアップが透過的暗号化を使用して作成され、パスワード保護されたソフトウェア・キーストアが使用された場合は、リストア操作を実行する前にキーストア・パスワードを指定する必要があります。DECRYPTION WALLET OPEN IDENTIFIED BYオプションを指定してSETコマンドを使用し、パスワードベースのキーストアをオープンするために使用するパスワードを指定します。

  SYSBACKUP権限があるユーザーがリカバリを実行しており、パスワード保護されたソフトウェア・キーストアが使用されている場合は、このユーザーにSYSKM権限を付与します。

• バックアップがパスワード・モードの暗号化を使用して作成された場合は、RESTOREおよびRECOVERコマンドを実行する前に、バックアップの復号化に使用するパスワードを指定する必要があります。SET DECRYPTION IDENTIFIED BYコマンドを使用し、バックアップの復号化に使用するパスワードを指定します。

関連項目:

• SETコマンドの構文および使用方法の詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスでこのコマンドを参照してください

• コマンドの前提条件および使用上のノートの詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスのRECOVERコマンドを参照してください。

18.5.2 データベースのPoint-in-Timeリカバリの実行

RESTOREおよびRECOVERコマンドを使用して、DBPITRを実行します。

DBPITRを実行する場合は、RESTOREおよびRECOVERコマンドで個々にUNTIL句を指定するのではなく、SET UNTILコマンドを使用して目標時点を手順の最初に設定することによって、エラーを回避できます。これによって、バックアップからリストアされたデータファイルに十分に古いタイムスタンプが設定され、後続のRECOVER操作に使用できます。

この項では、次のことを想定しています。

• 現行のデータベースのインカネーション内で、DBPITRを実行します。目標時点が現行のインカネーション内に存在しない場合は、祖先インカネーションへのDBPITRについて、「祖先インカネーションへのデータベースのリカバリ」を参照してください。

• 制御ファイルは現行のものです。バックアップ制御ファイルをリストアする必要がある場合は、「バックアップ制御ファイルを使用したリカバリの実行」を参照してください。

• データベースでは、現行のサーバー・パラメータ・ファイルが使用されています。バックアップ・サーバー・パラメータ・ファイルをリストアする必要がある場合は、「サーバー・パラメータ・ファイルのリストア」を参照してください。

DBPITRを実行するには:

1. データベースのPoint-in-Timeリカバリの前提条件で説明している前提条件を満たしていることを確認します。

2. リカバリを終了するSCN、リストア・ポイントまたはログ順序番号を決定します。

   フラッシュバック問合せ機能を使用すると、論理的な破損が発生した時点を特定できます。表に対してフラッシュバック・データ・アーカイブが有効になっている場合は、非常に古いデータを問い合せることができます。

   また、アラート・ログを使用して、リカバリする必要があるイベントの時刻を特定することもできます。

   さらに、SQL問合せを使用して、目的のSCNが含まれているログ順序番号を特定し、このログを使用してリカバリすることもできます。たとえば、次の問合せを実行して、現行のデータベース・インカネーションのログを表示します(出力例も示します)。

   SELECT RECID, STAMP, THREAD#, SEQUENCE#, FIRST_CHANGE#
          FIRST_TIME, NEXT_CHANGE#
   FROM   V$ARCHIVED_LOG
   WHERE  RESETLOGS_CHANGE# =
          ( SELECT RESETLOGS_CHANGE#
            FROM   V$DATABASE_INCARNATION
            WHERE  STATUS = 'CURRENT');
   
   RECID      STAMP      THREAD#    SEQUENCE#  FIRST_CHAN FIRST_TIM NEXT_CHANG
   ---------- ---------- ---------- ---------- ---------- --------- ----------
            1  344890611          1          1      20037 24-SEP-13      20043
            2  344890615          1          2      20043 24-SEP-13      20045
            3  344890618          1          3      20045 24-SEP-13      20046
   

   たとえば、ユーザーが誤って表領域を午前9時2分に削除したことがわかった場合は、削除が発生する直前の午前9時までリカバリを行うことができます。この時刻より後にデータベースに対して行われたすべての変更は消失します。

3. 目的のSCNではなく、目標の時刻書式を使用する場合は、RMANの起動前に時刻書式の環境変数が適切であることを確認します。

   グローバリゼーション・サポート設定の例を次に示します。

   NLS_LANG = american_america.us7ascii
   NLS_DATE_FORMAT="Mon DD YYYY HH24:MI:SS"
   

4. RMANによるデータベース接続の確立の説明に従って、RMANをターゲット・データベースに接続します。必要に応じて、リカバリ・カタログに接続します。

5. 次のコマンドを使用して、データベースをマウント状態にします。

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   

6. RUNブロック内で、次の操作を実行します。

   1. DBPITRの場合、SET UNTILを使用して、目標時点、SCNまたはログ順序番号を指定するか、またはSET TOを使用して、リストア・ポイントを指定します。時刻を指定する場合は、環境変数NLS_LANGおよびNLS_DATE_FORMATで指定した日付書式を使用します。

   2. 自動チャネルを構成していない場合は、必要に応じて、ディスク・チャネルおよびテープ・チャネルを手動で割り当てます。

   3. データベースをリストアおよびリカバリします。

   次の例では、ターゲット・データベースでSCN 1000までDBPITRを実行します。

   RUN
   { 
     SET UNTIL SCN 1000;    
     RESTORE DATABASE;
     RECOVER DATABASE;
   }
   

   また、次の例に示すように、時刻書式、リストア・ポイントまたはログ順序番号を使用して、SET UNTIL時刻を指定することもできます。

   SET UNTIL TIME 'Nov 15 2013 09:00:00';
   SET UNTIL SEQUENCE 9923;  
   SET TO RESTORE POINT before_update;
   

   操作がエラーを戻さずに完了した場合、DBPITRは正常に終了しています。

7. 次の相互に排他的ないずれかのアクションを実行します。

   • データベースを読取り/書込みでオープンし、目的のSCN以降のすべての変更を取り消します。この場合は、データベースを停止し、マウントしてから、次のコマンドを実行する必要があります。

     ALTER DATABASE OPEN RESETLOGS;
     

     データファイルがオフラインになっていると、データファイルが正常にオフラインにされているか、または読取り専用である場合を除き、OPEN RESETLOGS操作が失敗します。RESETLOGSの実行後はREDOが不要になるため、読取り専用またはNORMALモードでオフラインにされた表領域のファイルをオンラインにすることができます。

   • データ・ポンプ・エクスポートを使用してデータベースから1つ以上のオブジェクトをエクスポートします。次に、データベースを現在の時点までリカバリして、エクスポートされたオブジェクトを再インポートすることによって、他のすべての変更を取り消さずにこれらのオブジェクトを不要な変更前の状態に戻すことができます。

18.5.3 CDBおよびPDBのPoint-in-Timeリカバリの実行

RECOVERコマンドを使用して、コンテナ・データベース(CDB)およびプラガブル・データベース(PDB)のPoint-in-Timeリカバリ(PITR)を実行します。PDBのPITRは、RMANを使用する場合のみ実行できます。

この章に含まれるPITRに関する一般的な情報は、この項およびそのサブセクションで説明する相違点を除いて、CDBに当てはまります。

ノート:

リカバリ・カタログを使用しない場合は、制御ファイルの自動バックアップをオンにすることをお薦めします。そうしない場合、RMANでファイルの追加や削除を取り消す必要がある場合に、PDBに対するPITRが効果的に動作しない可能性があります。

関連項目:

• PDBに対するPoint-in-Timeリカバリの基本的な概念

• CDB全体のPoint-in-Timeリカバリの実行

• PDBのPoint-in-Timeリカバリの実行

18.5.3.1 CDB全体のPoint-in-Timeリカバリの実行

RESTOREおよびRECOVERコマンドを使用して、CDB全体のPoint-in-Timeリカバリを実行します。

CDB全体のPoint-in-Timeリカバリを実行するには:

1. データベースのPoint-in-Timeリカバリの前提条件で説明している前提条件を満たしていることを確認します。
2. リカバリを終了するSCN、リストア・ポイントまたはログ順序番号を決定します。

   フラッシュバック問合せ機能を使用すると、論理的な破損が発生した時点を特定できます。表に対してフラッシュバック・データ・アーカイブが有効になっている場合は、非常に古いデータを問い合せることができます。

   また、アラート・ログを使用して、リカバリする必要があるイベントの時刻を特定することもできます。

   さらに、SQL問合せを使用して、目的のSCNが含まれているログ順序番号を特定し、このログを使用してリカバリすることもできます。たとえば、次の問合せを実行して、現行のデータベース・インカネーションのログを表示します(出力例も示します)。

   SELECT RECID, STAMP, THREAD#, SEQUENCE#, FIRST_CHANGE#
          FIRST_TIME, NEXT_CHANGE#
   FROM   V$ARCHIVED_LOG
   WHERE  RESETLOGS_CHANGE# =
          ( SELECT RESETLOGS_CHANGE#
            FROM   V$DATABASE_INCARNATION
            WHERE  STATUS = 'CURRENT');
   
   RECID      STAMP      THREAD#    SEQUENCE#  FIRST_CHAN FIRST_TIM NEXT_CHANG
   ---------- ---------- ---------- ---------- ---------- --------- ----------
            1  344890611          1          1      20037 24-SEP-13      20043
            2  344890615          1          2      20043 24-SEP-13      20045
            3  344890618          1          3      20045 24-SEP-13      20046
   

   たとえば、ユーザーが誤って表領域を午前9時2分に削除したことがわかった場合は、削除が発生する直前の午前9時までリカバリを行うことができます。この時刻より後にデータベースに対して行われたすべての変更は消失します。

3. 目的のSCNではなく、目標の時刻書式を使用する場合は、RMANの起動前に時刻書式の環境変数が適切であることを確認します。

   グローバリゼーション・サポート設定の例を次に示します。

   NLS_LANG = american_america.us7ascii
   NLS_DATE_FORMAT="Mon DD YYYY HH24:MI:SS"
   

4. ターゲットとしてのrootへの接続の説明に従って、SYSBACKUPまたはSYSDBA権限を持つ共通ユーザーとしてRMANをrootに接続します。必要に応じて、リカバリ・カタログに接続します。
5. CDBをマウント状態にします。

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   

6. RUNブロック内で、次の操作を実行します。
   1. DBPITRの場合、SET UNTILを使用して、目標時点、SCNまたはログ順序番号を指定するか、またはSET TOを使用して、リストア・ポイントを指定します。時刻を指定する場合は、環境変数NLS_LANGおよびNLS_DATE_FORMATで指定した日付書式を使用します。
   2. 自動チャネルを構成していない場合は、必要に応じて、ディスク・チャネルおよびテープ・チャネルを手動で割り当てます。
   3. CDBをリストアおよびリカバリします。

   次の例では、ターゲットCDBでSCN 1000までDBPITRを実行します。

   RUN
   { 
     SET UNTIL SCN 1000;    
     RESTORE DATABASE;
     RECOVER DATABASE;
   }
   

   また、次の例に示すように、時刻書式、リストア・ポイントまたはログ順序番号を使用して、SET UNTIL時刻を指定することもできます。

   SET UNTIL TIME 'Nov 15 2013 09:00:00';
   SET UNTIL SEQUENCE 9923;  
   SET TO RESTORE POINT before_update;
   

   操作がエラーを戻さずに完了した場合、DBPITRは正常に終了しています。

7. 次の相互に排他的ないずれかのアクションを実行します。

   • CDBを読取り/書込みでオープンし、目的のSCN以降のすべての変更を取り消します。この場合は、CDBを停止し、マウントしてから、次のコマンドを実行する必要があります。

     ALTER DATABASE OPEN RESETLOGS;
     

     データファイルがオフラインになっていると、データファイルが正常にオフラインにされているか、または読取り専用である場合を除き、OPEN RESETLOGS操作が失敗します。RESETLOGSの実行後はREDOが不要になるため、読取り専用またはNORMALモードでオフラインにされた表領域のファイルをオンラインにすることができます。

   • データ・ポンプ・エクスポートを使用してCDBから1つ以上のオブジェクトをエクスポートします。次に、CDBを現在の時点までリカバリして、エクスポートされたオブジェクトを再インポートすることによって、他のすべての変更を取り消さずにこれらのオブジェクトを不要な変更前の状態に戻すことができます。

8. すべてのPDBをオープンします。

   CDBがオープンしているときは、PDBはオープンしません。次のコマンドは、rootに接続している場合、すべてのPDBをオープンします。

   ALTER PLUGGABLE DATABASE ALL OPEN;
   

   各PDBを別々にオープンすることもできます。

18.5.3.2 PDBのPoint-in-Timeリカバリの実行

1つ以上のPDBを指定された時点までリカバリする際に、CDB内のその他のPDBへの影響はなく、これらをオープンして操作することができます。

共有UNDOを使用するCDB内の1つ以上のPDBに対してDBPITRを実行する場合、ルートのバックアップおよびPDBが含まれるCDBのCDBシード(PDB$SEED)のバックアップが必要です。

Oracle Database 12cリリース2 (12.2)以降、COMPATIBLE初期化パラメータが12.2.0以上に設定されている場合、PDBフラッシュバック操作全体に渡るCDBまたはPDB PITRに対してフラッシュバック・データベースを実行できます。

PDBでDBPITRを実行するには:

1. データベースのPoint-in-Timeリカバリの前提条件で説明している前提条件を満たしていることを確認します。
2. リカバリを終了するSCN、リストア・ポイントまたはログ順序番号を決定します。
   フラッシュバック問合せまたはアラート・ログを使用して、物理的な破損が発生した時点を判断します。または、SQL問合せを使用して、目的のSCNが含まれているログ順序番号を特定し、このログを使用してリカバリします。
3. 目的のSCNではなく、目標の時刻書式を使用する場合は、RMANの起動前に時刻書式の環境変数が適切であることを確認します。

   グローバリゼーション・サポート設定の例を次に示します。

   NLS_LANG = american_america.us7ascii
   NLS_DATE_FORMAT="Mon DD YYYY HH24:MI:SS"
   

4. CDBへのRMAN接続の確立の説明に従って、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてRMANをrootに接続します。必要に応じて、リカバリ・カタログに接続します。
5. リカバリされているPDBを閉じます。他のPDBおよびCDBをオープンしたままにできます。

   ALTER PLUGGABLE DATABASE pdb1 CLOSE;
   

6. RUNブロック内で、次の操作を実行します。
   1. DBPITRの場合、SET UNTILを使用して、目標時点、SCNまたはログ順序番号を指定するか、またはSET TOを使用して、リストア・ポイントを指定します。時刻を指定する場合は、環境変数NLS_LANGおよびNLS_DATE_FORMATで指定した日付書式を使用します。
   2. 自動チャネルを構成していない場合は、必要に応じて、ディスク・チャネルおよびテープ・チャネルを手動で割り当てます。
   3. CDBをリストアおよびリカバリします。

   次の例では、PDB my_pdbでSCN 1000までDBPITRを実行します。

   RUN
   { 
     SET UNTIL SCN 1000;    
     RESTORE PLUGGABLE DATABASE my_pdb;
     RECOVER PLUGGABLE DATABASE my_pdb;
   }
   

   操作がエラーを戻さずに完了した場合、DBPITRは正常に終了しています。

7. 目的のSCN以降のすべての変更を取り消しているPDBをオープンします。

   次の例は、my_pdbという名前のPDBをオープンします。

   ALTER PLUGGABLE DATABASE my_pdb OPEN RESETLOGS;
   

例18-4 指定した時点へのPDBのリカバリ

この例では、PDB5という名前のPDBをSCN 1066までリカバリした後にオープンして、読取り/書込みのアクセスを行います。SYSDBA権限またはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続し、次のコマンドを入力します。

ALTER PLUGGABLE DATABASE pdb5 CLOSE;
run 
{
   SET UNTIL SCN 1066;
   RESTORE PLUGGABLE DATABASE pdb5;
   RECOVER PLUGGABLE DATABASE pdb5;
}
ALTER PLUGGABLE DATABASE pdb5 OPEN RESETLOGS;

この例は、高速リカバリ領域が使用されていることを想定しています。高速リカバリ領域を使用しない場合は、AUXILIARY DESTINATION句を使用して補助セットのファイルの一時的な場所を指定する必要があります。

RESETLOGSを指定してPDBをオープンすると、新規のPDBインカネーションが作成されます。インカネーション番号は、V$PDB_INCARNATIONビューを問い合せます。

関連項目:

PDBのPoint-in-Timeリカバリ時の高速リカバリ領域の使用方法の詳細は、PDBに対するPoint-in-Timeリカバリの基本的な概念を参照してください。

18.5.3.3 削除されたPDBのリカバリ

削除されたPDBをリカバリするには、RECOVER PLUGGABLE DATABASEコマンドを使用します。

PDBのリカバリに必要なバックアップが使用可能であることを確認してください。制御ファイル、ルートおよび削除されたPDBのバックアップが必要です。

削除されたPDBをリカバリするには:

1. データベースのPoint-in-Timeリカバリの前提条件で説明している前提条件を満たしていることを確認します。
   PDBが分離モード設定で構成されている場合は、PDBキーストアを開きます。
2. PDBのリカバリ目標となる時点、SCNまたはログ順序を決定します。
   フラッシュバック問合せまたはアラート・ログを使用して、論理的破損が発生した時点を判断します。または、SQL問合せを使用して、目的のSCNが含まれているログ順序番号を特定し、このログを使用してリカバリします。
3. 目的のSCNではなく、目標の時刻書式を使用する場合は、RMANの起動前に時刻書式の環境変数が適切であることを確認します。
4. RMANによるデータベース接続の確立の説明に従って、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてRMANをルートに接続します。必要に応じて、リカバリ・カタログに接続します。
5. RUNブロック内で、次の操作を実行します。
   1. SET UNTILを使用して、目標時点、SCNまたはログ順序番号を指定するか、またはSET TOを使用して、リストア・ポイントを指定します。時刻を指定する場合は、環境変数NLS_LANGおよびNLS_DATE_FORMATで指定した日付書式を使用します。
   2. 自動チャネルを構成していない場合は、必要に応じて、ディスク・チャネルおよびテープ・チャネルを手動で割り当てます。
   3. 削除されたPDBをリカバリします。

      次の例では、以前に削除されたmypdbというPDBをリカバリします。

      run
      {
          SET UNTIL SCN 146898;
          RECOVER PLUGGABLE DATABASE mypdb;
      }

      高速リカバリ領域が使用されていない場合は、AUXILIARY DESTINATION句をRECOVERコマンドに含めます。

6. PDBをオープンすると、目標となるSCNより後のすべての変更が取り消されます。

   次の例では、mypdbというPDBをオープンします。

   ALTER PLUGGABLE DATABASE mypdb OPEN RESETLOGS;

18.5.4 アプリケーションPDBのPoint-in-Timeリカバリの実行

RESTOREおよびRECOVERコマンドを使用して、アプリケーションPDBのPoint-in-Timeリカバリを実行します。

CDBのCOMPATIBLEパラメータは、12.2以上に設定する必要があります。

アプリケーションPDBのPoint-in-Timeリカバリを実行するには:

1. Point-in-Timeリカバリの前提条件を満たしていることを確認します。
2. RMANを起動し、SYSDBAまたはSYSBACKUP権限を持つアプリケーションの共通ユーザーとしてアプリケーション・ルートに接続します。
   アプリケーション・ルートには固有のサービス名があり、PDBに接続するのと同じ方法でアプリケーション・ルートに接続できます。
3. リカバリを終了するSCN、リストア・ポイントまたはログ順序番号を決定します。
4. リカバリが必要なアプリケーションPDBをクローズします。

   次のコマンドは、hr_appcont_pdb1というアプリケーションPDBをクローズします。

   ALTER PLUGGABLE DATABASE hr_appcont_pdb1 CLOSE; 

5. RUNブロック内で、次の操作を実行します。
   1. SET UNTILを使用して、目標時点、SCNまたはログ順序番号を指定するか、またはSET TOを使用して、リストア・ポイントを指定します。時刻を指定する場合は、環境変数NLS_LANGおよびNLS_DATE_FORMATで指定した日付書式を使用します。
   2. 自動チャネルを構成していない場合は、必要に応じて、ディスク・チャネルおよびテープ・チャネルを手動で割り当てます。
   3. アプリケーション・コンテナをリストアし、リカバリします。

   RUN
   {
   SET UNTIL SCN 34506;
   RESTORE PLUGGABLE DATABASE hr_appcont_pdb1;
   RECOVER PLUGGABLE DATABASE hr_appcont_pdb1;
   }
   

6. RESETLOGSを指定してアプリケーションPDBをオープンします。この結果は、ターゲットSCNの取消し後のすべての変更になります。

   ALTER PLUGGABLE DATABASE hr_appcont_pdb1 OPEN RESETLOGS;

関連項目:

CDBへのRMAN接続の確立

18.5.5 スパース・データベースのPoint-in-Timeリカバリの実行

スパース・データベースのPoint-in-Timeリカバリの実行は、通常のデータベースのPoint-in-Timeリカバリの実行と似ています。

リカバリされるデータベースのCOMPATIBLE初期化パラメータが12.2以上に設定されていることを確認します。

ノート:

スパース・データベースのベース(読取り専用)データファイルは、暗号化されていません。基本データファイルは、保護されたストレージに保存し、安全な通信を使用してアクセスするようにします。

スパース・データベースのPoint-in-Timeリカバリを実行するには:

1. データベースのPoint-in-Timeリカバリの前提条件で説明している前提条件を満たしていることを確認します。

2. リカバリを終了するSCN、リストア・ポイントまたはログ順序番号を決定します。

   フラッシュバック問合せ機能を使用すると、論理的な破損が発生した時点を特定できます。表に対してフラッシュバック・データ・アーカイブが有効になっている場合は、非常に古いデータを問い合せることができます。

   また、アラート・ログを使用して、リカバリする必要があるイベントの時刻を特定することもできます。

   さらに、SQL問合せを使用して、目的のSCNが含まれているログ順序番号を特定し、このログを使用してリカバリすることもできます。たとえば、次の問合せを実行して、現行のデータベース・インカネーションのログを表示します(出力例も示します)。

   SELECT RECID, STAMP, THREAD#, SEQUENCE#, FIRST_CHANGE#
          FIRST_TIME, NEXT_CHANGE#
   FROM   V$ARCHIVED_LOG
   WHERE  RESETLOGS_CHANGE# =
          ( SELECT RESETLOGS_CHANGE#
            FROM   V$DATABASE_INCARNATION
            WHERE  STATUS = 'CURRENT');
   
   RECID      STAMP      THREAD#    SEQUENCE#  FIRST_CHAN FIRST_TIM NEXT_CHANG
   ---------- ---------- ---------- ---------- ---------- --------- ----------
            1  344890611          1          1      20037 24-SEP-13      20043
            2  344890615          1          2      20043 24-SEP-13      20045
            3  344890618          1          3      20045 24-SEP-13      20046
   

   たとえば、ユーザーが誤って表領域を午前9時2分に削除したことがわかった場合は、削除が発生する直前の午前9時までリカバリを行うことができます。この時刻より後にデータベースに対して行われたすべての変更は消失します。

3. 目的のSCNではなく、目標の時刻書式を使用する場合は、RMANの起動前に時刻書式の環境変数が適切であることを確認します。

   グローバリゼーション・サポート設定の例を次に示します。

   NLS_LANG = american_america.us7ascii
   NLS_DATE_FORMAT="Mon DD YYYY HH24:MI:SS"
   

4. RMANによるデータベース接続の確立の説明に従って、RMANをターゲット・データベースに接続し、必要に応じてリカバリ・カタログ・データベースにも接続します。

5. データベースをマウント状態にします。

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   

   操作がエラーを戻さずに完了した場合、DBPITRは正常に終了しています。

6. RUNブロック内で、次の操作を実行します。

   1. DBPITRの場合、SET UNTILを使用して、目標時点、SCNまたはログ順序番号を指定するか、またはSET TOを使用して、リストア・ポイントを指定します。時刻を指定する場合は、環境変数NLS_LANGおよびNLS_DATE_FORMATで指定した日付書式を使用します。

   2. 自動チャネルを構成していない場合は、必要に応じて、ディスク・チャネルおよびテープ・チャネルを手動で割り当てます。

   3. FROM SPARSEオプションを指定して、スパース・データベースのリストアおよびリカバリを実行します。

      次の例は、スパース・データベースのPoint-in-Timeリカバリを、SCN 2775080まで実行します。

      RUN 
      {
      SET UNTIL SCN 2775080; 
      RESTORE FROM SPARSE DATABASE; 
      RECOVER DATABASE; 
      }

7. 次の相互に排他的ないずれかのアクションを実行します。

   • データベースを読取り/書込みでオープンし、目的のSCN以降のすべての変更を取り消します。この場合は、データベースを停止し、マウントしてから、次のコマンドを実行する必要があります。

     ALTER DATABASE OPEN RESETLOGS;
     

     データファイルがオフラインになっていると、データファイルが正常にオフラインにされているか、または読取り専用である場合を除き、OPEN RESETLOGS操作が失敗します。RESETLOGSの実行後はREDOが不要になるため、読取り専用またはNORMALモードでオフラインにされた表領域のファイルをオンラインにすることができます。

   • データ・ポンプ・エクスポートを使用してデータベースから1つ以上のオブジェクトをエクスポートします。次に、データベースを現在の時点までリカバリして、エクスポートされたオブジェクトを再インポートすることによって、他のすべての変更を取り消さずにこれらのオブジェクトを不要な変更前の状態に戻すことができます。

18.6 フラッシュバックおよびデータベースのPoint-in-Timeリカバリの例

この項では、基本的なフラッシュバック・データベースとDBPITRシナリオの例を示します。

この項では、次の項目について説明します。

• フラッシュバック・データベースを使用したOPEN RESETLOGS操作の巻戻し

• 取り消されたインカネーション・ブランチ内のSCNへのデータベースの巻戻し

• 祖先インカネーションへのデータベースのリカバリ

18.6.1 フラッシュバック・データベースを使用したOPEN RESETLOGS操作の巻戻し

フラッシュバック・データベースを使用して、OPEN RESETLOGS操作を元に戻すことができます。

フラッシュバック・データベースを使用して不要なALTER DATABASE OPEN RESETLOGS文の結果を前の状態に戻すための手順は、「フラッシュバック・データベース操作の実行」で説明する通常の場合と類似しています。ただし、FLASHBACK DATABASEコマンドで特定のSCNまたは時点を指定するかわりに、FLASHBACK DATABASE TO BEFORE RESETLOGSを使用します。

OPEN RESETLOGS操作を取り消すには:

1. SQL*Plusをターゲット・データベースに接続し、フラッシュバック・ウィンドウの開始時点が最新のOPEN RESETLOGSより前であることを確認します。

   次の問合せを実行します。

   SELECT RESETLOGS_CHANGE# FROM V$DATABASE;
   SELECT OLDEST_FLASHBACK_SCN FROM V$FLASHBACK_DATABASE_LOG;
   

   V$DATABASE.RESETLOGS_CHANGE#がV$FLASHBACK_DATABASE_LOG.OLDEST_FLASHBACK_SCNより大きい場合は、フラッシュバック・データベースを使用してOPEN RESETLOGS操作を前の状態に戻すことができます。

2. データベースを停止してマウントし、フラッシュバック・ウィンドウを再確認します。RESETLOGS SCNがまだフラッシュバック・ウィンドウ内にある場合は、次のステップに進みます。
3. RMANによるデータベース接続の確立の説明に従って、RMANをターゲット・データベースに接続します。
4. RESETLOGSの前に、SCNへのフラッシュバックをただちに実行します。

   次の形式のFLASHBACK DATABASEコマンドを使用します。

   FLASHBACK DATABASE TO BEFORE RESETLOGS;
   

   FLASHBACK DATABASEの他の使用例と同様に、ターゲットSCNがフラッシュバック・データベース・ウィンドウの開始時点より前である場合は、エラーが戻され、データベースは変更されません。コマンドが正常終了した場合、データベースはマウントされたまま、以前のインカネーションでOPEN RESETLOGS操作が実行される前の最新のSCNまでリカバリされます。

5. SQL*Plusを使用してデータベースを読取り専用でオープンし、必要に応じて問合せを実行して、論理的な破損の影響が無効にされたことを確認します。

   次のように入力して、データベースを読取り専用でオープンします。

   ALTER DATABASE OPEN READ ONLY;
   

6. データベースを再度更新できるようにするには、データベースを停止してマウントしてから、次のコマンドを実行します。

   ALTER DATABASE OPEN RESETLOGS;

18.6.1.1 フラッシュバック・データベースを使用したスタンバイ・データベースでのOPEN RESETLOGSの取消しについて

OPEN RESETLOGSをまたぐフラッシュバック・データベースは、Data Guard環境で複数の機能を実現するために使用できます。

次のものが必要となります。

• ロジカル・スタンバイ・スイッチオーバーを取り消すためのフラッシュバック

  この場合、データベースは、フラッシュバック・データベース操作の目標時点での役割(プライマリまたはスタンバイ)に戻されます。

• フィジカル・スタンバイのアクティブ化の取消し

  一時的にフィジカル・スタンバイ・データベースをアクティブ化し、テストまたはレポートの目的で使用してから、フラッシュバック・データベースを使用してフィジカル・スタンバイとしての役割に戻すことができます。

• テスト目的でのスタンバイ・データベースの継続的な使用

  フラッシュバック・データベースを使用すると、ストレージ・スナップショットを使用する必要がなくなります。

関連項目:

Data Guardでのフラッシュバック・データベースのこれらの高度な適用の詳細は、Oracle Data Guard概要および管理を参照してください

18.6.2 取り消されたインカネーション・ブランチ内のSCNへのデータベースの巻戻し

フラッシュバック・データベースを使用して、取り消されたデータベース・インカネーションまでデータベースを巻き戻すことができます。

フラッシュバック・データベースまたはDBPITRの後にOPEN RESETLOGS操作を使用すると、データベースが以前のSCNに戻され、その時点以降の変更が取り消されます。したがって、その時点以降の一部のSCNは、取り消された変更またはデータベースの現行の履歴にある変更のいずれかを参照できます。この方法では、FLASHBACK DATABASEで指定された目的のSCNが不明確になる可能性があります。

SCNとは異なり、時刻書式およびリストア・ポイントは不明確にはなりません。時刻書式は、常に、その時点の現行インカネーションに関連付けられています。リストア・ポイントは、常に、作成時の現行インカネーションに関連付けられています。これは、取り消されたデータベース・インカネーションに対応する時刻およびリストア・ポイントにも該当します。データベース・インカネーションは、指定した時刻またはリストア・ポイントの作成時の現行インカネーションに自動的に再設定されます。

フラッシュバック・データベースを使用して、現行のインカネーション・パスが古いインカネーションからブランチした時点のOPEN RESETLOGS操作のSCNより後の親インカネーション内の時点までデータベースを巻き戻す必要がある場合があります。OPEN RESETLOGS操作で新しいインカネーションを作成した後でも、インカネーション・ブランチでSCNを生成できる方法については、図14-1を参照してください。この図に示されているように、インカネーション1内の取り消されたSCN 1500まで戻る必要がある場合、データベースはインカネーション3内のSCN 3000にある可能性があります。

巻き戻しているSCNが直系祖先パスにある場合、またはデータベースをリストア・ポイントまで巻き戻している場合は、明示的なRESET DATABASEコマンドはフラッシュバック・データベースに必要ありません。ただし、明示的なRESET DATABASE TO INCARNATIONコマンドは、FLASHBACK DATABASEを使用して、データベースを取り消されたデータベース・インカネーションのSCNに巻き戻す場合は必須です。

取り消されたインカネーション・ブランチ内のSCNまでデータベースを巻き戻すには:

1. SQL*Plusを使用してターゲット・データベースに接続し、SCNまでフラッシュバックするための十分な情報がフラッシュバック・ログに含まれていることを確認します。

   たとえば、次の問合せを実行します。

   SELECT OLDEST_FLASHBACK_SCN FROM V$FLASHBACK_DATABASE_LOG;
   

2. フラッシュバック・データベース操作のターゲット・インカネーション番号(親インカネーションのインカネーション・キー)を特定します。

   たとえば、次の問合せを実行します。

   SELECT PRIOR_INCARNATION# 
   FROM   V$DATABASE_INCARNATION 
   WHERE  STATUS = 'CURRENT';
   

3. RMANを開始し、RMANによるデータベース接続の確立の説明に従ってターゲット・データベースに接続します。
4. 次のように入力して、データベースを停止してからマウントします。

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   

5. データベース・インカネーションを親インカネーションに設定します。

   たとえば、次のコマンドを使用してインカネーション1に戻ります。

   RESET DATABASE TO INCARNATION 1;
   

6. FLASHBACK DATABASEコマンドを実行し、目的のSCNを指定します。

   たとえば、次のコマンドを使用して、データベースをSCN 1500まで巻き戻します。

   FLASHBACK DATABASE TO SCN 1500;
   

7. SQL*Plusを使用してデータベースを読取り専用でオープンし、必要に応じて問合せを実行して、論理的な破損の影響が無効にされたことを確認します。

   次のように入力して、データベースを読取り専用でオープンします。

   ALTER DATABASE OPEN READ ONLY;
   

8. データベースを再度更新できるようにするには、データベースを停止してマウントしてから、次のコマンドを実行します。

   ALTER DATABASE OPEN RESETLOGS;

関連項目:

• データベースのインカネーション、取り消された変更、およびALTER DATABASE OPEN RESETLOGSの影響に関する有効な基礎知識については、「データベース・インカネーションについて」を参照してください

• RESET DATABASEコマンドの詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

18.6.3 祖先インカネーションへのデータベースのリカバリ

現在以外のデータベース・インカネーションへのDPITRを実行するには、明示的にRESET DATABASEを実行して、目的のSCNでの現行インカネーションにデータベースを再設定する必要があります。また、目的のSCNが含まれているデータベース・インカネーションから制御ファイルをリストアする必要もあります。

RMANがリカバリ・カタログに接続されている場合にRESTORE CONTROLFILEコマンドを実行すると、UNTIL句で指定された時刻に最も近い時刻の現行のデータベース・インカネーションのみが検索されます。現行以外のインカネーションから制御ファイルをリストアするには、LIST INCARNATIONを実行し、ターゲット・データベースのインカネーションを特定して、RESET DATABASE TO INCARNATIONコマンドにこのインカネーションを指定する必要があります。

RMANがリカバリ・カタログに接続されていない場合は、データベースをマウントする前にRESET DATABASE TO INCARNATIONコマンドを実行することはできません。したがって、SET UNTILを実行し、制御ファイルを自動バックアップからリストアしてマウントする必要があります。

次の状況を想定しています。

• RMANがリカバリ・カタログに接続されています。

• 2013年10月2日にターゲット・データベースtrgtのバックアップを実行しています。

• 2013年10月10日にこのデータベースに対してDBPITRを実行し、以前のエラーを修正しています。DBPITRの後にOPEN RESETLOGS操作を実行して、新しいインカネーションを開始しています。

10月25日、2013年10月8日午前8時にデータベースから削除された重要なデータが必要であることが判明したとします。これは、現行のインカネーションの開始点より前の時刻です。

DBPITRを現行以外のインカネーションに実行するには:

1. データベースのPoint-in-Timeリカバリの前提条件で説明している前提条件を満たしていることを確認します。
2. RMANを開始し、RMANによるデータベース接続の確立の説明に従って、必要に応じてターゲット・データベースおよびリカバリ・カタログに接続します。
3. バックアップの時点での現行のデータベース・インカネーションを特定します。

   LIST INCARNATIONを使用して、目標時点での現行のインカネーションの主キーを取得します。

   LIST INCARNATION OF DATABASE trgt;
   
   List of Database Incarnations
   DB Key  Inc Key   DB Name   DB ID       STATUS     Reset SCN    Reset Time
   ------- -------   -------   ------      -------    ----------   ----------
   1       2         TRGT      1224038686  PARENT     1            02-OCT-13
   1       582       TRGT      1224038686  CURRENT    59727        10-OCT-13
   

   Reset SCNおよびReset Time列を参照し、正しいインカネーションを特定して、Inc Key列内のインカネーション・キーを書き留めます。この例では、バックアップは2013年10月2日に実行されました。この場合、インカネーション・キーの値は2です。

4. データベースは起動されているが、マウントされていないことを確認します。

   STARTUP FORCE NOMOUNT;
   

5. ターゲット・データベースを、ステップ2で取得したインカネーションに再設定します。

   この例では、10月2日のバックアップ時点での現行インカネーションを指定します。Inc Key列の値を使用して、インカネーションを識別します。

   RESET DATABASE TO INCARNATION 2;
   

6. RUNコマンドで次の操作を実行して、データベースをリストアおよびリカバリします。

   • リカバリの終了時刻を、データが消失する直前の時刻に設定します。

   • 構成されていない必要なチャネルを割り当てます。

   • 10月2日のバックアップから制御ファイルをリストアし、マウントします。

   • データファイルをリストアし、データベースをリカバリします。RECOVER DATABASE ... UNTILコマンドを使用してDBPITRを実行し、データが消失する直前の10月8日午前7時55分の目標時点にデータベースを戻します。

   次の例では、この場合に必要なすべてのステップを示しています。

   RUN
   {
     SET UNTIL TIME 'Oct 8 2013 07:55:00'; 
     RESTORE CONTROLFILE;
     # without recovery catalog, use RESTORE CONTROLFILE FROM AUTOBACKUP
     ALTER DATABASE MOUNT; 
     RESTORE DATABASE;
     RECOVER DATABASE;
   }
   ALTER DATABASE OPEN RESETLOGS;

   関連項目:

   RESET DATABASEコマンドの詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。