ogg mysql 写入慢_OGG复制进程延迟高，优化方法一(使用索引)

日常运维过程中，可能发现OGG同步进程延迟很高；

本篇介绍其中的一种方式。

OGG复制进程，或者说同步进程及通过解析ogg trail文件，输出dml语句，在目标库执行dml操作，那么延迟高可能性其一、执行dml操作效率太低。 本篇不考虑并发过高或其它原因。 本次只考虑是执行update or delete的时候SQL效率执行太差！

导致OGG复制进程延迟很高。

GGSCI >info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

REPLICAT RUNNING RP1000:00:00 00:00:03

延迟说明参考

https://www.onekbit.com/ViewBlog/blog/BID20200408100342

一 、Time Since Checkpoint 过高

指ogg的extract或replicat进程产生最近的一个检查点，再从这个检查点到目前为止有多长时间没有更新了，即最近一个检查点与当前系统时间的时间差。该值可以通过info看到是在不断变化(特别是当处理长会话时，会持续增长，直到处理完该长会话)。

对于复制进程来说，如果Time Since Chkpt 延迟有2个小时，说明这个进程存在2个小时检查点未更新，也就说明有一个或多个组合成的大事务，执行了2个小时，并未执行成功？？？

正常情况下，OGG遇到异常报错，导致OGG进程中断Time Since Chkpt 50个小时后，解决报错后，启动该进程，一般来说2分内，会执行成功最少一个事务，会写入新的检查点，延迟的50个小时，会自动转换为lag at chkpt 50小时延迟。

异常情况或者说需要优化调整的情况是，启动进程，发现time since chkpt 延迟一直递增，不减少。说明存在事务未执行完毕。

实际遇到的情况1，进程同步4个表，其中一个表很大10G，并且目标端无主键！！！

因此目标端执行一条update sql执行效率非常低。  如何处理？？？

1.表存在主键

select   *   from   user_cons_columns

where   constraint_name   =   (select   constraint_name   from   user_constraints

where   table_name   =   'BST_FAVORITE'  and   constraint_type   ='P');

2.对OGG复制进程添加参数指定主键列

map source_owner.table_name target target_owner.table_name;

添加参数

map source_owner.table_name target target_owner.table_name，keycols(primary_column_name);

3.对于不存在主键的表呢？？？

select count(*) from xxx; 得到表的数量，如果表很大，不执行最好。

通过dba_tab_columns 根据NUM_DISTINCT 得到最多distinct的列，及选择性好的列。

SQL> select COLUMN_NAME,NUM_NULLS,NUM_DIST

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！