11 ロジカル・スタンバイ・データベースの管理
これらの概念を理解しておくと、ロジカル・スタンバイ・データベースを正常に管理するのに役立ちます。
11.1 SQL Applyアーキテクチャの概要
SQL Applyでは、バックグラウンド・プロセスの集合を使用して、プライマリ・データベースの変更がロジカル・スタンバイ・データベースに適用されます。
図11-1に、情報のフローと各プロセスで実行されるロールを示します。
ログのマイニングおよび適用処理中は、次のように、様々なプロセスとその機能が関係します。
ログのマイニング中には、次のプロセスが実行されます。
-
READERプロセスでは、REDOレコードがアーカイブREDOログ・ファイルまたはスタンバイREDOログ・ファイルから読み込まれます。 -
PREPARERプロセスでは、REDOレコードに含まれるブロックの変更が論理変更レコード(LCR)に変換されます。特定のREDOログ・ファイルに対して複数のPREPARERプロセスをアクティブにすることができます。LCRは、LCRキャッシュと呼ばれるシステム・グローバル領域(SGA)でステージングされます。 -
BUILDERプロセスでは、LCRがトランザクション単位にグループ化されて、LCRキャッシュ内のメモリー管理、SQL Applyの再起動に関連するチェックポイント処理および重要でない変更のフィルタリングなど、その他のタスクが実行されます。
適用処理中には、次のプロセスが実行されます。
-
ANALYZERプロセスでは、様々なトランザクション間の依存性が識別されます。 -
COORDINATORプロセス(LSP)では、トランザクションを様々なAPPLIERに割り当て、トランザクション間の依存性が考慮されるように調整します。 -
APPLIERプロセスでは、COORDINATORプロセスの管理下でロジカル・スタンバイ・データベースにトランザクションを適用します。
V$LOGSTDBY_PROCESSビューで問い合せて、SQL Applyプロセスのアクティビティを確認することができます。現在のアクティビティの情報を提供する別なビューにV$LOGSTDBY_STATSがあり、SQL Applyアクティビティ中のロジカル・スタンバイ・データベースのために統計、現在の状態、ステータス情報を表示します。このビューと関連するその他のビューの詳細は、「ロジカル・スタンバイ・データベースの管理と監視に関連するビュー」を参照してください。
ノート:
SQL Applyプロセス(COORDINATORプロセスlsp0を含む)はすべてバックグラウンド・プロセスです。リソース・マネージャによる調整は行われません。そのため、ロジカル・スタンバイ・データベースでリソース・グループを作成しても、SQL Applyプロセスには影響ありません。
11.1.1 SQL Applyに関する各種の考慮事項
トランザクション・サイズ、ページアウト、再起動、DML適用、およびパスワード検証について理解すると、ロジカル・スタンバイを管理して最適利用するうえで役立ちます。
次を参照してください。
11.1.1.1 トランザクション・サイズの考慮事項
SQL Applyでは、トランザクションが大小2つのクラスに分類されます。
各クラスの定義は次のとおりです。
-
小さいトランザクション: SQL Applyは、REDOログ・ファイル内で小さいトランザクションのコミット・レコードを検出すると、そのトランザクションに属するLCRの適用を開始します。
-
大きいトランザクション: SQL Applyは、大きいトランザクションをトランザクション・チャンクと呼ばれる小さい単位に分割し、そのトランザクションのコミット・レコードをREDOログ・ファイル内で検出する前に、チャンクの適用を開始します。この処理が実行されるのは、LCRキャッシュのメモリー使用量を削減し、フェイルオーバー時間全体を短縮するためです。
たとえば、小さく分割しない場合、SQL*Loaderのロードが1000万行で、サイズがそれぞれ100バイトであれば、LCRキャッシュでは1GBを超えるメモリーが使用されます。LCRキャッシュに割り当てられているメモリーが1GB未満の場合は、LCRキャッシュからのページアウトが発生します。
メモリーの考慮事項とは別に、SQL Applyがトランザクションの
COMMITレコードを検出するまでに1000万行のSQL*Loaderロードに関連する変更の適用を開始しない場合、ロールの推移が停止します。SQL Applyがロジカル・スタンバイ・データベース上でトランザクションを適用し終わるまで、そのトランザクションのコミット後に開始されたスイッチオーバーまたはフェイルオーバーは終了できません。トランザクション・チャンクの使用にもかかわらず、800万行超を変更するトランザクションの処理時にSQL Applyのパフォーマンスが低下することがあります。800万行を超えるトランザクションでは、SQL Applyは一時セグメントを使用して、トランザクションの処理に必要な一部の内部メタデータを処理します。800万行を超えるトランザクションを正常に処理するには、SQL Applyで使用される一時セグメントに十分なスペースを割り当てます。
すべてのトランザクションは、最初は小さいトランザクションとして分類されます。SQL Applyでは、トランザクションが大きいトランザクションとして再分類されるタイミングは、LCRキャッシュに使用可能なメモリー量と、トランザクションに属するLCRのメモリー使用量に応じて決定します。
11.1.1.2 ページアウトの考慮事項
LCRキャッシュのメモリーがすべて使用され、SQL Applyを進行させるために領域の解放が必要になると、SQL Applyのコンテキスト内でページアウトが発生します。
たとえば、LCRキャッシュに100MBのメモリーが割り当てられている場合に、SQL Applyでサイズが300MBのLONG列を含む表に対するINSERTトランザクションが検出されるとします。この場合、ログ・マイニング・コンポーネントは、LONGデータの最初の部分をページアウトして列変更の後半部分を読み取ります。適切にチューニングされているロジカル・スタンバイ・データベースの場合、ページアウト・アクティビティはほとんど発生せず、システム全体のスループットには影響しません。
関連項目:
問題のあるページアウトを識別して修正処理を実行する方法の詳細は、「ロジカル・スタンバイ・データベースのカスタマイズ」を参照してください。
11.1.1.3 再開の考慮事項
トランザクションのコミット・レコードがREDOログ・ファイルからマイニングされてロジカル・スタンバイ・データベースに適用されるまで、ロジカル・スタンバイ・データベースに対する変更は永続的な変更になりません。
つまり、ユーザー指示の結果であるかシステム障害の結果であるかに関係なく、SQL Applyは停止されるたびに、コミットされていない最も古いトランザクションまで遡って再びマイニングする必要があります。
作業量は少ないが、長期間開いたままになるトランザクションの場合、SQL Applyを最初からやりなおすとSQL Applyはコミットされていない少量のトランザクションに対してREDOデータを再度読み込むために、アーカイブされた大量のREDOログ・ファイルを再度マイニングしなければならなくなるので非常に効率が悪くなります。これを回避するために、SQL Applyはコミットされていない古いデータに対して、定期的にチェックポイントを行っています。チェックポイントを実施するSCNは、V$LOGSTDBY_PROGRESSビューのRESTART_SCN列に反映さえます。再開後、SQL ApplyはRESTART_SCN列に表示された値よりも大きいSCNで生成されたREDOレコードのマイニングを開始します。SQL Applyは、アーカイブされたREDOログ・ファイルのうち再開が不要なものを自動的に削除します。
大量のDDLトランザクション、パラレルDML文(PDML)、および直接パス・ロードなどの特定のワークロードによっては、ワークロードが完了するまで、RESTART_SCNが中断します。
11.1.1.4 DML適用の考慮事項
SQL Applyがロジカル・スタンバイ・データベースのスループットと待機時間に影響するDMLトランザクションを適用する場合、次の特性があります。
-
1つの文で複数の行が変更されるバッチ更新または削除をプライマリ・データベースで実行した場合、ロジカル・スタンバイ・データベースでは行の個別変更として適用されます。そのため、メンテナンスされている各表に一意索引または主キーが必要になります。詳細は、「プライマリ・データベース内の表の行が一意に識別できることの確認」を参照してください。
-
プライマリ・データベースで実行されたダイレクト・パス・インサートは、ロジカル・スタンバイ・データベースで従来型の
INSERT文を使用して適用されます。
11.1.1.5 DDL適用の考慮事項
SQL Applyがロジカル・スタンバイ・データベースのスループットと待機時間に影響するDDLトランザクションを適用する場合、次の特性があります。
-
DDLトランザクションは、ロジカル・スタンバイ・データベースではシリアルに適用されます。そのため、プライマリ・データベースで同時に適用されたDDLトランザクションは、ロジカル・スタンバイ・データベースでは一度に1つずつ適用されます。
-
ロジカル・スタンバイ・データベース上でDMLアクティビティ(
CREATE TABLE AS SELECT(CTAS)文の一部)が抑制されるように、CTAS文が実行されます。CTAS文の一部として新規作成された表に挿入された行は、REDOログ・ファイルからマイニングされ、INSERT文を使用してロジカル・スタンバイ・データベースに適用されます。 -
SQL Applyは、プライマリ・データベースで実行されたDDLを再発行し、DDL操作のターゲットである同じオブジェクトで、同じトランザクション内で発生するDMLがロジカル・スタンバイ・データベースでレプリケートされないようにします。そのため、次の2つの場合にプライマリ・サイトとスタンバイ・サイトは互いに異なります。
-
DDLに、プライマリ・データベースの状態から導出される非リテラル値が含まれる場合。このようなDDLの例を次に示します。
ALTER TABLE hr.employees ADD (start_date date default sysdate);
SQL Applyはロジカル・スタンバイで同じDDLを再発行するため、
sysdate()ファンクションはロジカル・スタンバイで再評価されます。そのため、start_date列は、プライマリ・データベースでのデフォルト値とは異なるデフォルト値で作成されます。 -
DDLで、ターゲット表で定義されているDMLトリガーを起動する場合。トリガーされるDMLはDDLと同じトランザクションで発生し、DDLのターゲット表で動作するため、これらのトリガーされるDMLは、ロジカル・スタンバイでレプリケートされません。
たとえば、次のような表を作成するとします。
create table HR.TEMP_EMPLOYEES ( emp_id number primary key, first_name varchar2(64), last_name varchar2(64), modify_date timestamp);
次に、表にトリガーを作成して、表が更新されるたびに、
modify_dateを更新して変更時間が反映されるようにします。CREATE OR REPLACE TRIGGER TRG_TEST_MOD_DT BEFORE UPDATE ON HR.TEST_EMPLOYEES REFERENCING NEW AS NEW_ROW FOR EACH ROW BEGIN :NEW_ROW.MODIFY_DATE:= SYSTIMESTAMP; END; /
通常のDML/DDLワークロードではこの表は正しく維持されます。ただし、この表にデフォルト値を含む列を追加すると、
ADD COLUMNDDLがこの更新トリガーを起動し、表内のすべての行のMODIFY_DATE列を新しいタイムスタンプに変更します。MODIFY_DATE列へのこの種の変更は、ロジカル・スタンバイ・データベースにはレプリケートされません。REDOストリーム内に記録されたMODIFY_DATE列データがロジカル・スタンバイ・データベース内のデータと一致しないため、この表に対してこれ以降DMLを行うと、SQL Applyが停止します。
-
11.2 ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスの制御
SQLのALTER DATABASE GUARD文は、ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスを制御します。
デフォルトでは、ロジカル・スタンバイ・データベースについてはデータベース・ガードがALLに設定されています。
ALTER DATABASE GUARD文では、次のキーワードを使用できます。
-
ALLALLを指定すると、SYS以外のすべてのユーザーが、ロジカル・スタンバイ・データベース内のデータを変更できなくなります。 -
STANDBYSTANDBYを指定すると、SYS以外のすべてのユーザーが、SQL Applyでメンテナンスされる表または順序に対してDMLおよびDDLを変更できなくなります。 -
なしNONEを指定すると、データベース内の全データには通常のセキュリティが適用されます。
たとえば、SQL Applyによってメンテナンスされない表をユーザーが変更できるようにするには、次の文を使用します。
SQL> ALTER DATABASE GUARD STANDBY;
権限を持つユーザーは、ALTER SESSION DISABLE GUARDおよびALTER SESSION ENABLE GUARD文をそれぞれ使用して、現在のセッションでデータベース・ガードを一時的にオフまたはオンにできます。この文は、Oracle9iと同じ機能を実行するDBMS_LOGSTDBY.GUARD_BYPASS PL/SQLプロシージャを配置します。ALTER SESSION [ENABLE|DISABLE] GUARD文は、「ロジカル・スタンバイ・データベースの変更」に説明されているように、データベース・ガードを一時的に無効にしてデータベースを変更するときに役立ちます。
ノート:
データベース・ガードが無効のときに、プライマリおよびロジカル・スタンバイ・データベースの内容に相違を生じさせないようにしてください。
11.3 ロジカル・スタンバイ・データベースの管理および監視関連のビュー
パフォーマンス・ビューを使用して、ロジカル・スタンバイ・データベースを保守するSQL Applyの動作を監視できます。
次の各トピックでは、ロジカル・スタンバイ・データベースの監視に使用できる主なビューについて説明します。
関連項目:
ビューの詳細な参照情報は、『Oracle Databaseリファレンス』を参照してください。
11.3.1 DBA_LOGSTDBY_EVENTSビュー
DBA_LOGSTDBY_EVENTSビューには、SQL Apply操作中に発生した重要なイベントが記録されます。
デフォルトでは、最新の10,000のイベントが記録されます。ただし、記録されるイベントの数は、PL/SQLプロシージャDBMS_LOGSTDBY.APPLY_SET()をコールして変更できます。SQL Applyが突然停止した場合は、このビューにその原因も記録されます。
ノート:
SQL Applyを停止させたエラーはイベント・テーブル内に記録されます。このイベントはALERT.LOGファイルにも記録され、テキスト内にLOGSTDBYキーワードが含まれます。ビューの問合せの際に、EVENT_TIME_STAMP、COMMIT_SCN、およびCURRENT_SCNによって列を順番に選択し、イベントの順序を正しく並べます。
このビューは、適用されたDDLトランザクションやスキップされたDDLトランザクションなどの他の情報も表示されるようにカスタマイズできます。次に例を示します。
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS'; Session altered. SQL> COLUMN STATUS FORMAT A60 SQL> SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS - > ORDER BY EVENT_TIMESTAMP, COMMIT_SCN, CURRENT_SCN; EVENT_TIME STATUS ------------------------------------------------------------------------------ EVENT ------------------------------------------------------------------------------- 23-JUL-02 18:20:12 ORA-16111: log mining and apply setting up 23-JUL-02 18:25:12 ORA-16128: User initiated shut down successfully completed 23-JUL-02 18:27:12 ORA-16112: log mining and apply stopping 23-JUL-02 18:55:12 ORA-16128: User initiated shut down successfully completed 23-JUL-02 18:57:09 ORA-16111: log mining and apply setting up 23-JUL-02 20:21:47 ORA-16204: DDL successfully applied create table hr.test_emp (empno number, ename varchar2(64)) 23-JUL-02 20:22:55 ORA-16205: DDL skipped due to skip setting create database link link_to_boston connect to system identified by change_on_inst 7 rows selected.
この問合せによって、SQL Applyが数回開始および停止したことがわかります。またDDLが適用され、スキップされたこともわかります。
11.3.2 DBA_LOGSTDBY_LOGビュー
DBA_LOGSTDBY_LOGビューには、SQL Applyで処理中のアーカイブ・ログに関する動的な情報が表示されます。
次に例を示します。
SQL> COLUMN DICT_BEGIN FORMAT A10; SQL> SET NUMF 99999999; SQL> SELECT FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS F_SCN#, - > NEXT_CHANGE# AS N_SCN#, TIMESTAMP, - > DICT_BEGIN AS BEG, DICT_END AS END, - > THREAD# AS THR#, APPLIED FROM DBA_LOGSTDBY_LOG - > ORDER BY SEQUENCE#; FILE_NAME SEQ# F_SCN N_SCN TIMESTAM BEG END THR# APPLIED ------------------------- ---- ------- ------- -------- --- --- --- --------- /oracle/dbs/hq_nyc_2.log 2 101579 101588 11:02:58 NO NO 1 YES /oracle/dbs/hq_nyc_3.log 3 101588 142065 11:02:02 NO NO 1 YES /oracle/dbs/hq_nyc_4.log 4 142065 142307 11:02:10 NO NO 1 YES /oracle/dbs/hq_nyc_5.log 5 142307 142739 11:02:48 YES YES 1 YES /oracle/dbs/hq_nyc_6.log 6 142739 143973 12:02:10 NO NO 1 YES /oracle/dbs/hq_nyc_7.log 7 143973 144042 01:02:11 NO NO 1 YES /oracle/dbs/hq_nyc_8.log 8 144042 144051 01:02:01 NO NO 1 YES /oracle/dbs/hq_nyc_9.log 9 144051 144054 01:02:16 NO NO 1 YES /oracle/dbs/hq_nyc_10.log 10 144054 144057 01:02:21 NO NO 1 YES /oracle/dbs/hq_nyc_11.log 11 144057 144060 01:02:26 NO NO 1 CURRENT /oracle/dbs/hq_nyc_12.log 12 144060 144089 01:02:30 NO NO 1 CURRENT /oracle/dbs/hq_nyc_13.log 13 144089 144147 01:02:41 NO NO 1 NO
BEGおよびEND列のYESエントリは、LogMinerディクショナリのビルドがログ・ファイル順序番号5で開始したことを示しています。最新のアーカイブREDOログ・ファイルは順序番号13で、01:02:41にロジカル・スタンバイ・データベースが受信しました。APPLIED列は、SQL ApplyがすべてのREDOをSCN 144057より前に適用したことを示しています。トランザクションが複数のアーカイブ・ログにまたがることがあるため、複数のアーカイブ・ログ・ファイルのAPPLIED列に、CURRENT値が現れることがあります。
11.3.3 V$DATAGUARD_STATSビュー
V$DATAGUARD_STATSビューには、ロジカル・スタンバイ・データベースのフェイルオーバー特性に関する情報が表示されます。
次の情報が含まれます。
-
フェイルオーバー時間(
apply finish time)適用終了時間は、受信済で未適用のREDOをすべて適用するために必要な見積時間です。見積りは、REDOを最大適用率で適用できるという前提に基づいています。残りのすべてのREDOの適用にかかる実際の時間は、REDOのタイプおよびREDOの適用率によって異なります。
-
ロジカル・スタンバイ・データベース内のコミット済データの最新性(
apply lag) -
障害時の潜在的なデータ損失(
transport lag)
例11-1 ロジカル・スタンバイ・データベースのV$DATAGUARD_STATSの内容
次の出力は、プライマリ・データベースから生成されたすべてのREDOを受信および適用したロジカル・スタンバイ・データベースからの出力です。
SQL> COL NAME FORMAT A20
SQL> COL VALUE FORMAT A12
SQL> COL UNIT FORMAT A30
SQL> SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS;
NAME VALUE UNIT
-------------------- ------------ ------------------------------
apply finish time +00 00:00:00 day(2) to second(1) interval
apply lag +00 00:00:00 day(2) to second(0) interval
transport lag +00 00:00:00 day(2) to second(0) interval
11.3.4 V$LOGSTDBY_PROCESSビュー
このビューには、次のように、SQL Apply関連の各種プロセスの現在の状態に関する情報が表示されます。
-
識別情報(
sid|serial#|spid) -
SQL Applyプロセス:
COORDINATOR、READER、BUILDER、PREPARER、ANALYZERまたはAPPLIER(type) -
プロセスの現行のアクティビティのステータス(
status_code|status) -
このプロセスで処理された最上位のREDOレコード(
high_scn)
次に例を示します。
SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE HIGH_SCN ----- ------- ----------- ---------------- ---------- 48 6 11074 COORDINATOR 7178242899 56 56 10858 READER 7178243497 46 1 10860 BUILDER 7178242901 45 1 10862 PREPARER 7178243295 37 1 10864 ANALYZER 7178242900 36 1 10866 APPLIER 7178239467 35 3 10868 APPLIER 7178239463 34 7 10870 APPLIER 7178239461 33 1 10872 APPLIER 7178239472 9 rows selected.
HIGH_SCN列は、READERプロセスが他のすべてのプロセスに先行することと、PREPARERおよびBUILDERプロセスが残りのプロセスに先行することを示しています。
SQL> COLUMN STATUS FORMAT A40 SQL> SELECT TYPE, STATUS_CODE, STATUS FROM V$LOGSTDBY_PROCESS; TYPE STATUS_CODE STATUS ---------------- ----------- ----------------------------------------- COORDINATOR 16117 ORA-16117: processing READER 16127 ORA-16127: stalled waiting for additional transactions to be applied BUILDER 16116 ORA-16116: no work available PREPARER 16116 ORA-16117: processing ANALYZER 16120 ORA-16120: dependencies being computed for transaction at SCN 0x0001.abdb440a APPLIER 16124 ORA-16124: transaction 1 13 1427 is waiting on another transaction APPLIER 16121 ORA-16121: applying transaction with commit SCN 0x0001.abdb4390 APPLIER 16123 ORA-16123: transaction 1 23 1231 is waiting for commit approval APPLIER 16116 ORA-16116: no work available
出力は、実行中のSQL Applyのスナップショットを示しています。マイニング側では、READERプロセスはさらに読み取れるように追加のメモリーが使用可能になるまで待機中で、PREPARERプロセスはREDOレコードの処理中、BUILDERプロセスに使用可能な作業はありません。適用側では、COORDINATORはAPPLIERプロセスにさらにトランザクションを割当中で、ANALYZERはSCN 7178241034で依存性を計算中、APPLIERの1つは使用可能な作業がなく、2つにはまだ満たされていない未処理の依存性があります。
関連項目:
出力例は「SQL Applyの進捗の監視」を参照してください。
11.3.5 V$LOGSTDBY_PROGRESSビュー
このビューには、次のように、SQL Applyの進捗に関する詳細情報が表示されます。
-
プライマリ・データベース上でコミットされた全トランザクションがロジカル・スタンバイ・データベースに適用されたSCNおよび時刻(
applied_scn,applied_time) -
再開時にSQL ApplyによるREDOレコードの読取りが開始されるSCNおよび時刻(
restart_scn,restart_time) -
ロジカル・スタンバイ・データベースで受信された最新REDOレコードのSCNおよび時刻(
latest_scn,latest_time) -
BUILDERプロセスにより処理された最新レコードのSCNおよび時刻(mining_scn,mining_time)
次に例を示します。
SQL> SELECT APPLIED_SCN, LATEST_SCN, MINING_SCN, RESTART_SCN - > FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN LATEST_SCN MINING_SCN RESTART_SCN ----------- ----------- ---------- ----------- 7178240496 7178240507 7178240507 7178219805
この出力は次のことを示しています。
-
SQL Applyにより、SCN 7178240496以前にコミットされた全トランザクションが適用されました。
-
ロジカル・スタンバイ・データベースで受信された最新REDOレコードは、SCN 7178240507で生成されました。
-
マイニング・コンポーネントにより、SCN 7178240507以前に生成された全REDOレコードが処理されました。
-
SQL Applyがなんらかの理由で停止されて再開されると、SCN 7178219805以降に生成されたREDOレコードのマイニングが開始されます。
SQL> ALTER SESSION SET NLS_DATE_FORMAT='yy-mm-dd hh24:mi:ss'; Session altered SQL> SELECT APPLIED_TIME, LATEST_TIME, MINING_TIME, RESTART_TIME - > FROM V$LOGSTDBY_PROGRESS; APPLIED_TIME LATEST_TIME MINING_TIME RESTART_TIME ----------------- ----------------- ----------------- ----------------- 05-05-12 10:38:21 05-05-12 10:41:53 05-05-12 10:41:21 05-05-12 10:09:30
この出力は次のことを示しています。
-
SQL Applyにより、時刻05-05-12 10:38:21以前にコミットされた全トランザクションが適用されました(
APPLIED_TIME)。 -
最後のREDOは、プライマリ・データベースで時刻05-05-12 10:41:53に生成されました(
LATEST_TIME)。 -
マイニング・エンジンにより、05-05-12 10:41:21以前に生成された全REDOレコードが処理されました(
MINING_TIME)。 -
SQL Applyの再開時には、05-05-12 10:09:30以後に生成されたREDOレコードのマイニングが開始されます。
関連項目:
出力例は「SQL Applyの進捗の監視」を参照してください。
11.3.6 V$LOGSTDBY_STATEビュー
このビューには、次のように、SQL Applyの現在の状態のシノプシスが表示されます。
-
プライマリ・データベースのDBID(
primary_dbid) -
SQL Applyに割り当てられているLogMinerセッションID(
session_id) -
SQL Applyがリアルタイムで適用中かどうか(
realtime_apply)
次に例を示します。
SQL> COLUMN REALTIME_APPLY FORMAT a15 SQL> COLUMN STATE FORMAT a16 SQL> SELECT * FROM V$LOGSTDBY_STATE; PRIMARY_DBID SESSION_ID REALTIME_APPLY STATE ------------ ---------- --------------- ---------------- 1562626987 1 Y APPLYING
この出力は、SQL Applyがリアルタイム適用モードで実行中で、現在はプライマリ・データベースから受信したREDOデータを適用中であり、プライマリ・データベースのDBIDが1562626987で、SQL Applyセッションに関連付けられているLogMinerセッションIDが1であることを示しています。
関連項目:
出力例は「SQL Applyの進捗の監視」を参照してください。
11.3.7 V$LOGSTDBY_STATSビュー
V$LOGSTDBY_STATSビューには、SQL Applyに関連する統計、現行の状態およびステータス情報が表示されます。SQL Applyが実行されていない場合、このビューからは1行も戻されません。このビューは、ロジカル・スタンバイ・データベースの下でのみ意味があります。
次に例を示します。
SQL> ALTER SESSION SET NLS_DATE_FORMAT='dd-mm-yyyy hh24:mi:ss'; Session altered SQL> SELECT SUBSTR(name, 1, 40) AS NAME, SUBSTR(value,1,32) AS VALUE FROM V$LOGSTDBY_STATS; NAME VALUE ---------------------------------------- -------------------------------- logminer session id 1 number of preparers 1 number of appliers 5 server processes in use 9 maximum SGA for LCR cache (MB) 30 maximum events recorded 10000 preserve commit order TRUE transaction consistency FULL record skipped errors Y record skipped DDLs Y record applied DDLs N record unsupported operations N realtime apply Y apply delay (minutes) 0 coordinator state APPLYING coordinator startup time 19-06-2007 09:55:47 coordinator uptime (seconds) 3593 txns received from logminer 56 txns assigned to apply 23 txns applied 22 txns discarded during restart 33 large txns waiting to be assigned 2 rolled back txns mined 4 DDL txns mined 40 CTAS txns mined 0 bytes of redo mined 60164040 bytes paged out 0 pageout time (seconds) 0 bytes checkpointed 4845 checkpoint time (seconds) 0 system idle time (seconds) 2921 standby redo logs mined 0 archived logs mined 5 gap fetched logs mined 0 standby redo log reuse detected 1 logfile open failures 0 current logfile wait (seconds) 0 total logfile wait (seconds) 2910 thread enable mined 0 thread disable mined 0 . 40 rows selected.
11.4 ロジカル・スタンバイ・データベースの監視
ロジカル・スタンバイ・データベースを使用するときは、SQL Applyの進捗を監視できます。また、ログ・ファイルを自動的に削除することもできます。
次のトピックを参照してください。
11.4.1 SQL Applyの進捗の監視
SQL Applyには、SQL Applyの初期化、ディクショナリ・ログの待機、LogMinerディクショナリのロード、(REDOデータの)適用、アーカイブのギャップ解消待ち、およびアイドルという6つの進捗状態があります。
図11-2はこれらの状態のフローを示しています。
次の各項では、それぞれの状態を詳細に説明します。
初期化中状態
ALTER DATABASE START LOGICAL STANDBY APPLY文を発行してSQL Applyを開始すると、初期化中状態になります。
SQL Applyの現在の状態を判断するには、V$LOGSTDBY_STATEビューを問い合せます。次に例を示します。
SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE; SESSION_ID STATE ---------- ------------- 1 INITIALIZING
SESSION_ID列は、SQL Applyにより作成された永続LogMinerセッションを示します。このセッションで、プライマリ・データベースで生成されたアーカイブREDOログ・ファイルがマイニングされます。
ディクショナリ・ログ待機中
SQL Applyは、初回の開始時に、REDOログ・ファイルで取得されたLogMinerディクショナリをロードする必要があります。SQL Applyは、LogMinerディクショナリのロードに必要なREDOデータをすべて受信するまで、WAITING FOR DICTIONARY LOGS状態にとどまります。
ディクショナリ・ロード中状態
ディクショナリ・ロード中状態は、しばらく継続する場合があります。大規模データベースでLogMinerディクショナリをロードするには、長時間かかることがあります。V$LOGSTDBY_STATEビューを問い合せると、ディクショナリのロード中は次の出力が戻されます。
SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE; SESSION_ID STATE ---------- ------------------ 1 LOADING DICTIONARY
LogMinerディクショナリが完全にロードされるまでに起動されるのは、COORDINATORプロセスとマイニング・プロセスのみです。したがって、この時点でV$LOGSTDBY_PROCESSを問い合せると、APPLIERプロセスは表示されません。次に例を示します。
SQL> SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE ------ --------- --------- --------------------- 47 3 11438 COORDINATOR 50 7 11334 READER 45 1 11336 BUILDER 44 2 11338 PREPARER 43 2 11340 PREPARER
V$LOGMNR_DICTIONARY_LOADビューを問い合せると、ディクショナリ・ロードの進捗に関する詳細情報を取得できます。ディクショナリ・ロードは、次の3つのフェーズで発生します。
-
LogMinerディクショナリのロードに関連するREDO変更を収集するために、関連アーカイブREDOログ・ファイルまたはスタンバイREDOログ・ファイルがマイニングされます。
-
変更が処理され、データベース内のステージング表にロードされます。
-
一連のDDL文が発行されて、LogMinerディクショナリ表がロードされます。
次に例を示します。
SQL> SELECT PERCENT_DONE, COMMAND -
> FROM V$LOGMNR_DICTIONARY_LOAD -
> WHERE SESSION_ID = (SELECT SESSION_ID FROM V$LOGSTDBY_STATE);
PERCENT_DONE COMMAND
------------- -------------------------------
40 alter table SYSTEM.LOGMNR_CCOL$ exchange partition
P101 with table SYS.LOGMNRLT_101_CCOL$ excluding
indexes without validation
PERCENT_DONEまたはCOMMAND列が長時間変化しない場合は、V$SESSION_LONGOPSビューを問い合せ、問題のDDLトランザクションの進捗を監視してください。
適用中状態
この状態では、SQL ApplyはLogMinerディクショナリの初期スナップショットを正常にロードしており、現在はロジカル・スタンバイ・データベースにREDOデータを適用中です。
SQL Applyの進捗の詳細情報を確認するには、次のようにV$LOGSTDBY_PROGRESSビューを問い合せます。
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS'; SQL> SELECT APPLIED_TIME, APPLIED_SCN, MINING_TIME, MINING_SCN - > FROM V$LOGSTDBY_PROGRESS; APPLIED_TIME APPLIED_SCN MINING_TIME MINING_SCN -------------------- ----------- -------------------- ----------- 10-JAN-2005 12:00:05 346791023 10-JAN-2005 12:10:05 3468810134
プライマリ・データベース上でAPPLIED_SCN(またはAPPLIED_TIME)以前に表示されるコミット済トランザクションは、すべてロジカル・スタンバイ・データベースに適用されています。マイニング・エンジンは、プライマリ・データベースでMINING_SCN(およびMINING_TIME)以前に生成されたREDOレコードをすべて処理しています。安定状態では、MINING_SCN(およびMINING_TIME)は常にAPPLIED_SCN(およびAPPLIED_TIME)よりも前の値を示します。
ギャップ待機中状態
この状態が発生するのは、SQL Applyが使用可能な全REDOレコードのマイニングと適用を完了し、RFSプロセスによる新規ログ・ファイル(または欠落しているログ・ファイル)のアーカイブを待機している場合です。
SQL> SELECT STATUS FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'READER'; STATUS ------------------------------------------------------------------------ ORA-16240: waiting for log file (thread# 1, sequence# 99)
アイドル状態
SQL Applyは、プライマリ・データベースで生成されたREDOをすべて適用し終わると、この状態になります。
11.4.2 ログ・ファイルの自動削除
外部アーカイブ・ログには、プライマリ・データベースから送信されたREDOが含まれています。
外部アーカイブ・ログの格納には次の2つの方法があります。
-
高速リカバリ領域に格納
-
高速リカバリ領域外のディレクトリに格納
高速リカバリ領域内に格納される外部アーカイブ・ログは、必ずSQL Applyによって管理されます。ログに含まれるすべてのREDOレコードは、ロジカル・スタンバイ・データベースでの適用後、DB_FLASHBACK_RETENTION_TARGETパラメータで指定された期間(DB_FLASHBACK_RETENTION_TARGETが指定されていない場合は1440分間)保持されます。高速リカバリ領域内に格納されている外部アーカイブ・ログの自動管理は上書きできません。
高速リカバリ領域内に格納されない外部アーカイブ・ログは、デフォルトではSQL Applyによって管理されます。自動管理下では、高速リカバリ領域内に格納されない外部アーカイブ・ログは、ログに含まれるすべてのREDOレコードがロジカル・スタンバイ・データベースで適用された後、LOG_AUTO_DEL_RETENTION_TARGETパラメータで指定された期間保持されます。高速リカバリ領域内に格納されない外部アーカイブ・ログの自動管理は、次のPL/SQLプロシージャを実行すると上書きできます。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');
ノート:
DBMS_LOGTSDBY.APPLY_SETプロシージャを使用してこのパラメータを設定します。LOG_AUTO_DEL_RETENTION_TARGETを明示的に指定しなかった場合、DB_FLASHBACK_RETENTION_TARGETがロジカル・スタンバイ・データベースにデフォルト設定され、DB_FLASHBACK_RETENTION_TARGETが設定されていない場合は、デフォルトの1440分に設定されます。
デフォルトの自動ログ削除機能を上書きする場合は、定期的に次のステップを実行してSQL Applyで不要になったアーカイブREDOログ・ファイルを識別し、削除します。
-
不要になったメタデータのロジカル・スタンバイ・セッションを消去するには、次のPL/SQL文を入力します。
SQL> EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;
この文では、不要になったアーカイブREDOログ・ファイルを表示する
DBA_LOGMNR_PURGED_LOGビューも更新されます。 -
DBA_LOGMNR_PURGED_LOGビューを問い合せて、削除できるアーカイブREDOログ・ファイルのリストを表示します。SQL> SELECT * FROM DBA_LOGMNR_PURGED_LOG; FILE_NAME ------------------------------------ /boston/arc_dest/arc_1_40_509538672.log /boston/arc_dest/arc_1_41_509538672.log /boston/arc_dest/arc_1_42_509538672.log /boston/arc_dest/arc_1_43_509538672.log /boston/arc_dest/arc_1_44_509538672.log /boston/arc_dest/arc_1_45_509538672.log /boston/arc_dest/arc_1_46_509538672.log /boston/arc_dest/arc_1_47_509538672.log
-
オペレーティング・システム固有のコマンドを使用して、問合せにより表示されたアーカイブREDOログ・ファイルを削除します。
11.5 ロジカル・スタンバイ・データベースのカスタマイズ
ロジカル・スタンバイ・データベースは、いくつかの方法でカスタマイズできます。これには、イベントのロギング、特定のスキーマ・オブジェクトに対する変更の防止、表の追加または再作成が含まれます。
次のトピックを参照してください。
11.5.1 DBA_LOGSTDBY_EVENTSビューでのイベントのロギングのカスタマイズ
DBA_LOGSTDBY_EVENTSビューは、SQL Applyの下で発生する重要な最新イベントを含む循環型ログとみなすことができます。
デフォルトでは、最新の10,000イベントがイベント・ビューに記録されます。ログに記録されるイベント数は、DBMS_LOGSTDBY.APPLY_SETプロシージャを起動して変更できます。たとえば、最新の100,000イベントを確実に記録するには、次の文を発行できます。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('MAX_EVENTS_RECORDED', '100000');
SQL Applyの停止原因となったエラーは、SYSTEM表領域に十分な領域があるかぎり、必ずDBA_LOGSTDBY_EVENTSビューに記録されます。これらのイベントは常にアラート・ファイルにも格納され、テキストにはLOGSTDBYというキーワードが含まれます。このビューを問い合せるときは、EVENT_TIME、COMMIT_SCN、CURRENT_SCNの順に列を選択してください。この順序によって、停止障害がビューの最後に表示されます。
次の例では、ビューに記録されるイベントを指定するDBMS_LOGSTDBYサブプログラムを示します。
例1: DDL文が適用されたかどうかを判断する
たとえば、適用済DDLトランザクションをDBA_LOGSTDBY_EVENTSビューに記録するには、次の文を発行します。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('RECORD_APPLIED_DDL', 'TRUE');例2: サポートされない操作がないかDBA_LOGSTDBY_EVENTSビューをチェックする
プライマリ・データベースで実行されていて、ロジカル・スタンバイ・データベースでサポートされないトランザクションに関する情報を取得するには、次の文を発行します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;SQL> EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
次に、サポートされない操作がないかDBA_LOGSTDBY_EVENTSビューをチェックします。通常、サポートされない表に対する操作は、SQL Applyによって警告なしで無視されます。しかし、ローリング・アップグレード中(スタンバイ・データベースが上位バージョンであり、下位バージョンのプライマリ・データベースによって生成されたREDOをマイニングしているとき)に、サポートされない操作をプライマリ・データベースに対して実行した場合、ロジカル・スタンバイ・データベースにスイッチオーバーされない可能性があります。Oracle Data Guardは、表ごとに1つ以上のサポートされない操作をDBA_LOGSTDBY_EVENTSビューに記録します。ローリング・アップグレードに関する詳細は、「SQL Applyを使用したOracle Databaseのアップグレード」を参照してください。
11.5.2 DBMS_LOGSTDBY.SKIPによる特定のスキーマ・オブジェクトに対する変更の防止
デフォルトでは、プライマリ・データベース内でサポートされる表は、すべてロジカル・スタンバイ・データベースで複製されます。
このデフォルト動作は、特定の表に対する変更の適用をスキップするルールを指定することで変更できます。たとえば、HR.EMPLOYEES表に対する変更を省略するには、特定の表に対するDML変更とDDL変更の適用を防止するルールを指定できます。次に例を示します。
11.5.3 DDL文のスキップ・ハンドラの設定
特定のDDL文をインターセプトして元のDDL文を別のDDL文で置き換えるプロシージャを作成できます。
たとえば、ロジカル・スタンバイ・データベース内のファイル・システムの編成がプライマリ・データベースとは異なる場合、DBMS_LOGSTDBY.SKIPプロシージャを作成し、ファイルを指定してDDLトランザクションを透過的に処理できます。
次のプロシージャでは、ファイル指定文字列に特定のネーミング規則を使用するかぎり、プライマリ・データベースとスタンバイ・データベース間で異なるファイル・システム編成を処理できます。
11.5.4 ロジカル・スタンバイ・データベースの変更
ロジカル・スタンバイ・データベースは、SQL文が適用されている間でもレポート・アクティビティに使用できます。
データベース・ガードはロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスを制御し、ALTER SESSION DISABLE GUARD文はデータベース・ガードをバイパスしてロジカル・スタンバイ・データベース内の表に対する変更を可能にするために使用します。
ノート:
ロジカル・スタンバイ・データベースを使用して、独自に他の表を作成すると同時にプライマリ・データベースからレプリケートされるデータを処理する他のアプリケーションをホスト管理するには、データベース・ガードをSTANDBYに設定する必要があります。このようなアプリケーションがシームレスに動作するには、PRESERVE_COMMIT_ORDERをTRUE(SQL Applyのデフォルト設定)に設定して実行する必要があります。(DBMS_LOGSTDBY PL/SQLパッケージのPRESERVE_COMMIT_ORDERパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。)
次のSQL文を発行して、データベース・ガードをSTANDBYに設定します。
SQL> ALTER DATABASE GUARD STANDBY;
このガード設定では、プライマリ・データベースからレプリケートされる表は、ユーザーによる変更から保護されますが、スタンバイ・データベースに作成された表は、ロジカル・スタンバイで実行されているアプリケーションで変更できます。
デフォルトでは、ロジカル・スタンバイ・データベースはデータベース・ガードがALL(最も限定的な設定)に設定されている状態で作動し、ユーザーはデータベースに対して変更を実行できません。データベース・ガードを無視して、ロジカル・スタンバイ・データベースを変更可能にするには、ALTER SESSION DISABLE GUARD文を実行します。権限を付与されているユーザーは、この文を発行して、現行のセッションでデータベース・ガードをオフにできます。
次の各項で、例を示します。これらの例では、データベース・ガードがALLまたはSTANDBYに設定されていると仮定しています。
11.5.4.1 ロジカル・スタンバイ・データベースでのDDLの実行
SQL Applyを介してメンテナンスされている表に制約を追加できます。
デフォルトでは、SYS権限を持つアカウントのみがデータベースを変更でき、データベース・ガードはALLまたはSTANDBYに設定されています。SYSDG、SYSTEMまたは権限を付与されている別のアカウントでログインした場合、最初はセッションに対するデータベース・ガードをバイパスしていないため、ロジカル・スタンバイ・データベースではDDL文を発行できません。
次の例は、SQL Applyを停止し、データベース・ガードをバイパスしてロジカル・スタンバイ・データベースでSQL文を実行した後、データベース・ガードを再び使用可能にする方法を示しています。この例では、部分一致の問合せを高速化するために、soundex索引がSCOTT.EMPのsurname列に追加されます。soundex索引をプライマリ・サーバーで保持すると、非常に高コストになる場合があります。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.
SQL> ALTER SESSION DISABLE GUARD;
PL/SQL procedure successfully completed.
SQL> CREATE INDEX EMP_SOUNDEX ON SCOTT.EMP(SOUNDEX(ENAME));
Table altered.
SQL> ALTER SESSION ENABLE GUARD;
PL/SQL procedure successfully completed.
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.
SQL> SELECT ENAME,MGR FROM SCOTT.EMP WHERE SOUNDEX(ENAME) = SOUNDEX('CLARKE');
ENAME MGR
---------- ----------
CLARK 7839
オラクル社では、データベース・ガードのバイパスが使用可能になっている間は、SQL Applyにより保守される表に対してDML操作を実行しないことをお薦めします。そうすることで、プライマリ・データベースとスタンバイ・データベース間で違いが生じ、ロジカル・スタンバイ・データベースをメンテナンスできないようになります。
11.5.4.2 SQL Applyでメンテナンスされていない表の変更
次の設定を行う必要があります。
-
DBMS_LOGSTDBY.SKIPプロシージャを実行して、アプリケーションによるデータの書込みを可能にする、ロジカル・スタンバイ・データベース上の表のセットを指定します。スキップされた表は、SQL Applyでメンテナンスされません。 -
スタンバイ表のみを保護するようにデータベース・ガードを設定します。
次の例では、レポートによって書込みが行われる表がプライマリ・データベース上にあると仮定しています。
この例では、SQL Applyを停止し、表をスキップした後、SQL Applyを再開しています。この操作によって、レポート生成アプリケーションは、HRのTESTEMP%に書き込みます。表はSQL Applyでメンテナンスされなくなります。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.
SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'SCHEMA_DDL',-
schema_name => 'HR', -
object_name => 'TESTEMP%');
PL/SQL procedure successfully completed.
SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','HR','TESTEMP%');
PL/SQL procedure successfully completed.
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.
SQL Applyでは、開始後に、新しく指定されてスキップ・ルールに追加された表について、スタンバイ・データベースのメタデータを更新する必要があります。SQL Applyによりメタデータが更新される前に、新しくスキップされる表を変更しようとすると失敗します。追加したばかりのSKIPルールがSQL Applyで正常に考慮されたかどうかは、次の問合せを発行すると確認できます。
SQL> SELECT VALUE FROM SYSTEM.LOGSTDBY$PARAMETERS WHERE NAME = 'GUARD_STANDBY'; VALUE --------------- Ready
VALUE列にReadyと表示される場合、SQL Applyではスキップされる表の関連メタデータがすべて正常に更新されており、その表を変更しても安全です。
11.5.5 ロジカル・スタンバイ・データベースでの表の追加または再作成
リカバリ不可能な操作が発生した場合は、一般にDBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャを使用して表を作成しなおします。
また、このプロシージャを使用して、以前はスキップしていた表に対してSQL Applyを使用可能にすることもできます。
表を作成する前に、「プライマリ・データベース内の表の行が一意に識別できることの確認」に記載されている要件を満たす必要があります。その後、次のステップに従って表HR.EMPLOYEESを再作成し、SQL Applyを再開できます。この手順は、プライマリ・データベースにアクセスするデータベース・リンクBOSTONが定義済であることを前提としています。
次のリストは、表を再作成し、その表に対してSQL Applyを再開する方法を示しています。
-
SQL Applyを停止します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
-
DBA_LOGSTDBY_SKIPビューを問い合せ、問題の表で操作がスキップされていないことを確認します。SQL> SELECT * FROM DBA_LOGSTDBY_SKIP; ERROR STATEMENT_OPT OWNER NAME PROC ----- ------------------- ------------- ---------------- ----- N SCHEMA_DDL HR EMPLOYEES N DML HR EMPLOYEES N SCHEMA_DDL OE TEST_ORDER N DML OE TEST_ORDER
ロジカル・スタンバイ・データベース上で再作成する表には、すでにスキップ・ルールが関連付けられているため、最初にそのルールを削除する必要があります。そのためには、
DBMS_LOGSTDBY.UNSKIPプロシージャをコールします。次に例を示します。SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', - > schema_name => 'HR', - > object_name => 'EMPLOYEES');
SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'SCHEMA_DDL', - > schema_name => 'HR', - > object_name => 'EMPLOYEES');
-
DBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャを使用し、ロジカル・スタンバイ・データベースの全データを使用して表HR.EMPLOYEESを再作成します。次に例を示します。SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE(schema_name => 'HR', - > table_name => 'EMPLOYEES', - > dblink => 'BOSTON');
-
SQL Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
関連項目:
DBMS_LOGSTDBY.UNSKIPおよびDBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
新規にインスタンス化された表とデータベースの残りの部分にまたがってビューの一貫性が得られるように、SQL Applyがプライマリ・データベースと一致するまで待機してから、この表を問い合せます。これを行うには、以下のステップに従います。
11.6 ロジカル・スタンバイ・データベースの下での特定のワークロードの管理
ロジカル・スタンバイの下で、特定のワークロードを管理できます。
次の各項を参照してください。
11.6.2 マテリアライズド・ビューの使用
ロジカル・スタンバイでは、マテリアライズド・ビューに関連した次のDDL文を自動的にスキップします。
たとえば、ロジカル・スタンバイでは、次の文がスキップされます。
-
CREATE、ALTERまたはDROP MATERIALIZED VIEW -
CREATE、ALTERまたはDROP MATERIALIZED VIEW LOG
ロジカル・スタンバイ・データベースの作成後にプライマリ・データベースで作成、変更または削除された新規マテリアライズド・ビューは、ロジカル・スタンバイ・データベースには反映されません。ただし、ロジカル・スタンバイ・データベースの作成前にプライマリ・データベースで作成されたマテリアライズド・ビューは、ロジカル・スタンバイ・データベースに存在します。
ロジカル・スタンバイでは、他の種類の補助データ構造に加えて、ロジカル・スタンバイ・データベースでの新規マテリアライズド・ビューのローカルな作成およびメンテナンスをサポートしています。たとえば、オンライン・トランザクション処理(OLTP)システムでは、高度に正規化された表を更新パフォーマンスに頻繁に使用しますが、これらの表により、複雑な意思決定支援の問合せに対するレスポンス時間が長くなることがあります。ロジカル・スタンバイ・データベースでより効率的な問合せが作成できるように、次のようにして、レプリケートされたデータを非正規化するマテリアライズド・ビューを作成できます(これらの文を発行する前にユーザーSYSとして接続してください)。
SQL> ALTER SESSION DISABLE GUARD; SQL> CREATE MATERIALIZED VIEW LOG ON SCOTT.EMP - > WITH ROWID (EMPNO, ENAME, MGR, DEPTNO) INCLUDING NEW VALUES; SQL> CREATE MATERIALIZED VIEW LOG ON SCOTT.DEPT - > WITH ROWID (DEPTNO, DNAME) INCLUDING NEW VALUES; SQL> CREATE MATERIALIZED VIEW SCOTT.MANAGED_BY - > REFRESH ON DEMAND - > ENABLE QUERY REWRITE - > AS SELECT E.ENAME, M.ENAME AS MANAGER - > FROM SCOTT.EMP E, SCOTT.EMP M WHERE E.MGR=M.EMPNO; SQL> CREATE MATERIALIZED VIEW SCOTT.IN_DEPT - > REFRESH FAST ON COMMIT - > ENABLE QUERY REWRITE - > AS SELECT E.ROWID AS ERID, D.ROWID AS DRID, E.ENAME, D.DNAME - > FROM SCOTT.EMP E, SCOTT.DEPT D WHERE E.DEPTNO=D.DEPTNO;
ロジカル・スタンバイ・データベースの場合
-
トランザクションのコミットが発生すると、ロジカル・スタンバイ・データベースのON-COMMITマテリアライズド・ビューが自動的にリフレッシュされます。
-
ON-DEMANDマテリアライズド・ビューは自動的にリフレッシュされません。リフレッシュするには、
DBMS_MVIEW.REFRESHプロシージャを実行する必要があります。
たとえば、次のコマンドを発行すると、前の例で作成されたON-DEMANDマテリアライズド・ビューがリフレッシュされます。
SQL> ALTER SESSION DISABLE GUARD; SQL> EXECUTE DBMS_MVIEW.REFRESH (LIST => 'SCOTT.MANAGED_BY', METHOD => 'C');
DBMS_SCHEDULERジョブを使用して定期的にオンデマンドでマテリアライズされたビューをリフレッシュする場合は、データベース・ガードをSTANDBYに設定しておく必要があります。(ALTER SESSION DISABLE GUARD文をPL/SQLブロック内で使用しても、効果がありません。)
11.6.3 ロジカル・スタンバイ・データベースでのトリガーと制約の処理方法
デフォルトでは、トリガーと制約はロジカル・スタンバイ・データベースで自動的に使用可能になり、処理されます。
SQL Applyでメンテナンスされる表にトリガーおよび制約がある場合:
-
制約: CHECK制約はプライマリ・データベースで評価されます。ロジカル・スタンバイ・データベースでの再評価は不要です。
-
トリガー: プライマリ・データベースで実行されたトリガーの影響は、スタンバイ・データベースでログに記録され、適用されます。
SQL Applyでメンテナンスされない表にトリガーおよび制約がある場合:
-
制約は評価されます
-
トリガーは発行されます
11.6.4 サポートされていない表のレプリケートでのトリガーの使用
表で作成されたDMLトリガーは、DBMS_DDL.SET_TRIGGER_FIRING_PROPERTYのfire_onceパラメータをTRUEにデフォルト設定します。
トリガーはユーザー・プロセスが変更された場合にのみ起動されます。SQL Applyプロセス内では自動的に無効化されるため、SQL Applyプロセスが表を変更しても起動されません。SQL Applyプロセスが保持している表に変更を加えた際に、トリガーを起動する方法が2つあります。
-
トリガーの
fire_onceパラメータをFALSEに設定します。ユーザー・プロセスとSQL Applyプロセスのどちらにも対応して起動できるようになります。 -
apply_server_onlyパラメータをTRUEに設定します。こうすると、トリガーはSQL Applyプロセスに対応してのみ起動し、ユーザー・プロセスに対応しては起動しません。
| fire_once | apply_server_only | 説明 |
|---|---|---|
|
|
|
DMLトリガーのデフォルトのプロパティ設定です。ユーザー・プロセスによって実表が変更された場合のみトリガーが起動します。 |
|
|
|
トリガーは、実表を変更するユーザー・プロセスのコンテキストおよびSQL Applyプロセスのコンテキストで起動します。2つのコンテキストは、 |
|
|
|
SQL Applyプロセスによって実表が変更された場合のみトリガーが起動します。トリガーは、ユーザー・プロセスによって実表が変更される場合は起動しません。そのため、 |
単純なオブジェクト型の列のためにサポートされない表をレプリケートするには、SQL Applyプロセスに対応して起動するトリガーを作成します(トリガーのfire_onceパラメータをFALSEに設定するか、トリガーのapply_server_onlyパラメータをTRUEに設定します)。通常のDMLトリガーをプライマリ・データベースで使用して、オブジェクト型を、サポート可能な表にフラット化できます。ロジカル・スタンバイのSQL Applyプロセスに対応して起動するトリガーによって、オブジェクト型が再作成され、サポートされない表がトランザクション方式で更新されます。
関連項目:
-
DBMS_DDL.SET_TRIGGER_FIRING_PROPERTYプロシージャとDBMS_LOGSTDBY.IS_APPLY_SERVER関数の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
次の例では、トリガーを使用して簡単なオブジェクト型の表をレプリケートする方法を示します。この例では挿入の処理方法を示しています。同じ原理で更新および削除も行えます。ネストされた表とVARRAYも、ネストされたデータの正規化を行うループを追加すれば、この方法でレプリケートすることができます。
-- simple object type
create or replace type Person as object
(
FirstName varchar2(50),
LastName varchar2(50),
BirthDate Date
)
-- unsupported object table
create table employees
(
IdNumber varchar2(10) ,
Department varchar2(50),
Info Person
)
-- supported table populated via trigger
create table employees_transfer
(
t_IdNumber varchar2(10),
t_Department varchar2(50),
t_FirstName varchar2(50),
t_LastName varchar2(50),
t_BirthDate Date
)
--
-- create this trigger to flatten object table on the primary
-- this trigger will not fire on the standby
--
create or replace trigger flatten_employees
after insert on employees for each row
declare
begin
insert into employees_transfer
(t_IdNumber, t_Department, t_FirstName, t_LastName, t_BirthDate)
values
(:new.IdNumber, :new.Department,
:new.Info.FirstName,:new.Info.LastName, :new.Info.BirthDate);
end
--
-- Option#1 (Better Option: Create a trigger and
-- set its apply-server-only property to TRUE)
-- create this trigger at the logical standby database
-- to populate object table on the standby
-- this trigger only fires when apply replicates rows
-- to the standby
--
create or replace trigger reconstruct_employees_aso
after insert on employees_transfer for each row
begin
insert into employees (IdNumber, Department, Info)
values (:new.t_IdNumber, :new.t_Department,
Person(:new.t_FirstName, :new.t_LastName, :new.t_BirthDate));
end
-- set this trigger to fire from the apply server
execute dbms_ddl.set_trigger_firing_property( -
trig_owner => 'scott', -
trig_name => 'reconstruct_employees_aso',
property => dbms_ddl.apply_server_only,
setting => TRUE);
--
-- Option#2 (Create a trigger and set
-- its fire-once property to FALSE)
-- create this trigger at the logical standby database
-- to populate object table on the standby
-- this trigger will fire when apply replicates rows to -- the standby, but we will need to make sure we are
-- are executing inside a SQL Apply process by invoking
-- dbms_logstdby.is_apply_server function
--
create or replace trigger reconstruct_employees_nfo
after insert on employees_transfer for each row
begin
if dbms_logstdby.is_apply_server() then
insert into employees (IdNumber, Department, Info)
values (:new.t_IdNumber, :new.t_Department,
Person(:new.t_FirstName, :new.t_LastName, :new.t_BirthDate));
end if;
end
-- set this trigger to fire from the apply server
execute dbms_ddl.set_trigger_firing_property( -
trig_owner => 'scott', -
trig_name => 'reconstruct_employees_nfo',
property => dbms_ddl.fire_once,
setting => FALSE);11.6.5 プライマリでのPoint-in-Timeリカバリの実行によるリカバリ
ロジカル・スタンバイ・データベースがREDOデータの新規ブランチを受信すると、SQL Applyではそれが自動的に使用されます。
ロジカル・スタンバイ・データベースの場合、スタンバイ・データベースにより新規リセットログのSCNより後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されていなければ、手動による介入は必要ありません。
次の表に、スタンバイ・データベースとプライマリ・データベースのブランチを再同期化する方法を示します。
| スタンバイ・データベースの状態 . . | 操作 . . | 実行するステップ . . |
|---|---|---|
|
新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されていない場合。 |
SQL Applyは、自動的にREDOデータの新規ブランチを使用します。 |
手動による介入は必要ありません。SQL Applyは、自動的にスタンバイ・データベースをREDOデータの新規ブランチと再同期化します。 |
|
新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっている場合。 |
スタンバイ・データベースは、REDOデータの将来の新規ブランチでリカバリされます。 |
SQL Applyは、自動的にスタンバイ・データベースを新規ブランチと再同期化します。 |
|
新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっていない場合。 |
指定のプライマリ・データベース・ブランチで、プライマリ・データベースとスタンバイの内容にずれが生じます。 |
「ロジカル・スタンバイ・データベースの作成」の手順に従ってロジカル・スタンバイ・データベースを再作成します。 |
|
REDOデータの前のブランチの終わりからアーカイブREDOログ・ファイルが欠落している場合。 |
SQL Applyは欠落しているログ・ファイルが取得されるまで続行できません。 |
前のブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。 |
データベース・インカネーション、OPEN RESETLOGSによるリカバリ、フラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
11.6.6 ロジカル・スタンバイ・データベースでのOracle Streams取得プロセスの実行
Oracle Streams取得プロセスをロジカル・スタンバイ・データベースで実行すると、ロジカル・スタンバイ・データベースに存在するすべての表(ローカル表またはプライマリ・データベースからレプリケートされているメンテナンス対象の表)の変更を取得できます。
メンテナンス対象の表の変更を取得するときは、Oracle Streams取得プロセスをプライマリ・データベースに対して実行する場合に比べると時間がかかります。時間が長くなるのは、ロジカル・スタンバイで実行しているとき、Oracle Streams取得プロセスは変更がプライマリからロジカル・スタンバイに転送され、SQL Applyによって適用されるのを待機する必要があるためです。ほとんどの場合、リアルタイム適用を実行していれば、数秒以上かかることはありません。
Oracle Streamsの取得プロセスは作成されたデータベースに関連付けられています。データベースのロールは関係ありません。たとえば、Bostonという名前のプライマリ・データベース、およびLondonという名前のロジカル・スタンバイがあると仮定します。ロール・トランジション時に、Oracle Streamsの取得プロセスを1つのデータベースから、別なデータベースに移動することはできません。たとえばLondonがロジカル・スタンバイのときに、Oracle Streamsの取得プロセスを作成した場合、スイッチオーバーやフェイルオーバーなどのロール・トランジションによって、Londonがプライマリになったとしても、London上に残ります。ロール・トランジション後もOracle Streamsの取得プロセスを継続するためには、次のようなロール・トランジション・トリガーを書く必要があります。
create or replace trigger streams_aq_job_role_change1
after DB_ROLE_CHANGE on database
declare
cursor capture_aq_jobs is
select job_name, database_role
from dba_scheduler_job_roles
where job_name like 'AQ_JOB%';
u capture_aq_jobs%ROWTYPE;
my_db_role varchar2(16);
begin
if (dbms_logstdby.db_is_logstdby() = 1) then my_db_role := 'LOGICAL STANDBY';
else my_db_role := 'PRIMARY';
end if;
open capture_aq_jobs;
loop
fetch capture_aq_jobs into u;
exit when capture_aq_jobs%NOTFOUND;
if (u.database_role != my_db_role) then
dbms_scheduler.set_attribute(u.job_name,
'database_role',
my_db_role);
end if;
end loop;
close capture_aq_jobs;
exception
when others then
begin
raise;
end;
end;11.7 ロジカル・スタンバイ・データベースのチューニング
次の各項では、ロジカル・スタンバイ・データベースをチューニングする様々な方法について説明します。
11.7.1 主キーRELY制約の作成
プライマリ・データベースで、表に主キーまたは一意索引がなく、実際には一意である行がわかっている場合は、主キーのRELY制約を作成します。
ロジカル・スタンバイ・データベースでは、主キーを構成する列に索引を作成します。次の問合せは、ロジカル・スタンバイ・データベースで行を一意に識別するために適用できる索引情報がない表のリストを生成します。次の表に索引を作成することによって、パフォーマンスが大幅に向上する可能性があります。
SQL> SELECT OWNER, TABLE_NAME FROM DBA_TABLES -
> WHERE OWNER NOT IN (SELECT OWNER FROM DBA_LOGSTDBY_SKIP -
> WHERE STATEMENT_OPT = 'INTERNAL SCHEMA') -
> MINUS -
> SELECT DISTINCT TABLE_OWNER, TABLE_NAME FROM DBA_INDEXES -
> WHERE INDEX_TYPE NOT LIKE ('FUNCTION-BASED%') -
> MINUS -
> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED;プライマリ・データベースの表に主キーのRELY制約を追加する手順は、次のとおりです。
11.7.2 コストベース・オプティマイザの統計の収集
コストベース・オプティマイザ(CBO)で最適の問合せ実行パスを判別するために使用されるため、スタンバイ・データベースで統計を収集する必要があります。
以前の統計情報が正確でなくなるような変更をスキーマ・オブジェクトのデータまたは構造に対して実行した場合は、その後に新しい統計を収集してください。たとえば、多数の行を表に挿入または削除した後は、行数に関する新しい統計を収集します。
プライマリ・データベースでのDMLおよびDDL操作はワークロードの機能として実行されるため、統計はスタンバイ・データベースで収集してください。スタンバイ・データベースがプライマリ・データベースと論理的に等しい場合、SQL Applyではワークロードを異なる方法で実行する場合があります。そのため、ロジカル・スタンバイ・データベースでSTATSパッケージおよびV$SYSSTATビューを使用すると、リソースおよび表スキャンを最も多く使用している表を判断する際に役立ちます。
11.7.3 プロセス数の調整
SQL Applyに割り当てられるプロセス数を制御するために変更できるパラメータには、MAX_SERVERS、APPLY_SERVERSおよびPREPARE_SERVERSの3つがあります。
常に、次の関係に該当する必要があります。
-
APPLY_SERVERS + PREPARE_SERVERS =MAX_SERVERS - 3これは、SQL Applyが常に
READER、BUILDER、ANALYZERの各ロールに対して1つずつプロセスを割り当てるためです。 -
デフォルトでは、
MAX_SERVERSは9に、PREPARE_SERVERSは1に、APPLY_SERVERSは5に設定されます。 -
DBMS_LOGSTDBY.APPLY_SETプロシージャを使用してMAX_SERVERSパラメータのみを変更し、SQL Applyでサーバー・プロセスを準備プロセスと適用プロセスの間に適当に分散できようにすることをお薦めします。 -
SQL Applyではプロセス割当てアルゴリズムを使用して、
MAX_SERVERで指定されるように、SQL Applyに割り当てられる20サーバー・プロセスごとに1つのPREPARE_SERVERを割り当て、PREPARE_SERVERSの数を5に制限します。そのため、MAX_SERVERSを1から20の任意の値に設定すると、SQL ApplyはPREPARERとして機能するようにサーバー・プロセスを1つ割り当て、残りのプロセスをAPPLIERとして割り当てて前述の関係を満たします。同様に、MAX_SERVERSを21から40の値に設定すると、SQL ApplyはPREPARERSとして機能するようにサーバー・プロセスを2つ割り当て、残りをAPPLIERSとして割り当てて前述の関係を満たします。この内部プロセス割当てアルゴリズムは、前述の関係を満たしているならば、APPLY_SERVERSおよびPREPARE_SERVERSを直接設定することで上書きできます。
この項では、次の項目について説明します。
11.7.3.1 APPLIERプロセス数の調整
APPLIERプロセスの数を調整する前に、その調整でスループットを改善できるかどうか判断する必要があります。
これを決定するには、次のステップを実行します:
11.7.3.2 PREPARERプロセス数の調整
PREPARERプロセスの数の調整が必要になることは、まれです。その数を増やす前に、一定の条件が満たされていることを確認する必要があります。
trueになる必要がある条件は、次のとおりです。
-
すべての
PREPARERプロセスがビジーである。 -
適用準備が完了しているトランザクションの数が、使用可能な
APPLIERプロセスの数よりも少ない。 -
アイドル状態の
APPLIERプロセスがある。
前述の条件に該当しているかどうかを判断するステップは、次のとおりです。
この例では、PREPARERプロセス数の増加に必要な3つの条件がすべて満たされています。APPLIERプロセス数の設定を20のままにし、PREPARERプロセス数を1から3に増やすとします。これは、常に次の等式を満たす必要があるためです。
APPLY_SERVERS + PREPARE_SERVERS = MAX_SERVERS - 3
まず、増加後のPREPARERプロセス数に対応するように、MAX_SERVERSの数を24から26に増やす必要があります。次に、PREPARERプロセス数を次のようにして増やすことができます。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS', 26);
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS', 3);11.7.4 LCRキャッシュ用メモリーの調整
ある程度のワークロードの場合、SQL Applyは多数のページアウト操作を使用することがあるため、システム全体のスループットが低下します。LCRキャッシュに割り当てられるメモリーを増やすと、改善する可能性があります。
LCRキャッシュに割当済のメモリーを増やした場合にスループットを改善できるかどうかを確認するステップは、次のとおりです。
ページアウト・アクティビティによる消費量が稼働時間全体の5%以下であれば理想的です。間隔を長くして引き続きスナップショットを取得し、ページアウト・アクティビティが引き続き適用時間の大部分を占めていることがわかった場合は、メモリー・サイズを大きくするとスループットが改善される可能性があります。SQL Applyに割当済のメモリーは、LCRキャッシュに割り当てられるメモリーを設定する(この例ではSGAを1GBに設定)と増やすことができます。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 1024);
PL/SQL procedure successfully completed11.7.5 ロジカル・スタンバイ・データベースにおけるトランザクションの適用方法の調整
デフォルトでは、トランザクションは、プライマリ・データベースでコミットされた順序に正確に従って、ロジカル・スタンバイ・データベースに適用されます。
厳密なデフォルト順序でのトランザクションのコミットにより、アプリケーションをロジカル・スタンバイ・データベースで透過的に実行できます。
ただし、多くのアプリケーションでは、すべてのトランザクションの間でそのような厳密な順序が必要なわけではありません。そのようなアプリケーションでは、オーバーラップしない一連の行を含むトランザクションを、プライマリ・データベースでコミットしたときと同じ順序でコミットする必要がありません。一般に、厳密でない順序により、ロジカル・スタンバイ・データベースでの適用率は高くなります。次のステップで、トランザクションをコミットするデフォルトの順序を変更できます。
-
SQL Applyを停止します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered
-
次の文を発行して、プライマリ・データベースでコミットされた順序と異なる順序でトランザクションを適用できるようにします。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER', 'FALSE'); PL/SQL procedure successfully completed -
SQL Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered
次のように適用モードを元に戻せます。
11.8 ロジカル・スタンバイ・データベースの下でのバックアップおよびリカバリ
ロジカル・スタンバイ・データベースは、従来の方法を使用してバックアップでき、データベース・バックアップをリストアしてアーカイブ・ログに対してメディア・リカバリを実行すると、バックアップと同時にリカバリができます。
次の各項目は、ロジカル・スタンバイ・データベースの場合に該当します。
RMANのローカル・リカバリ・カタログの作成および使用時の考慮事項
RMANのリカバリ・カタログを作成する、またはカタログを変更するRMANのアクティビティを実行する場合、ロジカル・スタンバイ・データベースでは、GUARDをSTANDBYに設定して実行する必要があります。
ローカル・リカバリ・カタログがロジカル・スタンバイ制御ファイルにのみ保持されている場合は、GUARDをALLに設定したままにできます。
制御ファイルのバックアップに関する考慮事項
ロジカル・スタンバイ・データベースのインスタンス化の直後に、制御ファイルのバックアップを取得することをお薦めします。
Point-in-Timeリカバリに関する考慮事項
Point-in-Timeリカバリの後に初めてSQL Applyが開始されるとき、必要なアーカイブ・ログをローカル・システムで検出するか、プライマリ・データベースからフェッチできる必要があります。V$LOGSTDBY_PROCESSビューを使用して、アーカイブ・ログをプライマリ・データベースでリストアする必要があるかどうかを判断します。
表領域のPoint-in-Timeリカバリに関する考慮事項
ロジカル・スタンバイ・データベースの表領域に対してPoint-in-Timeリカバリを実行する場合、次のいずれかを実行する必要があります。
-
表領域にSQL Applyプロセスでメンテナンスされている表またはパーティションが含まれないことを確認する。
-
表領域にSQL Applyプロセスでメンテナンスされている表またはパーティションが含まれる場合は、ロジカル・スタンバイ・データベースで、
DBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャを使用して、リカバリされる表領域に含まれるメンテナンス対象の表をすべて再度インスタンス化するか、またはDBMS_LOGSTDBY.SKIPプロシージャを使用してリカバリされる表領域に含まれる表をすべて登録し、メンテナンス対象の表のリストからスキップされるようにする。