4 ロジカル・スタンバイ・データベースの作成

この章では、ロジカル・スタンバイ・データベースを作成する手順について説明します。この章は、次の主な項目で構成されています。

• ロジカル・スタンバイ・データベースの作成要件

• ロジカル・スタンバイ・データベースの作成手順

• 作成後の手順

  関連項目 サーバー・パラメータ・ファイルの作成方法および使用方法は、『Oracle Database管理者ガイド』を参照してください。 グラフィカル・ユーザー・インタフェースを使用してロジカル・スタンバイ・データベースを自動的に作成する方法は、『Oracle Data Guard Broker』およびOracle Enterprise Managerのオンライン・ヘルプを参照してください。

4.1 ロジカル・スタンバイ・データベースの作成要件

ロジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを最初に確認する必要があります。表4-1は、ロジカル・スタンバイ・データベースを作成するための準備としてプライマリ・データベースで実行するタスクのチェックリストです。

表4-1    ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備 

参照先	タスク
4.1.1項	表のデータ型および記憶域属性のサポートの判別
4.1.2項	プライマリ・データベース内の表の行が一意に識別できることの確認

ロジカル・スタンバイ・データベースでは、スタンバイREDOログ（SRL）をプライマリ・データベースから受信したREDOに使用しますが、スタンバイ・データベースに変更を適用するため、オンラインREDOログ（ORL）にも書き込みます。そのため、ロジカル・スタンバイ・データベースには、SRLおよびORLを同時にアーカイブするために追加のARCnプロセスが必要になることがあります。さらに、ORLのアーカイブはSRLのアーカイブに優先するため、ワークロードが非常に高いときは、ロジカル・スタンバイにより多くのSRLが必要になる可能性があります。

4.1.1 表のデータ型および記憶域属性のサポートの判別

ロジカル・スタンバイ・データベースを設定する前に、ロジカル・スタンバイ・データベースが、プライマリ・データベースのデータ型と表を保持できることを確認する必要があります。データ型および記憶域タイプに関する考慮事項の詳細リストは、付録Cを参照してください。

4.1.2 プライマリ・データベース内の表の行が一意に識別できることの確認

ロジカル・スタンバイ・データベースがプライマリ・データベースのバックアップ・コピーから作成されていても、ロジカル・スタンバイ・データベースの物理的な構成は、プライマリ・データベースの構成とは異なります。そのため、プライマリ・データベースによって生成されたREDOレコードに含まれているROWIDは、ロジカル・スタンバイ・データベース内の対応する行を識別するためには使用できません。

Oracleでは、ロジカル・スタンバイ・データベース内の変更された行を論理的に識別するために、主キーまたは一意制約/索引サプリメンタル・ロギングを使用します。また、データベース全体の主キーおよび一意制約/索引サプリメンタル・ロギングが使用可能になると、各UPDATE文により、ロジカル・スタンバイ・データベース内の変更された行を一意に識別するために、REDOログに必要な列の値が書き込まれます。

• 表に主キーが定義されている場合、その主キーが、変更された行を識別するためにUPDATE文の一部として変更された列とともにログに記録されます。

• 主キーがない場合は、一番短く、NULL値が許容されていない一意制約/索引が、変更された行を識別するためにUPDATE文の一部として変更された列とともにログに記録されます。

• 主キーもNULL値が許容されていない一意制約/索引もない場合、バインドされているサイズのすべての列が、変更された行を識別するためにUPDATE文の一部としてログに記録されます。つまり、LONG、LOB、LONG RAW、オブジェクト型およびコレクション以外のすべての列が、ログに記録されます。

• ファンクション索引は、一意として宣言されている場合でも、変更された行を一意に識別するためには使用できません。しかし、ロジカル・スタンバイ・データベースでは、変更された行を一意に識別できるかぎり、ファンクション索引が定義された表をレプリケーションできます。

SQL Applyで、REDOデータの更新をロジカル・スタンバイ・データベースに効率的に適用できるように、適切で可能な場合には、必ずプライマリ・データベースの表に主キーまたはNULL値が許容されていない一意索引を追加することをお薦めします。

ロジカル・スタンバイ・データベース内のレプリケートされている各表の行をSQL Applyによって一意に識別できるかどうかを確認するには、次の手順を実行します。

手順1    プライマリ・データベース内の一意ロジカル識別子のない表を検索する

SQL Applyで一意に識別できない可能性がある表のリストを表示するには、DBA_LOGSTDBY_NOT_UNIQUEビューを問い合せます。次に例を示します。

