11gリリース1（11.1）
E05755-03
 目次 |
 索引 |
| Oracle Data Guard 概要および管理 11gリリース1（11.1） E05755-03 |
|
この章は、次の項目で構成されています。
SQL Applyでは、バックグラウンド・プロセスの集合を使用して、プライマリ・データベースの変更がロジカル・スタンバイ・データベースに適用されます。
図10-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アクティビティ中のロジカル・スタンバイ・データベースに関する統計、現在の状態およびステータス情報が表示されます。この2つのビューと他の関連ビューの詳細は、10.3項「ロジカル・スタンバイ・データベースの管理および監視関連のビュー」を参照してください。
この項は、次の項目で構成されています。
SQL Applyでは、トランザクションが大小2つのクラスに分類されます。
たとえば、小さく分割しない場合、SQL*Loaderのロードが1000万行で、サイズがそれぞれ100バイトであれば、LCRキャッシュでは1GBを超えるメモリーが使用されます。LCRキャッシュに割り当てられているメモリーが1GB未満の場合は、LCRキャッシュからのページアウトが発生します。
メモリーの考慮事項とは別に、SQL ApplyがトランザクションのCOMMITレコードを検出するまでに1000万行のSQL*Loaderロードに関連する変更の適用を開始しない場合、ロールの推移が停止します。SQL Applyがロジカル・スタンバイ・データベース上でトランザクションを適用し終わるまで、そのトランザクションのコミット後に開始されたスイッチオーバーまたはフェイルオーバーは終了できません。
トランザクション・チャンクの使用にもかかわらず、100万行超を変更するトランザクションの処理時にSQL Applyのパフォーマンスが低下することがあります。トランザクションのサイズを100万行未満に制限することをお薦めします。SQL*Loader表のロードが大規模な場合は、ROWS句を使用してトランザクション内にロードされる行数を制限します。
すべてのトランザクションは、最初は小さいトランザクションとして分類されます。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レコードのマイニングを開始します。再開に不要なアーカイブREDOログ・ファイルは、SQL Applyにより自動的に削除されます。
多数のDDLトランザクション、パラレルDML文（PDML）およびダイレクト・パス・ロードなど、ある種のワークロードがあると、RESTART_SCNはワークロードの存続期間中は進行しなくなります。
SQL Applyがロジカル・スタンバイ・データベースのスループットと待機時間に影響するDMLトランザクションを適用する場合、次の特性があります。
INSERT文を使用して適用されます。
SQL Applyがロジカル・スタンバイ・データベースのスループットと待機時間に影響するDDLトランザクションを適用する場合、次の特性があります。
CREATE TABLE AS SELECT（CTAS）文の一部）が抑制されるように、CTAS文が実行されます。CTAS文の一部として新規作成された表に挿入された行は、REDOログ・ファイルからマイニングされ、INSERT文を使用してロジカル・スタンバイ・データベースに適用されます。
ALTER TABLE hr.employees ADD (start_date date default sysdate);
SQL Applyはロジカル・スタンバイで同じDDLを再発行するため、sysdate()ファンクションはロジカル・スタンバイで再評価されます。そのため、start_date列は、プライマリ・データベースでのデフォルト値とは異なるデフォルト値で作成されます。
たとえば、次のような表を作成するとします。
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列へのこのような変更は、ロジカル・スタンバイ・データベースでレプリケートされません。表に対する後続のDMLではSQL Applyが停止します。これは、REDOストリームに記録されたMODIFY_DATE列のデータがロジカル・スタンバイ。データベースに存在するデータと一致しないためです。
パスワードの複雑性をチェックするパスワード検証関数は、SYSスキーマで作成する必要があります。SQL ApplyはSYSスキーマで作成されたオブジェクトをレプリケートしないため、このような検証関数は、ロジカル・スタンバイ・データベースにレプリケートされません。ロジカル・スタンバイ・データベースでは、パスワード検証関数を手動で作成し、適切なプロファイルと関連付ける必要があります。
SQLのALTER DATABASE GUARD文は、ロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスを制御します。デフォルトでは、ロジカル・スタンバイ・データベースについてはデータベース・ガードがALLに設定されています。
ALTER DATABASE GUARD文では、次のキーワードを使用できます。
ALLALLを指定すると、SYS以外のすべてのユーザーが、ロジカル・スタンバイ・データベース内のデータを変更できなくなります。
STANDBYSTANDBYを指定すると、SYS以外のすべてのユーザーが、SQL Applyでメンテナンスされる表または順序に対してDMLおよびDDLを変更できなくなります。
NONENONEを指定すると、データベース内の全データには通常のセキュリティが適用されます。
たとえば、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文は、10.5.4項に説明されているように、データベース・ガードを一時的に無効にしてデータベースを変更するときに役立ちます。
次のパフォーマンス・ビューでは、ロジカル・スタンバイ・データベースを保守するSQL Applyの動作が監視されます。次の各項では、ロジカル・スタンバイ・データベースの監視に使用できる主なビューについて説明します。
DBA_LOGSTDBY_EVENTSビューには、SQL Apply操作中に発生した重要なイベントが記録されます。デフォルトでは、最新の10,000のイベントが記録されます。ただし、記録されるイベントの数は、PL/SQLプロシージャDBMS_LOGSTDBY.APPLY_SET()をコールして変更できます。SQL Applyが突然停止した場合は、このビューにその原因も記録されます。
このビューは、適用された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 2 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とスキップされた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で、ロジカル・スタンバイ・データベースでは1時2分41秒に受信されています。
APPLIED列は、SQL ApplyによりSCN 144057までのREDOがすべて適用されたことを示しています。トランザクションでは複数のアーカイブ・ログ・ファイルを使用している可能性があるため、複数のアーカイブ・ログ・ファイルの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）
COORDINATOR、READER、BUILDER、PREPARER、ANALYZERまたはAPPLIER（type）
status_code | status）
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の進捗に関する詳細情報が表示されます。
applied_scn, applied_time）
restart_scn, restart_time）
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> 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
この出力は次のことを示しています。
APPLIED_TIME）。
LATEST_TIME）。
MINING_TIME）。
このビューには、次のように、SQL Applyの現在の状態の概要が表示されます。
primary_dbid）
session_id）
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であることを示しています。
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には、6つの進捗状況があります。SQL Applyの初期化、ディクショナリ・ログの待機、LogMinerディクショナリのロード、（REDOデータの）適用、アーカイブ・ギャップの解決の待機およびアイドルです。図10-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つのフェーズで発生します。
次に例を示します。
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:01291 Waiting for logfile
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);
デフォルトの自動ログ削除機能を上書きする場合は、定期的に次の手順を実行してSQL Applyで不要になったアーカイブREDOログ・ファイルを識別し、削除します。
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
この項は、次の項目で構成されています。
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サブプログラムを示します。
たとえば、適用済DDLトランザクションをDBA_LOGSTDBY_EVENTSビューに記録するには、次の文を発行します。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET ('RECORD_APPLIED_DDL', 'TRUE');
プライマリ・データベースで実行されていて、ロジカル・スタンバイ・データベースでサポートされないトランザクションに関する情報を取得するには、次の文を発行します。
SQL> EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');
次に、サポートされない操作がないかDBA_LOGSTDBY_EVENTSビューをチェックします。通常、サポートされない表に対する操作は、SQL Applyによって警告なしで無視されます。しかし、ローリング・アップグレード中（スタンバイ・データベースが上位バージョンであり、下位バージョンのプライマリ・データベースによって生成されたREDOをマイニングしているとき）に、サポートされない操作をプライマリ・データベースに対して実行した場合、ロジカル・スタンバイ・データベースにスイッチオーバーされない可能性があります。Data Guardは、表ごとに1つ以上のサポートされない操作をDBA_LOGSTDBY_EVENTSビューに記録します。ローリング・アップグレードの詳細は、第12章「SQL Applyを使用したOracle Databaseのアップグレード」を参照してください。
デフォルトでは、プライマリ・データベース内でサポートされる表は、すべてロジカル・スタンバイ・データベースで複製されます。このデフォルト動作は、特定の表に対する変更の適用をスキップするルールを指定することで変更できます。たとえば、HR.EMPLOYEES表に対する変更を省略するには、特定の表に対するDML変更とDDL変更の適用を防止するルールを指定できます。次に例を示します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SKIPルールを登録します。
SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'DML', schema_name => 'HR', - object_name => 'EMPLOYEES'); SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'SCHEMA_DDL', schema_name => 'HR', - object_name => 'EMPLOYEES');
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
特定のDDL文をインターセプトして元のDDL文を別のDDL文で置き換えるプロシージャを作成できます。たとえば、ロジカル・スタンバイ・データベース内のファイル・システムの編成がプライマリ・データベースとは異なる場合、DBMS_LOGSTDBY.SKIPプロシージャを作成し、ファイルを指定してDDLトランザクションを透過的に処理できます。
次のプロシージャでは、ファイル指定文字列に特定のネーミング規則を使用するかぎり、プライマリ・データベースとスタンバイ・データベース間で異なるファイル・システム編成を処理できます。
CREATE OR REPLACE PROCEDURE SYS.HANDLE_TBS_DDL ( OLD_STMT IN VARCHAR2, STMT_TYP IN VARCHAR2, SCHEMA IN VARCHAR2, NAME IN VARCHAR2, XIDUSN IN NUMBER, XIDSLT IN NUMBER, XIDSQN IN NUMBER, ACTION OUT NUMBER, NEW_STMT OUT VARCHAR2 ) AS BEGIN -- All primary file specification that contains a directory -- /usr/orcl/primary/dbs -- should go to /usr/orcl/stdby directory specification NEW_STMT := REPLACE(OLD_STMT, '/usr/orcl/primary/dbs', '/usr/orcl/stdby'); ACTION := DBMS_LOGSTDBY.SKIP_ACTION_REPLACE; EXCEPTION WHEN OTHERS THEN ACTION := DBMS_LOGSTDBY.SKIP_ACTION_ERROR; NEW_STMT := NULL; END HANDLE_TBS_DDL;
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'TABLESPACE', - proc_name => 'sys.handle_tbs_ddl');
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
ロジカル・スタンバイ・データベースは、SQL文が適用されている間でもレポート・アクティビティに使用できます。データベース・ガードはロジカル・スタンバイ・データベース内の表に対するユーザー・アクセスを制御し、ALTER SESSION DISABLE GUARD文はデータベース・ガードをバイパスしてロジカル・スタンバイ・データベース内の表に対する変更を可能にするために使用します。
デフォルトでは、ロジカル・スタンバイ・データベースはデータベース・ガードがALL（最も限定的な設定）に設定されている状態で作動し、ユーザーはデータベースに対して変更を実行できません。データベース・ガードを無視して、ロジカル・スタンバイ・データベースを変更可能にするには、ALTER SESSION DISABLE GUARD文を実行します。権限を付与されているユーザーは、この文を発行して、現行のセッションでデータベース・ガードをオフにできます。
次の各項で、例を示します。これらの例では、データベース・ガードがALLまたはSTANDBYに設定されていると仮定しています。
この項では、SQL Applyを介してメンテナンスされている表に制約を追加する方法を説明します。
デフォルトでは、SYS権限を持つアカウントのみがデータベースを変更でき、データベース・ガードはALLまたはSTANDBYに設定されています。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; Database altered. SQL> SELECT ENAME,MGR FROM SCOTT.EMP WHERE SOUNDEX(ENAME) = SOUNDEX('CLARKE'); ENAME MGR ---------- ---------- CLARK 7839
オラクル社では、データベース・ガードのバイパスが使用可能になっている間は、SQL Applyにより保守される表に対してDML操作を実行しないことをお薦めします。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 DBA_LOGSDTBY_PARAMETERS WHERE NAME = 'GUARD_STANDBY'; VALUE --------------- Ready
VALUE列にReadyと表示される場合、SQL Applyではスキップされる表の関連メタデータがすべて正常に更新されており、その表を変更しても安全です。
|
関連項目
C.11項「ロジカル・スタンバイ・データベースでサポートされるDDL文」および『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』の |
通常、リカバリ不能な操作の後に表を再作成するには、DBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャを使用します。また、このプロシージャを使用して、以前はスキップしていた表に対してSQL Applyを使用可能にすることもできます。
表を作成する前に、4.1.2項「プライマリ・データベース内の表の行が一意に識別できることの確認」に記載されている要件を満たす必要があります。その後、次の手順に従って表HR.EMPLOYEESを再作成し、SQL Applyを再開できます。この手順は、プライマリ・データベースにアクセスするデータベース・リンクBOSTONが定義済であることを前提としています。
次のリストは、表を再作成し、その表に対して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', - object_name => 'EMPLOYEES', - dblink => 'BOSTON');
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
新規にインスタンス化された表とデータベースの残りの部分にまたがってビューの一貫性が得られるように、SQL Applyがプライマリ・データベースと一致するまで待機してから、この表を問い合せます。手順は次のとおりです。
V$DATABASEビューを問い合せて現在のSCNを判別します。
SQL> SELECT CURRENT_SCN FROM V$DATABASE@BOSTON; CURRENT_SCN --------------------- 345162788
CURRENT_SCNより前のコミット済のトランザクションがすべて、SQL Applyにより適用されていることを確認します。
SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN -------------------------- 345161345
この問合せで戻されたAPPLIED_SCNが最初の問合せで戻されたCURRENT_SCNよりも大きい場合は、新規に再作成された表を問い合せても安全です。
この項は、次の項目で構成されています。
表領域をプライマリ・データベースにインポートする手順は、次のとおりです。
SQL> ALTER DATABASE GUARD STANDBY;
SQL> ALTER DATABASE GUARD ALL;
ロジカル・スタンバイでは、マテリアライズド・ビューに関連した次のDDL文を自動的にスキップします。
ロジカル・スタンバイ・データベースの作成後にプライマリ・データベースで作成、変更または削除された新規マテリアライズド・ビューは、ロジカル・スタンバイ・データベースには反映されません。ただし、ロジカル・スタンバイ・データベースの作成前にプライマリ・データベースで作成されたマテリアライズド・ビューは、ロジカル・スタンバイ・データベースに存在します。
ロジカル・スタンバイでは、他の種類の補助データ構造に加えて、ロジカル・スタンバイ・データベースでの新規マテリアライズド・ビューのローカルな作成およびメンテナンスをサポートしています。たとえば、オンライン・トランザクション処理（OLTP）システムでは、高度に正規化された表を更新パフォーマンスに頻繁に使用しますが、これらの表により、複雑な意思決定支援の問合せに対するレスポンス時間が長くなることがあります。ロジカル・スタンバイ・データベースでより効率的な問合せが作成できるように、次のようにして、レプリケートされたデータを非正規化するマテリアライズド・ビューを作成できます。
SQL> ALTER SESSION DISABLE GUARD; SQL> ALTER TABLE DEPT ADD (CONSTRAINT DEPT_PK PRIMARY KEY (DEPTNO)); SQL> ALTER TABLE EMP ADD (CONSTRAINT EMP_FK FOREIGN KEY (DEPTNO) 2 REFERENCES DEPT(DEPTNO)); SQL> CREATE MATERIALIZED VIEW LOG ON EMP 2 WITH ROWID (EMPNO, ENAME, MGR, DEPTNO) INCLUDING NEW VALUES; SQL> CREATE MATERIALIZED VIEW LOG ON DEPT 2 WITH ROWID (DEPTNO, DNAME) INCLUDING NEW VALUES; SQL> CREATE MATERIALIZED VIEW MANAGED_BY 2 REFRESH ON DEMAND 3 ENABLE QUERY REWRITE 4 AS SELECT E.ENAME, M.ENAME AS MANAGER 5 FROM EMP E, EMP M WHERE E.MGR=M.EMPNO; SQL> CREATE MATERIALIZED VIEW IN_DEPT 2 REFRESH FAST ON COMMIT 3 ENABLE QUERY REWRITE 4 AS SELECT E.ROWID AS ERID, D.ROWID AS DRID, E.ENAME, D.DNAME 5 FROM EMP E, DEPT D WHERE E.DEPTNO=D.DEPTNO;
ロジカル・スタンバイ・データベースの場合
DBMS_MVIEW.REFRESHプロシージャを実行する必要があります。
たとえば、次のコマンドを発行すると、前の例で作成されたON-DEMANDマテリアライズド・ビューがリフレッシュされます。
SQL> ALTER SESSION DISABLE GUARD; SQL> EXECUTE DBMS_MVIEW.REFRESH (LIST => 'SCOTT.MANAGED_BY', METHOD => 'C');
DBMS_SCHEDULERジョブを使用してON-DEMANDマテリアライズド・ビューを定期的にリフレッシュする場合は、データベース・ガードをSTANDBYに設定する必要があります。（ALTER SESSION DISABLE GUARD文をPL/SQLブロック内で使用して有効にすることはできません。）
デフォルトでは、トリガーと制約はロジカル・スタンバイ・データベースで自動的に使用可能になり、処理されます。
SQL Applyでメンテナンスされる表にトリガーおよび制約がある場合:
Fire_Once_Only起動プロパティがFALSEに設定されたトリガーです。
SQL Applyでメンテナンスされない表にトリガーおよび制約がある場合:
単純なオブジェクト型の列のためにサポートされていない表を、Fire_Once_Onlyではないトリガーを使用してレプリケートできます。通常のDMLトリガーをプライマリで使用して、オブジェクト型を、サポート可能な表にフラット化できます。Fire_Once_Onlyではないトリガーをロジカル・スタンバイで使用して、オブジェクト型を再作成し、サポートされていない表をトランザクション方式で更新できます。
次の例は、トリガーを使用して単純なオブジェクト・タイプをレプリケートする方法を示しています。この例では、挿入処理の方法を示します。同じ原則を更新および削除に適用できます。ネストした表および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 -- -- 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 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', fire_once => 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データが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっていない場合 |
指定のプライマリ・データベース・ブランチで、プライマリ・データベースとスタンバイの内容にずれが生じます。 |
第4章「ロジカル・スタンバイ・データベースの作成」の手順に従ってロジカル・スタンバイ・データベースを再作成します。 |
|
REDOデータの前のブランチの終わりからアーカイブREDOログ・ファイルが欠落している場合 |
SQL Applyは欠落しているログ・ファイルが取得されるまで続行できません。 |
前のブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。 |
データベース・インカネーション、OPEN RESETLOGS操作を使用したリカバリおよびフラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この項は、次の項目で構成されています。
プライマリ・データベースで、表に主キーまたは一意索引がなく、実際には一意である行がわかっている場合は、主キーのRELY制約を作成します。ロジカル・スタンバイ・データベースでは、主キーを構成する列に索引を作成します。次の問合せは、ロジカル・スタンバイ・データベースで行を一意に識別するために適用できる索引情報がない表のリストを生成します。次の表に索引を作成することによって、パフォーマンスが大幅に向上する可能性があります。
SQL> SELECT OWNER, TABLE_NAME FROM DBA_TABLES 2> WHERE OWNER NOT IN (SELECT OWNER FROM DBA_LOGSTDBY_SKIP 3> WHERE STATEMENT_OPT = 'INTERNAL SCHEMA') 4> MINUS 5> SELECT DISTINCT TABLE_OWNER, TABLE_NAME FROM DBA_INDEXES 6> WHERE INDEX_TYPE NOT LIKE ('FUNCTION-BASED%') 7> MINUS 8> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED;
プライマリ・データベースの表に主キーのRELY制約を追加する手順は、次のとおりです。
SQL> ALTER TABLE HR.TEST_EMPLOYEES ADD PRIMARY KEY (EMPNO) RELY DISABLE;
これにより、HR.TEST_EMPLOYEES表の各行を一意に識別するために使用可能なEMPNO列が、その表に対して実行される更新の一部としてサプリメンタル・ロギングで確実に記録されるようになります。
HR.TEST_EMPLOYEES表には、ロジカル・スタンバイ・データベースで指定された一意索引がまだないことに注意してください。このため、UPDATE文ではロジカル・スタンバイ・データベースに対して全表スキャンが実行される場合があります。これを避けるには、ロジカル・スタンバイ・データベースでEMPNO列に一意索引を追加します。
RELY制約の詳細は、4.1.2項「プライマリ・データベース内の表の行が一意に識別できることの確認」および『Oracle Database SQL言語リファレンス』を参照してください。
残りの手順をロジカル・スタンバイ・データベースで実行します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> ALTER SESSION DISABLE GUARD;
EMPNO列に一意索引を追加します。
SQL> CREATE UNIQUE INDEX UI_TEST_EMP ON HR.TEST_EMPLOYEES (EMPNO);
SQL> ALTER SESSION ENABLE GUARD;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
コストベース・オプティマイザ（CBO）で最適の問合せ実行パスを判別するために使用されるため、スタンバイ・データベースで統計を収集する必要があります。以前の統計情報が正確でなくなるような変更をスキーマ・オブジェクトのデータまたは構造に対して実行した場合は、その後に新しい統計を収集してください。たとえば、多数の行を表に挿入または削除した後は、行数に関する新しい統計を収集します。
プライマリ・データベースでのDMLおよびDDL操作はワークロードの機能として実行されるため、統計はスタンバイ・データベースで収集してください。スタンバイ・データベースがプライマリ・データベースと論理的に等しい場合、SQL Applyではワークロードを異なる方法で実行する場合があります。そのため、ロジカル・スタンバイ・データベースでSTATSパッケージおよびV$SYSSTATビューを使用すると、リソースおよび表スキャンを最も多く使用している表を判断する際に役立ちます。
次の各項で、次の内容を説明します。
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でサーバー・プロセスを準備プロセスと適用プロセスの間に適当に分散できようにすることをお薦めします。
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はPREPARERとして機能するようにサーバー・プロセスを2つ割り当て、残りをAPPLIERとして割り当てて前述の関係を満たします。この内部プロセス割当てアルゴリズムは、前述の関係を満たしているならば、APPLY_SERVERSおよびPREPARE_SERVERSを直接設定することで上書きできます。
APPLIERプロセスの数を調整することでスループットを改善できるかどうかを判断する手順は、次のとおりです。
APPLIERプロセスがビジーかどうかを判断します。
SQL> SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER' and status_code = 16166; IDLE_APPLIER ------------------------- 0
APPLIERプロセスがないことを確認した後、次の問合せを発行し、APPLIERの数を調整した場合に追加分のAPPLIERプロセスに十分な作業が使用可能かどうかを確認します。
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE 'transactions%';
この2つの統計では、APPLIERプロセスによる適用準備が完了しているトランザクション数とすでに適用済のトランザクション数の累計が維持されます。
この数値（transactions mined - transactions applied）が使用可能なAPPLIERプロセス数の2倍を超えている場合は、APPLIERプロセス数を増やすことでスループットを改善できます。
APPLIERプロセス数をデフォルト値の5から20に調整し、PREPARERプロセス数は1のままとします。これは、次の等式を満たす必要があるためです。
APPLY_SERVERS + PREPARE_SERVERS = MAX_SERVERS - 3
まず、MAX_SERVERSを24に設定する必要があります。設定したら、次のようにして、APPLY_SERVERSの数を20に設定できます。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS', 24); SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', 20);
PREPARERプロセスの数の調整が必要になることは、ほとんどありません。PREPARERプロセスの数を増やす前に、次の条件に該当しているかどうかを確認してください。
前述の条件に該当しているかどうかを判断する手順は、次のとおりです。
PREPARERプロセスがビジーであることを確認します。
SQL> SELECT COUNT(*) AS IDLE_PREPARER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'PREPARER' and status_code = 16166; IDLE_PREPARER ------------- 0
APPLIERプロセスの数よりも少ないことを確認します。
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE 'transactions%'; NAME VALUE --------------------- ------- transactions ready 27896 transactions applied 27892 SQL> SELECT COUNT(*) AS APPLIER_COUNT FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER'; APPLIER_COUNT ------------- 20
注意: これが一時イベントでないことを確認するために、この問合せは数回発行してください。
APPLIERプロセスがあることを確認します。
SQL> SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER' and status_code = 16166; IDLE_APPLIER ------------------------- 19
この例では、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キャッシュに割当済のメモリーを増やした場合にスループットを改善できるかどうかを判断する手順は、次のとおりです。
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE '%page%' OR NAME LIKE '%uptime%' OR NAME LIKE '%idle%'; NAME VALUE -------------------------- --------------- coordinator uptime in secs 894856 bytes paged out 20000 seconds spent in pageout 2 system idle time in secs 1000
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE '%page%' OR NAME LIKE '%uptime%' OR NAME LIKE '%idle%'; NAME VALUE -------------------------- --------------- coordinator uptime in secs 895156 bytes paged out 1020000 seconds spent in pageout 100 system idle time in secs 1000
Change in coordinator uptime (C)= (895156 - 894856) = 300 secs Amount of additional idle time (I)= (1000 - 1000) = 0 Change in time spent in pageout (P) = (100 - 2) = 98 secs Pageout time in comparison to uptime = P/(C-I) = 98/300 ~ 32.67%
ページアウト・アクティビティによる消費量が稼働時間全体の5%以下であれば理想的です。間隔を長くして引き続きスナップショットを取得し、ページアウト・アクティビティが引き続き適用時間の大部分を占めていることがわかった場合は、メモリー・サイズを大きくするとスループットが改善される可能性があります。SQL Applyに割当済のメモリーは、LCRキャッシュに割り当てられるメモリーを設定する（この例ではSGAを1GBに設定）と増やすことができます。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 1024); PL/SQL procedure successfully completed
デフォルトでは、トランザクションは、プライマリ・データベースでコミットされた順序に正確に従って、ロジカル・スタンバイ・データベースに適用されます。厳密なデフォルト順序でのトランザクションのコミットにより、アプリケーションをロジカル・スタンバイ・データベースで透過的に実行できます。
ただし、多くのアプリケーションでは、すべてのトランザクションの間でそのような厳密な順序が必要なわけではありません。そのようなアプリケーションでは、オーバーラップしない一連の行を含むトランザクションを、プライマリ・データベースでコミットしたときと同じ順序でコミットする必要がありません。一般に、厳密でない順序により、ロジカル・スタンバイ・データベースでの適用率は高くなります。次の手順で、トランザクションをコミットするデフォルトの順序を変更できます。
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> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered
プライマリ・データベースと一致し（V$LOGSTDBY_STATSビューを問い合せて確認し）、ロジカル・スタンバイ・データベースをレポート・アプリケーションに対してオープンする準備が完了した時点で、次のように適用モードを変更できます。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered
PRESERVE_COMMIT_ORDERパラメータのデフォルト値をリストアします。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER'); PL/SQL procedure successfully completed
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered
一般的なオンライン・トランザクション処理（OLTP）のワークロードでは、デフォルト以外のモードにすると、デフォルトの適用モードに比べてスループットを50%以上改善できます。
ロジカル・スタンバイ・データベースは、従来の方法を使用してバックアップでき、データベース・バックアップをリストアしてアーカイブ・ログに対してメディア・リカバリを実行すると、バックアップと同時にリカバリができます。次の各項目は、ロジカル・スタンバイ・データベースの場合に該当します。
Recovery Managerのリカバリ・カタログを作成する、またはカタログを変更するRecovery Managerのアクティビティを実行する場合、ロジカル・スタンバイ・データベースでは、GUARDをSTANDBYに設定して実行する必要があります。
ローカル・リカバリ・カタログがロジカル・スタンバイ制御ファイルにのみ保持されている場合は、GUARDをALLに設定したままにできます。
ロジカル・スタンバイ・データベースのインスタンス化の直後に、制御ファイルのバックアップを取得することをお薦めします。
Point-in-Timeリカバリの後に初めてSQL Applyが開始されるとき、必要なアーカイブ・ログをローカル・システムで検出するか、プライマリ・データベースからフェッチできる必要があります。V$LOGSTDBY_PROCESSビューを使用して、アーカイブ・ログをプライマリ・データベースでリストアする必要があるかどうかを判断します。
ロジカル・スタンバイ・データベースの表領域に対してPoint-in-Timeリカバリを実行する場合、次のいずれかを実行する必要があります。
|
 Copyright © 1999, 2008 Oracle Corporation. All Rights Reserved. |
|