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

誤ったデータベースの更新による影響が発生した後に、データベース内のオブジェクトやデータベース全体を以前の状態に戻す必要がある場合があります。たとえば、ユーザーまたはDBAが1つ以上の表の内容を誤って削除または更新したり、必要なデータベース・オブジェクトを削除したり、またはアプリケーションの更新や大規模なバッチ更新などの危険を伴う操作が失敗する場合があります。

データベース全体のPoint-in-Timeリストアおよびリカバリに加えて、OracleではOracle Flashback Technologyと呼ばれる機能グループが提供されます。これらの機能は、Point-in-Timeリカバリより高速である場合があり、また、データベースの可用性を損なう可能性が低くなります。

この章では、不要なデータベースの変更を調査し、Oracle Flashback Technologyとデータベースのバックアップに基づいて適切なリカバリ計画を選択および実施するためのガイドラインを示します。この章では、次の項目について説明します。

• Point-in-Timeリカバリとフラッシュバックの機能

• Oracle Flashback Query: 行レベルでのリカバリ

• Oracle Flashback Table: 個々の表の過去の状態へのリカバリ

• Oracle Flashback Drop: DROP TABLE操作の取消し

• Oracle Flashback Databaseを使用したデータベースの変更の取消し

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

Point-in-Timeリカバリとフラッシュバックの機能

不要なデータベースの変更に対する最も一般的な解決策は、データベースのPoint-in-Timeリカバリです。これは、バックアップからデータベースをリストアした後で、REDOログを適用し、不要な変更を行う前の時点までのすべての変更を再作成するものです。

Oracle Flashback Technologyでは、データベースをバックアップからリストアしなくても、データの過去の状態を表示したり、データを過去の任意の時点に戻すことができる一連の機能の様々な代替機能が提供されます。データベースの変更内容によっては、Oracle Flashback Technologyを使用した方が、不要な変更をより短時間で元に戻したり、データベースの残りの部分の可用性に与える影響をより少なくできる場合があります。

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

データベースのPoint-in-Timeリカバリ（DBPITR）は、物理レベルで動作して、データ・ファイルを過去の目標時点の状態に戻す処理です。Recovery ManagerのDBPITR操作では、ユーザーが目標時点を指定すると、Recovery Managerは、その時点より前のバックアップからデータベースをリストアし、その後で増分バックアップの適用とメディア・リカバリを実行して、データ・ファイルのバックアップの時刻と目標時点の間に行われたすべての変更を再作成します。バックアップ計画が適切に設計されていて、データベースがARCHIVELOGモードで実行されている場合、ほとんどすべての環境でDBPITRが選択肢の1つになります。

Recovery Managerを使用すると、DBPITRはユーザー管理のDBPITRに比べて大幅に簡単になります。ターゲットSCNを指定すると、ユーザーが介入することなく、データ・ファイルがバックアップからリストアされ、ディスクまたはテープで使用可能な増分バックアップとアーカイブREDOログを使用して効率的にリカバリされます。ただし、Point-in-Timeリカバリにはいくつかのデメリットがあります。

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

• データベースのPoint-in-Timeリカバリ・プロセスの実行中はデータベース全体が使用できなくなります。

• Point-in-Timeリカバリでは、すべてのデータ・ファイルをリストアし、REDOログと増分バックアップをバックアップからリストアしてデータ・ファイルのリカバリで使用する必要があるため、リカバリに時間がかかる可能性があります。必要なバックアップがテープに格納されている場合、このプロセスはさらに時間がかかる可能性があります。

  注意: 不要なデータベースの変更が大量にあっても、データベースの特定の表領域に限定される場合、表領域のPoint-in-Timeリカバリ（TSPITR）を使用すると、データベースで影響のない表領域は使用可能なまま、表領域のサブセットを以前のSCNに戻すことができます。TSPITRは高度な手法です。詳細は、『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

Oracle Flashback Technology: Point-in-Timeリカバリの代替方法

Oracleのフラッシュバック機能が使用可能なほとんどの環境では、これらの機能はメディア・リカバリよりも効率的です。また、これらの機能は過去の状態の調査にも使用できます。Oracle Flashback Technologyのほとんどの機能は論理レベルで動作して、データベース・オブジェクトの表示および操作を行います。次に例を示します。

• Oracle Flashback Queryを使用すると、目標時点を指定してデータベースに対する問合せを実行し、その時点での状態を示す結果を表示できます。表に対する誤った更新などの不要な変更からリカバリするには、その変更が発生する前の目標時点を選択し、問合せを実行して消失した行の内容を取得します。

• Oracle Flashback Version Queryを使用すると、指定した期間に1度でも表に存在したすべての行のすべてのバージョンを表示できます。また、異なるバージョンの行のメタデータ（そのバージョンを作成したトランザクションの開始時刻、終了時刻、操作、トランザクションIDなど）を取得できます。この機能は、消失したデータの値のリカバリおよび問い合せた表への変更の監査の両方に使用できます。

• Oracle Flashback Transaction Queryを使用すると、1つのトランザクションまたは一定期間内のすべてのトランザクションによる変更を表示できます。

• Oracle Flashback Tableを使用すると、表を過去の時点の状態に戻すことができます。データベースがオンラインである間に表データをリストアし、指定した表に対する変更のみを取り消すことができます。

• Oracle Flashback Dropを使用すると、DROP TABLE文の影響を無効にできます。

Oracle Flashback Table、Oracle Flashback Query、Oracle Flashback Transaction QueryおよびOracle Flashback Version Queryは、いずれもUNDOデータ（Oracleデータベースに対する各更新の影響および更新時に上書きされた値の記録）に依存します。これらのUNDOレコードは、主にSQL問合せに対する読取り一貫性の提供やトランザクションのロールバックなどのために使用され、過去の状態のデータを再構築したり、過去の時点からの変更の記録を確認するために必要な情報を含みます。

Oracle Flashback Dropは、ごみ箱というメカニズムを使用して構築されます。Oracleは、ごみ箱を使用して、削除されたデータベース・オブジェクトによって使用されていた領域に新しいデータを格納することが必要になるまで、これらのデータベース・オブジェクトを管理します。

Oracle Flashback Databaseを使用すると、データベースのPoint-in-Timeリカバリより効率的で直接的なリカバリを実行できます。この機能は、物理レベルで動作する点で他のフラッシュバック機能と異なります。Oracle Flashback Databaseを使用すると、現行のデータ・ファイルが過去の時点の内容に戻ります。結果はデータベースのPoint-in-Timeリカバリの結果とほぼ同じになりますが、バックアップからデータ・ファイルをリストアする必要がなく、メディア・リカバリと比較して、適用が必要なREDOの数が限られているため、より短時間でリカバリが行われます。

Oracle Flashback Databaseでは、フラッシュバック・ログを使用して、データ・ブロックの過去のバージョン、およびアーカイブREDOログに含まれる情報の一部にアクセスします。データベースの修復にOracle Flashback Databaseを使用するには、フラッシュバック・ログを生成するようにデータベースを構成するか、または保証付きリストア・ポイントの関連機能を使用して、特定の時点（危険を伴うデータベースの変更の直前など）でのデータベースの内容を保護する必要があります。

参照 UNDOデータおよび自動UNDO管理の詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。 Oracle Flashback Query、Oracle Flashback Transaction QueryおよびOracle Flashback Version Queryの詳細は、『Oracle Databaseアプリケーション管理者ガイド-基礎編』を参照してください。 Oracle Flashback Databaseを使用するたのデータベースの設定および関連するリストア・ポイント機能の詳細は、「リストア・ポイントおよびOracle Flashback Databaseを使用したデータ保護」を参照してください。

