说明
Time Since Checkpoint 可以理解为最后一次的检查点时间与当前时间的差，因此时间越大，说明这个进程启动后最后一次完成事务的时间非常长。
可能性
1.如果存在大表,且SQL执行计划全表扫描，可以参考如下，使用索引存在的列，加快同步速度；
https://www.cnblogs.com/lvcha001/p/13469500.html
2.遇到OGG复制进程延迟50分钟！对OGG Session进行分析，发现这个会话在一个insert sql 执行时间最长！
因此，可以得到一个结论，就是存在大事务导致我们认为OGG复制进程启动后，Time Since Checkpoint 一直增长，导致我们担心复制进程存在异常的问题。
此事：存在2个解决方案；(暂时只知道这么多)
A：将大的事务，拆分为多个小的事务，这样Time Since Checkpoint 值不存在延迟很大，因为小的事务提交非常快，不存在执行几十分钟的延迟【但是OGG复制进程的延迟，本质并未解决。】
B：真正解决insert 大事务导致Time Since Checkpoint 过高的问题，建议对OGG进程进行拆分，并行[,filter(@range(6,6,column_name))]。
C:其它方法。或参数。
使用方法A: 参数！
https://community.oracle.com/message/10688233
默认情况下，OGG是严格按照源端产生的交易依次进行提交，本身不改变交易的边界，但是有时候为了避免大交易需要读取大量队列文件以及在目标端数据投递需要大量资源，OGG提供了MAXTRANSOPS参数用于将大交易拆分为较小的交易多次提交，
除去性能的提升外还能让管理人员更为实时的看到数据投递的变化。例如： MAXTRANSOPS 1000 表示如果单个交易中的实际数据变化量超过了1千，replicat会每1千条进行一次提交。由于OGG的队列中全部是提交了的交易，使用此参数后只是交易被拆分为了多个依次提交，并不改变数据变化的顺序，所以对一致性并不影响。 需要注意的是使用MAXTRANSOPS时，如果出现了系统异常如目标数据库宕机，有可能出现Replicat的检查点还处在交易开始点，但实际已经投递到大交易的中间某个点了，这样再次重启会报告一些数据错误。
此时可以通过使用reperror default,discard将这些冲突数据写入discard文件，等待追上后再去验证这部分数据在两端是否一致，一般情况下不需要重新初始化。
疑问？ 使用这个参数，真的能加快OGG复制进程的应用速度吗？ 实际使用并未明显感觉到差异，但是管理上看到复制进程rba能快速前滚，避免管理上担心OGG进程hang住或其它问题。
对于加快OGG insert同步, 还是建议OGG复制进程拆分。 或者其它方法。