ヘッダーをスキップ
Oracle® Data Guard概要および管理
11gリリース2 (11.2)
B56302-06
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

16 Data Guardに関連するSQL文

この章では、Data Guard環境のスタンバイ・データベースで操作を実行するときに役立つSQLおよびSQL*Plus文の概要について説明します。この章は、次の項目で構成されています。

この章では、特定のSQL文について、その構文と簡単な概要を示します。ここに記載しているものを含むSQL文の完全な構文と説明は、『Oracle Database SQL言語リファレンス』を参照してください。

ALTER SYSTEM SET文を使用して設定および動的な更新を行うことができる初期化パラメータのリストは、第14章を参照してください。

16.1 ALTER DATABASE文

表16-1で、Data Guardに関連のあるALTER DATABASE文について説明します。

表16-1 Data Guard環境で使用されるALTER DATABASE文

ALTER DATABASE文 説明

ADD [STANDBY] LOGFILE [THREAD integer] [GROUP integer] filespec

指定したスレッドに1つ以上のオンラインREDOログ・ファイル・グループまたはスタンバイREDOログ・ファイル・グループを追加し、スレッドが割り当てられたインスタンスでログ・ファイルを使用できるようにします。

この文の例は、9.3.5項を参照してください。

ADD [STANDBY] LOGFILE MEMBER 'filename' [REUSE] TO logfile-descriptor

既存のオンラインREDOログ・ファイル・グループまたはスタンバイREDOログ・ファイル・グループに新しいメンバーを追加します。

[ADD|DROP] SUPPLEMENTAL LOG DATA {PRIMARY KEY|UNIQUE INDEX} COLUMNS

この文は、ロジカル・スタンバイ・データベース専用です。

ロジカル・スタンバイ・データベースを作成する前に、サプリメンタル・ロギングを使用可能にするために使用します。サプリメンタル・ロギングがロジカル・スタンバイ・データベースに対する変更のソースであるため、このようにする必要があります。完全なサプリメンタル・ロギングを実装するには、この文でPRIMARY KEY COLUMNSまたはUNIQUE INDEX COLUMNSキーワードを指定する必要があります。

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

COMMIT TO SWITCHOVER

次のスイッチオーバーを実行します。

  • カレント・プライマリ・データベースをスタンバイ・データベース・ロールに変更する

  • 1つのスタンバイ・データベースをプライマリ・データベース・ロールに変更する

注意: ロジカル・スタンバイ・データベースでは、ALTER DATABASE COMMIT TO SWITCHOVER文を発行する前に、ALTER DATABASE PREPARE TO SWITCHOVER文を発行し、スイッチオーバーのためにデータベースを準備します。

この文の例は、8.2.1項および8.3.1項を参照してください。この文の完全な構文は、『Oracle Database SQL言語リファレンス』も参照してください。

CONVERT TO [[PHYSICAL|SNAPSHOT] STANDBY] DATABASE

フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに、またはその逆に変換します。

CREATE [PHYSICAL|LOGICAL] STANDBY CONTROLFILE AS 'filename' [REUSE]

フィジカルまたはロジカル・スタンバイ・データベースの維持に使用される制御ファイルを作成します。この文はプライマリ・データベースで発行します。

この文の例は、3.2.2項を参照してください。

DROP [STANDBY] LOGFILE logfile_descriptor

オンラインREDOログ・ファイル・グループまたはスタンバイREDOログ・ファイル・グループのすべてのメンバーを削除します。

この文の例は、9.3.5項を参照してください。

DROP [STANDBY] LOGFILE MEMBER 'filename'

オンラインREDOログ・ファイル・グループまたはスタンバイREDOログ・ファイル・グループの1つ以上のメンバーを削除します。

[NO]FORCE LOGGING

一時表領域および一時セグメントに対する変更を除くデータベースに対するすべての変更を、Oracleデータベースが記録するかどうかを制御します。[NO]FORCE LOGGING句は、スタンバイ・データベース間の一貫性の欠如を防止するために必要です。

この文を発行する場合、プライマリ・データベースを少なくともマウントしておく(また、オープンもできるようにしておく)必要があります。この文の例は、3.1.1項を参照してください。

GUARD

ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスを制御します。可能な値は、ALLSTANDBYおよびNONEです。詳細は、10.2項を参照してください。

MOUNT [STANDBY DATABASE]

スタンバイ・データベースをマウントし、スタンバイ・インスタンスがREDOデータをプライマリ・インスタンスから受信できるようにします。

OPEN

すでに起動され、マウントされたデータベースをオープンします。

  • フィジカル・スタンバイ・データベースは読取り専用モードでオープンされ、ユーザーを読取り専用トランザクションに制限し、REDOデータの生成を防ぎます。

  • ロジカル・スタンバイ・データベースは読取り/書込みモードでオープンされます。

PREPARE TO SWITCHOVER

この文は、ロジカル・スタンバイ・データベース専用です。

スイッチオーバーが実行される前にLogMinerディクショナリを構築することにより、プライマリ・データベースおよびロジカル・スタンバイ・データベースをスイッチオーバー用に準備します。ディクショナリ構築の完了後、ALTER DATABASE COMMIT TO SWITCHOVER文を発行し、プライマリおよびロジカル・スタンバイ・データベースのロールを切り替えます。

この文の例は、8.3.1項を参照してください。この文の完全な構文は、『Oracle Database SQL言語リファレンス』も参照してください。

RECOVER MANAGED STANDBY DATABASE [ { DISCONNECT [FROM SESSION] | USING CURRENT LOGFILE | NODELAY | UNTIL CHANGE integer }...]