Oracle Flashback Query: 行レベルでのリカバリ

データをリカバリする場合、過去の時点での表の状態を問合せできると有効です。たとえば、午後12時30分に従業員「JOHN」がEMP表から削除されたことが判明し、午前9時30分にはJOHNのデータがデータベースに正しく格納されていたことがわかっている場合は、削除前の時点の表の内容を問い合せてどのデータが消失したかを確認し、必要に応じて、その消失したデータをデータベースに再挿入できます。

表の過去の状態を問い合せるには、SELECT文のAS OF句を使用します。たとえば、2005年4月4日午前9時30分の「JOHN」の従業員レコードの状態を取得するには、次の問合せを実行します。

SELECT * FROM EMP AS OF TIMESTAMP 
   TO_TIMESTAMP('2005-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')
   WHERE name = 'JOHN';

JOHNの情報をEMP表にリストアするには、次の更新が必要です。

INSERT INTO EMP 
    (SELECT * FROM EMP AS OF TIMESTAMP 
     TO_TIMESTAMP('2005-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')
     WHERE name = 'JOHN');

欠落した行が過去の内容で再作成され、実行されているデータベースへの影響が最小限に抑えられます。

参照: SQL文SELECT... AS OFの使用方法および使用例の詳細は、『Oracle Databaseアプリケーション管理者ガイド-基礎編』を参照してください。 SELECT... AS OF形式のSELECT文の構文の詳細は、『Oracle Database SQLリファレンス』を参照してください。

Oracle Flashback Table: 個々の表の過去の状態へのリカバリ

Oracle Flashback Tableを使用すると、DBAは、データベースをオフラインにせずに、1つまたは複数の表を、指定した過去の時点まで迅速かつ簡単にリカバリできます。多くの場合、Oracle Flashback Tableを使用すると、複雑なPoint-in-Timeリカバリ操作を実行する必要がなくなります。Oracle Flashback Tableによって、現行の索引、トリガー、制約などの関連する属性が自動的に保持され、表がリストアされます。DBAがアプリケーション固有のプロパティを検索およびリストアする必要はありません。Oracle Flashback Tableを使用すると、個々の表の内容が、任意の過去のSCNまたは時刻の状態に戻ります。

Oracle Flashback Tableでは、UNDO表領域の情報を使用して表がリストアされます。バックアップからデータをリストアする必要はありません。また、Oracle Flashback Table操作の実行中、データベースの残りの部分は使用可能のままになります。

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

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

Oracle Flashback Tableを使用する場合の前提条件

表に対してOracle Flashback Table機能を使用する場合の前提条件は次のとおりです。

• 表で行の移動が有効である必要があります。 行の移動を有効にするには、次のSQL文を使用します。

  ALTER TABLE table ENABLE ROW MOVEMENT;
  
  

• FLASHBACK ANY TABLEシステム権限または表に対するFLASHBACKオブジェクト権限を持っている必要があります。

• 表に対するSELECT、INSERT、DELETEおよびALTER権限を持っている必要があります。

• 指定した目標時点またはSCNまでのFLASHBACK TABLE操作に必要な過去の時点までのUNDO情報が、UNDO表領域に保持されている必要があります。

  注意: FLASHBACK TABLE ... TO BEFORE DROP文は、Oracle Flashback Tableではなく、Oracle Flashback Dropの機能を使用するので、これらの前提条件に従いません。 詳細は、「Oracle Flashback Drop: DROP TABLE操作の取消し」を参照してください。

Oracle Flashback Tableの実行

次のSQL*Plus文を使用すると、EMP表に対するFLASHBACK TABLE操作を実行できます。

EMP表が、SCNで指定した時点の状態にリストアされます。

FLASHBACK TABLE EMP TO SCN 123456; 

また、TO_TIMESTAMPを使用してFLASHBACK TABLE操作の目標時点を指定することもできます。次に例を示します。

FLASHBACK TABLE EMP TO TIMESTAMP 
      TO_TIMESTAMP('2005-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')

注意: SCNへのタイムスタンプのマッピングは、必ずしも正確ではありません。 FLASHBACK TABLE文でタイムスタンプを使用する場合、表がフラッシュバックされる実際の時間は、TO_TIMESTAMPで指定した時間と比較すると、最大で約3秒異なる可能性があります。 正確な時間が必要な場合は、時刻書式ではなくSCNを使用します。

デフォルトでは、データベースはFLASHBACK TABLE操作を実行する前に、影響を受ける表のトリガーを無効にし、その操作の後で、トリガーを操作前の状態（有効または無効）に戻します。表のトリガーをFLASHBACK TABLE操作中に適用させる場合は、ENABLE TRIGGERS句をFLASHBACK TABLE文に追加します。

FLASHBACK TABLE table_name 
        TO TIMESTAMP timestamp ENABLE TRIGGERS;

次の例は、Oracle Flashback Tableを使用できる論理的な破損の典型的な例です。

午後5時に人事管理者によって、従業員JOHNがEMP表から欠落していることが判明しました。この従業員は、レポートが最後に実行された午後2時には表に存在していました。したがって、午後2時から現在までの間に、誰かが誤ってJOHNのレコードを削除したのです。人事管理者は、Oracle Flashback Tableを使用して、EMP表に設定されているトリガーを有効にして、表を午後2時の状態に戻します。この場合は、次のように入力します。

FLASHBACK TABLE EMP 
        TO TIMESTAMP TO_TIMESTAMP('2005-03-03 14:00:00') ENABLE TRIGGERS;

参照: Oracle Flashback Tableの簡単な使用例は、『Oracle Database SQLリファレンス』を参照してください。

Oracle Flashback Drop: DROP TABLE操作の取消し

Oracle Flashback Dropを使用すると、DROP TABLE操作の影響を無効にできます。この機能を使用すると、誤って削除した表をリカバリできます。Oracle Flashback Dropは、このような状況で使用可能な他のリカバリ方法（Point-in-Timeリカバリなど）より大幅に高速に実行でき、最新のトランザクションも保持し、停止時間も発生しません。

表を削除した場合、その表に関連付けられた領域はすぐには削除されません。かわりに、表の名前が変更され、関連付けられたオブジェクトとともにデータベースのごみ箱に移動されます。削除のフラッシュバック操作を実行すると、その表がごみ箱からリカバリされます。

Oracle Flashback Dropの使用方法を理解するには、ごみ箱の仕組み、その内容へのアクセス方法およびその管理方法も理解する必要があります。

この項の内容は、次のとおりです。

• ごみ箱の概要

• ごみ箱への表およびその他のオブジェクトの移動

• ごみ箱内のオブジェクトのネーミング規則

• ごみ箱内のオブジェクトの表示および問合せ

• ごみ箱の容量と領域圧迫

• ごみ箱からのオブジェクトの消去

ごみ箱の概要

ごみ箱は、削除されたすべての表およびそれらの依存オブジェクトを格納する論理的なコンテナです。表が削除されると、後でリカバリできるように表とその依存オブジェクトがごみ箱に格納されます。ごみ箱に格納される依存オブジェクトには、索引、制約、トリガー、ネストした表、LOBセグメント、LOB索引セグメントが含まれます。

ごみ箱への表およびその他のオブジェクトの移動

