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

于是我就开始简单排除了一下。

排除的步骤如下：

1. 首先到源端查看一下是否有大事务发生。使用命令 GGSCI (zlf-lis-ogg-downstream) 2> send extract ext1,showtrans

   

   经过排除后，并不是大事务造成的。

2. 到目标端的数据库上看看，数据正在做什么，我是通过目标端的gv$transaction入手的，看看有什么事务在执行。

   表示目标端正在做什么。

   于是我使用如下的sql排查。

3. 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，在插入的操作，感觉应该是统计信息不准备造成的。于是我决定收集一下表的统计信息。

4. 收集表的统计信息，

   
   

5. 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

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

   
   

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

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