前言

GoldenGate几乎支持市面上流行的所有主流的操作系统平台和数据库。
博主所在单位目前使用Oracle GoldenGate将各个业务生产库汇聚到一起做数仓实时ODS平台, 我们采用异构同步，即源端同步过来的表在ODS新增了一个etltime字段，用来记录当前数据变更时间。 为了记录数据的事务变更历史记录，我们将数据的变更记录映射同步到一张tab_name_audit表中。为了防止源端业务库误删数据，我们将被删除的数据映射同步到一张tab_name_his表中。原表映射到ods后还是正常的映射同步dml操作。

最近源端库有一批大表做了DML变更，然后发现某个replicat进程一直在延迟，但是数据库整体挺空闲，就怀疑是否卡在某个大表的dml同步上了！于是用下面的检查过程来确定了问题。

一：按照rep的进程名进行 ps -ef | grep ，获得rep的进程PID

通过下面命令找到当前正在运行的replicat进程：

[Oracle@hosta ~]$ ps -ef | grep repfull
oracle  27906 27861  0 18:01 pts/7    S+    0:00              \_ grep repfull
oracle  27603 20773  1 17:03 ?        Ssl    0:51  \_ /u02/ggs/replicat PARAMFILE /u02/ggs/dirprm/repfull.prm REPORTFILE /u02/ggs/dirrpt/REPFULL.rpt PROCESSID REPFULL USESUBDIRS

二：按照rep的进程PID 进行 ps -ef | grep，以获得27603产生的LOCAL=YES的进程

通过步骤一，获得了replicat进程的进程id，然后通过ps命令获得当前正在操作数据库的进程，操作数据库的进程应该是通过本地访问的数据库，那么进程信息应该是包含(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))的，看下面结果，可以确定进程id:27607就是操作数据库的replicat进程。

[oracle@hosta ~]$ ps -ef f | grep 27603  
oracle  27910 27861  0 18:01 pts/7    S+    0:00              \_ grep 27603
oracle  27603 20773  1 17:03 ?        Ssl    0:52  \_ /u02/ggs/replicat PARAMFILE /u02/ggs/dirprm/repfull.prm REPORTFILE /u02/ggs/dirrpt/REPFULL.rpt PROCESSID REPFULL USESUBDIRS
oracle  27607 27603  2 17:03 ?        Ds    1:41      \_ oracleorcl (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))  ---->这一个就是

三、查询sql信息，分析执行计划

上面已经获得了操作数据库的replicat进程id，然后通过下面sql查找此进程会话执行的SQL ID:

   SELECT sql_text,sql_id 
    FROM 
    v$sqltext a 
    WHERE a.hash_value = (
    SELECT sql_hash_value
     FROM v$session b 
    WHERE b.SID =( 
    select s.sid 
    from v$session s,v$process p
     where s.paddr=p.addr and p.spid='27607'))  ---> 替换上27607
    ORDER BY piece ASC;

根据进程会话id就找到了当前replicat进程正在对哪个表做dml操作，以及相关dml语句，然后将SQL ID套入到dbms_xplan，然后看当前SQL的执行计划：

select plan_table_output
 from table(dbms_xplan.display_cursor('6ufrk02y1h6u5'));  --->替换为上一步查询得到的sql_id，查看其执行计划。 

四、确定问题原因，优化SQL

从上面一系列步骤看当前replicat进程执行的sql执行计划看，当前正在对一个大表的审计表做更新，而且源端变更的数据量级在200多万，而这个审计表未添加主键，而replicat又是一条条sql执行的，所以要走200万次全表扫描。确定了问题原因，在此表给原表对应的主键字段添加索引后。停止replicat进程，并清理当前SQL 缓存游标，然后再次重新启动replicat进程，发现这时此sql走了索引唯一扫描，replicat进程应用效率大大提升，大概10分钟后数据就已经同步完成，延迟恢复正常。因为这里SQL涉及内部信息，所以就不贴上来了。

总结

生产操作要慎重，索引要维护好。