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
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/15480802/viewspace-760985/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
ASM下迁移spfile
请登录后发表评论
登录
全部评论
