案例：DB2 三点 SQL 复制，APPLY 状态 -1

macrozeng

最近碰到一个三点  SQL 复制的问题，APPLY 状态为 -1  (The replication failed), 我用一个测试来还原真相，希望对大家有所帮助。
1.首先介绍一下环境
Suse Linux 下的 DB2 v9.1.0.6，db2inst1/2/3 代表三个不同的点
被复制表的结构
create table sr.s_tab(id integer not null PRIMARY KEY,content varchar(10) not null Unique )

2.错误发生以后检查各个点上的 apply 状态和 Apply Log

db2inst1@ibmswg01:~> db2 "select set_name, status, lastsuccess from asn.ibmsnap_subs_set with ur"

SET_NAME           STATUS LASTSUCCESS               
------------------ ------ --------------------------
PEER2TOPEER1           -1 2010-02-03-01.38.38.925787
PEER3TOPEER1            0 2010-02-03-01.44.40.263213

  2 record(s) selected.
  
db2inst2@ibmswg01:~> db2 "select set_name, status, lastsuccess from asn.ibmsnap_subs_set with ur"

SET_NAME           STATUS LASTSUCCESS               
------------------ ------ --------------------------
PEER1TOPEER2           -1 2010-02-03-01.38.41.502129
PEER3TOPEER2            0 2010-02-03-01.45.12.215878



db2inst3@ibmswg01:~> db2 "select set_name, status, lastsuccess from asn.ibmsnap_subs_set with ur"

SET_NAME           STATUS LASTSUCCESS               
------------------ ------ --------------------------
PEER1TOPEER3           -1 2010-02-03-01.38.45.122122
PEER2TOPEER3            0 2010-02-03-01.45.35.124049


Apply Log 如下所示
2010-02-03-01.38.51.244350 <CPDOUPD(CA/05)> ASN1001E  APPLY "SAMPLEAQ" : "WorkerThread".
The Apply program encountered an SQL error. The ERRCODE is "CA0105". The SQLSTATE is "23505".
The SQLCODE is "-803". The SQLERRM is "2??SR.S_TAB". The SQLERRP is "SQLDMISR". Te server name is "".
The table name is "S_TAB".


3. 查看 SR.S_TAB 表的数据
db2inst1@ibmswg01:~/repl_setup> db2 "select * from sr.s_tab"

ID          CONTENT   
----------- ----------
          1 a         
          3 c         
          2 b         
          4 ab        

  4 record(s) selected.
  

db2inst2@ibmswg01:~/repl_setup> db2 "select * from sr.s_tab"

ID          CONTENT   
----------- ----------
          2 b         
          1 a         
          3 c         
          5 ab        

  4 record(s) selected.
  
db2inst3@ibmswg01:~/repl_setup> db2 "select * from sr.s_tab"

ID          CONTENT   
----------- ----------
          1 a         
          3 c         
          2 b         
          5 ab        

  4 record(s) selected.


这个测试场景非常简单（真实环境复杂很多），大家大概也就能猜出问题所在，欢迎大家各抒己见，明天我再来说说解决办法吧

zhangzongjun

CD tables 不支持主键更新？

junli0310

SQL0803N  One or more values in the INSERT statement, UPDATE statement,
      or foreign key update caused by a DELETE statement are not valid
      because the primary key, unique constraint or unique index
      identified by "<index-id>" constrains table "<table-name>" from
      having duplicate values for the index key.

另外一点，你是更新了主键id的值吗？
如果要更改主键，你需要在capture端做一个设置，让capture把相应的update操作按照insert和delete来计入CD table。

junli0310

把你的具体操作过程列出来，只根据上面的信息没法准确定位错误！

huajieaixue

LZ的三点SQL REPLICATION 是PEER-TO-PEER的吗？
"create table sr.s_tab(id integer not null PRIMARY KEY,content varchar(10) not null Unique )"
存在PK ID的话,那就不能同时存在UNIQUE CONTENT。

我笨故我在

跟junli0310 说的一样.主键更新问题
经典错误,常见.不理解为什么DB2仍然保持这么容易出问题的默认设置,即使考虑性能也要在不出问题的前提下才行.
update  SCHEMA.IBMSNAP_REGISTER set CHG_UPD_TO_DEL_INS='Y' where CHG_UPD_TO_DEL_INS='N'
reinit / restart  Capture.

[ 本帖最后由 我笨故我在 于 2010-2-4 09:35 编辑 ]

macrozeng

呵呵，不是主键更新的问题，忘记交代一点了，真实环境中的主键自动增长的，而且是做了 offset 了的，就是说在 peer1 是 ID 是 start with 1 increase  by 3 上插入的主键只能是  1,4,7,11 。peer2 上是 2,5,8 。 Peer3 上是 3,6,9 ，而且对应用的要求是主键不能修改的，这是 P2P 复制的基本前提，否则早就乱了套

macrozeng

原帖由 junli0310 于 2010-2-4 00:00 发表
把你的具体操作过程列出来，只根据上面的信息没法准确定位错误！

呵呵，我做实验的时候的确还做了一步插入数据的工作，但是在生产环境中都是应用在插入，你作为 DBA ，根本就不知道他们在插入什么样的数据。只能根据你所看到的信息去分析

macrozeng

原帖由 huajieaixue 于 2010-2-4 08:35 发表
LZ的三点SQL REPLICATION 是PEER-TO-PEER的吗？
"create table sr.s_tab(id integer not null PRIMARY KEY,content varchar(10) not null Unique )"
存在PK ID的话,那就不能同时存在UNIQUE CONTENT。

为什么不能有？一个表里面一般都会有 PK 的，作为 DBA ，你没办法去要求业务不能有 UK 吧

junli0310

贴出TRC文件的内容