DROP TABLE文を実行するたびに、表とその依存オブジェクトがごみ箱に移動されます。たとえば、次の文を実行すると、EMPLOYEE_DEMO表が、前述した索引、制約などの依存オブジェクトとともにごみ箱に移動されます。

SQL> DROP TABLE EMPLOYEE_DEMO;
Table Dropped

表およびその依存オブジェクトは、ごみ箱から消去されるまでごみ箱の中に残ります。 SQL*PlusのPURGE文を使用すると、表またはその他のオブジェクトをごみ箱から明示的に消去できます（「ごみ箱からのオブジェクトの消去」を参照）。後で表をリカバリする必要がないことが確実な場合は、DROP TABLE文にPURGEオプションを使用して、その表をごみ箱に移動せず、即時永続的に削除できます。たとえば、次のように入力します。

DROP TABLE employee_demo PURGE;

ごみ箱からオブジェクトを明示的に消去しない場合でも、表領域の制約を満たすために、データベースによってごみ箱からオブジェクトが削除される場合があります。 詳細は、「ごみ箱の容量と領域圧迫」を参照してください。

ごみ箱内のオブジェクトは、使用領域とはみなされません。領域のビューを問い合せてデータベース内の空き領域を取得すると、ごみ箱内のオブジェクトは空き領域とみなされます。

オブジェクトは、削除された後もビューUSER_TABLES、ALL_TABLES、DBA_TABLES、USER_INDEX、ALL_INDEXおよびDBA_INDEXに表示されます。新しい列DROPPEDが、これらのオブジェクトに対してYESに設定されます。これらのビューに対する問合せにDROPPED列を使用すると、削除されていないオブジェクトのみを表示できます。

ごみ箱内のオブジェクトのみを表示するには、この章で後述するUSER_RECYCLEBINおよびDBA_RECYCLEBINビューを使用します。

ごみ箱内のオブジェクトのネーミング規則

表およびその依存オブジェクトは、ごみ箱に移動されると一意の名前が割り当てられ、名前の競合が回避されます。名前の競合は、次の状況で発生する場合があります。

• 1人のユーザーが表を削除し、同じ名前の別の表を作成して、その表も削除した場合

• 2人のユーザーが表に同じ名前を付け、2人とも表を削除した場合

割り当てられる名前はグローバルに一意で、ごみ箱に格納されている間のオブジェクトを識別するために使用されます。オブジェクト名の形式を次に示します。

BIN$$globalUID$version

次に、ここで示されている文字列について説明します。

• globalUIDは、オブジェクト用に生成されるグローバルに一意な24文字の識別子です。

• versionは、データベースによって割り当てられるバージョン番号です。

ごみ箱内のオブジェクトの名前は、常に30文字です。

ごみ箱での名前に使用されるglobalUIDは、オブジェクトまたはデータベースの情報が一目でわかるような、直接内容に関連する文字列ではありません。

ごみ箱の有効化および無効化

デフォルトでは、ごみ箱は有効に設定されています。初期化パラメータRECYCLEBINを使用して、ごみ箱を明示的に有効または無効にすることができます。

ごみ箱を有効にするには、RECYCLEBINの値をONに設定します。ごみ箱を無効にするには、RECYCLEBINの値をOFFに設定します。

データベースでパラメータ・ファイル（PFILE）を使用している場合は、パラメータ・ファイルのRECYCLEBINの値を指定できます。次に例を示します。

# turn off recycle bin
RECYCLEBIN=OFF

この値は、すべてのデータベース・セッションに適用されます。

ユーザー独自のデータベース・セッションにごみ箱の動作を指定するには、SQL*PlusでALTER SESSION文を使用して、そのセッション用のRECYCLEBINパラメータの値を変更できます。たとえば、次のコマンドでは、データベース・セッションのごみ箱が無効になります。

ALTER SESSION SET RECYCLEBIN=OFF;

このセッション中に削除するオブジェクトは、ALTER SESSION SET RECYCLEBIN=ONを使用してごみ箱を有効にするまで、ごみ箱に格納されなくなります。ただし、他のユーザーはごみ箱によって保護されたままです。また、将来のセッションでは、データベース全体に対し、この値が現行のデフォルトに戻されます。

また、SQL*PlusでALTER SYSTEM文を使用して、データベース全体に対し、RECYCLEBINパラメータの値を変更することもできます。次に例を示します。

ALTER SYSTEM SET RECYCLEBIN=OFF;

これによって、ユーザーがALTER SESSION SET RECYCLEBIN=ONを使用して自分のセッションのごみ箱を個別に有効にするまでは、すべてのセッションでのごみ箱が無効になります。

注意: ALTER SYSTEMまたはALTER SESSIONを使用して、ごみ箱を有効または無効にしても、すでにごみ箱にあるオブジェクトには影響しません。

ごみ箱内のオブジェクトの表示および問合せ

ごみ箱の内容を表示するには、SQL*PlusのSHOW RECYCLEBINコマンドを使用します。

SQL> 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列にごみ箱内でのオブジェクト名が表示されます。ごみ箱内の表を問い合せる場合は、RECYCLEBIN NAMEを使用します。

また、次の2つのビューで、ごみ箱内のオブジェクトの情報を取得できます。

ビュー	説明
USER_RECYCLEBIN	ユーザーが、自分でごみ箱に移動したオブジェクトを参照できます。簡単に使用するためのシノニムRECYCLEBINがあります。
DBA_RECYCLEBIN	管理者が、ごみ箱に移動されたすべてのオブジェクトを参照できます。

次の例では、ビューを使用して、削除したオブジェクトの元の名前を確認します。

SQL> 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
BIN$NR72JJN38KM1dsaM4gI348as==$0  LOB_EMP_DEMO           LOB
BIN$JKJ399SLKnaslkJSLK330SIK==$0  LOB_I_EMP_DEMO         LOB INDEX

次の3つの条件を満たしている場合は、他のオブジェクトを問い合せるときと同様に、ごみ箱内のオブジェクトを問い合せることができます。

• FLASHBACK権限を持っている。

• ごみ箱に移動される前のオブジェクトに対する問合せの実行に必要な権限を持っている。

• オブジェクトの元の名前ではなく、ごみ箱でのオブジェクトの名前を問合せに使用する。

次に、ごみ箱内のオブジェクトを問い合せる構文の例を示します。

SQL> SELECT * FROM "BIN$KSD8DB9L345KLA==$0";

（ごみ箱での名前に特殊文字を使用しているため、引用符を使用しています。）

また、ごみ箱の表に対してOracle Flashback Queryを使用することもできます（前述の権限が必要です）。

ごみ箱の容量と領域圧迫

ごみ箱には、事前に一定量の領域が割り当てられているわけではありません。そのため、削除されたオブジェクトがごみ箱に保持される最短期間も保証されていません。

この項では、オブジェクトがごみ箱に保持される期間および領域の再生方法および再生時期を決定する規則について説明します。

領域圧迫の理解

削除されたオブジェクトは、属している表領域に、その表領域を拡張せずに新しいエクステントを割り当てられなくなるまでごみ箱内に保持されます。この状態を、領域圧迫といいます。領域圧迫は、特定の表領域に定義されたユーザー割当て制限によって発生する場合もあります。表領域に空き領域が存在しても、ユーザーが表領域に対する割当て制限をすべて使用している場合があります。

領域圧迫に対する処理が必要となった場合を除いて、ごみ箱内の領域の再生またはオブジェクトの上書きは自動的には行われません。

データベースによる領域圧迫の処理

