OGG抽取延時問題的排查和處理：
背景：
主庫爲4節點RAC，OGG使用的Integrated Cpature(Real Time Downstream mode)
問題：
近期發現downstream節點上的ext進程，經常出現延遲，但可以肯定的是並不是由於大事務引起的，給人的感覺就像是ext進程是在定時抽取似的，延遲時間也不固定，有時候半個小時，有時候一個多小時，找不到規律
分析：
不知道怎麼處理。。
同事提醒看看能不能開開OGG trace，觀察ext進程到底在幹啥。。
開啓OGG trace：
send extract EXT1 trace /u01/ggs/trace.log
send extract EXT1 trace2 /u01/ggs/trace2.log
還有一種Activity Logging Tracing，需要將xml配置文件放到$GGS_HOME 下面，這裏就不說了
這兩個trace都沒找到什麼線索
參考：
http://blog.sina.com.cn/s/blog_4d22b9720100zvmh.html
https://jongsma.wordpress.com/2017/01/30/golden-gate-activity-logging-tracing/
沒思路後，又查了一下Integrated Cpature(Real Time Downstream mode)相關的概念，從官網上找了個pdf看看
https://www.oracle.com/technetwork/database/availability/8398-goldengate-integrated-capture-1888658.pdf
其中有提到： RDBMS alert log is a rich source of information
於是乎去downstream節點的alert日誌裏，果然看到了一點報錯信息：
RFS[1685]: No standby redo logfiles available for T-2
感覺像是主庫的redo沒有及時被接收，downstream節點查了下v$standby_log，發現只有兩個active的log，懷疑這塊應該有什麼問題
http://www.itpub.net/thread-2092510-1-1.html
從這個文章裏得到靈感，發現確實存在主庫redo log比downstream的standby log大的情況(可能是主庫有重建過redo)，於是乎把downstream的standby log全部重建了一遍，創建完成後查v$standby_log，果然變成4個active的狀態了，再去檢查ogg 發現ext延遲沒了，後續又觀察了幾個小時，確認沒有復發。