GoldenGate Replicat 进程延迟问题处理案例分享

关注“IT实战基地”，与行业大咖交流学习！

概要

Oracle GoldenGate软件是一种基于日志的结构化数据复制软件，它通过解析源数据库在线日志或归档日志获得数据的增量变化，再将这些变化应用到目标数据库，从而实现源数据库与目标数据库同步。但在OGG日常维护的过程中有经常遇到OGG replicat进程延时的情况，replicat进程延时代表数据同步出现滞后，目标库的数据不完整，如果目标库作为一个OLAP库，那相对应的业务功能就会受到很大的影响。通过本次案例分析，你将知道如何分析和处理OGG replicat进程延时的情况。

l故障描述

某一日，客户反馈在办理业务时查询不到相关的数据，影响大部分地区业务使用。运维人员接到此报障后，对系统进行检查发现，业务数据库的OGG RZH01进程延时一个小时，数据更新不及时。

l处理过程

可能问题分析：

OGG进程长时间延迟的原因可归结为如下：

1、源端E进程处于abended 状态且长时间未解决，导致Pump 和Replicat 进程均出现延迟；

2、源端有大表做批量更新操作(比如对历史表插入、更新、删除几千万上亿条记录)；

3、表没有主键或唯一索引，导致同步更新时出现全表扫描；

4、Replicat进程里面的表过多，处理不过来；

5、MGR管理进程挂死；

6、网络中断或主机故障，导致目标端与源端通讯异常；

解决办法：

根据问题分析出的几点原因进行排查；

通过登录目标端数据库的ogg控制台，执行命令info all检查ogg进程延迟的情况：

检查发现，目标端RGZ01进程延迟将近1个小时，进程状态running，源端抽取进程和投递进程都是running状态，没出现延迟情况，MGR管理进程以及源端和目标端的网络通信正常；经过排查，怀疑是源端数据库有做大批量的DML操作。

为了验证是否大批量的DML操作导致ogg进程延迟，通过如下方法来了解哪些表有可能存在批量更新；

执行命令stats RGZ01检查

通过检查RGZ01进程，发现几张表有几百万的大批量DML语句更新操作，更新非常频繁，由于RGZ01进程里面的表过多，处理不过来，导致延迟比较大。

RGZ01进程延迟达将近1个小时，我们可将这几张表分离出来，另外新建一个Replicat 进程，手工重导数据后再做同步，减少一个进程处理大批量表更新操作，处理数据速度慢（由于情况比较紧急，暂时不对RGZ01进程进行拆分处理）。

出现ogg进程延迟大的另一种可能，对于没有主键或索引的大表，更新时有可能因没有使用正确的索引导致全表扫描而变得非常慢，可通过如下办法查出sql 语句；

查找该GG进程的PID号；

$ more ./dirpcs/RGZ01.pcr

PROGRAM REPLICAT PROCESSID RGZ01 PORT OGG.7231 PID 73589

查找该GG进程（73589）相应的数据库会话；

SQL> select sid,serial#,module,event,sql_id,seconds_in_wait,last_call_et,status from v$session where process='&pid';

查看该会话执行的sql 语句；

SQL> select sql_text from v$sqltext where sql_id='&sql_id' order by piece;

查看该语句的执行计划；

SQL> select * from table(dbms_xplan.display_awr('sql_id'));

根据执行计划的情况，为该表加上临时的索引；

如果出现Replicat 进程执行某条语句时挂死的情况，可通过上述方法查出会话，kill 该会话（alter system kill session 'sid,serial#' ），并在操作系统级kill 该进程，重启Replicat 进程

l结论和建议

处理ogg进程延时故障时，处理方法基本都是上面列出的几点，大部分OGG进程延迟都是由于数据库大批量频繁的做了DML更新操作导致的。在处理过程中可以使用排除法，一步步缩小范围，确认导致问题的原因。

现在，你学会了吗？如对该经验分享有疑问，可进入小程序进行技术交流，技术人员之间互相讨论，并且会有专门的技术专家答疑解惑。

—END—

▼