OGG源端同目标端某个字段数值相差10000倍

来源：这里教程网时间：2026-03-03 16:36:41 作者：

1 业务需求

goldengate源端同目标端检修完成后，进行数据同步，检查相关数据，发现源端同目标端某几个字段的值相差10000倍，如下：源端：SYS@source >select a.rec_id,a.last_read,a.this_read,a.estimate_pq,a.mr_pq from USERA.TABLE_A a; REC_ID LAST_READ THIS_READ ESTIMATE_PQ MR_PQ------------------------ ---------- ---------- ----------- ----------1 .111 .111 .111 .111 目标端SYS@target>select a.rec_id,a.last_read,a.this_read,a.estimate_pq,a.mr_pq from USERB.TABLE_A a; REC_ID LAST_READ THIS_READ ESTIMATE_PQ MR_PQ------------------------ ---------- ---------- ----------- ----------1 .111 .111 1110 1110

2 使用logdump查看源端抽取出来的数据是什么？

2021/04/01 17:05:58.000.254 Insert Len 278 RBA 484408Name: USERA.TABLE_A After Image: Partition 4 G e 0000 0005 0000 0001 3100 0100 0500 0000 0131 0002 | ........1........1.. 000a 0000 0000 0000 0000 0001 0003 0005 0000 0001 | .................... 3100 0400 0500 0000 0131 0005 0005 0000 0001 3100 | 1........1........1. 0600 0500 0000 0131 0007 0005 0000 0001 3100 0800 | .......1........1... 0500 0000 0131 0009 000c 0000 0008 3230 3231 3033 | .....1........202103 3330 000a 000a 0000 0000 0000 0000 0001 000b 0005 | 30.................. 0000 0001 3100 0c00 0500 0000 0131 000d 000a 0000 | ....1........1...... Column 0 (x0000), Len 5 (x0005) 0000 0001 31 | ....1 Column 1 (x0001), Len 5 (x0005) 0000 0001 31 | ....1 Column 2 (x0002), Len 10 (x000a) 0000 0000 0000 0000 0001 | .......... Column 3 (x0003), Len 5 (x0005) 0000 0001 31 | ....1 Column 4 (x0004), Len 5 (x0005) 0000 0001 31 | ....1 Column 5 (x0005), Len 5 (x0005) 0000 0001 31 | ....1 Column 6 (x0006), Len 5 (x0005) 0000 0001 31 | ....1 Column 7 (x0007), Len 5 (x0005) 0000 0001 31 | ....1 Column 8 (x0008), Len 5 (x0005) 0000 0001 31 | ....1 Column 9 (x0009), Len 12 (x000c) 0000 0008 3230 3231 3033 3330 | ....20210330 Column 10 (x000a), Len 10 (x000a) 0000 0000 0000 0000 0001 | .......... Column 11 (x000b), Len 5 (x0005) 0000 0001 31 | ....1 Column 12 (x000c), Len 5 (x0005) 0000 0001 31 | ....1 Column 13 (x000d), Len 10 (x000a) 0000 0000 0000 0000 0001 | .......... Column 14 (x000e), Len 10 (x000a) 0000 0000 0000 0000 0001 | .......... Column 15 (x000f), Len 10 (x000a) 0000 0000 0000 0000 0001 | .......... Column 16 (x0010), Len 5 (x0005) 0000 0001 31 | ....1 Column 17 (x0011), Len 5 (x0005) 0000 0001 31 | ....1 Column 18 (x0012), Len 10 (x000a) 0000 0000 0000 0000 0456 | .........V -- 十六进制的456 转换为十进制的 1110 为什么此列的数据就是正常的 Column 19 (x0013), Len 10 (x000a) 0000 0000 0000 0000 0456 | .........V -- 十六进制的456 转换为十进制的 1110 为什么此列的数据就是正常的 Column 20 (x0014), Len 10 (x000a) 0000 0000 0000 0000 0456 | .........V -- 十六进制的456 转换为十进制的 1110 为什么此列的数据就是异常的，即扩大了10000倍 Column 21 (x0015), Len 10 (x000a) 0000 0000 0000 0000 0456 | .........V -- 十六进制的456 转换为十进制的 1110 为什么此列的数据就是异常的，即扩大了10000倍 Column 22 (x0016), Len 10 (x000a) 0000 0000 0000 0000 0456 | .........V -- 十六进制的456 转换为十进制的 1110 为什么此列的数据就是异常的，即扩大了10000倍 Column 23 (x0017), Len 10 (x000a) 0000 0000 0000 0000 0456 | .........V -- 十六进制的456 转换为十进制的 1110 为什么此列的数据就是异常的，即扩大了10000倍 GGS tokens: 5200 0014 4141 542f 5471 4144 5441 414a 7434 3941 | R...AAT/TqADTAAJt49A 4142 0001 | AB.. 对比以上数据，为什么LAST_READ 和 THIS_READ 列的数据正常，但ESTIMATE_PQ 以后的列数据就扩大了10000倍？