SQL> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE
  2> WHERE (OWNER, TABLE_NAME) NOT IN 
  3> (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) 
  4> AND BAD_COLUMN = 'Y'

手順2    無効化されたRELY主キー制約を追加する

アプリケーションで、表内の行が一意であることが保証される場合は、表に無効化されたRELY主キー制約を作成できます。これによって、プライマリ・データベースでの主キーのメンテナンスに関するオーバーヘッドを回避できます。

無効化されたRELY制約をプライマリ・データベース表に作成するには、RELY DISABLE句を指定してALTER TABLE文を使用します。次の例では、無効化されたRELY制約がmytabという表に作成されます。各行は、id列とname列を使用して一意に識別されます。

SQL> ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;

RELY制約を指定すると、システムでは行が一意であると仮定されます。システムには情報に依存するように指示を出しますが、表が変更されるたびに検証は行わないため、表内の各行を一意に識別するRELY制約が無効化されている場合は、十分に注意して列を選択する必要があります。このような一意性が存在しない場合、SQL Applyによる表のメンテナンスが正しく行われません。

SQL Applyのパフォーマンスを改善するには、ロジカル・スタンバイ・データベースで行を識別するために一意制約/索引を列に追加します。追加できない場合は、SQL Applyによって表上でUPDATEまたはDELETE文を実行中に、全表スキャンが実行されます。

関連項目 DBA_LOGSTDBY_NOT_UNIQUEビューの詳細は、『Oracle Databaseリファレンス』を参照してください。 ALTER TABLE文の構文およびRELY制約の作成の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 RELY制約およびロジカル・スタンバイ・データベース上でパフォーマンスを向上させるために行うことができる処理の詳細は、10.7.1項「主キーRELY制約の作成」を参照してください。

4.2 ロジカル・スタンバイ・データベースの作成手順

この項では、ロジカル・スタンバイ・データベースの作成で実行するタスクについて説明します。

表4-2は、ロジカル・スタンバイ・データベースの作成で実行するタスクのチェックリストで、各タスクを実行するデータベースを指定します。各タスクを詳細に説明している参照先の項も記載されています。

表4-2    ロジカル・スタンバイ・データベースの作成 

参照先	タスク	データベース
4.2.1項	フィジカル・スタンバイ・データベースの作成	プライマリ
4.2.2項	フィジカル・スタンバイ・データベースでのREDO Applyの停止	スタンバイ
4.2.3項	ロジカル・スタンバイ・データベースをサポートするためのプライマリ・データベースの準備	プライマリ
4.2.4項	ロジカル・スタンバイ・データベースへの推移	スタンバイ
4.2.5項	ロジカル・スタンバイ・データベースのオープン	スタンバイ
4.2.6項	ロジカル・スタンバイ・データベースが正しく実行されているかどうかの確認	スタンバイ

4.2.1 フィジカル・スタンバイ・データベースの作成

ロジカル・スタンバイ・データベースを作成するには、次のように最初にフィジカル・スタンバイ・データベースを作成してから、ロジカル・スタンバイ・データベースへと推移させます。第3章「フィジカル・スタンバイ・データベースの作成」の指示に従ってフィジカル・スタンバイ・データベースを作成します。

4.2.2 フィジカル・スタンバイ・データベースでのREDO Applyの停止

ロジカル・スタンバイ・データベースに変換する前に、実行時間に関係なく、新規フィジカル・スタンバイ・データベースでREDO Applyを実行できます。ただし、ロジカル・スタンバイ・データベースに変換する前に、フィジカル・スタンバイ・データベースでREDO Applyを停止する必要があります。REDO Applyの停止は、LogMinerディクショナリを含むREDOの後に変更が適用されることを避けるために必要です（4.2.3.2項「REDOデータでのディクショナリの構築」を参照）。

REDO Applyを停止するには、フィジカル・スタンバイ・データベースで次の文を発行します。データベースが複数のインスタンスから構成されるOracle RACデータベースの場合、この文を発行する前に、1つを残してすべてのOracle RACインスタンスを停止する必要があります。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

4.2.3 ロジカル・スタンバイ・データベースをサポートするためのプライマリ・データベースの準備

この項は、次の項目で構成されています。

• ロールの推移のためのプライマリ・データベースの準備

• REDOデータでのディクショナリの構築

4.2.3.1 ロールの推移のためのプライマリ・データベースの準備

3.1.4項「プライマリ・データベースの初期化パラメータの設定」では、プライマリ・データベースがフィジカル・スタンバイ・ロールに推移する場合に有効になるように、複数のスタンバイ・ロールの初期化パラメータを設定しました。

