GoldenGate抽取进程extract延迟处理

前言

一套GoldenGate环境，已经运行了很多年，一直比较正常，Extract抽取进程基本上没有出现延迟的情况，但这次突然出现抽取延迟，其中一个抽取进程延迟高达50个小时左右。

 

处理过程

1. 当前有两个抽取进程，分别为：E_HXZG、E_SBFSC, 目前出现延迟的是第1个抽取进程。检查该进程的当前状态。

 可以看出，该抽取进程当前正在处理数据，等待了10分钟左右，再次执行send e_hxzg, status命令，发现该进程的处理效率非常低，10分钟左右，才处理了200MB的日志。

2. 检查该抽取进程的配置文件，具体内容如下所示：

 该配置文件，整体上没有问题，但有两个参数，可能对性能有点影响。 getupdatebefores 和 nocompressdeletes，询问现场人员，得知：后续的PUMP进程不会进行filter过滤操作，同样Replicat进程也没有数据统计之类的额外需求。只是单纯的表数据同步。 所以建议屏蔽掉这两个参数，并重启抽取进程。

3. 删除getupdatebefores 和 nocompressdeletes参数后，观察该抽取进程的抽取效率，发现没有太多的改善。

4. 针对该抽取进程，获取pstack和strace信息。

 查看strace的输出，发现每次在read调用时，就卡住好几秒，而write调用就非常快。这应该就是读取时遇到性能问题。

5. 建议收集抽取进程的trace，看看时间都花在哪些位置。
Send <process_name> TRACE </full_path/trace.txt>
等待5分钟
Send <process_name> TRACE off

Send <process_name> TRACE2 </full_path/trace2.txt>
等待5分钟
Send <process_name> TRACE2 off

6. trace日志如下所示。

 可以看出，在抽取hx_zh.gy_zzsfpglxxttb_log这张表时，遭遇了ORA-01555，fetch failed. 然后通过rowid再去fetch数据，最终才fetch成功。 这正好验证了strace命令中为什么每次read时都会卡好几秒。

 

7. 此时， 我们可以在抽取进程的配置文件中添加fetch选项：fetchoptions nousesnapshot ，也即不要通过快照来fetch数据。

8. 添加完该参数后，该抽取进程在两个小时内追平数据。