GoldenGate在HP-UX上的缺陷,引起同步失败

个人简介:石云华,Exadata中国用户组联合创始人,ORACLE ACE。毕业后一直从事Oracle数据库第三方运维服务工作,拥有十余年电信运营商、保险、税务、电力行业核心系统数据库运维经验。现就职于北京海天起点技术服务股份有限公司,oracle数据库专家组成员,Exadata部门负责人。个人著作有《Exadata实施运维指南》,《Oracle Exadata性能优化》

问题描述:

在某个迁移项目中,需要将HP-UX主机上的某个数据库用户中的数据通过GoldenGate在线迁移至Linux平台。初始化完成后,在目标端启动复制进程,但有一张表同步失败,信息如下所示。

暂时屏蔽掉BB.CONTINFO这张表后,继续启动复制进程,后面一切正常,说明只有这张表存在问题。

问题分析:

下面,我们来分析为什么只有BD.RS_MIGU_CONTINFO.同步失败?

(1)、检查该表在源端数据库中的表级别附加日志。

可见,该表存在附加日志,由(SP_CODE,CONTENT_CODE,VALID_DATE)这三列组成。这三列也是该表的主键列。

(2)、对比该表在源端和目标端数据库中的表结构。

对比后,发现源端和目标端的表结构完全一致。

(3)、暂时还没有想明白问题出在哪,用logdump先看看源端生成的Trail文件中的内容。

从Trail文件来看,当前显示的这条记录是一个update操作,在Trail文件中记录了主键列和修改列的前、后镜像值。因为该表的附加日志是主键列,所以Trail文件中的信息是正常的。

(4)、至此,这个问题有些疑惑了,还没有想明白怎么回事,于是重新回过头再仔细查看报错时的日志,刚才被忽略的一些信息再次进入眼前。

当BB.CONTINFO同步失败之前,目标端的GoldenGate提示这张表上没有唯一键,于是将该表的所有列当作唯一键。

这张表有主键,所以源端的附加日志只只记录了主键列来当作唯一键,用来定位具体的列。目标端和源端的表结构完全一致,理论上,目标端也应该把这个主键列当作唯一键才对,但为什么没有这样做?

(5)、再一次回头查看表结构,这一次又有重大发现,原来这张表的主键当前是disable状态。

至此,整个问题已经完全想明白了。这张表有主键,但处于disable状态,HP-UX上的GoldenGate在添加表级别附加日志时,仍然只将主键列加入附加日志组中,同样,Trail文件中也只有主键列的值和修改列的值。目标端Linux上的GoldenGate在获取这张表的表结构时,发现主键是disable状态,于是只能将所有列当作唯一键列,在解析Trail文件构造SQL语句时,对于update操作,构造出来的SQL语句格式应该为:

然而,在Trail文件中,update操作只记录了主键列的值和修改列的值。这样,就无法正常构造出SQL语句。所以报错信息只有:

如果已经构造出SQL语句,则报错时,会将报错的SQL语句打印出来。

(6)、对于已经disable的主键,在HP-UX上,为什么GoldenGate还是把它当作唯一键列呢?我认为这是GoldenGate在HP-UX版本上的缺陷,这种disable的主键,是无法保证唯一性的,当然也就不能将这种主键作为表级别的附加日志。为了验证这一点,进行了如下测试,在Linux主机上对于这种主键为disable状态的表,添加表级别附加日志时,GoldenGate会将所有列当作唯一键列。

问题处理:

让业务人员确认这个主键是否置于enable,最终,针对该表重新初始化。

未经允许不得转载:Oracle一体机用户组 » GoldenGate在HP-UX上的缺陷,引起同步失败

相关推荐