在OGG日常运维过程中，如果发现OGG同步进程延迟很高，该如何解决呢？通过本文的案例，让你知道如何分析和处理复制进程的延迟问题！

查看延迟情况

使用下列命令，查看进程延迟情况：

GGSCI (coredb01) 3> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING                                              
REPLICAT    RUNNING     REPCRE      15:28:21      05:48:19

从上面的输出结果可以看到：

（1）Time Since Chkpt 延迟时间为5个多小时，该延迟时间指replicat进程产生最近的一个检查点到目前为止有多长时间没有更新了，即最近一个检查点与当前系统时间的时间差。长时间未更新，说明有大事务执行时间较长，尚未执行成功。

（2）Lag at Chkpt 延迟时间为15个多小时，该延迟时间指replicat进程处理最后一条记录的操作系统时间和此条记录在trail文件中记录的时间戳的差值，需要注意的是lag延迟只有在检查点更新时才会更新，所以这个值不是实时更新的。

查看事务的提交情况：

GGSCI (coredb01) 93> send repcre,status

Sending STATUS request to REPLICAT REPCRE ...
  Current status: Processing data
  Sequence #: 224
  RBA: 230,877,725
  1,504 records in current transaction.

通过send repcre,status查看事务提交的记录非常慢

从上面的分析可知，目前OGG进程再执行一个大事务，且没有及时提交导致延迟，那如何找到当前是在执行什么样的语句呢？

查找当前执行的SQL

我们需要分析一下，当前的复制进程再执行什么样的语句，有什么等待事件，通过以下命令进行查看：

col username for a15
col sql_text for a100
set linesize 400
select a.inst_id, a.username, a.sid, a.serial#, a.status, a.sql_id,b.sql_text, a.event
  from gv$session a,gv$sql b
 where a.status = 'ACTIVE'
   AND a.program like 'replicat%'
   AND a.inst_id=b.inst_id
   AND a.sql_id=b.sql_id;

可以看到，当前正在执行的一条delete语句和它相关等待事件。

查看语句的执行计划

需要执行这么久，是不是它的SQL效率执行太差了？需要看一下它的执行计划：

set linesize 400;
select plan_table_output
 from table(dbms_xplan.display_cursor('6c6jxcn11ab52')); 

虽然看到这条语句有走了一个索引，但发现该索引列的选择性太差了，创建了另外一个选择性更好的列来做索引

对比一下，可以看到使用新创建的索引，它的消耗更少，执行效率更高！

当然，造成复制延迟高的问题，不止这么一种，具体问题具体分析了，本文只是提供了一种解题思路！