注意 この手順は、スイッチオーバーを実行する予定の場合のみ必要です。

プライマリ・データベースをロジカル・スタンバイ・ロールに推移させる場合は、ロールの推移後にパラメータを変更しなくてもよいように、例4-1に太字で示すパラメータを変更する必要もあります。

• 元のLOG_ARCHIVE_DEST_1宛先のVALID_FOR属性を、スタンバイREDOログからではなく、オンラインREDOログからのみREDOデータをアーカイブするように変更します。

• LOG_ARCHIVE_DEST_3宛先をプライマリ・データベースに含めます。このパラメータは、プライマリ・データベースがロジカル・スタンバイ・ロールに推移したときにのみ有効になります。

  例4-1    プライマリ・データベース: ロジカル・スタンバイ・ロールの初期化パラメータ

  LOG_ARCHIVE_DEST_1=
   'LOCATION=/arch1/chicago/ 
    VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
    DB_UNIQUE_NAME=chicago'
  LOG_ARCHIVE_DEST_3=
   'LOCATION=/arch2/chicago/
    VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) 
    DB_UNIQUE_NAME=chicago'
  LOG_ARCHIVE_DEST_STATE_3=ENABLE
  
  

これらの初期化パラメータを動的に設定するには、SQL ALTER SYSTEM SET文を使用し、変更が即時に有効になってデータベースを停止して再起動した後も存続するようにSCOPE=BOTH句を指定します。

次の表に、例4-1に示した変更後の初期化パラメータで定義されるアーカイブ・プロセスを示します。

	シカゴのデータベースがプライマリ・ロールで稼働している場合	シカゴのデータベースがロジカル・スタンバイ・ロールで稼働している場合
LOG_ARCHIVE_DEST_1	/arch1/chicago/内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからプライマリ・データベースによって生成されたREDOデータをアーカイブするよう指示。	/arch1/chicago/内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからロジカル・スタンバイ・データベースによって生成されたREDOデータをアーカイブするよう指示。
LOG_ARCHIVE_DEST_3	無視。LOG_ARCHIVE_DEST_3は、chicagoがスタンバイ・ロールで稼働している場合にのみ有効。	/arch2/chicago/内のローカル・アーカイブREDOログ・ファイルにスタンバイREDOログ・ファイルからのREDOデータをアーカイブするよう指示。

4.2.3.2 REDOデータでのディクショナリの構築

LogMinerディクショナリは、SQL ApplyのLogMinerコンポーネントによってREDOでの変更が適切に解釈できるように、REDOデータに構築される必要があります。LogMinerディクショナリの構築の一部として、主キーおよび一意制約/索引列を記録するサプリメンタル・ロギングが自動的に設定されます。サプリメンタル・ロギング情報により、各更新に、文によって変更された各行を論理的に識別するための十分な情報が含まれていることが保証されます。

LogMinerディクショナリを構築するには、次の文を発行します。

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

DBMS_LOGSTDBY.BUILDプロシージャでは、既存のトランザクションがすべて完了するのを待機します。プライマリ・データベースで長時間実行されているトランザクションは、このコマンドの適時性に影響を与えます。

関連項目 『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』のDBMS_LOGSTDBY.BUILD PL/SQLパッケージに関する項 『Oracle Databaseリファレンス』のUNDO_RETENTION初期化パラメータに関する項

4.2.4 ロジカル・スタンバイ・データベースへの推移

この項では、ロジカル・スタンバイ・データベースに推移するために、フィジカル・スタンバイ・データベースを準備する方法について説明します。この章は、次の項目で構成されています。

• ロジカル・スタンバイ・データベースへの変換

• ロジカル・スタンバイ・データベース用の初期化パラメータの調整

4.2.4.1 ロジカル・スタンバイ・データベースへの変換

REDOログには、フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換するために必要な情報が含まれています。

注意 Oracle RACフィジカル・スタンバイ・データベースがある場合、1つのインスタンス以外はすべて停止して、CLUSTER_DATABASEをFALSEに設定し、次のようにしてスタンバイ・データベースをMOUNT EXCLUSIVEモードで単一インスタンスとして起動します。 SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE; SQL> SHUTDOWN ABORT; SQL> STARTUP MOUNT EXCLUSIVE;

ロジカル・スタンバイ・データベースへの変換準備が完了するまでREDOデータをフィジカル・スタンバイ・データベースに適用し続けるには、次のSQL文を発行します。

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name;

