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

了解GoldenGate中LAG的含義

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

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

LAG在以下情況中被引入：

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

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

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

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

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

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

INFO命令獲得的LAG返回自MANAGER來(lái)源于最近記錄的checkpoint

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

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

歸根結(jié)底LAG是衡量 數(shù)據(jù)歸檔或?qū)懗龅饺罩镜臅r(shí)間 和 EXTRACT/PUMP/REPLICAT處理該數(shù)據(jù)的時(shí)刻 這2個(gè)時(shí)間點(diǎn)之間的差距， 而不是說(shuō) LAG反映了EXTRACT還要工作多久。

實(shí)際EXTRACT/PUMP/REPLICAT都不知道自己要工作多久才能追上 REAL TIME，它們的LAG值只是顯示 最近它們處理的一條記錄的時(shí)間 和這條記錄被寫到REDO LOG的時(shí)間點(diǎn)之間的差距，即LAG只說(shuō)明ER之前的工作延遲，不代表還要工作多久才能追平。

舉個(gè)例子來(lái)說(shuō)，STOP EXTRACT之后等待一段時(shí)間再重啟看到有很大的LAG，這不代表EXTRACT有什么問(wèn)題，只是EXTRACT最后處理的一條記錄 很早就在REDO LOG里生成了 而EXTRACT真正處理這條記錄是等了一段時(shí)間的而已。

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 沒(méi)法預(yù)知自己什么時(shí)候能追平(catch up)， 為什么？ 因?yàn)殡m然看上去可能有幾十個(gè)GB的redo要處理，但是實(shí)際符合EXTRACT/PUMP/REPLICAT 要的記錄可能很少。

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

總結(jié)

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

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