最近，在GoldenGate(11.2.1.0.1 for 10g)的目标库上发现一个很有趣但又很扰人的问题。事情是这样的，有用户反映说在目标库上的一张表上有两个字段(DZFAILFLAG,REMARK)的值与源库的不一致。
检查了一下源库与目标库的GoldenGate进程，两边都运行的很好，也没有报任何错误。查看了一下源库和目标库上那张表的记录数，两边的记录数是一样的，但确实有些记录的值是不一致的！而且当源库的记录数增加时，目标库的记录数也跟着相应增加：
-
源库：
-
11:17:37 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
-
-
COUNT(*)
-
----------
-
980489
-
-
11:18:07 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
-
-
COUNT(*)
-
----------
-
980490
-
-
11:18:43 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
-
-
COUNT(*)
-
----------
-
980493
-
-
11:19:44 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
-
-
COUNT(*)
-
----------
-
980498
-
-
-
目标库：
-
11:17:43 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
-
-
COUNT(*)
-
----------
-
980490
-
-
11:18:53 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
-
-
COUNT(*)
-
----------
-
980493
-
-
11:19:38 SQL> SELECT COUNT(*) FROM LISDATA.LDCONTINVOICEMAP;
-
-
COUNT(*)
-
----------
-
980498
也就是说复制进程是在工作的，而且工作的很正常！尝试对源库上的某条记录的DZFAILFLAG,REMARK进行更新，结果很让人失望，在目标库的这两个字段的值死活都不更新！考虑到这张表的记录还不算多，于是就对这张表重新进行了初始化。经过一番折腾，表终于重新初始化完成了，满怀着希望重新尝试对源库上的字段进行更新，结果让人抓狂，还是不更新！没办法，只能去分析一下trail文件，看看到底发生了什么事，用logdump打开相应的trail文件，定位到相应的位置：
-
2013/08/20 12:50:55.000.000 FieldComp Len 48 RBA 17500895
-
Name: LISDATA.LDCONTINVOICEMAP
-
After Image: Partition 4 G s
-
0000 0010 0000 000c 3330 3030 3030 3030 3130 3335 | ........300000001035
-
0001 0005 0000 0001 3100 0200 0f00 0000 0b38 3330 | ........1........830
-
3130 3030 3030 3032 | 10000002
-
Column 0 (x0000), Len 16 (x0010)
-
Column 1 (x0001), Len 5 (x0005)
-
Column 2 (x0002), Len 15 (x000f)
从trail的记录里可以看到，EXTRACT只抓取到了主键列(列0，1，2是这张表的主键)，而要更新的那两列没有抓取到！试着重启了一下EXTRACT进程，结果更新就一切正常了！
了解到字段DZFAILFLAG,REMARK是前两天刚刚新增加的，而更新丢失恰恰就发生在这两个新增字段上。也就是说当对表增加新字段，如果不重启EXTRACT进程，就无法抓取到新的字段信息！这样的话，那如果使用GoldenGate的DDL复制功能，即使DDL复制工作正常，是不是应该也会碰到这样的问题？那GoldenGate的DDL的复制功能岂不成了摆设？已经开了SR给ORACLE，不知道是不是GoldenGate的BUG。在这之前，各位在做DDL前，还是先把EXTRACT先停掉。
GoldenGate更新丢失问题
原文：http://blog.itpub.net/13885898/viewspace-1651405/
