一次ogg pump extract lag time延迟大的调优记录

一次ogg pump extract lag time延迟大的调优记录

1.环境说明
源端：DB2v10.1.4数据库 安装12.1的ogg
目标：oracle 9i数据库 安装11.1的ogg

2.性能问题描述
在db2端，配置的一个primary extract进程，一个pump extract进程，primary进程抽取DB2的数据没有lag延迟，但是pump进程的lag time有20多个小时
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT RUNNING EDB2_001 00:00:00 00:00:06
EXTRACT RUNNING PDB2_001 24:15:00 00:00:03

3.尝试过程
ogg日志中没有任何报错，lag time 也会减少，但是远远比不上增长的时间，所以很明显的一个性能瓶颈问题，个人当时是这么认为的。

查看ogg 官方文档里的Troubleshooting and Tuning Guide，看到一些pump进程的优化参数：
PASSTHRU
Using pass-through mode, you can cascade the captured data to a data pump on an
intermediary system that has no database installed on it. Source and target table names
and structures must be identical; no filtering, column mapping, SQLEXEC functions,
transformation, or other functions requiring data manipulation or translation can be used.
我的进程里没有使用column map、SQLEXEC过滤等，所以我在参数里添加了passthru参数

TCPBUFSIZE
The TCPBUFSIZE option controls the size of the TCP socket buffer that Extract will try to
maintain, allowing larger packet sizes to be sent to the target system. You can use the
following formula as a guideline for further experimentation to determine the optimum
buffer size for your network

TCPFLUSHBYTES
Controls the size of the buffer, in bytes, that collects data that is ready
to be sent across the network. When either this value or the value of the
FLUSHSECS parameter is reached, the data is flushed to the target.
The default is 30,000 bytes. Valid values are from 1000 to 200000000
(two hundred million) bytes, but should be at least the value of
TCPBUFSIZE
详细解释的意思是可以增加传输的大小

pump进程部分参数如下：
rmthost 192.3.1.8, mgrport 7909, TCPBUFSIZE 2175000 ，TCPFLUSHBYTES 2175000
PASSTHRU

然后重启生效

然后观察了一段时间，发现lag time有明显的下降，以为问题已经得到了解决，第二天来一看，发现lag time依然处于增大的趋势。

4.解决问题

看了些golden gate Performance Best Practices的资料，里面也确实说明了passthur参数会优化传输效率，后来发现了有个实例描述如下：把架构改成多个parimary+pump+replicat的架构，可以突破由于操作系统限制原因，导致单个ogg进程达到某方面瓶颈的，于是我把我的ogg改成了4组parimary+pump+replicat的架构，每组进程负责不同的表，然后所以进程直接alter extract XXX，eof （DB2里postition到最新日志的参数为eof）

运行一段时间后发现，有3组进程几乎是0延迟，但是有一组依然产生了很大的lag 延迟时间。

所以配置都一样，只有里面的表不一样，所以执行了stats extract XXX,total来查看出现lag time的pump进程，发现有一张表的DML操作非常频繁，几分钟内增删改的操作达到了一百多万次，于是尝试把这张表注释掉，重启进程，发现lag time 噌噌的减少！到此终于找到了问题的原因，就是因为这张表导致。

后来我单独建立了一组进程，用来抽取、传递、应用这张表，这样能保证其他表同步状态的正常。如果大家以后碰到类似情况，条件允许的情况下，ogg里删掉这样表也是可以的。

5.总结

碰到问题后，以技术的角度去解决，如果实在是难以突破的话，可以换个角度去思考，说不定能发现些意想不到的东西！