該樓層疑似違規已被系統折疊?隱藏此樓查看此樓
了解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。
是啥意思?...)
