1.问题描述

1.目标端复制进程abend

在正常启动目标端复制进程后，对源端表TBCS.T_OM_ORDER进行一次insert与update操作，发现目标端复制进程出现abend状态，并且无法重新启动目标端复制进程。

2.源端表结构与复制进程配置存在差异

  通过查看源端与目标端表结构发现，源端表TBCS.T_OM_ORDER存在两个唯一索引，而目标端表OGG_TD_CH_OM_ORDER_201210没有任何索引，并且在复制进程的配置文件Map选项中keycols配置为keycols（ORDER_ID,INSTANCE_ID）。

2.问题分析

1.分析目标端复制进程abend

通过第三方数据同步工具完成数据初始化后，在对源端表进行insert/update操作后，目标端复制进程出现abend状态，并无法重新重启，查看目标端ggserr.log:

目标端对应replicat进程report（rep19,rpt）如下：

根据以上的report可以看出，在rep1进程在完成插入一条数据后，发生了abend这条插入的数据确实在目标表的行数上得以验证，即源端完成insert后，目标端的表中确实多了一条数据。通过这个report可以发现，update操作未生效。

经过一段时间的尝试，当时并未解决这个问题，考虑到停机的时间窗口，跟客户商量后，决定进行回退操作。

  2.源端表结构与复制进程配置存在差异

查看源端TBCS.T_OM_ORDER唯一索引，如下

查看目标端OGG..TD_CH_OM_ORDER_201210索引情况，如下

通过查看源端与目标端表结构发现，源端表TBCS.T_OM_ORDER上存在两个唯一索引，而目标端表OGG.TD_CH_OM_ORDER_201210没有任何索引。另外，在复制进程的配置文件Map参数选择中，keycols的值被定义为（ORDER_ID,INSTANCE_ID），由于在目标端表OGG..TD_CH_OM_ORDER_201210该两个字段不是索引列，并且在复制进程配置文件中同时配置了两个unique index，初步判断是由于这个原因一起Mapping error.

3.解决方案

针对第二部分的问题并结合现场环境，做如下建议：

1.协调现场工程师跟进SR(3-6372456501).

2.由于源端表结构与目标端表 OGG.TD_CH_OM_ORDER_201210添加与源端表相同的约束条件，即为目标端创建对应的索引，同事修改keycols配置（配置过程中使用一个，或者同时使用两个唯一索引进行测试），对表TBCS.T_OM_ORDER以及OGG..TD_CH_OM_ORDER_201210进行重新模拟mapping测试并确认。

3.为了保证下一次生产环境下的实施能够成功，建议重新搭建与此次���产环境实施一致的测试环境，重新进行测试。

这个归入数据库版块，可能更合适点