OGG 集成捕获模式下抽取延时问题的排查和处理

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延迟没了，后续又观察了几个小时，确认没有复发。