合并复制的发布与订阅

发布网友发布时间：2022-04-13 13:20

共2个回答

懂视网时间：2022-04-13 17:41

在事务复制的过程中，有时候会由于各种各样的原因导致发布服务器和订阅服务器的数据不一致，造成这种情况往往是由于以下几种原因之一：上面三种情况是最常见的导致发布端和订阅端数据不一致的原因，其中第三种原因往往出现的最多，在这种情况下，通常来说，

在事务复制的过程中，有时候会由于各种各样的原因导致发布服务器和订阅服务器的数据不一致，造成这种情况往往是由于以下几种原因之一：

上面三种情况是最常见的导致发布端和订阅端数据不一致的原因，其中第三种原因往往出现的最多，在这种情况下，通常来说，可以通过重新初始化订阅来解决该问题，但对于比较大的订阅来说，或者发布和订阅之间相隔太远而造成网络宽带的问题，则重新初始化订阅就不是那么吸引人的提案了。因此通过数据对比分析工具来比对有差异的数据，，并仅仅更新那些和源不同步的数据则是更好的选择。

这类工具包括类似Redgate和xSql的数据对比工具，也可以使用Visual Studio自带的数据对比工具进行，下面我通过一个简单的Demo来展示如何解决该类问题。

DEMO

目前我已经建立好一个发布服务器和订阅服务器，发布服务器CAREYSON-SQL发布了示例数据库AdventureWorks的SalesOrderDetail整张表，订阅服务器sqlazursql2012订阅了该表，如图1所示。

图1.基本的复制信息

此时，我在订阅服务器人为的删除数据，造成发布服务器和订阅服务器的数据不一致，如图2所示。

图2.在订阅端手动删除数据，造成不一致

我们再来服务端验证订阅，如图3所示。

图3.验证订阅

在复制监视器中，可以看到，在订阅服务器删除的一条数据导致了验证订阅出现不同步的提示，如图4所示。

图4.订阅已经不再同步

为了修正该问题，我们可以通过Visual Studio的数据库项目来建立数据对比分析任务来找到缺失的数据，从而根据发布端更新订阅端，如图5所示。

图5.找出被删除的数据

然后我们点击"更新目标"，则被删除的数据会由发布端同步到订阅端。如图6所示。

图6.目标数据库已经更新

我们再次进行验证订阅，显示已经通过订阅，如图7所示。

图7.更新订阅端后，订阅通过验证

热心网友时间：2022-04-13 14:49

合并复制必须先初始化发布服务器和订阅服务器，然后才能在它们之间传递数据。本主题提供有关初始化期间所进行的操作的信息。下表列出了发布的初始化操作的详细信息，在您执行列出的每个存储过程时，或在完成新建发布向导后，都会发生这些初始化操作。在为发布首次运行快照代理后，会发生进一步的初始化。
sp_replicationdboption
将发布数据库标记为要进行复制。除非删除复制，否则不能删除该数据库。
将系统表添加到发布数据库中（除非该数据库中已存在合并发布）。有关系统表的完整列表，请参阅本主题中的“在发布数据库和订阅数据库中创建的系统表”部分。
sp_addmergepublication
将发布项添加到系统表中。
sp_addpublication_snapshot
将快照代理作业添加到 SQL Server 代理系统中。作业名称的格式为 <发布服务器>-<发布数据库>-<发布>-<整数>。
sp_addmergearticle
将复制的每个对象标记为要进行复制。除非从所有发布中删除对象的相应项目，否则不能删除对象。
将代表每个项目的条目添加到系统表中。
发布数据库的其余初始化操作在为发布首次运行快照代理时执行（以后运行快照代理时，不会重新初始化发布数据库）。如果使用新建发布向导，默认情况下会在完成向导后创建初始快照。如果使用存储过程，则必须运行代理作业或直接运行代理。有关运行代理的详细信息，请参阅如何启动和停止复制代理 (SQL Server Management Studio)和复制代理可执行文件概念。
为发布首次运行快照代理：
在每个已发布的表中添加一个名为 rowguid的列，除非表中已有一个数据类型为 uniqueidentifier 并具有 ROWGUIDCOL 属性集的列（这种情况下将使用此列）。 rowguid列用于唯一标识每个已发布表中的每一行。如果从发布中删除表，将删除 rowguid列；如果将现有列用于跟踪，则不删除该列。
在发布数据库中为每个已发布的表创建下列对象（所有对象都在 dbo架构中创建）：
将插入、更新和删除触发器添加到已发布的表中，以跟踪更改。触发器的命名格式为 MSmerge_ins_<GUID>、MSmerge_upd_<GUID>和 MSmerge_del_<GUID>。 GUID 值从系统表 sysmergearticles中项目的项派生而来。
创建存储过程以处理已发布表的插入、更新和删除操作，并执行与复制相关的其他一些操作。
创建视图以管理插入、更新、删除和筛选操作。
创建冲突表以存储冲突信息。冲突表与已发布表的架构相匹配：为每个已发布的表编写脚本，然后用脚本在发布数据库中创建冲突表。冲突表的命名格式为 dbo.MSmerge_conflict_<发布>_<项目>。
每次运行快照代理时，都会为发布数据库中的每个项目创建下列类型的文件（带有相应的文件扩展名）：
架构 (.sch)
约束和索引 (.dri)
触发器 (.trg)
系统表数据 (.sys)
冲突表 (.cft)
数据 (.bcp) -- 不会为使用参数化筛选器的发布创建。
如果发布不使用任何参数化筛选器，快照会将已发布表的数据包含在一组 .bcp 文件中。如果发布使用参数化筛选器（对于合并发布通常如此），初始快照将不包含任何数据。将使用订阅服务器分区的快照提供数据，这将在“初始化订阅”部分进行讨论。每个订阅都在订阅的合并代理运行并将初始快照复制到订阅数据库时进行初始化。除了已复制对象的架构和数据之外，快照还包含发布数据库中存在的系统表、视图、触发器和存储过程（还会将一个或两个额外的系统表复制到订阅数据库中）。有关系统表的完整列表，请参阅本主题中的“在发布数据库和订阅数据库中创建的系统表”部分。如果重新初始化订阅，将覆盖所有已复制对象和复制系统对象。
如果发布数据库中的任何表都未使用参数化筛选器，则向每个订阅服务器上复制相同的发布快照。如果使用了一个或多个参数化筛选器，则每个订阅的初始化方式将由下列逻辑决定：
如果在命令行中为合并代理提供了快照位置：
则从此位置应用快照。
否则，如果快照是预生成的：
则从发布数据库中的 MSmerge_dynamic_snapshots检索快照的位置，并从该位置应用快照。
否则，如果发布允许订阅服务器初始化快照：
如果已经为具有同一分区的其他订阅服务器生成了快照，则将该快照应用于订阅服务器。
否则，将生成快照并将其应用于订阅服务器。
否则，将对发布中的表使用 SELECT 语句初始化订阅服务器。此方法要比使用订阅服务器分区的快照慢得多。
如果快照传输在任一点中断，它将自动恢复并且不再重新发送已经全部传输的任何文件。对于每个发布项目，快照代理的传递单位是bcp 文件，因此已部分传递的文件必须全部重新传递。不过，恢复快照可以大幅度减少传输的数据量，即便在连接不可靠的情况下也可以确保及时进行快照传递。有关创建快照的详细信息，请参阅带有参数化筛选器的合并发布的快照。