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
转载于:https://blog.51cto.com/maclean/1278457
