該樓層疑似違規已被系統折疊?隱藏此樓查看此樓

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

總結

以上是生活随笔為你收集整理的oracle进程瞬间暴增,oracle goldengate ogg 源段传输进程lag延迟不断增加的原因？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。