了解OGG GoldenGate Lag监控

了解OGG GoldenGate Lag监控

 

 

GGSCI中显示的LAG代表 事务被写入到磁盘介质中的时刻例如Oracle中redo被写入到online redo logfile中 和 Replicat将同一个事务分发到目标数据库的时刻 之间的时间间隔。

 

通俗地说,一个事务内的所有行记录将对应同一个LAG; 除非出现了一个事务被打散且被多个REPLICAT分别apply或者变成多个事务的情况。 OGG参数例如RANGE这种对应于第一种情况,即一个事务被多个REPLICATE分别APPLY。 OGG参数MAXTRANSOPS对应后一种情况。

 

LAG在以下情况中被引入:

 

  1. 当Extract进程在读取redolog并写出到TRAIL或REMOTE HOST
  2. 当额外的datapump在读取extract trail并通过网络写出到远程节点REMOTE HOST
  3. 当collector在目标服务器上接受网络数据并写出到LOCAL TRAIL
  4. 当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

*

沪ICP备14014813号-2

沪公网安备 31010802001379号