今早，同事说遇到的奇怪的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。