この文はフィジカル・スタンバイ・データベースに対するREDO Applyを開始および制御しますRECOVER MANAGED STANDBY DATABASE句は、マウント、オープンまたはクローズされているフィジカル・スタンバイ・データベースで使用できます。例は、3.2.6項および7.3項の手順4を参照してください。

注意: 複数の句およびキーワードが非推奨となり、下位互換性のためにのみサポートされています。これらの句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

RECOVER MANAGED STANDBY DATABASE CANCEL

CANCEL句は、現行のアーカイブREOログ・ファイルの適用後、フィジカル・スタンバイ・データベースへのRedo Applyを取り消します。

注意: 複数の句およびキーワードが非推奨となり、下位互換性のためにのみサポートされています。これらの句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

RECOVER MANAGED STANDBY DATABASE FINISH

FINISH句は、ターゲット・フィジカル・スタンバイ・データベースでフェイルオーバーを開始し、現行のスタンバイREDOログ・ファイルをリカバリします。FINISH句を使用するのは、プライマリ・データベースに障害が発生した場合のみです。この句により、指定の遅延間隔がオーバーライドされます。

例は、8.2.2項の手順4を参照してください。

注意: 複数の句およびキーワードが非推奨となり、下位互換性のためにのみサポートされています。これらの句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

REGISTER [OR REPLACE] [PHYSICAL|LOGICAL] LOGFILE filespec

手動でコピーされたアーカイブREDOログ・ファイルを登録できます。

注意: このコマンドは、対応するアーカイブREDOログ・ファイルを手動でスタンバイ・データベースにコピーした後にのみ発行します。ログ・ファイルのコピー中、あるいはログ・ファイルが存在しないときにこのコマンドを発行すると、後でスタンバイ・データベースにエラーが発生する可能性があります。

RECOVER TO LOGICAL STANDBY new_database_name

適用サービスに対して、データベースをロジカル・スタンバイ・データベースに変換するコマンドを発行するまでは、引き続き変更をフィジカル・スタンバイ・データベースに適用するように指示します。詳細は、4.2.4.1項を参照してください。

RESET DATABASE TO INCARNATION integer

データベースのターゲット・リカバリ・インカネーションを、現在のインカネーションから別のインカネーションにリセットします。

SET STANDBY DATABASE TO MAXIMIZE {PROTECTION|AVAILABILITY|PERFORMANCE}

この句を使用して、Data Guard構成におけるデータの保護レベルを指定します。この句は、マウント済でオープンされていないプライマリ・データベースから指定します。

START LOGICAL STANDBY APPLY INITIAL [scn-value] ] [NEW PRIMARY dblink]

この文はロジカル・スタンバイ・データベース専用です。ロジカル・スタンバイ・データベースに対して、SQL Applyを開始します。この文の例は、7.4.1項を参照してください。

{STOP|ABORT} LOGICAL STANDBY APPLY

この文はロジカル・スタンバイ・データベース専用です。STOP句を使用して、ロジカル・スタンバイ・データベースに対するSQL Applyを整然と停止します。ABORT句を使用するとSQL Applyが突然停止します。この文の例は、8.3.2項を参照してください。

ACTIVATE [PHYSICAL|LOGICAL] STANDBY DATABASE FINISH APPLY]

フェイルオーバーを実行します。スタンバイ・データベースは、マウント後に、この文を使用してアクティブ化する必要があります。

注意: ALTER DATABASE ACTIVATE STANDBY DATABASE文でフェイルオーバーを行うと、データが失われるので使用しないでください。かわりに次のベスト・プラクティスを使用します。

  • フィジカル・スタンバイ・データベースの場合、ALTER DATABASE RECOVER MANAGED STANDBY DATABASE文でFINISHキーワードを使用します。これにより、ロールの推移がすばやく実行されるため、データ消失は防止されるかまたは最小限に抑えられ、他のスタンバイ・データベースが使用できなくなることはありません。

  • ロジカル・スタンバイ・データベースの場合、ALTER DATABASE PREPARE TO SWITCHOVERおよびALTER DATABASE COMMIT TO SWITCHOVER文を使用します。


16.2 ALTER SESSION文

表16-2で、Data Guardに関連のあるALTER SESSION文について説明します。

表16-2 Data Guard環境で使用されるALTER SESSION文

ALTER SESSION文 説明

ALTER SESSION [ENABLE|DISABLE] GUARD

この文は、ロジカル・スタンバイ・データベース専用です。

権限を付与されているユーザーは、この文を使用して、現在のセッションでデータベース・ガードを選択または解除できます。

詳細は、10.5.4項を参照してください。

ALTER SESSION SYNC WITH PRIMARY

この文は、フィジカル・スタンバイ・データベース専用です。

この文は、起動時にフィジカル・スタンバイにより受信されたすべてのREDOデータが適用されるまでブロックすることにより、フィジカル・スタンバイ・データベースをプライマリ・データベースと同期します。

詳細は、9.2.1.3項を参照してください。


16.3 ALTER SYSTEM文

表16-3で、Data Guardに関連のあるALTER SYSTEM文について説明します。

表16-3 Data Guard環境で使用されるALTER SYSTEM文

ALTER SYSTEM文 説明

ALTER SYSTEM FLUSH REDO TO target_db_name [[NO] CONFIRM APPLY]

この文は、REDOデータをすべて、プライマリ・データベースからスタンバイ・データベースにフラッシュし、必要に応じて、フラッシュされたREDOデータがフィジカルまたはロジカル・スタンバイ・データベースに適用されるまで待機します。

この文は、マウントされているが、オープンされていないプライマリ・データベースで発行する必要があります。