该楼层疑似违规已被系统折叠 隐藏此楼查看此楼

了解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 , lag获得的LAG值基于正在处理的行记录的时间戳

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。