領域圧迫が発生すると、データベースによって、ごみ箱から自動的に消去するオブジェクトが選択されます。オブジェクトは、先入れ先出しの順序で消去されます。つまり、最初に削除されたオブジェクトが最初に消去されます。

実際のオブジェクトの消去は、発生した領域圧迫の解消に必要な場合にのみ行われます。つまり、すぐに必要な領域を確保するために消去する必要がある最小限の数のオブジェクトが選択され、消去されます。この方針によって、次の2つの目的が実現されます。

• 必要以上に消去操作を実行しないことで、領域圧迫を発生させたトランザクションのパフォーマンスの低下を最小限に抑えます。

• 領域が必要になるまでオブジェクトをごみ箱に残しておくことで、オブジェクトの保持期間を最大限に伸ばします。

表の索引などの依存オブジェクトは、関連付けられた表（またはその他の必要なセグメント）より先に消去されます。

個々のユーザーが表領域の割当て制限をすべて使用したために領域圧迫が発生した場合は、表領域に属するオブジェクトのうち、ユーザーの領域の割当て制限の負担になるオブジェクトが、ごみ箱から消去されます。

AUTO EXTENDを実行可能な表領域の場合、データ・ファイルが拡張される前にオブジェクトはごみ箱から消去され、領域が再生されます。

ごみ箱のオブジェクトとセグメント

ごみ箱は、表や索引などのオブジェクト・レベルで機能します。オブジェクトには、パーティション表、パーティション索引、LOBセグメント、ネストした表などの複数のセグメントが関連付けられている場合があります。データベースでは、領域圧迫をすぐに解消するために必要なセグメントのみが再生されるため、オブジェクトの一部のセグメントのみが再生される場合があります。この場合、すぐに再生されなかったオブジェクトのセグメントに、一時セグメントのマークが付けられます。これらの一時セグメントは、次に領域圧迫が発生した場合に、最初に再生されます。

このような場合は、Oracle Flashback Dropを使用して、部分的に再生されたオブジェクトをごみ箱から出すことはできません。（たとえば、パーティション表の1つのパーティションが再生された場合、その表は削除のフラッシュバックの対象にはなりません。）

ごみ箱内の表に対する削除のフラッシュバックの実行

FLASHBACK TABLE ... TO BEFORE DROP文を使用すると、オブジェクトをごみ箱からリカバリできます。ごみ箱内の表の名前または元の表の名前のいずれかを指定できます。 この名前は、DBA_RECYCLEBINまたはUSER_RECYCLEBINビューから取得できます（「ごみ箱内のオブジェクトの表示および問合せ」を参照）。 FLASHBACK TABLE ... TO BEFORE DROP文を使用するには、表を削除する場合と同様の権限が必要です。

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

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

引用符の使用には注意が必要です。これは、特殊文字がごみ箱のオブジェクト名に表示されている可能性があるためです。Oracle Flashback Drop操作では、表の元の名前を使用することもできます。

FLASHBACK TABLE HR.INT_ADMIN_EMP TO BEFORE DROP;

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

FLASHBACK TABLE "BIN$KSD8DB9L345KLA==$0" TO BEFORE DROP 
     RENAME TO hr.int2_admin_emp;

元の名前が同じ複数のオブジェクトに対する削除のフラッシュバック

元の名前が同じ複数のオブジェクトを作成して、削除できます。これらのすべてのオブジェクトは、ともにごみ箱に格納されます。たとえば、次のSQL文を実行するとします。

CREATE TABLE EMP ( ...columns ); # EMP version 1
DROP TABLE EMP;
CREATE TABLE EMP ( ...columns ); # EMP version 2
DROP TABLE EMP;
CREATE TABLE EMP ( ...columns ); # EMP version 3
DROP TABLE EMP;

この場合、各EMP表には、削除時にごみ箱での一意の名前が割り当てられます。 表の元の名前を指定してFLASHBACK TABLE ... TO BEFORE DROP文を実行できます。たとえば、次のように入力します。

FLASHBACK TABLE EMP TO BEFORE DROP;

その元の名前を持つ最後に削除された表が、元の名前でごみ箱から取り出されます。その表を取り出し、RENAME TO句を使用してその表に新しい名前を割り当てることができます。次の例では、前述の例で削除した3つすべてのEMP表をごみ箱から取り出し、それぞれに新しい名前を付けます。

FLASHBACK TABLE EMP TO BEFORE DROP RENAME TO EMP_VERSION_3;
FLASHBACK TABLE EMP TO BEFORE DROP RENAME TO EMP_VERSION_2;
FLASHBACK TABLE EMP TO BEFORE DROP RENAME TO EMP_VERSION_1;

FLASHBACK TABLE... TO BEFORE DROPで元の名前を使用すると、その名前を持つ、最後に削除された表が参照されるため、最初に取り出される表は、最後に削除された表になります。

また、ごみ箱での表の一意の名前を使用すると、元の名前が競合している場合でも、ごみ箱から目的の表を取り出すことができます。

ごみ箱からのオブジェクトの消去

PURGEコマンドを使用すると、オブジェクトをごみ箱から永続的に消去できます。一度消去したオブジェクトは、Oracle Flashback Dropを使用してごみ箱から取り出すことができなくなります。

PURGE文の形式は、ごみ箱から消去するオブジェクトによって異なります。

参照: PURGE文の詳細は、『Oracle Database SQLリファレンス』を参照してください。

PURGE TABLE: 表および依存オブジェクトの消去

PURGE TABLEコマンドを使用すると、個々の表およびそのすべての依存オブジェクトをごみ箱から消去できます。次に、表の元の名前を使用した構文の例を示します。

PURGE TABLE EMP;

また、PURGE TABLEにはごみ箱でのオブジェクトの名前も使用できます。

PURGE TABLE "BIN$KSD8DB9L345KLA==$0";

元の名前が同じ複数の表を作成して削除した場合、PURGE TABLE文を実行すると、最初に削除した表が消去されます。

注意: この場合の動作は、FLASHBACK TABLE... TO BEFORE DROPの動作（表の元の名前を使用すると、最後に削除した表がごみ箱から取り出される）と反対になります。

たとえば、次の一連のCREATE TABLEおよびDROP TABLE文を実行するとします。

CREATE TABLE EMP;   # version 1 of the table
DROP TABLE EMP;     # version 1 dropped
CREATE TABLE EMP;   # version 2 of the table
DROP TABLE EMP;     # version 2 dropped
CREATE TABLE EMP;   # version 3 of the table
DROP TABLE EMP;     # version 3 dropped

この時点で、3つのEMP表がごみ箱に格納されています。PURGE TABLE EMPを複数回実行した結果は、次のとおりです。

PURGE TABLE EMP;    # version 1 of the table is purged
PURGE TABLE EMP;    # version 2 of the table is purged
PURGE TABLE EMP;    # version 3 of the table is purged

PURGE INDEX: ごみ箱内の領域の解放

PURGE INDEXを使用すると、ごみ箱内の実表を保持したまま表の索引のみを消去できます。索引を消去するための構文は、次のとおりです。

PURGE INDEX "BIN$GTE72KJ22H9==$0";

ごみ箱から索引を消去することで、領域圧迫が発生する可能性を低減できるため、削除した表をより長くごみ箱に残しておくことができます。Oracle Flashback Dropを使用して表をごみ箱から取り出す場合は、表を取り出した後に索引を再作成できます。

PURGE TABLESPACE: 表領域内の削除したすべてのオブジェクトの消去

PURGE TABLESPACEコマンドを使用すると、特定の表領域内の、削除したすべての表および他の依存オブジェクトを消去できます。構文は次のとおりです。

