了解OGG 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。
Comment