我有一个源和目标都是IBM DB2 iSeries的表。复制方式为镜像。在镜像前刷新后，出现消息Table <lib>/<table> should already have been refreshed. Transformation Server will terminate.，并且表的状态保持为refresh。同一订阅中的其他表正常运行。下面是详细的日志:
- 表lib/Table，成员表将刷新为订阅。
- Tablelib/Table， memberTablerefresh tosubscription已完成200000行发送。
- Tablelib/TablememberTable无法刷新。
- Tablelib/Table应该已经刷新了。转换服务器将终止。
目标
- lib/table， member *ONLY.
- 从表lib/table. 的成员*FIRST中删除了220310行。
- 表lib/table刷新完成，member *ONLY。收到200000行，成功应用199500行，失败500行。
有人对这种情况有什么看法吗?
CDC iSeries将尝试获得一个非常短的排他锁(允许读)，以确保在刷新开始时没有涉及表的未提交提交周期。如果它不能获得锁，那么它跳过刷新，移动到下一个表，发布您报告的消息。因此，您需要在表上的活动较低(或没有活动)时运行该表的刷新。如果源应用程序在提交控制下更新表，则需要此锁来确保一致性，否则日志scraper将忽略属于在刷新本身开始之前开始的提交周期的任何事务。如果源应用程序根本没有使用提交控制，并且iSeries是唯一的源，那么您可以让目标程序忽略提交控制。然后源将知道不要尝试锁。要关闭基于java的目标的提交控制，请添加目标系统参数mirror_commit_on_transaction_boundary并将其设置为false，如果目标是iSeries，请将目标提交控制参数更改为*NONE。如果您在目标上进行此更改，请确保根本没有使用提交控制，否则如果在表刷新的同时回滚更改，可能会出现一些麻烦的同步问题
查看作业日志可以更清楚地了解导致此行为的原因，因为这种情况可能有多种原因。可以尝试的一件事是，在管理控制台中选择映射表
- 停表
- 将其标记为刷新并开始订阅它将刷新表并进入"Active"状态。