goldengate的lag

什麼是lag  Main Note - Oracle GoldenGate - Lag, Performance, Slow and Hung Processes [ID 1304557.1]

LAG = replicat將事務寫入target - 事務寫入source redo日誌； 即兩者時間點差

如果事務被分割成多個或由多個replicat執行，則其下各個記錄的lag可能不一致，分別由maxtransops和range引數決定；

lag由如下幾部分組成

extract讀取事務日誌並寫入trail；

datapump讀取trail並傳輸給remote host；

collector獲取網路包並寫入local trail；

replicat讀取trail並應用到target；

Info和send , lag計算的延遲可能不一致，前者由manager基於最近檢查點計算而來，後者則基於當前正在處理行的時間戳；

Lag is expressed in time units and in kilobytes of data the

The lag is a measure of the difference between row archiving or writing and the time an

如果某個長事務長時間不提交，有可能造成Lag過大，可透過maxtransops避免此問題；

Why Does GoldenGate Report The Lag Is Unknown or a Timestamp Mismatch? [ID 968614.1]

有時呼叫lag或info all，會顯示lag timestamp mismatch或lag is unknown；

(1) Lag Command(after handling one or more records)

             GGSCI > lag extract e1

             Sending GETLAG request to EXTRACT E1...

             Lag unknown (timestamp mismatch between source and target).

             At EOF, no more records to process.

(2) "Info All"(This may happen after handling a large amount of records)

             GGSCI > info all

             Program Status Group Lag Time Since Chkpt

             MANAGER RUNNING

             EXTRACT RUNNING E1 unknown 00:00:04

(3) "showch" and date timestamp mismatch

             GGSCI > info e1 showch

              ...

             Checkpoint Lag unknown (updated 00:00:03 ago)

             Log Read Checkpoint File /rdbms/oracle/ora1022i/64/oradata/ora1022a/redo01.log

             2007-03-12 13:36:48 Seqno 3724, RBA 32885344

             .....

             GGSCI > sh date

             Mon Mar 12 12:37:08 PDT 2007

驗證：為測試表新增token，對其做DML並提交，使用Logdump對比記錄提交時間和token，即extract處理該記錄的OS時間，如果前者大於後者則會顯示unknown;

check with logdump (set: usertokens detail) to compare the record commit time (this is from redo log) and the token (from os time when extract processes the record). if former time is later then the one from token, it may cause this 'unknown' display

解決：

首先檢查OS的時區變數TZ設定

        $ > env |grep TZ

        TZ=PST9PDT

        $ > date

        Mon Mar 12 12:40:57 PDT 2007

        $ > export TZ=PST8PDT

        $ > date

        Mon Mar 12 13:41:08 PDT 2007

        You must re-start the Manager and all other GoldenGate groups.

如果時區設定無誤，有可能target與source已經同步，所謂timestamp mismatch只是正常行為

The "timestamp mismatch" may also be displayed when the Extract or Replicat is completely caught up and a LAG command is issued. The LAG command will try to compute the difference between current timestamp on target versus the actual timestamp of the processed record (which comes from the source). When the difference is actually a negative value, then we will display the "timestamp mismatch" message. If these times are very close, this can be when we calculate a negative lag (target timestamp - record timestamp).

OGG Extract RBA Not Moving And LAG Increasing And Appears Hung [ID 964705.1]

症狀：

info extract 顯示RBA沒有增加，而lag卻在一直增長；

原因：

有可能正在處理長事務

send extract , status--應該顯示正在處理大事務，呼叫report繼續驗證

send extract , report--生成report並view report

如果已經宣告瞭warnlongtrans引數，report應該顯示

"Repositioning for Long Transaction"  

"Finished Long Transaction, Processed nnnnn records."

即extract只是在處理長事務，並沒有hung

Using A Heartbeat Table To Monitor LAG Between The Source And Target. [ID 968710.1]

除了GGSCI和GGS report，還可用heartbeat table監控lag

SOURCE: 

CREATE TABLE ggs_heartbeat ( 

id number primary key, 

source_time timestamp default sysdate 

); 

TARGET: 

CREATE TABLE ggs_heartbeat_t ( 

id number primary key, 

source_time timestamp, 

target_time timestamp default sysdate 

); 

只對source表插入id列，可定期插入一條記錄並在target執行

SELECT id, target_time - source_time lag FROM ggs_heartbeat