更新时间：2022-10-28 13:03
合并复制通常也是从发布数据库对象和数据的报表快照开始。并用触发器跟踪在发布服务器和订阅服务器中所做的后续数据更改和架构修改。订阅服务器与发布服务器在连接到网络时进行同步，并交换自上次同步以来发布服务器和订阅服务器间发生变化的所有行。
复制的一种，允许站点对已复制数据进行匿名更改，并在晚些时候合并更改和根据需要解决冲突。
多个订阅服务器可能会在不同时间更新同一数据，并将这些更改传播到发布服务器和其他订阅服务器。
订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
每个订阅服务器都需要不同的数据分区。
可能会发生冲突。如果发生冲突，则需要具备检测和解决冲突的功能。
应用程序需要最终的数据更改结果，而不是访问中间数据状态。例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器中的行更改了五次，则该行在发布服务器中仅更改一次，并更改为第五个值以反映最终数据更改。
合并复制允许不同站点自主工作，然后在以后将更新合并成一个统一的结果。由于更新是在多个服务器中进行，因此，同一数据可能由发布服务器和多个订阅服务器进行了更新。于是，合并更新时就可能出现冲突。合并复制提供有数种处理冲突的方法
合并复制的执行需要快照代理和合并代理。其主要步骤是：
（1） 与快照复制、事务复制中快照代理的作用一样，合并复制的快照代理在开始复制之前也要完成二项任务；创建快照文件（同步集合）将存储在分发者的复制目录下；在出版数据库记录同步作业。合并代理将初始快照文件分发给订购者，从而完成订购初始化（出版数据库与订购数据库同步）。
（2） 当在某一节点（订购者）对出版物中表的某一行进行修改时，触发器会触发，并将该行的生成列generation column 设置为零。当合并代理执行时，它把所有生成列为零的合成一组或多组，凡是新的生成列值比原来的大，则用新值替换旧值。
（3） 在进行同步处理时，合并代理把所有生成列值为零的列（被修改的列）复制到所有其它订购者。
（4） 在目标数据库，从节点送来的数据与已存在数据进行合并，合并代理来进行冲突检测，如果未发生冲突则接收复制数据；如果发生冲突，合并代理根据缺省或所设定的冲突解决规则来解决冲突。
合并复制必须先初始化发布服务器和订阅服务器，然后才能在它们之间传递数据。 本主题提供有关初始化期间所进行的操作的信息。
下表列出了发布的初始化操作的详细信息，在您执行列出的每个存储过程时，或在完成新建发布向导后，都会发生这些初始化操作。 在为发布首次运行快照代理后，会发生进一步的初始化。
sp_replicationdboption
将发布数据库标记为要进行复制。 除非删除复制，否则不能删除该数据库。
将系统表添加到发布数据库中（除非该数据库中已存在合并发布）。 有关系统表的完整列表，请参阅本主题中的“在发布数据库和订阅数据库中创建的系统表”部分。
sp_addmergepublication
将发布项添加到系统表中。
sp_addpublication_snapshot
将快照代理作业添加到 SQL Server 代理系统中。 作业名称的格式为 <发布服务器>-<发布数据库>-<发布>-<整数>。
sp_addmergearticle
将复制的每个对象标记为要进行复制。 除非从所有发布中删除对象的相应项目，否则不能删除对象。
将代表每个项目的条目添加到系统表中。
发布数据库的其余初始化操作在为发布首次运行快照代理时执行（以后运行快照代理时，不会重新初始化发布数据库）。 如果使用新建发布向导，默认情况下会在完成向导后创建初始快照。 如果使用存储过程，则必须运行代理作业或直接运行代理。 有关运行代理的详细信息，请参阅如何启动和停止复制代理 (SQL Server Management Studio)和复制代理可执行文件概念。
为发布首次运行快照代理：
在每个已发布的表中添加一个名为 rowguid的列，除非表中已有一个数据类型为 uniqueidentifier 并具有 ROWGUIDCOL 属性集的列（这种情况下将使用此列）。 rowguid列用于唯一标识每个已发布表中的每一行。 如果从发布中删除表，将删除 rowguid列；如果将现有列用于跟踪，则不删除该列。
在发布数据库中为每个已发布的表创建下列对象（所有对象都在 dbo架构中创建）：
将插入、更新和删除触发器添加到已发布的表中，以跟踪更改。 触发器的命名格式为 MSmerge_ins_
创建存储过程以处理已发布表的插入、更新和删除操作，并执行与复制相关的其他一些操作。
创建视图以管理插入、更新、删除和筛选操作。
创建冲突表以存储冲突信息。 冲突表与已发布表的架构相匹配： 为每个已发布的表编写脚本，然后用脚本在发布数据库中创建冲突表。 冲突表的命名格式为 dbo.MSmerge_conflict_<发布>_<项目>。
每次运行快照代理时，都会为发布数据库中的每个项目创建下列类型的文件（带有相应的文件扩展名）：
架构 (.sch)
约束和索引 (.dri)
触发器 (.trg)
系统表数据 (.sys)
冲突表 (.cft)
数据 (.bcp) -- 不会为使用参数化筛选器的发布创建。
如果发布不使用任何参数化筛选器，快照会将已发布表的数据包含在一组 .bcp 文件中。 如果发布使用参数化筛选器（对于合并发布通常如此），初始快照将不包含任何数据。 将使用订阅服务器分区的快照提供数据，这将在“初始化订阅”部分进行讨论。
每个订阅都在订阅的合并代理运行并将初始快照复制到订阅数据库时进行初始化。 除了已复制对象的架构和数据之外，快照还包含发布数据库中存在的系统表、视图、触发器和存储过程（还会将一个或两个额外的系统表复制到订阅数据库中）。 有关系统表的完整列表，请参阅本主题中的“在发布数据库和订阅数据库中创建的系统表”部分。 如果重新初始化订阅，将覆盖所有已复制对象和复制系统对象。
如果发布数据库中的任何表都未使用参数化筛选器，则向每个订阅服务器上复制相同的发布快照。 如果使用了一个或多个参数化筛选器，则每个订阅的初始化方式将由下列逻辑决定：
如果在命令行中为合并代理提供了快照位置：
则从此位置应用快照。
否则，如果快照是预生成的：
则从发布数据库中的 MSmerge_dynamic_snapshots检索快照的位置，并从该位置应用快照。
否则，如果发布允许订阅服务器初始化快照：
如果已经为具有同一分区的其他订阅服务器生成了快照，则将该快照应用于订阅服务器。
否则，将生成快照并将其应用于订阅服务器。
否则，将对发布中的表使用 SELECT 语句初始化订阅服务器。 此方法要比使用订阅服务器分区的快照慢得多。
如果快照传输在任一点中断，它将自动恢复并且不再重新发送已经全部传输的任何文件。 对于每个发布项目，快照代理的传递单位是bcp 文件，因此已部分传递的文件必须全部重新传递。 不过，恢复快照可以大幅度减少传输的数据量，即便在连接不可靠的情况下也可以确保及时进行快照传递。 有关创建快照的详细信息，请参阅带有参数化筛选器的合并发布的快照。