該樓層疑似違規(guī)已被系統(tǒng)折疊?隱藏此樓查看此樓

了解GoldenGate中LAG的含義

GGSCI中顯示的LAG代表 事務(wù)被寫入到磁盤介質(zhì)中的時刻例如Oracle中redo被寫入到online redo logfile中 和 Replicat將同一個事務(wù)分發(fā)到目標(biāo)數(shù)據(jù)庫的時刻 之間的時間間隔。

通俗地說，一個事務(wù)內(nèi)的所有行記錄將對應(yīng)同一個LAG； 除非出現(xiàn)了一個事務(wù)被打散且被多個REPLICAT分別apply或者變成多個事務(wù)的情況。 OGG參數(shù)例如RANGE這種對應(yīng)于第一種情況，即一個事務(wù)被多個REPLICATE分別APPLY。 OGG參數(shù)MAXTRANSOPS對應(yīng)后一種情況。

LAG在以下情況中被引入：

當(dāng)Extract進(jìn)程在讀取redolog并寫出到TRAIL或REMOTE HOST

當(dāng)額外的datapump在讀取extract trail并通過網(wǎng)絡(luò)寫出到遠(yuǎn)程節(jié)點REMOTE HOST

當(dāng)collector在目標(biāo)服務(wù)器上接受網(wǎng)絡(luò)數(shù)據(jù)并寫出到LOCAL TRAIL

當(dāng)REPLICAT讀取LOCAL TRAIL并寫出到數(shù)據(jù)庫中

同時也需要注意通過GGSCI中INFO或STATUS等命令顯示的LAG，或通過SEND 對象名,LAG命令獲得的LAG可能不一致：

INFO命令所獲得的LAG可能與SEND命令所得值存在小的差別

INFO命令獲得的LAG返回自MANAGER來源于最近記錄的checkpoint

SEND , lag獲得的LAG值基于正在處理的行記錄的時間戳

LAG常使用時間單位或需要處理的數(shù)據(jù)單位Kilobytes來表達(dá)

歸根結(jié)底LAG是衡量 數(shù)據(jù)歸檔或?qū)懗龅饺罩镜臅r間 和 EXTRACT/PUMP/REPLICAT處理該數(shù)據(jù)的時刻 這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 沒法預(yù)知自己什么時候能追平(catch up)， 為什么？ 因為雖然看上去可能有幾十個GB的redo要處理，但是實際符合EXTRACT/PUMP/REPLICAT 要的記錄可能很少。

又由于INFO的LAG是基于checkpoint的，所以如果出現(xiàn)大事務(wù)的情況Long Running Transactions (LRTs)，事務(wù)可能長時間不提交COMMIT。 該事務(wù)可能變成一個最老而又最無聊的數(shù)據(jù)由于一直不COMMIT而無法寫出。 這將造成EXTRACT/PUMP/REPLICAT實際處理這個大事務(wù)的時間點遠(yuǎn)落后于該大事務(wù)實際commit的時間點。 對于REPLICAT可以使用MAXTRANSOPS 參數(shù)來減少LAG。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。