PURGE TABLESPACE hr;

また、次の書式のコマンドを使用して、特定のユーザーに属する表領域のオブジェクトのみを消去することもできます。

PURGE TABLESPACE hr USER scott;

PURGE RECYCLEBIN: ユーザーのごみ箱内のすべてのオブジェクトの消去

PURGE RECYCLEBINコマンドを使用すると、現在ログインしているユーザーのごみ箱の内容を消去できます。

PURGE RECYCLEBIN;

このユーザーのすべての表とその依存オブジェクトが、このユーザーが所有する表の索引を除くすべての索引とともに消去されます。

PURGE DBA_RECYCLEBIN: ごみ箱内のすべてのオブジェクトの消去

SYSDBA権限を持っている場合は、どのユーザーがオブジェクトを所有しているかに関係なく、次のコマンドを使用して、すべてのオブジェクトをごみ箱から消去できます。

PURGE DBA_RECYCLEBIN;

表領域、クラスタ、ユーザーまたは型の削除とごみ箱

表領域をその内容とともに削除すると、表領域内のオブジェクトは即時削除され、ごみ箱には移動されません。削除した表領域内のオブジェクトがごみ箱に格納されている場合は、ごみ箱から消去されます。

表領域のすべてのオブジェクトがごみ箱に格納されている場合、DROP TABLESPACEでINCLUDING CONTENTS句を指定していない場合でも、表領域を削除するとオブジェクトが消去されます。

ユーザーを削除すると、そのユーザーに属するオブジェクトでごみ箱に格納されていないものは即時削除され、ごみ箱には移動されません。ユーザーに属するオブジェクトがごみ箱に格納されている場合は、ごみ箱から消去されます。

クラスタを削除すると、クラスタ内のすべての表が消去されます。ユーザー定義のデータ型を削除すると、その型に直接または間接的に依存するすべてのオブジェクトが消去されます。

Oracle Flashback Dropのための権限およびセキュリティ

この項では、Oracle Flashback Dropとごみ箱に関連する操作に必要なシステム権限について説明します。

• DROP

  オブジェクトを削除する権限を持つユーザーは、オブジェクトを削除してごみ箱に移動できます。

• FLASHBACK TABLE ... TO BEFORE DROP

  この権限は、DROP権限に関連付けられています。つまり、オブジェクトを削除できるユーザーは、Oracle Flashback Dropを実行して、削除したオブジェクトをごみ箱から取り出すことができます。

• PURGE

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

• ごみ箱内のオブジェクトに対するSELECT

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

Oracle Flashback Dropの制限事項

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

• ごみ箱には、一定量の領域が割り当てられていません。また、削除されたオブジェクトがごみ箱に保持される期間も保証されていません。削除されたオブジェクトがごみ箱内に保持される期間は、システムのアクティビティによって数秒から数か月まで異なります。

• ごみ箱に格納されているオブジェクトに対して問合せは実行できますが、DMLまたはDDL文は使用できません。

• ごみ箱内の表に対してフラッシュバック問合せは実行できますが、ごみ箱での名前を使用する必要があります。表の元の名前は使用できません。

• 表を削除すると、その表とすべての依存オブジェクト（索引、LOBセグメント、ネストした表、トリガー、制約など）も一緒にごみ箱に移動されます。同様に、Oracle Flashback Dropを実行すると、通常、すべてのオブジェクトが同時に取り出されます。

  ただし、索引などの一部の依存オブジェクトが、領域圧迫を解消するために再生される場合があります。このような場合、再生された依存オブジェクトはごみ箱から取り出されません。

• セキュリティ上の理由から、表に対してファイングレイン監査（FGA）およびVirtual Private Database（VPD）の方針が定義されている場合、その表はごみ箱によって保護されません。

• パーティション索引構成表は、ごみ箱によって保護されません。

• 表の参照制約は、ごみ箱に保持されません（ただし、他の制約は、可能であれば保持されます）。表を削除する（ごみ箱に移動する）前にその表に参照制約が定義されていた場合は、Oracle Flashback Dropを実行してごみ箱から表を取り出した後で参照制約を再作成します。

Oracle Flashback Databaseを使用したデータベースの変更の取消し

「Oracle Flashback Databaseの設定とメンテナンス」に示すように、データベースがフラッシュバック・ロギング用に構成されている場合は、FLASHBACK DATABASEコマンドを使用して、データベースの内容をフラッシュバックの期間内の時点に戻すことができます。 また、FLASHBACK DATABASEを使用すると、「通常のリストア・ポイントと保証付きリストア・ポイントの作成」に示すコマンドを使用して以前に定義した保証付きリストア・ポイントまで戻すこともできます。

この項では、Oracle Flashback Databaseを使用して、データベースに対する不要な変更を取り消す、一般的な使用例を説明します。この項では次の項目を取り上げます。

• Oracle Flashback Databaseの実行例

• 保証付きリストア・ポイントまでのデータベースのフラッシュバックの実行

• Oracle Flashback Databaseの実行によるOPEN RESETLOGSの取消し

  注意: 保証付きリストア・ポイントを定義していない場合は、そのターゲットSCNがフラッシュバックの期間（FLASHBACK DATABASEを使用できるSCNの範囲）内であることを確認します。 フラッシュバックの期間の確認方法については、「現行のデータベースのフラッシュバックの期間の確認」を、リカバリで使用できる保証付きリストア・ポイントの有無の確認方法については、「リストア・ポイントのリスト」を参照してください。 フラッシュバックの期間が目的の目標時点に達する過去の時点まで提供されておらず、その目的の時点での保証付きリストア・ポイントが存在しない場合は、同じ結果を得るために、データベースのPoint-in-Timeリカバリを使用できます。詳細は、「データベースのPoint-In-Timeリカバリの実行」を参照してください。

Oracle Flashback Databaseの実行例

この項では、Oracle Flashback Databaseを実行するためのプロセスについて、ほとんどすべての場合での基本的な概要を説明します。このプロセスでは、目的の目標時点の指定に、時刻書式、通常のリストア・ポイントか保証付きリストア・ポイントの名前、またはSCNを使用します。

Oracle Flashback Databaseの操作をRecovery Managerで実行するには、次の手順を使用します。

1. FLASHBACK DATABASEコマンドで使用する、目的のSCN、リストア・ポイントまたは時点を決定します。

   注意: SCNを使用して目標を指定し、データベースを、以前のPoint-in-TimeリカバリまたはOracle Flashback Databaseの操作を使用して取り消された変更が反映されている状態に戻す場合には、特に注意が必要なため、「Oracle Flashback Databaseおよびインカネーションをまたがった不明確なSCN」を参照してください。 目的が保証付きリストア・ポイントまでのフラッシュバックである場合は、「保証付きリストア・ポイントまでのデータベースのフラッシュバックの実行」に示す方法を使用できます。 目的が最後のOPEN RESETLOGS操作の直前の時点に、データベースを戻すことである場合は、「Oracle Flashback Databaseの実行によるOPEN RESETLOGSの取消し」に示す手順を使用します。

2. Recovery Managerを起動し、ターゲット・データベースに接続します。次に例を示します。

   rman TARGET /
   
   

3. データベースを正常に停止して、データベースをオープンしているインスタンスがないことを確認します。その後で、これをマウントします。

   RMAN> SHUTDOWN IMMEDIATE;
   RMAN> STARTUP MOUNT;
   
   

