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—

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20181224G0XNZR00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券