在Goldengate的环境中我们可以从以下几个方面对OGG的性能进行优化:

1.操作系统层面I/O、参数等;

2.网络层面;

3.数据库或应用层面;

4.OGG的进程配置层面;

因为12c以前的goldengate各个进程处trail文件是串行(12c开始就是并行的了)处理的，所以当源端一个大事务提交后因网络带宽等问题影响该事务提交后的其他小事务传输。因为OGG中的ext/rep都是独立的进程，因此我们可以根据事务量对schema中的数据进行分组拆分达到大事务不影响其他事务的传输的目的。

1.事务拆分的注意事项:

1).网络及硬件性能可以满足拆分后的需求(如果I/O网络等本来不好则需要权衡);

2).GLOBALS中的MAXGROUPS限制够用(默认最大组数300，最大支持5000);

3).最好将相关联的DML/DDL放在同一个进程确保数据完整;

4).虽然一个datapump进程可以同时往多个目标端多个trail推送数据，但是建议一个目标端配置一个datapump进程防止一个目标失败引起进程abend；

5).一般ext/dp进程都不会产生延迟而rep进程会，但是 同一个trail不要被3个rep进程同时读取，它会产生磁盘争用;

6).在同一个dp进程可以将不同数据推送到不同的主机和不同的trail;

7).当把同一个表中的数据根据@RANGE函数拆分时建议在ext中进行，因为REP处拆分可能会因为扫描整个trail而影响性能;

2.配置步骤：

1).可以在第一次初始化前根据业务统计信息合理规划后一次实施;

2).也可以在使用一段时间后进行统计信息收集并规划拆分方式；

3).拆分前确保所有进程停止且trail中的数据全部被应用到目标端;

4).执行进程拆分并根据拆分方案将schema中的数据拆分给不同进程处理;

5).基于拆分前的点启动进程(extseqno,extrba);

1.诊断步骤

1).在源端的ext/dp进程执行以下命令获取最近10个检查点

INFO EXTRACT <group>, SHOWCH 10

2).查看检查点并找到最近的一个checkpoint并记录它的SEQ,RBA和TS:

Historical Checkpoint  #1 Detail:(会有个当前检查点)

3).源端确认进程的rba是否在不断更新:

info <group>

4).目标端确认REP的状态

Sending STATUS request to REPLICAT REPSRC ...
  Current status:  At EOF(表示trail数据已处理过，还可以是:wait for data to process)
  Sequence #: 6
  RBA: 42080
  0 records in current transaction

5).问题判定:

a.ext的检查点快速更新而dp进程的检查点更新缓慢，且rep进程的状态处于delay或EOF

b.如果rep进程的状态处于waitfor data to process且extseqno严重落后于dp进程写的trail,则说明rep进程或目标数据库需要优化

2.改善方案:

a.增加网络带宽；
b.调整RMTHOST的TCPBUFSIZE选项达到增加发包大小的目的

1.问题诊断

2.改善方案(仅从配置上来说)：

1).将读写最频繁的Trail放到I/O较好的存储上；

2).调整CHECKPOINTSECS参数控制ext/rep产生检查点频率;

3).使用GROUPTRANSOPS参数使rep对小事务组合和作为一个事务进行操作;

4).使用EOFDELAY参数调整进程监测是否有新数据周期(不建议);

5).使用MAXTRANSOPS拆分大事务

因为对于goldengate来说，要将trail中的数据应用到目标端实际上是将他们构造成sql语句在目标端执行所以目标端数据库的性能也会一定程度影响rep进程的性能。则我们考虑从以下几方面去优化rep的效率：

1.调整open cursors:从MAXSQLSTATMENTS参数和数据库层面的参数；

2.确认是否有行迁移/行链接的情况；

3.确认执行计划是否需要优化;

4.设置事务超时时间(不建议设置)

5.确认目标端的统计信息是否准确