OGG目标端丢失数据问题处理

作者简介:丁向辉,现就职于北京海天起点,获有11gOCP、VCP认证,具有多年数据库管理维护经验,服务对象覆盖电信、中行、国税等大型企事业单位,擅长goldengate、数据库的问题处理及性能优化。

概述

近期在部署9I11G数据库OGG同步的过程中,遇到目标端update操作找不到数据,replicat进程abend的问题。OGG源端和目标端信息如下:

OGG源端信息如下:

OS aix 5.3
DB 9.2.0.8
Mode RAC
OGG Version 11.1.1.1.2 OGGCORE_11.1.1.1.2_PLATFORMS_111004.2100

OGG目标端信息如下:

OS Oracle Linux Server release 6.6
DB 11.2.0.4
Mode 单实例
OGG Version 11.2.1.0.24 18876493 OGGCORE_11.2.1.0.0OGGBP_PLATFORMS_140623.2214_FBO

问题说明

OGG源端extract进程参数配置

源端投递进程参数配置

目标端replicat进程参数配置

源端数据库版本为9.2.0.8exp初始化数据的时候,使用flashback_scn参数报错,该问题早期开过SR,但是没有给出处理方法。OGG初始化数据的时候使用的dbms_capture方式获取的SCN,该方式的弊端在于每个表的SCN都不同。目标端Replicat进程使用的filter (@GETENV(“transaction”,”csn”)参数,把同步表放在一个replicat进程里。初始化完成后,replicat进程启动正常,但是在同步数据过程中,目标端会丢失数据。导致update操作找不到对应的行数据,触发replicat进程abend。该问题处理过程如下。

问题处理

出现该问题后,首先考虑的是不是在实施过程中,有步骤遗漏导致的,随即对源端配置进行检查,检查后源端配置均正常,检查目标端同步表相关的触发器,级联删除,JOB等也都正常。排除以上顾虑后,使用Logdump工具分析队列文件,通过分析队列文件来定位问题具体是在哪一端,如果丢失的数据在队列文件,那就是目标端问题,反之,则是源端问题。

使用Logdump分析目标端队列文件

Update丢失数据的表为USER1.TABLE1,该表的4个列COLUMN1COLUMN2COLUMN3COLUMN4为复合主键,通过这4个列可以定位到表中的唯一行。查看DISCARDFILE文件rep_appht,丢失的行信息如下:

使用Logdump分析目标端对应的队列文件,分析如下:

从以上dump信息可以看到丢失的行数据在队列文件中是存在的,说明源端投递过来的队列文件是正常的。可能的情况是replicat进程同步了数据,但是数据被删除掉了,或者该条数据replicat进程根本就没有同步。源端问题排除,检查目标端。

目标端检查

源端USER1.TABLE1表的数据变更量不是太大,使用stats查看相关的抽取进程,该表只有insertupdate操作,没有delete操作。为了验证目标端是否有对表user1.table1delete操作,在目标库开启了该表的审计,操作如下

更改目标数据库的审计参数

该参数默认是DB,在此模式下,如果开启表的审计,只能查看对审计表的操作类型,不能获取具体的SQL,需要更改为DB,EXTENDED才能获取到审计表的具体SQL操作。

开启user1.table1表的delete、insert操作

查看审计结果

replicat参数修改

默认情况下,ogg目标端同步执行的SQL都是绑定变量的,修改replicat参数,更改为非绑定变量模式,这样就能获取到完整带值的SQL语句,便于后面定位问题。

添加以下参数到replicat进程:

参数说明:

Grouptransops 对小事物进行事物合并

Maxtransops 对大事物进行事物拆分

Binarychars/Nobinarychars 控制字符数据是否被视为二进制数据或以空字符结尾的字符串

Nodynsql replicat进程使用SQL文本语句,不使用绑定变量

审计开启以后,在目标端表user1.table1上没有发现delete操作。通过DISCARDFILE文件rep_appht,获取丢失的行数据信息,和捕获到的insert语句匹配,未找到对应的insert 语句。

以上信息说明队列文件里有丢失的行数据,但是目标端replicat进程没有执行相应的操作,造成数据丢失。

问题解决

通过以上分析,定位到了最终的问题,但还是一头雾水,问题该怎么解决?

再次检查replicat进程配置的时候,看到了参数filter (@GETENV(“transaction”,”csn”) >xxxxx,会不会是该参数造成的数据丢失?

为了验证自己的想法,把同步表进行了拆分,一个replicat进程对应一个表,不使用filter参数,参数配置如下:

Repht进程

Repht1进程

重新初始化数据,启动进程

表拆分以后,观察了几天,数据同步正常,replicat进程运行正常,没有丢失数据情况发生。果然是filter (@GETENV(“transaction”,”csn”) >xxxxx参数导致的目标端丢失数据。

遗留问题

问题虽然解决了,但是最根本的原因还没有找到,filter (@GETENV(“transaction”,”csn”)参数配置是没有问题的,并且其他环境该参数也一直在使用,均没有出现丢失数据的情况,为什么这套环境会出现该问题?遇到BUG?在metalink上没有搜到相关的bug说明。为了解开疑惑,目前已经开了SR

经过SR的分析,最后确认以上问题为BUG导致,但由于数据库和OGG版本比较旧,没有相应的补丁可以解决该问题,并且该版本已停止技术支持,SR最后的建议为升级数据库,使用高版本OGG软件。

未经允许不得转载:Oracle一体机用户组 » OGG目标端丢失数据问题处理

相关推荐