今早，同事说遇到的奇怪的GoldenGate延时问题，让帮忙看看。
1、现象描述：
A库上有2个抽取进程，（抽取进程1）后期投递给B库，（抽取进程2）后期投递给C库，两个进程抽取的内容基本相同。 抽取进程1 出现延时，延迟了1个多小时，而抽取进程2一切正常。
2、处理过程：
（1）、一般情况下，抽取进程很少会出现延迟的现象。如果出现延迟，通常是如下几种原因：
a. 数据变化量太大，抽取进程忙不过来。
b. 大的业务变更。例如：某张表直接update或者delete几千万甚至上亿条记录。
c. 存在长时间未提交的大事务。因为即使未提交的事务，GoldenGate也会抽取这个事务的数据变化，但抽取的这些信息不会写入trail文件，而是临时缓存到内存中，分配给GoldenGate的内存毕竟有限，如果这个长时间未提交的大事务占用了大量内存，则也可能会出现延迟。
（2）、让同事执行 send extract ...., status 命令，想看看该进程当前的状态。 但反馈说该命令无响应，一会就超时报错。
（3）、检查ggserr.log文件，无任何异常。
（4）、执行info extract ....., showch命令，查看该进程的checkpoint信息。等待10分钟后，再次查看该进程的checkpoint信息。
发现：该抽取进程的current checkpoint无任何变化 。这说明该抽取进程已经完全hang死，而不是因为抽取慢而导致延迟。
（5）、此时， 只能利用strace 或者 pstack 等工具查看该进程的系统调用情况。
pstack 该进程： 无任何输出
strace 该进程： 只显示一条记录,futex(0X7f8b833fb9d0, FUTEX_WAIT, 35298, NULL
（6）、至此，只能搜索MOS，通过关键字futex_wait， 找到Linux: Application Client Intermitttently Hangs (Doc ID 2278335.1)
大概是的意思是：操作系统的内核存在一个BUG，具体的BUG号未提供，服务器端程序运行一切正常，但客户端程序有可能会突然hang住。
3、解决办法：
尝试重启该抽取进程，但发现stop 该进程时，无响应。 没办法，直接 kill -9 该进程， 启动该抽取进程后，立即追平数据，无任何延迟。 从这个处理结果来看，也可以间接证明这一故障就是上述所提及的BUG。