第49期 OGG同步延时问题排除

最近经常收到ogg数据同步验证的邮件，一开始没注意，以为延时是正常现象，以为有业务执行了大事务造成的，也没放在心上。但是最近比较频繁，并且延时的时间还比较长。 于是我就开始简单排除了一下。排除的步骤如下：

首先到源端查看一下是否有大事务发生。使用命令 GGSCI (zlf-lis-ogg-downstream) 2> send extract ext1,showtrans 经过排除后，并不是大事务造成的。

到目标端的数据库上看看，数据正在做什么，我是通过目标端的gv$transaction入手的，看看有什么事务在执行。表示目标端正在做什么。于是我使用如下的sql排查。

select b.inst_id,
       b.sid,
       b.serial#,
       b.username,
       b.SQL_ID,
       l.SQL_FULLTEXT,
       wait_class,
       state,
       SECONDS_IN_WAIT,
       XIDUSN || '.' || XIDSLOT || '.' || XIDSQN "XID",
       (START_SCNW * 4294967296) + START_SCNB "Start SCN",
       SES_ADDR
  from gv$transaction a, gv$session b,gv$sql  l
 where a.SES_ADDR = b.saddr and b.SQL_ID=l.SQL_ID

看到有一个sql在执行，也正是ogg同步的数据。 sql的执行计划是 index fast full scan，这个执行计划虽然使用的索引，但是执行的索引快速全扫描。这个表经常执行delete，在插入的操作，感觉应该是统计信息不准备造成的。于是我决定收集一下表的统计信息。

收集表的统计信息，

SQL> begin
  2    DBMS_STATS.GATHER_TABLE_STATS(
  3      ownname          => '用户',
  4      tabname          => '表',
  5      estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
  6      method_opt       => 'FOR ALL COLUMNS SIZE AUTO',
  7      degree           => DBMS_STATS.AUTO_DEGREE,
  8      cascade          => TRUE,
  9      no_invalidate    => FALSE
 10  );
 11  end ;
 12  /
PL/SQL procedure successfully completed

再次查询表的执行计划，执行计划变成了index unique scan

经过和业务同事了解，这个是一个团险的业务，因为单子比较多，团险的承保的人员经常变动，于是业务经常需要先删除表中的数据，在经常插入操作，于是就有了，表中数据经常变动，统计信息不准备的问题。

因此让业务调整承保方式，从根本上解决问题。