SQL Server 2000 发布与订阅 .
SQL Server 2000 发布与订阅
为快照复制制定计划
快照复制需要在以下方面制定计划：
传输和存储快照文件。
调度快照。
传输和存储快照文件
可以选择在一个默认位置或非默认位置存储快照文件，默认位置一般位于分发服务器上。备用位置可以在另一台服务器、一个网络驱动器或可移动媒体（如光盘或可移动磁盘）上。也可以将快照文件保存到文件传输协议 (FTP) 站点以供订户以后检索。
此外，可以通过将数据写为 Microsoft CAB 文件格式来压缩快照文件，以改善网络性能。
当制定传输与存储快照文件计划时，估计在快照文件位置和接收快照文件的订阅服务器需要的磁盘空间。
一个快照需要的空间大小受几个因素影响，其中包括已发布项目的大小及数目。快照文件可以在分发服务器上的默认快照文件夹或可选位置中创建。压缩可选位置中的快照文件可以减少所需的总空间。
当在同一个驱动器的默认文件夹和备用位置创建快照文件时，快照文件首先在默认文件夹中创建，然后被复制到备用位置。如果使用压缩快照文件，则在将这些文件放入可选快照位置之前已经进行复制和压缩。在这种情况下，所有快照文件需要的总空间是默认位置中原始快照文件的大小与可选位置中压缩快照文件的大小之和。
如果备用存储位置与默认位置不在同一驱动器上，那么默认位置需要的空间就是快照文件的大小。可选位置需要的空间是压缩快照文件的总大小。
调度快照
并发快照处理是为事务复制提供的，而优化的合并快照生成是为合并复制提供的。从概念上讲，并发快照处理类似于数据库上的更新继续的同时执行数据库备份的方式。
使用并发快照处理和事务复制，在快照代理程序运行时，它将临时共享锁放置在发布表上，将该表快速发布以便数据库中的数据修改能够继续执行。此时所做的数据修改成为初始快照的一部分。快照应用于订阅服务器，且分发代理程序协调每个被捕获的事务以查看它是否已被传送到订阅服务器。在此调节过程中，订阅服务器上的表也临时锁定。
若要使用户不能临时添加或更新表的可能性最小化：
可能的情况下，选择带有事务复制的并发快照处理。发布服务器上的共享锁只能控制几秒钟。
识别所需要的数据更新量最小的时机，并相应调度代理程序。与备份一样，生成快照可能会消耗大量资源，在生成期间该开销会降低其余系统性能。
若要为运行快照代理程序制定最佳的调度计划，请计算快照代理程序完成快照所需的时间。因为快照是用 bcp 创建的，所以请对数据集执行大容量复制测试并测定其完成时间。如果数据集很大，请对数据集的某个示例执行大容量复制，并推断整个数据集的花费时间。
如果关心数据库内的中断活动，那么另一个选择便是不应用快照。可以手工设置订阅服务器，例如从数据库转储。这称为手工应用初始快照。
为事务复制制定计划
事务复制需要在以下方面制定计划：
事务日志空间。
分发数据库的磁盘空间。
要发布的各个表的主键。
即时更新和排队更新。
转换复制的数据。
事务复制中的 text 和 image 数据类型。
标识范围。
约束和 NOT FOR REPLICATION。
事务日志空间
对于将要在事务复制中发布的各个数据库，确保分配给事务日志足够的空间。已发布数据库的事务日志可能需要比同样的、未发布数据库的日志更多的空间。这是因为日志记录在移动到分发数据库之后才会被清除。
如果分发数据库不可用，或者日志读取器代理未在运行，那么发布数据库的事务日志将继续增长。除非完全关闭数据库的复制，否则晚于最先发布但尚未传入分发数据库的事务日志无法被截断。建议将事务日志文件设置为自动增长，以便日志可以适应这些环境。
分发数据库的磁盘空间
如果计划创建事务发布，并使快照文件可立即为订阅服务器所用，请为分发数据库分配足够的磁盘空间，以便存储最后一次快照之后的所有事务。使快照文件可立即为订阅服务器所用，尽管这样可提高新的订阅服务器访问发布的速度，但是该选项要求分发数据库拥有更大的磁盘空间。这还意味着每当快照代理程序运行时，将会生成一个新的快照。如果不使用该选项，并不允许匿名订阅，则只有存在新的订阅时才需要生成新的快照。
分发数据库立即开始收集事务，并继续保存它们，直到再次运行快照代理程序（无论以调度还是手工运行）。在下一次快照代理程序运行后，清除任务开始通过从第一个快照中删除行来清除和减小分发数据库的大小。因此，如果使用默认的调度，即每天运行一次快照代理程序，那么必须具有足够的磁盘空间以存储一天中发生的所有事务。
类似地，如果计划创建事务发布并允许对发布的匿名订阅，那么必须让分发数据库拥有足够的磁盘空间以存储自上次快照后的所有事务。允许匿名订阅还意味着每当运行快照代理程序时都会生成新的快照。
在以上两种情况下分配更多磁盘空间的另一个方法是：比每天运行一次（默认）更频繁地运行快照代理程序以使分发数据库中必须保留的命令较少。但是，生成快照非常消耗资源，会暂时影响性能。缩短分发保持期（在发布服务器和分发服务器属性对话框中）也有助于保留较少的命令，因为分发清理代理程序由分发保持期控制，并将已复制的事务从分发数据库删除。
主键
在事务复制中所有已发布的表都必须包含一个已声明的主键。通过用 Transact-SQL 语句 ALTER TABLE 为现有的表添加一个已声明的主键，可以使该表为发布做好准备。
事务复制中的 text 和 image 数据类型
在事务发布中复制 text 和 image 数据类型的过程受以下因素的影响：
支持在发布服务器上对 text 和 image 列使用 INSERT、UPDATE 和 DELETE 语句，而没有特殊考虑事项。但是，这些列不能由使用快照复制或事务复制和即时更新或排队更新订阅的订阅服务器更新。
在用于复制的已发布表上，可以使用带 WITH LOG 选项的 WRITETEXT 和 UPDATETEXT 来复制日志记录文本操作。不支持为复制而发布的 text 或 image 列，而该复制是使用带有 WITH NO_LOG 选项的 WRITETEXT 和 UPDATETEXT 操作的复制，这是因为复制读取事务日志。
仅当所有订户都运行 Microsoft SQL Server 6.0 版或更高版本订阅服务器时，才能执行 UPDATETEXT 操作。WRITETEXT 操作将被复制为 UPDATE 语句，从而使 WRITETEXT 不但实现到 SQL Server 的复制，而且实现到 ODBC 订阅服务器的复制。（UPDATETEXT 操作仅被复制为 UPDATETEXT。）
如果要修改多个 text 列，则不使用自定义过程，因为其它 text 列的值无日志记录。相反，将生成一个标准的 UPDATE 语句。
可配置参数 max text repl size 控制可被复制的 text 和 image 数据的最大字节数。这样可允许支持不能处理较大 text 和 image 值的 ODBC 驱动程序和 SQL Server 实例，以及具有系统资源（虚拟内存）限制的分发服务器。当发布 text 或 image 列，并且运行超过配置限制的 INSERT、UPDATE、WRITETEXT 或 UPDATETEXT 操作时，操作将失败。
使用 sp_configure 系统存储过程可设置 max text repl size 参数。
当发布 text 和 image 列时，文本指针应当在与 UPDATETEXT 或 WRITETEXT 操作（并可重复读取）相同的事务内检索。例如，不要在一个事务中检索文本指针，然后却在另一个事务中使用它。它可能已移动并失效。
另外，在获得文本指针后，不应在执行 UPDATETEXT 或 WRITETEXT 语句之前，执行任何可能改变文本指针所指向的文本位置的操作（例如更新主键）。
以下使用 UPDATETEXT 和 WRITETEXT 操作处理要复制数据的推荐方法：
1. 开始事务。
2. 获得带有可重复读取隔离的文本指针。
3. 在 UPDATETEXT 或 WRITETEXT 操作中使用文本指针。
4. 提交事务。
说明 如果未在同一事务中获得文本指针，则允许在发布服务器处进行修改，但更改不会发布到订阅服务器。
在评估订阅服务器数据库时，需要考虑的一个重要因素是：所复制的 text 和 image 列的文本指针将在订阅服务器表上被初始化，即使它们在发布服务器上未被初始化。因此，即使被分发任务添加到订阅服务器表中的各个 text 和 image 列中没有内容，它们也至少要占用 43 字节的数据库存储空间。
为合并复制制定计划
合并复制需要在以下方面制定计划：
timestamp 列。
标识范围。
数据完整性。
主键。
与可选同步伙伴同步。
行级跟踪和列级跟踪。
触发器和业务规则。
合并复制中的 text 和 image 数据类型。
冲突解决。
联机脱机应用程序的临时维护
timestamp 列
合并复制支持 timestamp 列。虽然复制 timestamp 列，但不复制 timestamp 的字面值。当在订阅服务器处应用初始快照行时，将重新生成 timestamp 值。这将允许订阅服务器处的客户端应用程序使用 timestamp 值以执行像乐观并发控制这样的功能。在那些情况下，用于执行乐观并发控制的 ODBC 驱动程序、OLE DB 提供程序、DB-Library 游标或服务器游标会对更新行的 timestamp 值与原始行的当前值进行进行比较。如果 timestamp 值不相同（表示某一行已经更改），那么应用程序能够执行适当的操作（例如回滚事务或重读数据）。因为 timestamp 值在订阅服务器重新生成，所以当执行项目验证时，将筛选出 timestamp 列。
数据完整性
因为合并复制可传播在订阅服务器处所做的更改，所以必须确保在各个订阅服务器处保留应用程序的完整性。所有用来验证发布服务器处数据更改的表应当也位于订阅服务器上。
提供选项以确保由合并代理程序用来连接发布服务器的登录也可用于控制以下情况：只有经过身份验证用户才能将在订阅服务器上所作的数据更改传播到发布服务器。
外键
当创建合并发布时，指定作为项目包含在此发布中的表。如果包含带有外键的表，那么所引用的表也应包含在发布中。如果试图向引用某个主键的项目中添加新行，而该主键位于缺少的表中，那么插入将失败，因为 SQL Server 2000 无法找到所需的主键。如果试图更新项目中现有行中的数据，那么更新将成功，因为 SQL Server 2000 不必添加新行和关键字。
在创建合并发布后，可对其进行修改以包含附加的项目。如果发现必须用额外的行来更新项目，而不仅仅靠对现有行的修改来更新，那么可向发布中添加任何缺少的引用表。请使用发布属性对话框添加缺少的表。
与可选同步伙伴保持同步
要合并发布的订阅服务器可与订阅起源所在的发布服务器以外的其它服务器保持同步。与可选同步伙伴的同步使得订阅服务器即使在主发布服务器不可用的情况下仍可同步数据，或由于物理位置可与另一同步伙伴连接（例如，正访问远程办公室且可以与那里的可选同步伙伴连接）的情况下，仍可使数据同步。
应该决定合并复制订阅服务器是否有必要拥有可选同步伙伴，并为同步准备这些备用服务器。
冲突检测和解决
在决定合并复制冲突的检测和解决方案时，可指定是在行级识别冲突，还是在列级识别冲突。
决定是使用行级跟踪还是列级跟踪，应根据是将行内的任何更改视为冲突（行级跟踪），还是允许不同的用户同时更新同一行而不是同步处理间的同一列（列级跟踪）。
选择使用行级还是列级跟踪应当基于应用程序，以及是要将对表中同一行的任何更改当作冲突，还是不同的用户可以同时更新同步处理间的同一行，而不是同一列。例如，在某些应用程序中，通过使用列跟踪来合并对不同列的更改视为是可接受的。这意味着如果发布服务器更改了列 1，订阅服务器更改了列 2，合并进程接受发布服务器对列 1 所做的更改以及订阅服务器对列 2 所做的更改。而有些应用程序可能要求对多个站点的相同行所做的更改（即使值位于不同列）应视为冲突，并在行级进行检测和解决。
触发器和业务规则
您应当清楚所复制表上的所有触发器和约束。在未制定计划的情况下，触发器和约束可与表一起复制，并可导致合并复制过程中反复出现冲突。
合并复制中的 text 和 image 数据类型
只有当 UPDATE 语句显式修改过 text、ntext 和 image 列时，合并复制才会支持对这些列的复制，因为这将导致触发器激发更新元数据以确保事务传播到其它订阅服务器。
只使用 WRITETEXT 和 UPDATETEXT 操作不会将更改传播至其它站点。如果应用程序使用 WRITETEXT 和 UPDATETEXT 更新 text 或 ntext 列，请在同一事务中，显式地将一个虚 UPDATE 语句添加到 WRITETEXT 或 UPDATETEXT 操作之后，以启动触发器，因而保证更改将传播到其它站点。
使用 Northwind 数据库并更新 Employees 表中的 Notes 列（数据类型为 ntext）：
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
BEGIN TRAN
DECLARE @mytextptr varbinary(16)
SELECT @mytextptr = textptr(Notes)
FROM Employees
WHERE EmployeeID = '7'
IF @mytextptr IS NOT NULL
BEGIN
UPDATETEXT Employees.Notes @mytextptr 0 NULL 'Terrific job this review period.'
-- Dummy update to fire trigger that will update meta data and ensure the update gets propagated to other Subscribers.
UPDATE Employees
-- Set value equal to itself.
SET Notes = Notes
WHERE EmployeeID = '7'
END
COMMIT TRAN
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
联机脱机应用程序的临时维护
在为使用复制的联机脱机应用程序制定计划时，要计划应用程序部署的临时维护以及把新数据集传输到脱接订阅服务器的方法。
尽管 SQL Server 2000 复制允许对临时连接或使用慢速链接的订阅服务器进行充分的数据访问，仍需为应用程序的临时维护制定计划，可能的话还需为在订阅服务器中重新应用快照制定计划。
为复制选项制定计划
在制定复制计划时需要额外考虑一些复制选项，其中包括即时更新、排队更新、将排队更新作为故障转移的即时更新和转换复制数据。如果用户不需要在订阅服务器更新数据，请考虑使用快照复制或不带即时更新或排队更新选项的事务复制，这样更易于配置和管理复制。
即时更新或排队更新订阅需要考虑的因素
计划即时更新或排队更新订阅需要考虑的因素有：
用于将数据行添加到表中的 INSERT 语句必须包含列的列表。
使用即时更新或排队更新选项的订户不能在订阅服务器上重新发布复制数据。
订户不能更新或插入 text 或 image 值。
在发布为即时更新订阅或排队更新订阅启用后，该选项无法为发布禁用（尽管订阅不需要使用它）；若要删除该选项，必须删除该发布并创建一个新发布。
快照复制不要求使用表中的主键。但是，自身事务复制或带有任何可更新订阅的快照复制不要求使用主键。
如果启用发布上的即时更新和或排队更新，也无法使用可转换订阅。如果已选择使用即时更新和或排队更新，创建发布向导中将不显示转换已发布的数据页。
即时更新订阅需要额外考虑的因素
即时更新允许快照复制和事务复制订户在订阅服务器上更新已复制数据，并将更改传播至发布服务器，然后传播到所有其它订阅服务器。
在计划使用带有即时更新的快照复制或事务复制时，请考虑以下因素：
使用 uniqueidentifier 列跟踪更新。uniqueidentifier 列将自动添加到发布中使用的任何表中。添加该列需要使用 INSERT 语句以获得列的列表。如果使用 Microsoft SQL Server 7.0 版中的即时更新，并正升级到 SQL Server 2000，将需要再次订阅发布。
使用此选项，在发布服务器和订阅服务器两处都使用两阶段提交协议 (2PC) 分发和执行更新：一相在订阅服务器本地，一相在发布服务器。这需要做更改的发布服务器和订阅服务器可用，且互相连接。
即时更新与发布服务器的订阅连接（由 sp_link_publication 控制）在创建登录映射时，对 SQL Server 身份验证可使用安全模式 0，对链接服务器定义可使用安全模式 2。发布访问列表 (PAL) 必须至少包括一个 SQL Server 身份验证帐户，除非用户使用安全模式 2 并配置了委托（通过配置委托可以设置 Windows 身份验证使用模式 2）。可以通过委托唤醒调用订阅服务器上的 INSERT、UPDATE 和 DELETE 触发器，以 Windows 用户帐户与发布服务器建立连接。若要设置委托，请参见
排队更新订阅需要额外考虑的因素
排队更新允许快照复制和事务复制订户修改已发布的数据，而不必一直连接在发布服务器上。
当创建发布时启用排队更新选项，一个启用了排队更新的订户对已发布数据执行了插入、更新或删除操作，所做的更改将存储在队列中。当网络连接恢复后，在发布服务器上经过排队的事务将进行异步应用。
当计划使用带有排队更新的快照复制或事务复制时，请考虑以下因素：
由于更新异步传播至发布服务器，所以发布服务器或另一台订阅服务器有可能更新同一数据，而在应用更新时会发生冲突。当创建发布时，需要选择适当的冲突解决策略。
对于快照复制，表应至少拥有一个唯一索引，且最好有一个主键。对于事务复制，表必须拥有一个主键。
如果订阅服务器数据库进行了水平分区，且在分区中有在订阅服务器上存在而在发布服务器上不存在的行，那么订阅服务器将无法更新这些预先存在的行。在试图更新这些行时返回错误。应当先将这些行从表中删除，然后再次添加。
用标识范围管理标识值以确保不同的订户具有不同的标识值。
转换已发布数据需要考虑的因素
借助于数据转换服务 (DTS) 的功能，可在复制过程中转换数据。创建自定义水平和垂直数据分区，创建诸如数据类型映射、列操作和字符串操作的数据转换，都是转换已发布数据的例子。
在制定转换复制数据计划时，请考虑以下因素：
可转换订阅的快照数据仅限于字符模式；无法对本机格式（通常应用速度更快）使用 DTS。
在为可转换订阅启用发布后，选项无法停用；必须删除现有的发布并创建一个新的发布，但是如果启用了选项，订阅无须使用它。
无法对可转换订阅使用即时更新或排队更新选项（转换映射为单方向，即从发布服务器到订阅服务器）。
尽管使用转换已发布数据向导会创建一个 DTS 包，但是这种类型的 DTS 包不能在复制外执行（从 DTS 设计器或命令提示符状态下）。但是，可以在允许转换已发布数据的事务发布和快照的复制过程中使用以 DTS 工具创建的包。
将 DTS 转换引入复制将增加开销并降低分发性能。数量取决于转换的复杂程度。但不影响日志读取器代理程序的性能。
合并复制或可更新订阅
当需要在订阅服务器上对复制数据进行更新时，可使用带可更新订阅选项的快照复制或事务复制，也可使用合并复制。选择的方式取决于复制拓扑和应用程序及其用户的需要。
在以下情况下使用合并复制。 在以下情况下使用快照复制或带有即时更新或排队更新的事务复制。
在订阅服务器上读取和更新已复制数据。
订阅服务器和发布服务器只偶尔连接。
处理和解决由对相同数据的多个更新引起的冲突。
需要逐行传播更新，并且在行级上对冲突进行评估和解决。
订阅服务器上的复制数据主要为只读。
订阅服务器、分发服务器和发布服务器在多数情况都是连接的，但是这对于排队更新订阅不是必要的。
很少发生由对相同数据的多个更新引起的冲突。
需要在事务的基础上传播更新，并且在事务的基础对冲突进行评估和解决（无论整个事务提交还是取消）。
设计复制拓扑
复制拓扑定义服务器和数据复本间的关系，以及用于决定复本间同步发生方式的逻辑。设计复制拓扑将有助于确定以下内容：更改从发布服务器到订阅服务器所需的时间，单个更新的失败是否阻止更新其它订阅服务器，以及更新信息到达订阅服务器的顺序（该顺序可影响分析和报表）。
确定复制拓扑：
选择物理复制模型（中央发布服务器、带有远程分发服务器的中央发布服务器、发布订阅服务器或中央订阅服务器）。
决定快照文件的位置及发布服务器和订阅服务器的初始同步方式。
决定分发服务器位于本地还是远程，并决定分发数据库是否共享。
决定多个发布服务器是共享一个分发服务器，而每个发布服务器使用其各自的分发数据库，还是共享一个分发数据库。
确定使用的复制类型和选项。
确定是在发布服务器上（使用强制订阅），还是在订阅服务器上（使用请求订阅）对复制进行初始化。
复制拓扑并不仅限于服务器间的物理连接，因为它还包含了数据复本间的数据路径。订阅服务器可从不同的发布服务器接收多个数据复本，而所有那些数据复本可在单个服务器上存在，从而组成复杂的拓扑。
物理复制模型
物理复制模型是一个映射表，用于确定如何在企业内分发数据及如何在复制执行过程中配置服务器。基于在分布式数据因素、评估复制环境和为各种类型的复制制定计划中列出的所有因素和注意事项，应当能够确定复制模型的最佳解决方案。
以下是复制模型的例子：
中央发布服务器。
带有远程分发服务器的中央发布服务器。
再次发布者。
中央订阅服务器。
中央发布服务器
这种最简单的 Microsoft SQL Server 2000 复制拓扑模型将一个发布服务器和一个分发服务器置于同一服务器上，而将一个订阅服务器置于单独的服务器上。
当将若干订阅服务器添加至发布服务器和分发服务器中时，该方案则变得稍微有些复杂。发布服务器拥有正在发布的数据，并成为所有订阅服务器的中央发布服务器。例如，该方案可能用于将主数据、列表或报表从中央发布服务器分发至任意数目的订阅服务器。
发布服务器和订阅服务器的角色不是互斥的；服务器可以同时担任二者。例如，假定服务器 A 发布发布 1，并且服务器 B 发布发布 2。在此情况下，服务器 A 既可作为发布 1 的发布服务器，也可作为发布 2 的订阅服务器。这是一个筛选数据和发布分区的示例。
带有远程分发服务器的中央发布服务器
随着复制活动等级的增加，或者随着服务器或网络资源变得受到限制，可能出于性能原因将发布服务器和分发服务器置于不同的服务器上。当将一个繁忙的联机事务处理 (OLTP) 服务器配置为发布服务器时，这样做可能比较适当。尽管使用单独的分发服务器会增加网络总流量，但是该方案将减少发布服务器上的本地处理工作和磁盘使用量。
这种方案类似于中央发布服务器方案，不同之处在于由单独的计算机执行发布和分发任务。当出于性能和存储空间方面的考虑，需要使发布服务器（例如，一台使用频繁的 OLTP 服务器）从分发任务中解脱出来时，此方案十分有用。发布服务器必须通过可靠、高速的通讯链接连接到分发服务器。
再次发布者
再次发布者模型使用两台服务器发布相同的数据。发布服务器将数据发送至订阅服务器，然后后者将数据重新发布至任意数目的订阅服务器。当发布服务器必须通过低速或昂贵的通讯链接向订阅服务器发送数据时，此方案十分有用。如果在链接的远端有许多订阅服务器，那么使用再次发布者会将大容量的分发负担转移到链接的远端。
在此图中，发布服务器和再次发布者（发布订阅服务器）都作为其自身的本地分发服务器。如果将其各自设置为使用远程分发服务器，则各分发服务器需要与其发布服务器位于低速或昂贵的通讯链接的同一端。发布服务器必须通过可靠、高速的通讯链接连接到远程分发服务器。
任何服务器既可作为发布服务器，又可作为订阅服务器。例如，设想发布一份位于纽约的表，它需要分发至欧洲四个不同城市：伦敦、奥斯陆、巴黎和里斯本。之所以选择位于伦敦的服务器来订阅源于纽约的发布表，是因为伦敦的站点满足下列条件：
返回纽约的网络链接相当可靠。
纽约到伦敦的通讯成本不太高。
从伦敦到其它欧洲订阅服务器站点有良好的网络通讯线路。
中央订阅服务器
在中央订阅服务器模型中，很多发布服务器将信息复制到订阅服务器上的公用目的表中。目的表进行了水平分区，且包含作为主键一部分的位置特有的列。各发布服务器复制包含位置特有的数据的行。
该复制配置对某些情况可能有用，例如，将来自本地仓库上许多服务器的清单数据汇总到公司总部的中央订阅服务器。该配置还可用于汇总来自公司内各自治商业部门的信息，或合并来自分散位置的订单处理。
快照复制的工作机制
快照复制是通过快照代理程序和分发代理程序实现的。快照代理程序准备快照文件，其中包含了已发布表和数据库对象的架构和数据，然后将这些文件存储在快照文件夹中，并在分发服务器上的分发数据库中记录同步作业。快照文件夹默认位于分发服务器上，但可以指定一个备用位置取代默认位置或者与之并存。
分发代理程序将保存在分发数据库表中的快照移动到订阅服务器上的目的表中。分发数据库仅用于复制，不包含任何用户表。
快照代理程序
快照代理程序每次运行时，都会检查是否新增了任何新订阅。如果没有新订阅，则不创建任何新的脚本或数据文件。如果创建发布时启用了立即创建第一个快照选项，则每次快照代理程序运行时都创建新的架构和数据文件。所有架构和数据文件都存储在快照文件夹中，然后由分发代理程序或合并代理程序将它们传送到订阅服务器，也可以手工传送。快照代理程序执行以下步骤：
1. 建立从分发服务器到发布服务器的连接，并在发布所包含的所有表上设置共享锁。共享锁保证了数据快照的一致性。由于这些共享锁阻止所有其他用户更新这些表，所以快照代理程序必须安排在数据库活动的非峰值期间执行。
2. 建立从发布服务器到分发服务器的连接，并将每个项目的表架构复制到一个 .sch 文件。如果要求包含索引和描述性引用完整性，则代理程序将选中索引写入一个 .idx 文件。其它数据库对象，如存储过程、视图、用户定义函数等，也可以作为复制的一部分进行发布。
3. 在发布服务器上复制已发布表中的数据，并将这些数据写入快照文件夹。如果所有订阅服务器都是 Microsoft SQL Server 2000 实例，则将快照存储为本机大容量复制程序文件。如果一个或多个订阅服务器为异类数据源，则快照将按字符模式文件存储。这些文件是代表一个时点的表的同步集合。一次发布内的每一个项目都有一个同步集。
4. 向分发数据库的 MSrepl_commands 表和 MSrepl_transactions 表追加行。MSrepl_commands 表中的表项是表明同步集（.sch 文件和 .bcp 文件）位置的命令，以及对所有指定的预创建脚本的引用。MSrepl_transactions 表中的表项是引用订阅服务器同步任务的命令。
5. 释放所有已发布表的共享锁，完成日志历史表的写入。
生成快照文件后，可以使用快照探索器在快照文件夹中查看这些快照文件。在 SQL Server 企业管理器中，展开复制及发布文件夹，右击一项发布，然后单击浏览最新快照文件夹菜单选项。
分发代理程序
每次分发代理程序运行快照发布时，都会将架构和数据移动到订阅服务器上。分发代理程序执行以下步骤：
1. 建立从代理程序所在服务器到分发服务器的连接。如果是强制订阅，分发代理程序通常在分发服务器上运行，如果是请求订阅，分发代理程序通常在订阅服务器上运行。
2. 检查分发服务器上的分发数据库中的 MSrepl_commands 表和 MSrepl_transactions 表。代理程序从第一个表中读取同步集的位置，并从这两个表中读取订阅服务器同步命令。
3. 将架构和命令应用到订阅数据库。如果订阅服务器不是 Microsoft SQL Server 2000 实例，则代理程序将在必要时转换数据类型。所有发布项目均将同步，同步时保持基础表间的事务和引用完整性（假定订阅数据库如果不是 SQL Server，具有完成该任务的事务功能）。
当处理大量的订阅服务器时，在订阅服务器上运行分发代理程序（不论通过使用请求订阅，还是通过使用远程代理程序激活），可以节省分发服务器的处理资源。如果使用远程代理程序激活，可以选择在订阅服务器上运行分发代理程序进行强制订阅，或者在分发服务器上运行分发代理程序进行请求订阅。
可以在创建订阅时应用快照，也可以按照创建发布时设置的调度应用快照。
说明 如果代理程序在分发服务器上运行，调度的同步是根据分发服务器上的日期和时间执行的，而不是根据订阅服务器上的日期和时间。否则，调度就根据订阅服务器上的日期和时间进行。
因为数据库或个别的表的自动同步增加了系统开销，所以加大自动同步的间隔时间的优点之一，是可以将初始快照安排在发布服务器较空闲的时候进行处理。
快照代理程序通常由 SQL Server 代理程序运行，可以直接用 SQL Server 企业管理器进行管理。快照代理程序与分发代理程序也可以通过使用 Microsoft ActiveX 控件嵌入到应用程序中。快照代理程序在分发服务器中运行。对于强制订阅，分发代理程序通常在分发服务器上运行，而对请求订阅，则通常在订阅服务器上运行。但是，可以使用远程代理程序激活将分发代理程序处理卸载到另一个服务器上进行。
清除快照复制
创建分发数据库时，SQL Server 2000 在分发服务器上加入下列任务：
代理程序检查
事务清除
历史记录清除
这些任务有助于在一个长期运行的环境中有效地进行复制。当快照在所有订阅服务器上应用后，复制清除程序自动为初始快照删除其关联的 .bcp 文件。
如果为匿名订阅启用了发布，或用立即创建第一个快照选项启用了发布，则在快照位置将至少保留快照文件的一个副本。如果具有快照发布匿名订阅的订阅服务器与发布服务器同步，这将确保最新的快照是可用的。
事务复制工作机制
事务复制是由快照代理程序、日志读取器代理程序和分发代理程序实现的。快照代理程序准备快照文件，其中包含了已发布表和数据库对象的架构和数据，然后将这些文件存储在快照文件夹中，并在分发服务器上的分发数据库中记录同步作业。
日志读取器代理程序监视已为事务复制配置的每个数据库的事务日志，并将已设复制标记的事务从事务日志复制到分发数据库中。分发代理程序将保存在分发数据库表中的事务和初始快照作业移动到订阅服务器上。
初始快照
新的事务复制订阅服务器上必须包含一些表，这些表与发布服务器上的表具有相同的架构和数据，然后才能从发布服务器上接收增量更改。将完整的当前发布从发布服务器复制到订阅服务器称为应用初始快照。Microsoft SQL Server 2000 将为您创建并应用快照，您也可以选择手工应用快照。
在向订阅服务器分发并应用快照时，实际上只有那些正在等待初始快照的订阅服务器受到影响。而该发布的其它订阅服务器（即那些已经收到对已发布数据所进行的插入、更新、删除或其它修改内容的订阅服务器）不受任何影响。
并发快照处理
一般来讲，随着快照的生成，SQL Server 在快照生成期间，将在所有作为复制一部分进行发布的表上放置共享锁。这可以防止在发布表上进行更新。只有使用事务复制才可用的并发快照处理，在整个快照生成过程中，将不包含共享锁，因而，在 SQL Server 2000 创建初始快照文件时，允许用户不间断地连续工作。
当使用事务复制新建发布并指出所有订阅服务器都是 SQL Server 7.0 或 SQL Server 2000 的实例时，可使用并发快照处理。
复制开始以后，快照代理程序将共享锁放在发布表中。直到在日志文件中输入了表明快照开始的记录后，锁才开始阻止更改。在接收到事务后，共享锁即被除去，从而可继续修改数据库中的数据。即使复制的数据量很大，包含锁的持续时间也是很短暂的（几秒钟）。
这时，快照代理程序开始生成快照文件。快照完成后，说明快照处理已结束的第二条记录被写入日志。在生成快照时影响表的任何事务都在开始和结束令牌之间捕获，并由日志读取器代理程序转发到分发数据库。
在订阅服务器上应用快照时，分发代理程序首先应用快照文件（架构文件和 .bcp 文件）。然后调节每个捕获事务，以查看该捕获是否已传送到订阅服务器。在协调过程中，订阅服务器上的表是锁定的。在创建快照时，从发布服务器上捕获的事务越多，在订阅服务器上应用此快照所需要的时间就越长。从概念上讲，这与重新启动 SQL Server 时的恢复进程相似。
在并发快照处理期间，当对标记用于复制的数据进行析取时，不能对它执行 UPDATETEXT 语句。如果启动 UPDATETEXT 语句，则会返回错误信息，指出由于正在进行并发快照处理而不允许此操作。快照完成之后，UPDATETEXT 语句可以再次执行。
前面已经提到，如果在某些系统中业务逻辑通过订阅数据库上的触发器或约束进行指示，则当并发快照处理发生在这些系统上时应注意。并发快照处理对表使用大容量插入，然后执行一系列特殊的 INSERT 和 DELETE 语句，使表处于一致的状态。这些操作作为一个事务执行，因此数据库用户看不见处于不一致状态的数据。但订阅服务器上的约束将在此事务内执行，而且可能评估不基于一致数据集的更改。若要避免这种情况，通常建议在订阅服务器数据库的所有约束和具有 IDENTITY 属性的列上指定 NOT FOR REPLICATION 选项。因为在订阅服务器表处于一致状态之前，不会在并发快照处理期间使用自定义存储过程，所以使用自定义存储过程不影响业务逻辑的执行。
订阅服务器上的外键约束、检查约束和触发器不需要 NOT FOR REPLICATION 选项，因为它们将在并发快照生成期间禁用并在快照生成后启用。
重要 日志读取器代理程序必须在用并发处理生成快照后运行。如果日志读取器代理程序不运行，分发代理程序将继续运行并返回错误，表明快照不可用，并且不将其应用到订阅服务器。在分发代理程序可以将快照应用到订阅服务器之前，日志读取器代理程序需要将快照生成期间发生的所有更改传播到分发数据库。日志读取器代理程序通常以连续模式运行，因此，它在生成快照后将很快自动运行，无须考虑此问题。如果选择不以连续模式运行日志读取器代理程序，则必须手工运行它。
尽管并发快照处理允许更新在发布表上继续，但由于快照本身的开销，性能将有所下降。只要可能，建议在最低常规活动期间生成快照（比如选择进行数据库备份的时段）。
重要 如果发布表含有不包含在聚集索引中的主键或唯一约束，且在并发快照处理过程中对聚集键上的数据进行修改，则复制会失败。建议仅当唯一和主键约束包含在聚集索引内或确保在生成快照时不修改聚集索引的列的数据时，才启用并发快照处理。
并发快照处理只适用于事务复制和在 Microsoft Windows 98、Microsoft Windows NT 4.0 和 Microsoft Windows 2000 操作系统上运行 SQL Server 7.0 或更高版本实例的订阅服务器。
如果要发布到运行 SQL Server 7.0 的订阅服务器，则分发服务器必须运行 SQL Server 2000 且必须使用强制订阅才能使用并发快照处理。分发代理程序在分发服务器上运行，并且能够执行并发快照处理。如果使用的是请求订阅，则分发代理程序将运行在 SQL Server 7.0 上的订阅服务器上，而在该服务器上并发快照处理不可用。
如果要发布到运行 SQL Server 7.0 的订阅服务器，则分发服务器必须运行 SQL Server 2000 且必须使用强制订阅才能使用并发快照处理。分发代理程序在分发服务器上运行，并且能够执行并发快照处理。如果使用的是请求订阅，则分发代理程序将运行在 SQL Server 7.0 上的订阅服务器上，而在该服务器上并发快照处理不可用。如果在运行 SQL Server 7.0 的订阅服务器上使用请求订阅，则必须禁用并发快照处理。
因为这些限制，所以当创建事务发布时创建发布向导不会默认进行并发快照处理；但是如果应用程序满足这些条件，则建议启用该选项。若要启用并发快照处理，请更改快照生成模式。打开发布属性，单击快照选项卡，然后选择在生成快照的过程中并发访问复选框。
快照代理程序
快照代理程序在事务复制过程中实现初始快照所执行的程序与快照复制中所用的程序相同（前面有关并发快照处理的概要除外）。生成快照文件后，可以使用快照探索器在快照文件夹中查看这些快照文件。在 SQL Server 企业管理器中，展开复制及发布文件夹，右击一项发布，然后单击浏览最新快照文件夹菜单选项。
数据修改及日志读取器代理程序
日志读取器代理程序可以连续运行，也可以按照创建发布时建立的调度运行。执行日志读取器代理程序时，该代理程序首先读取发布的事务日志（该日志与进行一般 SQL Server 操作期间为事务跟踪与恢复所用的数据库日志相同），并识别所有的 INSERT、UPDATE 以及 DELETE 语句，或者其它对已作复制标记的数据事务的修改。然后，该代理程序将这些事务批量复制到分发服务器上的分发数据库中。日志读取器代理程序使用内部存储过程 sp_replcmds 从日志中获得下一个已作复制标记的命令集。于是分发数据库成为将更改发送到订阅服务器所用的存储与转发队列。只有已提交的事务才能发送到分发数据库中。
发布服务器上的事务与分发数据库中的复制事务具有一一对应的关系。存储在表 MSrepl_transactions 中的一个事务可以包含许多命令，每个命令可以沿着表 MSrepl_commands 中的 500 Unicode 字符边界拆分。当整批事务都成功写入分发数据库之后，这一批事务便被提交。在每一批命令都提交到分发服务器后，日志读取器代理程序调用 sp_repldone 过程标记复制最终完成的位置。最后，代理程序标记事务日志中准备好截断的行。仍在等待复制的行不会被截断。发布服务器上的事务日志可以被转储而不会影响复制，因为只清除未作复制标记的事务。
只要不修改唯一约束的列，订阅服务器上所做的数据修改将始终作为一系列单行语句传播。如果 UPDATE 确实修改了唯一约束的列，则 UPDATE 将作为一系列后跟一系列 INSERT 语句的 DELETE 语句传播。唯一约束的列是任何参与唯一索引或聚集索引的列，即使没有将聚集索引声明为唯一索引。对索引视图或索引视图所基于的基表所执行的 UPDATES 将作为 DELETEINSERT 对传播。
日志读取器代理程序在分发服务器上的 SQL Server 代理程序中运行，并可通过在企业管理器中的复制监视器和代理文件夹中对其访问，进行直接管理。
分发代理程序
事务命令存储在分发数据库中，直到分发代理程序将其传播到所有订阅服务器中，或者订阅服务器上的分发代理请求订阅更改。分发数据库仅用于复制，不包含任何用户表。绝对不可以在分发数据库中创建其它对象。订阅服务器按事务在发布服务器上应用的相同次序接收事务。
分发代理程序是 SQL Server 代理程序的一个组件，并且可以通过使用 SQL Server 企业管理器对其进行直接管理。快照代理程序与分发代理程序也可以通过使用 Microsoft ActiveX 控件嵌入到应用程序中。快照代理程序在分发服务器中运行。对于强制订阅，分发代理程序通常在分发服务器上运行，而对请求订阅，则通常在订阅服务器上运行。但是，可以使用远程代理程序激活将代理程序处理卸载到另一个服务器上进行。
当复制过程正在进行时，SQL Server 可以验证订阅服务器上正在更新的数据。由此可以保证发布服务器与订阅服务器上的数据相同。
跳过事务复制中的错误
用于事务复制的 -skiperrors 代理程序命令行参数使您得以指定可以在分发进程中跳过的错误。一般来讲，当日志读取器代理程序和分发代理以连续模式运行，并且其中之一遇到错误时，代理程序以及分发进程将停止。通过用 -skiperrors 参数指定不希望干扰复制的预期错误，分发代理程序将错误信息记入日志，然后继续运行。
清除事务复制
创建分发数据库时，SQL Server 将下列任务加入到分发服务器上的 SQL Server 代理程序中，以清除不再需要的数据：
代理程序检查
代理程序历史记录清除
事务清除
分发清除
历史记录清除
过期订阅清除
在所有订阅服务器都接收到事务后，分发清除代理程序删除分发数据库中已提交的事务。已提交事务在分发数据库中保留一段定义好的时间，这段时间称为保持期。在调度备份时设置保留期，可确保在分发数据库中具有自动恢复目的数据库所需的可用信息。
例如，如果一个订阅服务器设置为每 24 小时对目的数据库做一次事务日志转储，则可将保留期设置为 48 小时。即使订阅服务器正好在调度备份发生前遇到失败，分发服务器的分发进程仍可使用自动还原复制表所需的所有事务。
合并复制的工作机制
合并复制是由快照代理程序和合并代理程序实现的。快照代理程序准备快照文件，其中包含已发布表的架构和数据，然后将这些文件存储在快照文件夹中，并在发布数据库中插入同步作业。快照代理程序还创建复制特定的存储过程、触发器和系统表。
合并复制代理程序将保存在发布数据库表中的初始快照作业应用到订阅服务器上。该代理程序也合并那些创建初始快照之后在发布服务器或订阅服务器上发生的增量数据更改，并根据配置的规则或者使用创建的自定义冲突解决程序协调冲突。
在合并复制中分发服务器的角色非常有限，所以在本地（即在与发布服务器所在的同一台服务器上）实现分发服务器是很常见的。在合并复制过程中根本不使用分发代理程序，分发服务器上的分发数据库存储有关合并复制的历史信息和杂项信息。
UNIQUEIDENTIFIER 列
Microsoft SQL Server 2000 为所复制的表的每一行标识一个唯一列。这使行在表的多个复本中被唯一识别。如果表中已含具有 ROWGUIDCOL 属性的列，且该列具有唯一索引或主键约束，则 SQL Server 自动使用该列作为正在发布的表的行标识符。
否则，SQL Server 为正在发布的表添加一个标题为 rowguid 的 uniqueidentifier 列，该列具有 ROWGUIDCOL 属性及一个索引。添加 rowguid 列会增加发布表的大小。rowguid 列和索引将在快照代理程序第一次执行发布时添加到发布表。
触发器
然后 SQL Server 安装触发器，该触发器跟踪每行或每列的数据更改。触发器捕获对正在发布的表的更改，并将这些更改记录在合并系统表中。发布表上的跟踪触发器在发布的快照代理程序第一次运行时得以创建。当快照在订阅服务器上应用时，在订阅服务器上创建触发器。
为项目创建的不同触发器在行级或列级跟踪更改。因为 SQL Server 在正在发布的表中支持同类型的多个触发器，所以合并复制触发器不会与应用程序定义的触发器相互冲突。
存储过程
快照代理程序还创建更新订阅数据库的自定义存储过程。一个自定义存储过程用于 INSERT 语句，一个用于 UPDATE 语句，还有一个用于 DELETE 语句。当数据进行了更新，需要在订阅数据库中输入新的记录时，将使用自定义存储过程，而不使用单个的 INSERT、UPDATE 和 DELETE 语句。
系统表
SQL Server 在数据库中增加数个系统表，以支持数据跟踪、高效同步以及冲突的检测、解决和报告。对于每个已更改或已创建的行，表 MSmerge_contents 包含发生最新修改的生成。还包含总体行版本和行的每个特性。MSmerge_tombstone 在发布内存储对数据的 DELETE。这些表使用 rowguid 列来连接发布表。
这些表中的生成列相当于一个逻辑时钟，指示某一行在一个给定站点的上次更新时间。实际的 datetime 值不用于标记更改发生的时间或者确定冲突，而且站点之间的同步时钟互不相干。这使得冲突检测和冲突解决算法对时区差别和多个服务器上物理时钟间的差别更有弹性。在一个给定的站点，生成编号与合并代理程序或用户在该站点执行更改的次序相关。
MSmerge_genhistory 和 MSmerge_replinfo 使 SQL Server 得以确定需要用每个合并发送的生成。
有几个跟踪列添加到合并发布表中。如果发布表中的某些列名是为合并处理保留的，则因为有重复的列名而无法生成初始快照。保留的列名如下：
reason_code
source_object
reason_text
Pubid
conflict_type
origin_datasource
tablenick
create_time
初始快照和快照代理程序
新的订阅服务器上必须包含一些表，这些表与发布服务器上的表具有相同的架构和数据，然后才能从发布服务器上接收增量更改。将完整的当前发布从发布服务器复制到订阅服务器称为应用初始快照。SQL Server 将为您创建并应用快照，您也可以选择手工应用快照。
即使创建的订阅不能自动对其应用快照（有时称为 nosync 订阅），仍可应用快照的某些部分。必要的跟踪触发器和表在订阅服务器上创建，这意味着即使订阅指定将不自动应用快照，仍需创建并应用快照。
只有在合并复制确保订阅服务器上具有已生成的表架构和数据的最新快照之后，才会发生已更改数据的复制。在向订阅服务器分发并应用快照时，实际上只有那些需要初始快照的订阅服务器才能获得并应用快照。除非将订阅标记为重新初始化或将发布标记为重新初始化（这种情况下，与给定发布相对应的所有订阅在下一个合并进程中均将重新初始化），否则已经接受了 INSERT、UPDATE、DELETE 或对已发布数据的修改的订阅服务器不会受到影响。
一个订阅表一次只能订阅一个合并发布。例如，假定在两个发布中都发布 Customers 表，然后从一台订阅服务器订阅两个发布，并指出同一个订阅数据库将接收来自两个发布的数据。在初始化同步过程中，其中一个合并代理程序将失败。
初始快照可以是快照复制、事务复制和合并复制中的附加订阅数据库。如果使用可连接的订阅数据库，将复制订阅数据库及其订阅，并可在另一个订阅服务器上应用它们。
快照代理程序在合并复制中执行初始快照的步骤与其在快照复制中执行的步骤相似。
生成快照文件后，可以使用快照探索器在快照文件夹中查看这些快照文件。在 SQL Server 企业管理器中，展开复制及发布文件夹，右击一项发布，然后单击浏览最新快照文件夹菜单选项。
动态快照
动态快照为应用动态筛选过的合并复制快照带来了性能上的好处。通过使用 SQL Server 2000 大容量复制编程文件将数据应用到特定的订阅服务器，而不是使用 INSERT 语句，将改善对动态筛选合并发布应用初始快照的性能。
合并代理程序
一旦在订阅服务器上应用了快照，SQL Server 触发器即开始跟踪在发布服务器和订阅服务器上执行的 INSERT、UPDATE 和 DELETE 语句。
对参与合并复制的每个表都在 MSmerge_articles 表中分配一个生成时隙。当在发布服务器或订阅服务器上的合并发布中更新了某行时，即使发布服务器和订阅服务器未连接，触发器也为该行更新 MSmerge_contents 系统表中的 generation 列，更新到给定基表适当的生成时隙。当发布服务器和订阅服务器重新连接，并且合并代理程序运行时，合并代理程序将所有未提交的行更改收集到一个或多个组中，并指派一个高于所有以前生成的生成值。这使合并代理程序对更改进行批处理，反映到独立生成中不同的表中，并处理这些批以在速度低的网络中取得效率。
每个站点的合并代理程序都跟踪记录它向每一个其它站点发送的最高生成列值，以及每一个其它站点向它发送的最高生成列值。这提供了起点，使得在检查每张表时可以不检查已与其它站点共享的数据。各个站点在给定行所存储的生成列值可以是不同的，因为站点存储的这些数值反映了该站点处理更改的次序。
可以通过设置 sp_addmergepublication 或 sp_changemergepublication 的 @max_concurrent_merge 参数来限制同时运行的合并进程数。如果最大数量的合并进程已经在运行，则任何新合并进程都将在队列中等待。可以在合并代理程序命令行上设置 –StartQueueTimeout，指定代理程序在其它合并进程结束前等待的时间。如果超出了 –StartQueueTimeout 时间，且新的合并进程仍然在等待，则新进程将停止并退出。
同步
当合并复制拓扑中的发布服务器和订阅服务器重新连接，并且更新在站点之间进行传播（如果有必要的话，还要检测和解决冲突）时，即发生同步处理。在同步处理过程中，合并代理程序将所有更改过的数据发送到订阅服务器。数据从更改发生处流向需要更新或同步处理的站点。
交换方向控制合并代理程序是从订阅服务器上载更改 (-ExchangeType='Upload')、将更改下载到发布服务器 (-ExchangeType='Download')，还是先执行上载、接着执行下载 (-ExchangeType='Bidirectional')。如果必须控制所应用的更改数量，则可以配置合并代理程序命令行参数 –MaxUploadChanges 和 –MaxDownloadChanges。在这种情况下，仅当传播了所有更改后，才汇集发布服务器和订阅服务器上的数据。
在目的数据库中，从其它站点传播来的更新按照冲突检测和解决规则与现有的值进行合并。合并代理程序评估送达的数据值与当前数据值，通过默认冲突解决程序自动解决新旧数据值之间的所有冲突。该默认冲突解决程序是在创建发布时指定的，也可以是自定义的。SQL Server 2000 中的合并复制提供许多用户可自定义的冲突解决程序，帮助您实现自己的业务逻辑。
只有在同步处理发生时，更改过的数据值才被复制到其它站点并与那些站点上的更改汇聚在一起。同步发生的时间可以是几分钟、几天、甚至几星期，这可在合并代理程序调度中进行定义。同步时数据将汇集并且所有站点最终将具有相同的数据值，但是，要想实现这一点，必须停止所有更新，并在站点之间合并若干次。
为每个发布指定的订阅保持期控制发布服务器和订阅服务器应多长时间同步一次。如果在保持期内订阅未与发布服务器保持同步，则订阅将标记为失效，需要重新初始化。这是为了防止旧的订阅服务器数据将这些更改同步并上载到发布服务器。发布的默认保持期是 14 天。由于合并代理程序根据此值清除发布和订阅数据库，配置此值时一定要小心地使其与应用程序相适应。
说明 合并进程要求在订阅服务器上 sysservers 表内有发布服务器的条目。如果该条目不存在，则 SQL Server 将尝试添加该条目。如果合并代理程序所使用的登录没有添加该条目（例如订阅数据库的 db_owner）的访问权限，则将返回一个错误。
重新初始化订阅
合并复制订阅服务器以所接收的初始快照为基础进行数据更新，除非将订阅标记为重新初始化。如将订阅标记为重新初始化，则当合并代理程序再次运行时，该程序将会在订阅服务器上应用新的快照。作为一种可选操作，在重新应用快照之前，可以将在订阅服务器上进行的更改上载到发布服务器上。这样可确保订阅重新初始化之前，在订阅服务器上进行的任何更改都不会丢失。
如果在创建订阅时指定不在订阅服务器上应用初始快照（在系统存储过程 sp_addmergesubscriptionthe 中将参数 @sync_type 设置为 nosync），则在对订阅重新初始化时，将会在订阅服务器上重新应用快照。此功能可确保订阅服务器具有与发布服务器相同的架构和数据。
如果重新初始化对合并发布的所有订阅，则没有指定初始快照同步的订阅的重新初始化方式，与重新初始化具有 'automatic' 同步类型的订阅相同。若要防止将快照的复制重新应用于订阅服务器，请除去指定不进行初始快照同步处理的那个订阅，然后在重新初始化之后重新创建它。
合并代理程序是 SQL Server 代理程序的一个组件，可以直接用 SQL Server 企业管理器进行管理。也可以用 Microsoft ActiveX 控件将快照代理程序和合并代理程序嵌入到应用程序中。快照代理程序在分发服务器中运行。合并代理程序通常在分发服务器上执行强制订阅，在订阅服务器上执行请求订阅。远程代理程序激活可用于将代理程序处理负荷卸载到另一台服务器。
SQL Server 能够在复制进程中验证订阅服务器上的数据，以便可以确保在发布服务器上应用的数据更新同样也在订阅服务器上应用。
验证订阅服务器的权限
SQL Server 2000 提供了验证订阅服务器权限的选项，以将数据更改上载到发布服务器。这将验证合并代理程序登录是否具有权限，以在发布数据库上执行 INSERT、UPDATE 和 DELETE 命令。验证权限要求合并代理程序必须是在发布数据库中具有适当权限的有效用户。
除了验证在订阅服务器上所用的登录是否在发布访问列表 (PAL) 中之外，还要进行这种权限验证。
可以使用 sp_addmergearticle 存储过程中的 @check_permissions 属性设置验证订阅服务器的权限，也可使用 SQL-DMO 中的 CheckPermissions 属性进行设置。可以指定 sp_addmergearticle 存储过程中 @check_permissions 参数的一个或多个下列值。
值 描述
0（默认值） 将不检查权限。
1 在可以上载订阅服务器上进行的 INSERT 操作之前检查发布服务器上的权限。
2 在可以上载订阅服务器上进行的 UPDATE 操作之前检查发布服务器上的权限。
4 在可以上载订阅服务器上进行的 DELETE 操作之前检查发布服务器上的权限。
说明 如果在已经生成初始快照后设置 @check_permissions 参数，则必须在订阅服务器上生成并重新应用新的快照，才能在合并数据更改时验证权限。
清除合并复制
分发数据库创建完成之后，SQL Server 自动将下列任务加到 SQL Server 代理程序上，以清除不再需要的数据：
在发布服务器上清除订阅
在分发服务器上清除历史记录
这些任务有助于在一个长期运行的环境中有效地进行复制；因此，管理员应制定该周期性维护计划。清除任务删除每个发布的初始快照，并删除 Msmerge_history 表中的历史信息。
合并元数据清除
系统存储过程 sp_mergecleanupmetadata 使管理员得以清除系统表 MSmerge_contents 和 MSmerge_tombstone 中的元数据。尽管这些表可以无限扩展，但在某些情形下清理其中的元数据可提高合并性能。该过程通过压缩发布服务器和订阅服务器中上述表的大小以节省空间。
在执行该存储过程之前，将来自订阅服务器的所有数据与发布服务器合并，以载入所有必须保存的订阅服务器数据更改。执行该存储过程之后，所有合并发布的相关各级快照文件都必须重新生成。如果没有先运行快照就试图进行合并，系统将提示运行快照。
注意 当存储过程 sp_mergecleanupmetadata 执行之后，在发布涉及的订阅服务器上，所有在上述两张表中存储有元数据的订阅都被标记为重新初始化，发布服务器上的更改都将丢失，而当前快照则标记为废弃。
重新初始化自动传播合并拓扑。管理员不必手工重新初始化每个再次发布者上的所有订阅。使用带有 Service Pack 2 的 SQL Server 7.0 时，重新初始化不会自动通过合并拓扑传播。
过程 sp_mergecleanupmetadata 的 @reinitialize_subscriber 参数默认设置为 TRUE，而所有的订阅都标记为重新初始化。如果将参数 @reinitialize_subscriber 设置为 FALSE，则订阅不会标记为重新初始化。将参数设置为 FALSE 必须慎重，因为如果选择不对订阅进行重新初始化，就必须确保发布服务器与订阅服务器上的数据是同步的。
如果使用设置为 TRUE 的 @reinitialize_subscriber 参数执行 sp_mergecleanupmetadata，则将在订阅服务器上重新应用快照，即使未应用初始快照而创建了订阅（例如，当手工应用快照数据和架构或者它们已存在于订阅服务器上时）。如果不想重新初始化订阅和重新应用快照，则在确保数据在发布服务器和订阅服务器之间同步后，必须除去该订阅并重新创建为无初始同步的订阅。
在没有将订阅标记为重新初始化时，如要运行存储过程 sp_mergecleanupmetadata，必须执行以下步骤：
1. 同步所有订阅服务器。
2. 停止所有对发布及订阅数据库的更新。
3. 建议在每个订阅服务器上带命令行选项 –Validate 运行合并代理程序，借此执行合并，用发布服务器验证订阅服务器上的数据。
4. 执行系统存储过程 sp_mergecleanupmetadata。执行该存储过程之后，可允许用户再次更新发布与订阅数据库。
在所有的合并（包括连续模式的合并）结束后执行 sp_mergecleanupmetadata。控制此行为的一种方法是停用发布并在完成合并清除后再将其激活。
例如，在发布服务器上执行类似于下面的代码：
EXEC central..sp_changemergepublication 'publicationname', 'status', 'inactive'
这确保了如果已停用发布，则正在轮询发布状态的所有连续模式的合并都将失败。在所有连续模式的合并终止后执行下列语句：
EXEC central..sp_mergecleanupmetadata 'publicationname',
@reinitialize_subscriber='false'
EXEC central..sp_changemergepublication 'publicationname', 'status', 'active'
如果合并清除传播到还在活动的再次发布者，将返回一个错误信息，指出不能执行合并元数据的清除。
要使用此存储过程，发布服务器和所有订阅服务器都必须运行带 Service Pack 2 或更高版本的 Microsoft SQL Server 7.0。只有具有 sysadmin 和 db_owner 角色的成员可以使用此存储过程。要清除合并元数据，须执行系统存储过程 sp_mergecleanupmetadata。如果指定一个 @tablename 参数，则只清除该表的合并元数据。如果未指定表名，则表 MSmerge_contents 和 MSmerge_tombstone 中的所有合并元数据都将被清除。
如果在数据库上有多个发布，并且其中任何都一个使用无限发布保持期 (@retention=0)，则运行 sp_mergecleanupmetadata 将不会清除数据库的合并复制更改跟踪元数据。为此，请谨慎使用无限发布保持。