实战golden gate同步KEYCOLS作用与用法

Nivek.cao

我们的一个生产环境，配置好源端和目标端以后，能够正常运行，但是在同步一张表如TABLEA时，会让复制进程Abending掉，检查了report日志和discard文件后，发现现象是源端的INSERT操作可以正常同步而UPDATE操作无法同步，

经检查发现，这个表在源端和目标端都没有主键，而且在目标端的表上我们自己新增了5个字段，遇到这个错误时我们一点头绪都没有，毕竟对golden gate都不太熟悉，包括它的工作原理在一些细节的地方更是没有深入接触到，这个时候我们找来测试环境，想把这个问题一点点的排除定位，看问题最终出在哪。

经测试发现，如果源端和目标端的表字段完全一致，则我们的配置是没有问题的，INSERT操作和UPDATE操作都能够正常同步(这里我们首先将原先抽取进程中的COMPRESSUPDATES改成NOCOMPRESSUPDATES了，但是依然没有解决问题)。 但是当目标端有了我们自定义的字段后，UPDATE操作就不能被同步，这个时候在官方pdf文档里面我去搜索primary key之类的信息，于是找到很多关于KEYCOLS的内容，接着我们就将这个参数配置到我们的复制进程里面，结果可以正常同步，然后放到真实的环境中，也是可以正常同步的，回头来再看pdf文档时，发现golden gate在online同步时，如果发现源表没有主键(同时目标端复制进程也没有指定KEYCOLS参数)，则它的处理方式是利用源表所有字段算出一个虚拟的主键，然后通过这个虚拟主键再去目标表上最相应的操作以保持目标表和源表的同步，但是这个时候因为目标表的字段比源表的字段多，这个虚拟主键在目标表上是找不到任何记录的，因为这一行还有多余的几个字段值。 所以在report日志里面就能看见下面的错误，这里的错误信息关键在于红色字体部分：


2011-05-24 12:58:01  WARNING OGG-01004  Aborted grouped transaction on 'ODSUSER.WTB', Database error 437 ([IBM][CLI
Driver][DB2/LINUXX8664] SQL0437W  Performance of this complex query may be sub-optimal.  Reason code: "3".  SQLSTATE=01602

[IBM][CLI Driver][DB2/LINUXX8664] SQL0100W  No row was found for FETCH, UPDATE or DELETE; or the result of a query is an empty table
.  SQLSTATE=02000

).

2011-05-24 12:58:01  WARNING OGG-01003  Repositioning to rba 1325 in seqno 0.

2011-05-24 12:58:01  WARNING OGG-01154  SQL error 437 mapping dbo.sfcg_wtb to ODSUSER.WTB [SQL error 437 (0x1b5)][IB
M][CLI Driver][DB2/LINUXX8664] SQL0437W  Performance of this complex query may be sub-optimal.  Reason code: "3".  SQLSTATE=01602

[IBM][CLI Driver][DB2/LINUXX8664] SQL0100W  No row was found for FETCH, UPDATE or DELETE; or the result of a query is an empty table
.  SQLSTATE=02000.

2011-05-24 12:58:01  WARNING OGG-01003  Repositioning to rba 1325 in seqno 0.

......

2011-05-24 12:58:01  ERROR   OGG-01296  Error mapping from dbo.sfcg_wtb to ODSUSER.WTB.


这个错误在db2信息中心里面能查到相应信息，根据实际情况可以判断出，UPDATE操作没有找到where条件的行。

当我们在复制进程的配置文件中定义了KEYCOLS参数后，就可以解决这个问题。