可能问题分析：

1、源端E进程处于abend状态且长时间未解决，导致pump和Replicat进程均出现延迟2、源端有大表做批量更新操作（比如对历史数据插入、更新、删除几千万上亿条数据）3、表没有主键或唯一索引，导致同步更新时出现全表扫描4、Replicat进程里面的表过多，处理不过来5、MGR管理进程挂死6、网络中断或主机故障，导致目标端与源端通讯异常

解决问题一系列办法：

我们通过数据库与OGG进程两个层面来简单讨论一下都有些什么方法缓解这一问题。1、在复制端数据库删除不必要的索引。我们在做OGG数据初始化时，大多数都是将表所用索引导入到目标库。我们知道索引的建立对于查询的帮助很大，对插入与更新就不尽然了。而一般情况下我们的源端与目标端同步表的实现功能往往是不一样的，当我们源端复制表索引较多，目标端查询用不到时，我们可以drop掉这些多余索引。2、复制端更改分区表索引类型，将分区表的全局索引修改为本地索引，这个情形适合分区较多，数据较大的分区表的复制，本地索引对分区表的插入更新效率更高。3、复制库表分析。对有条件的复制端数据库我们可以定期的进行对复制表进行表分析，获得最新的表统计信息。4、删除表历史数据。这样做的原因想必大家都了解。但这种情况比较特殊也比较危险，适用只有插入操作的日志表。在没有配置get truncate参数或目标端不需要历史数据时可以考虑。

分析问题及解决问题：

下面我们来讨论下OGG软件层面怎么缓解延迟这一问题：其实就是一个字’拆’。OGG复制进程的原理是单个复制进程读取队列文件中的数据来匹配自己参数配置表的列表依次以事务为单位还原到目标数据库中执行。所以当我们一个进程中出现多个热点表时，就有可能出现CPU、IO等等待现象造成延迟。这时我们可以将其中一部分热点表拆分到另外一个进程来缓解。具体步骤如下：示例将repa中的test表加入到repb中

一、新建复制进程

edit params repb

—将拆分出来的表放入参数中

map user.test,target user.test

add replicat repyb,exttrail/goldengate/dirdat/xx

二、停止原来的复制进程，并获取rba号

stop repa

Info repa

输出结果如下：

REPLICAT REPA Last Started2017-04-0109:55Status STOPED

Checkpoint Lag00:00:00(updated00:00:02ago)

Log Read Checkpoint File./dirdat/xx091249

2017-05-1816:32:40.000506RBA13442118

三、修改新增进程启动点

alter replicat repb,extseqno91249extrba13442118

四、启动进程

start repa

start repb

有的朋友可能会有疑问，只剩一张表还是有延迟怎么办，方法还是可以拆，方法与上面基本一致：

repa参数：

map user.test,target user.test,FILTER(@RANGE(1,2));

repb参数：

map user.test,target user.test,FILTER(@RANGE(2,2));

其他操作方法与上面一致

test拆分成了2份两个进程进行同步。

分别设置filter(@range(1…n,n)这样就可以拆成n个线程来同步我们延迟大的数据表。

但是此种方法比较极端，稳定性不如整表复制。我测试过，但是数据表只同步了部分数据，可能是参数设置有误，或者版本支持度不够，后来从索引方面找到解决方法就没有深究了。大家有需要的可以研究下，相信此功能还是可以实现的。

当然我们的实际情况可能比上述情况远远复杂得多，甚至有带宽影响投递队列速率从而影响复制进程延迟的。我们就需要具体原因具体分析了，但总体我们可以从OGG软件进程配置优化、数据库优化和硬件优化三个方面着手。