db_nameには、新しいロジカル・スタンバイ・データベースを識別するデータベース名を指定します。この文の発行時にサーバー・パラメータ・ファイル（spfile）を使用している場合、データベースは、新しいロジカル・スタンバイ・データベースに関する適切な情報でこのファイルを更新します。spfileを使用していない場合は、データベースの停止後にDB_NAMEパラメータの名前を設定するよう求めるメッセージが発行されます。

注意 フィジカル・スタンバイ・データベースでOracleソフトウェアのローリング・アップグレードを実行する状況で、ロジカル・スタンバイ・データベースを作成するとき、次のコマンドをかわりに発行する必要があります。 SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY; KEEP IDENTITY句を指定して作成されたロジカル・スタンバイ・データベースは、プライマリ・データベースと同じDB_NAMEおよびDBIDを保持します。このようなロジカル・スタンバイ・データベースは、1回のスイッチオーバー操作にしか使用できないため、フィジカル・スタンバイ・データベースでローリング・アップグレードを実行する状況でのみ作成する必要があります。 KEEP IDENTITY句は、アップグレードするデータベースでOracle Databaseリリース11.1以降が稼働している場合にのみ、使用できます。

この文では、ログ・ファイル内にLogMinerディクショナリが見つかるまで、REDOデータを適用しながら待機します。4.2.3.2項「REDOデータでのディクショナリの構築」で生成されたREDOがスタンバイ・データベースに推移されるのにかかる時間と、適用する必要のあるREDOデータの量にもよりますが、この作業には数分かかります。プライマリ・データベースでディクショナリ構築が正常に実行されるまで、このコマンドは完了しません。SQL文を取り消すには、別のSQLセッションからALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL文を発行します。

注意 旧リリースでは、ロジカル・スタンバイ・データベースをオープンする前に新しいパスワード・ファイルを作成する必要がありました。現在は、その必要はありません。ロジカル・スタンバイ・データベースに新しいパスワード・ファイルを作成すると、REDO転送サービスが正常に機能しなくなります。

4.2.4.2 ロジカル・スタンバイ・データベース用の初期化パラメータの調整

注意 Oracle RACフィジカル・スタンバイ・データベースで開始した場合、次のようにCLUSTER_DATABASEの設定をTRUEに戻します。 SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=SPFILE;

ロジカル・スタンバイ・データベースで、インスタンスを停止し、STARTUP MOUNT文を発行してデータベースを起動およびマウントします。データベースをオープンしないでください。後続の作成プロセスまで、データベースはユーザー・アクセスに対してクローズの状態のままにしておく必要があります。次に例を示します。

SQL> SHUTDOWN;
SQL> STARTUP MOUNT;

LOG_ARCHIVE_DEST_nパラメータを変更する必要があります。これは、フィジカル・スタンバイ・データベースとは異なり、ロジカル・スタンバイ・データベースはREDOデータを生成するオープン・データベースであり、複数のログ・ファイル（オンラインREDOログ・ファイル、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイル）があるためです。次のものに対し、別々のローカル宛先を指定することをお薦めします。

• ロジカル・スタンバイ・データベースで生成されたREDOデータを格納するアーカイブREDOログ・ファイル。例4-2では、LOG_ARCHIVE_DEST_1=LOCATION=/arch1/boston宛先として構成されています。

• プライマリ・データベースから受信したREDOデータを格納するアーカイブREDOログ・ファイル。例4-2では、LOG_ARCHIVE_DEST_3=LOCATION=/arch2/boston宛先として構成されています。

例4-2に、ロジカル・スタンバイ・データベース用に変更された初期化パラメータを示します。各パラメータは、ボストンのロジカル・スタンバイ・データベースがプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで実行されている場合に有効です。

例4-2    ロジカル・スタンバイ・データベース用の初期化パラメータの変更

LOG_ARCHIVE_DEST_1=
  'LOCATION=/arch1/boston/
   VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
   DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2=
  'SERVICE=chicago ASYNC
   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
   DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_3=
  'LOCATION=/arch2/boston/
   VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
   DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE

注意 データベースの互換性を11.1に設定した場合、フラッシュ・リカバリ領域を使用してリモート・アーカイブ・ログを格納することもできます。そのためには、次のパラメータを設定します（すでにDB_RECOVERY_FILE_DESTおよびDB_RECOVERY_FILE_DEST_SIZEは適切に設定されているとします）。 LOG_ARCHIVE_DEST_1= 'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ONLINE_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_3= 'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE) DB_UNIQUE_NAME=boston'