4. 「現行のデータベースのフラッシュバックの期間の確認」に示す問合せを再実行します。データベースを停止すると、いくつかのフラッシュバック・ロギング・データが生成されます。そのロギングに対応するフラッシュ・リカバリ領域の領域圧迫のためにデータベースのフラッシュバック・ログが削除されている場合、ターゲットSCNにフラッシュバックできない可能性があります。

   注意: FLASHBACK DATABASEを試行したときにターゲットSCNがすでにフラッシュバック期間の範囲外になっている場合、ORA-38729エラーが発生してFLASHBACK DATABASEが失敗します。この場合、データベースは変更されません。

5. Oracle Flashback Databaseの実行中、Recovery Managerで、バックアップからいくつかのアーカイブREDOログをリストアする必要がある場合があります。バックアップがテープに格納されているが、SBTデバイスへのアクセスに必要なチャネルを構成していない場合は、RUNブロック内にFLASHBACK DATABASEコマンドを指定し、必要に応じてALLOCATE CHANNELコマンドを発行して、Recovery Managerでディスクまたはテープからこれらのログを取得できるようにします。

6. 次の例に示すいずれかの形式のコマンドを使用して目標時点を指定し、Recovery ManagerのFLASHBACK DATABASEコマンドを実行します。

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

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

データベースを読取り専用でオープンし、いくつかの問合せを実行してデータベースの内容を検査することによって、データベースが目的の状態に戻っていることを確認できます。

RMAN> SQL 'ALTER DATABASE OPEN READ ONLY';

Oracle Flashback Database操作が正常に終了した後に実行可能な操作

Oracle Flashback Database操作後のデータベースの状態が適切である場合、次のいずれかの操作を実行できます。

• OPEN RESETLOGS操作を実行してデータベースを更新可能にする。

  RMAN> ALTER DATABASE OPEN RESETLOGS;
  
  

  注意: このOPEN RESETLOGS操作を実行すると、FLASHBACK DATABASEのターゲットSCNより後に実行されたデータベースに対するすべての変更が取り消されます。 ただし、「OPEN RESETLOGSの右側へのデータベースのフラッシュバックの例」に示す方法を使用すると、複数のSCNがフラッシュバックの期間内にあるかぎり、データベースをそれぞれのSCNの範囲まで戻すことができます。

• Oracleエクスポート・ユーティリティ（従来のエクスポートまたはData Pump Export）を使用して、破損しているオブジェクトをエクスポートします。その後、データベースを現在の状態に戻します。

  RMAN>  RECOVER DATABASE;
  
  

  この手順を実行すると、REDOログに記録されているすべての変更をデータベースに再適用し、最新のSCNに戻すことによって、Oracle Flashback Databaseの影響が取り消されます。

  データベースを読取り/書込みで再度オープンすると、以前使用したエクスポート・ユーティリティに対応するインポート・ユーティリティ（従来のインポートまたはData Pump Import）を使用して、エクスポートしたオブジェクトをインポートできます。

誤った時刻へのデータベースのフラッシュバック後に実行可能な操作

データベースの状態を調査した結果、Oracle Flashback Databaseに使用したリストア・ポイント、時刻またはSCNが誤っていることがわかった場合は、次のいずれかの操作を実行できます。

• 選択した目標時点が新しすぎた場合、FLASHBACK DATABASEコマンドを再度実行してデータベースを必要な時点まで戻すことができます。

  RMAN> FLASHBACK DATABASE TO SCN 42963;  #earlier than current SCN 
  
  

• 選択したターゲットSCNが古すぎた場合、データベースをマウントし、RECOVER DATABASE UNTILを使用してデータベースを目的のSCNまでの時点に進めることができます。

  RMAN> RECOVER DATABASE UNTIL SCN 56963; #later than current SCN 
  
  

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

  RMAN>  RECOVER DATABASE;
  
  

  これによって、データベースに対するすべての変更が再適用され、最新のSCNの状態に戻されます。

Oracle Flashback Databaseおよびインカネーションをまたがった不明確なSCN

Point-in-TimeリカバリまたはOracle Flashback Databaseが実施されたデータベースでは、時点を指定する方法としてSCNを使用するのは不明確な方法になる可能性があります。

OPEN RESETLOGSの後のOracle Flashback DatabaseまたはDBPITRの影響は、データベースが以前のSCNに戻され、その時点以降の変更が取り消されることです。したがって、その時点以降の一部のSCNは、取り消された変更を参照したり、データベースの現行の履歴での変更を参照する可能性があります。

デフォルトでは、FLASHBACK DATABASEコマンドで引数として使用されるSCNは、現行のインカネーション・パス（以前のDBPITRやOracle Flashback Databaseの後で取り消されていないインカネーション）での時点を参照するとみなされます。これが目的である場合は、Oracle Flashback Databaseに目標を指定するためにSCNを使用して、この項の手順を使用できます。

Oracle Flashback Databaseを使用して、以前のOracle Flashback DatabaseまたはDBPITRの後に取り消された変更に対応する時点までリカバリする場合は、「OPEN RESETLOGSの右側へのデータベースのフラッシュバックの例」に示す方法を使用できます。

参照: データベースのインカネーション、取り消された変更、およびOPEN RESETLOGSの影響については、「Point-in-Timeリカバリおよびデータベース・インカネーションの概要」を参照してください。

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

保証付きリストア・ポイントまでのデータベースのフラッシュバックの実行

V$RESTORE_POINTビューを使用して、使用可能な保証付きリストア・ポイントをリストできます。次に例を示します。

SQL> 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

使用するリストア・ポイントがわかっている場合は、データベースをマウントし、そのリストア・ポイントを使用してFLASHBACK DATABASEコマンドを実行します。次に例を示します。

RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP MOUNT;
RMAN> FLASHBACK DATABASE TO RESTORE POINT 'BEFORE_CHANGES';

コマンドが完了したら、データベースを読取り専用でオープンし、この操作の影響を調査します。結果が予定どおりである場合は、RESETLOGSオプションを指定してデータベースをオープンします。

Oracle Flashback Databaseの実行によるOPEN RESETLOGSの取消し

Oracle Flashback Databaseを使用して不要なOPEN RESETLOGSの前の状態に戻すための基本手順は、「Oracle Flashback Databaseの実行例」で説明する通常の場合と非常に似ています。

ただし、FLASHBACK DATABASEコマンドで特定のSCNまたは時点を指定するのではなく、FLASHBACK DATABASE TO BEFORE RESETLOGSを使用します。次に例を示します。

フラッシュバックを実行する前に、フラッシュバックの期間の開始時点が、最後のOPEN RESETLOGSの時刻よりも前であることを確認します。

sql> select resetlogs_change# from v$database;
sql> 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がまだフラッシュバックの期間内である場合は、FLASHBACK DATABASEコマンドを次の形式で使用します。

RMAN> FLASHBACK DATABASE TO BEFORE RESETLOGS;

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

データベースを読取り専用でオープンし、問合せを実行して、データが目的の状態になっていることを確認できます。データベースを更新可能な状態に戻すには、ALTER DATABASE OPEN RESETLOGSコマンドを使用します。

スタンバイ・データベースにおけるOPEN RESETLOGSに対するOracle Flashback Database

OPEN RESETLOGSに対してOracle Flashback Databaseがサポートされる場合、スタンバイ・データベースでのOracle Flashback Databaseの適用がいくつか可能になります。次に例を示します。

• フラッシュバックによるロジカル・スタンバイ・スイッチオーバーの取消し: データベースのロールがOracle Flashback Database操作の目標時点でのロール（プライマリまたはスタンバイ）に戻ります。

