18 フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行
この章では、不要なデータベース変更について調べ、Oracleのフラッシュバック技術およびデータベース・バックアップに基づいた適切なリカバリ計画を選択して実行する方法について説明します。次の項目が含まれます。
18.1 Oracleフラッシュバック技術およびデータベースのPoint-in-Timeリカバリの概要
この項では、Oracleフラッシュバック技術およびデータベースのPoint-in-Timeリカバリの目的および基本的な概念について説明します。
18.1.1 フラッシュバックおよびデータベースのPoint-in-Timeリカバリの目的
通常、フラッシュバック機能またはPoint-in-Timeリカバリは、次のような場合に実行します。
-
ユーザー・エラーまたは破損によって、必要なデータが削除されるか、またはデータが破損された場合。たとえば、ユーザーまたはDBAが誤って1つ以上の表の内容を削除または更新したり、アプリケーションの更新中にまだ必要なデータベース・オブジェクトを削除したり、大規模なバッチ更新を実行して途中で障害が発生した場合などです。
-
データベースのアップグレードに失敗するか、アップグレード・スクリプトが消失した場合。
-
すべての必要なREDOログまたは増分バックアップがないため、メディア障害後の完全なデータベース・リカバリを正常に実行できない場合。
これらの場合、Point-in-Timeリカバリまたはフラッシュバック機能を使用して、データベースまたはデータベース・オブジェクトを前の時点の状態に戻すことができます。
18.1.2 Point-in-Timeリカバリおよびフラッシュバック機能の基本的な概念
不要なデータベース変更に対する最も基本的な解決方法は、RMANのデータベースのPoint-in-Timeリカバリ(DBPITR)です。DBPITRは、使用可能なすべてのREDOを使用することも、データベースに対するすべての変更をリカバリすることもないため、不完全リカバリとも呼ばれます。この場合は、データベース全体のバックアップをリストアしてから、REDOログまたは増分バックアップを適用して、不要な変更の前の時点までのすべての変更を再作成します。
不要なデータベース変更が大規模ではあるが、特定の表領域に限定されている場合は、 表領域のPoint-in-Timeリカバリ(TSPITR)を使用して、影響を受けない表領域を使用可能な状態にしたまま、これらの表領域を以前のシステム変更番号(SCN)に戻すことができます。RMANのTSPITRは高度な手法です。詳細は、「RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行」を参照してください。
不要なデータベース変更が特定の表または表パーティションに限定されている場合、以前に作成したRMANバックアップを使用して、これらのオブジェクトのみを不要な変更が発生する前の時点まで戻すことができます。特定の時点への表または表パーティションのリカバリについては、「RMANバックアップからの表および表パーティションのリカバリ」を参照してください。
また、Oracle Databaseには、フラッシュバック技術と呼ばれる一連の機能も備えられています。この技術によって、バックアップからデータベースをリストアせずに、データの過去の状態を表示したり、データを任意の時点に戻したり、進めることができます。データベースに対する変更によっては、フラッシュバック技術で、データベースの可用性に与える影響を抑えてより迅速に不要な変更を無効にすることができます。
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リカバリをサポートします。リカバリを実行するプロセスは、DBPITRと同様です。1つ以上のPDBにPoint-in-Timeリカバリを実行するには、RECOVER
コマンドを使用します。ただし、PDBをリカバリするには、SYSDBA
権限またはSYSBACKUP
権限を持つユーザーとしてrootに接続する必要があります。「CDBおよびPDBのPoint-in-Timeリカバリの実行」を参照してください。
18.1.2.3 フラッシュバック技術の基本的な概念
Oracle Databaseのフラッシュバック機能が使用可能なほとんどの状況では、メディア・リカバリより効率的です。フラッシュバック機能を使用すると、データベースの過去の状態を調べることができます。
18.1.2.3.1 バックアップおよびリカバリで役立つ物理フラッシュバック機能について
「フラッシュバック・データベースを使用したデータベースの巻戻し」で説明されているように、DBPITRの最も効率的な代替機能として、Oracle Flashback Databaseがあります。他のフラッシュバック機能とは異なり、この機能は物理レベルで動作して、現行のデータファイルが過去の内容に戻されます。結果は、DBPITR(OPEN RESETLOGS
を含む)の結果に類似していますが、フラッシュバック・データベースではデータファイルをリストアする必要はなく、メディア・リカバリと比較してREDOの適用が限られているため、通常、はるかに短時間でリカバリが行われます。
「高速リカバリ領域の構成」で説明されているように、フラッシュバック・データベースには高速リカバリ領域が必要です。フラッシュバック・データベースのロギングを有効にするには、DB_FLASHBACK_RETENTION_TARGET
初期化パラメータを設定し、ALTER
DATABASE
FLASHBACK
ON
文を発行する必要があります。
通常の操作中、データベースによって、フラッシュバック・ログにデータファイル・ブロックの古いイメージが定期的に書き込まれます。フラッシュバック・ログは順次書き込まれ、バルク書込みが行われることも多くあります。フラッシュバック・ロギングは、継続バックアップに類似しています。データベースでは、リカバリ領域に対するフラッシュバック・ログの書込み、削除およびサイズ変更が自動的に行われます。フラッシュバック・ログはアーカイブされません。フラッシュバック・ログは、パフォーマンスを監視したり、フラッシュ・リカバリ領域に対するディスク領域の割当てを決定する場合にのみ確認する必要があります。
フラッシュバック・データベース操作を行う際に、データベースは、過去のバージョンのデータ・ブロックへのアクセスにフラッシュバック・ログを使用し、アーカイブREDOログの一部のデータも使用します。したがって、障害が検出された後はフラッシュバック・データベースを有効にできなくなるため、フラッシュバック・データベースを使用してこの障害発生の前まで巻き戻します。保証付きリストア・ポイントの関連機能を使用すると、危険を伴うデータベースの変更の直前などの特定の時点のデータベースの内容を保護できます。
18.1.2.3.2 バックアップおよびリカバリで役立つ論理フラッシュバック機能について
残りのフラッシュバック機能は、論理レベルで動作します。この章で説明する論理機能は、次のとおりです。
-
データベースのいずれの部分もオフラインにすることなく、表または表のセットを過去の指定した時点にリカバリできます。ほとんどの場合、フラッシュバック表を使用すると、より複雑なPoint-in-Timeリカバリ操作を行う必要がなくなります。フラッシュバック表では、表がリストアされ、同時に現在の索引、トリガーおよび制約などの関連する属性が自動的にメンテナンスされるため、ユーザーはアプリケーション固有のプロパティを検索してリストアする必要がありません。
この機能の使用方法については、「フラッシュバック表を使用した表の巻戻し」を参照してください。
関連項目:
以前に作成したRMANバックアップを使用した表のリカバリの詳細は、「RMANバックアップからの表および表パーティションのリカバリ」を参照してください。
-
DROP
TABLE
文の結果を無効にできます。この機能の使用方法については、「フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し」を参照してください。
フラッシュバック・ドロップ以外のすべての論理フラッシュバック機能では、UNDOデータが使用されます。UNDOレコードは、主に、SQL問合せでの読取り一貫性の提供およびトランザクションのロールバックのために使用されます。このため、UNDOレコードには、過去の時点のデータの再構築、およびその過去の時点以降の変更のレコードの調査に必要な情報が含まれています。
フラッシュバック・ドロップでは、ごみ箱と呼ばれるメカニズムが使用されます。Oracleは、削除されたデータベース・オブジェクトの占める領域が新しいデータのために必要となるまで、ごみ箱を使用してそれらのオブジェクトを管理します。ごみ箱に割り当てられる領域の量は固定されていません。また、削除されたオブジェクトがごみ箱に残される期間については保証されていません。システム・アクティビティに応じて、削除されたオブジェクトがごみ箱に残される期間は、数秒または数か月になる場合があります。
関連項目:
-
UNDOデータおよび自動UNDO管理の詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。
-
論理フラッシュバック機能の使用方法については、『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のすべてに対してフラッシュバック操作を実行する必要があります。アプリケーション・ルートでフラッシュバック操作を実行すると、アプリケーション・ルートが指定された時点まで戻されるだけです。
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へのフラッシュバック・データベース操作を実行します
-
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
句を使用して、補助インスタンスに別の場所を指定できます。
18.1.3.3 CDBでのREDOの破損の管理について
まれな状況ですが、マルチテナント・コンテナ・データベース(CDB)内のREDOログが壊れているとします。そのようなシナリオで、影響を受けたデータ・ブロックが1つのプラガブル・データベース(PDB)にのみ存在している場合、次のいずれかを実行できます。
-
PDBで、破損前の特定の時点へのフラッシュバック操作を実行してから
RESETLOGS
付きでPDBをオープンします -
PDBで、破損前の特定の時点へのPoint-in-Timeリカバリを実行してから
RESETLOGS
付きでPDBをオープンします
PDBでのPITRまたはフラッシュバックの後にプライマリに続くスタンバイを有効化するのに必要な手順を実行した場合、プライマリ・データベースでいずれかの手順を実行した後、このプライマリ・データベースのスタンバイ・データベースも破損されたREDOをスキップできます。
関連項目:
-
プライマリに続くようにスタンバイを有効化する手順については、『Oracle Data Guard概要および管理』ガイドを参照
18.2 フラッシュバック表を使用した表の巻戻し
フラッシュバック表では、リストアされたバックアップではなくUNDO表領域の情報を使用して、表を取得します。フラッシュバック表操作を行うと、新しい行が削除され、古い行が再度挿入されます。表のフラッシュバックの実行中、データベースの残りの部分は使用可能のままになります。
この項では、次の項目について説明します。
関連項目:
自動UNDO管理の詳細は、『Oracle Database管理者ガイド』を参照してください。
18.2.1 フラッシュバック表の前提条件
1つ以上の表でOracle Flashback Table機能を使用するには、目標時点またはSCNでFLASHBACK
TABLE
SQL文を使用します。
フラッシュバック表機能を使用するには、次の権限を所有している必要があります。
-
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 フラッシュバック表操作の実行
次の例では、ユーザーが更新を誤って複数回実行した後、hr.temp_employees
表のフラッシュバックを実行すると想定しています。
temp_employeesのフラッシュバックを実行するには、次の手順を実行します。
18.2.2.1 フラッシュバック表中のトリガーの有効状態の保持
デフォルトでは、データベースによって、FLASHBACK TABLE
操作の実行前に、影響を受ける表のトリガーが無効にされます。このトリガーの状態は、操作の終了後、操作前の状態(有効または無効)に戻されます。表のフラッシュバック中にトリガーを有効な状態のままにするには、手順7で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 Flashback Tableの簡単な使用例は、『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
を使用し、削除されたオブジェクトを取得します。
削除された表を取得する手順
18.3.3.1 元の名前が同じオブジェクトが複数存在する場合のフラッシュバック・ドロップを使用したオブジェクトの取出し
複数のオブジェクトを同じ元の名前で作成し、その後削除できます。削除されたすべてのオブジェクトは、ごみ箱に保存されます。たとえば、例18-1のSQL文について考えてみます。
関連項目:
-
フラッシュバック・ドロップを使用する方法およびごみ箱を管理する方法については、『Oracle Database管理者ガイド』を参照してください。
-
FLASHBACK TABLE
文の詳細は、『Oracle Database 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;
例18-1では、temp_employees
表が削除されるたびに、ごみ箱の中でそれぞれに一意の名前が割り当てられています。次の例に示すように、FLASHBACK TABLE ... TO BEFORE DROP
文は、表の元の名前を指定して使用できます。
FLASHBACK TABLE temp_employees TO BEFORE DROP;
この元の名前で最後に削除された表は、その元の名前でごみ箱から取得されます。例18-2では、前の例で削除された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;
18.4 フラッシュバック・データベースを使用したデータベースの巻戻し
この項では、フラッシュバック・データベースを使用して、データベースに対する不要な変更を巻き戻す最も一般的な例について説明します。
この項では、次の項目について説明します。
18.4.1 フラッシュバック・データベースの前提条件
FLASHBACK
DATABASE
コマンドを使用してデータベースの内容をフラッシュバック・ウィンドウ内の時点まで戻すには、「フラッシュバック・データベース、リストア・ポイントおよび保証付きリストア・ポイントの概要」の説明に従って、フラッシュバック・ロギングを行うようにデータベースを事前に構成しておく必要があります。保証付きリストア・ポイントまでデータベースを戻すには、「通常のリストア・ポイントと保証付きリストア・ポイントの使用」の説明に従って、保証付きリストア・ポイントを事前に定義しておく必要があります。
フラッシュバック・データベースでは、コマンド実行時に存在した、データファイルに対する変更が取り消されます。重要な前提条件は、次のとおりです。
-
現行のデータファイルが消失または破損していないこと。
FLASHBACK DATABASE
は、Oracle Databaseで行われたデータファイルに対する変更の巻戻しにのみ使用できます。メディア障害の修復には使用できません。 -
データファイルの誤った削除からのリカバリ、データファイルの縮小操作の取消しまたはデータベース名の変更の取消しをしようとしていないこと。
-
制御ファイルのリストアまたは再作成前の時点に戻すために
FLASHBACK
DATABASE
を使用しようとしていないこと。データベース制御ファイルがバックアップからリストアされるか、または再作成されると、すべての累積フラッシュバック・ログ情報が破棄されます。 -
互換性の変更を取り消すために
FLASHBACK
DATABASE
を使用しようとしていないこと。
関連項目:
FLASHBACK DATABASE
のコマンドの前提条件および使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
18.4.2 フラッシュバック・データベース操作の実行
この項では、時刻書式、通常のリストア・ポイントまたは保証付きリストア・ポイントの名前、あるいはSCNを使用して目的の目標時点を指定し、データベースのフラッシュバックを実行する基本的な方法について説明します。
次の例では、現行のデータベースのインカネーション内の時点までデータベースを巻戻すと想定しています。最後のOPEN
RESETLOGS
操作の直前の時点にまでデータベースを戻す場合は、「フラッシュバック・データベースを使用したOPEN RESETLOGS操作の巻戻し」を参照してください。
デフォルトでは、FLASHBACK DATABASE
コマンドで使用されるSCNは、データベース・インカネーションの直系祖先パス内のSCNを参照します。「データベース・インカネーションについて」で説明されているように、データベースを以前に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全体に対するフラッシュバック・データベース操作を実行する手順は次のとおりです。
18.4.4 PDBに対するフラッシュバック・データベース操作の実行
FLASHBACK DATABASE
コマンドを使用して、マルチテナント・コンテナ・データベース(CDB)の単一のプラガブル・データベース(PDB)に対してフラッシュバック・データベース操作を実行できます。
PDBに対するフラッシュバック・データベース操作を実行する手順は次のとおりです。
注意:
プロキシPDBでは、フラッシュバック操作はサポートされていません。
18.4.5 フラッシュバック・データベースの監視
フラッシュバック・データベースを使用してデータベースを過去の目標時点に巻き戻す場合、目標時点以降に変更されたブロックが判別され、フラッシュバック・ログからリストアされます。これをリストア・フェーズと呼びます。このフェーズの完了後、フラッシュバック・データベースでは、REDOログを使用して、これらのブロックがフラッシュバック・ログに書き込まれた後に行われた変更が再適用されます。これをリカバリ・フェーズと呼びます。
リストア・フェーズ中のフラッシュバック・データベースの進捗状況は、V$SESSION_LONGOPS
ビューを問い合せることによって監視できます。opname
はFlashback Database
です。TOTALWORK
列の下には、読み取る必要があるフラッシュバック・ログのMB数が表示されます。例18-3に示す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リカバリではなく、フラッシュバック・データベースを実行することをお薦めします。バックアップを使用したメディア・リカバリは、最後に行った変更を取り消すためにフラッシュバックを使用できない場合の最後の手段です。
この項では、次の項目について説明します。
18.5.1 データベースのPoint-in-Timeリカバリの前提条件
データベースのPoint-in-Timeリカバリ(DBPITR)の前提条件は、次のとおりです。
-
データベースは
ARCHIVELOG
モードで実行されている必要があります。 -
DBPITRの目的のSCNより前のすべてのデータファイルのバックアップ、およびバックアップのSCNと目的のSCNの間の期間のアーカイブ・ログが存在している必要があります。
-
バックアップが透過的暗号化を使用して暗号化され、パスワードベースのソフトウェア・キーストアが使用された場合、リストア操作を実行する前にキーストア・パスワードを指定する必要があります。
DECRYPTION WALLET OPEN IDENTIFIED BY
オプションを指定してSET
コマンドを使用し、パスワードベースのキーストアをオープンするために使用するパスワードを指定します。自動ログイン・ソフトウェア・キーストアが使用される場合、このコマンドは不要です。関連項目:
SET
コマンドの構文および使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
コマンドの前提条件および使用上の注意の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のRECOVER
エントリに関する項を参照してください。
18.5.2 データベースのPoint-in-Timeリカバリの実行
この項では、DBPITRの基本手順について説明します。この手順では、次のことを想定しています。
-
現行のデータベースのインカネーション内で、DBPITRを実行します。目標時点が現行のインカネーション内に存在しない場合は、祖先インカネーションへのDBPITRについて、「祖先インカネーションへのデータベースのリカバリ」を参照してください。
-
制御ファイルは現行のものです。バックアップ制御ファイルをリストアする必要がある場合は、「バックアップ制御ファイルを使用したリカバリの実行」を参照してください。
-
データベースでは、現行のサーバー・パラメータ・ファイルが使用されています。バックアップ・サーバー・パラメータ・ファイルをリストアする必要がある場合は、「サーバー・パラメータ・ファイルのリストア」を参照してください。
DBPITRを実行する場合は、RESTORE
およびRECOVER
コマンドで個々にUNTIL
句を指定するのではなく、SET
UNTIL
コマンドを使用して目標時点を手順の最初に設定することによって、エラーを回避できます。これによって、バックアップからリストアされたデータファイルに十分に古いタイムスタンプが設定され、後続のRECOVER
操作に使用できます。
DBPITRを実行する手順
-
「データベースのPoint-in-Timeリカバリの前提条件」で説明している前提条件を満たしていることを確認します。
-
リカバリを終了する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時までリカバリを行うことができます。この時刻より後にデータベースに対して行われたすべての変更は消失します。
-
目的のSCNではなく、目標の時刻書式を使用する場合は、RMANの起動前に時刻書式の環境変数が適切であることを確認します。
グローバリゼーション・サポート設定の例を次に示します。
NLS_LANG = american_america.us7ascii NLS_DATE_FORMAT="Mon DD YYYY HH24:MI:SS"
-
RMANをターゲット・データベースに接続し、必要に応じてリカバリ・カタログにも接続します。データベースをマウント状態にします。
SHUTDOWN IMMEDIATE; STARTUP MOUNT;
関連項目:
-
RUN
ブロック内で、次の操作を実行します。-
DBPITRの場合、
SET
UNTIL
を使用して、目標時点、SCNまたはログ順序番号を指定するか、またはSET
TO
を使用して、リストア・ポイントを指定します。時刻を指定する場合は、環境変数NLS_LANG
およびNLS_DATE_FORMAT
で指定した日付書式を使用します。 -
自動チャネルを構成していない場合は、必要に応じて、ディスク・チャネルおよびテープ・チャネルを手動で割り当てます。
-
データベースをリストアおよびリカバリします。
次の例では、ターゲット・データベースで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は正常に終了しています。
-
-
次の相互に排他的ないずれかのアクションを実行します。
-
データベースを読取り/書込みでオープンし、目的のSCN以降のすべての変更を取り消します。この場合は、データベースを停止し、マウントしてから、次のコマンドを実行する必要があります。
ALTER DATABASE OPEN RESETLOGS;
データファイルがオフラインになっていると、データファイルが正常にオフラインにされているか、または読取り専用である場合を除き、
OPEN RESETLOGS
操作が失敗します。RESETLOGS
の実行後はREDOが不要になるため、読取り専用またはNORMALモードでオフラインにされた表領域のファイルをオンラインにすることができます。 -
データ・ポンプ・エクスポートを使用してデータベースから1つ以上のオブジェクトをエクスポートします。次に、データベースを現在の時点までリカバリして、エクスポートされたオブジェクトを再インポートすることによって、他のすべての変更を取り消さずにこれらのオブジェクトを不要な変更前の状態に戻すことができます。
-
18.5.3 CDBおよびPDBのPoint-in-Timeリカバリの実行
RMANを使用すると、CDBおよびPDBのPoint-in-Timeリカバリ(PITR)を実行できます。PDBに対するPITRは、RMANを使用する場合のみ実行できます。リカバリ・カタログを使用しない場合は、制御ファイルの自動バックアップをオンにすることをお薦めします。そうしない場合、RMANでファイルの追加や削除を取り消す必要がある場合に、PDBに対するPITRが効果的に動作しない可能性があります。
この章でのPITRに関する情報は、以降の項で説明する相違点を除いて、CDBに当てはまります。
PDBのDBPITRおよび高速リカバリ領域について
PDBのDBPITRを実行する場合、このPDBのすべてのデータファイルはインプレースにリカバリされます。ただし、PDBを指定した目標時点にリカバリするには、RMANでは、UNDO
表領域が目標時点の状態である必要があります。UNDO
表領域はすべてのPDBで共有されるため、インプレースでリカバリすることはできません。RMANは、UNDO
、SYSTEM
およびSYSAUX
の表領域を補助データベースのrootにリストアしてからUNDO情報を使用してPDBを目標時点にリカバリします。高速リカバリが構成されている場合は、Oracle Databaseでそれが補助の宛先として使用されます。高速リカバリ領域が構成されていない場合は、AUXILIARY DESTINATION
句を使用して補助データベース・ファイルに使用される場所を指定する必要があります。root表領域およびUNDO表領域を格納するために十分な領域が高速リカバリ領域にあることを確認してください。高速リカバリ領域に必要な領域がない場合は、AUXILIARY DESTINATION
句で指定する代替場所を使用します。
18.5.3.2 PDBのPoint-in-Timeリカバリの実行
PDBのPoint-in-Timeリカバリを実行する手順は、DBPITRの実行手順と同様ですが、この項で説明する相違点があります。1つ以上のPDBを指定された時点までリカバリする際に、CDB内のその他のPDBへの影響はなく、これらをオープンして操作することができます。リカバリ後、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に対してフラッシュバック・データベースを実行できます。
Data Guard環境では、PDBが特定の時点にリストアされたプライマリ・データベースにスタンバイ・データベースが続くには、スタンバイ・データベース全体をフラッシュバックするか、PDBをリストアするか、PDBをフラッシュバックする必要があります。
PDBでDBPITRを実行するには、次の手順を実行します。
例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
句を使用して補助セットのファイルの一時的な場所を指定する必要があります。PDBのPoint-in-Time時の高速リカバリ領域の使用方法の詳細は、「PDBのDBPITRおよび高速リカバリ領域について」を参照してください。
RESETLOGS
は、PDBの新しいインカネーションを作成します。「PDBのインカネーションについて」の記載に従ってV$PDB_INCARNATION
ビューでインカネーション番号を問い合せることができます。
18.5.4 アプリケーションPDBのPoint-in-Timeリカバリの実行
RESTORE
およびRECOVER
コマンドを使用して、アプリケーションPDBのPoint-in-Timeリカバリを実行します。
COMPATIBLE
パラメータは、12.2以上に設定する必要があります。
アプリケーションPDBのPoint-in-Timeリカバリを実行する手順
関連項目:
18.5.5 スパース・データベースのPoint-in-Timeリカバリの実行
スパース・データベースのPoint-in-Timeリカバリの実行は、通常のデータベースのPoint-in-Timeリカバリの実行と似ています。スパース・データベースのPoint-in-Timeリカバリを実行するには、リカバリ対象データベースのCOMPATIBLE
初期化パラメータが12.2以上に設定されていることを確認する必要があります。
注意:
スパース・データベースのベース(読取り専用)データファイルは、暗号化されていません。基本データファイルは、保護されたストレージに保存し、安全な通信を使用してアクセスするようにします。
スパース・データベースのPoint-in-Timeリカバリを実行する手順
-
「データベースのPoint-in-Timeリカバリの前提条件」で説明している前提条件を満たしていることを確認します。
-
リカバリを終了する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時までリカバリを行うことができます。この時刻より後にデータベースに対して行われたすべての変更は消失します。
-
目的のSCNではなく、目標の時刻書式を使用する場合は、RMANの起動前に時刻書式の環境変数が適切であることを確認します。
グローバリゼーション・サポート設定の例を次に示します。
NLS_LANG = american_america.us7ascii NLS_DATE_FORMAT="Mon DD YYYY HH24:MI:SS"
-
「RMANによるデータベース接続の確立」の説明に従って、RMANをターゲット・データベースに接続し、必要に応じてリカバリ・カタログ・データベースにも接続します。データベースをマウント状態にします。
SHUTDOWN IMMEDIATE; STARTUP MOUNT;
操作がエラーを戻さずに完了した場合、DBPITRは正常に終了しています。
-
RUN
ブロック内で、次の操作を実行します。-
DBPITRの場合、
SET
UNTIL
を使用して、目標時点、SCNまたはログ順序番号を指定するか、またはSET
TO
を使用して、リストア・ポイントを指定します。時刻を指定する場合は、環境変数NLS_LANG
およびNLS_DATE_FORMAT
で指定した日付書式を使用します。 -
自動チャネルを構成していない場合は、必要に応じて、ディスク・チャネルおよびテープ・チャネルを手動で割り当てます。
-
FROM SPARSE
オプションを指定して、スパース・データベースのリストアおよびリカバリを実行します。次の例は、スパース・データベースのPoint-in-Timeリカバリを、SCN
2775080
まで実行します。RUN { SET UNTIL SCN 2775080; RESTORE FROM SPARSE DATABASE; RECOVER DATABASE; }
-
-
次の相互に排他的ないずれかのアクションを実行します。
-
データベースを読取り/書込みでオープンし、目的のSCN以降のすべての変更を取り消します。この場合は、データベースを停止し、マウントしてから、次のコマンドを実行する必要があります。
ALTER DATABASE OPEN RESETLOGS;
データファイルがオフラインになっていると、データファイルが正常にオフラインにされているか、または読取り専用である場合を除き、
OPEN RESETLOGS
操作が失敗します。RESETLOGS
の実行後はREDOが不要になるため、読取り専用またはNORMALモードでオフラインにされた表領域のファイルをオンラインにすることができます。 -
データ・ポンプ・エクスポートを使用してデータベースから1つ以上のオブジェクトをエクスポートします。次に、データベースを現在の時点までリカバリして、エクスポートされたオブジェクトを再インポートすることによって、他のすべての変更を取り消さずにこれらのオブジェクトを不要な変更前の状態に戻すことができます。
-
18.6 フラッシュバックおよびデータベースのPoint-in-Timeリカバリの例
この項では、「フラッシュバック・データベースを使用したデータベースの巻戻し」および「データベースのPoint-in-Timeリカバリの実行」で説明されている基本例を少し変更した例について説明します。
この項では、次の項目について説明します。
18.6.1 フラッシュバック・データベースを使用したOPEN RESETLOGS操作の巻戻し
フラッシュバック・データベースを使用して不要なALTER DATABASE OPEN RESETLOGS
文の結果を前の状態に戻すための手順は、「フラッシュバック・データベース操作の実行」で説明する通常の場合と類似しています。ただし、FLASHBACK
DATABASE
コマンドで特定のSCNまたは時点を指定するかわりに、FLASHBACK
DATABASE
TO
BEFORE
RESETLOGS
を使用します。
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までデータベースを巻き戻す手順
関連項目:
-
データベースのインカネーション、取り消された変更、および
ALTER DATABASE OPEN
RESETLOGS
の影響に関する有効な基礎知識については、「データベース・インカネーションについて」を参照してください -
RESET
DATABASE
コマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
18.6.3 祖先インカネーションへのデータベースのリカバリ
現行のインカネーション内でのDBPITRの手順は、現行以外のインカネーション内のSCNへのDBPITRとは異なります。後者の場合は、明示的に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を現行以外のインカネーションに実行する手順