次の表に、例4-2に示した初期化パラメータで定義されるアーカイブ・プロセスを示します。

	ボストンのデータベースがプライマリ・ロールで稼働している場合	ボストンのデータベースがロジカル・スタンバイ・ロールで稼働している場合
LOG_ARCHIVE_DEST_1	/arch1/boston/内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからプライマリ・データベースによって生成されたREDOデータをアーカイブするよう指示。	/arch1/boston/内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからロジカル・スタンバイ・データベースによって生成されたREDOデータをアーカイブするよう指示。
LOG_ARCHIVE_DEST_2	リモート・ロジカル・スタンバイ・データベースchicagoにREDOデータを転送するよう指示。	無視。LOG_ARCHIVE_DEST_2は、bostonがプライマリ・ロールで稼働している場合にのみ有効。
LOG_ARCHIVE_DEST_3	無視。LOG_ARCHIVE_DEST_3は、bostonがスタンバイ・ロールで稼働している場合にのみ有効。	/arch2/boston/内のローカル・アーカイブREDOログ・ファイルにプライマリ・データベースから受信したREDOデータをアーカイブするよう指示。

注意 DB_FILE_NAME_CONVERT初期化パラメータは、フィジカル・スタンバイ・データベースがロジカル・スタンバイ・データベースに変換された後は考慮されません。必要な場合は、スキップ・ハンドラを登録し、プライマリ・データベースのデータファイルのパス名をスタンバイ・データファイルのパス名に変換することで、実行対象のかわりとなるDDL文字列をSQL Applyに提供します。SKIPプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』の DBMS_LOGSTDBYパッケージに関する項を参照してください。

4.2.5 ロジカル・スタンバイ・データベースのオープン

新規ロジカル・スタンバイ・データベースをオープンするには、次の文を発行し、RESETLOGSオプションを使用してオープンする必要があります。

SQL> ALTER DATABASE OPEN RESETLOGS;

注意 Oracle RACフィジカル・スタンバイ・データベースで開始した場合、その他のすべてのスタンバイ・インスタンスをこの時点で開始できます。

注意 ロジカル・スタンバイ・データベースをプライマリ・データベースと同じコンピュータ・システム上に配置している場合、SQL Applyを初めて開始する前に次のSQL文を発行し、SQL Applyがプライマリ・データベースで実行されるファイル操作をスキップするようにする必要があります。この文の発行が必要な理由は、SQL Applyはプライマリ・データベースと同じディレクトリ構造にアクセスできるので、特定のファイル固有の操作を再実行しようとした場合に、プライマリ・データベースに属するデータファイルが破損する可能性があるためです。 SQL> EXECUTE DBMS_LOGSTDBY.SKIP('ALTER TABLESPACE'); フィジカル・データベースをプライマリ・データベースと同じシステム上に配置する際に設定したDB_FILENAME_CONVERTパラメータは、SQL Applyでは無視されます。DBMS_LOGSTDBY.SKIPおよびロジカル・スタンバイ・データベースの下での同等の動作の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

データベースがオープンされるのはこれが初回であるため、データベースのグローバル名は、新しいDB_NAME初期化パラメータと一致するように自動的に調整されます。

次の文を発行して、ロジカル・スタンバイ・データベースに対するREDOデータの適用を開始します。次に例を示します。

SQL>  ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

4.2.6 ロジカル・スタンバイ・データベースが正しく実行されているかどうかの確認

ロジカル・スタンバイ・データベースが適切に実行されていることを検証するには、次の項を参照してください。

• 第6章「REDO転送サービス」

• 第10章「ロジカル・スタンバイ・データベースの管理」

4.3 作成後の手順

この時点で、ロジカル・スタンバイ・データベースが実行中であり、最大パフォーマンス・レベルのデータ保護を提供できます。次のリストに、ロジカル・スタンバイ・データベースに対して実行できるその他の準備について説明します。

• データ保護モードのアップグレード

  Data Guard構成は、最初は最大パフォーマンス・モード（デフォルト）で設定されます。

• フラッシュバック・データベースの有効化

  フラッシュバック・データベースにより、フェイルオーバー後のプライマリ・データベースの再作成の必要がなくなります。フラッシュバック・データベースでは、データファイルをバックアップからリストアしたりREDOデータを広範囲に適用する必要がないため、従来のPoint-in-Timeリカバリよりもはるかに高速でデータベースを過去の最新時点の状態に戻すことができます。フラッシュバック・データベースは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できます。Data Guard環境でのフラッシュバック・データベースの使用例は、13.2項「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」、および13.3項「Open Resetlogs文の発行後のフラッシュバック・データベースの使用」を参照してください。また、フラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。