@TOC
前言
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涉及内部信息，所以就不贴上来了。
总结
生产操作要慎重，索引要维护好。