3 对比源端和目标端的表结构，发现一致。

4 咨询目标端业务人员，询问对数据库做的操作，说明除过检修内容，未有其它操作。

5 咨询源端业务系统人员，询问相关操作，说只更改了表结构，COLL_PQ、ESTIMATE_PQ、MR_PQ、ADJ_PQ列表结构从NUMBER(16) 变为NUMBER(16,4)

6 查看OGG的参数配置，发现配置SOURCEDEFS参数，此参数会根据定义文件来录入数据，咨询相关人员，发现未及时更新defgen文件，故导致了源端同目标端的数据差异。

GGSCI (target) 26> view params REPCXX REPLICAT repcjxxsetenv (NLS_LANG=AMERICAN_AMERICA.ZHS16GBK) ---the same as source dbUSERID goldengate, PASSWORD AAdddAS, ENCRYPTKEY defaultSQLEXEC "ALTER SESSION SET CONSTRAINTS=DEFERRED"REPORT AT 01:59REPORTCOUNT EVERY 30 MINUTES, RATEREPERROR DEFAULT, ABENDSOURCEDEFS ./dirdef/cj/xxx.defDISCARDROLLOVER AT 02:30GETUPDATEBEFORES MAP USERA.TABLE_A,TARGET USERB.TABLE_A,colmap (usedefaults,target_write_time = @datenow(), source_change_time = @GETENV ("GGHEADER", "COMMITTIMESTAMP"));

7 更新defgen文件，进行数据传输，发现数据正常

./defgen paramfile ./dirdef/extjc_xsc.prm 源端：SYS@source >select a.rec_id,a.last_read,a.this_read,a.estimate_pq,a.mr_pq from USERA.TABLE_A a; REC_ID LAST_READ THIS_READ ESTIMATE_PQ MR_PQ------------------------ ---------- ---------- ----------- ----------3 .555 .555 .555 .555 目标端SYS@target>select a.rec_id,a.last_read,a.this_read,a.estimate_pq,a.mr_pq from USERB.TABLE_A a; REC_ID LAST_READ THIS_READ ESTIMATE_PQ MR_PQ------------------------ ---------- ---------- ----------- ----------3 .555 .555 .555 .555

总结及反思：

1 根据如上信息，源端同目标端相关表的字段类型一致，如果配置了sourcedefs参数，则OGG会严格按照defgen生成的表的定义文件进行数据录入，如果未及时更新defgen文件，有可能会造成源端同目标端的数据不一致。

2 业务系统检修，未协调相关OGG人员，相关工作没有配合到位，导致源端同目标端数据出现差异。

3 现实场景，在多个工作环境中，发现都是源端修改相关表结构后，目标端出现故障或报错后，才会解决相关问题。那么问题来了，如果源端同目标端是异构，且源端更改表结构后，目标端未及时更新目标端的defgen文件，且目标端的OGG状态正常，但有可能已经造成了数据的不一致。根据如上，为了保证源端及目标端数据的一致性，急需检修管理的规范性，要不然，即使数据发生差异，也无法及时发现问题。等真正用时，已经晚了。