• フィジカル・スタンバイのアクティブ化の取消し: フィジカル・スタンバイ・データベースを一時的にアクティブ化し、テストまたはレポートに使用した後で、Oracle Flashback Databaseを使用してロールをフィジカル・スタンバイに戻すことができます。

• クローン・データベースまたはスタンバイ・データベースのテストへの継続的な使用: ストレージ・スナップショットの使用を必要としません。

Data GuardでのOracle Flashback Databaseのこれらの高度な適用の詳細は、『Oracle Data Guard概要および管理』を参照してください。

OPEN RESETLOGSの右側へのデータベースのフラッシュバックの例

現行のインカネーション・パスが古いインカネーションから分岐した時点のOPEN RESETLOGSのSCNよりも新しい、親インカネーションの時点にデータベースを戻す必要がある場合があります。 親インカネーションで取り消された変更に対応するこれらの時点は、図7-1「複数のRESETLOGSが存在するデータベースのインカネーション履歴」などのインカネーションを示す図で、最後のOPEN RESETLOGSの「右側」として表現することができます。たとえば、この図で、データベースがインカネーション3である場合に、インカネーション1で取り消したSCN 1500まで戻る必要があるとします。

Recovery ManagerのRESET DATABASE TO INCARNATIONコマンドを使用して、Oracle Flashback Databaseで使用するSCNが現行のインカネーションを参照するように指定できます。

このプロセスは次のとおりです。

• フラッシュバック・ログに、該当するSCNまでフラッシュバックするのに十分な情報があることを確認します。

  sql> select oldest_flashback_scn from v$flashback_database_log;
  
  

• フラッシュバックのターゲットのインカネーション番号（親インカネーションのインカネーション・キー）を決定します。

  SQL> select prior_incarnation# from v$database_incarnation where status = 
  'CURRENT';
  
  

• Recovery Managerで、データベースを停止してからマウントします。

  RMAN> SHUTDOWN IMMEDIATE;
  RMAN> STARTUP MOUNT;
  
  

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

  RMAN> RESET DATABASE TO INCARNATION 1;
  
  

• FLASHBACK DATABASEコマンドを実行します。

  RMAN> FLASHBACK DATABASE TO SCN 1500;
  
  

フラッシュバックが完了すると、結果を確認できます。成功した場合は、RESETLOGSを指定してデータベースをオープンします。

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

データベースのPoint-in-Timeリカバリ（DBPITR）を実行すると、リカバリの目標時点より前のバックアップからデータベースがリストアされ、増分バックアップおよびREDOを使用してデータベースが目標時点にロールフォワードされます。

使用可能なすべてのREDOが使用されたり、データベースに対するすべての変更が完全にリカバリされないため、DBPITRは不完全リカバリとも呼ばれます。

ターゲットSCNは日時で指定できます。この場合の操作は、時間ベースのリカバリとも呼ばれます。

データベースのPoint-in-Timeリカバリの要件

データベースのPoint-in-Timeリカバリの要件を次に示します。

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

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

Point-in-Timeリカバリおよびデータベース・インカネーションの概要

DBPITRを理解するには、データベース・インカネーションの背景情報と、Recovery Managerがどのように現行のインカネーション・パスではなく過去の時点のバックアップを処理するかという背景情報が必要です。特に、データベースを最後のOPEN RESETLOGSより前の時点に戻す場合には、特別な考慮事項があります。

この項では次の項目を取り上げます。

• 親、祖先および兄弟のデータベース・インカネーションの理解

• データベースのインカネーション履歴の例

• データベース・インカネーションと孤立したバックアップ

親、祖先および兄弟のデータベース・インカネーションの理解

RESETLOGSオプションを指定してデータベースをオープンするたびに、データベースの新しいインカネーションが作成されます。OPEN RESETLOGSを実行すると、現行のオンラインREDOログがアーカイブされ、インカネーションによってログ順序番号が1にリセットされて、オンラインREDOログに新しいタイムスタンプおよびSCNが設定されます。また、インカネーション番号が1つ増加します。インカネーション番号は、REDOのストリームを一意にタグ付けおよび識別するために使用されます。

インカネーションは相互に複数の相関関係を持つことができます。

• OPEN RESETLOGS操作によって、あるインカネーションから現行のインカネーションが分岐している場合、そのインカネーションを、現行のインカネーションの親インカネーションといいます。

• 親インカネーションとそのすべての親インカネーションは、現行のインカネーションの祖先インカネーションです。

• 共通の祖先を持つ2つのインカネーションは、一方のインカネーションが他方のインカネーションの祖先でない場合、兄弟インカネーションです。

データベースのインカネーション履歴の例

図7-1「複数のRESETLOGSが存在するデータベースのインカネーション履歴」に、複数のインカネーションを持つデータベースを示します。

図7-1    複数のRESETLOGSが存在するデータベースのインカネーション履歴

画像の説明

データベースのインカネーション1はSCN 1で始まり、SCN 1000からSCN 2000まで続いています。インカネーション1のSCN 2000で、Point-in-Timeリカバリを実行してSCN 1000まで戻し、RESETLOGS操作でデータベースをオープンします。これによって、SCN 1000で始まりSCN 3000まで続く、インカネーション2が作成されます。インカネーション2のSCN 3000で、別のPoint-in-Timeリカバリを実行し、RESETLOGS操作を行います。これによって、SCN 2000で始まるインカネーション3が作成されます。

LIST INCARNATIONコマンドを使用して、データベースのインカネーション履歴を表示できます。この図のインカネーション履歴を表す出力を、次に示します。

LIST INCARNATION;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID          STATUS   Reset SCN  Reset Time
------- ------- -------- -------------- -------  ---------- ----------
1       1       TRGT     930791268      PARENT   1          23-APR-05
2       2       TRGT     930791268      PARENT   1000       23-APR-05
3       3       TRGT     930791268      CURRENT  2000       23-APR-05

Reset SCN列の値は、RESETLOGSが実行されたときのSCNです。Inc Key列には、インカネーション・キーが示されます。Recovery Managerでは、一部のコマンドで、インカネーション・キーを使用してデータベース・インカネーションを指定します。たとえば、RESET DATABASE TO INCARNATIONを使用して、一部の複雑なリカバリの例で現行のインカネーションを変更します。

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

兄弟インカネーション、不明確なSCNおよびRESET DATABASE INCARNATION

フラッシュバックまたはPoint-in-Timeリカバリ操作によって兄弟インカネーションが生成されているデータベースを使用する場合、現行のインカネーションとして設定されているインカネーションによって、特定のSCN値が複数の時点を示す場合があることに注意してください。たとえば、この図では、SCN 1500はインカネーション1または2での時点を示すことが可能です。

SCNは、FLASHBACK DATABASE、RECOVER... UNTILなどのRecovery Managerコマンドで使用する場合、デフォルトで、兄弟インカネーションではなく現行のインカネーション・パスを示すとみなされます。ただし、RESET DATABASE TO INCARNATIONコマンドを使用すると、SCNが別のインカネーションの範囲にあると解釈されます。たとえば、Point-in-Timeリカバリで、次のコマンドを使用するとします。

RMAN> RECOVER DATABASE TO SCN 1500;

図7-1に示すデータベースで使用すると、デフォルトで、SCN 1500はインカネーション2を示します。次の一連のコマンドを実行するとします。

RMAN> RESET DATABASE INCARNATION TO 1;
RMAN> RECOVER DATABASE TO SCN 1500;

