この章では、不要なデータベース変更について調べ、Oracleのフラッシュバック技術およびデータベース・バックアップに基づいた適切なリカバリ計画を選択して実行する方法について説明します。含まれる内容は、次のとおりです。
この項では、フラッシュバック技術およびデータベースのPoint-in-Timeリカバリの目的および基本的な概念について説明します。
通常、フラッシュバック機能またはPoint-in-Timeリカバリは、次のような場合に実行します。
ユーザー・エラーまたは破損によって、必要なデータが削除されるか、またはデータが破損された場合。たとえば、ユーザーまたはDBAが誤って1つ以上の表の内容を削除または更新したり、アプリケーションの更新中にまだ必要なデータベース・オブジェクトを削除したり、大規模なバッチ更新を実行して途中で障害が発生した場合などです。
データベースのアップグレードに失敗するか、アップグレード・スクリプトが消失した場合。
すべての必要なREDOログまたは増分バックアップがないため、メディア障害後の完全なデータベース・リカバリを正常に実行できない場合。
いずれの場合も、Point-in-Timeリカバリまたはフラッシュバック機能を使用して、データベースまたはデータベース・オブジェクトを前の時点の状態に戻すことができます。
不要なデータベース変更に対する最も基本的な解決方法は、RMANのデータベースのPoint-in-Timeリカバリ(DBPITR)です。DBPITRは、使用可能なすべてのREDOを使用することも、データベースに対するすべての変更をリカバリすることもないため、不完全リカバリとも呼ばれます。この場合は、データベース全体のバックアップをリストアしてから、REDOログまたは増分バックアップを適用して、不要な変更の前の時点までのすべての変更を再作成します。
不要なデータベース変更が大規模ではあるが、特定の表領域に制限されている場合は、 表領域のPoint-in-Timeリカバリ(TSPITR)を使用して、影響を受けない表領域を使用可能の状態にしたまま、影響を受けている表領域を以前のSCNに戻すことができます。RMANのTSPITRは高度な手法です。詳細は、第21章「RMANの表領域のPoint-in-Timeリカバリ(TSPITR)の実行」を参照してください。
また、Oracle Databaseには、フラッシュバック技術と呼ばれる一連の機能も備えられています。この技術によって、バックアップからデータベースをリストアせずに、データの過去の状態を表示したり、データを任意の時点に戻したり、進めることができます。データベースに対する変更によっては、フラッシュバック技術で、データベースの可用性に与える影響を抑えてより迅速に不要な変更を無効にすることができます。
DBPITRは、物理レベルで動作し、データファイルを過去の目標時点の状態に戻します。RMANのDBPITR操作では、目的のSCN、ログ順序、リストア・ポイントまたは時刻を指定します。RMANは、目標時点以前に作成されたバックアップからデータベースをリストアしてから、増分バックアップおよびログを適用して、データファイルをバックアップした時点とリカバリの終了時点の間のすべての変更を再作成します。終了時点がSCNとして指定されている場合、データベースは、REDOログを適用し、各REDOスレッドの終了時または指定したSCNのうちの早い方の時点で停止します。終了時点が時刻として指定されている場合、データベースは、指定した時刻に適したSCNを内部的に判別した後、このSCNまでリカバリします。
バックアップ計画が適切に設計され、データベースがARCHIVELOG
モードで実行されている場合は、ほぼすべての状況でDBPITRを実行できます。「データベースの不完全リカバリの実行」で説明されているように、RMANのDBPITRは、ユーザー管理のDBPITRと比較すると簡略化されています。目的のSCNを指定すると、データファイルがバックアップからリストアされ、ユーザーの介入なしで効率的にリカバリが行われます。ただし、RMANのDBPITRには、次のデメリットがあります。
以前の状態に戻すことができるのはデータベース全体のみであり、選択したオブジェクトを以前の状態に戻すことはできません。
DBPITRの実行中、データベース全体が使用不可になります。
RMANはすべてのデータファイルをリストアする必要があるため、DBPITRに時間がかかる可能性があります。また、RMANは、データファイルをリカバリするためにREDOログおよび増分バックアップをリストアする必要がある場合もあります。バックアップがテープ上にある場合は、このプロセスにさらに時間がかかる可能性があります。
Oracleのフラッシュバック機能が使用可能なほとんどの状況では、フラッシュバック機能の方がメディア・リカバリより効率的です。フラッシュバック機能を使用すると、データベースの過去の状態を調べることができます。
「フラッシュバック・データベースを使用したデータベースの巻戻し」で説明されているように、DBPITRの最も効率的な代替機能として、Oracle Flashback Databaseがあります。他のフラッシュバック機能とは異なり、この機能は物理レベルで動作して、現行のデータファイルが過去の内容に戻されます。結果は、DBPITR(OPEN RESETLOGS
を含む)の結果に類似していますが、フラッシュバック・データベースではデータファイルをリストアする必要はなく、メディア・リカバリと比較してREDOの適用が限られているため、通常、はるかに短時間でリカバリが行われます。
「高速リカバリ領域の構成」で説明されているように、フラッシュバック・データベースには高速リカバリ領域が必要です。フラッシュバック・データベースのロギングを有効にするには、DB_FLASHBACK_RETENTION_TARGET
初期化パラメータを設定し、ALTER
DATABASE
FLASHBACK
ON
文を発行する必要があります。
通常の操作中、データベースによって、フラッシュバック・ログにデータファイル・ブロックの古いイメージが定期的に書き込まれます。フラッシュバック・ログは順次書き込まれ、バルク書込みが行われることも多くあります。フラッシュバック・ロギングは、継続バックアップに類似しています。データベースでは、リカバリ領域に対するフラッシュバック・ログの書込み、削除およびサイズ変更が自動的に行われます。フラッシュバック・ログはアーカイブされません。フラッシュバック・ログは、パフォーマンスを監視したり、フラッシュ・リカバリ領域に対するディスク領域の割当てを決定する場合にのみ確認する必要があります。
フラッシュバック・データベース操作を行う際に、データベースは、過去のバージョンのデータ・ブロックへのアクセスにフラッシュバック・ログを使用し、アーカイブREDOログの一部のデータも使用します。したがって、障害が検出された後はフラッシュバック・データベースを有効にできなくなるため、フラッシュバック・データベースを使用してこの障害発生の前まで巻き戻します。保証付きリストア・ポイントの関連機能を使用すると、危険を伴うデータベースの変更の直前などの特定の時点のデータベースの内容を保護できます。
残りのフラッシュバック機能は、論理レベルで動作します。この章で説明する論理機能は、次のとおりです。
データベースのいずれの部分もオフラインにすることなく、表または表のセットを過去の指定した時点にリカバリできます。ほとんどの場合、フラッシュバック表を使用すると、より複雑なPoint-in-Timeリカバリ操作を行う必要がなくなります。フラッシュバック表では、表がリストアされ、同時に現在の索引、トリガーおよび制約などの関連する属性が自動的にメンテナンスされるため、ユーザーはアプリケーション固有のプロパティを検索してリストアする必要がありません。
この機能の使用方法については、「フラッシュバック表を使用した表の巻戻し」を参照してください。
DROP
TABLE
文の結果を無効にできます。
この機能の使用方法については、「フラッシュバック・ドロップを使用したDROP TABLE操作の巻戻し」を参照してください。
注意: 論理フラッシュバック機能の用途はバックアップおよびリカバリに特化したものではないため、これらの機能に関する一部のドキュメントはドキュメント・セット内の他の場所に存在しています。 |
フラッシュバック・ドロップ以外のすべての論理フラッシュバック機能では、UNDOデータが使用されます。UNDOレコードは、主に、SQL問合せでの読取り一貫性の提供およびトランザクションのロールバックのために使用されます。このため、UNDOレコードには、過去の時点のデータの再構築、およびその過去の時点以降の変更のレコードの調査に必要な情報が含まれています。
フラッシュバック・ドロップでは、ごみ箱と呼ばれるメカニズムが使用されます。Oracleは、削除されたデータベース・オブジェクトの占める領域が新しいデータのために必要となるまで、ごみ箱を使用してそれらのオブジェクトを管理します。ごみ箱に割り当てられる領域の量は固定されていません。また、削除されたオブジェクトがごみ箱に残される期間については保証されていません。システム・アクティビティに応じて、削除されたオブジェクトがごみ箱に残される期間は、数秒または数か月になる場合があります。
参照:
|
フラッシュバック表では、リストアされたバックアップではなくUNDO表領域の情報を使用して、表を取得します。フラッシュバック表操作を行うと、新しい行が削除され、古い行が再度挿入されます。表のフラッシュバックの実行中、データベースの残りの部分は使用可能のままになります。
関連項目: 自動UNDO管理の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
1つ以上の表でOracle Flashback Table機能を使用するには、目標時点またはSCNでFLASHBACK
TABLE
SQL文を使用します。
フラッシュバック表機能を使用するには、次の権限を所有している必要があります。
FLASHBACK ANY TABLE
システム権限を付与されているか、または表に対するFLASHBACK
オブジェクト権限を所有している必要があります。
表に対する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操作の巻戻し」を参照してください。 |
次の例では、ユーザーが更新を誤って複数回実行した後、hr.temp_employees
表のフラッシュバックを実行すると想定しています。
temp_employees
のフラッシュバックを実行する手順
SQL*Plusをターゲット・データベースに接続し、現行のSCNを識別します。
FLASHBACK TABLE
文はロールバックできませんが、別のFLASHBACK TABLE
文を発行し、現在の時刻の直前の時刻を指定することができます。このため、現行のSCNを記録することお薦めします。現行のSCNは、V$DATABASE
を次のように問い合せることによって取得できます。
SELECT CURRENT_SCN FROM V$DATABASE;
表を戻す時刻、SCNまたはリストア・ポイントを識別します。
リストア・ポイントを作成した場合は、次の問合せを実行して、使用可能なリストア・ポイントを表示できます。
SELECT NAME, SCN, TIME FROM V$RESTORE_POINT;
指定した目標時点に表を巻戻すための十分なUNDOデータが存在していることを確認します。
UNDO_RETENTION
初期化パラメータが設定されており、UNDO保存保証が有効になっている場合は、次の問合せを使用して、UNDOデータが保持される期間を確認できます。
SELECT NAME, VALUE/60 MINUTES_RETAINED FROM V$PARAMETER WHERE NAME = 'undo_retention';
行の移動が、フラッシュバック表を使用して巻き戻しているすべてのオブジェクトに対して有効になっていることを確認します。
次のSQL文を使用して、表の行の移動を有効にすることができます。ここで、tableは、巻き戻す表の名前です。
ALTER TABLE table ENABLE ROW MOVEMENT;
フラッシュバック対象の表に、他の表への依存性があるかどうかを確認します。依存性が存在する場合は、それらの表をフラッシュバックするかどうかも決定します。
次の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';
フラッシュバック対象のオブジェクトに対して、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('2007-10-17 09:30:00', 'YYYY-MM-DD HH:MI:SS');
注意: タイムスタンプとSCNのマッピングは、常に正確であるとはかぎりません。FLASHBACK TABLE 文でタイムスタンプを使用した場合、表がフラッシュバックされる時刻とTO_TIMESTAMP で指定される時刻の間で最大3秒異なることがあります。過去の正確な時点が必要な場合は、時刻ではなくSCNを使用します。 |
必要に応じて、表を問い合せてデータを確認します。
デフォルトでは、データベースによって、FLASHBACK TABLE
操作の実行前に、影響を受ける表のトリガーが無効にされます。このトリガーの状態は、操作の終了後、操作前の状態(有効または無効)に戻されます。表のフラッシュバック中にトリガーを有効な状態のままにするには、手順6
でFLASHBACK TABLE
文にENABLE TRIGGERS句を追加します。
たとえば、HR管理者が17時に、hr.temp_employees
表からある従業員が欠落していることに気付いたとします。この従業員は、レポートが最後に実行された14時には表に含まれていました。したがって、この従業員のレコードが誤って削除されたのは、14時から17時の間です。HR管理者は、フラッシュバック表を使用して、hr.temp_employees
表に設定されているすべてのトリガーを有効にして、表を午後2時の状態に戻します。この場合、次の例のSQL文を使用します。
FLASHBACK TABLE temp_employees TO TIMESTAMP TO_TIMESTAMP('2005-03-03 14:00:00' , 'YYYY-MM-DD HH:MI:SS') ENABLE TRIGGERS;
関連項目:
|
この項では、FLASHBACK TABLE ... TO BEFORE DROP
文を使用して、ごみ箱からオブジェクトを取得する方法について説明します。
フラッシュバック・ドロップによって、DROP TABLE
操作の結果を無効にできます。フラッシュバック・ドロップは、この状況で使用できる他のリカバリ・メカニズム(Point-in-Timeリカバリなど)より高速です。また、フラッシュバック・ドロップによって、停止時間または最新のトランザクションの消失は発生しません。
表を削除した場合、その表に関連付けられている領域はデータベースによってすぐには削除されません。かわりに、表は、名前を変更され、関連付けられているすべてのオブジェクトとともにごみ箱に配置されます。システム生成のごみ箱のオブジェクト名は一意です。他のオブジェクトを問い合せる場合と同様に、ごみ箱内のオブジェクトを問い合せることができます。
フラッシュバック操作では、ごみ箱から表が取り出されます。削除された表を取得する場合は、ユーザーが指定した表の元の名前またはシステム生成の名前を使用できます。
表を削除すると、表およびそれに依存するすべてのオブジェクトが同時にごみ箱に移動されます。同様に、フラッシュバック・ドロップを実行すると、通常、すべてのオブジェクトが同時に取得されます。表をごみ箱からリストアすると、索引などの依存オブジェクトの名前は、元の名前に戻されず、ごみ箱内のシステム生成の名前のままになります。Oracle Databaseでは、表に定義されたすべての索引(ビットマップ結合索引を除く)、および表に定義されたすべてのトリガーと制約(他の表を参照する参照整合性制約を除く)が取得されます。
索引などの依存オブジェクトの一部は、領域圧迫のため再利用される場合があります。この場合、再利用された依存オブジェクトは、ごみ箱から取得できません。
次に、フラッシュバック・ドロップおよびごみ箱に関連する操作に必要なユーザー権限の概要を示します。
DROP
オブジェクトに対してDROP権限を持つすべてのユーザーは、オブジェクトを削除し、ごみ箱に配置することができます。
FLASHBACK TABLE ... TO BEFORE DROP
この文に対する権限は、DROP
権限に関連付けられています。つまり、オブジェクトを削除できるすべてのユーザーは、フラッシュバック・ドロップを実行して、削除済オブジェクトをごみ箱から取得できます。
PURGE
ごみ箱の消去に対する権限は、DROP
権限に関連付けられています。DROP
TABLE
またはDROP
ANY
TABLE
権限を持つユーザーは、オブジェクトをごみ箱から消去できます。
ごみ箱内のオブジェクトに対するSELECT
ごみ箱のオブジェクトの問合せを行う場合、ユーザーは、ごみ箱のオブジェクトに対してSELECT
およびFLASHBACK
権限を所有している必要があります。削除前にオブジェクトに対してSELECT
権限を所有していたすべてのユーザーは、ごみ箱内のそのオブジェクトに対してSELECT
権限を継続して所有しています。ごみ箱内のオブジェクトは過去の状態のデータベースのオブジェクトであるため、これらのオブジェクトを問い合せるには、ユーザーはFLASHBACK
権限が必要です。
ごみ箱からオブジェクトを取得するには、オブジェクトが次の要件を満たしている必要があります。
システム表領域ではないローカル管理表領域に対してのみごみ箱が使用可能であること。表がシステム表領域ではないローカル管理表領域に含まれていて、その依存セグメント(オブジェクト)がディクショナリ管理表領域に含まれている場合、これらのオブジェクトはごみ箱によって保護されます。
ファイングレイン監査ポリシー(FGA)およびVirtual Private Database(VPD)ポリシーが定義されている表が、ごみ箱によって保護されていないこと。
パーティション化された索引構成表が、ごみ箱によって保護されていないこと。
領域再利用操作のため、ユーザーまたはOracle Databaseのいずれかによって表が削除されていないこと。
FLASHBACK
TABLE
...
TO
BEFORE
DROP
文を使用すると、ごみ箱からオブジェクトをリカバリできます。ごみ箱内の表の名前または元の表の名前のいずれかを指定できます。
この項では、誤った表を削除した例を想定しています。テスト・データベースで表の削除を複数回要求されましたが、この場合、かわりに本番データベースに誤って接続し、hr.employee_demo
を削除したとします。FLASHBACK TABLE
を使用し、削除されたオブジェクトを取得します。
削除された表を取得する手順
SQL*Plusをターゲット・データベースに接続し、ごみ箱内の削除された表の名前を取得します。
SQL*PlusコマンドSHOW RECYCLEBIN
は、次のように使用できます。
SHOW RECYCLEBIN; ORIGINAL NAME RECYCLEBIN NAME TYPE DROP TIME ---------------- --------------------------------- ------------ ------------- EMPLOYEE_DEMO BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0 TABLE 2005-04-11:17:08:54
ORIGINAL NAME
列には、オブジェクトの元の名前が表示され、RECYCLEBIN NAME
列には、ごみ箱内でのオブジェクトの名前が表示されます。
また、USER_RECYCLEBIN
またはDBA_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 などのオブジェクト・ビューには、ごみ箱オブジェクトは表示されません。 |
必要に応じて、ごみ箱内の表を問い合せます。
問合せでは、オブジェクトの元の名前ではなく、オブジェクトのごみ箱内の名前を使用する必要があります。次の例では、BIN$KSD8DB9L345KLA==$0
というごみ箱内の名前を持つ表を問い合せます。
SELECT * FROM "BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0";
ごみ箱内の名前に特殊文字が含まれているため、引用符が必要です。
注意: 必要な権限を所有している場合は、ごみ箱内の表に対してフラッシュバック問合せを使用できますが、表の元の名前ではなく、ごみ箱内の名前を使用する必要があります。ごみ箱内のオブジェクトに対して、DMLまたはDDL文を使用することはできません。 |
削除された表を取得します。
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$KSD8DB9L345KLA==$0" TO BEFORE DROP RENAME TO hr.emp_demo;
必要に応じて、すべての依存オブジェクトがごみ箱内のシステム生成の名前を保持していることを確認します。
次の問合せによって、取得されたhr.employee_demo
表の索引の名前を確認します。
SELECT INDEX_NAME FROM USER_INDEXES WHERE TABLE_NAME = 'EMPLOYEE_DEMO'; INDEX_NAME ------------------------------ BIN$JKS983293M1dsab4gsz/I249==$0
必要に応じて、取得された索引を元の名前に変更します。
次の文を実行すると、索引がその元の名前であるi_emp_demo
に変更されます。
ALTER INDEX "BIN$JKS983293M1dsab4gsz/I249==$0" RENAME TO I_EMP_DEMO;
取得された表に、ごみ箱に配置される前に参照制約が含まれていた場合は、その参照制約を再作成します。
ごみ箱では表に対する参照制約が保存されないため、この手順は手動で実行する必要があります。
複数のオブジェクトを同じ元の名前で作成し、その後削除できます。削除されたすべてのオブジェクトは、ごみ箱に保存されます。たとえば、次の例の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 2007-02-05:21:05:52 BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES 2007-02-05:21:25:13 BIN$yrMKlZaQMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES 2007-02-05:22:05:53
次のコマンドを使用すると、中間の表を取得できます。
FLASHBACK TABLE BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TO BEFORE DROP;
関連項目:
|
この項では、フラッシュバック・データベースを使用して、データベースに対する不要な変更を巻き戻す最も一般的な例について説明します。
FLASHBACK
DATABASE
コマンドを使用してデータベースの内容をフラッシュバック・ウィンドウ内の時点まで戻すには、「フラッシュバック・データベース、リストア・ポイントおよび保証付きリストア・ポイントについて」の説明に従って、フラッシュバック・ロギングを行うようにデータベースを構成する必要があります。保証付きリストア・ポイントまでデータベースを戻すには、「通常のリストア・ポイントと保証付きリストア・ポイントの使用」の説明に従って、保証付きリストア・ポイントを定義しておく必要があります。
フラッシュバック・データベースでは、コマンド実行時に存在した、データファイルに対する変更が取り消されます。重要な前提条件は、次のとおりです。
現行のデータファイルが消失または破損していないこと。FLASHBACK DATABASE
は、Oracle Databaseで行われたデータファイルに対する変更の巻戻しにのみ使用できます。メディア障害の修復には使用できません。
データファイルの誤った削除からのリカバリ、データファイルの縮小操作の取消しまたはデータベース名の変更の取消しをしようとしていないこと。
制御ファイルのリストアまたは再作成前の時点に戻すためにFLASHBACK
DATABASE
を使用しようとしていないこと。データベース制御ファイルがバックアップからリストアされるか、または再作成されると、すべての累積フラッシュバック・ログ情報が破棄されます。
互換性の変更を取り消すためにFLASHBACK
DATABASE
を使用しようとしていないこと。
関連項目: FLASHBACK DATABASEのコマンドの前提条件および使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』 を参照してください。 |
この項では、時刻書式、通常のリストア・ポイントまたは保証付きリストア・ポイントの名前、あるいはSCNを使用して目的の目標時点を指定し、データベースのフラッシュバックを実行する基本的な方法について説明します。
次の例では、現行のデータベースのインカネーション内の時点までデータベースを巻戻すと想定しています。最後のOPEN
RESETLOGS
の直前の時点までデータベースを戻す場合は、「フラッシュバック・データベースを使用したOPEN RESETLOGS操作の巻戻し」を参照してください。
デフォルトでは、FLASHBACK DATABASE
コマンドで使用されるSCNは、データベース・インカネーションの直系祖先パス内のSCNを参照します。「データベース・インカネーション」で説明されているように、データベースを以前にRESETLOGS
オプションでオープンした後で取り消さなかった場合、インカネーションはこのパス内にあります。取り消されたインカネーション内の変更を取得する場合は、「取り消されたインカネーション・ブランチ内のSCNへのデータベースの巻戻し」を参照してください。
フラッシュバック・データベース操作を行う手順
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-05 12.39.45 AM 2 YES
注意: フラッシュバック・ウィンドウが目的の目標時点に達する過去の時点まで提供されておらず、その目的の時点での保証付きリストア・ポイントが存在しない場合は、同じ結果を得るために、データベースのPoint-in-Timeリカバリを使用できます。詳細は、「データベースのPoint-in-Timeリカバリの実行」を参照してください。 |
データベースを、一貫性のある状態で停止し、インスタンスによってオープンされていないことを確認してからマウントします。
SHUTDOWN IMMEDIATE; STARTUP MOUNT;
手順1で実行した問合せを繰り返します。
データベースが停止されている場合は、一部のフラッシュバック・ロギング・データが生成されます。高速リカバリ領域での領域圧迫が原因でフラッシュバック・ログが削除された場合は、目的のSCNが取得不可になっている可能性があります。
注意: 目的のSCNがフラッシュバック・ウィンドウの範囲外にある場合にFLASHBACK DATABASE を実行すると、FLASHBACK DATABASE は失敗し、ORA-38729 エラーが戻されます。この場合、データベースは変更されません。 |
RMANを起動し、ターゲット・データベースに接続します。
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
コマンドを含めます。
RMANのFLASHBACK DATABASE
コマンドを実行します。
次の例に示すいずれかの形式のコマンドを使用して、目標時点を指定できます。
FLASHBACK DATABASE TO SCN 46963; FLASHBACK DATABASE TO RESTORE POINT BEFORE_CHANGES; FLASHBACK DATABASE TO TIME "TO_DATE('09/20/05','MM/DD/YY')";
FLASHBACK
DATABASE
コマンドが完了すると、データベースはマウントされたまま、指定した目標時点にリカバリされています。
SQL*Plusを使用してデータベースを読取り専用でオープンし、いくつかの問合せを実行して、データベースの内容を検証します。
次のように入力して、データベースを読取り専用でオープンします。
ALTER DATABASE OPEN READ ONLY;
データベースの状態が適切である場合は、手順8で手順を終了します。データベースの状態が適切でない場合は、手順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ユーティリティ』を参照してください。
フラッシュバックで誤ったリストア・ポイント、時刻または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まで戻されます。
フラッシュバック・データベースを使用してデータベースを過去の目標時点に巻き戻す場合、目標時点以降に変更されたブロックが判別され、フラッシュバック・ログからリストアされます。これをリストア・フェーズと呼びます。このフェーズの完了後、フラッシュバック・データベースでは、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リファレンス』 を参照してください。 |
RMANのDBPITRを実行すると、リカバリの目標時点より前のバックアップからデータベースがリストアされ、増分バックアップおよびREDOを使用してデータベースが目標時点までロールフォワードされます。SCN、時刻、ログ順序番号またはリストア・ポイントまでのリカバリを行うことができます。必要になった場合にPoint-in-Timeリカバリをより管理しやすい状態にしておくために、重要な時刻にリストア・ポイントを作成しておくことをお薦めします。
可能な場合は、データベースのPoint-in-Timeリカバリではなく、フラッシュバック・データベースを実行することをお薦めします。バックアップを使用したメディア・リカバリは、最後に行った変更を取り消すためにフラッシュバックを使用できない場合の最後の手段として使用してください。
データベースのPoint-in-Timeリカバリの前提条件は、次のとおりです。
データベースはARCHIVELOG
モードで実行されている必要があります。
DBPITRの目的のSCNより前のすべてのデータファイルのバックアップ、およびバックアップのSCNと目的のSCNの間の期間のアーカイブ・ログが存在している必要があります。
コマンドの前提条件および使用上の注意の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』のRECOVERエントリに関する項を参照してください。
この項では、DBPITRの基本手順について説明します。この手順では、次のことを想定しています。
現行のデータベースのインカネーション内で、DBPITRを実行します。目標時点が現行のインカネーション内に存在しない場合は、祖先インカネーションへのDBPITRについて、「祖先インカネーションへのデータベースのリカバリ」を参照してください。
制御ファイルは現行のものです。バックアップ制御ファイルをリストアする必要がある場合は、「バックアップ制御ファイルを使用したリカバリの実行」を参照してください。
データベースでは、現行のサーバー・パラメータ・ファイルが使用されています。バックアップ・サーバー・パラメータ・ファイルをリストアする必要がある場合は、「サーバー・パラメータ・ファイルのリストア」を参照してください。
DBPITRを実行する場合は、RESTORE
およびRECOVER
コマンドで個々にUNTIL
句を指定するのではなく、SET
UNTIL
コマンドを使用して目標時点を手順の最初に設定することによって、エラーを回避できます。これによって、バックアップからリストアされたデータファイルに十分に古いタイムスタンプが設定され、後続のRECOVER
操作に使用できます。
DBPITRを実行する手順
リカバリを終了する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-05 20043 2 344890615 1 2 20043 24-SEP-05 20045 3 344890618 1 3 20045 24-SEP-05 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
ブロック内で、次の操作を実行します。
SET
UNTIL
を使用して、DBPITRの目標時点、リストア・ポイント、SCNまたはログ順序番号を指定します。時刻を指定する場合は、環境変数NLS_LANG
およびNLS_DATE_FORMAT
で指定した日付書式を使用します。
自動チャネルを構成していない場合は、必要に応じて、ディスク・チャネルおよびテープ・チャネルを手動で割り当てます。
データベースをリストアおよびリカバリします。
次の例では、ターゲット・データベースでSCN 1000までDBPITRを実行します。
RUN { SET UNTIL SCN 1000; RESTORE DATABASE; RECOVER DATABASE; }
また、次の例に示すように、時刻書式、リストア・ポイントまたはログ順序番号を使用して、SET
UNTIL
時刻を指定することもできます。
SET UNTIL TIME 'Nov 15 2004 09:00:00'; SET UNTIL SEQUENCE 9923; SET UNTIL RESTORE POINT before_update;
操作がエラーを戻さずに完了した場合、DBPITRは正常に終了しています。
次の相互に排他的ないずれかのアクションを実行します。
データベースを読取り/書込みでオープンし、目的のSCN以降のすべての変更を取り消します。この場合は、データベースを停止し、マウントしてから、次のコマンドを実行する必要があります。
ALTER DATABASE OPEN RESETLOGS;
データファイルがオフラインになっていると、データファイルが正常にオフラインにされているか、または読取り専用である場合を除き、OPEN RESETLOGS
操作が失敗します。RESETLOGS
の実行後はREDOが不要になるため、読取り専用またはNORMALモードでオフラインにされた表領域のファイルをオンラインにすることができます。
データ・ポンプ・エクスポートを使用してデータベースから1つ以上のオブジェクトをエクスポートします。次に、データベースを現在の時点までリカバリして、エクスポートされたオブジェクトを再インポートします。これによって、他のすべての変更を取り消さずにこれらのオブジェクトを不要な変更前の状態に戻すことができます。
この項では、「フラッシュバック・データベースを使用したデータベースの巻戻し」および「データベースのPoint-in-Timeリカバリの実行」で説明されている基本例を少し変更した例について説明します。
フラッシュバック・データベースを使用して不要なALTER DATABASE OPEN RESETLOGS
文の結果を前の状態に戻すための手順は、「フラッシュバック・データベース操作の実行」で説明する通常の場合と類似しています。ただし、FLASHBACK
DATABASE
コマンドで特定のSCNまたは時点を指定するかわりに、FLASHBACK
DATABASE
TO
BEFORE
RESETLOGS
を使用します。
OPEN
RESETLOGS
操作を取り消す手順
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
より大きい場合は、Oracle Flashback Databaseを使用してOPEN
RESETLOGS
を前の状態に戻すことができます。
データベースを停止してマウントし、フラッシュバック・ウィンドウを再確認します。RESETLOGS SCNがまだフラッシュバック・ウィンドウ内にある場合は、次の手順に進みます。
RMANをターゲット・データベースに接続し、RESETLOGS
の直前のSCNまでフラッシュバックを実行します。
次の形式のFLASHBACK
DATABASE
コマンドを使用します。
FLASHBACK DATABASE TO BEFORE RESETLOGS;
FLASHBACK
DATABASE
の他の使用例と同様に、ターゲットSCNがフラッシュバック・データベース・ウィンドウの開始時点より前である場合は、エラーが戻され、データベースは変更されません。コマンドが正常終了した場合、データベースはマウントされたまま、以前のインカネーションでOPEN RESETLOGS
が実行される前の最新のSCNまでリカバリされます。
SQL*Plusを使用してデータベースを読取り専用でオープンし、必要に応じて問合せを実行して、論理的な破損の影響が無効にされたことを確認します。
次のように入力して、データベースを読取り専用でオープンします。
ALTER DATABASE OPEN READ ONLY;
データベースを再度更新できるようにするには、データベースを停止してマウントしてから、次のコマンドを実行します。
ALTER DATABASE OPEN RESETLOGS;
OPEN RESETLOGS
をまたぐフラッシュバック・データベースは、Data Guard環境で次の機能を実現するために使用できます。
ロジカル・スタンバイ・スイッチオーバーを取り消すためのフラッシュバック
この場合、データベースは、フラッシュバック・データベース操作の目標時点での役割(プライマリまたはスタンバイ)に戻されます。
フィジカル・スタンバイのアクティブ化の取消し
一時的にフィジカル・スタンバイ・データベースをアクティブ化し、テストまたはレポートの目的で使用してから、フラッシュバック・データベースを使用してフィジカル・スタンバイとしての役割に戻すことができます。
テスト目的でのスタンバイ・データベースの継続的な使用
フラッシュバック・データベースを使用すると、ストレージ・スナップショットを使用する必要がなくなります。
関連項目: Data Guardでのフラッシュバック・データベースのこれらの高度な適用の詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
フラッシュバック・データベースまたは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までデータベースを巻き戻す手順
SQL*Plusを使用してターゲット・データベースに接続し、SCNまでフラッシュバックするための十分な情報がフラッシュバック・ログに含まれていることを確認します。
たとえば、次の問合せを実行します。
SELECT OLDEST_FLASHBACK_SCN FROM V$FLASHBACK_DATABASE_LOG;
フラッシュバック・データベース操作のターゲット・インカネーション番号(親インカネーションのインカネーション・キー)を特定します。
たとえば、次の問合せを実行します。
SELECT PRIOR_INCARNATION# FROM V$DATABASE_INCARNATION WHERE STATUS = 'CURRENT';
RMANを起動し、ターゲット・データベースに接続します。
次のように入力して、データベースを停止してからマウントします。
SHUTDOWN IMMEDIATE; STARTUP MOUNT;
データベース・インカネーションを親インカネーションに設定します。
たとえば、次のコマンドを使用してインカネーション1に戻ります。
RESET DATABASE TO INCARNATION 1;
FLASHBACK
DATABASE
コマンドを実行し、目的のSCNを指定します。
たとえば、次のコマンドを使用して、データベースをSCN 1500まで巻き戻します。
FLASHBACK DATABASE TO SCN 1500;
SQL*Plusを使用してデータベースを読取り専用でオープンし、必要に応じて問合せを実行して、論理的な破損の影響が無効にされたことを確認します。
次のように入力して、データベースを読取り専用でオープンします。
ALTER DATABASE OPEN READ ONLY;
データベースを再度更新できるようにするには、データベースを停止してマウントしてから、次のコマンドを実行します。
ALTER DATABASE OPEN RESETLOGS;
関連項目:
|
現行のインカネーション内での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がリカバリ・カタログに接続されています。
2007年10月2日にターゲット・データベースtrgt
のバックアップを実行しています。
2007年10月10日にこのデータベースに対してDBPITRを実行し、以前のエラーを修正しています。DBPITRの最後にOPEN
RESETLOGS
操作を実行して、新しいインカネーションを開始しています。
10月25日、2007年10月8日午前8時にデータベースから削除された重要なデータが必要であることが判明したとします。これは、現行のインカネーションの開始点より前の時刻です。
DBPITRを現行以外のインカネーションに実行する手順
RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。
バックアップの時点での現行のデータベース・インカネーションを特定します。
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-06 1 582 TRGT 1224038686 CURRENT 59727 10-OCT-06
Reset SCN
およびReset Time
列を参照し、正しいインカネーションを特定して、Inc
Key
列内のインカネーション・キーを書き留めます。この例では、バックアップは2007年10月2日に実行されました。この場合、インカネーション・キーの値は2です。
データベースは起動されているが、マウントされていないことを確認します。
STARTUP FORCE NOMOUNT
ターゲット・データベースを、手順2で取得したインカネーションに再設定します。
この例では、10月2日のバックアップ時点での現行インカネーションを指定します。Inc Key
列の値を使用して、インカネーションを識別します。
RESET DATABASE TO INCARNATION 2;
RUN
コマンドで次の操作を実行して、データベースをリストアおよびリカバリします。
リカバリの終了時刻を、データが消失する直前の時刻に設定します。
構成されていない必要なチャネルを割り当てます。
10月2日のバックアップから制御ファイルをリストアし、マウントします。
データファイルをリストアし、データベースをリカバリします。RECOVER DATABASE
...
UNTIL
コマンドを使用してDBPITRを実行し、データが消失する直前の10月8日午前7時55分の目標時点にデータベースを戻します。
次の例では、この場合に必要なすべての手順を示しています。
RUN { SET UNTIL TIME 'Oct 8 2007 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バックアップおよびリカバリ・リファレンス』 を参照してください。 |