ロジカル・スタンバイ・データベースの管理方法の詳細は、次の各項を参照してください。
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プロセスには影響ありません。
この項は、次の項目で構成されています。
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のメモリー使用量に応じて決定します。
LCRキャッシュのメモリーがすべて使用され、SQL Applyを進行させるために領域の解放が必要になると、SQL Applyのコンテキスト内でページアウトが発生します。
たとえば、LCRキャッシュに100MBのメモリーが割り当てられている場合に、SQL Applyでサイズが300MBのLONG
列を含む表に対するINSERT
トランザクションが検出されるとします。この場合、ログ・マイニング・コンポーネントは、LONG
データの最初の部分をページアウトして列変更の後半部分を読み取ります。適切にチューニングされているロジカル・スタンバイ・データベースの場合、ページアウト・アクティビティはほとんど発生せず、システム全体のスループットには影響しません。
関連項目:
問題のあるページアウトを識別して修正処理を実行する方法の詳細は、「ロジカル・スタンバイ・データベースのカスタマイズ」を参照してください。
トランザクションのコミット・レコードが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
が中断します。
SQL Applyがロジカル・スタンバイ・データベースのスループットと待機時間に影響するDMLトランザクションを適用する場合、次の特性があります。
1つの文で複数の行が変更されるバッチ更新または削除をプライマリ・データベースで実行した場合、ロジカル・スタンバイ・データベースでは行の個別変更として適用されます。そのため、メンテナンスされている各表に一意索引または主キーが必要になります。詳細は、「プライマリ・データベース内の表の行が一意に識別できることの確認」を参照してください。
プライマリ・データベースで実行されたダイレクト・パス・インサートは、ロジカル・スタンバイ・データベースで従来型のINSERT
文を使用して適用されます。
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 COLUMN
DDLがこの更新トリガーを起動し、表内のすべての行のMODIFY_DATE
列を新しいタイムスタンプに変更します。MODIFY_DATE
列へのこの種の変更は、ロジカル・スタンバイ・データベースにはレプリケートされません。REDOストリーム内に記録されたMODIFY_DATE
列データがロジカル・スタンバイ・データベース内のデータと一致しないため、この表に対してこれ以降DMLを行うと、SQL Applyが停止します。
SQLのALTER DATABASE GUARD
文は、ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスを制御します。デフォルトでは、ロジカル・スタンバイ・データベースについてはデータベース・ガードがALL
に設定されています。
ALTER DATABASE GUARD
文では、次のキーワードを使用できます。
ALL
ALL
を指定すると、SYS
以外のすべてのユーザーが、ロジカル・スタンバイ・データベース内のデータを変更できなくなります。
STANDBY
STANDBY
を指定すると、SYS
以外のすべてのユーザーが、SQL Applyでメンテナンスされる表または順序に対してDMLおよびDDLを変更できなくなります。
NONE
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
文は、「ロジカル・スタンバイ・データベースの変更」に説明されているように、データベース・ガードを一時的に無効にしてデータベースを変更するときに役立ちます。
注意:
データベース・ガードが無効のときに、プライマリおよびロジカル・スタンバイ・データベースの内容に相違を生じさせないようにしてください。
次のパフォーマンス・ビューでは、ロジカル・スタンバイ・データベースを保守するSQL Applyの動作が監視されます。次の各項では、ロジカル・スタンバイ・データベースの監視に使用できる主なビューについて説明します。
関連項目:
ビューの詳細な参照情報は、『Oracle Databaseリファレンス』を参照してください。
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が適用され、スキップされたこともわかります。
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
値が現れることがあります。
このビューには、ロジカル・スタンバイ・データベースのフェイルオーバー特性に関連する次のような情報が表示されます。
フェイルオーバー時間(apply finish time
)
ロジカル・スタンバイ・データベース内のコミット済データの最新性(apply lag
)
障害時の潜在的なデータ損失(transport lag
)
次に例を示します。
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
この出力は、プライマリ・データベースから生成されたすべてのREDOを受信および適用したロジカル・スタンバイ・データベースからの出力です。
このビューには、次のように、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の進捗の監視」を参照してください。
このビューには、次のように、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の進捗の監視」を参照してください。
このビューには、次のように、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の進捗の監視」を参照してください。
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.
この項は、次の項目で構成されています。
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をすべて適用し終わると、この状態になります。
外部アーカイブ・ログには、プライマリ・データベースから送信された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ログ・ファイルを削除します。
この項は、次の項目で構成されています。
関連項目:
『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_LOGSTDBY
パッケージ
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のアップグレード」を参照してください。
デフォルトでは、プライマリ・データベース内でサポートされる表は、すべてロジカル・スタンバイ・データベースで複製されます。このデフォルト動作は、特定の表に対する変更の適用をスキップするルールを指定することで変更できます。たとえば、HR.EMPLOYEES
表に対する変更を省略するには、特定の表に対するDML変更とDDL変更の適用を防止するルールを指定できます。次に例を示します。
ロジカル・スタンバイ・データベースは、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
に設定されていると仮定しています。
この項では、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操作を実行しないことをお薦めします。そうすることで、プライマリ・データベースとスタンバイ・データベース間で違いが生じ、ロジカル・スタンバイ・データベースをメンテナンスできないようになります。
場合によっては、レポート・アプリケーションを使用してサマリー結果を収集し、一時的に保存し、レポートの実行回数を追跡する必要があります。この種のアプリケーションの主な目的はレポート・アクティビティですが、アプリケーションはロジカル・スタンバイ・データベースに対してDML(挿入、更新、および削除)操作を実行しなければならない場合があります。表の作成または削除が必要になることもあります。
データが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ではスキップされる表の関連メタデータがすべて正常に更新されており、その表を変更しても安全です。
関連項目:
「ロジカル・スタンバイ・データベースがサポートしているDDL文」、および『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_LOGSTDBY
パッケージ
リカバリ不可能な操作が発生した場合は、一般に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がプライマリ・データベースと一致するまで待機してから、この表を問い合せます。手順は次のとおりです。
この項は、次の項目で構成されています。
ロジカル・スタンバイでは、マテリアライズド・ビューに関連した次の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ブロック内で使用しても、効果がありません。)
デフォルトでは、トリガーと制約はロジカル・スタンバイ・データベースで自動的に使用可能になり、処理されます。
SQL Applyでメンテナンスされる表にトリガーおよび制約がある場合:
制約: CHECK制約はプライマリ・データベースで評価されます。ロジカル・スタンバイ・データベースでの再評価は不要です。
トリガー: プライマリ・データベースで実行されたトリガーの影響は、スタンバイ・データベースでログに記録され、適用されます。
SQL Applyでメンテナンスされない表にトリガーおよび制約がある場合:
制約は評価されます。
トリガーは発行されます。
表で作成された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);
ロジカル・スタンバイ・データベースが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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
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;
拡張データ型サポート(EDS)では、ネイティブなREDOベースのサポートが欠如した特定のデータ型をサポートするためのロジカル・スタンバイ用のメカニズムが提供されます。たとえば、最上位のVARRAY
列を持つ表はEDSを使用してレプリケートできます。
DBA_LOGSTDBY_EDS_SUPPORTED
ビューを問い合せて、EDSの候補の表を探すことができます。
EDSベースのレプリケーションはロールの推移とシームレスに動作します。たとえば、EDSベースのレプリケーションがOE.CUSTOMERS
という名前のテーブルに対するプライマリ・データベースとターゲット・ロジカル・スタンバイ・データベース間で有効な場合、スイッチオーバーまたはフェイルオーバー操作の後、OE.CUSTOMERS
テーブルはEDSフレームワークを使用してレプリケートされ続けます。これは、別のスタンバイが存在し、テーブルのレプリケート中にEDSを使用している場合でも適用されます。
DBMS_LOGSTDBY
PL/SQLパッケージでは、EDSを追加、削除または変更するプロシージャが提供されます。EDSベースのレプリケーションは、トリガー、シャドウ表、および場合によってはマテリアライズド・ビューの使用を介して動作します。
シャドウ表は、ターゲット表と同じ表領域に作成されます。これには、ロジカル・スタンバイによりネイティブにサポートされる形式に変換された実表からのデータが含まれます。ターゲット表がパーティション化されているとしても、シャドウ表はパーティション化されません。シャドウ表は、実表と同じパーティションに存在します。シャドウ表には、ソース表を変更するトランザクションの期間のみデータが含まれます。結果として、シャドウ表のサイズは最小限で、ソース表のサイズには依存しません。
DMLトリガーは実表およびシャドウ表に作成されます。トリガーは、それらを所有するSYS
スキーマに作成されます。
最初のトリガー(ベース・トリガー)はDML操作(INSERT
、UPDATE
またはDELETE
)が実行されるたびに起動されます。トリガーはサポートされないデータ型をロジカル・スタンバイがサポートするデータ型に変換してから、変換した行をDML操作の型のタイプの情報とともにシャドウ表に取得します。
シャドウ表にはロジカル・スタンバイがサポートするデータ型のみが含まれるので、ネイティブにレプリケートされます。2番目のトリガー(シャドウ・トリガー)はロジカル・スタンバイ上の適用プロセスによりシャドウ表に実行されたDML操作に対して起動されます。シャドウ・トリガーはデータを元の形式に変換し、行で記録されたDML操作が何であってもそれに従って、ターゲット表に適用します。
注意:
EDS表にSQL*Loaderのダイレクト・パス・ロードは使用できません。EDS表へのトリガーによりロードが失敗する場合があります。かわりに、従来型パスを使用してください。
関連項目:
DBMS_LOGSTDBY
PL/SQLパッケージで提供されるEDS関連プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
次の手順で、EDSベースのレプリケーションを有効化する方法の例について説明します。この手順はプライマリ・データベースとスタンバイ・データベース間で分けられています。各手順でデータベースが正しいことを確認してください。
この時点では、OE.CUSTOMERS
表はEDS機能によりレプリケートされています。
構成に複数のロジカル・スタンバイが存在する場合、それぞれで手順3 - 5を繰り返す必要があります。
DBMS_LOGSTDBY.EDS_REMOVE_TABLE
プロシージャを使用してロジカル・スタンバイで特定の表に対しEDSベースのレプリケーションを削除します。
スタンバイで起動された場合、このプロシージャはスタンバイからのみサポートを削除します。
プライマリで起動された場合、このプロシージャはプライマリとすべてのスタンバイ上のその表のサポートを削除します。また、プライマリ・データベースでのEDSベースのレプリケーションに関連するすべてのメタデータも削除されます。ロジカル・スタンバイ・データベースでのEDSベースのレプリケーションに関連するメタデータは、EDS_REMOVE_TABLE
プロシージャと関連するREDOが処理された後で削除されます。EDSベースのメタデータおよびサポートしているオブジェクトのみが削除されます。ソース表は変更されません。
ローリング・アップグレードの期間に対しサポートを追加しただけの場合、表のセットに対しEDSベースのレプリケーションを削除する必要がある場合があります。
EDSベースのレプリケーションは次のようにスキップ・ルールを処理します。
EDSベースのレプリケーションは、ソース表に関連付けられたDDLスキップ・ルールが存在しないことを前提とします。プライマリ・データベースのソース表で実行されたDDLはネイティブのREDOベースのメカニズムを使用してレプリケートされると想定されます。
EDSを使用してレプリケートされているソース表にDMLスキップ・ルールが存在しても、EDSベースのレプリケーションには影響しません。
スキーマのワイルドカード・スキップ・ルールと一致する表にEDSベースのレプリケーションを作成しようとすると失敗します。EDSに対して作成された既存のメッセージ表と一致するワイルドカード・スキップ・ルールを追加しようとするためです。
EDSベースのレプリケーションは表の定義に従って作成されたトリガーに依存するので、DDL操作ではトリガーがすでに有効ではないような方法で表を変更することが可能です。それらは表の新しい定義に従い、自動または手動のいずれかで再生成される必要があります。
自動DDL処理を有効化(または無効化)するには、DBMS_LOGSTDBY.EDS_EVOLVE_AUTOMATIC
プロシージャを使用する必要があります。自動DDL処理が有効な場合、EDS特有のDDLトリガーが各DDL操作の後で起動され、該当するDDLが現在EDSに有効な表のEDSベースのレプリケーションの実行可能性に影響するかどうかが判断されます。影響する場合、別のEVOLVINGトリガーが表に生成され、補正アクションが実行されてEDS特有のメタデータを修復するまで、影響をうける実表でDML操作が許可されないようにします。補正アクションが実行されると、EVOLVINGトリガーは削除され、表でDDL操作が再開できるようになります。
EDSベースのレプリケーションが存在するところでの自動DDL処理には、すべてのDDL操作で起動するDDLトリガーが必要です。補正アクションを手動で実行することが有効な場合もあります。そのような場合、自動DDL処理を無効にし、DBMS_LOGSTDBY.EDS_EVOLVE_MANUAL
プロシージャを使用してDDLを処理することができます。
すべてのEDS保守表で自動DDL処理を有効化するには、DBMS_LOGSTDBY.EDS_ADD_TABLE
への最初のコールの前に、プライマリ・データベースで次の文を一度発行します。
EXECUTE DBMS_LOGSTDBY.EDS_EVOLVE_AUTOMATIC('ENABLE');
すべてのEDS保守表で自動DDL処理を無効化するには、次の文を発行します。
EXECUTE DBMS_LOGSTDBY.EDS_EVOLVE_AUTOMATIC('DISABLE');
手動でDDL操作を処理するには、EDSでレプリケートされている実表に影響する可能性のあるDDL操作の前と後で、DBMS_LOGSTDBY.EDS_EVOLVE_MANUAL
プロシージャをコールする必要があります。次の手順を実行して、手動でDDL操作を処理します。
この順番を守らないと、エラーが発生し、データが失われる可能性があります。
必要ならば、CANCEL
オプションを指定してこのプロシージャを起動することで、手動でのDDL処理を取り消すことができます。
EXECUTE DBMS_LOGSTDBY.EDS_EVOLVE_MANUAL('CANCEL');
関連項目:
DBMS_LOGSTDBY
パッケージのEDS関連プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
この項は、次の項目で構成されています。
プライマリ・データベースで、表に主キーまたは一意索引がなく、実際には一意である行がわかっている場合は、主キーの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制約を追加する手順は、次のとおりです。
コストベース・オプティマイザ(CBO)で最適の問合せ実行パスを判別するために使用されるため、スタンバイ・データベースで統計を収集する必要があります。以前の統計情報が正確でなくなるような変更をスキーマ・オブジェクトのデータまたは構造に対して実行した場合は、その後に新しい統計を収集してください。たとえば、多数の行を表に挿入または削除した後は、行数に関する新しい統計を収集します。
プライマリ・データベースでのDMLおよびDDL操作はワークロードの機能として実行されるため、統計はスタンバイ・データベースで収集してください。スタンバイ・データベースがプライマリ・データベースと論理的に等しい場合、SQL Applyではワークロードを異なる方法で実行する場合があります。そのため、ロジカル・スタンバイ・データベースでSTATSパッケージおよびV$SYSSTAT
ビューを使用すると、リソースおよび表スキャンを最も多く使用している表を判断する際に役立ちます。
次の各項で、次の内容を説明します。
SQL Applyに割り当てられるプロセス数を制御するために変更できるパラメータには、MAX_SERVERS、APPLY_SERVERSおよびPREPARE_SERVERSの3つがあります。常に、次の関係に該当する必要があります。
APPLY_SERVERS + P
REPARE_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
を直接設定することで上書きできます。
PREPARER
プロセスの数の調整が必要になることは、ほとんどありません。PREPARER
プロセスの数を増やす前に、次の条件に該当しているかどうかを確認してください。
すべての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);
ある程度のワークロードの場合、SQL Applyは多数のページアウト操作を使用することがあるため、システム全体のスループットが低下します。LCRキャッシュに割当済のメモリーを増やした場合にスループットを改善できるかどうかを判断する手順は、次のとおりです。
ページアウト・アクティビティによる消費量が稼働時間全体の5%以下であれば理想的です。間隔を長くして引き続きスナップショットを取得し、ページアウト・アクティビティが引き続き適用時間の大部分を占めていることがわかった場合は、メモリー・サイズを大きくするとスループットが改善される可能性があります。SQL Applyに割当済のメモリーは、LCRキャッシュに割り当てられるメモリーを設定する(この例ではSGAを1GBに設定)と増やすことができます。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 1024); PL/SQL procedure successfully completed
デフォルトでは、トランザクションは、プライマリ・データベースでコミットされた順序に正確に従って、ロジカル・スタンバイ・データベースに適用されます。厳密なデフォルト順序でのトランザクションのコミットにより、アプリケーションをロジカル・スタンバイ・データベースで透過的に実行できます。
ただし、多くのアプリケーションでは、すべてのトランザクションの間でそのような厳密な順序が必要なわけではありません。そのようなアプリケーションでは、オーバーラップしない一連の行を含むトランザクションを、プライマリ・データベースでコミットしたときと同じ順序でコミットする必要がありません。一般に、厳密でない順序により、ロジカル・スタンバイ・データベースでの適用率は高くなります。次の手順で、トランザクションをコミットするデフォルトの順序を変更できます。
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
次のように適用モードを元に戻せます。
ロジカル・スタンバイ・データベースは、従来の方法を使用してバックアップでき、データベース・バックアップをリストアしてアーカイブ・ログに対してメディア・リカバリを実行すると、バックアップと同時にリカバリができます。次の各項目は、ロジカル・スタンバイ・データベースの場合に該当します。
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
プロシージャを使用してリカバリされる表領域に含まれる表をすべて登録し、メンテナンス対象の表のリストからスキップされるようにする。