SQLServer 可更新订阅数据冲突的一个原因

原文:SQLServer 可更新订阅数据冲突的一个原因

可更新订阅为什么有冲突？

可更新订阅中，当升级增加一个字段时，通常在发布服务器的发布数据库中增加，对表增加字段后，发布自动同步到订阅数据库中（复制架构更改=true）。但是，如果此时在订阅数据库进行DML操作，数据将不会同步到发布表中；这些差异数据在订阅表中如果一直未进行DML 操作，也就不会再次同步到发布中，存在差异。

复制配置环境：

可更新订阅事务复制

发布和订阅冲突都以订阅为准

使用排队更新

在订阅操作

冲突测试结果（以下为： 当数据存在不一致的情况下，对订阅再次操作会引起冲突，冲突策略会自动解决）：

当发布数据不存在，订阅数据存在时，此时更新订阅数据：（排队更新冲突）

当发布和订阅主键相同，msrepl_tran_version不同时，此时更新订阅数据：（排队更新冲突）

以上两种情况结果：

在发布冲突，冲突表记录值都为最新值，订阅数据更新或插入到发布表中。

当发布数据不存在，订阅数据存在时，此时删除订阅数据：（排队更新冲突）

当发布和订阅主键相同，msrepl_tran_version不同时，此时删除订阅数据：（排队更新冲突）

以上两种情况结果：

删除操作同步到发布时冲突。

 

冲突入选方：

此行不再存在于“[dbo].[TestTab]”中。 [[dbo].[TestTab]].[qcfttabrowid] 中唯一 ID 的值是“8d335a44-36a0-432c-bba4-4979df3c804e”。

冲突落选方：

尝试删除此位置上的此数据时出现上述错误，原因可能是此删除操作违反了一个或多个约束。如果您忽略此冲突，则应通过其他方式加以解决。您可以记录此冲突的详细信息，然后将日志条目发送给系统管理员。

架构更如何防止冲突？

若要在支持更新订阅的发布中的表上进行架构更改，必须在发布服务器和订阅服务器中停止该表上的所有活动，还必须将挂起的数据更改传播到所有节点，然后才能进行架构更改。这可以确保未完成的事务不会与挂起的架构更改发生冲突。架构更改传播到所有节点后，可以在已发布的表上恢复活动。如何停止复制拓扑（复制 Transact-SQL
编程）

本人测试了一种解决方案：SQLServer 可更新订阅数据在线架构更改（增加字段）方案

参考: 事务复制的可更新订阅