10 フィジカルおよびスナップショット・スタンバイ・データベースの管理
この章では、フィジカルおよびスナップショット・スタンバイ・データベースの様々な管理方法について説明します。
次のトピックを参照してください。
Oracle Data Guard Brokerによるフィジカルおよびスナップショット・スタンバイ・データベース管理の簡素化方法を学習するには、『Oracle Data Guard Broker』を参照してください。
10.1 フィジカル・スタンバイ・データベースの起動と停止
この項では、フィジカル・スタンバイ・データベースを起動および停止する方法について説明します。
10.1.1 フィジカル・スタンバイ・データベースの起動
フィジカル・スタンバイ・データベースを起動するには、SQL*Plus STARTUPコマンドを使用します。
SQL*Plus STARTUPコマンドは、引数を指定せずに起動すると、フィジカル・スタンバイ・データベースを読取り専用モードで起動、マウントおよびオープンします。
フィジカル・スタンバイ・データベースは、マウントまたはオープンされると、プライマリ・データベースからREDOデータを受信できます。
REDO Applyについては「REDOデータのフィジカル・スタンバイ・データベースへの適用」および読取り専用モードでのフィジカル・スタンバイ・データベースのオープンについては、「フィジカル・スタンバイ・データベースのオープン」を参照してください。
ノート:
プライマリ・データベースからのREDOデータをまだ受信していないフィジカル・スタンバイ・データベースでREDO Applyを開始すると、ORA-01112メッセージが戻されることがあります。このメッセージは、REDO Applyがメディア・リカバリ用の開始順序番号を判別できないことを示します。このエラーが発生した場合は、スタンバイ・データベースでアーカイブREDOログ・ファイルをプライマリ・データベースから手動で取得して登録するか、またはREDO転送が開始されるまで待機した後、REDO Applyを開始します。
10.2 フィジカル・スタンバイ・データベースのオープン
フィジカル・スタンバイ・データベースは、読取り専用アクセス用にオープンし、問合せをプライマリ・データベースからオフロードするために使用できます。
ノート:
読取り専用モードで開かれたフィジカル・スタンバイ・データベースは、読取り専用モードで開かれたその他のOracleデータベースと同じ制約を受けます。詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle Active Data Guardオプションのライセンスを購入している場合は、フィジカル・スタンバイ・データベースを開いている間はRedo Applyをアクティブにすることができます。それにより、問合せによって、プライマリ・データベースからのものと同じ結果が得られます。この機能は、リアルタイム問合せ機能と呼ばれます。詳細は、「リアルタイム問合せ」を参照してください。
Oracle Active Data Guardオプションのライセンスを未購入の場合、REDO Applyがアクティブである間は、フィジカル・スタンバイ・データベースをオープンできません。そのため、フィジカル・スタンバイ・データベース・インスタンスのオープン時またはREDO Applyの開始時には、次のルールに従う必要があります。
-
REDO Applyは、フィジカル・スタンバイ・データベース・インスタンスをオープンする前に停止する必要がある。
-
1つ以上のフィジカル・スタンバイ・インスタンスがオープンしている場合、REDO Applyを開始する前にこれらのインスタンスを停止する、またはMOUNT状態を再開する必要がある。
関連項目:
-
Oracle Active Data Guardの詳細は、『Oracle Databaseライセンス情報』を参照してください。
10.2.1 リアルタイム問合せ
Oracle Active Data Guardオプションのリアルタイム問合せ機能を使用するためには、COMPATIBLEデータベース初期化パラメータを11.0以上に設定する必要があります。
フィジカル・スタンバイ・データベース・インスタンスは、そのデータベースのマウント済インスタンスでREDO Applyがアクティブである場合、オープンできません。次のSQL文を使用してREDO Applyを停止し、スタンバイ・インスタンスを読取り専用でオープンしてREDO Applyを再開します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> ALTER DATABASE OPEN; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
ノート:
REDO Applyがオープン・インスタンスでアクティブになっている場合は、REDO Applyを停止せずにその他のインスタンスをオープンすることができます。
REDO Applyは、そのデータベースのいずれかのインスタンスがオープンされている場合、マウント済フィジカル・スタンバイ・インスタンスでは開始できません。REDO Applyを開始する予定のインスタンスは、開始前にオープンしておく必要があります。
例: スタンバイのオープン・モードを調べるためのV$DATABASEの問合せ
この例は、フィジカル・スタンバイがリアルタイム問合せモードで開かれているときのV$DATABASE.OPEN_MODE列の値の変化を示します。
10.2.1.1 リアルタイム問合せ環境での適用ラグの監視
リアルタイム問合せを使用して、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せをオフロードしている場合、適用ラグを監視して許容範囲内かどうかを確認できます。
現行の適用ラグとは、最後に適用された変更がスタンバイで表示可能になってから、同じ変更がプライマリで最初に表示可能になるまでに経過した時間です。このメトリックは秒単位で計算されます。
適用ラグを取得するには、V$DATAGUARD_STATSビューを問い合せます。次に例を示します。
SQL> SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS -
> WHERE name like 'apply lag';
NAME VALUE DATUM_TIME TIME_COMPUTED
--------- ------------- ------------------- -------------------
apply lag +00 00:00:00 05/27/2009 08:54:16 05/27/2009 08:54:17
apply lagメトリックの計算には、プライマリ・データベースから定期的に受信されるデータが使用されます。DATUM_TIME列には、このデータがスタンバイ・データベースにより最後に受信されたときのタイムスタンプが格納されます。TIME_COMPUTED列には、apply lagメトリックが計算されたときに取得されたタイムスタンプが格納されます。これらの列の値の差は30秒未満である必要があります。差が30秒以上である場合、apply lagメトリックが正確ではない可能性があります。
スタンバイ・インスタンスが最後に起動されてからの適用ラグ値の履歴を示すヒストグラムを取得するには、V$STANDBY_EVENT_HISTOGRAMビューを問い合せます。次に例を示します。
SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM WHERE NAME = 'apply lag' - > AND COUNT > 0; NAME TIME UNIT COUNT LAST_TIME_UPDATED --------- --------- -------- ----------- ------------------------ apply lag 0 seconds 79681 06/18/2009 10:05:00 apply lag 1 seconds 1006 06/18/2009 10:03:56 apply lag 2 seconds 96 06/18/2009 09:51:06 apply lag 3 seconds 4 06/18/2009 04:12:32 apply lag 4 seconds 1 06/17/2009 11:43:51 apply lag 5 seconds 1 06/17/2009 11:43:52 6 rows selected
ある期間にわたってapply lagを評価するには、その期間の開始時のV$STANDBY_EVENT_HISTOGRAMのスナップショットを取得し、その期間の終了時に取得したスナップショットと比較します。
10.2.1.2 リアルタイム問合せ環境での適用ラグ許容差の構成
リアルタイム問合せモードのフィジカル・スタンバイ・データベースへの非管理ユーザーからの問合せで、新しいSTANDBY_MAX_DATA_DELAYセッション・パラメータを使用して特定のセッションの適用ラグの許容値を指定できます。
この機能によって、スタンバイ・データベースが許容できないほど失効したかどうかを検出できるため、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せを安全に移動できます。
STANDBY_MAX_DATA_DELAYがデフォルト値NONEに設定されている場合、フィジカル・スタンバイ・データベースに発行された問合せは、そのデータベースの適用ラグに関係なく実行されます。
STANDBY_MAX_DATA_DELAYを0 (ゼロ)以外の値に設定すると、フィジカル・スタンバイ・データベースに発行された問合せは、適用ラグがSTANDBY_MAX_DATA_DELAY以下の場合のみ実行されます。それ以外の場合は、ORA-3172エラーが返され、適用ラグが大きすぎることがクライアントに警告されます。
STANDBY_MAX_DATA_DELAYを0に設定すると、フィジカル・スタンバイ・データベースに発行される問合せは、スタンバイ・データベースがプライマリ・データベースから遅れていないかぎり、その問合せがプライマリ・データベースに発行された場合とまったく同じ結果を返すことが保証されます。遅れている場合、ORA-3172エラーが返されます。
ALTER SESSION SQL文を使用してSTANDBY_MAX_DATA_DELAYを設定します。次に例を示します。
SQL> ALTER SESSION SET STANDBY_MAX_DATA_DELAY=2
10.2.1.3 リアルタイム問合せ環境でのREDO Applyの強制同期
プライマリ・データベースから受信したすべてのREDOデータがフィジカル・スタンバイ・データベースに適用されたことを確認するには、SQL ALTER SESSION文を使用します。
次のSQL文を発行します。
SQL> ALTER SESSION SYNC WITH PRIMARY;
このコマンドが発行された時点でスタンバイ・データベースが受け取ったすべてのREDOデータが、フィジカル・スタンバイ・データベースに適用されるまで、この文によってその他の処理がブロックされます。スタンバイ・データベースのREDO転送ステータスがSYNCHRONIZEDでない場合、またはREDO Applyがアクティブでない場合は、ORA-3173エラーがすぐに返され、同期は行われません。
特定のケースでREDO Apply同期を確実に行うためには、SYS_CONTEXT('USERENV','DATABASE_ROLE')ファンクションを使用して、スタンバイ専用トリガー(プライマリで有効化されるが、スタンバイで実行される場合のみ特定の処理を実行するトリガー)を作成します。たとえば、特定のユーザー接続に対してログオン時にALTER SESSION SYNC WITH PRIMARY文を実行する次のトリガーを作成することができます。
CREATE TRIGGER adg_logon_sync_trigger
AFTER LOGON ON user.schema
begin
if (SYS_CONTEXT('USERENV', 'DATABASE_ROLE') IN ('PHYSICAL STANDBY')) then
execute immediate 'alter session sync with primary';
end if;
end;10.2.1.4 リアルタイム問合せの制限
このリストでは、リアルタイム問合せモードに関連する制限事項について説明しています。
-
これまでに説明した、適用ラグの制御およびREDO Apply同期のメカニズムでは、クライアントが接続していることと、リアルタイム問合せモードのフィジカル・スタンバイ・データベースに問合せを発行することが必要です。
-
STANDBY_MAX_DATA_DELAYが0に設定されている場合、またはALTER SESSION SYNC WITH PRIMARYSQL文が使用される場合には、この他に次の制限も適用されます。-
スタンバイ・データベースがSYNC転送でREDOデータを受け取ります。
-
スタンバイ・データベースのREDO転送ステータスはSYNCHRONIZEDである必要があります。また、プライマリ・データベースは、最大保護モードまたは最大可用性モードのいずれかで実行されている必要があります。
-
リアルタイム適用を有効化しておく必要があります。
-
-
Oracle Active Data Guardは、キャッシュ・フュージョンの使用を通じてOracle RAC環境でパフォーマンスの高いリアルタイム問合せを実現しています。これにより、Oracle Data Guardの適用インスタンスおよび問合せは、キャッシュで動作することが可能となり、ディスクI/O制限によって低速化することがなくなります。
この結果として、適用インスタンスの予期しない障害が発生すると、Oracle RACのすべてのオープン・インスタンス全体でバッファが一貫性のない状態となります。データベースが他のインスタンスでオープンしている場合、いずれかのオープン・インスタンスがActive Data Guardインスタンス・リカバリを実行してデータベースを一貫性のある状態にし、すべてのオープン・インスタンスがオープンしたままになります。
関連項目:
-
ブローカによる適用インスタンス障害の処理方法の詳細は、『Oracle Data Guard Broker』を参照してください。
-
Oracle Active Data GuardのOracle RACスタンバイにおける適用インスタンス障害の詳細は、
http://support.oracle.comにあるMy Oracle Supportノート1357597.1を参照してください。
-
10.2.1.5 自動ブロック・メディア・リカバリ
データベースのアクセス時に破損データ・ブロックが検出されると、それらのブロックの破損していないコピーで自動的に置き換えることができます。
これには次の条件があります。
-
フィジカル・スタンバイ・データベースがリアルタイム問合せモードで動作している必要があります(Oracle Active Data Guardライセンスが必要)。
-
フィジカル・スタンバイ・データベースがリアルタイム適用を実行している必要があります。
自動ブロック・メディア・リカバリは、破損ブロックが検出されたのがプライマリかスタンバイかにより、2つの方向で動作します。
プライマリでの破損ブロック
破損データ・ブロックがプライマリ・データベースで検出されると、プライマリはそれらのブロックの破損していないコピーをスタンバイで自動的に検索し、見つかれば、プライマリに送信します。
プライマリには、スタンバイのみ(フィジカル・スタンバイ、カスケード・フィジカル・スタンバイ、または遠隔同期インスタンス)へのLOG_ARCHIVE_DEST_nが必要です。プライマリには、ターミナル宛先へのLOG_ARCHIVE_DEST_nは必要ありません。それらのサービス名は自動的に確認できます。
スタンバイでの破損ブロック
破損データ・ブロックがスタンバイで検出されると、スタンバイは自動的にプライマリとの通信を起動し、それらのブロックの破損していないコピーをリクエストします。破損していないブロックをスタンバイに送信できるプライマリでは、次のデータベース初期化パラメータがスタンバイに構成されている必要があります。これは、プライマリが直接スタンバイにサービスを提供していない場合(カスケード構成など)でも適用されます。
-
LOG_ARCHIVE_CONFIGパラメータはDG_CONFIGリストを使用して構成され、LOG_ARCHIVE_DEST_nパラメータはプライマリ・データベース用に構成されている。または
-
FAL_SERVERパラメータが構成され、その値にプライマリ・データベース用のOracle Netサービス名が含まれている。
自動ブロック・メディア修復の追加の考慮事項
-
自動修復は、Oracle Data Guardのどの保護モードでもサポートされます。ただし、スタンバイの破損していないバージョンのブロックを使用してプライマリの破損ブロックを修復する場合の効果は、プライマリによって生成されるREDOとスタンバイ適用がどの程度密接に同期化されているかによって変化します。
-
自動ブロック修復が実行されると、データベースのアラート・ログにメッセージが書き込まれます。
-
自動ブロック修復が可能でない場合は、
ORA-1578エラーが返されます。
10.2.1.6 手動ブロック・メディア・リカバリ
破損データ・ブロックを手動で修復するには、RMAN RECOVER BLOCKコマンドを使用します。
このコマンドは、データ・ブロックの破損していないコピーをいくつかの場所で探します。デフォルトの場所の1つは、リアルタイム問合せモードで実行しているいずれかのフィジカル・スタンバイ・データベースです。RMAN RECOVER BLOCKコマンドのEXCLUDE STANDBYオプションを使用すると、置換ブロックのコピー元からフィジカル・スタンバイ・データベースを除外することもできます。
関連項目:
RMANのRECOVER BLOCKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
10.2.1.7 フィジカル・スタンバイ・データベースでの問合せのチューニング
フィジカル・スタンバイ・データベースに対する問合せをチューニングしてパフォーマンスを最適化できます。
問合せの調整については、次の場所からOracle Maximum Availability Architecture (MAA)のホームページにあるActive Data Guardのベスト・プラクティスに関する技術概要を参照してください。
http://www.oracle.com/goto/maa
強制全データベース・キャッシュ・モード
全データベース・キャッシュ・モードの強制の使用により、問合せがより高速に実行されるため、パフォーマンスが向上する可能性があります。
全データベース・キャッシュ・モードの強制の有効化および無効化はREDOに記録されないので、インメモリー・キャッシュのステータスはData Guard構成のすべてのメンバーで同じである必要はありません。
全データベース・インメモリー・キャッシュの強制機能の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
10.2.2 Active Data GuardスタンバイでのSQLおよびPL/SQLの使用
Oracle Databaseリリース19c以降では、Active Data Guardスタンバイ・データベースでSQLおよびPL/SQL操作を実行できます。
10.2.2.1 Active Data Guardスタンバイ・データベースでのDML操作の実行
Active Data Guardスタンバイ・データベースでDML操作を実行できます。これにより、スタンバイ・データベースで、DMLを実行する可能性のあるread-mostlyアプリケーションを実行できます。
スタンバイでのDML操作は、透過的にプライマリ・データベースにリダイレクトして実行できます。これには、PL/SQLブロックの一部であるDML文が含まれます。対応する変更がActive Data Guardスタンバイに送信され、適用されるまで、Active Data Guardセッションは待機します。DML操作中は読取り一貫性が維持され、DMLが実行されるスタンバイ・データベースでは、そのコミットされていない変更を表示できます。ただし、その他すべてのスタンバイ・データベース・インスタンスでは、トランザクションがコミットされた後のみ、これらの変更を表示できます。
ノート:
Active Data Guardスタンバイ・データベースで実行するDML操作の数が多すぎないようにしてください。この操作は実際にはプライマリ上で実行されるため、DMLが多すぎると、プライマリのパフォーマンスに影響を及ぼす可能性があります。
ノート:
Oracle XAトランザクションでのDML操作は、Active Data Guardスタンバイ・データベースではサポートされていません。プライマリへのDML操作の自動リダイレクトは、システム・レベルまたはセッション・レベルで構成できます。セッション・レベルの設定は、システム・レベルの設定をオーバーライドします。
Active Data Guard環境ですべてのスタンバイ・セッションに対するDML操作の自動リダイレクトを構成するには:
ADG_REDIRECT_DML初期化パラメータをTRUEに設定します。
現在のセッションに対するDML操作の自動リダイレクトを構成するには、次のコマンドを使用します。
ALTER SESSION ENABLE ADG_REDIRECT_DML;
例10-1 フィジカル・スタンバイ・データベースでのDML操作の実行
Active Data Guard設定のフィジカル・スタンバイ・データベースには、employeesという名前の表が含まれます。Active Data Guard環境のフィジカル・スタンバイ・データベースでDMLを実行して、この表に行を挿入できます。
スタンバイ・データベースで、現在のセッションに対してDMLリダイレクトを有効にします。
SQL> ALTER SESSION ENABLE ADG_REDIRECT_DML;次のコマンドを使用して、employees表に行を追加します。
SQL> INSERT INTO employees VALUES (.......);この時点で、変更されたデータはコマンドが実行されたスタンバイ・データベースによってのみ認識されます。挿入操作がプライマリ・データベースでコミットされると、変更は、すべてのスタンバイ・データベースに送信されて適用されます。
10.2.2.2 Active Data Guardスタンバイ・データベースでの最上位のPL/SQL操作の実行
Active Data Guardスタンバイ・データベースで実行する最上位のPL/SQLブロックは、バインド変数が含まれていない場合、プライマリ・データベースにリダイレクトして実行できます。
スタンバイで実行される最上位のPL/SQL操作をプライマリにリダイレクトするには、スタンバイ・データベースで、次のコマンドを使用して、自動リダイレクトを構成します。
ALTER SESSION ENABLE ADG_REDIRECT_PLSQL;
最上位のPL/SQL操作の自動リダイレクトは、セッション・レベルでのみ構成できます。
10.2.2.3 変更されたPL/SQLオブジェクトの自動再コンパイル
スタンバイ・インスタンスで実行されるPL/SQLオブジェクトは、無効になっている場合、再コンパイルできます。
PL/SQLオブジェクトは、依存オブジェクトが変更または削除されると無効になります。Oracle Databaseリリース19c以降では、ADG_REDIRECT_DML初期化パラメータをTRUEに設定することで、スタンバイ・データベースで実行される、無効化されたPL/SQLオブジェクトを自動的に再コンパイルできます。これらのPL/SQLオブジェクトに対応するDDLは、プライマリ・データベースにリダイレクトされ、実行されます。スタンバイ・セッションは、操作が完了するまで待機します。
例10-2 変更されたPL/SQLオブジェクトの自動再コンパイル
Active Data Guard環境のプライマリ・データベースで、insert_emplという名前のプロシージャが作成されます。このプロシージャは、employees表を更新するために使用されます。
CREATE OR REPLACE PROCEDURE update_sal (emp_id IN NUMBER,sal IN NUMBER)
AS BEGIN
UPDATE employees SET salary=sal WHERE employee_id=emp_id);
END;その後、employees表の構造は、ALTER TABLEコマンドを使用して変更されます。これにより、update_salプロシージャが無効化されます。
Active Data Guard環境のスタンバイ・データベースで、update_salプロシージャを使用し、従業員の給与を更新する必要があります。フィジカル・スタンバイで次のコマンドを実行します。
SQL> ALTER SESSION ENABLE ADG_REDIRECT_DML;
SQL> exec update_sal(105,6000);これらのコマンドを実行するユーザーには、update_salプロシージャを実行する権限が付与されています。
10.2.3 Active Data Guardインスタンスでの一時表の使用
Active Data Guardインスタンスでは、グローバル一時表とプライベート一時表の両方を作成できます。
一時表には、トランザクションまたはセッションの期間中にのみ存在するデータが保持されます。一時表内のデータはセッション専用です。各セッションで参照および変更できるのは、そのセッション自体のデータのみです。
関連項目:
-
グローバル一時表、プライベート一時表およびそれらの相違点の詳細は、Oracle Database概要を参照してください。
10.2.3.1 Active Data Guardインスタンス上のグローバル一時表
Oracle Active Data Guardインスタンス上のグローバル一時表では、DMLおよびDDL操作が可能です。
DML操作
DML操作によってグローバル一時表が変更された場合、変更自体は一時表のみであるため、REDOは生成されません。しかし、変更に対して生成されたUNDOは次にREDOを生成します。読取り専用データベース(Active Data Guardスタンバイなど)でのREDO生成は許可されません。しかし、一時UNDO機能によってグローバル一時表への変更に対するUNDOをUNDO表領域ではなく一時表領域に格納できるため、Oracle Active Data Guardスタンバイ上のグローバル一時表でのDML操作は可能です。また、一時表領域に格納されたUNDOはREDOを生成しません。
この機能は次のようにOracle Data Guardに利点をもたらします。
-
一時データの格納にグローバル一時表を使用するread-mostlyレポート・アプリケーションは、Oracle Active Data Guardインスタンスに負荷を軽減させることができます。
-
一時UNDOがプライマリ・データベースで有効化されていると、グローバル一時表への変更のUNDOはREDOに記録されないので、プライマリ・データベースが生成するREDOはより少なくなります。そのため、Oracle Data Guardがスタンバイに送信する必要のあるREDOの量も減少するので、ネットワーク帯域幅と記憶域の使用量が減少します。
プライマリ・データベースで一時UNDOを有効化するには、TEMP_UNDO_ENABLED初期化パラメータを使用します。Oracle Active Data Guardスタンバイでは、一時UNDOはデフォルトで常に有効化されているので、TEMP_UNDO_ENABLEDパラメータは何も影響しません。
制限事項
-
一時UNDO機能では、データベース初期化パラメータ
COMPATIBLEを12.0.0以降に設定する必要があります。 -
Oracle Active Data Guardインスタンスでの一時UNDO機能は一時
BLOBまたは一時CLOBをサポートしません。 -
ローカル・オブジェクトに対する変更を伴っている場合、Oracle Active Data Guardインスタンス上の分散トランザクションは許可されません。たとえば、Oracle Active Data Guardインスタンスでグローバル一時表を変更し、かつデータベース・リンクを使用して他のデータベース上でリモート表を更新するようなトランザクションは、コミットできません。Active Data Guardインスタンス上のグローバル一時表に対する未処理のDML操作をコミットまたはロールバックしてから、リモートDML操作を発行する、あるいはその逆順を行う必要があります。
EXPLAIN PLAN文などの操作によるグローバル一時表への暗黙的な書込みも、これに該当します。
関連項目:
-
一時表UNDOの詳細は、『Oracle Database管理者ガイド』を参照してください。
-
TEMP_UNDO_ENABLED初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
DDL操作
Active Data Guardスタンバイ・データベースでは、グローバル一時表を作成および削除できます。これらの操作のDDLは、プライマリ・データベースに透過的にリダイレクトされます。対応する変更がActive Data Guardスタンバイに送信され、適用されるまで、Active Data Guardセッションは待機します。グローバル一時表の作成例を次に示します。
SQL> CREATE GLOBAL TEMPORARY TABLE tab2(c1 number, c2 varchar(10)) ON COMMIT PRESERVE ROWS;
Table created.
SQL>ノート:
DDLリダイレクションが成功するには、Active Data Guardスタンバイ・データベースで、リアルタイム適用オプションを使用して管理スタンバイ・リカバリを開始し、かつ、Active Data Guardスタンバイ・データベースがプライマリ・データベースと同期している必要があります。
ノート:
グローバル一時表でのデータ定義言語(DDL)操作(CREATEやDROPなど)は引き続きプライマリ・データベースから発行できます。DDL変更はプライマリ・データベースでキャッチアップするとスタンバイで表示可能です。
10.2.3.2 Active Data Guardインスタンス上のプライベート一時表
Oracle Active Data Guardインスタンスでは、読取り専用であっても、プライベート一時表を作成できます。
読取り専用データベースでプライベート一時表を作成できる理由は、表のメタデータがディスク上ではなくメモリー上に格納されるためです。プライベート一時表の存続期間は表が作成されたセッション中のみであり、表はセッションの終了時に自動的に削除されます。この機能により、Active Data Guardスタンバイ・データベースに対してレポート・アプリケーションを実行できます。
ノート:
- Oracle Database管理者ガイド(プライベート一時表の作成の詳細)
10.2.4 Active Data Guardスタンバイ環境でのIM列ストア
Oracle Database 12cリリース2 (12.2.0.1)以降、Active Data Guard (ADG)環境のスタンバイ・データベースでOracle Databaseインメモリー列ストア(IM列ストア)がサポートされます。
Active Data Guardスタンバイ・データベースで実行するレポート作成のワークロードでは、IM列ストアを使用できます。IM列ストアを使用すると、圧縮列形式(インメモリー)のデータへのアクセスを最大限に利用できるため、ワークロードの実行パフォーマンスが向上します。さらに、プライマリ・データベースとスタンバイ・データベースでIM列ストアにまったく異なるデータ・セットを移入でき、アプリケーションで使用できるIM列ストアのサイズを事実上2倍にすることができます。複数インスタンスのREDO ApplyでIM列ストアのサポートを有効にするには、初期化パラメータenable_imc_with_miraをTRUEに設定します。
次の制約に注意してください:
-
インメモリー式はプライマリ・デーベースで実行された問合せのみに基づいて取得されます。
-
アクセス条件に基づいたインメモリーの情報ライフサイクル管理(ILM)ポリシーは、プライマリ・デーベースに記録されたアクセスのみに基づいてトリガーされます。
ノート:
-
インメモリーのFastStartは、ADG環境のスタンバイ・データベースでサポートされていません。
-
インメモリーのJoin-Groupsは、ADG環境のスタンバイ・データベースでサポートされていません。
10.2.5 Active Data Guard環境でのインメモリー外部表
Oracle Active Data Guardは、インメモリー外部表をサポートしています。
インメモリー外部表は、プライマリ・データベースとスタンバイ・データベースの両方でパラレルにロードされます。Active Data Guard環境で実行される問合せでは、パラレル問合せでインメモリー外部表セグメントを使用します。INMEMORYまたはNO INMEMORYを使用すると、アクティブなスタンバイ・データベースで、インメモリー外部表セグメントが解放されます。
ノート:
IM列ストアにINMEMORYオブジェクトを移入するとき、INMEMORY...DISTRIBUTE句のFOR SERVICE副句を使用することは、プライマリ・データベース、スタンバイ・データベース、およびその両方についてサポートされていません。
10.2.6 Oracle Active Data Guardでの順序の使用
Oracle Active Data Guard環境では、デフォルトのCACHEオプションおよびNOORDERオプションでプライマリ・データベースによって作成された順序には、スタンバイ・データベースからもアクセスできます。
スタンバイ・データベースはそのような順序に最初にアクセスするとき、プライマリ・データベースに順序番号の範囲を割り当てることを要求します。範囲はキャッシュ・サイズと、順序が作成されたときに指定したその他の順序プロパティに基づきます。次に、データ・ディクショナリ内の対応する順序エントリを調整することで、プライマリ・データベースがそれらの順序番号を要求しているスタンバイ・データベースに割り当てます。スタンバイが範囲内のすべての番号を使用したら、別の番号の範囲を要求します。
プライマリ・データベースは、スタンバイ・データベースからの範囲の要求ごとに、プライマリ・データベースとスタンバイ・データベースの両方に以前に割り当てられたものと重複しないような順序番号の範囲が確実に取得されるようにします。これでOracle Data Guard構成全体にわたって一意の順序番号のストリームが生成されます。
順序の範囲に対するスタンバイの要求にはプライマリへのラウンドトリップが含まれるため、Oracle Active Data Guardスタンバイで使用される順序を作成するときは、CACHEキーワードに十分大きい値を指定するようにしてください。そうしないと、パフォーマンスが影響を受ける可能性があります。
また、ターミナル・スタンバイには、プライマリを指すように定義されたLOG_ARCHIVE_DEST_nパラメータが含まれることを確認してください。
例: 複数スタンバイ構成での順序値の範囲の割当て
この例は、最初、または以前に割り当てられた順序値のすべてを使い果してしまった後で順序のNEXTVALを参照する場合に、データベースに割り当てることのできる順序値の範囲を示します。この例では、2つのスタンバイ・データベースがあります。
10.2.6.1 セッション順序
セッション順序はセッションの可視性があるグローバル一時表で使用されるように特別に設計された特別なタイプの順序です。
既存の通常の順序(対比のために「グローバルな」順序と呼びます)とは異なり、セッションの順序は、複数のセッション全体ではなく、1つのセッションに限定された順序番号の一意の範囲を返します。また、セッションの順序は永続されない点も異なります。セッションが失われると、そのセッション中にアクセスされるセッションの順序も失われます。
セッション順序は、順序が定義されるときに指定する順序プロパティのほとんどをサポートします。しかし、CACHE/NOCACHEおよびORDER/NOORDERオプションはセッション順序には関係なく、無視されます。
セッション順序は読取り/書込みデータベースにより作成される必要がありますが、読取り/書込みまたは読取り専用データベース(通常のデータベースを読取り専用で一時的にオープンするか、またはスタンバイ・データベース)でアクセスできます。
セッション順序の作成および変更
セッション順序を作成するには、次のSQL文を発行します。
SQL> CREATE SEQUENCE … SESSION;
既存のセッション順序を通常の(グローバル)順序に変更するには、次のSQL文を発行します。
SQL> ALTER SEQUENCE … GLOBAL;
通常の順序をセッション順序に変更するには、次のSQL文を発行します。
SQL> ALTER SEQUENCE … SESSION;
例: セッション順序の使用
この例では、セッション順序値がデータベース・セッションごとにどのように一意になるかを示しています。
10.3 フィジカル・スタンバイでの手動操作が必要なプライマリ・データベースの変更
プライマリ・データベースに対して行われる構造変更のほとんどは、REDOデータによってフィジカル・スタンバイ・データベースに自動的に伝播されますが、手動操作が必要な変更がいくつかあります。
次の表に、フィジカル・スタンバイ・データベースで手動操作が必要な、プライマリ・データベースの構造および構成の変更を示します。
表10-1 フィジカル・スタンバイでの手動操作が必要なプライマリ・データベースの変更
| プライマリ・データベースの変更 | フィジカル・スタンバイ・データベースで必要なアクション |
|---|---|
|
|
|
|
|
|
|
プライマリ・データベースとフィジカル・スタンバイ・データベースの間で表領域を移動する。 |
|
|
フィジカル・スタンバイ・データベースでデータファイル名を変更します。 |
|
|
フィジカル・スタンバイ・データベースでREDOログおよびスタンバイREDOログの構成を評価し、必要に応じて調整する。 |
|
|
RMANコマンド |
|
|
Oracle Database 12cリリース2 (12.2.0.1)以降、プライマリ・データベースで行われたパスワード・ファイルの変更は、スタンバイ・データベースに自動的に伝播されます。唯一の例外は、遠隔同期インスタンスです。遠隔同期インスタンスはREDOを受け取りますが、適用しないため、更新したパスワード・ファイルを引き続き手動で遠隔同期インスタンスにコピーする必要があります。遠隔同期インスタンスでパスワード・ファイルが更新された後、プライマリでのパスワードの更新を含むREDOは、遠隔同期インスタンスからREDOログを受け取るように設定されているすべてのスタンバイ・データベースに自動的に伝播されます。REDOが適用されると、スタンバイでパスワード・ファイルが更新されます。 |
|
|
フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットをプライマリ・データベースのデータベース暗号化ウォレットの最新コピーで置き換える。 |
|
|
フィジカル・スタンバイ・データベースで対応する変更を初期化パラメータに加える必要があるかどうかを評価する。 |
10.3.1 データファイルの追加または表領域の作成
STANDBY_FILE_MANAGEMENTデータベース初期化パラメータは、プライマリ・データベースへのデータ・ファイルの追加がフィジカル・スタンバイ・データベースに自動的に伝播されるかどうかを制御します。
-
フィジカル・スタンバイ・データベースの
STANDBY_FILE_MANAGEMENTデータベース・パラメータがAUTOに設定されている場合、プライマリ・データベースに作成された新しいデータファイルはフィジカル・スタンバイ・データベースに自動的に作成されます。 -
フィジカル・スタンバイ・データベースの
STANDBY_FILE_MANAGEMENTデータベース・パラメータがMANUALに設定されている場合、新しいデータファイルがプライマリ・データベースに追加されると、そのファイルは、プライマリ・データベースからフィジカル・スタンバイ・データベースに手動でコピーする必要があります。ノート:
Oracle Active Data Guardオプションが有効になっているフィジカル・スタンバイでは、手動でのコピーの方法は使用できません。かわりに、スタンバイで次のSQL文を実行して、空のデータファイルを作成する必要があります。
SQL> ALTER DATABASE CREATE DATAFILE [filename | filenumber] - AS [NEW | new_filename];名前を変更するもの(
filenameまたはfilenumber)を指定する必要があります。また、新しいファイル名または
NEWのいずれかを指定します。NEWキーワードにより、Oracle Managed Files (OMF)が有効な場合、自動的に名前が選択されます。
別のデータベースの既存のデータ・ファイルがプライマリ・データベースにコピーされた場合、同様にそのファイルをスタンバイ・データベースにコピーする必要があり、STANDBY_FILE_MANAGEMENTパラメータの設定に関係なくスタンバイ制御ファイルを再作成する必要があります。
10.3.2 表領域の削除とデータファイルの削除
プライマリ・データベースから表領域またはデータファイルが削除されると、対応するデータファイルがフィジカル・スタンバイ・データベースから削除される必要があります。
次の例に、表領域を削除する方法を示します。
SQL> DROP TABLESPACE tbs_4; SQL> ALTER SYSTEM SWITCH LOGFILE;
削除されたデータファイルがデータベースに属していないことを確認するには、V$DATAFILEビューを問い合せます。
過去の変更を含むREDOデータがスタンバイ・データベースに適用された後、スタンバイ・システムで対応するデータファイルを削除します。次に例を示します。
% rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf
削除した表領域のREDO情報がスタンバイ・データベースで適用されたことを確認した後、プライマリ・データベースで表領域のデータファイルを削除できます。次に例を示します。
% rm /disk1/oracle/oradata/payroll/tbs_4.dbf
10.3.2.1 DROP TABLESPACE INCLUDING CONTENTS AND DATAFILESの使用
プライマリ・データベースでSQL DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES文を発行すると、プライマリ・データベースとスタンバイ・データベースの両方からデータファイルを削除できます。
この文を使用するには、STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定する必要があります。たとえば、プライマリ・サイトで表領域を削除するには、次のように入力します。
SQL> DROP TABLESPACE tbs_4 INCLUDING CONTENTS AND DATAFILES; SQL> ALTER SYSTEM SWITCH LOGFILE;
10.3.3 フィジカル・スタンバイ・データベースでのトランスポータブル表領域の使用
Oracleトランスポータブル表領域機能を使用すると、Oracleデータベースのサブセットを移動して、別のOracleデータベースにプラグインできます。これにより、実際には表領域がデータベース間で移動します。
フィジカル・スタンバイの使用中に表領域セットをプライマリ・データベースに移動またはコピーするステップは、次のとおりです。
-
トランスポートする表領域セットのデータファイルとその表領域セットの構造情報を含むエクスポート・ファイルで構成される、トランスポータブル表領域セットを生成します。
-
次の手順で表領域セットをトランスポートします。
-
データファイルをコピーし、プライマリ・データベースにエクスポートします。
-
データファイルをスタンバイ・データベースにコピーします。
DB_FILE_NAME_CONVERTデータベース初期化パラメータが構成されていないかぎり、データファイルのパス名はプライマリ・データベースとスタンバイ・データベースで同じものが使用される必要があります。DB_FILE_NAME_CONVERTが構成されてなく、プライマリ・データベースとスタンバイ・データベースでデータファイルのパス名が同じではない場合、ALTER DATABASE RENAME FILE文を発行して、データファイルの名前を変更します。この操作は、REDO Applyが、表領域をプライマリ・データベースにプラグすることで生成されたREDOの適用に失敗した後で行います。データ・ファイル名を変更する前に、STANDBY_FILE_MANAGEMENT初期化パラメータをMANUALに設定し、データ・ファイル名を変更した後で、前の値にリセットする必要があります。 -
-
表領域をプラグインします。
データ・ポンプ・ユーティリティを起動して、表領域セットをプライマリ・データベースにプラグインします。スタンバイ・サイトでREDOデータが生成されて適用され、表領域がスタンバイ・データベースにプラグインされます。
トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。
10.3.4 プライマリ・データベースのデータファイルの改名
プライマリ・データベースで1つ以上のデータファイルを改名した場合、その変更はスタンバイ・データベースに伝播されません。それは手動で行う必要があります。
STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定しても変更処理は自動的に実行されないため、スタンバイ・データベースにある同じデータファイルを改名する場合は、スタンバイ・データベースで同じ変更を手動で行う必要があります。
次のステップでは、プライマリ・データベースでデータファイルを改名し、その変更をスタンバイ・データベースに手動で伝播する方法について説明します。
スタンバイ・システムで対応するデータ・ファイルを改名せず、スタンバイ・データベースの制御ファイルのリフレッシュを試みた場合、スタンバイ・データベースは改名したデータ・ファイルを使用しようとしますが、見つかりません。次のようなメッセージがアラート・ログに書き込まれます。
ORA-00283: recovery session canceled due to errors ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'
ノート:
ステップ4-9のかわりに、ALTER DATABASE MOVE DATAFILEコマンドを使用してスタンバイでデータファイルを改名する方法があります。詳細は、「オンライン・データ・ファイルの場所の移行」を参照してください。
10.3.5 REDOログ・ファイル・グループの追加または削除
プライマリ・データベースでログ・ファイル・グループを追加または削除した後に、フィジカル・スタンバイ・データベースのREDOログおよびスタンバイREDOログの構成を再評価し、必要に応じて調整する必要があります。
次のステップを実行して、フィジカル・スタンバイ・データベースでログ・ファイル・グループまたはスタンバイ・ログ・ファイル・グループを追加または削除します。
Oracle RAC環境では、次の点に注意してください。
-
プライマリ・データベースにオンラインREDOログ・グループが追加されるとき、スタンバイ・データベースにはオンラインREDOログ・グループを手動で追加する必要があります。自動的には実行されません。
-
プライマリ・データベースに新しいREDOスレッドが追加されるとき、スタンバイには新しいREDOスレッドが自動的に追加されます。デフォルトでは、新しいスレッドは100 MBずつの2つのログ・グループで構成されます。これは変更もオーバーライドもできません。
-
既存のREDOスレッドに新しいログ・グループが追加されるとき、既存のスレッドに新しいログ・グループは自動的に追加されません。
10.3.6 NOLOGGINGまたはリカバリ不能な操作
NOLOGGINGまたはUNRECOVERABLE句を使用してDMLまたはDDL操作を実行すると、スタンバイのブロックが無効とマークされることがあります(ログに記録されないブロックとも呼ばれます)。
ログに記録されない方法で操作が実際に実行される場合の詳細は、FORCE LOGGING設定の優先順位を参照してください。
NOLOGGING句を使用した後のリカバリの詳細は、「NOLOGGING句を指定した後のリカバリ」を参照してください。
FORCE LOGGINGモードの指定の詳細は、『Oracle Database管理者ガイド』を参照してください。
10.3.7 パスワード・ファイルのリフレッシュ
REMOTE_LOGIN_PASSWORDFILEデータベース初期化パラメータがSHAREDまたはEXCLUSIVEに設定されている場合は、フィジカル・スタンバイ・データベース上のパスワード・ファイルは、プライマリ・データベースからの最新コピーと自動的に置き換えられます。
ファイルは、管理権限が付与または解除されるか、管理権限があるユーザーのパスワードが変更されると、置き換えられます。唯一の例外は、遠隔同期インスタンスです。遠隔同期インスタンスはREDOを受け取りますが、適用しないため、更新したパスワード・ファイルを引き続き手動で遠隔同期インスタンスにコピーする必要があります。遠隔同期インスタンスでパスワード・ファイルが手動で更新されると、プライマリ・データベースからの同じパスワード変更内容を含むREDOが、遠隔同期インスタンスからREDOを受け取るように設定されているすべてのスタンバイ・データベースに自動的に伝播されます。REDOが適用されると、スタンバイでパスワード・ファイルが更新されます。
10.3.8 TDEマスター暗号化キーのリセット
フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットは、プライマリ・データベースでTDEマスター暗号化キーがリセットされるたびに、プライマリ・データベースのデータベース暗号化ウォレットの最新コピーで置き換える必要があります。
フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットをリフレッシュできないと、プライマリ・データベースでマスター暗号化キーがリセットされた後に変更された、フィジカル・スタンバイ・データベース上の暗号化された列にアクセスできません。
オンラインの表領域およびデータベースの場合、Oracle Database 12cリリース2 (12.2.0.1)以降、新規および既存の両方の表領域、およびOracle Data Guard環境内の既存のデータベースを暗号化、復号化およびキー更新できます。
オフラインの表領域およびデータベースの場合、Oracle Database 12cリリース2 (12.2.0.1)以降、新規および既存の両方の表領域、およびOracle Data Guard環境内の既存のデータベースを暗号化および復号化できます。
オンライン変換では、スタンバイ上の暗号化、復号化またはキー更新は、プライマリでの実行後に自動で行われます。オンラインの暗号化、復号化またはキー更新は、スタンバイ・データベースで直接に実行することはできません。
オフライン変換では、暗号化または復号化はプライマリとスタンバイ上の両方に手動で実行する必要があります。オフライン変換は、特定のプライマリまたはスタンバイ・データベースのみのデータ・ファイルに影響を及ぼします。プライマリおよびフィジカル・スタンバイの両方を同じ状態に維持する必要があります。最初にスタンバイ上の表領域を暗号化(または復号化)し、プライマリにスイッチしてからプライマリの表領域を暗号化(または復号化)することで、停止時間を最小化できます。
10.4 OPEN RESETLOGS文を使用したリカバリ
Oracle Data Guardでは、RESETLOGSオプションを使用してプライマリ・データベースがオープンされた後も、フィジカル・スタンバイ・データベースでリカバリを続行できます。
プライマリ・データベースでALTER DATABASE OPEN RESETLOGS文が発行されると、データベースのインカネーションが変更され、REDOデータの新しいブランチが作成されます。
フィジカル・スタンバイ・データベースがREDOデータの新規ブランチを受信すると、REDO Applyではそれが自動的に使用されます。フィジカル・スタンバイ・データベースの場合、スタンバイ・データベースにより新規リセットログのSCNより後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されていなければ、手動による介入は必要ありません。次の表に、スタンバイ・データベースとプライマリ・データベースのブランチを再同期化する方法を示します。
| スタンバイ・データベースの状態 . . | 操作 . . | 実行するステップ . . |
|---|---|---|
|
新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されておらず、 |
REDO Applyは自動的にREDOの新規ブランチを使用します。 |
手動による介入は必要ありません。管理されたREDOプロセス(MRP)は、自動的にスタンバイ・データベースをREDOデータの新規ブランチと再同期化します。 ノート: 新規REDOブランチがスタンバイに登録されたかどうかを調べるには、プライマリおよびスタンバイで次の問合せを実行して、結果が一致することを確認します。 SELECT resetlogs_id, resetlogs_change# FROM V$DATABASE_INCARNATION WHERE status='CURRENT' |
|
新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっている場合。 |
スタンバイ・データベースは、REDOデータの将来の新規ブランチでリカバリされます。 |
管理されたREDOプロセス(MRP)は、自動的にスタンバイ・データベースを新規ブランチと再同期化します。 |
|
新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっていない場合。 |
指定のプライマリ・データベース・ブランチで、プライマリ・データベースとスタンバイの内容にずれが生じます。 |
「フィジカル・スタンバイ・データベースの作成」の手順に従ってフィジカル・スタンバイ・データベースを再作成します。 |
|
REDOデータの新規ブランチから介入するアーカイブREDOログ・ファイルが欠落している場合。 |
MRPは欠落しているログ・ファイルが取得されるまで続行できません。 |
各ブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。 |
|
REDOデータの前のブランチの終わりからアーカイブREDOログ・ファイルが欠落している場合。 |
MRPは欠落しているログ・ファイルが取得されるまで続行できません。 |
前のブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。 |
データベース・インカネーション、OPEN RESETLOGSによるリカバリ、フラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
10.5 プライマリRESETLOGS操作の後のマウント済スタンバイの自動フラッシュバック
マウント状態のスタンバイ・データベースは、プライマリでのRESETLOGS操作の後、プライマリ・データベースを自動的に継ぐことができます。これにより、プライマリでのRESETLOGS操作の後のスタンバイ管理が簡略化されます。
プライマリ・データベースまたはプライマリ・データベース内のPDBのいずれかでフラッシュバックまたはPoint-in-Timeリカバリが実行されると、プライマリ・データベースまたはPDBは過去のある時点に戻され、その後、RESETLOGSオプションを使用してオープンされます。プライマリまたはプライマリ内のPDBの新しいインカネーションが作成されます。スタンバイが自動的にプライマリを継ぐようにするために、MRPによって次のアクションが実行されます。
-
新しいインカネーションを検出します
-
スタンバイまたはスタンバイ上のPDBを、プライマリまたはプライマリ上のPDBと同じ時点までフラッシュバックします
-
スタンバイ・リカバリを再開し、REDOの新規ブランチにスタンバイを移動します
フラッシュバック操作は、スタンバイ・データベースに十分なフラッシュバック・データがある場合にのみ成功します。
スタンバイが自動的にプライマリを継がないようにする場合は、スタンバイ・データベースをOPENモードのままにするか、スタンバイでMRPプロセスを停止します。
スタンバイ・データベースが読取り専用モードでオープンされている場合、対応するエラー・メッセージはアラート・ログに記録されます。フィジカル・スタンバイをクローズした後にMRPを再起動すると、リカバリ・プロセスにより自動的にスタンバイ・データベースがフラッシュバックされ、REDOの新規ブランチの適用が続行されます。
10.6 プライマリ、フィジカル・スタンバイおよびスナップショット・スタンバイ・データベースの監視
次の表に、一般的なプライマリ・データベースの管理アクションと、そのアクションに関する情報の参照先を示します。
表10-2 一般的なプライマリ・データベースの管理アクションに関する情報ソース
10.6.1 プライマリ、フィジカルおよびスナップショット・スタンバイ・データベースを監視するためのビューの使用
プライマリ、フィジカル・スタンバイおよびスナップショット・スタンバイ・データベースを監視するには、動的パフォーマンス・ビューを使用します。
次の動的パフォーマンス・ビューについて説明します。
関連項目:
ビューの詳細な参照情報は、『Oracle Databaseリファレンス』を参照してください。
10.6.1.1 V$DATABASE
V$DATABASEビューを使用すると、データ保護、スイッチオーバー・ステータス、ファスト・スタート・フェイルオーバーのステータスに関する情報を確認できます。
次の問合せは、プライマリ・データベース、フィジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースのデータ保護モード、データ保護レベル、データベース・ロールおよびスイッチオーバー・ステータスを表示します。
SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL, – > DATABASE_ROLE ROLE, SWITCHOVER_STATUS – > FROM V$DATABASE;
次の問合せは、ファスト・スタート・フェイルオーバーのステータスを表示します。
SQL> SELECT FS_FAILOVER_STATUS "FSFO STATUS", - > FS_FAILOVER_CURRENT_TARGET TARGET, - > FS_FAILOVER_THRESHOLD THRESHOLD, - > FS_FAILOVER_OBSERVER_PRESENT "OBSERVER PRESENT" – > FROM V$DATABASE;
10.6.1.2 V$DATAGUARD_PROCESS
V$DATAGUARD_PROCESSビューには、現在実行されているOracle Data Guardプロセスごとに1つの行が表示されます。
V$DATAGUARD_PROCESSビューは、Oracle Database 12cリリース2 (12.2.0.1)から非推奨となっており、将来のリリースでサポートされなくなる可能性があるV$MANAGED_STANDBYビューのかわりに使用します。
このビューの問合せの例を次に示します。
SQL> SELECT ROLE, THREAD#, SEQUENCE#, ACTION FROM V$DATAGUARD_PROCESS;
ROLE THREAD# SEQUENCE# ACTION
------------------------ ---------- ---------- ------------
RFS ping 1 9 IDLE
recovery apply slave 0 0 IDLE
recovery apply slave 0 0 IDLE
managed recovery 0 0 IDLE
recovery logmerger 1 9 APPLYING_LOG
RFS archive 0 0 IDLE
RFS async 1 9 IDLE10.6.1.3 V$MANAGED_STANDBY
V$MANAGED_STANDBYビューを使用すると、フィジカル・スタンバイ・データベースでREDO ApplyおよびREDO転送ステータスを問い合せることができます。
ノート:
このビューは、Oracle Database 12cリリース2 (12.2.0.1)から非推奨となっており、将来のリリースで削除される可能性があります。かわりに、V$DATAGUARD_PROCESSビューを使用する必要があります。
V$MANAGED_STANDBYビューの問合せの例を次に示します。
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#,- > BLOCK#, BLOCKS FROM V$MANAGED_STANDBY; PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS ------- ------------ ---------- ---------- ---------- ---------- RFS ATTACHED 1 947 72 72 MRP0 APPLYING_LOG 1 946 10 72
このサンプル出力は、リモート・ファイル・サーバー(RFS)プロセスがREDOログ・ファイル順序番号947のアーカイブを完了し、REDO ApplyがアクティブにアーカイブREDOログ・ファイル順序番号946を適用していることを示しています。また、REDO ApplyがアーカイブREDOログ・ファイル順序番号946を適用していることも示しています。
10.6.1.4 V$ARCHIVED_LOG
V$ARCHIVED_LOGビューを使用すると、プライマリ・データベースからフィジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースで受信されたアーカイブREDOログ・ファイルに関する情報を問い合せることができます。
たとえば、次の問合せを発行します。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, - > NEXT_CHANGE# FROM V$ARCHIVED_LOG; THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# ---------- ---------- ------------- ------------ 1 945 74651 74739 1 946 74739 74772 1 947 74772 74795
このサンプル出力は、プライマリ・データベースから受信した3つのアーカイブREDOログ・ファイルを示しています。
10.6.1.5 V$LOG_HISTORY
V$LOG_HISTORYビューを使用すると、アーカイブ・ログの履歴情報を問い合せることができます。
たとえば、次の問合せを発行します。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, - > NEXT_CHANGE# FROM V$LOG_HISTORY;
10.6.1.6 V$DATAGUARD_STATUS
V$DATAGUARD_STATUSビューを使用して、アラート・ログまたはサーバー・プロセス・トレース・ファイルにメッセージが書き込まれる原因となったOracle Data Guardイベントによって生成されたメッセージを表示できます。
たとえば、次の問合せを発行します。
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
10.6.1.7 V$ARCHIVE_DEST
V$ARCHIVE_DESTビューを問い合せて、各REDO転送先のステータスを表示します。スタンバイ・データベースであるREDO転送先については、そのスタンバイ・データベースで適用された最後のプライマリ・データベースREDOのSCNを表示します。
たとえば、次の問合せを発行します。
SQL> SELECT DEST_ID, STATUS, APPLIED_SCN FROM V$ARCHIVE_DEST WHERE TARGET='STANDBY'; DEST_ID STATUS APPLIED_SCN ---------- --------- ----------- 2 VALID 439054 3 VALID 439054
10.7 プライマリからスタンバイへのリストア・ポイントのレプリケート
プライマリ・データベースで作成されたリストア・ポイントは、自動的にスタンバイ・データベースにレプリケートされます。スタンバイ・データベースで作成されたリストア・ポイントは、レプリケートされたリストア・ポイントと呼ばれます。プライマリ・データベースのリストア・ポイントが保証付きリストア・ポイントか通常のリストア・ポイントかに関係なく、対応するレプリケートされたリストア・ポイントは、常に、通常のリストア・ポイントになります。
次の条件が満たされると、Oracle Databaseでは、リストア・ポイントがプライマリ・データベースからスタンバイ・データベースに自動的にレプリケートされます。
-
プライマリ・データベースとスタンバイ・データベースの両方の
COMPATIBLE初期化パラメータが19.0.0以降に設定されている -
プライマリ・データベースがオープンされている
プライマリがマウント・モードの場合にプライマリ・データベース上で作成されたリストア・ポイントは、レプリケートされません。この制限は、リストア・ポイント情報がREDOを介してレプリケートされるためです。
レプリケートされたリストア・ポイントのネーミング規則では、プライマリ・データベース上のリストア・ポイントの名前に_PRIMARYを接尾辞として付加したものが使用されます。スタンバイ・データベース上に同じ名前のレプリケートされたリストア・ポイントが存在する場合、レプリケートされたリストア・ポイントは作成されません。たとえば、プライマリ・データベースでPRE_MYTBSという名前のリストア・ポイントを作成すると、レプリケートされたリストア・ポイントはPRE_MYTBS_PRIMARYという名前になります。プライマリ上でリストア・ポイントを削除すると、スタンバイ上の対応するレプリケートされたリストア・ポイントも削除されます。
管理されたREDOプロセス(MRP)は、レプリケートされたリストア・ポイントの作成およびメンテナンスを管理します。MRPが実行されていないときにプライマリ・データベース上でリストア・ポイントが作成されると、これらのリストア・ポイントは、MRPの起動後にスタンバイ・データベースにレプリケートされます。
リストア・ポイントが自動的にレプリケートされるかどうかを判断するには、V$RESTORE_POINTビューを問い合せます。
10.8 REDO Applyのチューニング
REDO Applyおよびメディア・リカバリのパフォーマンスを最適化する方法について説明するOracleの技術概要が提供されています。
特に、Active Data Guardの11gのベスト・プラクティス(REDO Applyのベスト・プラクティスを含む)を参照してください。このホワイト・ペーパーは、次の場所からOracle Maximum Availability Architecture(MAA)のホームページにアクセスして入手することができます。
http://www.oracle.com/goto/maa
関連項目:
Standby Statspackのインストールと使用の詳細は、http://support.oracle.comのMy Oracle Supportノート454848.1を参照してください。Standby Statspackはフィジカル・スタンバイ・データベースからRedo Applyパフォーマンス・データを収集するために使用することもできます。
10.9 SQLチューニング・アドバイザによるActive Data Guard環境でのデータベースのチューニング
Active Data Guard環境では、SQLチューニング・アドバイザでプライマリ・データベース上のスタンバイ・ワークロードをチューニングできます。
データベース・リンクを使用すると、特定のデータベースでSQLチューニング・アドバイザ文を発行し、異なるデータベースで文を実行できます。
プライマリ・データベースのスタンバイ・データベース・ワークロードのチューニング
場合によっては、スタンバイ・データベースでは、データ保護ロールに加えてレポート・ロールを仮定できます。スタンバイ・データベースでは、問合せの固有のワークロードを含めることができ、一部でチューニングが必要になる場合があります。このシナリオで、スタンバイ・データベースで各チューニング文を発行してスタンバイ・データベース・ワークロードをチューニングしますが、SQLチューニング・アドバイザでは、スタンバイとプライマリのデータベース・リンクを使用してプライマリ・データベースで分析を実行します。
プライマリ・データベースのスタンバイ・データベース・ワークロードをチューニングするために実行する必要があるタスクを次に示します。タスクは、スタンバイ・データベースで、指定された順序で、DBMS_SQLTUNE PL/SQLパッケージを使用して実行する必要があります。
-
DBMS_SQLTUNE.CREATE_TUNING_TASK文を実行して、タスクの作成に必要なデータをプライマリ・データベースからフェッチします。スタンバイは読取り専用データベースのため、タスクに関するデータはリモートでプライマリ・データベースに書き込まれます。プライマリに書き込むこのステップでは、データベース・リンク・パラメータが必要です。(データベース・リンク・パラメータは、このステップで作成されるタスクに関連付けられているため後続のステップではオプションです。) -
DBMS_SQLTUNE.EXECUTE_TUNING_TASK文を実行します。最初は、タスクを実行するために必要なデータはリモートのプライマリ・データベースからフェッチされます。考えられるお薦め事項を見つけるためのチューニング分析プロセスが実行されます。スタンバイは読取り専用データベースのため、結果が使用可能な場合はリモートでプライマリに格納されます。 -
DBMS_SQLTUNE.REPORT_TUNING_TASK文を実行します。レポートを作成するために必要なデータは、リモートでプライマリ・データベースに格納されます。データはリモートでプライマリからフェッチされ、ローカルにスタンバイで作成されます。 -
DBMS_SQLTUNE.ACCEPT_SQL_PROFILE文を実行します。プロファイル・データは、スタンバイが読取り専用のためリモートのプライマリ・データベースに書き込まれます。 -
SQLプロファイルは、REDO Applyを使用してスタンバイで使用可能にされます。
関連項目:
-
DBMS_SQLTUNEパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください。 -
ローカルおよびリモートのSQLチューニングの詳細は、Oracle Database SQLチューニング・ガイドを参照してください
10.10 Oracle Diagnostic Packを使用したOracle Active Data Guardのスタンバイのチューニング
Oracle Diagnostic Packは、読取り専用モードでオープンされているOracle Active Data Guardスタンバイ・データベースとともに使用できます。
これにより、Oracle Active Data Guardスタンバイ用の自動ワークロード・リポジトリ(AWR)へのパフォーマンス・データを取得し、AWRデータに関する自動データベース診断モニター(ADDM)分析を実行できます。これらの操作の実行方法の詳細は、Oracle Databaseパフォーマンス・チューニング・ガイドを参照してください。
10.11 スナップショット・スタンバイ・データベースの管理
スナップショット・スタンバイ・データベースは完全に更新可能なスタンバイ・データベースです。これは、プライマリ・データベースからREDOデータを受信およびアーカイブしますが、適用はしません。
プライマリ・データベースから受信したREDOデータは、スナップショット・スタンバイ・データベースへのローカル更新がすべて破棄された後、スナップショット・スタンバイ・データベースが変換されてフィジカル・スタンバイ・データベースに戻ると適用されます。
プライマリ・データベースのREDOデータは受信と同時には適用されないので、スナップショット・スタンバイ・データベースは通常、時間の経過とともにプライマリ・データベースとの差異が生じます。スナップショット・スタンバイ・データベースのローカルな更新によって差異が増えます。ただし、スナップショット・スタンバイはいつでもフィジカル・スタンバイ・データベースに戻すことができ、その後プライマリから受信したREDOデータを適用できるため、プライマリ・データベース内のデータは完全に保護されています。
スナップショット・スタンバイ・データベースには、フィジカル・スタンバイ・データベースと同様の、障害時リカバリおよびデータ保護のメリットがあります。スナップショット・スタンバイ・データベースは、プライマリ・データベースの一時的かつ更新可能なスナップショットを保持することにメリットがあれば、プライマリ・データベースの障害からリカバリする時間が増えてもかまわない場合に最もよく使用されます。
10.11.1 スナップショット・スタンバイ・データベースへのフィジカル・スタンバイ・データベースの変換
これらのステップでは、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換する方法について説明します。
ノート:
Oracle Data Guard Brokerで管理されるフィジカル・スタンバイ・データベースは、DGMGRLまたはOracle Enterprise Manager Cloud Controlのいずれかを使用してスナップショット・スタンバイ・データベースに変換できます。詳細は、『Oracle Data Guard Broker』を参照してください。
10.11.2 スナップショット・スタンバイ・データベースの使用
スナップショット・スタンバイ・データベースは読取り/書込みモードでオープンされ、全体を更新できます。
スナップショット・スタンバイ・データベースには、次の特性があります。
-
スナップショット・スタンバイ・データベースは、スイッチオーバーまたはフェイルオーバーのターゲットにはできません。スナップショット・スタンバイ・データベースは、ロールの推移を実行する前にフィジカル・スタンバイ・データベースに変換して戻す必要があります。
-
スナップショット・スタンバイ・データベースは、最大保護のOracle Data Guard構成では唯一のスタンバイ・データベースになりません。
ノート:
フラッシュバック・データベースを使用して、スナップショット・スタンバイ・データベースを変換してフィジカル・スタンバイ・データベースに戻すことができます。フラッシュバック・データベース・テクノロジを使用して元に戻せない操作では、スナップショット・スタンバイを変換してフィジカル・スタンバイに戻せません。
フラッシュバック・データベースの詳細と制約は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。