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