goldengate replicat优化思路以及案例讲解
【goldengate架构图】
注释:goldengate通过抽取源端日志写入trail(当然可以跳过),replicat应用trailfile中数据到目标端(可能是数据库也可能是消息队列中),replicat写入性能取决于ogg和目标端，ogg可能存在非优化配置或者目标端配置问题.
【goldengate replicat参数优化】
goldengate replicat常见优化参数：
grouptransops:将源端原始事务进行合并后批量提交,但是不会破坏原始事务一致性，合并是按照操作记录来计算，不是按照事务数来合并计算.例如A事务影响3条记录，B事务影响4条记录，C事务影响5条记录.此时grouptransops此时设置10，那么3个事务被合并一起提交(如果说3个事务间隔过来不一定合并，因为可能一个事务就提交了，否则A事务可能很久都不会被提交的,出现饿死情况)--参考上个文章，在空闲数据库，ogg延迟问题
maxtransops:对于是拆分事务，将大事务拆分小事务进行提交且会破坏事务完整性,特定场景会使用的，例如全插入的事务可以拆分，排错可以设置maxtransops为1
batchsql:也是将源端原始事务按照相同类型(相同表、相同操作类型、相同列)进行合并放在不同batch中组成一个queue.与grouptransops区别比较大，batchsql有自己batch引擎通过array方式提交，例如一次合并1000条一次提交到dbms，grouptransops是一条一条提交到dbms(one by one).
备注：
虽然batchsql可以提升性能,根据官方说明平均每行改变是100bytes长度记录，可以提升300%的性能,当改变达到5000bytes,则效果不明显，测试发现特定情况下(500以下),性能提升更多，尤其是单一类型操作的.同时batchsql会使用更多内存，默认是20m大小,如果batchsql设置queue的太大，则会使用更多内存.
【batchsql限制】
1、存在lob、long等大字段时候
2、存在除主键之外不能包含唯一索引
3、语句长度不能超过25k.
3、sql导致错误，例如冲突之类
【goldengate replicat延迟案例】
--RTEST延迟124小时.
REPLICAT RUNNING RTEST 124:11:03 00:00:01
--RETEST参数配置
replicat retest
userid goldengate, password xiaoxu
--grouptransops 2000
batchsql
reportcount every 1 hours, rate
discardfile /ogg1121/dirrpt/retest.dsc, purge,megabytes 5000
discardrollover at 14:00
dynamicresolution
MAP SOURCE.XIAOXU, TARGET TARGET.XIAOXU;
--通过使用GROUPTRANSOPS和BATCHSQL性能对比
采用grouptransops 2000方式
*** Total statistics since 2019-03-15 08:37:56 ***
Total inserts/minute: 4836.89
Total updates/minute: 0.00
Total deletes/minute: 0.00
Total discards/minute: 0.00
Total operations/minute: 4836.89
采用batchsql方式
*** Total statistics since 2019-03-15 08:46:06 ***
Total inserts/minute: 5268.69
Total updates/minute: 0.00
Total deletes/minute: 0.00
Total discards/minute: 0.00
Total operations/minute: 5268.69
【如何优化replicat延迟】
--goldengate参数优化
通过更改goldengate replicat参数后，grouptransops--->batchsql，性能虽然有提升，但是只有10%左右，明显没有达到期望的值且本身插入性能也没有达到期望，每分钟4800条,grouptransops平均每条插入时间是12.5ms,batchsql平均每条插入时间是11.3ms.对于单条插入平均相应时间太慢了，但是不能说明数据库有问题。从ogg角度来说，单一进程已经是没有太多优化空间,可以考虑拆分进程等方式解决,可以从数据库角度看下是否存在优化空间.
--数据库角度优化
1、分析数据库性能
oracle有awr，mysql可以分析慢查询 2、分析表结构以及索引设计
表的索引多少、索引个数以及索引类型.
【本次案例原因分析】
从ogg角度已经无太多优化空间.从数据库角度分析下.
本次案例中是oracle数据库，表是分区表(按天分区,保留90天)，索引个数是4个，3个全局索引和1个分区索引，字段长度是294byte.表中无lob等大字段.主键是varchar2(50).
性能数据:
每分钟4800条,grouptransops平均每条插入时间是12.5ms
每分钟5300条,batchsql平均每条插入时间是11.3ms
索引数据:
备注:其中全局索引的集群因子跟表数据基本保持一直,这种说明数据都是无序的，通过索引查找数据时，每次查找数据都在不同数据页上，导致IO性能很差.
优化全局索引修改local索引后测试性能:
备注性能:grouptransops每次插入数据是0.39ms,batchsql每次插入数据是1/5的0.39ms，所以插入慢不一定是数据库问题，有可能是表设计问题，改成local index对于查询的影响与insert数据性能需要折中考虑，本次是优化思路。
把主键从global改成local的效率（主键且包括3个其他索引非空表)采用grouptransops 2000方式
*** Total statistics since 2019-03-14 14:31:44 ***
Total inserts/minute: 152058.02
Total updates/minute: 0.00
Total deletes/minute: 0.00
Total discards/minute: 0.00
Total operations/minute: 152058.02
把主键从global改成local的效率（主键且包括3个其他索引非空表)采用batchsql方式
*** Total statistics since 2019-03-14 14:24:58 ***
Total inserts/minute: 773252.89
Total updates/minute: 0.00
Total deletes/minute: 0.00
Total discards/minute: 0.00
Total operations/minute: 773252.89
【性能对比】
