可能问题分析:
1、源端E进程处于abend状态且长时间未解决,导致pump和Replicat进程均出现延迟
2、源端有大表做批量更新操作(比如对历史数据插入、更新、删除几千万上亿条数据)
3、表没有主键或唯一索引,导致同步更新时出现全表扫描
4、Replicat进程里面的表过多,处理不过来
5、MGR管理进程挂死
6、网络中断或主机故障,导致目标端与源端通讯异常
解决问题一系列办法:
我们通过数据库与OGG进程两个层面来简单讨论一下都有些什么方法缓解这一问题。
1、在复制端数据库删除不必要的索引。我们在做OGG数据初始化时,大多数都是将表所用索引导入到目标库。我们知道索引的建立对于查询的帮助很大,对插入与更新就不尽然了。而一般情况下我们的源端与目标端同步表的实现功能往往是不一样的,当我们源端复制表索引较多,目标端查询用不到时,我们可以drop掉这些多余索引。
2、复制端更改分区表索引类型,将分区表的全局索引修改为本地索引,这个情形适合分区较多,数据较大的分区表的复制,本地索引对分区表的插入更新效率更高。
3、复制库表分析。对有条件的复制端数据库我们可以定期的进行对复制表进行表分析,获得最新的表统计信息。
4、删除表历史数据。这样做的原因想必大家都了解。但这种情况比较特殊也比较危险,适用只有插入操作的日志表。在没有配置get truncate参数或目标端不需要历史数据时可以考虑。
分析问题及解决问题:
下面我们来讨论下OGG软件层面怎么缓解延迟这一问题:其实就是一个字’拆’。OGG复制进程的原理是单个复制进程