SCN 1500は、SCNが1500であったときのインカネーション1での時点を示します。

データベース・インカネーションと孤立したバックアップ

データベースが複数のインカネーションを持つ場合、一部のバックアップは孤立する可能性があります。孤立したバックアップとは、現行のインカネーションの祖先ではないデータベースのインカネーションで作成されたバックアップです。

「Point-in-Timeリカバリおよびデータベース・インカネーションの概要」に示す例のデータベースを使用して、次の表に、孤立したバックアップを示します。孤立したバックアップは、どのインカネーションが現行のインカネーションかによって異なります。

現行のインカネーション	使用可能な（孤立していない）バックアップ	孤立したバックアップ
インカネーション1	インカネーション1のすべてのバックアップ	インカネーション2および3のすべてのバックアップ
インカネーション2	SCN 1000以前のインカネーション1のすべてのバックアップ インカネーション2のすべてのバックアップ	SCN 1000より後のインカネーション1のバックアップ インカネーション3のすべてのバックアップ
インカネーション3	SCN 1000以前のインカネーション1のすべてのバックアップ SCN 2000以前のインカネーション2のすべてのバックアップ インカネーション3のすべてのバックアップ	SCN 1000より後のインカネーション1のすべてのバックアップ SCN 2000より後のインカネーション2のすべてのバックアップ

孤立したバックアップの使用

現行のインカネーション・パス以外の時点にデータベースをリストアする場合、Recovery Managerで孤立したバックアップを使用できます。Recovery Managerは、OPEN RESETLOGS操作が実行された場合でも、最も古いバックアップからリカバリする時点までのアーカイブ・ログが連続して存在していれば、直接の祖先であるインカネーションからバックアップをリストアして、現在の時点までリカバリできます。また、Recovery Managerでは、バックアップに示されている変更が取り消されたことがないインカネーションから制御ファイルをリストアする場合、孤立したバックアップを使用してリストアおよびリカバリを実行できます。

データベースのPoint-in-Timeリカバリの準備

DBPITRの準備として、次の手順を実行します。

• リカバリを終了する必要がある目標時点、SCN、リストア・ポイントまたはログ順序番号を決定します。Oracle Flashback Query、Oracle Flashback Version QueryおよびOracle Flashback Transaction Query機能は、いつ論理的な破損が発生したかを識別するのに役立ちます。

  また、alert.logで、リカバリが必要なイベントの時間を決定するのに役立つ情報を確認できます。

  または、ターゲットSCNを含むログ順序番号を設定し、このログまでリカバリすることもできます。たとえば、アーカイブ済のログを表示するには、V$LOG_HISTORYを問い合せます。

  RECID      STAMP      THREAD#    SEQUENCE#  FIRST_CHAN FIRST_TIM NEXT_CHANG
  ---------- ---------- ---------- ---------- ---------- --------- ----------
           1  344890611          1          1      20037 24-SEP-04    20043
           2  344890615          1          2      20043 24-SEP-04      20045
           3  344890618          1          3      20045 24-SEP-04      20046
  
  

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

• ターゲットSCNのかわりに目標時点を指定する場合、Recovery Managerを起動する前に時刻書式の環境変数が適切に設定されていることを確認します。グローバリゼーション・サポート設定の例を次に示します。

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

現行のインカネーション内でのPoint-in-Timeリカバリ

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

DBPITRに必要な手順を次に示します。

1. Recovery Managerをターゲット・データベースおよび（必要に応じて）リカバリ・カタログ・データベースに接続します。データベースをMOUNTモードにします。

   SHUTDOWN IMMEDIATE;
   STARTUP MOUNT;
   
   

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

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

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

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

   RUN
   { 
       SET UNTIL SCN 1000;    
     # Alternatives:
     # SET UNTIL TIME 'Nov 15 2004 09:00:00';
     # SET UNTIL SEQUENCE 9923;  
     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が誤っている可能性があります。このような場合、不要な変更をさらに調査し、新しいターゲットSCNを決定して、DBPITRの処理を繰り返します。

データベースのPoint-in-Timeリカバリでの目標時点の指定

前述の例に示したように、SET UNTIL文では、SCNのかわりに時刻書式を使用できます。ただし、SET UNTIL TIMEを使用して、Point-in-Timeリカバリの目標時点を指定する場合は、指定できる時点が現行のインカネーションに含まれていない場合があることに注意してください。目標時点では、データベースが祖先インカネーションまたは兄弟インカネーションに存在する場合があります。 目標時点が現行のインカネーションにない場合、祖先インカネーションに対するDBPITRの詳細は「祖先インカネーションまでのPoint-in-Timeリカバリ」を、現行のインカネーションの祖先ではないインカネーションに対するDBPITRの詳細は『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』を参照してください。

データベースのPoint-in-Timeリカバリ後に実行可能な操作

DBPITRが正常に終了した後、次のいずれかの操作を実行できます。

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

• データベースを読取り/書込みでオープンして、ターゲットSCNより後に実行されたすべての変更を取り消します。この場合、次に示すとおり、RESETLOGSオプションを指定してデータベースをオープンする必要があります。

  RMAN> ALTER DATABASE OPEN RESETLOGS;
  
  

  現行のオンラインREDOログがアーカイブされ、ログ順序番号が1にリセットされ、オンラインREDOログに新しいタイムスタンプおよびSCNが設定されます。新しいログ順序番号およびインカネーションが設定されたREDOログ・ファイルを識別することによって、不要なアーカイブREDOログが適用されることによるデータ・ファイルの破損を回避します。

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

祖先インカネーションまでのPoint-in-Timeリカバリ

現行のインカネーション内のDBPITRと祖先インカネーションのSCNまでのDBPITRの主な違いは、データベースのインカネーションをターゲットSCNでの現行のインカネーションに再設定する必要があり、またターゲットSCNが含まれるインカネーションの制御ファイルをリストアする必要があることです。

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

• リカバリ・カタログでRecovery Managerを実行しています。

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

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

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

古いインカネーションまでのPoint-in-Timeリカバリを実行するには、次の手順を実行します。

1. 10月2日のバックアップの時点での現行のインカネーションを確認します。LISTINCARNATIONを使用して、目標時点での現行のインカネーションの主キーを取得します。

   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-04
   1       582       TRGT      1224038686  CURRENT    59727        10-OCT-04
   
   

   Reset SCNおよびReset Time列で現行のインカネーションを識別し、Inc Key列でインカネーション・キーを確認します。この例では、インカネーション・キーの値は2です。

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

   STARTUP FORCE NOMOUNT
   
   

3. trgtを10月2日のバックアップの時点での現行のインカネーションに再設定します。Inc Key列の値を使用して、インカネーションを識別します。

   # reset database to old incarnation
   RESET DATABASE TO INCARNATION 2;
   
   

4. RUNコマンドで次の操作を実行して、データベースをリストアおよびカバリします。
   • リカバリの終了時刻をデータが消失する直前の時刻に設定します。

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

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

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

   この場合に必要なすべての手順の例を次に示します。

   RUN
   {
     # set target time for all operations in the RUN block
     SET UNTIL TIME 'Oct 8 2004 07:55:00'; 
     RESTORE CONTROLFILE ;
   # without recovery catalog, use RESTORE CONTROLFILE FROM AUTOBACKUP
     ALTER DATABASE MOUNT; 
     RESTORE DATABASE;
     RECOVER DATABASE;
   }
   
   

ALTER DATABASE OPEN RESETLOGS;