了解GoldenGate中LAG的含义

GGSCI中显示的LAG代表事务被写入到磁盘介质中的时刻例如Oracle中redo被写入到online redo logfile中和 Replicat将同一个事务分发到目标数据库的时刻之间的时间间隔。通俗地说，一个事务内的所有行记录将对应同一个LAG；除非出现了一个事务被打散且被多个REPLICAT分别apply或者变成多个事务的情况。 OGG参数例如RANGE这种对应于第一种情况，即一个事务被多个REPLICATE分别APPLY。 OGG参数MAXTRANSOPS对应后一种情况。 LAG在以下情况中被引入：

当Extract进程在读取redolog并写出到TRAIL或REMOTE HOST
当额外的datapump在读取extract trail并通过网络写出到远程节点REMOTE HOST
当collector在目标服务器上接受网络数据并写出到LOCAL TRAIL
当REPLICAT读取LOCAL TRAIL并写出到数据库中

同时也需要注意通过GGSCI中INFO或STATUS等命令显示的LAG，或通过SEND 对象名,LAG命令获得的LAG可能不一致： INFO命令所获得的LAG可能与SEND命令所得值存在小的差别 INFO命令获得的LAG返回自MANAGER来源于最近记录的checkpoint SEND <OBJECT>, lag获得的LAG值基于<OBJECT>正在处理的行记录的时间戳 LAG常使用时间单位或需要处理的数据单位Kilobytes来表达归根结底LAG是衡量数据归档或写出到日志的时间和 EXTRACT/PUMP/REPLICAT处理该数据的时刻这2个时间点之间的差距，而不是说 LAG反映了EXTRACT还要工作多久。实际EXTRACT/PUMP/REPLICAT都不知道自己要工作多久才能追上 REAL TIME，它们的LAG值只是显示最近它们处理的一条记录的时间和这条记录被写到REDO LOG的时间点之间的差距，即LAG只说明ER之前的工作延迟，不代表还要工作多久才能追平。举个例子来说，STOP EXTRACT之后等待一段时间再重启看到有很大的LAG，这不代表EXTRACT有什么问题，只是EXTRACT最后处理的一条记录很早就在REDO LOG里生成了而EXTRACT真正处理这条记录是等了一段时间的而已。 GGSCI (XIANGBLI-CN) 27> stop load2 Sending STOP request to EXTRACT LOAD2 ... Request processed. GGSCI (XIANGBLI-CN) 28> start load2 Sending START request to MANAGER ... EXTRACT LOAD2 starting GGSCI (XIANGBLI-CN) 31> info load2 EXTRACT LOAD2 Last Started 2012-09-18 20:26 Status RUNNING Checkpoint Lag 00:04:34 (updated 00:00:08 ago) Log Read Checkpoint Oracle Redo Logs 2012-09-18 20:21:32 Seqno 44, RBA 13750272 SCN 0.1845479 (1845479) GGSCI (XIANGBLI-CN) 35> lag load2 Sending GETLAG request to EXTRACT LOAD2 ... Last record lag: 130 seconds. At EOF, no more records to process. GGSCI (XIANGBLI-CN) 36> info load2 EXTRACT LOAD2 Last Started 2012-09-18 20:26 Status RUNNING Checkpoint Lag 00:00:00 (updated 00:00:02 ago) Log Read Checkpoint Oracle Redo Logs 2012-09-18 20:27:33 Seqno 44, RBA 13817856 SCN 0.1845671 (1845671) 以上可以看到 Last record lag 和 Checkpoint Lag 是不同的 EXTRACT/PUMP/REPLICAT 没法预知自己什么时候能追平(catch up)，为什么？因为虽然看上去可能有几十个GB的redo要处理，但是实际符合EXTRACT/PUMP/REPLICAT 要的记录可能很少。又由于INFO的LAG是基于checkpoint的，所以如果出现大事务的情况Long Running Transactions (LRTs)，事务可能长时间不提交COMMIT。该事务可能变成一个最老而又最无聊的数据由于一直不COMMIT而无法写出。这将造成EXTRACT/PUMP/REPLICAT实际处理这个大事务的时间点远落后于该大事务实际commit的时间点。对于REPLICAT可以使用MAXTRANSOPS 参数来减少LAG。