可更新订阅为什么有冲突?
可更新订阅中,当升级增加一个字段时,通常在发布服务器的发布数据库中增加,对表增加字段后,发布自动同步到订阅数据库中(复制架构更改=true)。但是,如果此时在订阅数据库进行DML操作,数据将不会同步到发布表中;这些差异数据在订阅表中如果一直未进行DML 操作,也就不会再次同步到发布中,存在差异。
复制配置环境:
可更新订阅事务复制
发布和订阅冲突都以订阅为准
使用排队更新
在订阅操作
冲突测试结果(以下为: 当数据存在不一致的情况下,对订阅再次操作会引起冲突,冲突策略会自动解决):
当发布数据不存在,订阅数据存在时,此时更新订阅数据:(排队更新冲突)
当发布和订阅主键相同,msrepl_tran_version不同时,此时更新订阅数据:(排队更新冲突)
以上两种情况结果:
在发布冲突,冲突表记录值都为最新值,订阅数据更新或插入到发布表中。
当发布数据不存在,订阅数据存在时,此时删除订阅数据:(排队更新冲突)
当发布和订阅主键相同,msrepl_tran_version不同时,此时删除订阅数据:(排队更新冲突)
以上两种情况结果:
删除操作同步到发布时冲突。
冲突入选方:
此行不再存在于“[dbo].[TestTab]”中。 [[dbo].[TestTab]].[qcfttabrowid] 中唯一 ID 的值是“8d335a44-36a0-432c-bba4-4979df3c804e”。
冲突落选方:
尝试删除此位置上的此数据时出现上述错误,原因可能是此删除操作违反了一个或多个约束。如果您忽略此冲突,则应通过其他方式加以解决。您可以记录此冲突的详细信息,然后将日志条目发送给系统管理员。
架构更如何防止冲突?
若要在支持更新订阅的发布中的表上进行架构更改,必须在发布服务器和订阅服务器中停止该表上的所有活动,还必须将挂起的数据更改传播到所有节点,然后才能进行架构更改。这可以确保未完成的事务不会与挂起的架构更改发生冲突。架构更改传播到所有节点后,可以在已发布的表上恢复活动。如何停止复制拓扑(复制 Transact-SQL
编程)
参考: 事务复制的可更新订阅