复制概述

Microsoft® SQL Server™ 2000 复制是一组解决方案，使您得以在企业范围内复制、分发和可能修改数据。SQL Server 2000 包括几种用于设计、执行、监视和管理复制的方案和选项，这些内容为您提供了分发数据和维护数据一致性所需的功能和灵活性。

主题 | 描述
复制简介 | 描述如何将复制用于不同的业务环境中。解释 SQL Server 2000 复制的模型、类型以及工作原理。
为复制制定计划 | 提供当创建复制计划时制定关键决策所需的信息，包括：业务考虑事项、企业数据需求、网络考虑事项以及复制的拓扑设计。
复制类型 | 详述复制的类型（快照复制、事务复制以及合并复制）。讨论每种类型的组件及其工作原理、构架和所提供的好处和能力。
复制工具 | 描述用于执行复制的各种主要方法，包括：使用复制向导、使用系统存储过程、用 Microsoft ActiveX® 控件编写复制应用程序，以及使用 Windows 同步管理器这类工具。
执行复制 | 描述用复制工具执行复制的步骤。包括配置分发服务器和发布服务器、创建发布、创建不同类型的订阅、在 SQL Server 2000 实例和 SQL Server 7.0 版和更低版本的实例之间进行复制。
复制选项 | 解释了每种复制类型可用的选项，包括筛选已发布数据、发布数据库对象、立即更新、排队更新和转换已发布数据。
复制数据考虑事项 | 包括处理 identity 列、timestamp 数据、uniqueidentifiers 和数据类型。
管理和监视复制 | 详述复制期间使用的代理程序、复制警报、验证订阅服务器上数据的有效性、监视复制的策略以及远程代理程序激活。
复制和异类数据源 | 描述在异类数据源（例如 DB2、Oracle、Microsoft Access 或 Microsoft Exchange）之间复制数据、向异类订阅服务器进行发布和向异类发布服务器进行订阅的方法。
复制安全性 | 讨论安全访问层与复制、Internet 安全性问题、快照文件夹安全性、代理登录安全性、角色要求和可更新订阅的安全性等问题。
增强复制性能 | 提供优化复制性能的技术，包括针对每类复制的改进技术、有效的数据分区和分发服务器选项。
备份和还原复制数据库 | 描述备份复制数据库的策略、还原每类复制的方法和还原已复制数据库的备份。
复制程序设计入门 | 讨论复制程序设计，包括使用 ActiveX 控件、SQL-DMO 和复制分发服务器接口。


复制简介

Microsoft® SQL Server™ 2000 的复制是在数据库之间对数据和数据库对象进行复制和分发并进行同步以确保其一致性的一组技术。

使用复制可以将数据分发到不同位置，通过局域网、使用拨号连接、通过 Internet 分发给远程或移动用户。复制还能够使用户提高应用程序性能，根据数据的使用方式物理分隔数据（例如，将联机事务处理 (OLTP) 和决策支持系统分开），或者跨越多个服务器分布数据库处理。

复制的优点

根据复制的类型和选择的选项，复制提供不同的优点，但是 SQL Server 2000 复制的共同优点在于需要数据时数据随时随地的可用性。

其它的优点包括：

  • 可在多个站点保存相同数据的复本。当多个站点需要为报表应用程序读取相同的数据或需要各个独立的服务器时，这一点十分有用。

  • 从大量读取数据的应用程序（如联机分析处理 (OLAP) 数据库、数据集市或数据仓库）中分离 OLTP 应用程序。

  • 允许更大的独立性。用户可以在连接断开的情况下继续使用数据的复本，然后在连接恢复时将对数据库所做的更改传播到其它数据库。

  • 分离出要浏览的数据，如使用基于 Web 的应用程序浏览数据。

  • 提高聚合读取性能。

  • 拉近了数据与个人或团体的距离。这有助于减少因多个用户进行数据修改和查询而引起的冲突，因为数据可以通过网络进行分发，所以可以根据不同商业单位或用户的需求对数据进行分区。

  • 将复制用作自定义备用服务器策略的一部分。复制是备用服务器策略的一种选择。SQL Server 2000 中的其它选择包括日志传送和故障转移群集，它们在服务器失败的情况下提供数据的复本。
何时使用复制

对于在分布式环境中使用支持多种硬件和软件应用程序的公司来说，存储冗余数据是必须的。另外，不同的应用程序对独立性和数据一致性有不同的需求。

有下列需求时，复制是分布式数据环境的一种解决方案：

  • 将数据复制或分发至一个或多个站点。

  • 依照调度方式分发数据复本。

  • 将数据更改分发到其它服务器上。

  • 允许多个用户和站点进行更改，然后将数据修改合并到一起，潜在地识别和解决冲突。

  • 生成需要在联机或脱机环境下使用的数据应用程序。

  • 生成用户可以浏览大量数据的 Web 应用程序。

  • 可以有选择地在订阅站点上进行更改，这些站点透明地处于发布服务器的事务控制之下。


复制模型

Microsoft® SQL Server™ 2000 复制使用发布工业术语来表示复制拓扑中的组件和进程。该模型由下列对象组成：发布服务器、分发服务器、订阅服务器、发布、项目和订阅。

还有几个负责在发布服务器和订阅服务器之间复制和移动数据的复制进程。它们是快照代理程序、分发代理程序、日志读取器代理程序、队列读取器代理程序和合并代理程序。有关代理程序进程的更多信息，请参见代理程序和监视器。

发布服务器

发布服务器是提供数据以便复制到其它服务器的服务器。发布服务器可以具有一个或多个发布，每个发布代表一组逻辑相关的数据。除了指定其中哪些数据需要复制之外，发布服务器还检测事务复制期间发生更改的数据并维护有关此站点上所有发布的信息。

分发服务器

分发服务器是作为分发数据库宿主并存储历史数据和/或事务以及元数据的服务器。分发服务器的角色根据执行的复制类型而不同。有关更多信息，请参见复制类型。

远程分发服务器是独立于发布服务器并配置为复制的分发服务器的服务器。本地分发服务器是既配置为复制的发布服务器又配置为复制的分发服务器的服务器。

订阅服务器

订阅服务器是接收复制数据的服务器。订阅服务器订阅的是发布而不是发布中分离的项目；并且订阅服务器只订阅其需要的发布，而不是发布服务器上所有可用的发布。根据复制的类型和所选择的复制选项，订阅服务器还可以将数据更改传播回发布服务器或将数据重新发布到其它订阅服务器。

发布

发布是一个数据库中的一个或多个项目的集合。这种多个项目的分组使得指定逻辑相关的一组数据和数据库对象以一起复制变得更容易。

项目

项目是指定要复制的数据表、数据分区或数据库对象。项目可以是完整的表、某几列（使用垂直筛选）、某几行（使用水平筛选）、存储过程或视图定义、存储过程的执行、视图、索引视图或用户定义函数。

订阅

订阅是对数据或数据库对象的复本的请求。订阅定义将接收的发布和接收的时间、地点。订阅的同步或数据分发可以由发布服务器（强制订阅）或订阅服务器（请求订阅）请求。发布可以支持强制订阅和请求订阅的混合。

请参见

执行复制

发布服务器、分发服务器和订阅服务器

订阅发布


复制类型的介绍

Microsoft® SQL Server™ 2000 可用的复制类型有三种：快照复制、事务复制和合并复制。

快照复制

快照复制是完全按照数据和数据库对象出现时的状态对其进行复制和分发的过程。快照复制不要求对更改进行连续的监视，因为对发布数据所做的更改不会增量地传播到订阅服务器。订阅服务器用数据集的完全刷新而不是单独的事务来进行更新。因为快照复制一次复制整个数据集，所以将数据修改传播到订阅服务器的时间要更长一些。复制快照发布的频率通常低于其它发布类型。

快照复制提供的选项使您得以筛选已发布的数据，允许订阅服务器修改复制的数据并将更改传播到发布服务器，然后传播到其它订阅服务器，并允许在发布时转换数据。

快照复制在下列情况会有帮助：

  • 数据主要是静态数据，不经常更改。

  • 一个时期内允许有已过时的数据复本。

  • 复制小批量数据。

  • 站点经常脱接，并且可接受高滞后时间（数据在一个站点上更新到其在另一个站点上更新之间的时间量）。
事务复制

事务复制将数据的初始快照传播到订阅服务器，然后，当发布服务器上发生数据修改时，捕获个别的事务并传播到订阅服务器。

SQL Server 2000 监视 INSERT、UPDATE 和 DELETE 语句，以及对存储过程执行和索引视图的更改。SQL Server 2000 存储影响已复制的对象的事务，然后连续或按一定的调度间隔将这些更改传播到订阅服务器。保留事务边界。例如，如果在事务中更新 100 行，则带有所有 100 个数据修改的整个事务将被接受和传播到订阅服务器，或者一个也未被接受和传播。当所有改动传播完毕后，全部订阅服务器的值将与发布服务器的值相同。

  • 事务复制提供的选项使您得以筛选已发布数据、允许订阅服务器中的用户修改复制的数据并将这些更改传播到发布服务器或其它订阅服务器，并允许在发布时转换数据。

事务复制通常在下列情况下使用：

  • 希望将数据修改传播到订阅服务器，通常在更新发生的几秒内进行。

  • 需要事务是原子事务（或者在订阅服务器上全部应用，或者都不应用）。

  • 订阅服务器通常连接到发布服务器。

  • 应用程序不能承受订阅服务器接收更改时的高延迟。
合并复制

合并复制使各站点得以自主工作（联机或脱机），并且过一段时间后将多个站点上的数据修改合并为一个统一的结果。首先在订阅服务器上应用初始快照，然后 SQL Server 2000 在发布服务器和订阅服务器上跟踪对已发布数据的更改。数据在调度时间或请求时在服务器之间进行同步。由于在多个服务器上独立地进行更新（不提交协议），发布服务器或多个订阅服务器可能更新同一数据。于是，合并更新时就可能出现冲突。

合并复制包含默认或自定义冲突解决选项，可在配置合并复制时加以定义。当冲突发生时，合并代理程序唤醒调用冲突解决程序，决定接受和向其它站点传播哪些数据。

合并复制可用的选项包括：水平和垂直筛选已发布的数据，包含联接筛选和动态筛选，使用可选同步方，优化同步以改善合并性能，验证已复制的数据以确保同步，以及使用可连接的订阅数据库。

合并复制适用于下列情况：

  • 多个订阅服务器需要在不同时刻更新数据并将这些更改传播到发布服务器和其它订阅服务器。

  • 订阅服务器需要接收数据、脱机更改数据、然后将更改同步到发布服务器和其它订阅服务器。

  • 应用程序延迟请求为高或低。

  • 站点独立很重要。

请参见

设计复制拓扑

为复制制定计划

复制选项

复制类型

验证已复制的数据


复制选项介绍

复制类型可用的各选项为您提供更多的复制解决方案，并为应用程序注入更大的灵活性和更强的控制功能。复制选项如下：

  • 筛选已发布数据

  • 发布数据库对象

  • 发布架构对象

  • 可更新订阅

  • 转换已发布的数据

  • 可选同步伙伴
筛选已发布数据

复制期间进行数据筛选使您得以只发布订阅服务器上需要的数据或数据分区。可以筛选数据以创建只包含为复制指定的列和/或行的分区。

在所有复制类型中，可以选择复制并分发完整的表，或用静态筛选水平或垂直地筛选数据。合并复制在筛选选项方面功能尤其强大，可以使用动态筛选基于接收数据的订阅服务器的属性自定义筛选。

垂直筛选数据使您得以只发布所需的数据，将数据分区到不同的站点、避免冲突（因为订阅服务器会查看和更新数据的不同子集），并根据用户需求或应用程序来管理发布。

另外，还可以选择在静态和动态筛选中使用用户定义函数，并充分利用自定义函数的功能。

合并复制还提供了联接筛选和动态筛选的附加功能。联接筛选使您得以将在一个表上创建的筛选扩展到另一个表。例如，如果正在基于客户所在的州发布客户数据，则可能希望将筛选扩展到某个特定州内客户的相关订单和订单详细信息。动态筛选可创建合并发布，然后从发布表中筛选数据。根据 Transact-SQL 函数（如 SUSER_SNAME() 或 HOSTNAME()），筛选值可以是所检索的用户 ID 或登录。

发布数据库对象

可以发布的数据库对象包括视图、索引视图、用户定义的函数、存储过程定义和存储过程的执行。可以在同一发布或不同发布中包括数据和数据库对象。发布数据库对象适用于所有类型的复制（快照复制、事务复制和合并复制）。

发布架构对象

除了数据库对象之外，还可指定是否要发布架构对象，如声明引用完整性（主键约束、引用约束和唯一约束）、聚集索引、非聚集索引、用户触发器、扩展属性和排序规则。还可以更改目的表所有者名称和数据格式为 SQL Server 2000 或异类订阅服务器进行优化。

可更新的订阅

如果使用合并复制或者使用带有可更新订阅选项的快照复制或事务复制，则可以修改订阅服务器上的数据。

快照复制和事务复制可以提供可更新订阅选项，该选项使您得以更改订阅服务器上的已发布数据并将更改传播到发布服务器和其它订阅服务器。可更新订阅选项包括即时更新、排队更新以及用排队更新作为故障转移的即时更新。

仅当发布服务器将立即接受数据时，即时更新才允许订阅服务器更新数据。如果发布服务器接受了更改，则将更改传播到其它订阅服务器。订阅服务器必须连续且可靠地连接到发布服务器，才能在订阅服务器上进行更改。

排队更新使订阅服务器得以修改数据并在与发布服务器断开连接期间将这些数据修改保存在队列中。当订阅服务器与发布服务器重新连接时，更改将传播到发布服务器。如果发布服务器接受更改，则发生普通复制进程，并且将更改从发布服务器传播到其它订阅服务器。可以将数据修改存储在 SQL Server 2000 队列中或使用Microsoft 消息队列。

带有排队更新选项的即时更新使您可以使用即时更新并在不能维持发布服务器和订阅服务器之间的连接时切换到排队更新。在切换到排队更新后，重新与发布服务器连接并清空队列，可以切换回即时更新模式。

当使用合并复制时，订阅服务器上的数据可以自动更新。

转换已发布的数据

使用快照复制或事务复制，可以在生成复制拓扑时利用数据转换服务 (DTS) 的转换映射和脚本功能。与 DTS 集成的复制使您得以根据个别订阅服务器的要求自定义和分发数据。例如，订阅服务器可能需要具有不同的表名、列名或兼容的数据类型。

通过转换已发布的数据，可以筛选数据和模拟数据的动态分区，以便来自一个快照或事务发布的数据可以分发给要求不同数据分区的订阅服务器。使用静态分区，需要为每个订阅服务器基于订阅服务器的需要创建和筛选独立分区。

可选同步伙伴

要合并发布的订阅服务器可与订阅起源所在的发布服务器以外的其它服务器进行同步。与备用合作伙伴同步使得订阅服务器在即使基本发布服务器不可用的情况下也可同步数据。当移动订阅服务器可以使用备用发布服务器访问更快或更可靠的网络连接时，此功能也很有用。

请参见

可选同步伙伴

筛选已发布数据

合并复制或可更新订阅

发布数据和数据库对象


复制的典型用法

Microsoft® SQL Server™ 2000 复制支持日益全球化和移动化企业操作的分布式环境。复制使您得以跨异类平台和数据库共享信息，然后可以修改和协调该信息。复制确保根据需要随时随地都可以得到正确的数据。

复制可应用于多种应用程序：

  • 报表、决策支持和数据仓库应用程序。

  • 联机和脱机应用程序。

  • 基于 Web 的应用程序，众多用户浏览此应用程序的数据。

  • 使数据靠近用户（提供更高的站点独立性和有效的网络使用）。


报表、决策支持和数据仓库应用程序

数据仓库是一种数据库，其中包含代表某组织机构业务历史的企业数据。该数据库用于合并那些存储在不同商务系统和异类平台的信息。数据仓库中的数据通常已经为决策支持进行了结构化和优化。

当复制在数据阶段使用以及用作数据仓库管理和开发工具时，复制成为数据仓库和决策支持环境的一个组成部分。可以使用复制来更新数据集市和数据仓库，将数据分发到用于查询和分析的只读数据库，将数据分发到联机分析处理 (OLAP) 数据库，或将数据合并以使其能转换和移动到数据仓库环境中。

复制也可以用于将合并到数据仓库环境中的数据分区，以及将数据分发到数据集市或数据仓库环境以内或以外的数据库中。

尽管 Microsoft® SQL Server™ 不能复制 SQL Server 2000 Analysis Services 对象（例如维度或多维数据集），它却可以帮助您将数据从 OLTP 数据库分发到数据中间临时数据库或将用于报表、决策支持或分析目的的数据库，并且如果需要可以在复制期间使用数据转换服务 (DTS) 的功能。

为数据仓库和决策支持系统提供一致的数据是这些操作能否成功的关键。在报表、决策支持查询或 OLAP 环境中，不同的用户组对数据有不同的要求，复制提供了分发、更新和同步数据的几个选项。

因为决策支持使用的数据主要是只读数据（用于查询和分析），所以快照复制或事务复制是常用的复制类型。使用快照复制，数据和数据库对象在指定的时刻一经出现，便立即对其进行复制和分发。如果复制到数据集市或数据仓库的数据需要数据转换，使用快照复制或事务复制时，可以将数据转换服务 (DTS) 用作复制进程的一部分。

示例

使用"复制和数据分发"中介绍过的 Northwind Traders 示例，假设 Northwind Traders 希望在数据仓库中存储历史数据，然后为 OLAP 分析优化数据仓库。他们可能需要收集企业中不同操作数据存储中的数据，合并这些数据，以及为在数据仓库中进行转换和存储作好准备。另外，如果他们决定创建一个特定的 OLAP 数据库或业务数据集市，则可以从数据仓库中复制数据并将其用于只读查询和分析。

请参见

快照复制

事务复制

转换已发布的数据


联机/脱机应用程序

Microsoft® SQL Server™ 2000 复制提供一种方案来解决外出旅行时或在脱接地点的数据访问问题。商业用户在外出旅行并需要访问数据时，经常需要使用膝上型或手提式电脑借助调制解调器拨号连接到公司网络、Intranet 或 Internet。

当移动用户连接到公司广域网 (WAN)、局域网 (LAN) 或通过 Internet 联机工作时，使用复制使其可以接收来自中央服务器（通常是发布服务器）的数据。他们可以立刻更改数据或脱机修改数据，然后在与网络重新连接的时候将这些更改传播到原始数据库和其它位置。

因为订阅服务器做出的数据修改由原始服务器异步执行，然后发送到其它服务器，所以移动用户或断开连接的用户经常使用的复制类型是使用排队更新选项的事务复制或者合并复制。

说明 在计划使用复制的联机/脱机应用程序时，要计划应用程序部署的临时维护以及把新数据集传输到脱节订阅服务器的方法。

示例

Northwind Traders 的销售代表工作地区广泛，他们需要掌握最新的客户和订单信息并在旅途中对其进行更新。Northwind 公司办事处决定发布来自存储在中央联机事务处理 (OLTP) 数据库中的 CUSTOMERS、ORDERS 和 ORDER DETAILS 表的数据，并基于销售代表所工作的地区筛选数据。销售代表所使用的膝上型或手提式电脑是数据的订阅服务器，当销售代表远离办事处或脱机时能够根据需要更新数据。

因为销售代表频繁进行数据修改且经常断开连接，所以 Northwind 管理员决定使用合并复制。当销售代表的电脑与网络重新连接时，他们可以将所做的更改与其它位置上的更改进行同步处理。

请参见

合并复制

合并复制或可更新订阅

为合并复制制定计划


基于 Web 的应用程序

通过 Internet 复制数据可使远程、脱接和匿名用户在需要时使用 Internet 连接访问数据。例如，如果 Web 站点允许用户浏览销售项目，用户将需要浏览大量数据。使用复制，系统管理员能使数据可用于在多个 Web 服务器上进行读取。浏览可以发生在任意服务器上，因而该站点可以应付更多数据传输。

复制以及基于 Web 的应用程序的另一个用途是允许单个订阅服务器下载或上载数据更改，方法是使用应用程序（该应用程序使用 Internet 浏览器）或使用到公司网络或数据驻留在其中的共享。用户使用 Microsoft® SQL Server™ 2000 通过 Internet 连接到已复制的数据的方式有：

  • 使用虚拟专用网络 (VPN)，如基于 Microsoft Windows NT® Server 4.0 版操作系统或 Microsoft Windows® 2000 Server 操作系统或第三方提供程序的 VPN。

  • 将复制与 Microsoft Proxy Server 集成在一起。

  • 使用 TCP/IP 和文件传输协议 (FTP) 通过 Internet 传输数据的初始快照。

VPN 使不与公司网络直接连接的用户可以通过 Internet 远程访问公司网络。VPN 通过一个网络连接另一个网络的组件。这一功能是通过允许用户以管道方式进入 Internet 或其它公共网络（例如，使用 Microsoft 点对点管道协议 (PPTP) ）实现的。这个过程提供了与以前专用网络相同的安全性和功能。

使用 VPN 是在 Internet 上复制数据的最安全的方法。您可以象在局域网 (LAN) 上一样使用 Windows 身份验证。

将 Microsoft SQL Server 2000 复制与 Microsoft Proxy Server 集成在一起，可允许通过 Internet 用在 Windows NT 4.0 版或 Windows 2000 Server、Proxy Server 和 SQL Server 2000 上所配置的安全性进行复制。

SQL Server 2000 可以使用 TCP/IP 套接字或多协议网络库通过 TCP/IP 在发布服务器或分发服务器与订阅服务器之间建立 ODBC 或 OLE DB 连接。然后可以配置发布以及请求订阅或匿名订阅来访问 FTP 站点，以应用初始快照文件（使用 TCP/IP 上的 ODBC 或 OLE DB 传播增量更改）。

有关更多信息，请参见通过 Internet 执行复制。


拉近数据与用户的距离

数据分发是确保用户在需要时可获得所需数据的进程。以下为使用复制为需要数据的用户提供数据的示例。发布数据：

  • 从中央站点复制数据，对数据进行分区，并将其分发到不同的区域办事处。

  • 将数据复制到只读数据库，以便用户执行查询和分析，但不会中断产品数据库的事务进程。

  • 将数据从多个数据库复制到可以成为数据集市或数据仓库的中央数据库。

  • 将数据复制到备份数据库，作为备用解决方案的一部分。

  • 复制数据支持移动、未连接的用户。

  • 在 Internet 上，使用匿名订阅使数据可用。

示例

假设 Northwind Traders 公司（Northwind 示例数据库的创建者）在全世界都有区域办事处。一些区域办事处只读取数据，而其它办事处负责更新该特定地区中的客户和订单信息。

使用复制，Northwind Traders 可以将中央订单联机事务处理 (OLTP) 数据库的分区复制到每个地区，并根据城市、地区或访问数据的用户筛选数据。

如果区域办事处只需要读取数据而不进行更改，那么中央办事处可以筛选数据以根据地区或其它准则创建适当的分区，然后将该数据发布到订阅服务器。根据发布站点上修改数据的频繁程度和数量，这种应用程序可以使用快照复制或事务复制。

如果一个区域办事处要进行更改并需要更大的独立性，则可以筛选数据并复制到该地区，而该区域办事处可在需要时更改其数据。当需要将更改传播到公司办事处或其它地区时，区域办事处可以与公司办事处同步，这样当其它地区与公司办事处同步并被公司办事处接受时，更改就会自动传播到其它地区。如果区域办事处需要将公司数据分发给同一地区的销售队伍，则可以将数据重新发布到所需的站点。

有几个选项可以调度数据分发和修改不同区域办事处的数据。如果区域办事处连续且可靠地连接，则多个办事处可以更新数据并将更改立即传播到公司办事处。然后数据在几秒内传播到其它地区（即时更新）；或者，如果某个站点在有限时间内断开连接，则数据修改可以存储在队列中，直到重新建立与公司办事处的连接（排队更新）。


复制的原理

执行和监控复制的方法有几种，而复制的进程根据选择的复制类型和选项的差异而不同。一般说来，复制包括以下几个阶段：配置复制；生成和应用初始快照；修改复制数据以及同步和传播数据。

配置复制

当配置发布服务器和分发服务器时，开始配置复制。分发服务器可以是与发布服务器不同的独立的服务器，也可以是同一台服务器。一般说来，复制包括以下几个阶段：配置复制；生成和应用初始快照；修改复制数据以及同步和传播数据。分发服务器是快照复制和事务复制的首要组件，但是在合并复制中分发服务器的角色就不是如此重要。分发服务器仅用于代理程序历史记录报表和监视。在合并复制过程中，发布服务器和分发服务器通常为同一个服务器。这称为使用本地分发服务器。

在发布服务器和分发服务器配置完毕后，可以根据数据、数据的子集和/或数据库对象创建发布。创建发布后，可以决定需要使用的复制类型、订阅服务器要订阅发布的数据库类型、要发布的数据和数据库对象、快照文件存储的位置、初始化快照进行同步的时间以及发布要使用的选项。

创建发布后，可以在发布服务器或订阅服务器上创建强制和/或请求订阅并配置复制调度和选项。

生成和应用初始快照

无论选择的是快照复制、事务复制还是合并复制，SQL Server 2000 都会创建架构和数据的初始快照，并将其保存在创建发布时选择的快照文件夹和位置中。该进程的两个例外是在合并复制中使用动态筛选和快照将手动应用的订阅。创建订阅以后，应用初始快照的时间基于创建发布时所指定的调度，或者可以手工应用快照。

快照代理程序准备包含架构、数据和数据库对象的快照文件，将文件存储在快照文件夹中，并在分发服务器上的分发数据库中（用于快照复制或事务复制）和发布数据库中（用于合并复制）记录同步作业。当合并发布使用动态筛选并且不使用动态快照时，或当订阅指定手工应用快照时，快照代理程序不准备这些文件。

对于快照复制和事务复制，分发代理程序将快照从分发数据库移动到订阅服务器上的目的表，并应用复制所需的脚本、架构和数据。对于合并复制，当合并代理程序第一次运行或为重新初始化设置订阅时，合并代理程序将快照移动到订阅服务器。然后它将应用复制所需的脚本、架构和数据。

修改已复制的数据

根据复制的类型和配置发布时所选择的选项，订阅服务器在初始快照已经复制之后能够修改数据并将更改传播到发布服务器，然后发布服务器可以将更改传播到其它订阅服务器。

下列复制类型和选项允许订阅服务器修改复制的数据：

  • 合并复制

  • 即时更新的快照复制或事务复制

  • 排队更新的快照复制或事务复制

  • 对于筛选数据的任何复制，可在单个站点修改数据分区且站点间不发生冲突。
同步和传播数据更改

选择的复制类型和选项决定着数据同步的方式和将数据更改传播到发布服务器和其它订阅服务器的方式。同步处理数据是指在初始快照已经应用于订阅服务器之后，数据在发布服务器和订阅服务器之间传播的过程。

对于快照复制，同步处理数据意味着在订阅服务器上重新应用快照，以便订阅数据库上的架构和数据与发布数据库保持一致。对于事务复制，对数据进行同步处理意味着数据插入、更新、删除和其它修改在发布服务器和订阅服务器之间分发。对于合并复制，同步处理意味着合并在多个站点进行的数据修改、检测和解决冲突（如果有的话）并将数据最终汇聚为所有站点上相同的数据值。

请参见

应用初始快照

生成初始快照

执行复制

复制选项

同步数据

复制类型


执行方法

执行复制、开发复制应用程序和维护复制的方法有：复制向导和属性、复制程序接口、系统存储过程的脚本和 Windows 同步管理器。

复制向导和属性

SQL Server 企业管理器包括几个向导和属性对话框，可以用来简化复制的安装和维护。SQL Server 企业管理器使您得以查看和修改复制的属性，并提供了图形化的导航工具。它还提供了复制文件夹和复制监视器，可以帮助您监视和解决复制过程中的疑难问题。

下列复制向导和属性对话框提供了执行复制的指导性方法：

  • 配置发布和分发向导帮助您指定一个服务器作为分发服务器，而且还可以指定其它的复制组件。在发布服务器和分发服务器初始配置完毕后，可以在"发布服务器和分发服务器的属性"对话框中对其进行修改。

  • 创建发布向导指导您完成下列过程，选择复制类型和复制选项、指定要复制的数据或数据库对象、访问发布的订阅服务器类型以及其它发布属性。使用创建发布向导创建发布后，可以在"发布属性"对话框中对其进行修改。

  • 强制订阅向导帮助创建将分发到特定订阅服务器的发布的订阅。可以在"订阅属性"对话框中查看为强制订阅选择的选项。

  • 请求订阅向导帮助创建订阅服务器所请求的发布的订阅。订阅创建后，可以在"请求订阅属性"对话框中查看其选项。

  • 禁用发布和分发向导可以帮助在服务器上禁用发布、分发、或同时禁用发布和分发。

使用向导配置复制以后，可以编写复制的不同配置进程的脚本。例如，在为一个订阅服务器创建了某个发布的标准订阅以后，可以编写该订阅的创建的脚本，在各种订阅服务器上运行该脚本，并根据需要在脚本中用正确的订阅服务器名称进行替换。有关更多信息，请参见脚本复制。

复制程序接口

执行和管理复制另外一个的方法是使用一个或组合使用复制程序接口。

  • SQL-DMO

  • 用于复制的 Microsoft® ActiveX® 控件

  • 复制分发服务器接口

与复制向导（该向导基于 SQL-DMO）相比，SQL-DMO 提供更多选项，可使用 Microsoft Visual Basic® 或 Microsoft Visual C++®（它们允许您配置或维护复制拓扑）创建自定义应用程序。SQL-DMO 可用来编制复制管理（如配置分发、创建订阅等）程序。

用于复制的 ActiveX 控件使您得以编程的方式控制快照代理程序、合并代理程序和分发代理程序活动。这使用户可以将复制编写到其应用程序中。这些控件还提供某些轻便的管理选项，以创建、删除和重新初始化订阅，以及控制、监视复制代理程序和排除复制代理程序故障。可用这些控件编制操作复制所需要的活动的程序。例如，对于提供联机和脱机功能的应用程序，可能想要表现"同步"按钮。该按钮可以与合并 ActiveX 控件相关联，每当用户单击该按钮时，合并代理程序将连接到发布服务器，并且将为指定发布进行数据同步。

复制分发服务器接口提供从异类数据源（例如 Microsoft Access 或 Oracle）复制数据的功能。复制分发接口主要供独立服务供应商或其他需要基于专用数据源开发自定义复制应用程序的用户使用。

本质上来说，当使用复制分发系统时该接口允许自定义解决方案，但开发人员采用数据修改检测功能，这些功能通常由日志读取器代理程序执行。

复制系统存储过程

复制系统存储过程编写成文档，可以作为特殊环境中执行复制的方法，也可在批处理文件和脚本中使用。然而，在大多数情况下，使用编程接口 SQL-DMO 和复制 ActiveX 控件来进行程序复制效果会更好。与直接使用存储过程相比，SQL-DMO 提供更简单的方法和更高层次的解决方案。

如果使用 SQL Server 企业管理器的脚本编写功能，则通常要用到存储过程。当编写复制脚本时，SQL Server 生成重新创建复制环境的 Transact-SQL 批处理（配置发布和分发、创建发布和订阅等等）。生成脚本以后，可以根据需要使用 SQL 查询分析器编辑它们。

Windows 同步管理器

Windows 同步管理器是 Microsoft Windows® 2000 操作系统和安装了 Microsoft Internet Explorer 5.0 或更高版本的任何操作系统中都可用的一种实用工具。它使您可以在 Microsoft SQL Server™ 的实例之间对数据进行同步处理。可以使用 SQL Server 企业管理器在 Windows 同步管理器中启用请求订阅，或通过使用用于复制的 ActiveX 控件以编程方式在同步管理器中启用订阅。

使用 Windows 同步管理器，可以调度同步或指示 Windows 当您登录到计算机上或当计算机在指定的时间长度内空闲时对选定项目自动进行同步处理。Windows 同步管理器位于 Windows"开始"菜单上的"附件"文件夹下。

请参见

开发 SQL-DMO 应用程序

复制程序设计入门

复制工具


代理程序和监视器

Microsoft® SQL Server™ 2000 复制使用的代理程序执行与复制和分发数据相关的任务。SQL Server 2000 复制使用 SQL Server 代理以及特定的复制代理程序。

SQL Server 代理

SQL Server 代理宿主并调度在复制中使用的代理程序，并提供了一种简单的方法来运行复制代理程序。SQL Server 代理程序还控制并监视除复制以外的一些其它操作，包括监视 SQL Server 代理程序服务、维护错误日志、运行作业和启动其它进程。

快照代理程序

快照代理程序将与所有的复制类型一起使用。快照代理程序准备已发布表和存储过程的架构和初始数据文件、存储快照文件以及记录分发数据库中的同步信息。快照代理程序通常在分发服务器上的 SQL Server 代理程序下运行，并用 SQL Server 企业管理器管理。

日志读取器代理程序

日志读取器代理程序将与事务复制一起使用。它将标记为复制的事务从发布服务器的事务日志移动到分发数据库中。使用事务复制发布的每一个数据库都有其自己的日志读取器代理程序，该程序运行于分发服务器上并与发布服务器连接。

分发代理程序

分发代理程序将与快照复制和事务复制一起使用。它将分发数据库上的快照作业和事务移给订阅服务器。分发代理程序通常运行于分发服务器上（对于强制订阅）或订阅服务器上（对于请求订阅）。

合并代理程序

合并代理程序将与合并复制一起使用。它将初始快照应用于订阅服务器，并移动和协调所发生的增量数据更改。每个合并订阅都有自己的合并代理程序，此合并代理同时连接发布服务器和订阅服务器并对它们进行更新。合并代理程序通常运行于分发服务器上（对于强制订阅）或订阅服务器上（对于请求订阅）。在典型的双向合并过程中合并代理程序通常从订阅服务器将更改上载到发布服务器上，然后从发布服务器将更改下载到订阅服务器上。还可以通过配置代理程序的交换类型将更改按照一个方向进行移动。

队列读取器代理程序

队列读取器代理程序将与快照复制或事务复制（使用排队更新选项）一起使用，或者如果使用排队更新立即更新作为一个故障转移选项被启用的情况下与快照复制或事务复制一起使用。

队列读取器代理程序是一个运行在分发服务器上的多线程代理程序。它负责从队列中获取消息并将它们应用于相应的发布。

与分发代理程序和合并代理程序不同，只存在一个队列读取器代理程序的实例来服务于所有的发布服务器和用于给定分发服务器的发布。

杂项代理程序

复制监视器中的 Miscellaneous Agents 文件夹下列出的清理代理程序完成复制的调度的和按需维护。

清理代理程序 | 描述 | 默认调度
代理程序历史记录清理：分发 | 从分发数据库中删除复制代理程序历史记录。 | 每 10 分钟运行一次
分发清理：分发 | 从分发数据库中删除复制的事务。 | 每 10 分钟运行一次
过期订阅清理 | 从发布数据库检测和删除过期的订阅。 | 每天凌晨 1:00 运行
重新初始化数据验证失败的订阅 | 重新初始化所有存在数据验证失败的订阅。 | 无默认调度（默认情况下未启用）。
复制代理程序检查 | 检测未活动地记录历史信息的复制代理程序。 | 每 10 分钟运行一次

复制监视器

通过 SQL Server 企业管理器中的复制监视器，可以查看和管理负责多项复制任务的复制代理程序。例如，可以设置事务复制以便可以连续读取发布服务器日志，事务可以每隔十分钟就分发给订阅服务器（尽管这经常也是连续的），以及在每晚的午夜生成初始化快照。还可以在需要时执行复制代理程序。

复制监视器提供了设置复制事件警报的一种方法。当事件发生时，通过执行您定义的任务或向某人发送电子邮件或传呼信息，复制监视器可以自动响应。

请参见

管理和监视复制

复制代理程序

复制类型


为复制制定计划

在部署复制前仔细地制定计划能够使数据一致性最大化、对网络资源的需求最小化并防止故障的发生。

在制定复制计划时请考虑以下几方面：

  • 已复制的数据是否需要更新，以及由谁来更新。

  • 与一致性、独立性和滞后时间有关的数据分发要求。

  • 包括商业用户、技术基本结构、网络和安全性以及数据特性在内的复制环境。

  • 复制类型和复制选项。

  • 复制拓扑结构及其如何与复制类型相配合。


分布式更新要素

如果分布式数据无须在一个以上的站点进行更新，则数据可以轻松地保持事务的 ACID 属性。可是，当您需要在多个站点更新数据时，应当考虑事务的 ACID 属性和站点独立将会受到怎样的影响。

ACID 属性

若要取得事务资格，单个工作单元必须坚持原子性、一致性、隔离性和持久性的 ACID 属性。

  • 原子性。若要使事务具有原子性，或者对其全部数据执行修改，或者不执行任何修改。

  • 一致性。若要具有一致性，已完成事务必须使所有数据保持一致且逻辑正确的状态。

  • 隔离性。若要满足隔离性，事务必须在另一个并发事务修改数据前它所处的状态中读取数据（尚未提交事务）。正在进行的并发修改不影响该事务。

  • 持久性。若要满足持久性，事务的修改必须持续（例如，即使系统出现错误，修改仍保留在数据库中）。在提交得到确认后，系统必须保证事务持续。

在制定复制计划时需要严格坚持 ACID 属性，因为在多台订阅服务器上独立地进行数据修改时，可能会发生冲突。如果允许冲突，那么即使检测并解决了冲突，也不能保证严格的 ACID 特性。如果考虑使用合并复制或带排队更新选项的事务复制，则需要对如何处理不满足这些属性的事务做准备。

在分布式、多更新的环境中需要两阶段提交协议 (2PC) 以保证 ACID 属性。但是，这意味着为完成更新，站点将互相依赖，并且将放弃站点独立。

有关 ACID 属性的更多信息，请参见事务。

有关 ACID 属性的问题包括：

  • 有多个订阅服务器需要执行更新吗？如果已复制的数据为只读，将不会影响 ACID 属性。

  • 如果需要在多个站点进行更新，那么允许发生冲突吗？是否为不同站点将数据筛选到不同分区中？如果需要保持事务的隔离性和持久性，那么必须避免冲突。

  • 允许取消已提交的事务以解决冲突吗？

  • 允许根据因冲突而被取消的事务的值更改后续事务吗？

如果必须保留 ACID 属性，可以使用 2PC 以便发布服务器在冲突存在之前接受所有更改，在一个站点执行全部更新，或对数据进行筛选以便站点可以更新数据的唯一子集并避免与其它站点冲突。

ACID 属性和复制

当设计复制时，请确定是否需要保持 ACID 属性以及您的应用程序要求多大程度的自治。

当考虑关于复制的 ACID 属性时，请考虑任何参与站点上的数据是否必须与所有事务只在一个站点上执行时将得到的数据相同。如果在一个站点上进行所有数据修改，事务通常是一致、隔离和持久的。请考虑在分布式环境中是否也有这些需要。

滞后时间是指从数据在一个站点（发布服务器）进行更新，到这些更改出现在另一个站点（订阅服务器）之间的时间周期。滞后时间可以从几秒到几小时、几天或更长。

复制应用程序中与 ACID 属性相关的问题包括：

  • 数据是否需要在订阅服务器上更新？

  • 允许多长的滞后时间？

若要保持严格的 ACID 属性，应该放弃站点独立，因为服务器之间必须保持持续而可靠的连接。这是保证避免冲突的唯一方式。如果允许冲突，则必须改变或撤消一些事务以解决冲突。因此，至少有些事务不是持久的，并且读取非持久事务的值的其它事务不是隔离的。

独立性

独立性是指一个站点对另一个站点的依赖度。当一个站点不依靠任何其它站点来完成其工作，同时它与任何其它站点的操作无关时，该站点实现完全独立。

2PC 就是非独立进程的一个示例，因为每次数据更改都依靠其它各个参与站点，而这些参与站点能够立即成功地接受事务。但是在复制中，2PC 优化为只依靠复制拓扑中的两台服务器：发布服务器和进行更新的订阅服务器，其中发布服务器作为判优器。

当站点需要独立地修改数据，然后将这些更改与在发布服务器和其它订阅服务器处所做的更改进行合并时，经常使用合并复制或带排队更新选项的事务性复制。

通过合并复制，数据汇聚并且所有站点最终得到相同的值；但是，因为可能会发生冲突并得以解决，所以这些值无须是只在一个站点上进行所有工作时将得到的值。所有站点都可以脱机工作，并且当所有站点同步完数据时，它们最终会具有相同的数据。但是，因为在多个位置对相同的数据进行更改，所以可能会发生冲突，并且提交某个站点的一些事务，而拒绝并解决其它事务。这些事务根据定义不是持久的。

示例

Northwind Traders 在公司总部有一台具有本地分发服务器的发布服务器，使用合并复制向四个地区销售办事处发布客户和订单信息。数据不以分区进行筛选和发布，因此对相同行的数据修改可在多个站点进行。

Northwest 办事处的销售代表通过将客户 White Clover Markets 公司的电话号码值更改为 (206) 554-2341，更改了客户信息。Southwest 办事处的销售代表使用该站点上已复制的数据，并将 White Clover Markets 的传真号更改为 (206) 555-8314。在公司总部发布站点的另一个销售代表将 White Clover Markets 的电话号码更改为 (206) 554-2241。当订阅服务器与发布服务器合并时，将会检测到冲突，并根据冲突解决策略对其进行解决。结果可能是 White Clover Markets 的新电话号码为在公司总部输入的 (206) 554-2241，并且在数据库中保留原来的传真号，而回滚在 Southwest 办事处输入的新传真号。

如果站点为自治的，则无法保证 ACID 属性。例如，合并复制允许站点独立，也允许联机或脱机更新已复制数据。但是它不保证持久性。如果打算解决冲突，那么为了解决冲突必须更改某个已提交的事务。相反，它强调数据汇集，即将在不同站点所做的更改合并入新的结果集。

有关独立性的问题包括：

  • 不同站点需要多大的独立程度？

  • 站点间是持续而可靠地连接着还是定期断开连接？

  • 保留 ACID 属性比独立性更重要吗？


评估复制环境

复制环境包括业务单元、用户、技术结构以及将寄存或使用复制的应用程序。在复制计划的这个阶段，您应该与将受复制影响的人交流，并收集有关技术基本结构的信息，包括如何存储数据和存储什么数据，何时、何地需要复制数据及如何复制数据，如何管理和维护复制。


业务目标和需要

在数据分发和数据修改方面提出问题将有助于确定分发数据的方法、使用的复制类型、使用的复制选项、复制的业务需要以及将受到复制影响的人。

数据分发

回答有关分发数据的目标的问题，将确保复制对于需要解决的问题或希望达到的目标来说是正确的解决方案。回答单位对于数据分发的需要有关的问题将有助于计划需要复制的位置及复制的频率，并有助于确定使用的复制类型。这些对象包括：

  • 复制可以帮助解决的核心问题或目标是什么？例如，要为报表服务器分发数据吗？有需要联机和脱机更新的应用程序吗？或者需要备用解决方案吗？

  • 数据分发将如何影响现有技术、管理资源、正在访问数据的人以及数据管理成本？

  • 需要何种数据及何处需要该数据？

  • 对数据的需求频率如何？

  • 需要对数据进行全面刷新，还是只需进行增量更新？

  • 需要全部表，还是可根据站点或数据的使用情况对数据进行筛选？需要复制数据库对象（例如，存储过程定义或执行、视图、触发器或用户定义的函数）吗？

  • 在何处发布数据？哪些订阅服务器需要接收这些数据？

  • 有多少订阅服务器需要这些数据？

  • 在复制过程中需要数据转换吗？
修改数据

回答修改数据的有关问题将有助于确定使用的复制类型、使用的复制选项及调度更新的时间。

  • 订阅服务器需要更新数据吗？

  • 如果多个订阅服务器更新了相同的数据集，那么允许发生冲突吗？

  • 事务之间具有相关性吗？如果某事务具有相关性，且该事务因冲突而未被提交，那么相关事务会受到影响吗？

  • 如果在订阅服务器上修改数据，数据修改的速率是多少？

  • 订阅服务器持续、可靠地连接发布数据库，还是周期性地断开连接？

  • 数据是否可以进行逻辑分区，以便各个站点可以修改它们各自的数据子集，而不会发生导致与其它站点所进行的更新冲突的更新？

  • 如果多个站点正在独立地更新相同的数据，那么如何处理冲突？

  • 必须以多快的速率将更改复制到其它站点？

  • 初始快照和数据必须以多快的速度在订阅服务器上应用？

  • 订阅服务器同步数据或传播更改的频率如何？

  • 正在发送多少更新？


需要考虑的网络因素

以下复制问题将影响网络的性能：

  • 网络的数据流量的量和典型大小。

  • 特定发布服务器的订阅服务器数目。

  • 线路速度及可靠性。

  • 发布服务器、分发服务器和订阅服务器的处理能力。

如果通过低速链接进行复制，那么可以自定义复制所涉及的代理程序的配置文件。例如，可以配置像批处理大小、轮询间隔、超时周期及可用缓冲区数之类的行为。为特定的不同代理程序配置其配置文件，配置选项也会有所不同。

当应用初始快照时，网络速度通常是最重要的问题。增量数据更改的量可能很小，但初始分发的数据量可能较大。使用 CD-ROM 或磁带设备传输快照是针对这种情况的一种解决方案。压缩快照文件也对保持网络速度有所帮助。

了解复制拓扑中服务器的处理能力将有助于决定是否使用远程代理程序激活。如果使用强制订阅，且订阅服务器具有更高的处理能力，那么您可能会使用远程代理程序激活，以便在订阅服务器，而不是分发服务器上运行分发代理程序或合并代理程序。如果使用请求订阅，并且分发服务器具有更高的处理能力，那么您可能会使用远程代理程序激活，以便在分发服务器上，而不是在订阅服务器上运行分发代理程序或合并代理程序。

可能想要对单个订阅服务器特有的已发布数据进行转换，这些订阅服务器在分发服务器上废弃了部分数据。转换可以在把数据放置在网络上之前废弃数据，这对于复制性能来说会是极大的优势，特别是在网络带宽较低时尤为突出。

请参见

代理程序配置

生成初始快照

远程代理程序激活

传输快照

转换已发布的数据


需要考虑的安全性因素

当考虑 Microsoft® SQL Server™ 2000 中的安全性时，复制类似于 SQL Server 2000 中的其它应用程序。决定因素将是数据所需的安全程度与您的环境中数据所需的可访问程度间的平衡。

在下列方面需要考虑其它安全性问题：

  • SQL Server 代理程序。

  • 快照文件的位置。

  • 测试代理连接。

  • 发布服务器的安全模式。
SQL Server 代理

客户端的 SQL Server 代理服务 (SQLServerAgent) 不应使用 LocalSystem 帐户。它需要使用标准的域帐户。SQLAgent 帐户即是这样的安全环境，默认情况下快照代理程序、合并代理程序和分发代理程序在此环境下运行。

SQL Server 代理使用的帐户是在安装 SQL Server 2000 时定义的，可随时更改。

在 Microsoft Windows® 98 操作系统上，SQL Server 代理程序和复制代理程序在登录到 Windows 操作系统的用户的安全帐户下运行。在 Microsoft Windows NT® 4.0 版和 Microsoft Windows 2000 操作系统上，复制代理程序在 SQLServerAgent 服务的登录或安全环境下运行。SQLServerAgent 服务和 SQL Server 服务均不必在 Windows 2000 管理员帐户下运行。

每个代理连接一个或多个服务器（根据代理为发布服务器、分发服务器或订阅服务器），并且必须有效登录到 SQL Server 的该实例，以完成连接。有关更多信息，请参见代理登录安全性。

快照文件的位置

存储快照的文件夹必须可以为网络上的所有订阅服务器所用。若要确保对已复制数据的快照文件的安全访问，建议您使用显式共享而不是无法授予特定权限的管理共享（例如 C$）。管理共享用作默认设置，只是因为它在 Windows NT 4.0 和 Windows 2000 上始终存在（但是它只能由管理帐户访问）。

当配置分发时，可以为所有快照文件定义默认位置。在创建发布后，可使用发布属性对话框定义快照文件的位置。

测试代理连接

在执行复制时，请确保复制代理能够与包含在复制拓扑中的所有服务器通讯。测试代理连接的一个方法是，使用 SQL 查询分析器登录到所需的服务器和数据库，或使用复制代理要使用的同一个登录（或通常情况下 SQL Server 代理使用的登录）登录到 osql。

要启用执行复制的服务器，您必须是 SQL Server 2000 系统管理员。在启用复制后，若要创建发布和订阅、唤醒调用或调度复制代理，则不必是 SQL Server 2000 系统管理员。您必须以 db_owner 的角色创建发布。添加到发布访问列表 (PAL) 的任何人可以创建对该发布（也仅限于该发布）的请求订阅。

发布服务器的安全模式

与服务器（发布服务器、分发服务器或订阅服务器）的连接可以使用 Windows 身份验证或 SQL Server 安全性。Windows 身份验证因其较强的安全性和易用性受到广泛地青睐；但是与 Windows 98 服务器的连接必须使用 SQL Server 安全性，因为 Windows 身份验证只是 Windows NT 4.0 和 Windows 2000 的功能。

建议订阅服务器连接在订阅数据库中具有 dbo 权限，从而确保被授予适当的权限并全面简化；但不要求 dbo 权限。

请参见

生成初始快照

安全管理

复制安全性

传输快照


数据需要和特性

在检查正在复制的数据时，请考虑以下问题：

  • 排序规则（定义代码页或字符集和数据排序）

  • 数据类型
字符集

如果在使用不同字符集的服务器间执行复制，Microsoft® SQL Server™ 2000 不转换任何复制的数据，并在复制时可能错译数据，因为在字符集间不可能映射所有字符。

如果可以保证使用的所有字符在所有代码页上都具有相同的代码，则复制可以成功进行，但无法保证这一点。同样，所选的排序规则所指定的比较风格会影响已复制事务的准确性。若要保证成功复制数据，服务器最好在配置时使用相同的代码页和比较风格。

通常，如果您的环境具有不同的字符集，应当考虑使用无须转换的 Unicode 数据类型。

数据类型

在确定要复制的数据时，应该考虑数据类型。您应当理解以下内容：

  • timestamp 列。对带有排队更新选项的合并复制或事务复制，当项目中包含 timestamp 列时，timestamp 列被复制，但不复制 timestamp 的字面值。当在订阅服务器上应用初始快照行时，重新生成 timestamp 值。这允许 timestamp 继续使用乐观并发控件（一种常见用法）。对于快照发布和事务发布及允许即时更新的发布，复制 timestamp 列的字面值，但是复制值的数据类型在订阅服务器上更改为二进制 (8)。有关更多信息，请参见复制数据考虑事项。

  • uniqueidentifier 列。如果使用合并复制，或者使用快照复制或带有排队更新的事务复制且被复制的表没有 uniqueidentifier 列，则 SQL Server 2000 将在创建发布时添加一个 uniqueidentifier 列。在合并复制中，SQL Server 将在生成初始快照时添加一个 uniqueidentifier 列。在快照复制或使用排队更新选项的事务复制中，SQL Server 将在创建发布时添加一个 uniqueidentifier 列。在排队更新情况下，将为行版本控制添加一个预定义的 uniqueidentifier 列，而与表中是否有全局唯一标识符 (GUID) 列无关。在排队更新中使用唯一标识符从概念上讲类似全局时戳。若要确保合并复制将再次使用现有的 uniqueidentifier 列，以唯一标识已复制的行，请确保使用列属性 ROWGUIDCOL 创建 uniqueidentifier 列。在合并复制中使用 GUID 从概念上讲类似全局主键的使用。

  • 带有 text 或 image 数据类型的列。因为这些列可能很大，所以复制它们可能需要更长时间。当使用快照复制，或使用带有即时更新或排队更新选项的事务复制时，不支持在订阅服务器上对带有 text 或 image 数据类型的复制数据进行更新。但是，当不使用可更新的订阅时，全面支持这些列的复制和更新。在合并复制中还支持发布 text 和 image 数据类型。

  • 大小写敏感性。通常，应当在发布服务器和订阅服务器上选择相同的排序规则方案（如最常见的设置是大小写敏感性）。有关更多信息，请参见指定排序规则。

例如，假设您正在发布有关客户的数据，而您在发布服务器上没有选择与订阅服务器上相同的排序规则方案。那么，会基于 state="Ca" 为特定的订阅服务器筛选数据。因为排序规则的差异，发布到订阅服务器的数据可能并非是您所需的数据。不要求选择相同的排序规则方案，并且根据您应用程序的要求，可能要选择不同的排序规则方案（例如，发布服务器可能具有区分大小写的数据，而作为报表服务器的订阅服务器可能具有不区分大小写的数据）。

  • 触发器。考虑驻留在发布表上的触发器。默认情况下，触发器与该表的数据一起发布。如果不想让该发布表上的触发器与数据一起发布，可以为特定发布更改属性中的选项。有关更多信息，请参见发布数据和数据库对象和使用 NOT FOR REPLICATION。

  • 行大小。行的大小超过最大值吗？对于合并复制，最大值为 6.000 个字符，而对于事务复制，最大值为 8.000 个字符。（大小限制不包括具有 text 和 image 数据类型的列。）

  • 数据类型映射。您需要支持在 SQL Server 7.0 或早期版本的实例中运行的订阅服务器，还是支持不在 SQL Server 版本中运行的订阅服务器？运行 SQL Server 早期版本的服务器无法复制 SQL Server 2000 所具有的数据类型。如果需要，则应当知道不同数据库之间数据类型映射的方式。有关更多信息，请参见数据类型映射。

  • 列级或数据库排序规则。根据所使用的排序规则，在不同的订阅服务器上检索数据可能不同。


为应用程序的开发制定计划

当制定复制应用程序的计划时，请考虑以下问题：

  • 设计应用程序以最小化冲突。如果订阅服务器需要读取数据，但不需要更新数据，则可以避免冲突。根据地理位置或商业用途对数据进行逻辑分区，可防止用户更新相同的数据值而避免发生冲突。

  • 对于预期可能发生并将要发生冲突的联机/脱机应用程序，合并复制通常是您应用程序的最佳选择。合并复制允许各种冲突检测和解决策略，逐行评估更新，并产生数据汇聚。

  • 建议为以读取为主、不经常更新的应用程序使用快照复制或带有即时更新或排队更新选项的事务复制。即时更新使用两阶段提交协议 (2PC)。排队更新提供解决冲突的策略，并基于事务评估更新和冲突。

  • 当使用合并复制，或使用快照复制或带有排队更新选项的事务复制时，请在执行复制前确定冲突解决策略。

  • 研究断开与数据库的连接将如何影响移动或脱接用户。如果用户未在订阅服务器立即看见他们执行的更新，发生了什么情况？

  • 数据同步有多快？应用初始快照及周期性更新分别需要多长时间？通过在将要使用的实际网络上应用初始快照，对它进行测试。如果通过网络传输花费时间太长，请考虑使用光盘或可移动媒体设备手动应用初始快照。

  • 当使用合并复制，或者使用快照复制或事务复制并允许排队更新订阅时，通过使用 identity 范围来管理 identity 值。如果创建数据分区并为各分区指派不同的标识范围，将会避免冲突的发生，因为不同的站点将使用不同的数据子集。

  • 在启用合并复制或带有即时更新或排队更新选项的事务复制之前，请确保应用程序在 INSERT 语句中使用列名，因为这些类型的复制会将列添加到发布表中。如果未在 INSERT 语句中列出这些类型的复制的列名，那么将出现错误。

  • 如果使用带即时更新或排队更新选项的事务复制，那么订阅服务器将无法更新 text 或 image 数据类型的值。发布可以包含 text 或 image 列，但是这些列可能只在发布服务器上进行更新。

  • 注意列和行大小的上限。在快照复制或事务复制中所使用的表最多可有 255 列，且每行最多为 8,000 字节。合并发布中所使用的表最大可有 246 列，行容量最大为 6,000 字节。对合并复制的限制比对事务复制的限制严格，是因为冲突表与存储有关冲突起源及冲突的特定原因的信息的附加列具有相同的结构。因为需要另外的空间记录该冲突信息，所以最大的行大小小于事务复制的最大行大小。

  • 如果具有大批量的事务，请总是将您的应用程序设计为使用存储过程修改订阅服务器上的数据，并发布存储过程的执行。

请参见

筛选已发布数据

合并复制冲突的检测和解决

合并复制或可更新订阅

排队更新冲突检测和解决


为各种类型的复制制定计划

每种类型的复制（快照复制、事务复制及合并复制）都有特定的要求和问题。在执行复制前，应当考虑这些要求和问题。

因为所有类型的复制都必须应用初始快照，所以即使选择执行事务复制或合并复制，也应该熟悉制定快照复制计划需要考虑的问题。

在考虑事务复制时，请在分发数据库中分配足够的磁盘空间以处理即将存储于其中的大量事务。

在考虑合并复制时，Microsoft® SQL Server™ 2000 在合并复制进程中使用全局唯一标识符 (GUID) 列以标识各行。如果被复制的表中没有带 ROWGUIDCOL 属性的 uniqueidentifier 列，SQL Server 2000 将为该表添加一个 uniqueidentifier 列，而您则需要解决存储在那里的其它数据。如果表已经具有 uniqueidentifier 列，您可以将 ROWGUIDCOL 属性添加到可以在合并复制过程中使用的信号。您还必须在该列添加一个唯一索引，或使其成为该表的主键。使用 uniqueidentifier 列使分布式应用程序受益匪浅，因为它保证了不会有两个站点生成相同的键值。

请参见

为快照复制制定计划

复制类型


为快照复制制定计划

快照复制需要在以下方面制定计划：

  • 传输和存储快照文件。

  • 调度快照。
传输和存储快照文件

可以选择在一个默认位置或非默认位置存储快照文件，默认位置一般位于分发服务器上。备用位置可以在另一台服务器、一个网络驱动器或可移动媒体（如光盘或可移动磁盘）上。也可以将快照文件保存到文件传输协议 (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 所做的更改。而有些应用程序可能要求对多个站点的相同行所做的更改（即使值位于不同列）应视为冲突，并在行级进行检测和解决。

有关更多信息，请参见合并复制冲突的检测和解决。

触发器和业务规则

您应当清楚所复制表上的所有触发器和约束。在未制定计划的情况下，触发器和约束可与表一起复制，并可导致合并复制过程中反复出现冲突。有关更多信息，请参见发布数据和数据库对象和使用 NOT FOR REPLICATION。

合并复制中的 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 用户帐户与发布服务器建立连接。若要设置委托，请参见 sp_addlinkedsrvlogin。
排队更新订阅需要额外考虑的因素

排队更新允许快照复制和事务复制订户修改已发布的数据，而不必一直连接在发布服务器上。

当创建发布时启用排队更新选项，一个启用了排队更新的订户对已发布数据执行了插入、更新或删除操作，所做的更改将存储在队列中。当网络连接恢复后，在发布服务器上经过排队的事务将进行异步应用。

当计划使用带有排队更新的快照复制或事务复制时，请考虑以下因素：

  • 由于更新异步传播至发布服务器，所以发布服务器或另一台订阅服务器有可能更新同一数据，而在应用更新时会发生冲突。当创建发布时，需要选择适当的冲突解决策略。

  • 对于快照复制，表应至少拥有一个唯一索引，且最好有一个主键。对于事务复制，表必须拥有一个主键。

  • 如果订阅服务器数据库进行了水平分区，且在分区中有在订阅服务器上存在而在发布服务器上不存在的行，那么订阅服务器将无法更新这些预先存在的行。在试图更新这些行时返回错误。应当先将这些行从表中删除，然后再次添加。

  • 用"标识"范围管理"标识"值以确保不同的订户具有不同的"标识"值。有关更多信息，请参见复制数据考虑事项。
转换已发布数据需要考虑的因素

借助于数据转换服务 (DTS) 的功能，可在复制过程中转换数据。创建自定义水平和垂直数据分区，创建诸如数据类型映射、列操作和字符串操作的数据转换，都是转换已发布数据的例子。

在制定转换复制数据计划时，请考虑以下因素：

  • 可转换订阅的快照数据仅限于字符模式；无法对本机格式（通常应用速度更快）使用 DTS。

  • 在为可转换订阅启用发布后，选项无法停用；必须删除现有的发布并创建一个新的发布，但是如果启用了选项，订阅无须使用它。

  • 无法对可转换订阅使用即时更新或排队更新选项（转换映射为单方向，即从发布服务器到订阅服务器）。

  • 尽管使用"转换已发布数据向导"会创建一个 DTS 包，但是这种类型的 DTS 包不能在复制外执行（从 DTS 设计器或命令提示符状态下）。但是，可以在允许转换已发布数据的事务发布和快照的复制过程中使用以 DTS 工具创建的包。

  • 将 DTS 转换引入复制将增加开销并降低分发性能。数量取决于转换的复杂程度。但不影响日志读取器代理程序的性能。

请参见

筛选已发布数据

即时更新

排队更新

转换已发布的数据


合并复制或可更新订阅

当需要在订阅服务器上对复制数据进行更新时，可使用带可更新订阅选项的快照复制或事务复制，也可使用合并复制。选择的方式取决于复制拓扑和应用程序及其用户的需要。

在以下情况下使用合并复制。 		在以下情况下使用快照复制或带有即时更新或排队更新的事务复制。
  • 在订阅服务器上读取和更新已复制数据。

  • 订阅服务器和发布服务器只偶尔连接。

  • 处理和解决由对相同数据的多个更新引起的冲突。

  • 需要逐行传播更新，并且在行级上对冲突进行评估和解决。
  • 订阅服务器上的复制数据主要为只读。

  • 订阅服务器、分发服务器和发布服务器在多数情况都是连接的，但是这对于排队更新订阅不是必要的。

  • 很少发生由对相同数据的多个更新引起的冲突。

  • 需要在事务的基础上传播更新，并且在事务的基础对冲突进行评估和解决（无论整个事务提交还是取消）。

请参见

合并复制

为合并复制制定计划

为复制选项制定计划

可更新订阅


设计复制拓扑

复制拓扑定义服务器和数据复本间的关系，以及用于决定复本间同步发生方式的逻辑。设计复制拓扑将有助于确定以下内容：更改从发布服务器到订阅服务器所需的时间，单个更新的失败是否阻止更新其它订阅服务器，以及更新信息到达订阅服务器的顺序（该顺序可影响分析和报表）。

确定复制拓扑：

  • 选择物理复制模型（中央发布服务器、带有远程分发服务器的中央发布服务器、发布订阅服务器或中央订阅服务器）。

  • 决定快照文件的位置及发布服务器和订阅服务器的初始同步方式。

  • 决定分发服务器位于本地还是远程，并决定分发数据库是否共享。

  • 决定多个发布服务器是共享一个分发服务器，而每个发布服务器使用其各自的分发数据库，还是共享一个分发数据库。

  • 确定使用的复制类型和选项。

  • 确定是在发布服务器上（使用强制订阅），还是在订阅服务器上（使用请求订阅）对复制进行初始化。

复制拓扑并不仅限于服务器间的物理连接，因为它还包含了数据复本间的数据路径。订阅服务器可从不同的发布服务器接收多个数据复本，而所有那些数据复本可在单个服务器上存在，从而组成复杂的拓扑。

请参见

同步数据

传输快照

复制类型


物理复制模型

物理复制模型是一个映射表，用于确定如何在企业内分发数据及如何在复制执行过程中配置服务器。基于在分布式数据因素、评估复制环境和为各种类型的复制制定计划中列出的所有因素和注意事项，应当能够确定复制模型的最佳解决方案。

以下是复制模型的例子：

  • 中央发布服务器。

  • 带有远程分发服务器的中央发布服务器。

  • 再次发布者。

  • 中央订阅服务器。


中央发布服务器

这种最简单的 Microsoft® SQL Server™ 2000 复制拓扑模型将一个发布服务器和一个分发服务器置于同一服务器上，而将一个订阅服务器置于单独的服务器上。

当将若干订阅服务器添加至发布服务器和分发服务器中时，该方案则变得稍微有些复杂。发布服务器拥有正在发布的数据，并成为所有订阅服务器的中央发布服务器。例如，该方案可能用于将主数据、列表或报表从中央发布服务器分发至任意数目的订阅服务器。

发布服务器和订阅服务器的角色不是互斥的；服务器可以同时担任二者。例如，假定服务器 A 发布发布 1，并且服务器 B 发布发布 2。在此情况下，服务器 A 既可作为发布 1 的发布服务器，也可作为发布 2 的订阅服务器。这是一个筛选数据和发布分区的示例。


带有远程分发服务器的中央发布服务器

随着复制活动等级的增加，或者随着服务器或网络资源变得受到限制，可能出于性能原因将发布服务器和分发服务器置于不同的服务器上。当将一个繁忙的联机事务处理 (OLTP) 服务器配置为发布服务器时，这样做可能比较适当。尽管使用单独的分发服务器会增加网络总流量，但是该方案将减少发布服务器上的本地处理工作和磁盘使用量。

这种方案类似于中央发布服务器方案，不同之处在于由单独的计算机执行发布和分发任务。当出于性能和存储空间方面的考虑，需要使发布服务器（例如，一台使用频繁的 OLTP 服务器）从分发任务中解脱出来时，此方案十分有用。发布服务器必须通过可靠、高速的通讯链接连接到分发服务器。

请参见

中央发布服务器


再次发布者

再次发布者模型使用两台服务器发布相同的数据。发布服务器将数据发送至订阅服务器，然后后者将数据重新发布至任意数目的订阅服务器。当发布服务器必须通过低速或昂贵的通讯链接向订阅服务器发送数据时，此方案十分有用。如果在链接的远端有许多订阅服务器，那么使用再次发布者会将大容量的分发负担转移到链接的远端。

在此图中，发布服务器和再次发布者（发布订阅服务器）都作为其自身的本地分发服务器。如果将其各自设置为使用远程分发服务器，则各分发服务器需要与其发布服务器位于低速或昂贵的通讯链接的同一端。发布服务器必须通过可靠、高速的通讯链接连接到远程分发服务器。

任何服务器既可作为发布服务器，又可作为订阅服务器。例如，设想发布一份位于纽约的表，它需要分发至欧洲四个不同城市：伦敦、奥斯陆、巴黎和里斯本。之所以选择位于伦敦的服务器来订阅源于纽约的发布表，是因为伦敦的站点满足下列条件：

  • 返回纽约的网络链接相当可靠。

  • 纽约到伦敦的通讯成本不太高。

  • 从伦敦到其它欧洲订阅服务器站点有良好的网络通讯线路。


中央订阅服务器

在中央订阅服务器模型中，很多发布服务器将信息复制到订阅服务器上的公用目的表中。目的表进行了水平分区，且包含作为主键一部分的位置特有的列。各发布服务器复制包含位置特有的数据的行。

该复制配置对某些情况可能有用，例如，将来自本地仓库上许多服务器的清单数据汇总到公司总部的中央订阅服务器。该配置还可用于汇总来自公司内各自治商业部门的信息，或合并来自分散位置的订单处理。


复制类型

Microsoft® SQL Server™ 2000 提供以下可用于分布式应用程序的复制类型：

  • 快照复制

  • 事务复制

  • 合并复制

根据所使用的应用程序以及事务和站点自主的不同 ACID 属性（原子性、一致性、隔离性和持久性）级别，每种类型可提供不同的功能。例如，合并复制使得用户可以自主使用和更新数据，即使没有确定的 ACID 属性。但是，当重新连接服务器时，复制拓扑中的所有站点都汇聚为相同的数据值。事务复制维护事务的一致性，但其订阅服务器站点的自主性不如合并复制，因为发布服务器和订阅服务器通常应保持不间断的连接，以使更新内容能传播到订阅服务器。

一个应用程序可以使用多个复制类型和选项。应用程序中的有些数据可能不需要在订阅服务器上更新，有些数据集可能需要偶尔更新，但是这种更新只在一个或几个服务器上进行，而有些数据集可能需要在多个服务器上每天更新。

为应用程序选择何种复制类型取决于分布式数据的因素、数据是否需要在订阅服务器上更新、复制环境，以及被复制数据的需要和要求。有关更多信息，请参见为复制制定计划。

每种类型的复制都是以在订阅服务器上生成和应用快照开始的，所以了解快照复制以及其它类型的复制和所选选项是很重要的。


快照复制

快照复制将数据以特定时刻的当时状态分发，不监视对数据的更新。对于复制不经常更改的数据，或不要求保持数据最新值（低滞后时间）的情况，快照复制是一种最好的数据复制方法。发生同步时，生成完整的快照并发送到订阅服务器。

当数据更改量大但不经常发生时，快照复制要强于事务复制。例如，如果某销售组织要维护一个产品价格表，并且这些价格每年要在固定时间进行一两次更新，建议在数据更改后复制完整的数据快照。如果发布的是只在发布服务器上更新的相对较小的表，在夜间创建快照也是一种选择。

当需要浏览只读数据，而该数据是不是最新并非至关重要时（例如浏览价格表、在线产品目录或决策支持数据），经常使用快照复制。此时如果这些订阅服务器不是正在更新数据，就允许断开连接。

满足下述条件时适合采用快照复制：

  • 数据主要是静态数据，不经常更改。当数据确实发生更改时，将一个完全新的副本发布到订阅服务器更有意义。

  • 一个时期内允许有已过时的数据复本。

  • 复制少量数据（在整个数据刷新为合理的情况下）。

当需要分发数据的只读复本时，快照复制最为适合，但快照复制还提供了在订阅服务器上更新数据的选项。当订阅服务器只读取数据时，维护发布服务器和订阅服务器之间的事务一致性。当快照发布的订阅服务器必须更新数据时，因为使用两阶段提交协议 (2PC)（即时更新选项的一个功能）传播数据，所以可以在发布服务器和订阅服务器之间维护事务一致性。快照复制比事务复制需要的经常性处理器开销少，因为快照复制不要求连续监视源服务器的数据更改。如果所复制的数据集非常大，则传输数据时将需要可观的网络资源。在决定使用快照复制是否合适时，必须考虑整个数据集的大小，以及数据更改的频繁程度。


快照复制工作机制

 复制

快照复制的工作机制

快照复制是通过快照代理程序和分发代理程序实现的。快照代理程序准备快照文件，其中包含了已发布表和数据库对象的架构和数据，然后将这些文件存储在快照文件夹中，并在分发服务器上的分发数据库中记录同步作业。快照文件夹默认位于分发服务器上，但可以指定一个备用位置取代默认位置或者与之并存。有关更多信息，请参见备用快照位置。

分发代理程序将保存在分发数据库表中的快照移动到订阅服务器上的目的表中。分发数据库仅用于复制，不包含任何用户表。

快照代理程序

快照代理程序每次运行时，都会检查是否新增了任何新订阅。如果没有新订阅，则不创建任何新的脚本或数据文件。如果创建发布时启用了"立即创建第一个快照"选项，则每次快照代理程序运行时都创建新的架构和数据文件。所有架构和数据文件都存储在快照文件夹中，然后由分发代理程序或合并代理程序将它们传送到订阅服务器，也可以手工传送。快照代理程序执行以下步骤：

  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 文件。

如果为匿名订阅启用了发布，或用"立即创建第一个快照"选项启用了发布，则在快照位置将至少保留快照文件的一个副本。如果具有快照发布匿名订阅的订阅服务器与发布服务器同步，这将确保最新的快照是可用的。

请参见

为快照复制制定计划

复制选项


事务复制

通过事务复制，在订阅服务器上应用数据的初始快照，然后，当发布服务器上发生数据修改时，捕获个别的事务并传播到订阅服务器。

满足下述情形时适合采用事务复制：

  • 希望发生增量更改时将其传播到订阅服务器上。

  • 需要遵守 ACID 属性的事务。

  • 订阅服务器可靠和/或频繁地连接到发布服务器上。

事务复制用事务日志捕获已发布表中发生的增量更改。Microsoft® SQL Server™ 2000 监视 INSERT、UPDATE 和 DELETE 语句或其它数据修改，并将这些更改存储到分发数据库中，这里分发数据库相当于一个可靠的队列。然后将更改传播到订阅服务器上，并按其发生次序加以应用。

利用事务复制，在发布服务器上进行的增量更改根据分发代理程序调度流动。可将此调度设置为连续，以获得最少滞后时间，或对订阅服务器按调度间隔进行设置。由于必须在发布服务器上进行数据更改（使用事务复制，不用立即更新或排队更新选项），避免了更新冲突。这将保证事务的 ACID 属性得到维护。最终，所有订阅服务器都将获得与发布服务器同样的值。如果事务复制使用了立即更新或排队更新选项，更新可以在订阅服务器上进行，而如果使用了排队更新，则可能发生冲突。

如果订阅服务器需要几乎实时地接收数据更改，需要建立同发布服务器的网络连接。事务复制可以为订阅服务器提供非常低的滞后时间。使用强制订阅接收数据的订阅服务器通常在一分钟或更短的时间内从发布服务器接收更改，条件是存在网络连接并具有充分的处理资源（通常可以获得几秒钟的滞后时间）。

然而，订阅服务器也可以按需请求订阅更改。一名出差途中的销售代表可以作为订户请求获得价格表的增量更改。这些价格表只在公司办公室作每晚一次的修改。离线用户获取只读数据时使用事务复制非常有效。


事务复制工作机制

事务复制是由快照代理程序、日志读取器代理程序和分发代理程序实现的。快照代理程序准备快照文件，其中包含了已发布表和数据库对象的架构和数据，然后将这些文件存储在快照文件夹中，并在分发服务器上的分发数据库中记录同步作业。

日志读取器代理程序监视已为事务复制配置的每个数据库的事务日志，并将已设复制标记的事务从事务日志复制到分发数据库中。分发代理程序将保存在分发数据库表中的事务和初始快照作业移动到订阅服务器上。

初始快照

新的事务复制订阅服务器上必须包含一些表，这些表与发布服务器上的表具有相同的架构和数据，然后才能从发布服务器上接收增量更改。将完整的当前发布从发布服务器复制到订阅服务器称为应用初始快照。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 将作为 DELETE/INSERT 对传播。

日志读取器代理程序在分发服务器上的 SQL Server 代理程序中运行，并可通过在企业管理器中的复制监视器和"代理"文件夹中对其访问，进行直接管理。

分发代理程序

事务命令存储在分发数据库中，直到分发代理程序将其传播到所有订阅服务器中，或者订阅服务器上的分发代理请求订阅更改。分发数据库仅用于复制，不包含任何用户表。绝对不可以在分发数据库中创建其它对象。订阅服务器按事务在发布服务器上应用的相同次序接收事务。

分发代理程序是 SQL Server 代理程序的一个组件，并且可以通过使用 SQL Server 企业管理器对其进行直接管理。快照代理程序与分发代理程序也可以通过使用 Microsoft ActiveX® 控件嵌入到应用程序中。快照代理程序在分发服务器中运行。对于强制订阅，分发代理程序通常在分发服务器上运行，而对请求订阅，则通常在订阅服务器上运行。但是，可以使用远程代理程序激活将代理程序处理卸载到另一个服务器上进行。有关更多信息，请参见远程代理程序激活。

当复制过程正在进行时，SQL Server 可以验证订阅服务器上正在更新的数据。由此可以保证发布服务器与订阅服务器上的数据相同。有关更多信息，请参见验证已复制的数据。

跳过事务复制中的错误

用于事务复制的 -skiperrors 代理程序命令行参数使您得以指定可以在分发进程中跳过的错误。一般来讲，当日志读取器代理程序和分发代理以连续模式运行，并且其中之一遇到错误时，代理程序以及分发进程将停止。通过用 -skiperrors 参数指定不希望干扰复制的预期错误，分发代理程序将错误信息记入日志，然后继续运行。有关更多信息，请参见处理代理程序错误。

清除事务复制

创建分发数据库时，SQL Server 将下列任务加入到分发服务器上的 SQL Server 代理程序中，以清除不再需要的数据：

  • 代理程序检查

  • 代理程序历史记录清除

  • 事务清除

  • 分发清除

  • 历史记录清除

  • 过期订阅清除

在所有订阅服务器都接收到事务后，分发清除代理程序删除分发数据库中已提交的事务。已提交事务在分发数据库中保留一段定义好的时间，这段时间称为保持期。在调度备份时设置保留期，可确保在分发数据库中具有自动恢复目的数据库所需的可用信息。

例如，如果一个订阅服务器设置为每 24 小时对目的数据库做一次事务日志转储，则可将保留期设置为 48 小时。即使订阅服务器正好在调度备份发生前遇到失败，分发服务器的分发进程仍可使用自动还原复制表所需的所有事务。

请参见

为事务复制制定计划

复制选项


合并复制

合并复制是从发布服务器向订阅服务器分发数据的过程，该复制类型使发布服务器和订阅服务器得以在连接或未连接时更新数据，然后在连接时合并所有站点的更新。

合并复制使许多不同的站点得以自主工作，然后在晚一些时候再将更新合并成一个统一的结果。首先在订阅服务器上应用初始快照，然后 Microsoft® SQL Server™ 2000 在发布服务器上和订阅服务器上跟踪已发布数据的更改。数据或是连续地、或是按调度时间或是按需在服务器之间同步。由于更新是在多个服务器上进行的，所以同一数据可能由发布服务器或者由多个订阅服务器进行了更新。于是，合并更新时就可能出现冲突。

合并复制包含默认或自定义冲突解决选项，可在配置合并复制时加以定义。当冲突发生时，合并代理程序唤醒调用一个冲突解决程序，并决定接受和向其它站点传播哪些数据。

满足下述条件时适合使用合并复制：

  • 多个订阅服务器需要在不同时刻更新数据并将这些更改传播到发布服务器和其它订阅服务器。

  • 订阅服务器需要接收数据，脱机更改数据，然后将更改同步到发布服务器和其它订阅服务器。

  • 当数据在多个站点更新时，您不希望看到许多冲突（因为数据先筛选成分区，然后发布到不同的订阅服务器；或者因为使用您的应用程序）。但是，如果确实发生了冲突，则违反 ACID 属性是可以接受的。

插入关系图（服务器和数据流 — 膝上型电脑显示偶尔有连接）

排队更新和合并复制允许脱机时在发布服务器和订阅服务器上更新；但是，在两种方法之间区别很大。有关更多信息，请参见合并复制或可更新订阅。


合并复制的工作机制

合并复制是由快照代理程序和合并代理程序实现的。快照代理程序准备快照文件，其中包含已发布表的架构和数据，然后将这些文件存储在快照文件夹中，并在发布数据库中插入同步作业。快照代理程序还创建复制特定的存储过程、触发器和系统表。

合并复制代理程序将保存在发布数据库表中的初始快照作业应用到订阅服务器上。该代理程序也合并那些创建初始快照之后在发布服务器或订阅服务器上发生的增量数据更改，并根据配置的规则或者使用创建的自定义冲突解决程序协调冲突。

在合并复制中分发服务器的角色非常有限，所以在本地（即在与发布服务器所在的同一台服务器上）实现分发服务器是很常见的。在合并复制过程中根本不使用分发代理程序，分发服务器上的分发数据库存储有关合并复制的历史信息和杂项信息。

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 属性进行设置。有关更多信息，请参见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 将不会清除数据库的合并复制更改跟踪元数据。为此，请谨慎使用无限发布保持。

请参见

为合并复制制定计划

复制选项


合并复制冲突的检测和解决

当发布服务器与订阅服务器重新连接并开始同步时，合并代理程序检测冲突，然后根据冲突解决程序决定所要接受并传播至其它站点的数据。该冲突解决程序是执行合并发布时指定的。

在合并复制中，当下述情况发生时将存在冲突：

  • 在多个复本中对同一行中的相同列进行更改（使用 INSERT、UPDATE 或 DELETE 语句），实际上存在列级冲突跟踪。

  • 在两个副本中都对某一行进行了更改，且行级跟踪有效（在相应行中所影响的列不必相同）。

说明 尽管订阅服务器正与发布服务器合并，但通常在不同的订阅服务器上进行的更新之间以及在订阅服务器和发布服务器上进行的不必要更新之间发生冲突。

冲突检测

合并代理程序根据项目数据库的表 MSmerge_contents 中的沿袭值检测冲突。表 MSmerge_contents 中的每一个条目都包含着关于一个已更新行的信息。表 MSmerge_contents 中的 lineage 列代表着在一个已更新行中所作更改的历史记录；每当对该行进行同步时，合并代理程序自动更新该列的值。

合并代理程序进行更改合并时，将检查每一个站点上该行的版本的 lineage 值。代理程序为已更新行在各个 MSmerge_contents 表（MSmerge_contents 发布服务器表，MSmerge_contents 订阅服务器表）之间比较 lineage 值，以确定该行是否在多个地点进行了更新。如果该行未曾在多个地点进行更新，则不存在冲突，将合并已更新值。如果该行曾在多个地点进行更新，则发生冲突，将唤醒调用冲突解决进程。

如果启用了列级跟踪，则合并代理程序还需要对比 MSmerge_contents 表中的 COLV 值与已更新的行。

解决冲突

当检测到冲突之后，合并代理程序启动选中的冲突解决程序。冲突的入选方根据用户指定的优先级方案、先入首选方案（先同步者在冲突中入选）选定，或者根据由 COM 对象或存储过程组成的自定义冲突解决程序选定。除非使用交互式冲突解决程序，否则一当执行冲突解决程序，立即解决冲突。落选的行写入名为 conflict_<PublicationName>_<ArticleName>_usertablename 的冲突表中（入选行则应用到发布服务器和订阅服务器）。

冲突解决程序

Microsoft® SQL Server™ 2000 使您得以选择解决合并冲突的方案。可用的方案包括：

  • SQL Server 2000 附带的基于默认优先级的冲突解决程序。当使用该解决程序时，可以分别为每个订阅服务器指派优先级值（全局订阅）或使用默认优先级指派（本地订阅），在后一种情况中，发布服务器享有数据同步时所做更改的所有权。这些更改因而比在第一次合并的基础上在其它本地订阅服务器上的更改优先。

  • 执行特定数据或业务决策规则以解决冲突的自定义冲突解决程序。自定义冲突解决程序可以作为存储过程生成，也可以作为用 Microsoft Visual C++® 或 Microsoft Visual Basic® 等语言编写的 COM 对象生成。SQL Server 2000 提供的一套用户可自定义的冲突解决程序和自定义冲突解决程序的示例。

  • 其它 Microsoft 冲突解决程序，包括累积冲突解决程序、平均化冲突解决程序、DATETIME 冲突解决程序、最大冲突解决程序、合并文本冲突解决程序、最小冲突解决程序以及首选订阅服务器冲突解决程序。

此外，SQL Server 2000 还提供了一个交互式冲突解决程序，可以与基于优先级的冲突解决程序或者与自定义冲突解决程序联合使用。当执行按需同步时，交互式冲突解决程序在运行时显示冲突数据，使您得以选择用以解决冲突的数据。还可以使用冲突查看器查看已解决冲突的结果，该查看器的用户界面与交互式冲突解决程序类似。这就是说，用户必须可以在发生合并时对交互式冲突解决程序作出响应。因此这对与人的交互无关的应用程序不适合。

在合并复制中，冲突解决按项目级（项目属性）进行，一次处理单独一行数据。对于包含多个项目的发布，可以用不同的冲突解决程序为不同的项目解决冲突，也可以同用一个冲突解决程序为一个项目、多个项目或者组成发布的所有项目解决冲突。

如果计划使用基于优先级的默认冲突解决程序，可以不为项目设置冲突解决程序属性。如果想使用自定义冲突解决程序而非默认冲突解决程序，必须为将使用该程序的项目设置冲突解决程序属性（通过在发布服务器上选择一个可用的自定义冲突解决程序完成设置）。任何需要传递到自定义冲突解决程序的特定信息，也可以在冲突解决程序信息属性中进行指定。

查看冲突

复制将会创建数张可用以查看冲突及冲突解决信息的表。此外，冲突查看器将会显示冲突行并可用作冲突查看工具。

SQL Server 2000 为合并项目中的每张表创建一张冲突表。例如，如果有一个名为 Customers 的表发布为"Northwind-Customers"发布中名为"Customer-Article"的一项，则将生成名为 conflict_Northwind-Customers_Customers-Article 的冲突表。

冲突表与其所依据的表具有相同的结构。这些冲突表中有一个表中的一行包含冲突行的落选版本（该行的入选版本位于实际用户表中）。表 sysmergearticles 标识具有冲突表的用户表，并提供关于冲突表的信息。SQL Server 还提供允许查询冲突表的存储过程。

另一个在合并复制设置中生成的冲突表为表 MSmerge_delete_conflicts。该表是为已删除冲突建立的日志记录。其中包含关于已被删除的行信息，这些行与更新相冲突并且落选，或者因为这些行是过去为实现数据汇聚而撤消删除的结果。

为理解合并冲突解决所需要了解的概念包括：

  • 行级跟踪与列级跟踪，用于指定合并代理程序是将相应行中任何值的更改标识为冲突，还是将相应行的同一列中发生的更改标识为冲突。

  • 订阅服务器类型，用于描述在进行更改同步时，是由用户为订阅服务器指定优先级值（全局订阅），还是订阅服务器使用发布服务器的优先级值（本地订阅）。


行级跟踪与列级跟踪

有几个选项可用以指定合并代理程序识别冲突的方法。其中一个选项指定是在行级识别冲突，还是在列级识别冲突。

如果在行级识别冲突，则对相应行的更改将被判断为冲突，无论更改是否发生在同一列中。例如，假定一个更改是对发布服务器行的地址列的更改，第二个更改是对相应订阅服务器行的电话号码列的更改（在同一表中）。使用行级跟踪将检测到一个冲突，因为两个行同时发生了更改。使用列级跟踪，将不会检测到冲突，因为更改是在同一行的不同列中作出的。

无论使用哪一个跟踪选项，冲突的解决方法都是相同的；整个行的数据都用冲突入选方的数据重写。在前面的例子中，假定同时在发布服务器和订阅服务器上都更改了电话号码，而只在订阅服务器行中更改了地址。如果发布服务器在冲突解决中入选，则对于行级跟踪和列级跟踪，都使用整个发布服务器行重写订阅服务器行；这样，发布服务器上电话号码的原值就重写了订阅服务器上的更改值。如果使用列级跟踪，当一个用户更改了特定行的地址，而另一个用户更改了同一行的电话号码，则不产生冲突，两个更改都将接受。

通常可以根据应用程序的语义决定采用哪个跟踪选项。例如，如果正在更新通常同时录入的客户数据，比如地址和电话号码，就应当选用行级跟踪。如果在这种情形中选择了列级跟踪，则对于某个位置的客户地址更改和另一个位置的客户电话号码更改，并不将其作为冲突检测出来：而是在同步时合并数据且没有错误信息。在其它情形中，为不同站点按单独的列作更新可能是最合理的选择。例如，两个站点可能有权访问有关某一客户的不同类型的统计数据，比如收入水平和信用卡的购物总金额。选用列级跟踪可以确保两个站点都能在不同列录入统计数据，而不会生成不必要的冲突。

列级跟踪涉及较少的跟踪开销。选用列级跟踪，结果可使合并代理程序检测到更少的冲突，但可能需要为跟踪更改提供更多的存储资源。列级跟踪在同步过程中会产生较少的网络流量，因为只将更改的列传送到合作者数据库（发布数据库或订阅数据库）。

为项目设置行级跟踪或列级跟踪

企业管理器

企业管理器

Transact-SQL


订阅类型和冲突

当创建订阅时，既可以为该订阅指定一个优先级值，也可以使用发布服务器的优先级值。

具有优先级值的订阅称为全局订阅；使用发布服务器优先级值的订阅称为本地订阅。下表概括了每种订阅类型的主要区别和用途。

类型 | 优先级值 | 已使用
全局 | 由用户指定 | 当希望不同的订阅服务器具有不同的优先级时使用。
本地订阅（包括匿名订阅） | 0.00，但在同步后更改采用发布服务器的优先级值 | 当希望所有的订阅服务器都具有相同的优先级，并且第一个与发布服务器合并的订阅服务器在冲突解决中入选时使用。 希望有大量的订阅，并且不想在发布服务器/订阅服务器上对其进行跟踪时，匿名订阅对此有所帮助。

当在全局订阅中更改一行时，将为该更改在元数据中存储订阅优先级。当更改的行与其它订阅服务器上的更改合并时，该订阅优先级将跟随此行。这确保由较高优先级订阅所进行的更改不会丢失由较低优先级订阅所进行的更改。

如果在本地订阅中更改一行，则不为该更改指定优先级，直到此行与发布服务器上的其它更改合并。在发布服务器上的合并进程中，来自订阅服务器的更改被指定发布服务器的优先级，并且，当此更改与其它发布服务器和订阅服务器上的更改合并时，将随该优先级更改。从某种意义上，发布服务器采用更改的作者身份。

全局订阅比本地订阅提供了更多的选项，并且可执行更复杂的冲突解决方案。使用全局订阅可确保在整个企业范围内保持优先级值。

本地订阅也适于在分层拓扑结构中使用（一般是要求的），这时订阅服务器是叶节点。在这些拓扑中，要重新发布数据的所有节点都必须是全局订阅服务器；本地订阅服务器只能用作叶节点。

基于订阅服务器类型和指定优先级的合并冲突解决示例

要理解根据指定优先级值解决冲突的过程，以及区分全局订阅与本地订阅的方法，请考虑以下示例。这些示例描述了在几项合并同步中对一个行所作的一系列更新。

下表为四个站点列出了初始优先级值，这些站点组成了一个简单的合并复制拓扑（一个发布服务器、两个全局订阅服务器以及一个本地订阅服务器）。

站点 | 类型 | 优先级值
A | 发布服务器 | 100.00
B | 全局订阅服务器 | 75.00（指定值）
C | 全局订阅服务器 | 50.00（指定值）
D | 本地订阅服务器 | 0.00（默认值）

阶段 1：初始值

首先，站点 A（发布服务器）创建包含值等于 Nebraska 的第一版的行，该行将在下一轮合并同步中复制给站点 B、C 和 D。同步之后，行值如下表：

站点 | 优先级值 | 行值
A（发布服务器） | 100.00 | Nebraska
B（全局订阅服务器） | 75.00 | Nebraska
C（全局订阅服务器） | 50.00 | Nebraska
D（本地订阅服务器） | 0.00 | Nebraska

阶段 2：发布服务器和全局订阅服务器都更新行

站点 A 行值更新为 Texas，站点 B 行值更新为 New Jersey。当下一次合并同步发生时，站点 A 和站点 B 之间产生冲突。站点 A 入选冲突（发布服务器始终在更新冲突中入选，即使优先级值根据默认值是相同的，但还有订阅服务器入选冲突的选项）。冲突入选方站点 A 的值传播到站点 B、C 和 D。

站点 | 优先级值 | 行值
A（发布服务器） | 100.00 | Texas
B（全局订阅服务器） | 75.00 | Texas
C（全局订阅服务器） | 50.00 | Texas
D（本地订阅服务器） | 0.00 | Texas

阶段 3：对同一行进行多个更改

假定站点 C 对行进行了更新（更改为 North Carolina），并与发布服务器同步。这不是一种冲突，因为 C 已经成功地合并了来自 A 的最新的更新（对行值 ='Texas' 成功地进行合并）。然后假定站点 B 对行进行了更新（更改为 Idaho）。

站点 | 优先级值 | 行值
A（发布服务器） | 100.00 | North Carolina
B（全局订阅服务器） | 75.00 | Idaho
C（全局订阅服务器） | 50.00 | North Carolina
D（本地订阅服务器） | 0.00 | Texas

当站点 B 与发布服务器同步时，产生更新冲突。因为站点 B 与站点 C 都是全局订阅，并且站点 B 的优先级大于站点 C，站点 B 在冲突解决中入选。当其它两个站点也合并之后，站点 B 的值就传播到其它订阅服务器上。

站点 | 优先级值 | 行值
A（发布服务器） | 100.00 | Idaho
B（全局订阅服务器） | 75.00 | Idaho
C（全局订阅服务器） | 50.00 | Idaho
D（本地订阅服务器） | 0.00 | Idaho

阶段 4：本地和全局订阅服务器都更新行

假定站点 B 更新行（改为 New Mexico），并与发布服务器同步。然后假定站点 B 更新行（更改为 California）。

站点 | 优先级值 | 行值
A（发布服务器） | 100.00 | New Mexico
B（全局订阅服务器） | 75.00 | California
C（全局订阅服务器） | 50.00 | Idaho
D（本地订阅服务器） | 0.00 | New Mexico

当站点 B 与发布服务器同步时，产生更新冲突。和前例不同，因为站点 D 为本地订阅服务器，所以站点 D 将在同步时采用发布服务器（站点 A）的优先级值。因为站点 A 的优先级比站点 B 高，站点 B 在冲突中落选；最初在站点 D 输入的值入选。（如果全局订阅服务器 B 与站点 A 的同步早于本地服务器 D，则站点 B 应在冲突中入选。）在冲突中入选的站点 D 依赖于发布服务器自上次同步在站点 D 上更新的行版本后还没有更改或接收其它更改。如果任何全局订阅服务器或任何其它本地订阅服务器先进行同步，则遵循最高优先级或最先进入发布服务器的一方入选的规则。

所有站点都同步之后的终值如下所示：

站点 | 优先级值 | 行值
A（发布服务器） | 100.00 | New Mexico
B（全局订阅服务器） | 75.00 | New Mexico
C（全局订阅服务器） | 50.00 | New Mexico
D（本地订阅服务器） | 0.00 | New Mexico

当把全局订阅服务器和本地订阅服务器在拓扑中的同一层进行混合时，将由同步的顺序和优先级值确定解决冲突的结果。本例中最后一批更新举例说明了为什么在这种情况下必须特别慎重。尽管本地订阅服务器在三个订阅服务器中的优先级最低，但是由于该订阅服务器首先与发布服务器同步（从而沿袭发布服务器的优先级，其优先级为 100.00），所以在冲突解决中入选。如果是站点 C（全局订阅服务器，优先级值为 50.00）而非站点 D中输入 New Mexico，则站点 B（全局订阅服务器，优先级值为 75.00）将在冲突解决中入选，最终结果将是 California。


默认冲突解决程序和自定义冲突解决程序

当创建合并发布时，发布中的所有项目的冲突解决程序都设置为默认冲突解决程序（如果不计划对项目使用自定义冲突解决程序，就无须选择冲突解决程序）。对每一个项目，都可以使用默认合并冲突解决程序或者选择一个可用的自定义冲突解决程序。在将发布中的一个条目指派给一个冲突解决程序后，必须在所有发布之间维护那种关联（什么时候同样的表在多个发布中）。无法在不同发布间将不同的冲突解决程序分配给同一个条目。

默认冲突解决程序

当创建强制订阅或请求订阅时，可通过将订阅标记为全局或本地的方式，指定默认冲突解决程序的行为。

SQL Server 将订阅默认设置为本地，其优先级值为 0.00。在强制订阅向导或请求订阅向导的"设置订阅优先级"页上，与该选择相应的选项为在发生冲突时使用发布服务器的优先级值。如果对所有订阅服务器保留此优先级，则结果是发布服务器更新入选冲突，并且在有冲突的订阅服务器之间，第一个要同步的订阅服务器入选冲突。对于默认合并冲突解决程序，发布服务器始终是冲突的入选方；但是，自定义的冲突解决程序可以替代此规则。

也可以为订阅指定一个特定的优先级值。在强制订阅向导或请求订阅向导的"设置订阅优先级"页上，与该选择相应的选项是为订阅服务器在从 0.00 到 99.99 的范围内设置特定优先级值。当进行这种选择并指定一个大于 0.0 的优先级时，定义一个全局订阅。

如果全局和本地订阅服务器都连接到发布服务器，并且来自优先级值大于 0.00 的全局订阅服务器的更改先进行同步，则随后来自本地订阅服务器的冲突更改将被拒绝。全局订阅服务器的优先级值较任何本地订阅服务器的优先值（在合并同步之前其值为零）为高。如果本地订阅服务器先与发布服务器同步，则随后来自全局订阅服务器或其它本地订阅服务器的冲突更改将会被拒绝。首先与发布服务器进行同步的订阅服务器沿袭发布服务器的优先级值，并在冲突解决中始终入选；但是，自定义合并冲突解决程序可以替代这些规则。

自定义冲突解决程序

合并复制允许使用各种自定义冲突解决程序处理各种情形的冲突。自定义冲突解决程序总在运行合并代理程序的地方执行。可以从一些随 SQL Server 提供的现成自定义冲突解决程序中选择，也可以编写自定义存储过程冲突解决程序，或者用 Microsoft Visual C++® 或 Microsoft Visual Basic® 等语言编写 COM 对象冲突解决程序。如果打算使用 COM 对象冲突解决程序，确保在运行合并代理程序的计算机上注册了 DLL。对于强制订阅，该计算机是分发服务器，对于请求订阅，该计算机是订阅服务器。对于使用合并 ActiveX® 控件的应用程序，应该在执行应用程序的计算机上注册冲突解决程序。

自定义冲突解决程序可以用下述方法之一载入：

  • 通过在创建发布向导中选择所需的自定义冲突解决程序。本选项位于"属性"对话框的"冲突解决程序"选项卡下。

  • 如果正在使用存储过程设置并配置合并发布，则系统存储过程 sysmergearticles 的 @article_resolver 参数包含了项目所用的自定义冲突解决程序的名称。

选择冲突解决程序

企业管理器

企业管理器

Transact-SQL


COM 自定义冲突解决程序

COM 自定义冲突解决程序是一个动态链接库 (DLL)，该动态链接库实现 ICustomResolver 接口及其方法与属性，以及其它专为冲突解决程序编写的支持接口和类型定义。

这些接口和类型定义包含在 Microsoft® Visual C++® 头文件（Sqlres.h 和 Sqlresid.h）中，这两个头文件与合并冲突解决程序示例一起提供，存放路径为 \Microsoft SQL Server\Tools\DevTools\Samples\Sqlrepl（可从 Microsoft SQL Server™ 2000 自定义安装获得）。如果您是一位 Visual C++ 开发人员，可以查看这些示例，从而了解在 Visual C++ 中生成自定义 COM 冲突解决程序的方法。

因为冲突解决程序接口基于 COM，从而在语言是中性的，所以可以在非 C++ 语言环境中创建自定义 COM 冲突解决程序。若要在 Visual Basic® 中生成自定义 COM 冲突解决程序，可以使用 replrec.dll 中提供的类型库。

编写自定义 COM 冲突解决程序之前，必须决定以下事项：

  • 决定想要解决冲突的行更改的类型，例如更新、插入或删除；决定上载或下载合并更改，或同时上载并下载。可以指定一种类型的更改、所有更改或者任何组合。默认冲突解决程序将处理任何未被自定义冲突解决程序处理的冲突。

  • 决定是否在解决冲突时使用列跟踪。不进行列跟踪意味着所有更改都在行级进行跟踪。同时在两个行内所作的任何列的更改都将标记为冲突。为解决该冲突，优先级较高的入选方为对方重写整行数据。

当打开列级跟踪时，只将那些存在冲突的列中的数据标记为冲突。否则，数据将正常合并。但是，解决冲突的方式与行级跟踪相同：优先级入选方重写整个数据行（但数据可以是发布服务器的值、订阅服务器的值或既非发布服务器又非订阅服务器上的一些已更改值的混合）。

在群集上的合并复制中使用自定义 COM 冲突解决程序时，必须在群集的两个节点上都注册自定义冲突解决程序，无论配置是主动对主动还是主动对被动。这对于确保自定义冲突解决程序能够在故障转移后正确装载协调是必需的。


指定自定义冲突解决程序

可以通过创建发布向导或者用复制存储过程指定自定义冲突解决程序。

使用创建发布向导

当用创建发布向导创建合并复制时，可以在"指定项目"页中指定自定义冲突解决程序。当选择一张表加以发布时，可看到一个属性（"..."）按钮，单击此按钮将显示该项目（即所选表）的"属性"对话框。

在"常规"选项卡下，选择是将对同一行的更改视为冲突，还是将对同一列的更改视为冲突。当把对同一列的更改视为冲突时，在同一行的不同列中的更改将被合并。

在"冲突解决程序"选项卡下，选择是使用默认冲突解决程序，还是使用自定义冲突解决程序，然后在列表中选择一个程序。如果冲突解决程序引用了一个特定的列，请在"自定义冲突解决程序信息"对话框中输入列名。

使用复制存储过程

当用复制存储过程创建合并复制时，自定义冲突解决程序在存储过程 sp_addmergearticle 或 sp_changemergearticle 中指定。

在存储过程 sp_addmergearticle 中，若要使用某一自定义冲突解决程序，请将 Microsoft 冲突解决程序描述表中的冲突解决程序名输入到参数 @article_resolver 中。输入的该程序名必须与表中的完全相同。如果要求列名，请用参数 @resolver_info 输入。

下面的示例指定在发生冲突时，使用 Microsoft SQL Server 平均化冲突解决程序在发布 ProductsPublication 中为项目 ProductsArticle 的源表 Products 计算 UnitPrice 列的平均值。

exec @ret = sp_addmergearticle @publication='ProductsCatalog',
            @article='ProductsArticle', @source_object='Products',
            @article_resolver='Averaging Conflict Resolver',
            @resolver_info='UnitPrice'

存储过程 sp_changemergearticle 用来更改现有合并项目的单个属性。参数 @property 指定要更改的属性，参数 @value 指定该属性的新值。

下面的示例在发生冲突时，为发布 ProductsPublication 中的项目 ProductsArticle 使用 Microsoft SQL Server 累积冲突解决程序计算 UnitsOnOrder 列的和。

exec @ret = sp_changemergearticle @publication='ProductsCatalog',
            @article='ProductsArticle', @property='article_resolver',
            @value='Additive Conflict Resolver'
exec @ret = sp_changemergearticle
            @publication='ProductsCatalog', @article='ProductsArticle',
            @property='resolver_info', @value='UnitsOnOrder'

请参见

Microsoft 冲突解决程序描述


交互式冲突解决程序

Microsoft SQL Server 复制提供了一个交互式冲突解决程序，使您得以在进行按需同步时手工解决冲突。运行时激活后，该交互式冲突解决程序显示每个存在冲突的行的数据，并提供选项供查看和编辑冲突数据以及逐个解决冲突。

交互式冲突解决程序和冲突查看器

交互式冲突解决程序与冲突查看器类似。但是，冲突查看器显示已在合并同步后解决的冲突结果，而交互式冲突解决程序显示每个解决前的冲突，并允许在进行合并同步时确定每个冲突的结果。发生冲突时，必须有人监视交互式冲突解决程序。

项目冲突解决程序和交互式冲突解决程序

创建发布时将为特定的项目指定冲突解决程序（Microsoft® SQL Server™ 2000 默认冲突解决程序或自定义冲突解决程序）。当输入相互冲突的行数据时，冲突解决程序使用一套预先确定的规则决定输入哪个数据集。

交互式冲突解决程序不具有确定冲突入选方与落选方的规则，不是独立的冲突解决程序，而是一个须与默认或自定义合并冲突解决程序联合使用的工具。项目冲突解决程序仍将确定入选与落选的行，而交互式冲突解决程序则使用户得以干预并决定接受、拒绝或修改其结果。当同步过程中发生冲突时，使用交互式冲突解决程序查看各个单独的冲突，编辑冲突数据，或者决定个别冲突入选方与落选方。换句话讲，可以连同默认或自定义冲突解决程序一起使用交互式冲突解决程序。

允许在订阅中使用交互式冲突解决程序的选项是作为发布属性启用的。但是，若要在检测到冲突时唤醒调用交互式冲突解决程序，需要将该选项作为订阅属性设置（在创建请求订阅向导中，使用复制存储过程或使用 ActiveX® 控件）。分别为发布及订阅完成上述属性设置之后，当在合并同步中检测到冲突时，就会调用交互式冲突解决程序。

说明 因为需要用户干预，所以交互式冲突解决程序只能在按需同步中使用，不能在调度的同步中使用。

启用交互式冲突解决程序的激活

企业管理器

企业管理器

激活交互式冲突解决程序

可以在使用 Windows 同步管理器对订阅进行同步时激活交互式冲突解决程序。

在合并同步过程中激活交互式冲突解决程序（Windows 同步管理器）

Windows

Windows NT

使用交互式冲突解决程序

交互式冲突解决程序使您得以查看、比较、编辑并选择结果数据。不能在交互式冲突解决程序中编辑的数据（例如 rowguid 数据）以只读方式显示，并且此时窗口为阴影显示。描述冲突原因的信息（例如，同时在发布服务器和订阅服务器上更新了同一行）在"冲突原因"窗口显示。

冲突数据在两个对应列中显示（"显示"列和"显示或编辑解决方法"列），订阅服务器数据显示在左边的"显示"列，而建议解决数据则显示在右边的"显示或编辑解决方法"列。"用此数据解决"按钮始终指向显示在右侧列中的数据。

如果冲突发生在已更新数据和已删除数据之间，则冲突中已删除的数据可能无法显示。在此情况下，交互式冲突解决程序在其中一列中显示一条消息，指出该行在一个地点已删除，而在另一地点已更新，并指示建议的解决方法（冲突入选方）。

交互式冲突解决程序使您得以：

  • 显示冲突行的所有列，或者只显示带有冲突数据的列。

  • 通过选择"发布服务器数据"、"订阅服务器数据"或者"建议解决方法"选项，在两个列表中显示不同组合的冲突数据。

  • 将交互式冲突解决程序会话的结果作日志记录。

  • 采取下述冲突解决操作之一：
    • 接受建议结果（按照基础冲突解决程序所选择的结果）。其方法是先为"显示或编辑解决方法"列选用"建议解决方法"选项，再单击"用此数据解决"按钮。在解决冲突之前，可以在"显示或编辑解决方法"列中修改任何可编辑的建议解决数据。

    • 接受原始发布服务器数据或者原始订阅服务器数据。其方法是在"显示或编辑解决方法"列中选择这两个选项之一，然后单击"用此数据解决"按钮。对于本选项，在解决冲突之前，可以在"显示或编辑解决方法"列中修改任何可编辑的发布服务器数据或订阅服务器数据。

    • 用项目冲突解决程序重新评估冲突，然后自动确定结果。若要用此选项，请单击"自动解决冲突"选项。
  • 使用项目冲突解决程序评估所有冲突，并自动为所有冲突确定结果。当采用此操作时，将终止为当前同步使用交互式冲突解决程序。若要用此选项，请单击"自动解决所有冲突"选项。


自定义存储过程冲突解决程序

可以创建由特殊查询和代码组成的自定义冲突解决程序，检查冲突并替代 Microsoft® SQL Server™ 2000 解决冲突的默认方法。只需用自己的同名程序替换，便可以替代默认冲突解决程序。例如，假定有多个站点参与监控一个化学反应过程，每个站点都记录一次试验中所达到的最高与最低温度。对于这样一个应用，可能不想使用按优先级或先入首选的解决方案，而希望接受最低值与最高值。

可以使用 Transact-SQL 生成自己的自定义冲突解决程序，作为每个发布服务器上的存储过程。自定义冲突解决程序总在发布服务器上执行。存储过程必须接受以下要求的参数：

参数 | 数据类型 | 描述
@tableowner | Sysname | 正在为其解决冲突的表的所有者的名称 — 这是发布数据库中表的所有者。
@tablename | sysname | 要解决冲突的表名。
rowguid | uniqueidentifier | 冲突行的唯一标识符。
subscriber | sysname | 正传播冲突更改的服务器名称。
subscriber_db | sysname | 正传播冲突更改的数据库名称。
@log_conflict OUTPUT | int | 合并进程是否需要为以后解决冲突记录冲突： 0 = 不记录冲突 1 = 订阅服务器为冲突落选方 2 = 发布服务器为冲突落选方
@conflict_merge OUTPUT | nvarchar(512) | 将提供的有关冲突解决的信息（若记录冲突）。

存储过程使用这些参数同时在发布服务器和订阅服务器上检查行中所含的值。存储过程也可以检查所指定的任何其它信息，并操作值以确定所解决的行应具有哪些列值。然后存储过程返回单个行结果集，采用的结构与基表相同，并包含入选行版本的数据值。存储过程具有使用分布式查询或其它机制从远程数据库查询值的潜在可能性。

存储过程必须要么位于发布服务器的发布数据库中，要么位于 master 数据库并标记为系统对象。执行权限必须授予 public 或者授予所有订阅服务器的列表。

说明 SQL Server 存储过程冲突解决程序将只唤醒调用处理更新冲突。无法用它们处理其它类型的冲突，如由于违反 PRIMARY KEY 或违反唯一索引约束所造成的插入失败。

当存储过程创建之后，必须配置项目将此存储过程用作其自定义冲突解决程序。通过执行 sp_addmergearticle 将存储过程与项目相关联，可以为项目指定自定义冲突解决程序。必须将参数 @article_resolver 设置为 Microsoft SQLServer Stored Procedure，并将参数 @resolver_info 设置为存储过程名。

有关更多信息，请参见通过自定义冲突解决程序开发复制合并冲突解决程序。


其它 Microsoft 冲突解决程序

当在合并过程中发生冲突时，冲突解决程序必须确定解决冲突的方法。除了默认的基于优先级的冲突解决程序和存储过程冲突解决程序外，Microsoft® SQL Server™ 2000 还包含几个自定义 COM 组件冲突解决程序可用于此目的：

  • Microsoft SQL Server 累积冲突解决程序

  • Microsoft SQL Server 平均化冲突解决程序

  • Microsoft SQL Server DATETIME（靠前入选）冲突解决程序

  • Microsoft SQL Server DATETIME（靠后入选）冲突解决程序

  • Microsoft SQL Server 最大冲突解决程序

  • Microsoft SQL Server 合并文本冲突解决程序

  • Microsoft SQL Server 最小冲突解决程序

  • Microsoft SQL Server 订阅服务器始终入选冲突解决程序

冲突解决程序在 SQL Server 2000 的安装进程中进行安装。存储过程 sp_enumcustomresolvers 可用来查看在该计算机上注册的所有冲突解决程序。在 SQL 查询分析器中，运行：

exec sp_enumcustomresolvers

此操作在一个单独的结果集中显示每个冲突解决程序的描述和全局唯一标识符 (GUID)。

冲突解决程序必须在唤醒调用合并代理程序的计算机上注册。对强制订阅，冲突解决程序在分发服务器上注册。对请求订阅，冲突解决程序必须在订阅服务器上注册。


Microsoft 冲突解决程序描述

Microsoft® SQL Server™ 2000 中的所有冲突解决程序都处理更新冲突，而且如有指明，亦可处理插入冲突和删除冲突。所有冲突解决程序都处理列跟踪，大多数也处理行跟踪。这些冲突解决程序和所有其它的自定义冲突解决程序都声明它们能处理的冲突类型，而合并复制代理程序使用默认冲突解决程序处理所有其它冲突类型。

下表描述了特定冲突解决程序的特性。有关如何指定要求的输入的信息，请参见指定自定义冲突解决程序。

名称 | 要求的输入 | 描述 | 注释
Microsoft SQL Server 累积冲突解决程序 | 所要求和的列的名称。必须具有算术数据类型（如 int、smallint、numeric 等等）。 | 按照优先级确定冲突解决的入选方。指定的列值设置为源和目的列值的和。如其中一列设为 NULL，则结果按另一列的值设定。 | 只支持更新冲突和列跟踪。
Microsoft SQL Server 平均化冲突解决程序 | 所要平均化的列的名称。必须具有算术数据类型（如 int、smallint、numeric 等等）。 | 按照优先级确定冲突解决的入选方。结果列值设置为源和目的列值的平均值。如其中一列设为 NULL，则结果按另一列的值设定。 | 只支持更新冲突和列跟踪。
Microsoft SQL Server DATETIME（靠前入选）冲突解决程序 | 用于确定冲突入选方的列名称。它必须有 DATETIME 数据类型。 | 具有较早的 datetime 值的列决定冲突的入选方。如果其中一列设为 NULL，则包含另一个的行入选。 | 支持更新冲突、行和列跟踪。列值直接进行比较，并且不对不同的时区进行比较。
Microsoft SQL Server DATETIME（靠后入选）冲突解决程序 | 用于确定冲突入选方的列名称。它必须有 DATETIME 数据类型。 | 具有较晚的 datetime 值的列决定冲突的入选方。如果其中一列设为 NULL，则包含另一个的行入选。 | 支持更新冲突、行和列跟踪。
Microsoft SQL Server 最大冲突解决程序 | 用于确定冲突入选方的列名称。必须具有算术数据类型（如 int、smallint、numeric 等等）。 | 具有较大数值的列决定冲突的入选方。如果其中一列设为 NULL，则包含另一个的行入选。 | 支持行和列跟踪。
Microsoft SQL Server 合并文本冲突解决程序 | 无输入。合并有冲突的文本列。 | 按照优先级确定冲突解决的入选方。有冲突的文本列设置为合并值，该值的构成是：通用前缀，接着是源文本的特有部分，换行符，最后是目的文本的特有部分。 | 只支持更新冲突和列跟踪。
Microsoft SQL Server 最小冲突解决程序 | 用于确定冲突入选方的列名称。必须具有算术数据类型（如 int、smallint、numeric 等等）。 | 具有最小数值的列决定冲突的入选方。如果其中一列设为 NULL，则包含另一个的行入选。 | 支持更新冲突、行和列跟踪。
Microsoft SQL Server 订阅服务器始终入选冲突解决程序 | 无输入。无数据类型限制。 | 订阅服务器，无论作为源或目的服务器，始终是入选方。 | 支持所有冲突类型。


选择冲突解决程序

选择冲突解决程序时，需要考虑在复制应用中解决冲突的重要性，并决定是否要生成自定义冲突解决程序。

如果数据是分区的，没有多个用户对同一分区进行写入，而且复制拓扑也相对简单（一个发布服务器加上几个订阅服务器），则冲突将极少发生或根本不存在冲突。在这些环境中，不需要复杂的冲突解决策略。推荐策略为使用默认的冲突解决设置，使用本地订阅服务器及首次更改入选规则。

另一个要考虑的因素是决定要生成自定义冲突解决程序，还是使用默认合并冲突解决程序。如果业务上需要精确调节的解决方案，而默认冲突解决程序不能满足这一需要，并且与自定义冲突解决程序相关联的表都相对比较稳定，或者更新自定义冲突解决程序不是问题，则使用自定义冲突解决程序将是较好的选择。

选择使用默认冲突解决程序或是自定义冲突解决程序，以及在自定义冲突解决程序中所用的逻辑关系，必须基于数据才能决定。例如，假定雇员向一系列未分区的副本输入客户排名数据时，跨越多个工作分类（分公司经理、产品经理、销售人员），并且工作分类决定谁的数据具有优先级。在这种情况下，可以生成一个自定义冲突解决程序，使用项目工作类别数据在发生冲突时确定优先入选方。

自定义冲突解决程序通常是针对一个特定的表而设计的；如果项目所用的表发生了修改（例如，重命名冲突解决中使用的列名），则自定义冲突解决程序必须修改并重新编译。

如果冲突有可能频繁发生，下面列出了当实施冲突解决策略时所要考虑的最重要的决定：

冲突解决问题 | 建议
不同分类的用户要求不同的优先级值。
  • 使用默认合并冲突解决程序并创建具有不同优先级值的全局订阅服务器。

    或

  • 使用自定义冲突解决程序识别项目的授权值列，帮助解决冲突。
要求首次更改入选冲突解决方案。 | 使用默认合并冲突解决程序并创建本地订阅服务器。
允许多个用户更改同一数据行，只要不在同一列中作出有冲突的更改。 | 使用具有列级跟踪的默认合并冲突解决程序或者自定义冲突解决程序。
将对行内任何值的多次更改标记为冲突。 | 使用具有行级跟踪的默认合并冲突解决程序或者自定义冲突解决程序。
冲突解决结果数据应该与原始冲突数据不同。 | 使用计算新值的自定义冲突解决程序。另一种方法是可选的，可以使用存储过程冲突解决程序并编写一个返回包含新数据的结果集的自定义存储过程。


复制工具

Microsoft® SQL Server™ 2000 提供了几种执行和管理复制的方法，包括 SQL Server 企业管理器、程序接口和其它 Microsoft Windows® 组件。

SQL Server 企业管理器包括一个复制对象的图形化结构、几个向导，以及可用来简化复制的配置和管理的对话框。SQL Server 企业管理器使您得以查看及修改复制配置的属性，对复制活动进行监视和疑难解答。

还可以使用用于复制的 Microsoft ActiveX® 控件、SQL-DMO 和 Transact-SQL 系统存储过程脚本等编程接口执行、监视和维护复制。

像 Windows 同步管理器和 Active Directory 服务这样的组件使您得以在 Windows 应用程序中执行同步数据、订阅发布以及组织和访问复制对象。


复制和 SQL Server 企业管理器

使用 SQL Server 企业管理器可执行、管理和监视企业范围内整个复制环境。

SQL Server 企业管理器提供 Replication 文件夹，作为组织和管理发布和订阅的中央位置。如果安装了 Microsoft 公司或其它公司的异类发布服务，则在 Replication 文件夹下将出现 Heterogeneous Replication 文件夹，作为基于异类数据源管理分发和订阅的位置。

复制监视器

通过复制监视器，可以查看和管理负责多项复制任务的复制代理程序。在配置了发布和分发之后，复制监视器将作为分发服务器上 SQL Server 企业管理器中 Replication 文件夹下的一个节点出现。

例如，可设置复制以便连续读取发布服务器日志，每隔十分钟向订阅服务器分发一次事务，并在每天午夜生成初始化快照。还可以在需要时执行复制代理程序。

复制监视器提供了设置复制事件警报的一种方法。当事件发生时，通过执行您定义的任务或向某人发送电子邮件或传呼信息，复制监视器可以自动响应。

如果任务设置为使用 Windows NT 日志，则任务历史记录中的事件也可写入 Microsoft Windows NT® 4.0 或 Windows 2000 的应用程序日志，并可用事件查看器进行查看。有关使用事件查看器的信息，请参见 Windows NT 4.0 或 Windows 2000 帮助。

SQL Server 代理是一个 SQL Server 2000 内部工具，用来宿主和调度复制中使用的代理程序，并提供运行复制代理程序的简便方法。SQL Server 代理同时还控制并监视除复制以外的一些其它操作，包括监视 SQLServerAgent 服务、维护错误日志、运行作业和启动其它进程。

通过 SQL Server 企业管理器可访问的另外一个工具是复制冲突查看器。复制冲突查看器帮助您查看和解决在合并复制过程中或排队更新过程中发生的冲突。

请参见

管理和监视复制

合并复制冲突的检测和解决

排队更新冲突的检测和解决


复制向导

Microsoft® SQL Server™ 包括复制向导，用以简化复制的配置和执行。在 SQL Server 企业管理器中可访问复制向导。在"工具"菜单上指向"复制"子菜单，然后单击适当的向导。

配置发布和分发向导

使用配置发布和分发向导可以：

  • 指定要配置为分发服务器的服务器。

  • 将 SQLServerAgent 服务配置成在启动计算机时手动或者自动启动。

  • 自定义分发数据库属性、启用分布服务器、启用订阅服务器和设置发布设置。
创建发布向导

用创建发布向导可指定：

  • 用作新发布的模板的现有发布。

  • 要创建的发布类型（快照、事务或合并）。

  • 包含在发布中的数据和数据库对象（项目）。

  • 发布的名称和描述。

  • 水平和垂直数据筛选、用于合并发布的动态和联接筛选。

  • 是否允许匿名订户。

  • 快照代理程序调度以及是否立即运行快照代理程序。

如果在向导的"欢迎"页中选中"显示本向导中的高级选项"复选框，并且创建了快照或事务发布，则可指定以下内容：

  • 启用可更新订阅，包括即时更新和/或排队更新。

  • 启用转换已发布数据，以便在将数据分发到订阅服务器之前转换数据。
创建请求订阅向导

创建请求订阅向导使您得以在订阅服务器启动订阅，并从发布服务器请求要复制的数据。通过创建请求订阅向导可以：

  • 选择要订阅的发布服务器和发布。

  • 选择准备接收所发布的数据的订阅服务器（目的）数据库。

  • 指定订阅的初始值，以便在订阅服务器处应用架构和数据的快照。

  • 指定快照文件的位置，以及在初始化订阅时访问这些快照文件的方式。

  • 设置代理调度，该调度用于指定向订阅服务器传播更新内容的频率。

  • 指定数据是否在分发之前进行转换（用于允许转换已发布数据的快照或事务发布）。

  • 指定在创建订阅之后是自动启动所需的服务，还是手动启动所需的服务。
创建强制订阅向导

创建强制订阅向导使您得以在发布服务器上指定要复制到指定订阅服务器的数据。用创建强制订阅向导可以：

  • 选择接收已发布数据的一个或多个订阅服务器或订阅服务器组。

  • 指定订阅服务器上将发布数据的数据库。

  • 指定分发代理程序运行的位置（用于快照复制或事务复制）。

  • 设置代理调度，该调度用于指定向订阅服务器传播更新内容的频率。

  • 指定订阅的初始值，以便在订阅服务器处应用架构和数据的快照。

  • 指定数据是否在分发之前进行转换（用于允许转换已发布数据的快照或事务发布）。

  • 设置订阅的优先级值以确定在检测到冲突时的入选方（用于合并复制）。

  • 指定在创建订阅之后是自动启动所需的服务，还是手动启动所需的服务。
定义已发布数据的转换

配置了允许转换已发布数据的发布之后，将能够使用定义已发布数据的转换向导。此向导使您得以创建用于定义数据转换的数据转换服务 (DTS) 包。可指定：

  • 将使用该包的订阅服务器和订阅服务器使用的身份验证方式。

  • 发布数据时进行的列映射和数据转换，包括 Microsoft ActiveX® 或 Java 脚本。

  • DTS 包在运行分发代理程序的服务器上的位置。

  • 包的名称、描述和安全性。

说明 在定义已发布数据的转换向导中创建的 DTS 包在复制外部无法使用。但是，使用 DTS 工具独立于复制所创建的 DTS 包在复制期间可用来转换已发布数据。

创建动态快照作业向导

创建动态快照作业向导引导您一步步地创建用于动态筛选合并复制的动态快照。在本向导中，可以：

  • 指定筛选准则页，包括发布的动态筛选中所使用的任何系统或用户定义函数以及发布服务器的登录值。

  • 指定保存快照文件的快照文件位置。

  • 设置动态快照代理程序调度。

  • 指定该动态快照代理程序的代理程序名称。

说明 在创建动态快照之前，必须生成到动态筛选的合并发布的常规快照。

禁用发布或分发内容向导

禁用发布和分发向导使您得以在服务器上禁用发布、分发或者同时禁用此二者。还可以：

  • 指定是否在运行向导的服务器上禁用发布。

  • 确认要除去的发布。

请参见

配置复制

禁用发布和分发

动态快照

发布数据和数据库对象

订阅发布

转换已发布的数据


复制属性

配置了复制之后，可使用复制的属性对话框查看和修改选项。属性可用于发布服务器和它的订阅服务器、分发服务器、发布、强制订阅、请求订阅和复制代理程序。

发布服务器和分发服务器属性

使用配置发布和分发向导配置了一个发布服务器和分发服务器之后，可使用发布服务器和分发服务器属性查看和修改其选项。发布服务器和分发服务器属性包括以下选项卡和信息。

选项卡 | 信息
分发服务器 | 分发服务器名称、分发数据库、分发数据库属性、用于创建或删除分发数据库的按钮、用于查看所有复制代理程序的代理配置文件的按钮、发布服务器连接到分发服务器所用的管理链接密码。
发布服务器 | 已在复制期间启用，以便使用此分发服务器的发布服务器列表，以及启用、禁用或指定新发布服务器的按钮。
发布数据库 | 为事务复制（包括快照复制）和/或合并复制所启用的数据库列表，以及为事务复制和/或合并复制启用或禁用数据库的按钮。
订阅服务器 | 配置为从此分发服务器接收数据的订阅服务器，以及启用、禁用或指定新订阅服务器的按钮。

打开发布服务器和分发服务器的属性

企业管理器

企业管理器

发布属性

使用创建发布向导创建发布之后，可使用发布属性查看和修改大多数选项。某些选项仅当创建了发布后才可指定，而某些选项如果当前有发布的活动订阅，则无法更改。发布属性包括以下选项卡和信息。

选项卡 | 信息
常规 | 发布名称、发布数据库、描述、发布类型和订阅期限。
项目 | 将要作为发布的一部分而发布的数据和数据库对象。可显示和添加当前没有发布的对象，并设置项目属性。
筛选列 | 使您得以从一个表项目当中选择要发布的列。也可向表和发布中添加一列。如果在创建发布时指定不筛选任何项目，"筛选列"选项卡将不显示在发布属性中。
筛选行 | 在表项目上显示所有的行筛选。单击表项目属性（"..."）按钮便可添加行筛选。如果在创建发布时指定不筛选任何项目，"筛选行"选项卡将不会出现在发布属性中。
订阅 | 显示强制订阅。此选项卡还提供用于创建、删除、重新初始化、全部重新初始化和查看订阅属性的按钮。
订阅选项 | 提供匿名请求订阅、允许用快照文件立即初始化新的订阅、允许请求订阅、允许可连接的订阅数据库和允许已发布数据的转换等订阅选项。
快照 | 不管是否启用了并发快照处理（仅用于事务复制），都列出快照格式（本机 Microsoft® SQL Server™ 格式或字符模式格式），以及在订阅服务器上应用快照前后要应用的脚本路径。
快照位置 | 提供在其默认位置或在其它可替换位置生成快照、压缩快照文件和指定订阅服务器使用文件传输协议 (FTP) 访问快照文件夹等选项。
发布访问列表 | 请求订阅和即时更新订阅在访问此发布时必需使用的登录的列表。
同步伙伴（合并发布） | 提供允许订阅服务器与非创建订阅的发布服务器的服务器同步的选项。可选择协作发布服务器和订阅服务器，这些服务器可以作为在发布中订阅服务器的可替代同步伙伴。
可更新（快照或事务发布） | 提供允许立即更新订阅、排队更新订阅选项，报告数据冲突；提供可更新订阅的冲突解决策略，如果允许排队更新订阅（在 SQL Server 2000 数据库中或使用 Microsoft 消息队列），对更改排队。
状态 | 显示快照代理程序状态、代理程序上次运行时间、下次预定运行时间、用于立即运行代理程序的按钮，以及显示代理程序属性、探求快照文件夹。SQLServerAgent 服务和 MSDTC 服务状态和用于启动或刷新这些服务的按钮。

打开发布属性

企业管理器

企业管理器

强制订阅属性

强制订阅属性对话框包括以下选项卡和信息。

选项卡 | 信息
常规 | 订阅服务器名称、订阅服务器数据库、订阅类型、状态、解决冲突时的优先级（用于合并发布）、即时更新订阅或排队更新订阅（用于快照复制或事务复制）。
同步 | 指定合并代理程序（用于合并复制）或分发代理程序（用于快照复制或事务复制）运行的位置。

打开强制订阅属性

企业管理器

企业管理器

请求订阅属性

请求订阅属性对话框包括以下选项卡和信息。

选项卡 | 信息
常规 | 订阅服务器名称、订阅服务器数据库、订阅类型、状态、解决冲突时的优先级（用于合并发布）、即时更新订阅或排队更新订阅（用于快照复制或事务复制）。
同步 | 指定订阅上次同步的时间、分发代理程序属性、使用 Windows 同步管理器同步此订阅的选项、分发代理程序（快照复制或事务复制）或合并代理程序（合并复制）运行的位置，以及如果是可更新订阅，是即时更新还是排队更新。
安全性 | 分发服务器登录和发布服务器登录信息。
快照传送 | 快照位置信息。

打开请求订阅属性

企业管理器

企业管理器

代理程序属性

以下属性对于所有代理程序均可用。代理程序属性对话框包括以下选项卡和信息。SQL Server 代理是主代理程序，因此，SQL Server 代理自动控制代理程序调度和若干个代理程序进程。

选项卡 | 信息
常规 | 代理程序名称、创建时间、上次修改时间、所有者和描述。
步骤 | ID、步骤名称、步骤类型、步骤成功后进行的操作、步骤失败后进行的操作、用于创建、插入、编辑和删除步骤的按钮。SQL Server 代理程序将完成这些步骤，所以无须对其进行更改。
调度 | 调度或警报的名称、调度或警报的启用状态、描述，以及用于创建、编辑或删除调度或警报的按钮。
通知 | 作业完成时执行的操作，包括发送电子邮件、发送页、网络发送、写入 Microsoft Windows NT® 4.0 或 Windows 2000 应用程序事件日志，以及自动删除作业。可选择在作业失败、成功时或只要作业完成时开始这些操作。

打开代理程序属性

企业管理器

企业管理器

请参见

管理和监视复制

配置复制

发布数据和数据库对象

订阅发布


复制图标

SQL Server 企业管理器使用几个图标代表复制对象、操作和结果。

图标 | 描述
 | 发布服务器
 | 发布服务器错误
 | 发布服务器重试同步
 | 快照发布
 | 快照发布错误
 | 快照发布重试
 | 事务发布
 | 事务发布错误
 | 事务发布重试
 | 合并发布
 | 合并发布错误
 | 合并发布重试
 | 订阅
 | 订阅错误
 | 订阅重试同步
 | 订阅合并发布
 | 订阅（代理程序没有运行）
 | 订阅（代理程序正在运行）
 | 数据库发布已启用
 | 复制监视器
 | 复制监视器错误
 | 复制监视器重试
 | 快照代理程序正在运行
 | 快照代理程序没有运行
 | 快照代理程序重试
 | 快照代理程序错误
 | 日志读取器代理正在运行
 | 日志读取器代理没有运行
 | 日志读取器代理重试
 | 日志读取器代理错误
 | 队列读取器代理程序正在运行
 | 队列读取器代理程序没有运行
 | 队列读取器代理程序重试
 | 队列读取器代理程序错误
 | 杂项代理程序正在运行
 | 杂项代理程序错误
 | 杂项代理程序重试
 | 列是个主键
 | 表中没有主键
 | 该表包含一个时间戳列且不能由运行 SQL Server 7.0 的发布服务器发布或发布到运行 SQL Server 7.0 的订阅服务器。


复制程序接口

作为使用 SQL Server 企业管理器的一个替代方案，可使用以下编程接口执行、管理和监视复制：

  • 用在使用 Microsoft Visual Basic® 或 Microsoft Visual C++® 的自定义应用程序中的 Microsoft® ActiveX® 控件，提供控件以管理和控制快照代理程序、分发代理程序和合并代理程序。可用这些控件编制操作复制所需要的活动的程序。例如，对于提供联机和脱机功能的应用程序，可能想要显示"同步"按钮。可将该按钮与合并 ActiveX 控件相关联，用户单击该按钮时将连接到发布服务器，而指定发布的合并代理程序合并和同步数据。

  • SQL-DMO 使您得以用 Visual Basic 或 C++ 创建自定义应用程序，这些程序您得以配置、执行或维护复制拓扑。SQL-DMO 可用来编制复制管理（如，配置分发、创建订阅等）程序。

  • 复制分发服务器接口提供从异类数据源（例如 Microsoft Access 或 Oracle）复制数据的功能。复制分发服务器接口主要由独立服务厂商或那些需要基于专有数据源开发自定义复制应用程序的其它厂商使用。

  • 使用 Transact-SQL 系统存储过程编写复制脚本，使您得以自动化某些复制任务、配置复制以及在多台服务器上执行订阅。存储过程在脚本中频繁使用，当在多个服务器上配置复制时，这些脚本可以运行（例如，在多个订阅服务器上创建发布的订阅时）。


使用 ActiveX 控件进行复制程序设计

Microsoft® ActiveX® 控件允许自定义应用程序唤醒调用复制代理程序功能。这些控件支持所有的订阅类型，并且可以用分发服务器上的 SQL Server企业管理器监视这些控件。

程序员可以使用 ActiveX 控件进行复制，与使用任何标准的内置控件类似。这些控件是 SQL 快照控件、SQL 分发控件和 SQL 合并控件。

下面的列表讲述了使用 ActiveX 控件进行复制的各种优点：

  • 复制可以是应用程序固有的一部分。例如，可以在菜单上放置"现在同步"命令，用它来控制何时运行与所使用的复制类型相关联的指定代理程序。

  • 应用程序可使用进度栏提供复制控件进度的反馈。

  • 应用程序可决定如何获得登录信息（例如，硬代码或交互式）。

  • 可在应用程序中嵌入复制控件，这提供了一种不用安装复杂的订阅服务器，就可以分发移动应用程序的方法。

  • 可对控件进行程序设计，从而在订阅服务器处添加或除去订阅、创建或附加数据库。

  • 可以设计应用程序，以便在 Microsoft 同步管理器上注册订阅同步。

  • 客户不依赖于负责执行除复制以外的其它作业的 SQL Server 代理。

  • 如果使用 SQL Server 代理启动了某个复制，则其它作业同样可以运行。如果正在使用请求订阅或匿名订阅复制到异类订阅服务器，则该订阅服务器上不能使用 SQL Server 代理。

  • ActiveX 复制控件可以从许多编程环境调用，包括 Microsoft Visual Basic®、Visual Basic Scripting Edition、Java 和 Microsoft Visual C++®。

如果在 Microsoft 同步管理器中注册了一条订阅，就不必在应用程序中嵌入控件。如果此中央应用程序能满足您应用程序的需要，则所有同步都可由它进行控制。

有关更多信息，请参见使用 ActiveX 控件开发复制应用程序。


使用 SQL-DMO 进行复制程序设计

SQL 分布式管理对象 (SQL-DMO) 使您得以控制用于执行、管理和监视的复制组件。SQL-DMO 将 Microsoft® SQL Server™ 2000 组件封装为对象。使用 Microsoft Visual C++® 或 Microsoft Visual Basic® 等编程语言，可根据这些对象、属性和与对象关联的方法编写 SQL-DMO 应用程序。

例如，复制组件可以是分发服务器，使用 SQL-DMO 可对 SQL-DMO 分发服务器对象进行程序设计，以便安装本地分发服务器或为发布服务器配置远程分发。然后可使用 DistributionDatabase 对象创建新分发数据库或更改分发数据库的属性。

配置了分发之后，可使用 DistributorAvailable 属性查找分发服务器的状态，或使用 Distribution Database 属性标识分发服务器使用的分发数据库。

有关更多信息，请参见开发 SQL-DMO 应用程序。


使用复制分发服务器接口设计复制程序

复制分发服务器接口是一个 OLE DB 服务提供程序，该接口允许异类数据源用快照复制或事务复制将数据发布给 Microsoft® SQL Server™ 订阅服务器。复制分发服务器接口通常用作第三方工具中的组件，使异类发布服务器得以继承 SQL Server 复制的功能，例如异类订阅服务器、匿名订阅、SQL Server 企业管理器中的监视和疑难解答工具、警报和通知等功能。

可设计 C++ 应用程序，以便使用复制分发服务器接口并存储非 SQL Server 数据库所发布的事务。可设计分发代理程序，从而将那些事务转发给订阅服务器。

请参见

复制和异类数据源

从异类数据源设计复制程序


Transact-SQL 系统存储过程

复制系统存储过程和复制代理程序可执行文件编写成文档，可以作为特殊环境中执行复制的方法，也可在批处理文件和脚本中使用。然而在大多数情况下，最好使用 SQL-DMO 编程接口和复制 Microsoft® ActiveX® 控件进行复制程序设计，而不编写直接调用系统存储过程的程序。

使用基于系统存储过程的脚本的好处之一是可在一台服务器上执行复制、创建发布和订阅，通过 SQL Server 企业管理器自动生成脚本，然后在其它服务器上使用该脚本执行复制组件。执行脚本要比使用 SQL Server 企业管理器手工重复执行相同步骤更迅速、更高效。

有关更多信息，请参见编写复制脚本。


Windows 同步管理器

Windows 同步管理器是一个实用工具，在 Microsoft® Windows® 2000 和安装 Microsoft Internet Explorer 5.0 版的任何计算机中均有提供。使用快照复制、事务复制或合并复制时，它使您得以在 Microsoft SQL Server™ 2000 实例间同步或分发数据。

Windows 同步管理器还是同步包括电子邮件页和脱机 Web 页等其它应用程序的中央位置。可以使用 Windows 同步管理器调度同步或指示 Windows 在您登录或注销计算机时，或取消靠接便携式计算机时，自动同步所选项目。

Windows 同步管理器使您得以：

  • 选择可选同步伙伴。

  • 添加一个新订阅。

  • 只从 Windows 同步管理器删除订阅。

  • 删除订阅。

  • 重新初始化订阅。

  • 重新初始化前面带有更改上载的订阅。

  • 更改可更新订阅的更新模式。

  • 附加订阅数据库。

可使用 SQL Server 企业管理器启用用于 Windows 同步管理器中的请求订阅，或使用复制 Microsoft ActiveX® 控件、SQL-DMO 或 Transact-SQL 系统存储过程在程序设计中启用用于 Windows 同步管理器中的订阅。

有关 Windows 同步管理器的更多信息，请参见 Windows 2000 文档。

示例

例如，Northwind Traders 使用合并复制以便让远程销售部门能够查看和更新其特定地区的客户和订单信息。在创建请求订阅向导中，复制管理员可指定合并代理程序只按需更新订阅。脱机工作时，销售代表可查看其数据，更新客户和订单信息。重新连接到发布服务器时，他们可打开 Windows 同步管理器，单击"同步"按钮，使其更新与在发布服务器和其它订阅服务器处所做的更新同步。

打开 Windows 同步管理器

Windows

Windows NT

请参见

同步数据


Active Directory 服务

使用 Microsoft® Windows®2000 操作系统的 Active Directory™ 服务可访问复制发布。通过 Active Directory，可以查看复制对象（如发布）和该发布的订阅（如果允许）。

典型的例子是当订阅发布时，用户必须知道发布该发布的 Microsoft SQL Server™ 实例和数据库的名称。如果在 Active Directory 中使用发布信息，则使用户得以基于发布属性进行浏览，而且如果允许的话，可使用请求订阅订阅发布。用户不必知道发布所在的服务器名称和数据库。

Active Directory 是 Windows 2000 操作系统的中心组件，可存储有关基于网络的实体的信息，例如应用程序、文件、打印机和人等。

Active Directory 中列出的属性不总是与 SQL Server 中列出的属性完全相同。如果 Active Directory 的发布及特性与 SQL Server 的发布属性存在差异，则 SQL Server 的发布属性为可使用的正确设置。该原则也适用于 Active Directory 中列出的数据库和服务器。

向 Active Directory 中添加或删除服务器对象

将 SQL Server 对象实例添加到 Active Directory 要求登录在服务器上有本地管理员特权。如果用于注册 SQL Server 实例的登录没有足够的权限且服务器为本地服务器，则显示"连接到 SQL Server"对话框，要求登录具有所需的权限。如果登录没有足够的权限且服务器为远程服务器，则显示错误信息。

添加 SQL Server 对象到 Active Directory

  1. 在"SQL Server 属性"对话框的"Active Directory"选项卡中单击"添加"按钮。

  2. 添加了 SQL Server 对象后，单击"刷新"按钮更新 Active Directory 中的 SQL Server 对象实例的特性。（单击"刷新"按钮并不将新对象添加到 Active Directory；而是仅刷新服务器对象的特性）。

删除 Active Directory 中的 SQL Server 对象

  • 在"SQL Server 属性"对话框的"Active Directory"选项卡中单击"删除"按钮。从 Active Directory 中删除 SQL Server 对象也将删除该对象在 Active Directory 中的数据库和发布。

使用 Transact-SQL 从 Active Directory 添加或删除 SQL Server 对象

  • 执行 sp_ActiveDirectory_SCP，并将 @action='CREATE' 设置为添加到 Active Direcotry 或将 @action='DELETE' 设置为从 Active Directory 中删除。
将发布添加为 Active Directory 对象

在为 Active Directory 启用 SQL Server 对象后，可将发布添加为 Active Directory 对象。若要添加发布，则 SQL Server 服务帐户必须至少有权限高的用户特权。

将发布添加到 Active Directory

  1. 右击发布，然后单击"发布属性"命令。

  2. 在"常规"选项卡中，选择"在 Active Directory 中列出此发布"选项。或当使用创建发布向导创建发布时，在"选择发布名称"和"描述"页中选择"在 Active Directory 中列出此发布"选项。如果订阅服务器可以访问发布，可使用 Active Directory 订阅发布。

使用 Transact-SQL 将发布添加到 Active Directory

  • 对于新的发布，执行 sp_addpublication 或 sp_addmergepublication 并设置 @add_to_active_directory='TRUE'。

  • 对于现有发布，执行 sp_changepublication 或 sp_changemergepublication 并设置 @property=publish_to_ActiveDirectory, @value='TRUE'。
浏览或订阅 Active Directory 中的发布

可在 Active Directory 中浏览发布，如果允许，还可用请求订阅向导或 Windows 同步管理器订阅发布。

使用请求订阅向导浏览或订阅 Active Directory 中的发布

  1. 在订阅服务器上，启动请求订阅向导，然后在查找发布页上，选择"查找 Active Directory 中的发布或指定发布信息"。

  2. 在指定发布页上，单击浏览（"..."）按钮以浏览 Active Directory 中的发布。

使用 Windows 同步管理器浏览或订阅 Active Directory 中的发布

  3. 在 Windows 同步管理器中，双击"创建订阅"，然后选择"通过浏览 Active Directory 中的发布"。

  4. 在"创建匿名订阅（浏览 Active Directory）"对话框上，查看 Active Directory 中列出的发布，或单击浏览（"..."）按钮以浏览 Active Directory 中的发布。

有关更多信息，请参见 Windows 2000 服务器文档。


执行复制

无论使用快照复制、事务复制还是合并复制，以下阶段都将帮助您执行复制。

阶段 | 任务
配置复制 | 在拓扑中标识发布服务器、分发服务器和订阅服务器。使用 SQL Server 企业管理器、SQL-DMO 或 Transact-SQL 系统存储过程和脚本配置发布服务器，创建分发数据库和启用订阅服务器。
发布数据和数据库对象 | 在发布中创建发布并定义数据和数据库对象项目，并将必要的筛选器应用到要发布的数据。
订阅到发布 | 创建强制、请求或匿名订阅说明需要传播到个人订阅服务器发布的类型和时间。
生成初始快照 | 说明在何处保存快照文件，这些文件是否已被压缩，以及在应用初始快照之前或之后要运行的脚本。 指定快照代理程序生成快照一次，或按照反复出现的调度生成快照。
应用初始快照 | 使用分发代理程序或合并代理程序通过同步订阅自动应用快照。快照可以从默认快照文件夹进行应用，或从可移动介质进行应用，此介质可以在快照应用之前手动传送到订阅服务器上。
同步数据 | 当快照代理程序、分发代理程序或合并代理程序的运行和更新在发布服务器和订阅服务器之间进行传播时，将会对数据进行同步处理。 对于快照复制，快照将在订阅服务器上重新应用。 对于事务复制，日志读取器代理程序将存储分发数据库中的更新，并且更新将通过分发代理程序传播到订阅服务器。 如果在快照复制或事务复制使用可更新订阅，数据将从订阅服务器传播到发布服务器以及其它订阅服务器。 对于合并复制，在合并过程中进行数据同步（所有服务器的数据更改进行汇聚，如果有冲突，会进行检测和解决）。


配置复制

配置复制是标识企业内的发布服务器、分发服务器和订阅服务器的过程，使用 Microsoft® SQL Server™ 2000 工具配置发布服务器、分发服务器和订阅服务器以用于复制，并且将来在必要时修改或禁用复制。

配置复制的步骤如下：

  1. 标识分发服务器。

  2. 在此分发服务器上创建分发数据库。

  3. 启用将使用此分发服务器的发布服务器。

  4. 启用发布数据库。

  5. 启用将接收发布数据的订阅服务器。

为便于执行，可使用配置分发和发布向导、采用 Transact-SQL 系统存储过程的分发和发布脚本配置或者 SQL-DMO。配置了复制以后，可以使用"发布服务器和分发服务器的属性"对话框、Transact-SQL 系统存储过程或 SQL-DMO 修改设置。


发布服务器、分发服务器和订阅服务器

在配置发布和分发之前，应考虑复制拓扑中服务器的角色和要求。

发布服务器

发布服务器是提供数据以便复制到其它服务器的服务器。除了指定其中哪些数据需要复制之外，发布服务器还检测发生更改的数据并维护有关此站点上所有发布的信息。任何复制的数据元素通常都有一个发布服务器，即使这些数据可能由几个订阅服务器更新或由某个订阅服务器重新发布。

发布数据库是发布服务器上的数据库，它是要复制的数据和数据库对象的源。复制中要用到的每个数据库都必须启用为发布数据库，方法是：通过配置发布和分发向导的"发布服务器和分发服务器的属性"对话框，使用 sp_replicationdboption 系统存储过程或使用创建发布向导在那个数据库上创建发布。

分发服务器

分发服务器是包含分发数据库并存储元数据、历史数据和/或事务的服务器。分发服务器可以是不同于发布服务器的服务器（远程分发服务器），也可以是与发布服务器相同的服务器（本地分发服务器）。分发服务器的角色因所执行的复制类型而异，一般情况下，其作为快照复制和事务复制的角色远远多于合并复制的角色。

复制类型 分发服务器的角色
快照复制或事务复制
  • 为事务复制临时存储复制的事务。

  • 除非使用远程代理程序激活或请求订阅，否则作为大多数复制代理程序的宿主。

  • 存储元数据和历史数据。
合并复制
  • 存储元数据和同步历史。

  • 作为强制订阅的快照代理程序和合并代理程序的宿主。

分发服务器可能需要其它资源：

  • 存储发布的快照文件。默认快照文件夹位于分发服务器上，但您可更改此默认位置或选择备用快照位置。有关更多信息，请参见备用快照位置。

  • 作为一个或多个分发数据库的宿主。

  • 作为大多数复制代理程序处理的宿主（对于在订阅服务器上运行的请求订阅、合并代理程序或分发代理程序）。还可以选择卸载代理程序处理。有关更多信息，请参见远程代理程序激活。
远程分发服务器

远程分发服务器是物理上独立于发布服务器并配置为复制的分发服务器的计算机。本地分发服务器是既配置为复制的发布服务器又配置为复制的分发服务器的计算机。

在创建发布时，默认快照文件夹位于分发服务器上。如果使用此默认位置并使用远程分发服务器，请确保发布服务器上的快照代理程序能访问此快照文件夹。如果不能访问，则快照代理程序无法将快照文件写入分发服务器。

与此类似，如果请求订阅要访问远程分发服务器上的数据，而快照文件夹位于此分发服务器上，请确保运行于订阅服务器上的分发代理程序或合并代理程序拥有此快照文件夹的读取权限。

一般情况下，在以下几种情况中选择使用远程分发服务器：希望将处理卸载到其它计算机上，希望复制对发布服务器的影响最小（例如，如果发布服务器是 OLTP 服务器），希望对多个发布服务器使用一个集中的分发服务器。

分发服务器可配置为 SQL Server 的一个独立实例，因此可以在与发布服务器相同的计算机上运行。这在技术上正确，且是一种远程分发服务器，但建议不要这样做。

订阅服务器

订阅服务器是接收复制数据的服务器。订阅服务器订阅发布而非发布中的个别项目，而且它们只订阅所需要的发布而非发布服务器上可用的所有发布。

如果某些应用程序使用通过 Microsoft® SQL Server™ 6.5 或更高版本生成的事务复制，并且这些应用程序直接订阅项目而非发布，那么它们可继续在 SQL Server 2000 中运行。不过应当着手将这些订阅移植到发布级别，在此级别每个发布都由一个或多个项目组成。

配置发布和分发

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

修改发布服务器和分发服务器的属性

企业管理器

企业管理器

Transact-SQL

Transact-SQL

添加、修改或禁用订阅服务器

企业管理器

企业管理器

SQL-DMO


禁用发布和分发

禁用发布和分发包括禁用分发服务器和发布服务器，删除分发数据库以及删除发布和订阅。

通过在分发服务器上使用禁用发布和分发向导、SQL-DMO 或者带有 Transact-SQL 系统存储过程的脚本，可以：

  • 删除分发服务器上的所有分发数据库。

  • 禁用使用此分发服务器的所有发布服务器并且删除发布服务器上面的所有发布。

  • 删除对这些发布的所有订阅。订阅服务器上的订阅信息不会被删除，您应当手工进行删除。发布和订阅数据库中的数据不会被删除，但它将失去与任何发布数据库的同步关系。如果希望删除订阅服务器上的数据，则需要手动删除。

禁用发布和分发

企业管理器

企业管理器

Transact-SQLTransact-SQL

Transact-SQL

SQL-DMO


发布数据和数据库对象

在创建发布时，可以选择表以及要发布的数据和数据库对象的筛选分区。

快照发布或事务发布中所使用的表最大可有 255 列，行容量最大为 8,000 字节。合并发布中所使用的表最大可有 246 列，行容量最大为 6,000 字节。

可通过水平、垂直、动态和联接筛选创建要发布数据的分区。通过筛选已发布数据，可以：

  • 将网络上发送的数据量减到最少。

  • 减少订阅服务器上需要的存储空间量。

  • 实现更好的安全性，订阅服务器只看到所需要的数据。

  • 根据个别订阅服务器的要求，自定义发布和应用程序。

  • 由于不同的数据分区可以发送到不同的订阅服务器，因此可避免冲突（限制可能更新相同的数据值的订阅服务器的数目）。

  • 限制敏感数据对订阅服务器的可见性。例如，可对 Employees 表进行垂直筛选以排除职员薪水或检查信息，因为这些数据是敏感的且可能是订阅服务器上不必要的数据。

快照复制、事务复制和合并复制可使用水平（行）筛选和垂直（列）筛选。合并复制可使用动态和联接筛选。但是，使用可转换订阅可为快照复制和事务复制创建与动态分区类似的自定义分区。有关创建数据的筛选分区的信息，请参见筛选已发布数据。有关快照复制或事务复制中的动态分区的信息，请参见使用可转换的订阅创建自定义数据分区。

有关特定数据类型的信息，请参见数据要求和特性以及计划各种复制类型。

说明 当以现有发布为模板创建发布时，原发布的发布访问列表 (PAL) 不会复制到第二个发布。必须在创建发布后使用发布属性和"发布访问列表"选项卡手动重新创建所有 PAL 设置。

发布数据库对象

下列数据库对象可以由 Microsoft® SQL Server™ 2000 复制发布。

数据库对象 | 快照复制或事务复制 | 合并复制
表 | X | X
存储过程 – 定义 | X | X
存储过程 – 执行 | X |
视图 | X | X
索引视图 | X | X
作为表的索引视图 | X |
用户定义函数 | X | X

发布这些对象时，其定义会复制到订阅服务器。当向发布数据库添加列或从发布数据库除去列时，这些对象定义的更改将传播到订阅服务器。其它类型对象的定义更改不会自动复制到订阅服务器。

当更改已发布表中的数据时，或运行为执行而发布的存储过程时，所进行的数据更改不会传播到订阅服务器。

如果正在发布引用了其它数据库对象的某个数据库对象，则必须将此对象引用的所有对象一起发布。例如，Northwind 数据库中的 Products Above Average Price（超过平均价格的产品）视图从 PRODUCTS 表检索数据。如果发布此视图，则必须同时发布 PRODUCTS 表。

即使不发布存储过程所引用的数据库对象，包含此存储过程定义的发布也可能被复制。但是当您试图在订阅服务器上执行此存储过程时将会出错。这是由于延迟名称解析造成的，当执行存储过程而不是创建存储过程时，要对对象相关性进行检查。

发布视图、用户定义的函数、存储过程定义和触发器

在数据库中创建视图、用户定义的函数和存储过程定义之后，它们将作为对象显示在"指定项目"对话框上的创建发布向导中。

当复制这些对象时，其定义作为应用于订阅服务器的初始快照的一部分进行复制。对这些对象的定义的后续更改不自动复制到订阅服务器。但是，对这些对象的定义进行复制可提供方便的机制，以向订阅服务器部署应用程序的这些组件。

当为快照复制或事务复制发布非只架构项目的索引视图时，不必将视图以表的形式进行复制。当视图发布到订阅服务器时，订阅服务器上将创建一个表，其中包含视图所基于的数据。在订阅服务器上将视图作为一个表进行索引是复制视图内容的一种方便的方式，它不要求组成视图定义的每个表也加以复制。作为表项目发布的索引视图不能通过列筛选进行垂直分区。

触发器定义为表的一部分，当此表作为某个发布的一部分进行复制时它将作为一个架构选项进行发布。若要为正在发布的表项目发布触发器：

  1. 右击发布，然后单击"属性"命令。

  2. 在"项目"选项卡上，单击特定表项目的属性（"..."）按钮。

  3. 在"表项目属性"对话框中的"快照"选项卡上，选择"将对象复制到目的"下面的"用户触发器"复选框。

说明 如果发布到运行 SQL Sever 早期版本的订阅服务器，则只能使用该版本的功能。例如，无法将视图、用户定义函数、触发器和架构对象发布到运行 SQL Server 7.0 的订阅服务器。

架构对象

除了前面的表中列出的数据库对象之外，还可指定是否要复制架构对象，如声明引用完整性（主键约束、引用约束和唯一约束）、聚集索引、非聚集索引、用户触发器、扩展属性和排序规则。

加密数据库对象

用 ENCRYPTION 或 WITH ENCRYPTION 标记的存储过程、视图、触发器和用户定义的函数不能作为 SQL Server 复制的一部分进行发布。

创建发布和定义项目

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO

SQL-DMO

SQL-DMO

修改发布和项目

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO

SQL-DMO

SQL-DMO

删除发布和项目

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO

SQL-DMO

SQL-DMO


发布存储过程执行

如果某个快照或事务发布中包括一个或多个作为项目的存储过程，SQL Server 2000 将复制这些存储过程的执行而不复制由这些存储过程的执行引起的数据更改。这对于复制面向维护的存储过程的结果很有用处，这种存储过程的结果可能会影响大量的数据。

如果作为一组数据操作语言 (DML) SQL 语句进行复制，这些过程可能需要大量的网络资源、分发数据库空间和服务器处理时间。以一个存储过程语句的形式复制更改可显著提高应用程序的效率，但请慎用该功能。

发布存储过程的执行有两种不同方式：

  • 过程执行项目。将过程执行复制到项目的所有订阅服务器。无论存储过程中的各条语句是否成功都是如此。此外，由于存储过程引起的数据更改可能在多个事务内发生，订阅服务器上的数据不能保证与发布服务器上的数据一致。

  • 可串行过程执行项目。只有当过程在可串行事务上下文内执行时才复制过程执行。如果存储过程从可串行事务外部执行，所发布的表中的数据更改将作为一组 DML 语句复制。此行为有助于使订阅服务器上的数据与发布服务器上的数据一致。这对批处理操作尤其有用，例如大量的清除操作。
过程执行项目

若要复制存储过程执行，在此过程执行完之前，不会从当前连接复制新的数据更改或过程执行。例如，如果执行某个用于修改已发布表中数据的存储过程，并且复制此过程执行，那么已发布表的单个 DML 更改不会被复制。

与此类似，若某个存储过程执行另一个已发布存储过程，如果执行此存储过程，并且复制此执行，那么由第一个过程调用的那个存储过程的 EXEC 语句不会被复制。但是，如果某个已发布存储过程修改了另一个数据库中的数据，而且复制了基础表，那么这些数据更改将复制为 DML 语句。

在默认情况下，发布服务器上的存储过程定义会传播到每个订阅服务器。但是，也可以在订阅服务器上定义不同的存储过程逻辑。这有助于在发布服务器和订阅服务器上执行不同逻辑。例如，考虑发布服务器上的 sp_big_delete 存储过程，它有两个功能：从已复制表 big_table1 中删除 1,000,000 行并更新未复制表 big_table2。若要减少对网络资源的需求，应当通过发布 sp_big_delete 并在订阅服务器上创建订阅而将 1 百万行删除作为一个存储过程进行传播。在订阅服务器上，可以定义 sp_big_delete 只删除 1 百万行且不对 big_table2 进行后续更新。

每当某个已发布存储过程在发布服务器上执行时，其执行和传递给它用于执行的参数会传送到该发布的每个订阅服务器。

例如，如果执行某个存储过程，此过程包含对几个不同表的操作，那么只是此过程的执行（含其参数）会传送到每个订阅服务器。如果不发布存储过程而发布基础表，由此存储过程产生的每项数据修改（插入、更新或删除）会为复制作标记并传送到每个订阅服务器。在已发布存储过程的执行期间，SQL Server 2000 会临时停止为此过程内的事务或用于复制的命令进行标记，以避免重复操作。

存储过程复制既可减少需要传送到订阅服务器的命令数量，又可通过在每个订阅服务器上执行更少的动态 SQL 语句而提高应用程序的性能。

例如，假设您创建了一个存储过程：

CREATE PROC give_raise AS
UPDATE EMPLOYEES SET salary = salary * 1.10

此过程用于为贵公司的 10,000 名职员每人增加 10% 的薪水。在发布服务器上执行此存储过程时，它会更新每位职员的薪水。若没有存储过程复制，此更新将作为一个大型的多步骤事务传送到订阅服务器：

BEGIN TRAN
UPDATE EMPLOYEES SET salary = salary * 1.10 WHERE PK = 'emp 1'
UPDATE EMPLOYEES SET salary = salary * 1.10 WHERE PK = 'emp 2'

以次类推进行 10,000 次更新。

而使用存储过程复制，SQL Server 2000 仅发送此存储过程的执行：

EXEC give_raise

重要 存储过程复制并非对所有应用程序均适用。如果对某个项目进行水平筛选，以致发布服务器上存在不同于订阅服务器的行集，那么在这两个服务器上执行同一个存储过程会产生不同的结果。与此类似，如果某个更新基于另一个未复制表的子查询，而此表在发布服务器和订阅服务器上有不同的值，那么在这两个服务器上执行同一个存储过程也会产生不同的结果。

若要确保在发布服务器和订阅服务器上得到相同的结果，SQL Server 2000 的默认行为是将结果数据更改作为一个事务中的一组单独语句进行传送。

可串行过程执行项目

下例说明建议将过程复制设置为可串行过程项目的原因。

BEGIN TRANSACTION T1
SELECT @var = max(col1) FROM tableA
UPDATE tableA SET col2 = <value>
   WHERE col1 = @var

BEGIN TRANSACTION T2
   WHERE col1 = @var
INSERT tableA VALUES
COMMIT TRANSACTION T2

在前面的例子中，假定事务 T1 中的 SELECT 发生在事务 T2 中的 INSERT 之前。

如果该过程不在可串行事务内执行（例如，隔离级别设置为 SERIALIZABLE），则允许事务 T2 在 T1 的 SELECT 语句范围内插入新行，且在 T1 前提交。这还意味着在订阅服务器上先应用 T2，后应用 T1。在订阅服务器上应用 T1 时，SELECT 返回的值可能与发布服务器上的值不同，且可能导致与 UPDATE 不同的结果。

如果在可串行事务中执行该过程，将不允许将事务 T2 插入到 T2 中的 SELECT 语句所包括的范围内。T2 将被阻塞，直到 T1 提交且确保与订阅服务器上的结果相同。

在可串行事务中执行过程时控制锁的时间将更长，且可能导致并发减少。

若要复制在可串行事务内部执行的存储过程，在要发布的存储过程的项目属性中，单击"其它"选项卡，然后选择"仅在可串行事务内部执行该存储过程时"。

使用 Transact-SQL 系统存储过程时，当在可串行事务内执行要复制的存储过程时，可以通过将 sp_addarticle 的 @type 参数设置为 serializable proc exec 值来表示这一存储过程。


在项目中使用自定义存储过程

当日志读取器代理程序在发布数据库的事务日志中遇到标记为复制的 INSERT、UPDATE 或 DELETE 语句时，它通常根据记录的数据更改重新构造单独的一行 Transact-SQL 语句。然后分发代理程序将此条 Transact-SQL 语句发送给每个订阅服务器，并将此语句应用于每个目的数据库中的目的表。这是当存在一个或多个异类订阅服务器时，Microsoft® SQL Server™ 2000 所使用的默认数据复制机制。

如果所有订阅服务器都是 SQL Server 2000 的实例，则 SQL Server 2000 可以用每个订阅服务器上的自定义存储过程替代事务日志中的 INSERT、UPDATE 和 DELETE 语句。对于每个已发布的表，有三种方法可以处理由日志读取器代理程序检测到的所有语句类型（INSERT、UPDATE 或 DELETE）。可以：

  • 保留默认的复制机制。

  • 指定在每个订阅服务器上不执行任何操作。不复制这种类型的事务。例如，如果选择"用此存储过程替换 DELETE 语句"并输入 NONE，那么 DELETE 语句不会为此项目进行复制。

  • 指定在所有订阅服务器上调用某个自定义过程。当日志读取器代理程序在标记用于复制的事务中遇到指定类型的语句（INSERT、UPDATE 或 DELETE）时，它会基于此语法构造一个存储过程调用，并且将列值传递给所引用的存储过程。这是 SQL Server 2000 订阅服务器的默认行为。
关于自定义存储过程

根据应用程序的要求，可使用以下方法指定存储过程的参数：

  • CALL 语法

  • XCALL 语法

  • MCALL 语法

各方法传播到订阅服务器的数据量不同。例如，MCALL 将只传递进来更新实际影响到的列的值，以及代表更改的列的位掩码，而 XCALL 将传递进来所有列（不论是否受到更新的影响）以及每个列所有旧数据值。这使得应用程序开发人员可以灵活地满足各种要求。当使用 XCALL 时，text 和 image 列的"之前"映像值预期为 NULL。

若要实现已发布表的基于自定义存储过程的复制，存储过程必须通过复制或由用户创建。这些自定义存储过程预期可接收和处理以下参数：

call 语法

INSERT 存储过程

处理 INSERT 语句的存储过程将传送所有列的插入值：

c1, c2, c3,... cn

UPDATE 存储过程

处理 UPDATE 语句的存储过程将传送定义于项目中的所有列的更新值，后面跟着主键列的起始值：

c1, c2, c3,... cn, pkc1, pkc2,... pkcn

说明 此过程不会尝试确定哪些列发生了更改。

DELETE 存储过程

处理 DELETE 语句的存储过程将传送主键列的值：

pkc1, pkc2,... pkcn

mcall 语法

UPDATE 存储过程

处理 UPDATE 语句的存储过程将传送定义于项目中的所有列的更新值，后面依次跟着主键列的起始值及一个用于指明已更改列的位掩码 (binary(n)) 参数：

c1, c2, c3,... cn, pkc1, pkc2,... pkcn, bitmask

xcall 语法

UPDATE 存储过程

将为处理 UPDATE 语句的存储过程传递定义于项目中的所有列的起始（即"之前"映像）值，后面跟着定义于项目中的所有列的更新（即"之后"映像）值。

old-c1, old-c2, old-c3,... old-cn, c1, c2, c3,... cn,

DELETE 存储过程

将为处理 UPDATE 语句的存储过程传递定义于项目中的所有列的起始（即"之前"映像）值。

old-c1, old-c2, old-c3,... old-cn

如果希望 INSERT、UPDATE 或 DELETE 存储过程在遇到失败状态时返回错误，则必须添加 RAISERROR 语句以便分发服务器能捕获返回的失败状态。如果严重度大于 12，则分发服务器会终止对此订阅服务器的分发过程。如果作为项目架构定义文件的一部分分发这个过程定义，那么此过程定义将使用 ODBC 发送。在这种情况下，只可使用单引号 (') 定义 RAISERROR 消息字符串。使用双引号 (") 将产生错误。

还可以编写自定义存储过程以跳过指定错误。有关更多信息，请参见处理代理程序错误。

当在创建发布向导中指定项目属性时，请指定希望使用单引号还是双引号。也可在此项目的"属性"对话框中进行选择。


订阅发布

订阅是对发布到指定订阅服务器的数据或数据库对象的请求。一个订阅服务器可以有向不同发布请求的多个订阅。

订阅定义将复制的发布和复制的时间、地点。订阅可以创建于发布服务器（强制订阅）或订阅服务器（请求订阅）。然后在发布服务器/分发服务器上创建并同步强制订阅，且通常在分发服务器上运行同步代理程序（分发代理程序或合并代理程序）。在订阅服务器上创建并同步请求订阅和匿名订阅，且通常在订阅服务器上运行同步代理程序。

当计划订阅时，要考虑订阅管理发生的位置和希望代理程序处理发生的位置。选择的订阅类型将控制代理程序运行的位置，但是在某些情况下，使用远程代理程序激活，则可以将同步代理程序处理卸载到其它服务器上。

另外，应留意发布数据库和分发数据库属性以防订阅停用和过期。有关更多信息，请参见订阅停用和过期。

订阅 特点 何时使用
强制订阅 使用强制订阅，发布服务器不经订阅服务器请求即将更改传播给订阅服务器。更改可按需、连续或根据调度强制传播给订阅服务器。根据默认，分发代理程序或合并代理程序运行于分发服务器。

因为订阅服务器必须在发布服务器上显式启用以接收强制订阅，所以强制订阅称为署名订阅。
  • 数据通常按需或按照反复出现的调度进行同步处理。

  • 发布要求数据在不轮询的情况下实现近似实时移动。

  • 使用本地分发服务器的发布服务器上的更高的处理器开销不影响性能。

  • 需要从集中位置（分发服务器）更方便地进行管理。

  • 集中的分发服务器将建立调度，按照此调度与远程的、偶尔连接的订阅服务器进行连接。
请求订阅 使用请求订阅，订阅服务器可以请求发布服务器上的更改。请求订阅使用户得以确定同步数据更改的时间。根据默认，分发代理程序或合并代理程序运行于订阅服务器。

因为订阅服务器必须在发布服务器上显式启用以接收强制订阅，所以请求订阅称为署名订阅。
  • 订阅的管理将发生在订阅服务器上。

  • 发布拥有大量的订阅服务器（例如使用 Internet 的订阅服务器），并且当在分发服务器上运行一个或全部站点上的所有代理程序消耗过多资源时。

  • 订户是自治、脱接和/或移动的。订阅服务器将确定何时连接到发布服务器/分发服务器和对更改进行同步处理。

  • 数据通常按需或按照调度进行同步处理，而不是连续进行同步处理。
匿名订阅 匿名订阅是请求订阅的一种。在使用匿名订阅时，有关此订阅和订阅服务器的详细信息不会在发布服务器上进行存储。

而由订阅服务器保留有关订阅以及上次将订阅同步时的数据内容的信息。然后当下一次同步发生时将该信息传递到分发服务器上。

使用匿名订阅时订阅服务器不必在发布服务器上显式命名。
  • 请求订阅的所有规则都适用于匿名订阅。

  • 应用程序拥有大量订户。

  • 不希望有在发布服务器或分发服务器上维护额外信息的开销。

  • 如果订户使用 Internet 访问发布。


强制订阅

强制订阅可以简化和集中订阅管理，因为不必逐个管理每个订阅服务器。当同步强制订阅时，分发代理程序或合并代理程序运行于分发服务器。强制订阅在发布服务器上创建，复制代理程序不经订阅服务器请求即将数据及更新传播给订阅服务器。数据更改也可以按照调度强制发布给订阅服务器。

在以下情况下可使用强制订阅：

  • 数据通常按需或按照反复出现的调度进行同步处理。

  • 发布要求数据在不轮询的情况下实现近似实时移动。

  • 使用本地分发服务器的发布服务器上的更高的处理器开销不影响性能。

  • 需要从集中位置（分发服务器）更方便地进行管理。

集中的分发服务器将建立调度，按照此调度与远程的、偶尔连接的订阅服务器进行连接。使用强制订阅，分发代理程序（对于快照发布和事务发布）或合并代理程序（对于合并发布）可以运行于分发服务器。但是，如果需要从分发服务器卸载代理程序处理但保留便于管理的某些好处，则可以在订阅服务器上运行代理程序。有关更多信息，请参见远程代理程序激活。

因为可以使用远程代理程序激活，建立订阅时要考虑的决定因素是您需要的订阅的类型（强制、请求或匿名）以及运行复制代理程序的位置。

用户如果是订阅服务器上的 sysadmin 或 db_owner 角色的成员，则可以建立强制订阅。但是，对于建立强制订阅的 db_owner 角色的成员而言，订阅服务器必须由 sysadmin 角色的一位成员注册。

为了创建订阅，发布服务器上必须有发布，订阅服务器上也必须有订阅数据库。可以在创建订阅之前创建订阅数据库，或在创建强制订阅向导中指定新的订阅数据库。可以为任何在发布服务器和分发服务器的属性中启用的订阅服务器创建强制订阅。

强制订阅和请求订阅称为署名订阅，因为有关订阅和订户的信息存储在发布服务器上，有关订阅服务器的性能信息存储在分发服务器上。这与匿名订阅（一种请求订阅类型）不同，匿名订阅保存少量或不保存有关订阅和订阅服务器的信息。

在创建强制订阅时，请指定：

  • 订阅服务器的名称。

  • 订阅数据库的名称。

  • 分发代理程序或合并代理程序运行于分发服务器（默认）还是使用远程代理程序激活的订阅服务器。

  • 分发代理程序或合并代理程序是连续运行，根据调度运行，还是只按需运行。

  • 快照代理程序是否应为订阅创建更新的初始快照，以及分发代理程序或合并代理程序是否应将此快照应用于订阅服务器。

  • 对于允许即时更新或排队更新的快照发布或事务发布，该订阅将使用的选项（在强制订阅向导中启用高级选项时可用）。

  • 对于合并复制，订阅数据库中进行的更改的优先级值，以用于冲突检测和解决。

  • 对于快照复制和事务复制，指定订阅将使用即时更新、排队更新或转换已发布的数据选项（这些必须在创建发布时首先启用）。

  • 为创建订阅而将启动的服务。

创建强制订阅

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO

修改强制订阅

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO

删除强制订阅

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO


请求订阅

请求订阅创建于订阅服务器，订阅服务器可以请求发布服务器上的数据和所做的更新。请求订阅使订阅服务器上的用户得以确定何时对数据更改进行同步处理，该处理可以根据需要或根据调度进行。

以下情况下可使用请求订阅：

  • 订阅的管理将发生在订阅服务器上。

  • 发布拥有大量的订阅服务器（例如使用 Internet 的订阅服务器），并且当在分发服务器上运行一个或全部站点上的所有代理程序消耗过多资源时。

  • 订户是自治、脱接和/或移动的。订阅服务器将确定何时连接到发布服务器/分发服务器和对更改进行同步处理。

数据通常按需或按照调度进行同步处理，而不是连续进行同步处理。请求订阅的一个特征是分发代理程序（对于快照发布和事务发布）和合并代理程序（对于合并发布）都在订阅服务器上运行。这可以减少在分发服务器上处理的开销量。但是，如果需要在分发服务器上运行分发代理程序或合并代理程序，可以从订阅服务器上卸载代理程序处理。

例如，如果订阅服务器将决定何时连接到网络并可以开始进行同步，但您希望在分发服务器上运行代理程序以利用分发服务器上的更好的处理能力，则可以使用该选项。有关更多信息，请参见远程代理程序激活。

使用请求订阅的另一个优点是所接收的发布和时间由订阅服务器上的 sysadmin 或 db_owner 角色的成员决定。每个订阅服务器可以订阅不同发布服务器上的多个发布。

为了创建订阅，发布服务器上必须有发布，订阅服务器上也必须有订阅数据库。可以在创建订阅之前创建订阅数据库，也可以在创建请求订阅向导中指定新的订阅数据库。可以创建任何发布的请求订阅，只要此发布在某个已注册的发布服务器上启用了请求订阅。

在创建请求订阅时应指定：

  • 订阅数据库的名称。

  • 快照代理程序是否应创建初始快照，以及分发代理程序或合并代理程序是否应将此快照应用于订阅服务器。

  • 初始化订阅时要应用的快照文件的位置。

  • 用于合并的订阅的优先级。

  • 对于快照复制和事务复制，指定订阅将使用即时更新、排队更新或转换已发布的数据选项（这些必须在创建发布时首先启用）。

  • 分发代理程序或合并代理程序是连续运行，按需运行，还是根据调度运行。

  • 为创建订阅而将启动的服务。

强制订阅和请求订阅称为署名订阅，因为有关订阅和订户的信息存储在发布服务器上，有关订阅服务器的性能信息存储在分发服务器上。这与匿名订阅（一种请求订阅类型）不同，匿名订阅不保存有关订阅和订阅服务器的信息。

在创建对订阅服务器来说已经存在的发布的请求订阅和强制订阅时，会出现错误信息，提示此强制订阅已经存在，应当除去所有强制订阅才能继续。当创建请求订阅时，如果对同一个发布的另一个请求订阅已经存在，则除非第一个订阅已经过期，否则将要求您先除去现有订阅，才能添加新的订阅。

创建请求或匿名订阅

企业管理器

企业管理器

SQL-DMO

SQL-DMO

查看或修改请求订阅或匿名订阅

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO

删除请求订阅

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO


匿名订阅

匿名订阅是请求订阅的一种，有关匿名订阅的订阅和订户的详细信息不予保存。如果匿名订阅发自订阅服务器，则由订阅服务器负责进行同步处理。

以下情况下可使用匿名订阅：

  • 应用程序拥有大量订户。

  • 不希望有在发布服务器或分发服务器上维护额外信息的开销。

  • 如果订户使用 Internet 访问发布。

  • 请求订阅的所有规则都适用于匿名订阅。

决定对快照复制和事务复制使用匿名订阅的定义因素是分发数据库的清除。分发数据库由分发清除代理程序清除，该清除根据默认调度为每 10 分钟运行一次。分发清除代理程序从分发数据库删除已复制的事务。但是，如果正在使用匿名订阅，则在订阅的保持期内保留事务至给定的匿名订阅时间以进行同步处理。

对于合并，影响小数位数的重要因素与订阅服务器是否知道其它订阅服务器有关。在 Sysmergesubscriptions 系统表中为所有全局订阅存储元数据。可以查看有关所有订阅服务器、发布服务器和发布所传送到的所有全局订阅的信息。

如果启用了发布的匿名订阅，那么创建请求订阅的用户可以在创建请求订阅向导中指定匿名订阅，方法是通过使用 Windows 同步管理器或在存储过程中指定。

创建请求或匿名订阅

企业管理器

企业管理器

Windows

Windows NT

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO

查看或修改请求订阅或匿名订阅

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO

删除匿名订阅

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO


应用初始快照

在创建发布和订阅之后，需要创建初始快照并传输给订阅服务器。此快照向订阅服务器传输架构和数据，以及复制所需的约束、扩展属性、索引、触发器和系统表。

快照由不同的文件组成，这取决于复制的类型和发布中的项目。可以使用快照资源管理器查看这些文件。有关更多信息，请参见浏览快照。

复制类型 | 常用快照文件
快照复制或事务复制 | 架构 (.sch)、数据 (.bcp)、约束和索引 (.dri)、约束 (.idx)。
合并复制 | 架构 (.sch)、数据 (.bcp)、约束和索引 (.dri)、触发器 (.trg)、系统表数据 (.sys)、冲突表 (.cft)。

如果通过网络传输大量数据或者网络链接很慢，那么应用初始快照会耗费额外的时间。在这种情况下，也许可考虑将快照保存到可移动媒体中并手工传输给订阅服务器。

另外，SQL Server 2000 已通过以下方法提高了应用初始快照的性能：压缩快照的能力；事务复制的并发快照处理能力；以及使用动态筛选的合并发布的动态快照能力。有关更多信息，请参见提高生成和应用快照的性能。


生成初始快照

可以依如下方法创建快照：

  • 通过在创建发布之后运行快照代理程序而手动创建。

  • 通过在创建发布向导中的"设置快照代理程序调度"页上选择"立即创建第一个快照"，而在创建发布时自动创建。

  • 在通过创建发布向导中的"快照代理程序调度"页指定的调度时间创建快照。

在默认情况下快照保存在分发服务器上的默认快照文件夹中。在运行 Microsoft® Windows NT® 4.0 版或 Windows 2000 的分发服务器上，在默认情况下快照文件夹使用 <drive>$ 共享以及路径 \\<computer>\<drive>$\Program Files\Microsoft SQL Server\Mssql\Repldata。

在运行 Microsoft Windows 98 操作系统的分发服务器上，在默认情况下快照文件夹使用不共享的 <drive> 和路径 \\<computer>\<drive>\Program Files\Microsoft SQL Server\Mssql\Repldata。如果您的应用程序需要具有在运行 Windows 98 操作系统的服务器上创建请求订阅的能力，则必须将快照文件夹的路径改为发布服务器和订阅服务器上运行的复制代理程序可访问的网络路径。通过共享此文件夹可将它从本地路径更改为网络路径。

重要 <drive>$ 共享是一种特殊的仅面向管理的共享，您不能对其授权，只有计算机的管理员才可以访问它。建议将默认的快照位置更改为订阅服务器可以访问的网络位置或共享文件夹。如果打算允许请求订阅或匿名订阅，这同样适用，因为远程订户或 Internet 上的订户很少是管理员。通过在订阅服务器上的 Windows 资源管理器中映射一个网络驱动器可以测试此订阅服务器与快照文件夹的连接。

也可以将快照文件保存在可移动媒体中，如可移动的磁盘、光盘或者分发服务器上默认快照文件夹以外的位置，如文件传输协议 (FTP) 服务器。此外，使用快照资源管理器可以查看和传输快照文件，可以压缩这些文件以便于存储和传输，还可以在快照同步之前或之后执行脚本。

查看或修改默认快照文件夹位置

企业管理器

企业管理器

SQL-DMO

SQL-DMO


备用快照位置

备用快照位置可使用户将快照文件存储在默认位置以外的位置，默认位置常常位于分发服务器上。可选位置可以在另一台服务器上、网络驱动器上或可移动媒体（例如光盘或可移动的磁盘）上。

将快照文件保存在可选位置可以减轻分发服务器的磁盘开销，提供管理优势，并且使您得以使用可移动媒体传输文件。

备用快照位置作为发布的一项属性保存。可以在"快照位置"选项卡上的发布属性中查看此信息。因为备用快照位置是一个发布属性，所以分发代理程序和合并代理程序能将查找适当的快照位置作为同步处理的一部分。但是，如果在创建快照之后更改了可选位置，分发代理程序和合并代理程序可能无法找到可选位置，可能需要重新初始快照。

运行 Microsoft® SQL Server™ 早期版本的订阅服务器不能使用备用快照位置。因此对于这些订阅服务器请继续使用默认的快照位置来存储快照文件。

如果要指定可选快照文件夹位置或压缩快照文件，请在不立即创建初始快照的情况下创建发布，设置快照位置的发布属性，然后为该发布运行快照代理程序。

说明 在发布属性中不要指定与默认快照文件夹位置相同的备用位置。您将收到错误信息且应该指定不同的备用位置或使用默认的位置。

通过将快照文件保存在运行 Microsoft Cluster Server 的服务器的共享位置，可以在使用故障转移群集时提高复制的可用性。有关更多信息，请参见故障转移群集。

指定备用快照位置

企业管理器

企业管理器

SQL-DMO


压缩快照文件

当快照文件太大以致于可移动媒体无法装下，或者需要通过较慢的网络进行传输时，可以选择对快照文件进行压缩。对快照文件进行压缩可以减少网络流量，但这样增加了生成及应用快照的时间。

压缩以 Microsoft® CAB 文件格式写入数据。将快照文件保存到可选位置或订阅服务器使用 FTP 访问快照文件时，可对其进行压缩。在分发服务器上，不能压缩已写入默认快照文件夹的快照文件。

磁盘空间要求

单个快照文件需要的空间大小受几个因素影响，其中包括已发布项目的大小及数目。快照文件可以在分发服务器上的默认快照文件夹或可选位置中创建。压缩可选位置中的快照文件可以减少所需的总空间。

如果在同一驱动器上，既在默认目录又在可选位置中创建快照文件，那么每个文件首先在默认目录下创建，然后复制到可选位置。如果使用压缩快照文件，则在将这些文件放入备用快照位置之前已经进行复制和压缩。在这种情况下，所有快照文件需要的总空间是默认位置中原始快照文件的大小与备用位置中压缩快照文件的大小之和。

如果备用存储位置与默认位置不在同一驱动器上，那么默认位置需要的空间就是快照文件的大小。可选位置需要的空间是压缩快照文件的总大小。

当只使用备用快照位置时，快照代理程序将文件直接写入该位置。在快照代理程序生成文件之后，这些文件被 CAB 实用工具压缩成扩展名为 .cab 的压缩快照文件的一部分。在成功地对每个文件进行压缩并将其包括在压缩快照 (.cab) 文件中之后，原始的未压缩文件会被删除。可选位置所需空间是默认快照位置中最后一个文件（通常是 .bcp 文件）的大小与压缩快照 (.cab) 文件的大小之和。

当订阅服务器接收压缩快照文件时，此文件首先写入一个临时位置。此位置可以是默认客户端工作目录，也可以是在订阅属性中指定的可选位置。在将压缩快照文件复制到订阅服务器之后，CAB 实用工具将按次序逐个解压缩。

解压缩后的文件由合并代理程序或分发代理程序读取，然后执行或应用到订阅服务器。在成功应用每个文件之后，这些文件会被删除，同时解压缩快照目录中的下一个文件。订阅服务器上需要的空间是压缩快照文件的大小与最大的已解压缩文件的大小之和。

压缩和传送快照文件

企业管理器


浏览快照

浏览快照使您得以使用 Windows 资源管理器审阅或自定义当前快照文件，或者将其复制到其它位置。在快照代理程序创建包含已发布表的数据和架构的快照文件之后，这些文件被存储在分发服务器上的快照文件夹或可选位置中。然后可以使用 Windows 资源管理器查看和传输这些快照文件。

说明 您可能看不到已经接收同步对象的署名订阅服务器的某个快照。在这种情况下，分发清除代理程序可能已将此目录中的所有内容删除。在查看带有署名订阅的订阅服务器的快照时，如果快照处理过程尚未完成，或者快照代理程序尚未生成此订阅服务器的新快照文件，则您可能看不到当前快照。

浏览和复制快照文件

企业管理器

企业管理器

Transact-SQL


传输快照

在新的订阅服务器可接收发布服务器的增量更改之前，它必须包含带有与发布服务器上的表相同的架构和数据的表。在发布服务器上创建快照并存储后，必须使用 Microsoft® SQL Server™ 2000 复制代理程序或手工将快照传输到订阅服务器。

SQL Server 应用初始快照

当 SQL Server 2000 将快照应用到订阅服务器时，分发代理程序（对于快照复制和事务复制）或合并代理程序（对于合并复制）会将架构和数据文件应用到订阅服务器上的订阅数据库。

除非将事务复制与并发快照处理一起使用，否则生成快照时将控制共享锁，以生成完整、有逻辑的和一致的数据集。这意味着这些数据在生成快照期间可以被查询但不可更新。若要使对操作所带来的不便最小化，请将生成快照的工作安排在更新最少的时候。如果使用事务复制，并发快照处理允许您在生成快照期间继续修改数据。有关更多信息，请参见提高生成和应用快照的性能。

对于合并复制，该过程与事务复制的并发快照处理类似，因为锁只在合并内容表复制的持续时间内存在。当快照进行大容量复制不对表进行锁定，并且在整个快照的持续时间内不禁止发布数据库上的更新。

在向订阅服务器分发并应用快照时，只有那些正在等待初始快照或新建快照的订阅服务器受到影响。而该发布的其它订阅服务器（即那些已经收到对已发布数据所进行的插入、更新、删除或其它修改内容的订阅服务器）不受任何影响。

可以在创建强制订阅向导或创建请求订阅向导中的"初始化订阅"页上指定 SQL Server 2000 应当初始化架构和数据。

当发生第一次同步处理时（在订阅向导中所指定立即发生的同步处理），分发代理程序或合并代理程序会应用初始快照，然后继续传播更新和其它数据修改。

手工应用快照

如果发布很大，则从光盘或其它存储设备装载快照的效率可能更高。

例如，对于一个 20 GB 的数据库，与通过慢速网络发送文件相比，更为轻松快捷的方法是将此数据库转储到可移动媒体中，再迅速将此它送到订阅服务器所在位置，然后重新装载此数据库。如果选择使用此方法装载快照，SQL Server 2000 不会将已发布的项目与目的表进行同步处理。

对于这个在合并复制中有效运作的例子，您必须已经预先创建并填充了 ROWGUIDCOL 列，或已经在发布服务器上运行了快照代理程序。还需要应用快照，以便订阅服务器上存在合并复制所需的系统跟踪数据和对象。

当需要应用较大的快照时，建议使用可连接的订阅数据库，而不使用标准和动态快照与带压缩的备用快照位置的组合。有关更多信息，请参见可连接的订阅数据库。

利用 SQL Server 2000，可以将快照存储在默认位置以外或除它之外的位置，而且可以浏览快照文件夹，以便于查看、复制和移动快照文件。

若要手工应用快照，请：

  • 将快照文件保存到可移动媒体上，如光盘、磁带设备或可移动磁盘，然后将此媒体发送到订阅服务器所在位置

  • 以数据库转储中的内容为基础应用初始快照。

可以在创建强制订阅向导或创建请求订阅向导中的"初始化订阅"页上指定订阅服务器已经拥有架构和数据。

接下来分发代理程序或合并代理程序会假设发布服务器和订阅服务器已经进行同步处理，并立即开始发送对已发布数据的插入、更新、删除或其它修改。

如果当前快照并非已经在等待中，则在将快照应用于新的订阅服务器之前，SQL Server 在快照代理程序根据其调度进行下一次运行之前将一直等待（根据默认，此运行为一天一次，在 1 A.M. 进行）。

如果创建一个发布并为匿名订阅启用，或者指定快照应保留在快照位置上（二者均为创建发布向导中的选项），则快照将在调度的时间运行，并且将保留在快照位置上。如果未选择以上选项之一，则不会保留该快照。因此，当某个新的订阅服务器试图进行第一次同步处理时，将必须等待，直到下次生成快照使该快照得以应用为止。


可连接的订阅数据库

可连接的订阅数据库功能使您可以在订阅服务器之间传输带有已发布数据和订阅的数据库。在数据库连接到新的订阅服务器后，新订阅服务器上的数据库将自动地接收其自身对那些发布服务器上的发布所作的请求订阅。

可连接的订阅数据库需要以下步骤：

  1. 配置一个发布为允许复制。

  2. 复制订阅数据库。

  3. 将订阅数据库传输并连接到新的订阅服务器。

复制并连接到其它订阅服务器的订阅数据库可以使用快照复制、事务复制或合并复制来包含多个发布的多个请求订阅。可连接的订阅数据库与异类数据库或 Microsoft® SQL Server™ 6.5 版的实例不兼容。强制订阅中无该功能。


配置发布允许复制

若要使用可连接的订阅数据库，首先必须为每个发布配置订阅选项，这些发布将数据传播到将要复制的订阅数据库。这些选项允许在把订阅数据库连接到不同的订阅服务器以后创建新的订阅。

重要 创建对发布的订阅以后，不能更改订阅选项。如果想要使用可连接的订阅数据库，请在创建订阅以前为发布配置订阅选项。

配置发布允许复制订阅数据库

企业管理器


复制订阅数据库

在配置了发布中的订阅选项、创建了对订阅数据库的请求订阅并进行了同步处理以后，可以复制订阅数据库。

订阅数据库的复制包括组成该数据库的数据、视图、存储过程、用户定义的函数、架构以及未复制的所有对象。只可以复制包含在一个主文件组中的订阅数据库。复制前必须同步处理对订阅数据库的至少一个订阅。

在复制进程中，创建一个压缩的 Microsoft 订阅文件 (.msf)。这个 .msf 文件包含直到订阅数据库的上一个订阅的订阅信息。

当创建 .msf 文件时，请将该文件保存到某个位置。以便以后可以找到该文件，将它通过网络传输，使用可移动媒体传输或附加到电子邮件消息中。

复制订阅数据库

企业管理器


连接订阅数据库

在复制订阅数据库并将它保存为 .msf 文件以后，可以将它传输并连接到任何订阅服务器。当把它连接到新的订阅服务器时，该文件将解压缩，然后连接。若要将订阅数据库连接到新的订阅服务器，必须具有数据库所有者权限。

合并复制 .msf 文件仅在为那些发布设置的保持期内有效，事务复制 .msf 文件仅在分发数据库的最大保持期内有效。如果订阅过期，则必须生成新的快照文件，并且重新初始化订阅。

如果订阅数据库有对允许排队更新（带有自动标识范围项目）的发布的订阅，那么在连接订阅数据库以后将需要运行分发代理程序以获得订阅服务器上新的标识范围。如果订阅数据库有对合并发布的订阅，则在连接订阅数据库以后将需要运行订阅服务器上的合并代理程序以防止冲突。

说明 不推荐将使用 SQL Server 7.0 创建的数据库与对事务复制的订阅分离，也不推荐将此数据库附加到运行 SQL Server 2000 的服务器上。如果必须这样做，请运行 master 数据库中的系统存储过程 sp_vupgrade_subscription_databases，以便在附加数据库后升级复制架构。

连接订阅数据库的过程根据使用的是匿名订阅还是署名订阅而有所不同。


将数据库与署名订阅连接

对于非匿名的订阅，必须启用订阅服务器以使其可以接收来自发布服务器的数据，连接订阅数据库，并使用 SQL-DMO 或存储过程在发布服务器上添加该订阅。可以在连接数据库之前或之后在发布服务器上添加订阅。

启用订阅服务器以接收已发布的数据

企业管理器

企业管理器

将订阅数据库与署名订阅连接

企业管理器

企业管理器

请参见

AttachSubscriptionDatabase 方法


将数据库与匿名订阅连接

将订阅数据库连接到新的订阅服务器以后，将自动生成对起始发布的订阅。这使得同步进程对于匿名订阅可以立即开始。如果使用匿名订阅，则不需要启用订阅服务器。

将订阅数据库与匿名订阅连接

企业管理器


提高生成和应用快照的性能

将初始快照应用到订阅服务器可能既耗时又耗费资源，这取决于发布的数据量、网络连接和资源。对事务复制的并发快照处理、动态快照（合并复制）和 –UseInprocLoader 属性已经添加到 Microsoft® SQL Server™ 2000 中，以提高在生成初始快照及在订阅服务器上应用它时的性能。

事务复制的并发快照处理

通常，对于快照生成，在生成快照的持续时间内，SQL Server 将在作为复制的一部分发布的所有表上放置共享锁。这可以防止在发布表上进行更新。只有使用事务复制才可用的并发快照处理，在整个快照生成过程中，将不包含共享锁，因而，在 SQL Server 2000 创建初始快照文件时，允许用户不间断地连续工作。

当使用事务复制新建发布并指出所有订阅服务器都是 SQL Server 7.0 或 SQL Server 2000 的实例时，并发快照处理会自动启用。

有关更多信息，请参见事务复制工作机制。

合并复制的快照处理

对于合并复制，该过程与事务复制的并发快照处理类似，因为锁只在合并内容表复制的持续时间内存在。当快照进行大容量复制不对表进行锁定，并且在整个快照的持续时间内不禁止发布数据库上的更新。

动态快照

动态快照为应用动态筛选过的合并复制快照带来了性能上的好处。通过使用 SQL Server 2000 大容量复制编程文件将数据应用到特定的订阅服务器，而不是使用 INSERT 语句，将改善对动态筛选合并发布应用初始快照的性能。

有关更多信息，请参见动态快照。

向合并复制添加 ROWGUIDCOL

通过预先计划并创建一个可用于帮助跟踪合并复制期间的更改的列，可以避免间或的重要时刻（以及磁盘和日志）的性能降低，这些性能降低可能在等待快照代理程序为您改变表时发生。

合并复制要求每个已发布表具有 ROWGUIDCOL 列。如果在快照代理程序创建初始快照文件之前表中不存在 ROWGUIDCOL 列，那么此代理程序必须首先添加和填充此列。若要获取合并复制期间生成和应用快照时的性能优势，请在合并复制期间发布的每个表中创建 ROWGUID 列。当创建此列时，请指定：

  • 列标题为 ROWGUID。

  • 数据类型为 UNIQUEIDENTIFIER。

  • 默认为 NEWID()。

  • ROWGUIDCOL 属性。

  • 列上的索引。

ROWGUID 列频繁使用，在跟踪和同步发布服务器和订阅服务器上进行的更改期间，关联合并跟踪数据。

-UseInProcLoader

–UseInprocLoader 代理程序属性可提高快照复制、事务复制和合并复制的初始快照性能。

在向分发代理程序（对于快照复制或事务复制）或合并代理程序（对于合并复制）应用此属性之后，代理程序将在向订阅服务器应用快照文件时使用进程内 BULK INSERT 命令。

–UseInprocLoader 属性不能用于字符模式 bcp，并且 OLE DB 或 ODBC 订阅服务器不能使用该属性。

重要 当使用 –UseInprocLoader 属性时，订阅服务器所运行的 SQL Server 2000 帐户必须对快照 .bcp 数据文件所在目录拥有读权限。在不使用 –UseInprocLoader 属性时，代理程序（对于异类订阅服务器）或代理程序所装载的 ODBC 驱动程序（对于 SQL Server 2000 订阅服务器）从文件中读取，因此不使用订阅服务器 SQL Server 2000 帐户的安全上下文。

设置 –UseInprocLoader 属性

企业管理器


在应用快照之前和之后执行脚本

可对脚本进行指定以在快照同步之前或之后在订阅服务器上执行必需的过程。在同步处理之前或之后执行脚本的目的可以是：在每个订阅服务器上创建登录，在订阅服务器上创建用户定义的数据类型，以便能够复制具有这些数据类型的数据，或者在快照同步之后对统计进行更新。

在指定文件位置和脚本名称项之后，每次发生快照处理时，快照代理程序都会将脚本文件复制到当前快照文件夹中。在应用初始同步处理时，分发代理程序或合并代理程序将在任何已复制的对象脚本之前运行快照前脚本。分发代理程序或合并代理程序将在所有其它复制的对象脚本和数据已在初始同步过程中应用之后才运行快照后脚本。通过启动 osql 实用工具运行脚本。请通过使用 osql 运行脚本来测试您的脚本，以确保它如预期的那样执行。建议您确保在应用快照之前和之后所执行的脚本的内容是可重复的，并可执行不止一次。如果需要重新初始化已对其应用了脚本的订阅，则当重新初始化期间应用新的快照时，该脚本将再次应用。

如果正在压缩快照文件（以 CAB 文件格式将其放入），则也将脚本压缩并放入此 CAB 文件。在压缩的快照文件传输到订阅服务器并解压缩到订阅服务器上的工作目录中之后，将执行指示为快照前脚本的任何脚本。同样的，任何快照后脚本将在应用快照时的最后一个步骤中在订阅服务器上进行解压缩并执行。在完成初始同步处理并成功执行脚本文件之后，这些脚本文件将从订阅服务器上的工作目录中删除。

重要 如果使用强制订阅且分发服务器运行的是 SQL Server 2000，在将快照应用到运行 SQL Server 7.0 的订阅服务器时可以执行脚本。当将快照应用到运行 SQL Server 7.0 的订阅服务器时，如果使用请求订阅或匿名订阅，则无法执行脚本。可以使用强制订阅在订阅服务器上创建并运行代理程序。SQL Server 7.0 中的代理程序不能在应用快照的过程中运行脚本。然而，如果使用强制订阅，则默认情况下将在分发服务器上运行代理程序。如果分发服务器运行 SQL Server 2000，则在那里运行的代理程序可在应用快照之前和之后执行脚本。

在应用快照之前和之后执行脚本

企业管理器

企业管理器

SQL-DMO

SQL-DMO


重新初始化订阅

在为重新初始化标记订阅时，快照架构和数据会在下次快照代理程序准备快照，并且分发代理程序（对于快照复制或事务复制）应用快照或合并代理程序（对于合并复制）运行之后应用于订阅服务器上。

例如，除非将订阅标记为重新初始化，否则合并复制订阅服务器将根据所提供的原始快照对数据进行更新。在将订阅标记为重新初始化之后，合并代理程序在下次运行时会将最新的快照应用于订阅服务器。

根据默认，在将新的快照标记为重新初始化之后，在下一个同步处理的第一个步骤中在订阅服务器上应用它。这表示订阅服务器上所进行的但尚未与发布服务器同步的任何更改，将由新快照的应用重写。合并复制提供一个选项，可以为正在重新初始化的订阅保留在订阅服务器上进行的更改。

如果有一个向合并发布订阅的订阅，则可以选择在重新应用快照之前从订阅服务器上载所有数据更改。自上次同步处理以来在此订阅服务器上所进行的任何更新，都将在重新应用此快照前传播到发布服务器。

如果创建订阅并指明不将任何初始快照应用于订阅服务器（在创建强制订阅向导或创建请求订阅向导中指定订阅服务器已经具有架构和数据），那么在重新初始化此订阅时最新的快照将被应用于订阅服务器。

此功能可确保订阅服务器具有与发布服务器相同的架构和数据。若要防止将快照重新应用于订阅服务器，请除去指定不进行初始快照同步处理的那个订阅，然后在任何其它订阅服务器重新初始化之后重新创建它。

强制订阅的重新初始化在发布服务器上进行管理，而请求订阅的重新初始化在订阅服务器上进行管理。

说明 在此阶段中，很容易搞混重新初始化和同步。重新初始化标记订阅。下一次同步订阅时（分发代理程序或合并代理程序运行时），将在订阅服务器上重新应用快照。

重新初始化订阅

企业管理器

企业管理器

SQL-DMO


同步数据

同步处理数据是指在初始快照已经应用于订阅服务器之后，数据在发布服务器和订阅服务器之间传播的过程。当对某个订阅进行同步处理时，发生的过程会有所不同，这取决于使用的复制类型以及此订阅是否标记为重新初始化。

对于快照发布，同步处理数据意味着在订阅服务器上重新应用快照，以便订阅数据库上的架构和数据与发布数据库保持一致。对于事务复制，同步处理数据意味着数据更新、插入、删除和其它修改在发布服务器和订阅服务器之间分发。对于合并发布，同步处理数据意味着合并在多个站点进行的更新，检测、解决冲突（如果有的话）并将数据最终汇聚为相同的值。

分发代理程序和合并代理程序移动发生在发布服务器或订阅服务器上的数据更改。为取得一致，Microsoft® SQL Server™ 2000 复制使用术语同步处理来表示这些复制代理程序之一运行时所进行的处理。

快照复制同步处理

当对某个快照发布的订阅进行同步处理时，分发代理程序（使用 distrib.exe 或分发 ActiveX® 控件）会运行而且最新的快照将应用于订阅服务器上。如果已经对数据进行修改，那么在订阅服务器能够应用新数据之前必须生成新的快照。

事务复制同步处理

当对事务发布的订阅进行同步处理时，分发代理程序（使用 distrib.exe 或分发 ActiveX 控件）会运行而且已经在分发服务器上登录的 UPDATE、INSERT 和 DELETE 语句会传播到订阅服务器。

如果此订阅已标记为重新初始化，那么快照代理程序和分发代理程序必须运行，以生成新的快照并传播到订阅服务器。

合并复制同步处理

当合并复制拓扑中的发布服务器和订阅服务器使用合并代理程序（replmerg.exe 或合并 ActiveX 控件）重新连接，并且更新在站点之间进行传播（如果有必要的话，还要检测和解决冲突）时，即发生同步处理。在同步处理过程中，合并代理程序将所有更改过的数据发送到其它站点。数据从更改发生处流向需要更新或同步处理的站点。

在目的数据库中，从其它站点传播来的更新与现有的值进行合并，合并按照可扩展且灵活的冲突检测和解决方法进行。合并代理程序评估送来的值和当前的值，而新旧值之间的任何冲突由默认的解决程序自动解决。可在创建发布或自定义解决程序时指定此解决程序。

只有在同步处理发生时，更改过的数据值才被复制到其它站点并与那些站点上的更改汇聚在一起。两次同步处理的时间间隔可以是几分钟、几天甚至几周。数据进行集中，并且最终所有站点的数据值相同。但是，如果检测并解决了冲突，便意味着根据您定义的策略改变或撤消了某些用户提交的工作以解决冲突。

同步处理架构更改

Microsoft® SQL Server™ 2000 支持对现有发布数据库进行有限的架构更改。可以向某个已发布的表中添加列和从中除去列，而无须除去和重新创建引用此表的发布和订阅。

快照复制、事务复制和合并复制支持对架构更改的复制。列的添加和删除在表级别执行并传播到从该表接收数据的所有订阅服务器。

有关更多信息，请参见发布数据库上的架构更改。

按需脚本执行

按需脚本执行使您得以发布一个 SQL 脚本，然后在分发或合并过程中，该脚本可以在特定发布的所有订阅服务器上执行。

按需脚本执行可用于快照复制、事务复制和合并复制。

若要指定为合并发布的所有订阅服务器运行某个脚本，请执行 sp_addreplmerge_script。下次合并代理程序运行时，该脚本将在各订阅服务器上执行。

若要指定为快照发布或事务发布的所有订阅服务器运行某个脚本，请执行 sp_addscriptexec。下次分发代理程序运行时，该脚本将在各订阅服务器上执行。

当执行 sp_addscriptexec 或 sp_addreplmerge_script 时，需要指定以下参数。

参数 | 数据类型 | 描述
@publication | sysname | 指定一个有效的发布。必需的。无默认。
@scriptfile | nvarchar(8000) | 指定 SQL 脚本位于的 UNC 路径。必需的。无默认。

按需脚本执行将脚本复制到复制工作目录，然后使用 osql.exe 将该脚本应用于订阅服务器。如果为快照发布或事务发布应用脚本时失败，则分发代理程序将停止。sp_addscriptexec 系统存储过程有另一个参数 @SkipError，以指定分发代理程序遇到错误时是应当停止 (@SkipError = 0)，还是应当将错误记入日志并且分发代理程序应当继续 (@SkipError = 1)。

同步处理强制订阅或请求订阅

企业管理器

企业管理器

同步匿名订阅

Windows

Windows

查看和解决合并同步处理冲突

企业管理器


编写复制脚本

可以编写脚本执行常用的复制功能，如配置发布和分发以及创建或删除发布和订阅。在配置或创建复制组件之后，可以使用 SQL Server 企业管理器自动创建脚本。

脚本包含实施复制组件所必需的 Transact-SQL 系统存储过程。它主要由一组存储过程组成，可以使用 SQL Server 查询分析器或 osql 查看、执行和/或修改及运行脚本。

可以选择为创建或删除下列项目之一或其组合编写脚本：

  • 分发服务器属性

  • 发布和强制订阅

  • 请求订阅

如果需要删除多个强制订阅或强制订阅与请求订阅的组合，则可以通过创建一个用于删除发布的脚本自动完成此过程。此发布的所有订阅将随此发布一起删除。若要删除请求订阅，则可以生成一个脚本，该脚本用于在不删除发布的情况下删除一个或多个请求订阅。

示例

Northwind Traders 决定执行合并复制以将数据分发给其远程销售人员。通过使用请求订阅，销售代表可在需要时下载与其所负责区域内的客户有关的所有数据。当脱机工作时，他们可以更新数据并输入新的客户和订单。在重新连接到发布服务器并进行同步处理时，这些更新将传播到发布服务器和其它订阅服务器，同时检测并解决冲突（如果有的话）。

由于 Northwind Traders 在不同地区拥有的销售代表超过 50 个，因此在每个订阅服务器上创建所需的不同订阅需要耗费大量时间。因此，复制管理员可以设置必要的合并复制（根据销售代表或其地区进行静态或动态分区），然后创建请求订阅，根据此请求订阅生成脚本，再在多个订阅服务器上运行此脚本生成所需请求订阅。

编写脚本进行复制

企业管理器

企业管理器

SQL-DMO


发布数据库上的架构更改

Microsoft® SQL Server™ 2000 支持对现有发布数据库进行一般的架构更改。可以向某个已发布的表中添加列和从中除去列，而无需除去和重新创建引用此表的发布和订阅。

架构更改可以在快照复制、事务复制和合并复制期间进行复制。列的添加和删除在表级别执行并传播到从该表接收数据的所有订阅服务器。对于快照复制，当在订阅服务器上重新应用新建快照时，将传播架构更改。对于事务复制和合并复制，当分发代理程序或合并代理程序运行时，将增量传播架构更改。

重要 对已发布表的架构更改必须通过 SQL Server 企业管理器中的复制发布属性对话框或复制存储过程进行。不要在诸如 SQL Server 查询分析器的工具中使用 SQL ALTER TABLE 语句或使用 SQL Server 企业管理器可视化数据库工具进行已发布表的架构更改。使用这些工具对已发布表进行的更改不能传播到订阅服务器。

建议在更改架构或使用 sp_mergecleanupmetadata 后备份发布数据库。这将确保在发布服务器发生故障时将发布数据库恢复到正确的状态。

添加列

可以将列添加到：

  • 一个或多个发布中的项目。

    此时，添加一列并立即将架构更改应用于一个或多个现有发布，此更改将传播到这些发布的订阅服务器。

  • 基础表，而不将其包括在已发布的项目中。

    您也许要更改基础表而非已发布项目的架构。例如，如果要添加包括敏感数据或专有数据的列，那么这个选择可允许进行架构更改而不会将信息传播到订阅服务器。它也可使您推迟将新列加入到已发布项目中的时间。

  • 已发布的项目，使用基础表中现有的列。

每当将一个列添加到事务发布中时，适当的 ALTER TABLE 语句（或者 sp_repladdcolumn 或 sp_repldropcolumn，如果在订阅服务器上重新发布表的话）将传播到订阅服务器并在其上运行，以在订阅数据库上完成架构更改。

订阅的重新初始化只有在将现有列添加到已发布项目时才有必要进行。在创建新列并立即将其添加到已发布项目时，不需要进行重新初始化。这是因为在下次同步处理时，合并代理程序会在每个受影响的订阅服务器上重新执行 sp_repladdcolumn 存储过程（或在除去某列时执行 sp_repldropcolumn），其中包括所有原始语法。如果目的表未在订阅服务器上重新发布，则分发代理程序重新执行 ALTER TABLE 语句，否则在下次同步处理时在每个受影响的订阅服务器上重新执行 sp_repladdcolumn 或 sp_repldropcolumn，其中包括所有原始语法。

当向正在发布的表添加一个列，但不包括发布中的列时，不需要进一步的操作。但是，如果以后将列添加到发布，则发布的订阅将需要为所有类型的发布进行重新初始化。若要避免重新初始化订阅，请立即将此列添加到已发布项目，而不要等到以后将其添加到现有项目。

补充考虑事项

在通过复制用户界面或复制存储过程定义新列时，必须执行下列操作之一：

  • 允许新列使用 NULL 值。

  • 指定列的默认值。
将项目添加到合并发布中

当将项目添加到合并发布中时，对于将要传播到订阅服务器的新项目架构和数据，不要求重新初始化现有订阅。当将项目添加到有活动订阅的合并发布中时，必须在添加项目后及同步任何订阅服务器之前运行快照代理程序。如果发布已有订阅，则订阅服务器将在下一次同步时将接收到基于该快照的新项目的架构和数据。然后合并代理程序将同步订阅的所有数据更改。

当将项目添加到有活动订阅的发布中时，可以用子集筛选子句筛选项目而不需要重新初始化订阅。然而，如果没有重新初始化所有对发布的订阅，则无法将任何联接筛选字句添加到有活动订阅的发布中。

当使用 SQL Server 企业管理器中的"发布属性"添加项目时，将收到一条信息，指出生成发布的新快照之前订阅无法同步。当应用更改时，建议立即运行快照代理程序。

如果使用存储过程添加项目，必须通过设置 sp_addmergearticle 中的 @force_invalidate_snapshot=1，授权将项目添加到发布中。然后应该立即运行发布的快照代理程序。

不论使用 SQL Server 企业管理器中的"发布属性"还是存储过程，都可以推迟运行快照代理程序，但是在对已更改发布的任何现有订阅可以同步并接收新架构和新数据之前，必须运行快照代理程序。

除去列

在从已发布项目中除去列时，请考虑任何可能影响数据库的列的约束或属性。

  • 不能除去带有主键或唯一约束的列，并且不能除去复制代理程序所使用的 UNIQUEIDENTIFIER（或 ROWGUIDCOL）列。

  • 要除去的列不能用于数据库中任何发布的任何项目的筛选子句中。

  • 其它类型的约束（如外键和检查约束）不会阻止除去列。但是对于大多数约束来说，会有警告消息提示您，标识列上的约束并要求在除去此列之前进行验证。在确认操作后，SQL Server 2000 除去此列上的所有约束，然后除去此列。

说明 对于除去的列，复制不会就与其有关的每种可能的相关性提出警告。如果您考虑要除去的列由另一列上的约束引用，那么 SQL Server 2000 不会通知此相关性，并允许除去此列。因此，您应当透彻理解基础数据库架构，并在除去已发布列时慎重行事。

如何应用架构更改

在合并复制的发布表上添加或除去一个列以后，下次对订阅进行同步处理时架构更改将传播到订阅服务器。在事务复制中，下次日志读取器代理程序和分发代理程序运行时，架构更改将传播到订阅服务器。当用并发的快照处理添加新项目或重新初始化现有项目到事务发布中，且当快照代理程序启动时，分发代理程序停止等待同步过程，包括快照代理程序和日志读取器代理运行的时间。完成同步后，分发代理程序将继续运行。

默认情况下，在事务复制中，自定义存储过程将在订阅服务器上自动重新创建。在默认情况下对于所有类型的复制，废弃带有旧架构信息的当前快照。

如果不希望自定义存储过程在事务发布的架构更改之后在订阅服务器上重新创建，那么应当指定何时创建发布。

说明 当向允许转换已发布的数据的发布添加列或从这样的发布除去列时，DTS 包将需要重新生成。

禁用初始同步处理期间的自定义存储过程的自动创建（事务复制）：

  1. 在创建发布向导中的"指定项目"页上，选择要发布的项目，并为特定表项目单击与之相关的属性（"..."）按钮。

  2. 在"命令"选项卡上，清除"在订阅的初始同步处理期间创建存储过程"复选框。

更改当前快照的强制重新初始化和失效的默认属性（事务复制）：

  • 执行 sp_repladdcolumn 或 sp_repldropcolumn，其中 @force_reinit_subscription 参数值取 1。当设置为 1 时，将不会向订阅服务器传播架构更改命令。除 nosync 订阅外（对于它不进行任何操作），架构更改所影响的所有订阅将重新初始化。

  • 执行 sp_repladdcolumn 或 sp_repldropcolumn，其中 @force_invalidate_snapshot 参数值取 0。当设置为 0 时，仍然会在需要时提供带有先前架构信息的当前快照。该参数只影响用 immediate_sync 选项创建的发布。
将架构更改应用于特定的发布
  • 通常，架构更改在包括到某个项目中时会传播到所有的订阅服务器和发布服务器。可以随意选择要在其中添加列的发布，而架构的更改将只传播到这些发布的订阅服务器。

  • 在除去某列时，所有发布和订阅服务器都会受到影响；不能有选择地在某个特定发布上执行此更改。

在发布数据库上应用架构更改

企业管理器

企业管理器

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO


通过 Internet 执行复制

通过 Internet 复制数据可使远程、脱接和匿名用户在需要时使用 Internet 连接访问数据。使用 Microsoft® SQL Server™ 2000 通过 Internet 复制数据的方法有：

  • 使用包含在 Microsoft Windows NT® Server 4.0 版操作系统或 Microsoft Windows® 2000 Server 操作系统内的虚拟专用网络 (VPN)，以及由一些第三方提供的 VPN。

  • 将复制与 Microsoft Proxy Server 集成在一起。

  • 使用 TCP/IP 和文件传输协议 (FTP) 访问 Internet 上的实时数据（如果未使用防火墙或代理服务器的话）。


使用 VPN 通过 Internet 发布数据

虚拟专用网络 (VPN) 技术使用户得以在保持通讯安全的同时，在家中、分支机构、远程客户端和其它公司通过 Internet 连接到某公司网络进行工作。对于通过 Internet 发布数据，使用 VPN 是最安全的方法。用户可以象在局域网 (LAN) 上那样使用 Windows 身份验证。

VPN 包括客户端软件，使得计算机可以通过 Internet（特殊情况下甚至是 Intranet）连接到专用计算机或服务器上的软件。用户可通过在两端加密和验证用户身份的办法来确保数据安全。通过 Internet 的 VPN 连接，其运作在逻辑上相当于站点间的广域网 (WAN) 链接。

VPN 通过一个网络连接另一个网络的组件。其实现方法是允许用户以 Internet 或其它公共网络（使用诸如 Microsoft® Windows NT 4.0 版或 Microsoft Windows® 2000 操作系统中的 Microsoft 点对点隧道协议 (PPTP) 或者 Windows 2000 中的第 2 层隧道协议 (L2TP)）为通道。这个过程提供了与以前专用网络相同的安全性和功能。

对于用户来说，Internet 的中间路由基本结构是不可见的，数据好象通过专门的专用链接发送。用户所关心的是 VPN 是用户计算机和公司服务器之间的点对点连接。

在将远程客户端配置为使用 VPN 进行连接，同时此客户端能访问 Internet 并已登录到公司 LAN 上之后，可以像此远程客户端直接处于 LAN 上一样地配置复制。出于安全性考虑，通过 VPN 连接的用户和直接地连接在局域网上的用户可能使用不同的网络资源。

有关设置 VPN 的更多信息，请参见 Windows 2000 文档中的虚拟专用网络部分。


使用 Microsoft Proxy Server 通过 Internet 发布数据

Microsoft® SQL Server™ 2000 复制与 Microsoft 代理服务器集成后，可通过 Internet，按照在 Microsoft Windows® NT 4.0 版或 Microsoft Windows 2000 Server 操作系统、Proxy Server 和 SQL Server 2000 上配置的安全性执行复制。

通过该方法，Proxy Server 提供 Internet 与 SQL Server 2000 中存储数据的服务器的连接。订阅服务器通过 Internet 连接到 Proxy Server，并使用请求订阅接收数据。Proxy Server 在经过配置之后，未经授权的 Internet 用户不能访问内部网络资源，同时订阅服务器必须连接到 Proxy Server 上的某个端口，以限制它只能访问已授权的服务。

有关如何为复制配置 Microsoft Proxy Server 的信息，请搜索 Microsoft Web 站点上标题为"Configuring Proxy Server for SQL Server Replication"的白皮书。


使用 TCP/IP 和 FTP 通过 Internet 发布数据

Microsoft® SQL Server™ 2000 可以使用 TCP/IP 套接字或多协议 Net-Library 通过 TCP/IP 在发布服务器或分发服务器与订阅服务器之间建立 ODBC 连接。然后便可以配置发布和请求订阅或匿名订阅，访问含有要复制数据的 FTP 站点。

配置应用程序可在 Internet 上发布数据要求：

  • 配置侦听 TCP/IP的发布服务器或分发服务器

  • 配置发布以允许订阅使用 FTP 接收快照。

  • 创建订阅以使用 FTP 检索快照。

  • 配置订阅代理程序以使用 TCP/IP。


配置侦听 TCP/IP 的发布服务器或分发服务器

在通过 Internet 发布项目之前，发布服务器和分发服务器所在的服务器必须启用以侦听 TCP/IP 或 Multiprotocol（多协议）网络协议。Microsoft® SQL Server™ 2000 使用 TCP/IP 套接字或多协议 Net-Library 通过 TCP/IP 在 Internet 一端的发布服务器或分发服务器与另一端的订阅服务器之间建立 ODBC 连接。在事务发布的请求订阅或匿名订阅中，分发代理程序在订阅服务器上执行并通过 Internet 连接到分发服务器进行同步处理。在合并发布的请求订阅或匿名订阅中，合并代理程序在订阅服务器上执行并通过 Internet 连接到发布服务器和分发服务器进行同步处理。

根据默认，在 SQL Server 2000 典型安装过程中，TCP/IP 套接字 Net-Library 启用，但如果选择自定义安装，那么也许尚未启用。可以将 FTP 路径和端口指定为"发布属性"下的快照文件夹位置，以便将已经配置为 FTP 站点的服务器用作快照文件夹位置。或者可以设置快照文件夹为 FTP 主目录（根据默认为 \Microsoft SQL Server\Mssql\Repldata\Ftp），并将 FTP 主目录配置为 FTP 站点。

指定 FTP 信息

企业管理器

企业管理器

SQL-DMO

SQL-DMO


配置发布以允许订阅服务器使用 FTP 检索快照

在将服务器配置为侦听 TCP/IP 或 Multiprotocol 连接之后，便可以配置发布，使它可通过 Internet 发布数据。通过在发布上设置 @enabled_for_internet 属性，所创建的任何发布都可启用用于 Internet 发布。将 @enabled_for_internet 设置为 TRUE 告诉快照代理程序把与初始快照相关的文件放置到在"发布属性"对话框中指定的 FTP 位置中。

分发代理程序或合并代理程序使用 FTP 将架构和数据的快照下载到订阅服务器。整个发布的映像传送到目的数据库，在此数据库中重新创建为精确的副本。在快照文件到达订阅服务器以后，代理程序会将这些文件应用到订阅服务器上的适当表。代理程序在每个表中扫描，取得一组行的排它锁，复制到新行，释放这些行的锁，然后对下一组行重复此过程。由于代理程序每次只锁住少量行，其他用户应该能够继续使用此表而几乎不会被打断。

可以通过 SQL Server 企业管理器配置发布，方法是在"发布属性"对话框的"订阅选项"选项卡上选择"允许使用 FTP 下载快照"选项。也可以通过复制存储过程编程设置 @enabled_for_internet 属性，此存储过程支持通过 Internet 进行复制：

  • sp_addpublication

  • sp_addmergepublication

  • sp_changemergepublication

  • sp_helpmergepublication

通过 Internet 发布数据

Transact-SQL

Transact-SQL

SQL-DMO

SQL-DMO


配置订阅使用 FTP 检索快照

当发布已启用可用于 Internet 发布后，必须创建此发布的请求订阅或匿名订阅。使用 Internet 的订阅的创建方法与其它订阅相同。通过 Internet 订阅发布的唯一差别在于还必须为所使用的分发代理程序或合并代理程序配置 FTP 寻址属性（FtpAddress、FtpPassword、FtpPort 和 FtpUserName）。

可以通过"发布属性"对话框中的"快照位置"选项卡上的"SQL Server 企业管理器"配置 FTP 地址。


在不同版本的 SQL Server 之间进行复制

因为可以每次对一台运行 Microsoft® SQL Server™ 2000 实例的服务器进行升级，可能会面临这样的情况，即复制拓扑中的服务器运行不同版本的 SQL Server。可以在不同版本的 SQL Server 之间进行复制，但通常仅限于所使用最早版本的功能。

例如，如果您将分发服务器升级为 SQL Server 2000 的实例，但使用运行 SQL Server 7.0 版实例的发布服务器和运行 SQL Server 6.5 版实例的订阅服务器，则您限于使用 SQL Server 6.5 的复制功能，不能使用 SQL Server 7.0 或 SQL Server 2000 中引入的功能。若要使用新特性，请将用于复制的所有服务器升级为 SQL Server 2000。

运行 SQL Server 早期版本的订阅服务器不支持 SQL Server 2000 中的可用功能。例如，如果合并发布包含仅在 SQL Server 2000 中才有效的功能，且对于运行 SQL Server 7.0 的订阅服务器使用强制订阅，则检查其向后兼容性，且合并代理程序将失败并显示错误信息，指出订阅服务器不满足兼容级别。如果事务发布包含仅在 SQL Server 2000 中才有效的功能，且使用对运行SQL Server 7.0 的订阅服务器的强制订阅，则不检查其向后兼容性，且分发代理程序可能失败且显示与向后兼容无关的错误信息，分发代理程序也可能会成功，但是事务处理将在另一点失败。

如果发布具有对运行 SQL Server 早期版本的订阅服务器的活动订阅，且将仅在 SQL Server 2000 中才有效的功能添加到发布，则 SQL Server 7.0 订阅的合并代理程序或分发代理程序将失败。即使已安装了 SQL Server 2000 功能，代理程序也不能成功运行。必须删除订阅并重新创建发布和订阅。

下面是复制拓扑中可以存在的 SQL Server 版本的不同组合。在使用 SQL Server 6.5 时，必须已经安装 SQL Server Service Pack 4 或更高版本。而在使用 SQL Server 7.0 时，必须已经安装 SQL Server Service Pack 1 或更高版本。SQL Server 6.0 版可在快照复制或事务复制中作为 ODBC 订阅服务器使用，但不能作为发布服务器使用。

下表列出快照复制和事务复制的组合。

 | 组合 1 | 组合 2 | 组合 3
发布服务器 | SQL Server 6,5 | SQL Server 7.0 | SQL Server 2000
分发服务器 | SQL Server 6.5 或 SQL Server 7.0 | SQL Server 7.0 或 SQL Server 2000 | SQL Server 2000
订阅服务器 | SQL Server 6.0、SQL Server 6.5、SQL Server 7.0 或 SQL Server 2000 | SQL Server 6.0、SQL Server 6.5、SQL Server 7.0 或 SQL Server 2000 | SQL Server 6.0、SQL Server 6.5、SQL Server 7.0 或 SQL Server 2000

下表列出合并复制的组合。

 | 组合 1 | 组合 2 | 组合 3
发布服务器 | SQL Server 7.0 | SQL Server 2000 | SQL Server 2000
分发服务器 | SQL Server 2000 | SQL Server 2000 | SQL Server 2000
订阅服务器 | SQL Server 7.0 | SQL Server 7.0 | SQL Server 2000

请参见

复制和升级


从 SQL Server 7.0 发布服务器/分发服务器复制到 SQL Server 6,5 订阅服务器

可以使用 SQL Server 企业管理器或存储过程实现从 Microsoft® SQL Server™ 7.0 版发布服务器/分发服务器到 SQL Server 6.5 订阅服务器的复制。发布的创建和订阅的创建都受到一定的限制。

创建发布

在创建含有 SQL Server 6.5 订阅的 SQL Server 7.0 发布时，受到下列限制：

  • 复制的表不能包含任何 Unicode 或 uniqueidentifier 数据类型。

  • 复制的表不能有超过 30 个字符的名称。

  • 自定义存储过程的名称不能超过 21 个字符。在创建仅含有 SQL Server 6.5 订阅服务器的事务发布时，创建发布向导默认使用自定义存储过程在订阅服务器上应用事务。这种配置应用于发布中的每个项目。在订阅服务器上创建和调用的插入/更新/删除存储过程的名称，在默认情况下使用表的名称加上前缀 sp_Msins_、sp_Msupd_ 或 sp_Msdel_。如果某个发布的表的名称超过了 21 个字符，这种前缀将使得自定义存储过程的名称太长，无法在 SQL Server 6.5 订阅服务器上创建。解决办法是更改默认的自定义存储过程的名称，以使它们的长度不超过 30 个字符。方法是进入复制中每个项目的属性页，打开"命令"选项卡，然后更改自定义存储过程的名称。也可以选择不在订阅服务器上使用自定义存储过程或设置使用存储过程 (sp_addarticle) 的订阅，此过程能更有效地替代默认设置。
创建订阅

在创建从 SQL Server 7.0 发布服务器传送到 SQL Server 6.5 订阅服务器的订阅之前，必须在订阅服务器上运行 Replp70.sql，然后在订阅服务器上执行 sp_addpublisher70。sp_addpublisher70 在 SQL Server 6.5 订阅服务器上注册 SQL Server 7.0 发布服务器（进行 SQL 6.x 复制的一个必要步骤）。Replp70.sql 位于 \Mssql7\Install 目录下。sp_addpublisher70 有两个参数：@publisher 和 @dist_account。@publisher 是 SQL Server 7.0 发布服务器的名称。@dist_account 是域帐户名称，SQL Server 代理程序以此名称在 SQL Server 7.0 分发服务器上运行。此语法的示例如下：

EXEC sp_addpublisher70 'PUBSERV', 'REDMOND\repladmin'

对于复制而言还有必要启用 SQL Server 6.5 订阅数据库。要做到这一点可使用 SQL Server 6.5 中的 SQL Server 企业管理器或者执行：

EXEC sp_dboption <dbname>, 'subscribed', true

SQL Server 7.0 复制支持对 SQL Server 6.5 服务器的强制订阅，但不支持从 SQL Server 企业管理器 6.5 的请求订阅。若要配置对 SQL Server 6.5 订阅服务器的强制订阅，必须首先在发布服务器上注册此订阅服务器。要做到这一点可使用 SQL Server 7.0 中的 SQL Server 企业管理器或者执行 sp_addsubscriber。

说明 运行 SQL Server 6.5 的订阅服务器不支持可为空的 bit 列，所以由运行 SQL Server 7.0 或 SQL Server 2000 的发布服务器发布的 bit 列中的 NULL 值不能在订阅服务器上显示。如果有运行 SQL Server 6.5 的订阅服务器且需要使用可为空的 bit 列，则使用自定义存储过程将外来 NULL 值改为 0。


从 SQL Server 7.0 发布服务器/分发服务器复制到 SQL Server 6.0 订阅服务器

从 Microsoft® SQL Server™ 7.0 版发布服务器/分发服务器复制到 SQL Server 6.0 订阅服务器的执行方式与复制到 SQL Server 6.5 订阅服务器的方式十分相似。唯一的区别在于 SQL Server 6.0 订阅服务器必须配置为 ODBC 数据源而不是本机 SQL Server 订阅服务器。


从 SQL 6.5 发布服务器/分发服务器复制到 SQL Server 7.0 订阅服务器

Microsoft® SQL Server™ 7.0 版可以作为 SQL Server 6.5 版发布服务器的订阅服务器。必须在 SQL Server 6.5 发布服务器上将 SQL Server 7.0 Server 添加为订阅服务器。

此操作还将在 SQL Server 企业管理器的控制台树中添加一项。它只用于复制目的，不能使用 SQL Server 6.5 版中的 SQL Server 企业管理器管理此服务器。如果在此控制台树中单击此服务器，则会返回如下警告消息（若要复制则可忽略此消息）：

A connection cannot be established to <SERVER> - (SQL Server) You must upgrade your SQL 企业管理器 and SQL-DMO (SQLOLE) to version 7.0 (SQLDMO) to connect to this server

不能使用 SQL Server 6.5 版中的 SQL Server 企业管理器的复制拓扑或请求订阅功能管理 SQL Server 7.0 订阅服务器。

如果未在分发服务器上对 ODBC 驱动程序进行升级（因此使用的是 SQL Server 6.5 ODBC 驱动程序），则当分发代理程序连接到 SQL Server 7.0 订阅服务器时可能遇到登录失败。为成功启动 SQL Server 7.0 订阅服务器，应当对 ODBC 驱动程序进行升级。

若要从运行 SQL Server 6.5 的发布服务器发布到运行 SQL Server 7.0 的订阅服务器，请在 SQL Server 7.0 订阅服务器上，使用空白密码添加 SQL Server 身份验证登录 repl_publisher。


从 SQL Server 6.5 发布服务器复制到 SQL Server 7.0 分发服务器

可以配置 Microsoft® SQL Server™ 6.5 版发布服务器，以将 SQL Server 7.0 安装用作远程分发服务器。这种拓扑结构使得您可以错开复制应用程序中所涉及的多个SQL Server 安装的升级。此外，在使用 SQL Server 7.0 分发服务器为 SQL Server 6.5 发布服务器提供服务时，可以利用 SQL Server 7.0 复制的监视功能。

通过在 SQL Server 企业管理器 7.0 中注册 SQL Server 6.5 服务器并将其配置为发布服务器，可以配置它使用 SQL Server 7.0 分发服务器。


使用 SQL Server 2000 Windows CE 版本进行复制

使用 Microsoft® SQL Server™ 2000 和合并复制，可以将数据发布到运行 SQL Server 2000 Windows CE 版 (SQL Server CE) 的移动设备上。合并复制适合于使用移动的、断开的订阅服务器进行复制，因为它允许订阅服务器与网络和发布服务器断开时在订阅服务器进行更新。以后，当重新连接设备时，订阅服务器上的更改可以与发布服务器或其它订阅服务器上的更改合并。

使用 SQL Server CE 进行复制可用于使用匿名订阅的合并发布。在订阅服务器上执行订阅管理，且有关运行 SQL Server CE 的订阅服务器和订阅的信息不存储在发布服务器上。

如何复制到 SQL Server CE

发布到运行 SQL Server CE 的订阅服务器类似于使用匿名订阅发布到其它类型的订阅服务器上。

创建合并发布，并在创建发布向导的指定订阅服务器类型页上选择"运行 SQL Server CE 的服务器"，作为可以订阅到该发布的一种订阅服务器类型。如果选择了该选项，将自动启用发布的匿名订阅。

SQL Server CE 应用程序可以使用 SQL Server CE 复制对象订阅到发布。如果创建了订阅，则应用初始快照以在运行 SQL Server CE 的设备上创建订阅数据库。

用户可以在联机或脱机状态下修改订阅数据库中的数据。当重新连接时，订阅服务器上所做的数据更改将被发送到发布服务器上且与发布服务器和其它订阅服务器上所做的更改合并。自上一次同步后在发布服务器上所做的更改或传播到发布服务器的更改将被发送到订阅服务器。

SQL Server CE 复制对象在 SQL Server CE 的内部控制 SQL Server 合并代理程序的执行以完成同步。如果由于更改到相同的数据而发生冲突，将使用创建发布时选择的冲突解决程序解决冲突。

有关更多信息，请参见 SQL Server CE 文档。

请参见

匿名订阅

合并复制


复制选项

复制选项使您得以以最适合于您的应用程序和环境的方式配置复制。

选项 		复制类型
益处
筛选已发布数据 快照复制

事务复制

合并复制

 筛选使您得以创建数据的垂直和/或水平分区，该数据可作为复制的一部分进行发布。通过向不同的订阅服务器分配数据分区，您可以：
  • 将网络上发送的数据量减到最少。

  • 减少订阅服务器上需要的存储空间量。

  • 根据个别订阅服务器的要求，自定义发布和应用程序。

  • 减少冲突，因为不同的数据分区可以被发送到不同的订阅服务器中。
可更新的订阅（立即更新，排队更新） 快照复制

事务复制

 立即更新和排队更新选项使用户得以在订阅服务器上更新数据，并立即将这些更新传播到发布服务器，或者将更新存储在队列中。

当发布服务器、分发服务器和订阅服务器大多数时间是连接的，并且当由多个用户更新相同的数据而引起的冲突很少发生时，可更新的订阅适合于复制拓扑，这种情况下主要在订阅服务器上读取已复制的数据，只是偶尔进行更新。
可更新的订阅（合并复制） 合并复制 合并复制使用户得以更新订阅服务器或发布服务器上的数据，并得以连续地、按需或按调度的间隔使更改同步。

合并复制非常适合拓扑，即使在订阅服务器从发布服务器断开时也经常在拓扑上更新已复制数据。多用户更新相同数据时引起的冲突应是不经常发生的，但是合并复制提供了一个丰富的选项集用于处理确实发生的冲突。有关更多信息，请参见合并复制。
转换已发布的数据 快照复制

事务复制

 可以在复制期间调节数据转换服务 (DTS) 的数据移动、转换映射和筛选能力。通过可转换的订阅，可以：
  • 创建快照和事务发布的自定义分区。

  • 当数据与数据类型映射（如整型到实型）、列操作（如将名列和姓列连成一个列）、字符串操作以及函数一起发布时，则转换该数据。
可选同步伙伴 | 合并复制 | 可选同步伙伴允许合并订阅服务器使用订阅起源所在的发布服务器以外的服务器对数据进行同步处理。这使得订阅服务器得以在原始发布服务器不可用时同步数据，同时，这对可以通过备用服务器访问更快捷和更可靠网络连接的移动订阅服务器也很有用。
优化同步 | 合并复制 | 合并复制期间，通过优化同步，您可以在发布服务器上存储更多的信息，而不用将这些信息通过网络传输到订阅服务器。合并复制期间，通过优化同步，您可以在发布服务器上存储更多的信息，而不用将这些信息通过网络传输到订阅服务器。


筛选已发布数据

可通过水平、垂直、动态和联接筛选创建要发布数据的分区。通过筛选已发布数据，可以：

  • 将网络上发送的数据量减到最少。

  • 减少订阅服务器上需要的存储空间量。

  • 根据个别订阅服务器的要求，自定义发布和应用程序。

  • 由于不同的数据分区可以发送到不同的订阅服务器（不同的订阅服务器不会同时更新同一个数据值），因此可避免或减少冲突。

行筛选和列筛选可用于快照发布、事务发布和合并发布。行筛选使用 SQL 语句的 WHERE 子句并基于特定准则限制发布中所包含的行。列筛选限制发布中所包含的列。

动态筛选和联接筛选扩展了合并复制的功能。动态筛选是使用函数从订阅服务器检索值并基于该值筛选数据的行筛选。该筛选为发布定义一次，但合格的结果集对于每个订阅服务器可以不同，并且允许订阅服务器上的用户只接收根据需要自定义的数据的子集。

联接筛选将行筛选从一个已发布的表扩展到另一个已发布的表。联接筛选定义两个表之间的一种关系，该关系将在合并进程中加以强制；它与指定两个表之间的联接类似。


行筛选

使用行筛选可以指定要发布的表中行的子集。当只需要将特定行传播到订阅服务器时，可以使用行筛选，以消除用户不需要看到的行（如包含敏感或保密信息的行），或创建发送到不同订阅服务器的不同数据分区。对于可以将不同数据分区发布到不同订阅服务器的应用程序，这样做还有助于避免由多个订阅服务器更新相同的数据值导致的冲突。

行筛选之所以方便是因为它可以应用于现有应用程序，这些应用程序中提供站点特有的特性，以在要发布的表或其相关表之一中根据此特性进行筛选。

在下面的关系图中，对已发布的表进行筛选，以便发送到订阅服务器的发布中只包含行 2、3 和 6。

行筛选可用于快照复制、事务复制和合并复制。事务发布中的行筛选可能会显著增加开销，因为要为每个为已发布表编写的日志行评估项目筛选子句以确定是否要将其标记为复制。事务发布中行筛选在以下情况下应避免使用：各站点可支持完整数据装载，总体数据集相当小，以及每天的插入、更新和删除事务的数目较小。

快照复制和事务复制中的行筛选是静态的，在创建发布向导或"发布属性"对话框中设置的 WHERE 子句准则保持不变，直到对它进行修改。如果有两个订阅服务器分别需要发布表中的不同数据行，则需要两个不同的发布，分别带有不同的行筛选以为每个订阅服务器检索正确的行。

尽管可以将子查询放入行筛选中，但行筛选不是联接筛选。如果更新由某个子查询引用的表中的行，则不会重新评估该查询，并且不会将该行作为复制的一部分进行传播。复制联接筛选仅存在于合并复制中。有关更多信息，请参见联接筛选。

创建多个发布的一种可选方法是：将动态筛选用于合并复制，或创建可转换的订阅，该订阅带有用于快照复制或事务复制的自定义筛选，此筛选基于来自各个订阅服务器的信息动态创建数据分区。有关更多信息，请参见动态筛选和转换已发布数据。

示例

Northwind Traders 公司需要向其销售人员发布客户和订单信息。销售代表们是根据客户所在地区进行分配以向客户提供服务的，Northwind 希望销售代表们只有访问其指定地区的数据的权限。

由于销售代表们需要经常更新数据，并在连接和断开发布服务器时也需要进行更新，所以 Northwind 的复制管理员决定使用合并复制，创建基于地区的带行筛选的不同发布。该发布将包括客户、订单和订单明细表中的数据。例如，要将其中一个发布限制在美国的西北地区。在创建发布向导中的"指定筛选"对话框中，WHERE 子句应为：

SELECT <published_columns> FROM [dbo].[Customers] WHERE Region = 'WA'

因为基于地区的数据分区将发送到订阅服务器，而这些订阅服务器对每个地区具有唯一的逻辑所有权，所以多个订阅服务器更新相同数据时可能产生的冲突将被避免。但如果发布服务器和订阅服务器更新相同数据，则冲突仍可能发生。有关更多信息，请参见合并复制和合并复制冲突的检测和解决。

另外，通常在这种情况下的更好方法是对合并发布使用动态筛选或者对快照发布或事务发布使用可转换订阅。有关更多信息，请参见动态筛选和转换已发布数据。

水平筛选发布

企业管理器

企业管理器

SQL-DMO

使用发布属性水平筛选发布

企业管理器


列筛选

列筛选限制要包含在快照发布、事务发布或合并发布中的列。列筛选可以减少将数据更新传播到订阅服务器所需的时间，减少订阅服务器上所需的存储空间，以及限制发布中的数据为各个订阅服务器所需的数据。

下图展示一个发布，它具有一个列筛选来限制除列 A、B 和 D 以外的所有列。

还可以一起使用行筛选和列筛选，如下图所示。

当将列添加到垂直分区中时，表结构发生改变，且发布表上的任何 INSERT 语句都将需要列的列表。

不能从发布中进行垂直筛选的列有：

  • 带有主键约束的列。

  • 无默认值的非空列。

  • 包含在唯一索引中的列。

  • 合并发布的 ROWGUID 列和允许即时更新订阅的快照发布或事务发布的 ROWGUID 列。

对于快照复制和事务复制，可以使用可转换的订阅创建自定义筛选，此筛选使用一个发布为不同的订阅服务器生成不同的垂直分区。有关更多信息，请参见使用可转换的订阅创建自定义数据分区。

说明 如果快照发布或事务发布允许可更新的订阅并且发布具有一个列筛选，则无法从发布对无默认值的非空列进行筛选。

示例

Northwind Traders 使用合并复制将客户和订单信息发布给它的移动的、偶尔连接的销售代表。总部决定跟踪每个销售代表在订单上提取的佣金，且将名为 COMMISSION 的列添加到 ORDER DETAILS 表中。

目前将销售信息分发给所有销售代表，但是 Northwind 经理不想让销售代表看到已支付的佣金金额。复制管理员可以使用列筛选从发布中排除 COMMISSION 列。

垂直筛选发布

企业管理器

企业管理器

SQL-DMO

使用发布属性垂直筛选发布

企业管理器


动态筛选

动态筛选使您得以创建合并发布，然后从发布表中筛选数据，为不同的订阅服务器提供不同分区的数据。在合并发布中使用动态筛选的益处有：

  • 存储在发布服务器上的发布较少。这减小了管理多个发布的开销。

  • 在动态筛选中使用用户定义的函数使您得以筛选准则。

  • 因为根据订阅合并代理程序的连接属性对数据进行筛选，所以订阅服务器仅接收需要的信息。

在动态筛选中，指定 Microsoft® SQL Server™ 2000 函数或用户定义函数，当合并进程在订阅服务器和发布服务器之间复制数据时，该函数根据合并代理程序的连接属性为每个订阅服务器进行不同的计算。用于该目的的最常见的系统函数是 SUSER_SNAME() 和 HOST_NAME()。可以在动态筛选中使用用户定义函数，但是除非用户定义函数的定义包括 SUSER_SNAME()、HOST_NAME()，或用户定义函数计算筛选准则中系统函数之一（如 MyUDF(SUSER_SNAME()），否则用户定义函数将是静态的。

动态筛选是行筛选（限制数据的行），并以单个表为基础进行创建（它们不跨表，也不联接表）。但是可以在同一个发布中以及相同的已发布表上既使用动态筛选又使用联接筛选。

动态筛选只可用于合并复制，因此在使用动态筛选时，应当考虑也使用动态快照。根据默认，动态筛选的发布依靠来自发布服务器的 INSERT 语句将数据作为初始快照的一部分应用于订阅服务器。动态快照提供这样的性能优势：当使用动态筛选应用初始快照时，可以使用 SQL 大容量复制程序 (bcp) 文件将数据应用于特定订阅服务器。有关更多信息，请参见动态快照。

当使用快照复制或事务复制时，可以使用可转换的订阅创建自定义筛选，此筛选将基于各个订阅服务器要求筛选数据。有关更多信息，请参见转换已发布的数据。

示例

Northwind Traders 使用合并复制将客户和订单信息发布给它的移动的、偶尔连接的销售代表。Northwind 希望确保每个销售代表只接收其客户的数据并能够对数据进行更新。

无须为每个销售代表创建单独的发布，Northwind 将在 CUSTOMERS 表项目上的动态筛选中使用 SUSER_SNAME() 函数，以返回指派给每个客户的销售代表的用户 ID，并基于它筛选已发布的数据。可将 SALES_REP 列添加到 CUSTOMERS 表中以标识负责为每个客户服务的销售代表。

发布服务器上的 CUSTOMERS 表。

CustomerID | CompanyName | SALES_REP
GREAL | Great Lakes Food Market | WestRegion\Robert King
RATTC | Rattlesnake Canyon Grocery | Janet Leverling

Northwind 合并发布中的 CUSTOMERS 项目的行筛选为：

WHERE SALES_REP = SUSER_SNAME()

如果合并进程使用 WestRegion\Robert King 集成安全帐户进行初始化，则仅当合并代理程序由用户 WestRegion\Robert King 运行时，SUSER_SNAME() 函数才在动态筛选中取值为该帐户。结果，Robert King 只接收与他作为销售代表被指派的客户有关的数据。

发布数据时使用动态筛选以后订阅服务器上的 CUSTOMERS 表。

CUST_ID | CUSTNAME | SALES_REP
GREAL | Great Lakes Food Market | West Region\Robert King

根据使用的是 Windows 身份验证还是 SQL Server 身份验证，动态筛选的行为不同。在使用 SQL Server 身份验证的情况下，合并代理程序命令行中指定的 –PublisherLogin 参数（或 SQL 合并 ActiveX® 控件中的 PublisherLogin 属性）是在动态筛选中使用 SUSER_SNAME() 函数时所返回的主要属性。

在使用 Windows 身份验证的情况下，SQL Server 代理程序初始化合并进程，而且 SQL Server 2000 中的 SUSER_SNAME() 函数返回在其下运行 SQLServerAgent 服务的帐户。这可能与用户的 Microsoft Windows® NT® 安全帐户不同。如果使用 Microsoft ActiveX 控件或通过独立调用 SQL Server 代理程序的 Replmerge.exe 初始化合并进程，则 SQL Server 2000 中的 SUSER_SNAME() 函数返回用户的登录帐户。

当使用动态筛选时，筛选逻辑表达式在到发布服务器的合并连接而不是在到订阅服务器的连接的上下文内进行评估。如果合并进程使用 SQL Server 2000 登录 Janet Leverling 连接到发布服务器，而使用 sa 登录连接到订阅服务器，则 SUSER_SNAME() 函数将在筛选逻辑中取值为 Janet Leverling。

订阅服务器上的 CUSTOMERS 表（使用动态筛选）。

CUST_ID | CUSTNAME | SALES_REP
RATTC | Rattlesnake Canyon Grocery | Janet Leverling


动态快照

动态快照为应用动态筛选过的合并复制快照带来了性能上的好处。通过使用 Microsoft® SQL Server™ 2000 大容量复制文件将数据应用于特定订阅服务器而不是使用一系列 INSERT 语句可以提高性能。

为订阅生成动态快照还提供了通过可移动媒体（如光盘）保存和传输快照，并将快照从媒体应用于订阅服务器的灵活性，而不必通过慢速网络连接应用初始快照。

动态快照工作方式

当动态筛选用于合并发布时，根据合并过程中发布的合并代理程序的连接属性筛选发布表中的数据。根据默认，动态筛选的发布依靠来自发布服务器的 INSERT 语句，将数据作为初始快照的一部分应用于订阅服务器。这可能是一个非常长且消耗大量资源的过程，因为合并代理程序将不得不根据动态筛选准则逐行确定哪些数据要包含在快照中。

动态快照提供这样的性能优势：当使用动态筛选应用初始快照时，可以使用 SQL 大容量复制程序 (bcp) 文件将数据应用于特定订阅服务器。当创建动态快照时，预先生成一个快照，将它自定义给特定订阅服务器。因为已经复制和提取了数据值，所以快照的应用将与应用不带动态筛选的快照一样快。但是，生成和存储动态快照时需要额外的时间和空间。

尽管准备动态快照所需时间更长（将需要生成两个快照），但在订阅服务器上应用快照的进程比为动态筛选的合并发布应用标准快照要快。在通过筛选标准快照创建动态快照之前需首先生成标准快照。

可以使用 SQL Server 企业管理器、创建发布向导、创建动态快照作业向导、Transact-SQL 系统存储过程和脚本、Microsoft ActiveX® 控件或 SQL-DMO 执行动态快照。

动态快照考虑事项

当准备动态筛选的合并发布和动态快照时，请考虑：

  • 动态快照可用于各种订阅。可以使用创建动态快照作业向导和/或运行带有适当参数的快照代理程序生成动态快照。使用合并代理程序或合并 ActiveX 控件和设置 DynamicSnapshotLocation 属性来应用动态快照。

  • 可以使用合并代理程序的 –DynamicSnapshotLocation 命令行参数或合并 ActiveX 控件中的 DynamicSnapshotLocation 属性应用预先生成的动态快照。

  • 动态筛选和动态快照只可用于合并复制。

  • 若要生成动态快照，必须为动态筛选启用发布，并且必须生成一个标准快照。

  • 如果对标准快照进行压缩，则动态快照文件也将压缩。若要压缩标准快照（从而压缩动态快照），请打开"发布属性"对话框，在"快照位置"选项卡上，选择"在以下位置生成快照"选项，在文本框中指定快照位置，然后选择"在该位置压缩快照文件"选项。

  • 指定为发布服务器登录名的登录名必须在发布访问列表 (PAL) 中，或者是发布数据库 sysadmin 角色或 db_owner 组的成员。此登录名可以在创建动态快照作业向导中指定，也可以使用快照代理程序中的参数 -DynamicFilterLogin 指定。

  • 因为 SQL Server 在快照代理程序中添加和除去临时登录，所以为能够生成动态快照，快照代理程序的发布服务器登录必须是 securityadmin 服务器角色的成员和发布数据库中的 db_owner 组的成员。

  • 为动态快照生成指定的动态筛选登录必须是相应的发布访问列表 (PAL) 的成员。

  • 发布服务器上的 SQL Server 必须以混合安全模式运行。

  • 更改发布属性而不重新生成动态筛选的发布的标准快照，将使所有后续生成的动态快照无效。

例如，如果有一个销售代表基于 SalesPersonLogin 接收客户管理信息，SalesPersonLogin 是用在订阅服务器上以连接到发布服务器的真正的集成登录。在本实例中有两个用户"域\JohnSmith"和"域\BobJohnson"。发布的管理员可以指定快照代理程序的 -DynamicFilterLogin 属性为"域\JohnSmith"并为名为 John Smith 的用户生成动态快照。类似地，这些管理员可以指定 –DynamicFilterLogin 属性为 DOMAIN\BobJohnson 并为名为 Bob Johnson 的用户生成快照。但是，为使这种情况发生，该动态筛选必须使用 SUSER_SNAME() 函数来表达。

如果先前使用的动态筛选是 SalesPersonLogin = SUSER_SNAME()，则现在动态筛选必须为 SalesPersonLogin = SUSER_SNAME()，才能使用动态快照功能。

  • 不使用在动态快照中使用的 SUSER_SNAME() 系统函数中的参数，如 'SUSER_SNAME(SID)'。

  • 隐性依赖于 SUSER_SNAME() 或当前用户的函数（如 USER_NAME()、CURRENT_USER()、SYSTEM_USER()、USER_ID() 或 SUSER_SID()）将不会按预期运行，不应用于动态快照（而应使用 SUSER_SNAME() 或 HOST_NAME()）。

  • 可以在动态筛选中使用用户定义函数；然而，如果用户定义的筛选对于所有订阅服务器取相同的值，则这是一种静态筛选，且不必使用动态快照，因为所有订阅服务器都将接收相同的数据快照。

  • 可以在动态筛选的筛选准则中使用嵌套在用户定义函数中的 SUSER_SNAME() 系统函数，而且可使用动态快照（如 MyUDF(SUSER_SNAME()），用户定义函数 MyUDF 将评估 SUSER_SNAME() 系统函数）。系统函数在动态筛选准则中必须是可见的。如果系统函数存在于用户定义函数的定义中，并且在动态筛选中仅输入了用户定义函数，则将无法使用动态快照。

创建动态快照

企业管理器

企业管理器

SQL-DMO

手工生成并应用动态快照

  1. 运行快照代理程序以生成标准快照架构及其它文件。当运行快照代理程序时使用标准属性（如 -Publisher、-PublisherDB、-Publication 等等）。

  2. 为所定义的每个订阅服务器分区运行快照代理程序一次以生成大容量复制 (.bcp) 文件。使用标准属性和下列属性：
    • -DynamicFilterHostName

    • -DynamicFilter Login

    • -DynamicSnapshotLocation
  3. 为每个订阅运行合并代理程序以将初始动态快照应用于订阅服务器。使用标准属性并添加下列属性：
    • -Hostname

    • -DynamicSnapshotLocation

请参见

DynamicSnapshotLocation 属性

MergeDynamicSnapshotJob 对象

SQLSnapshot 对象


验证订阅服务器信息

通过合并复制动态筛选，可以使用引用订阅服务器信息的函数。Microsoft® SQL Server™ 2000 在每个合并之前基于该函数验证订阅服务器信息。从而确保每个合并分区信息的一致。

例如，当使用函数 SUSER_SNAME() 动态筛选某个发布时，合并代理程序基于对 SUSER_SNAME() 表达式有效的数据将初始快照应用于每个订阅服务器。

当订阅服务器重新连接到发布服务器以进行下一次同步处理时，合并代理程序将验证订阅服务器上的信息，确保对与原先作为初始快照的一部分发送的分区相同的分区进行同步处理。如果合并代理程序检测到筛选表达式返回不同的值，则合并失败。因为动态筛选中所使用的函数的值已经改变，所以订阅服务器上的订阅可能需要重新初始化，或者必须使用原始登录或 host_name 值，才能允许同步处理。这将防止更改订阅服务器的合并设置而引起的问题。

可以选择创建动态筛选，然后当使用创建发布向导创建发布时，或在通过使用发布属性创建了发布并为动态筛选启用发布之后，验证订阅服务器信息。

示例

Northwind Traders 使用具有动态筛选的合并发布向其移动的、偶尔连接的销售代表发布顾客和订单信息。基于访问订阅服务器用户 ID 的 SUSER_SNAME() 系统函数，筛选发布以获得基于由 SUSER_SNAME() 检索的用户 ID 的数据。

如果由 Northwind 销售代表 Bob Jones 使用的膝上型电脑是具有动态筛选的合并发布的订阅服务器，每次 Bob Jones 登录到发布服务器并与之同步数据时，将在登录到其膝上型电脑时接收仅基于输入的用户 ID 的数据。因为他是接收客户和订单信息的销售代表，所以他仅接收所服务顾客的数据。

使用创建发布向导验证订阅服务器信息

企业管理器

企业管理器

验证订阅服务器信息

企业管理器


联接筛选

当一个表的筛选基于发布中的另一个表时，联接筛选允许在合并复制筛选中使用跨表关系。联接筛选定义两个表之间的一种关系，该关系将在合并进程中加以强制；它与指定两个表之间的联接类似。联接筛选命名两个项目，并指定联接条件代表项目中的两个表之间的关系。联接条件通常为以下形式：

ARTICLE1_TABLE.COLUMN = ARTICLE2_TABLE.COLUMN

联接筛选通常与行筛选联合使用，允许合并进程保持两个表之间的引用完整性。如果某个使用行筛选发布的表由另一个已发布表中的外键引用，则外键表的项目必须具有一个联接筛选来代表主键表项目上的引用相关性。

当创建发布时，SQL Server 企业管理器使用该规则为在外键引用中所基于的外键表自动建议联接筛选逻辑。为此原因，也为了使用方便，建议声明正确的主键到外键的关系，然后当使用创建发布向导创建发布时让联接筛选自动生成。

说明 使用 CREATE TABLE 或 ALTER TABLE 创建 FOREIGN KEY 约束的语法允许 NOT FOR REPLICATION 选项。当设置了该选项时，Microsoft® SQL Server™ 2000 假定当用户进行数据更改时验证了引用；因此，当合并进程对数据进行同步处理时，SQL Server 2000 将不执行附加的处理步骤以验证引用。如果使用该选项，则必须定义一个合并筛选以避免订阅服务器上出现无效的外键行。

联接筛选并非严格限于主键/外键关系。联接筛选可基于与两个项目表中的数据相关联的任何比较逻辑，但该逻辑应尽可能使用索引列，以获得最佳性能。

根据联接条件是否基于一个唯一列，合并进程具有特殊的性能优化，如同联接筛选代表外键关系时的情况。如果联接条件基于一个唯一列，则应当为项目设置 join_unique_key 属性，以获得最佳性能。

尽管可以将子查询放入行筛选中，但行筛选不是联接筛选。如果更新由某个子查询引用的表中的行，则不会重新评估该查询，并且不会将该行作为复制的一部分进行传播。复制联接筛选仅存在于合并复制中。

警告 具有多个表（如数十个或数百个表）的联接筛选将严重影响合并处理过程中的性能。如果正在生成五个或更多表的联接筛选，建议考虑使用其它解决方案。其它策略可能不会筛选这些表，而主要是查找表、较小的表和未经更改的表。使这些表成为发布整体的一部分。建议仅在这些表中使用联接筛选，因为在订阅服务器中认真进行分区很重要。

示例

Northwind Traders 数据库包含 CUSTOMERS 表和 ORDERS 表。CUSTOMERS 表具有 CustomerID 主键，而 ORDERS 表具有 CustomerID 列，该列带有与 CUSTOMERS 表中的 CustomerID 列相关的外键约束。还可能需要向 CUSTOMERS 表添加一个新列，标题为 Status，以显示客户是活动的还是非活动的。

CUSTOMERS 表

CustomerID | CustomerName | 状态
ALFKI | Alfreds Futterkiste | 活动的
ANATR | Ana Trujillo Emparedados. . . | 非活动
ANTON | Antonio Moreno Taqueria | 活动的

ORDERS 表

OrderID | CustomerID | OrderDate
10643 | ALFKI | 1997-08-25
11077 | RATTC | 1998-05-06
10926 | ANATR | 1998-03-04
11000 | RATTC | 1998-04-06
11010 | REGGC | 1998-04-09
10569 | RATTC | 1997-06-16

将为 ORDERS 项目定义这些表的联接筛选。联接项目为 CUSTOMERS 项目，而联接筛选子句为：

CUSTOMERS.CUSTOMERID=ORDERS.CUSTOMERID

如果发布中的 CUSTOMERS 表项目具有行筛选子句 Status = 'Active'，则合并进程只将 Alfreds Futterkiste 和 Antonio Moreno Taqueria 客户数据发布到订阅服务器。

如果不存在将 ORDERS 表数据限制于已筛选的客户的联接筛选，则合并进程因 ORDERS 表中的 CustomerID 列的主键冲突而失败。这是因为该进程试图插入非活动的客户的事务行，这些行不具有订阅服务器上的 CUSTOMERS 表中的有效的 CustomerID。

没有联接筛选应用于订阅服务器的 ORDERS 表数据。

OrderID | CustomerID | OrderDate
10643 | ALFKI | 1997-08-25
11077* | RATTC | 1998-05-06
10926 | ANATR | 1998-03-04
11000* | RATTC | 1998-04-06
11010* | REGGC | 1998-04-09
10569* | RATTC | 1997-06-16

*这些行违反了订阅服务器上 CustomerID 列上的外键。

若要避免该问题，请将联接筛选添加到 ORDERS 表中，该筛选代表 CUSTOMERS 表上的引用相关性。合并进程只复制活动客户的 ORDERS 数据。

发布服务器上的 CUSTOMERS 表。

CustomerID | CustomerName | 状态
ALFKI | Alfreds Futterkiste | 活动的
ANATR | Ana Trujillo Emparedados. . . | 非活动
ANTON | Antonio Moreno Taqueria | 活动的

发布服务器上的 ORDERS 表。

OrderID | CustomerID | OrderDate
10643 | ALFKI | 1997-08-25
11077 | RATTC | 1998-05-06
10926 | ANATR | 1998-03-04
11000 | RATTC | 1998-04-06
11010 | REGGC | 1998-04-09
10569 | RATTC | 1997-06-16

订阅服务器上的 CUSTOMERS 表，该表带有用于活动客户的行筛选子句。

CustomerID | CustomerName | 状态
ALFKI | Alfreds Futterkiste | 活动的
ANTON | Antonio Moreno Taqueria | 活动的

订阅服务器上的 ORDERS 表，该表带有对活动客户的联接筛选。

OrderID | CustomerID | OrderDate
10643 | ALFKI | 1997-08-25
10926 | ANTON | 1998-03-04


用户定义函数和静态筛选

用户定义函数是由封装的 Transact-SQL 逻辑集合组成的子程序。可以在行静态或动态筛选中使用这些函数。

通过使用用户定义的函数可以增加筛选功能，因为这样做可以基于频繁执行的逻辑、表驱动的业务规则或任何返回值的复杂指令的集合来创建筛选。

当在快照复制、事务复制或合并复制中进行水平筛选（行筛选复制表中行的子集）时，可以指定返回标量值（如 int、char 或 decimal）的用户定义函数。

若要创建用作发布筛选的用户定义函数，请在包含要发布数据的数据库上使用 CREATE FUNCTION 命令，并使用 Transact-SQL 生成一个函数。然后当使用创建发布向导创建新的发布或当使用"发布属性"对话框配置现有发布时，可以在筛选中使用该函数。如果发布有订户，则必须除去该发布的所有订户，才可以创建或修改行筛选。将该函数作为发布中的筛选的一部分使用时，不必复制该函数。

示例

以下语句创建一个函数来返回参数中指定的任何日期的星期号：

CREATE FUNCTION fn_wknum(@Parm datetime)
RETURNS  int
AS
BEGIN
  DECLARE @ReturnVar int
  SELECT @ReturnVar = CAST((DATEPART(dy,@Parm) + DATEPART(dw,@Parm-DATEPART(dy, @Parm)-1))/7+1 AS int)
  RETURN @ReturnVar
END

若要基于 Northwind 数据库在发布中执行 fn_wknum 示例，请在该数据库上创建此函数。启动创建发布向导，选择"定义数据筛选"，然后在"筛选表行"对话框中，单击 Orders 项目的属性按钮（"..."）。

在"指定筛选"对话框中，可以完成 WHERE 子句，以基于 orderdate 列筛选任意年的前 12 周。

SELECT * FROM [dbo].[Orders] WHERE dbo.fn_wknum(orderdate) between 1 and 12

使用创建发布向导通过用户定义函数进行筛选

企业管理器

企业管理器

使用"发布属性"对话框通过用户定义函数进行筛选

企业管理器

企业管理器

除去发布的所有订阅

企业管理器

企业管理器

请参见

CREATE FUNCTION

用户定义函数和动态筛选


用户定义函数和动态筛选

通过调用用户定义函数以确定数据的不同分区，可以在筛选合并发布时获得更大灵活性，并且改善动态筛选性能。动态筛选使您可以定义将一个发布的不同分区复制到不同订阅服务器。

动态筛选可以使用内部函数（如 SUSER_SNAME()），内部函数基于发布的各订阅服务器取值。基于该函数返回的值将数据的不同分区复制到不同订阅服务器。

用户定义函数使您可以定义动态筛选中使用的函数，从而扩展了该功能。这种功能增强使您可以定义业务规则、标量或表值，以在基于动态筛选对已发布数据进行分区时使用。

例如，在某个销售环境中，为每个客户指派一个地区代码来代表他们所在的地区。Northwest 中的销售代表只需要查看该地区的客户的订单。若要仅将在 Northwest 中发出的订单发布到该地区中的订阅服务器，可以编写一个用户定义函数，该函数从该订阅服务器检索地区代码，然后使用该代码根据接收数据的订阅服务器将数据动态分区。

有关更多信息，请参见动态筛选。

请参见

CREATE FUNCTION

用户定义函数和静态筛选


可更新订阅

 复制

可更新的订阅

使用快照复制或事务复制时，默认情况下复制的数据为只读；然而，能够使用可更新订阅在订阅服务器上修改复制的数据。若需要使用快照或事务复制在订阅服务器上修改数据，可根据要求选择以下选项之一。

可更新订阅 | 要求
即时更新 | 必须连接发布服务器和订阅服务器才能更新订阅服务器上的数据。
排队更新 | 不必连接发布服务器和订阅服务器即可更新订阅服务器上的数据。可在脱机状态下进行更新。
在即时更新中将排队更新作为故障转移 | 发布服务器和订阅服务器在大多数时间都相连，但可能偶尔需要脱机更新。


即时更新

即时更新允许快照复制和事务复制订户在订阅服务器上更新已复制数据，并将更改发送至发布服务器和其它订阅服务器。即时更新对于这样的应用程序有益：首选快照或事务发布，且需要偶尔在订阅服务器上进行更新。如果使用即时更新，则发布服务器和订阅服务器必须可用且互相连接。

即时更新选项：

  • 确保不存在冲突。仅当订阅服务器可以执行与发布服务器之间的两阶段提交协议 (2PC) 事务时，才可以对已复制的数据执行插入、更新和删除操作。发布服务器必须接受每次更新，然后更新才能在订阅服务器上进行。因为在事务提交之前对冲突加以检测，所以不会发生冲突。

  • 自动启动两阶段提交 (2PC)。

  • 将提交的更新通过标准快照复制或事务复制机制复制给所有其它订阅服务器。

  • 让订阅服务器继续工作而不必等待将成功的更新传播到其它订阅服务器。

  • 防止要求更新订阅服务器具有分发数据库或日志读取器，避免牵涉到复制发布的管理问题。

  • 每个站点的错误点少于涉及每个订阅服务器的完全 2PC 情况，并且还更加易于升级。

  • 因为不存在冲突，所以没有 ACID 属性损失。

  • 在名为 MSrepl_tran_version 的发布表中注册 uniqueidentifier 列。该列用于跟踪对已复制数据的更改以及在发布服务器上执行冲突检测。添加 uniqueidentifier 列将导致不带列的列表的 INSERT 语句失败，并增加了发布表的大小。

如果在 Microsoft® SQL Server™ 7.0 版中使用了即时更新选项并正在向 SQL Server 2000 升级，则还存在其它升级要求。有关更多信息，请参见复制和升级。


即时更新工作方式

当启用发布以支持即时更新时，如果可将两阶段提交协议 (2PC) 用于发布服务器来执行事务，则订阅服务器可修改已复制的数据。返回发布服务器的 2PC 事务自动完成，因此可以编写应用程序，就象它只在更新一个站点。

在所有参与站点中使用 2PC 时，这种方法的可用性限制很小，因为只需要发布服务器是可用的。在 2PC 下在发布服务器上完成更改以后，更改最终将发布到该发布的所有订阅服务器上。

2PC 由 Microsoft 分布式事务处理协调器 (MS DTC) 管理。如果可以使用 2PC 执行更新，则发布服务器根据分发代理程序调度（如果是快照发布，则在下次快照刷新时）将这些更改传播到所有其它订阅服务器。因为执行更新的订阅服务器已经在本地反映了数据更改，所以用户可以安全地继续对已更新数据进行操作，同时确保发布服务器上的数据也反映所做更改。没有 ACID 属性损失。

使用即时更新的应用程序应能够处理事务中的错误，正如它能够在非复制环境中对唯一性冲突之类的问题进行处理一样。最常见错误是，数据已在发布服务器上进行了更改，而订阅服务器却需要刷新其复本。在很多情况下，首选处理方法是在几秒后重试更新。如果事务成功了，则订阅服务器可以立即使用已更改的值，并知道发布服务器已经在没有冲突的情况下接受更新，且更新最终将传播到该发布的每个订阅服务器。但是，因为发布服务器必须在更新时可用，所以执行更新的订阅服务器不具有完全自治。自治程度高于完全 2PC 情况，在完全 2PC 情况下，当任意站点执行更改时，每个站点都必须可用。

不使用 timestamp 列跟踪更新（在 SQL Server 7.0 中使用该列跟踪更新），而使用 uniqueidentifier 列跟踪更新，该列自动添加到发布中所使用的所有表中。添加该列需要使用 INSERT 语句以获得列的列表。

使用 uniqueidentifier 列 MSrepl_tran_version 代替 timestamps，以提供可靠的方法来检测即使是脱机进行更新时（如排队更新等情况）的冲突。企业中的任何服务器都可以指派一个 uniqueidentifier 列，并且该列不会重复。如果发生一个更新而 uniqueidentifier 列不匹配，则检测到冲突。如果 uniqueidentifier 列匹配，则完成更新。


即时更新组件

使用以下组件支持即时更新：

  • 触发器

  • 存储过程

  • Microsoft 分布式事务处理协调器 (MS DTC)

  • 冲突检测

  • 环回检测
触发器

发布服务器上的更新触发器根据需要对已更新的行的 MSrepl_tran_version 列进行更新。

订阅服务器上的触发器捕获事务，并使用 2PC（由 MS DTC 控制）内的远程存储过程调用提交给发布服务器。使用 CREATE TRIGGER 语句的 NOT FOR REPLICATION 参数创建触发器，以便由分发代理程序应用的更改自身不激发触发器。INSERT、UPDATE 和 DELETE 触发器的逻辑是：

  • 从订阅服务器上所插入或删除的表析取值。

  • 调用 BEGIN DISTRIBUTED TRANSACTION 语句。

  • 执行远程过程以调用发布服务器上的相关存储过程，从插入或删除的表传递值。

  • 管理订阅服务器上的 identity 和 timestamp 值。在即时更新订阅的情况下，发布服务器上生成的这些类型的列的新值作为 2PC 事务的一部分传播到订阅服务器。

  • 如果远程存储过程调用成功，则提交事务，在订阅服务器上和发布服务器上精确反映相同的更改。

    然后发布服务器确保将更改传播到所有其它订阅服务器。否则，回滚事务并向用户返回错误。

    如果订阅某个事务发布并使用即时更新选项，但不初始化订阅，则即时更新触发器不自动应用于订阅服务器。您必须使用 sp_addsynctrigger 在订阅服务器上手动创建触发器。可以使用 sp_script_synctran_commands 在发布服务器上编写即时更新触发器命令，然后当在订阅服务器上运行 sp_addsynctrigger 时使用这些命令。

    当为即时更新订阅或排队更新订阅创建同步触发器时，对 sp_settriggerorder 系统存储过程进行附加调用，以指定 INSERT、UPDATE 和 DELETE 触发器的激发顺序，使这些触发器在同步过程中首先激发。如果已有一触发器设置为首先激发，则将会返回一个错误，订阅将被标记为未激活。如果接收到此错误，则应删除现有的触发器或将启动顺序设置为无。重新启动分发代理程序以便初始快照和触发器可在订阅服务器上应用。

存储过程

仅当在订阅服务器上次接收到更改的复本以后，事务不与发布服务器上进行的更改冲突时，发布服务器上的存储过程才应用这些事务。如果检测到冲突，则拒绝事务并在两个站点上回滚事务。为每个项目都创建 INSERT、UPDATE 和 DELETE 过程。发布服务器上的即时更新订阅存储过程的逻辑是：

  • 插入过程

    尝试插入行。检查 @@ROWCOUNT 和 @@ERROR，并返回触发器调用是成功还是失败。如果需要还可以向订阅服务器返回 identity 值。

  • 删除过程

    尝试删除行，通过 WHERE 子句使用来自删除表的值限定当前行。检查 @@ROWCOUNT 和 @@ERROR，并返回触发器调用是成功还是失败。

  • 更新过程。尝试更新行，通过 WHERE 子句使用来自删除表的唯一索引和 uniqueidentifier 值限定当前行中的唯一索引和 uniqueidentifier 列。检查 @@ROWCOUNT 和 @@ERROR，并返回触发器调用是成功还是失败。如果需要还可以向订阅服务器返回 identity 值。

说明 影响多个行的事务要成功必须使所有的行在两个站点上都予以反映。

Microsoft 分布式事务处理协调器 (MSDTC)

Microsoft 分布式事务处理协调器 (MS DTC) 使用 Transact-SQL 中的 BEGIN DISTRIBUTED TRANSACTION 语句，管理在 Microsoft® SQL Server™ 2000 远程存储过程调用内的订阅服务器和发布服务器之间的两阶段提交操作。

冲突检测

发布服务器存储过程使用 uniqueidentifier 列检测某个行在复制到订阅服务器以后是否已经改变。当订阅服务器请求即时更新事务时，将 uniqueidentifier 值（在订阅服务器上生成）与行中的所有其它列一起传递给发布服务器。在发布服务器的存储过程内，将该值与正在检测的行的当前 uniqueidentifier 值进行比较。如果两个值相同，则该行在复制到订阅服务器以后未进行更改，因而接受事务。如果检测到冲突，则拒绝事务，应用程序应象处理任何事务回滚那样处理该事务。这通常意味着订阅服务器需要与发布服务器上的最新数据更改进行同步，然后才能尝试在本地更新相同的数据。

环回检测

如果某个事务成功应用于订阅服务器和发布服务器，则不必使用标准匿名事务复制机制将更改传播回起源订阅服务器。SQL Server 2000 复制具有环回检测机制以处理这种情况。

用于执行环回检测的信息基于逐个事务进行存储。因此，驻留在带有即时更新订阅的订阅服务器上的不同数据库中的表，或驻留在跨带有即时更新订阅的订阅服务器的不同数据库中的表，不应当在相同事务中进行更新。

警告 使用相同的事务更新驻留在订阅服务器上的不同数据库中的表，或更新驻留在跨订阅服务器（具有即时更新订阅）的不同数据库中的表，将删除控制环回检测所需的信息，并可能导致复制失败。在事务级别上跟踪环回检测。如果该事务涉及多个订阅数据库，则 SQL Server 将多次尝试用订阅服务器名称和数据库名称标记事务。最后的项将重写以前的所有项。


即时更新考虑事项

可以使用 SQL Server 企业管理器启用即时更新，或使用 Transact-SQL 系统存储过程或 SQL-DMO 通过编程来启用即时更新。

即时更新限制

即时更新存在以下限制：

  • 已发布表必须有 uniqueidentifier 列。uniqueidentifier 列 MSrepl_tran_version 自动添加到发布表。如果发布表上已经存在 MSrepl_tran_version 列，则将使用该列。

  • 用于将数据行添加到表中的 INSERT 语句必须包含列的列表。

  • 如果在发布数据库中的同一个表上创建两个或多个项目，然后在相同的订阅数据库中创建这些项目的订阅，则应受下列额外限制：
    • 如果基于同一个表的多个项目位于一个启用了即时更新的发布中，则不能创建该发布的即时更新订阅。否则，将发出警告消息 21293。

    • 如果基于同一个表的多个项目位于不同发布中，并且您希望在相同的订阅数据库中创建所有发布的订阅，则只有一个订阅可以是即时更新订阅。
  • 即时更新与发布服务器的订阅连接（由 sp_link_publication 控制）在创建登录映射时，对 SQL Server 身份验证可使用安全模式 0，对链接服务器定义可使用安全模式 2。发布访问列表 (PAL) 必须至少包括一个 SQL Server 身份验证帐户，除非用户使用安全模式 2 并配置了委托（通过配置委托可以设置 Windows 身份验证使用模式 2）。可以通过委托唤醒调用订阅服务器上的 INSERT、UPDATE 和 DELETE 触发器，以 Windows 用户帐户与发布服务器建立连接。若要设置委托，请参见 sp_addlinkedsrvlogin。

  • 如果快照或事务发布允许即时更新订阅且发布具有列筛选，则不能从发布筛选无默认值的非空列。

  • 使用即时更新订阅的订阅服务器不能将数据再次发布给其它订阅服务器。
订阅服务器上的数据修改

当使用即时更新订阅服务器选项在订阅服务器站点上修改数据时，请考虑下列问题：

  • 订阅服务器不应直接更新 timestamp 或 identity 值。这些值由发布服务器作为发布服务器和订阅服务器之间的 2PC 事务的一部分生成。默认约束应用于订阅服务器上的这些列。

  • 订阅服务器不能更新或插入 text 或 image 值，因为无法在触发器内从插入或删除的表读取这些值。同样，订阅服务器不能使用 WRITETEXT 或 UPDATETEXT 更新或插入 text 或 image 值，因为这些数据由发布服务器重写。但您可以将 text 和 image 列分区到独立的表中，并在一个事务内修改这两个表。如果需要在订阅服务器上对 text 或 image 列更新，则可以使用合并复制对这些值进行同步处理。如果所有的更新都按照这条准则进行，则可以确保无冲突，其原因在于除非更新了主表（它由 2PC 保护），否则 text 或 image 表的更新无法发生。

  • 当环回检测有效时，已修改的行不发送回起源订阅服务器（因此减少了开销）。

  • 建议订阅服务器表至少有一个唯一索引，且最好有用于快照复制的主键。对于事务复制这是必需的。

  • 尽管不带即时更新的快照复制不要求在表中使用主键，但带有即时更新的快照复制或带有即时更新的事务复制要求在发布表上使用主键。（事务复制始终要求在发布表上使用主键）。

  • 如果水平筛选订阅数据库，且分区中有一些行，这些行在订阅服务器上的位置与由发布服务器传播到订阅服务器的数据的位置不同，且该分区不在发布服务器上，则订阅服务器无法更新预先存在的行。在试图更新这些行时返回错误。应当先将这些行从表中删除，然后再次添加。
配置模式

对于从同步触发器回到发布服务器的 2PC 连接，即时更新选项既支持动态 RPC 模式，也支持静态 RPC 模式。在动态 RPC 模式中，同步触发器使用提供的服务器名称、登录和密码动态连接到发布服务器。有些用户不需要静态定义的从订阅服务器到发布服务器的链接服务器/远程服务器连接，而动态 RPC 模式为这些用户提供了增强的安全保障。安装强制订阅时，该模式也易于使用，因为发布服务器不必在订阅服务器上预定义。在静态 RPC 模式中，同步触发器通过一个静态定义的服务器名称（在 sysservers 表中定义为链接服务器或远程服务器）连接到发布服务器。管理员将该条目添加到订阅服务器上。

创建强制订阅或请求订阅时，配置模式自动设置：

  • 当在 SQL Server 企业管理器中或在 sp_addsubscription 存储过程中使用强制订阅向导安装强制订阅时，默认配置在订阅服务器上使用动态 RPC。动态 RPC 默认使用不带密码的 sa 登录。这样做可以避免通过网络发送登录或密码，而且应当使用 sp_link_publication 在订阅服务器上进行更改。

  • 当在 SQL Server 企业管理器中使用请求订阅向导安装请求订阅时，用户可选择所需的配置模式。如果选择静态 RPC，发布服务器必须在订阅服务器上配置为链接服务器或远程服务器。如果选择动态 RPC，则必须提供登录和密码，同步触发器将用它们连接到发布服务器上。

  • 当使用存储过程建立请求订阅时，需要在调用订阅服务器上的 sp_addpullsubscription 后，显式调用 sp_link_publication。
用户定义的触发器

如果向已发布并允许即时更新的表添加用户定义的级联触发器，则既可以将触发器放置在发布服务器上，又可以放置在订阅服务器上。在发布服务器上添加触发器不需要特殊编程注意事项。例如，可能有两个表 customer 和 orders，其中 customerid 是 customers 表中的主键，是 orders 表中的外键。可以使用 customers 表上的用户定义触发器级联对 orders 表中的 customerid 的更改。在订阅服务器上更新 customers 表中的 customerid，导致即时更新触发器将更新传播到发布服务器。当更新应用于发布服务器时，在发布服务器上激发用户定义的触发器，并级联对发布服务器上的 orders 表的更新。当分发代理程序运行时，对 orders 表的更新向下传播到订阅服务器。已级联的更改在订阅服务器上准确反映，但存在一些滞后时间，因为 orders 表未立即更新。

如果应用程序要求订阅服务器上已级联的表立即反映所级联的表中的更改（即避免到发布服务器的来回旅程的滞后时间），那么还可以在订阅服务器上添加级联触发器。但是，当在发布服务器和订阅服务器上均添加用户定义的触发器时，两组触发器必须都使用 NOT FOR REPLICATION 选项创建。在 NOT FOR REPLICATION 选项处于活动状态下，对订阅服务器上的一个表的更新通过用户定义的触发器级联到其它表，然后通过各表上的即时更新触发器传播到发布服务器。因为发布服务器上的用户定义的级联触发器标记为 NOT FOR REPLICATION，所以这些触发器不激发。

说明 SQL Server 2000 复制支持触发器从发布服务器上的表自动传输到订阅服务器上的表；但是，它们在订阅服务器上不会自动标记为 NOT FOR REPLICATION，这必须手工完成。如果触发器在发布服务器上定义为 NOT FOR REPLICATION，则它们将标记为 NOT FOR REPLICATION。

还可以添加用户定义的触发器以更新当前正在修改的行中的列。插入和更新触发器的编程具有挑战性，因为即时更新触发器可能也需要更新相同的行。例如，即时更新触发器必须插入新的 timestamp 或 identity 值，新的 timestamp 或 identity 值是作为两阶段提交事务的一部分从发布服务器接收的。

如果用户定义的触发器和即时更新触发器都将更新应用于同一行，且您尚未加入子程序来处理特殊情况，则事务可能终止。在没有特殊处理的情况下，更新进程以循环的形式继续，即每个触发器更新启动另一个触发器，直到达到最大嵌套级 (32)，然后事务终止。

为避免这种情况，必须允许即时更新插入和更新触发器在任意用户定义的触发器之前激发。用户定义的触发器应当确定其是否在即时更新触发器的环境中激发，如果是，则应终止而不是激发。将下列代码行添加到触发器的开始部分：

DECLARE @retcode int, @trigger_op char(10)
EXEC @retcode = sp_check_for_sync_trigger @table_id, @tablename sysname, @trigger_op OUTPUT
IF @retcode = 1 RETURN


排队更新

排队更新允许快照复制和事务复制订阅服务器不必与发布服务器建立活动的网络连接，即可修改已发布的数据。

当通过启用排队更新选项来创建发布，且订阅服务器在已发布数据上执行 INSERT、UPDATE 或 DELETE 语句时，更改将存储在一个队列中。当网络连接恢复后，在发布服务器上经过排队的事务将进行异步应用。

由于更新异步传播至发布服务器，所以发布服务器或另一台订阅服务器有可能更新同一数据，而在应用更新时会发生冲突。

根据创建发布时设置的冲突解决策略检测和解决冲突。然后使用典型复制机制将事务传播到其它订阅服务器（环回检测避免将更新发送到事务起源的订阅服务器）。

排队更新最适用于这样的应用程序：用户主要读取数据且只偶尔更新数据。订阅服务器大部分时间应当连接，但如果订阅服务器脱机，更新可以不中断地继续进行。

排队更新和合并复制都允许脱机更新，但是两种功能之间存在显著区别。有关更多信息，请参见合并复制或可更新订阅。


排队更新工作方式

当创建一个发布并启用排队更新时，数据修改可以在订阅服务器上进行，然后保存在队列中，直到可以应用于发布服务器并接着传播到其它订阅服务器。队列作为 Microsoft® SQL Server™ 2000 表实现，但在 Microsoft Windows® 2000 中，还可以选择使用 Microsoft 消息队列实现。有关更多信息，请参见排队更新组件。

下图说明触发器、队列和队列读取器代理程序如何一起工作以完成该进程。

  1. 订阅服务器上进行的更新由订阅表上的触发器捕获。触发器将这些更新存储在一个队列中，该队列在默认情况下为 SQL Server 队列。当创建订阅时自动创建触发器。

  2. 如果正在使用 SQL Server 队列，则更新将存储在指定为队列的表中（称为 MSreplication_queue），该表在配置订阅时自动创建。如果使用消息队列 2.0 版，则更新将存储在分发服务器上的消息队列中。当订阅服务器从网络断开连接时，可以继续生成去往其它计算机的消息。消息队列在本地存储消息，并当恢复网络连接时将它们自动发送到分发服务器上的队列。

  3. 队列读取器代理程序将排队事务应用于适当的发布。当使用 SQL Server 2000 队列时，排队事务从存储在订阅服务器上的队列直接读取。当使用消息队列时，排队事务从存储在分发服务器上的队列读取。

  4. 当应用排队事务时，根据创建发布时设置的冲突解决策略检测和解决冲突（如果有的话）。因此，可能生成补偿命令以使用标准事务复制分发进程将事务回滚至订阅服务器，但它们只发送给导致冲突的订阅服务器。

  5. 发布服务器上进行的任何更改根据分发代理程序调度传播到所有其它订阅服务器。


排队更新组件

排队更新所使用的组件有触发器、存储过程、队列和队列读取器代理程序。

触发器

当启用即时更新、排队更新或以排队更新作为故障转移的即时更新时，将触发器附加到订阅服务器上已复制的表。在排队更新的情况下，触发器捕获订阅服务器上启动的事务，然后将事务封装入消息并放置在队列中。这发生在相同的事务内以确保对本地数据库的更新和更新的排队是原子的。

使用 CREATE TRIGGER 语句的 NOT FOR REPLICATION 限定语符创建触发器，以便由分发代理程序应用的更改不会激发触发器。

如果订阅某个事务发布并使用排队更新选项，但不初始化订阅，那么排队更新触发器不自动应用于订阅服务器。相反，必须使用 sp_addsynctrigger 在订阅服务器上手动创建触发器。手工初始同步排队更新订阅将在本主题的后面进行讨论。

当为即时更新订阅或排队更新订阅创建同步触发器时，对 sp_settriggerorder 系统存储过程进行附加调用以指定 INSERT、UPDATE 和 DELETE 的激发顺序，使这些触发器在同步过程中首先激发。如果已有一触发器设置为首先激发，则将会返回一个错误，且订阅将被标记为未激活。如果接收到此错误信息，则应删除现有的触发器或将启动顺序设置为无。重新启动分发代理程序以便初始快照和触发器可在订阅服务器上应用。

存储过程

当创建一个发布并根据默认启用排队更新时，在发布数据库上自动创建存储过程以在已发布的表中插入、更新和删除数据。

存储过程由队列读取器代理程序调用，以将事务应用于订阅服务器、检测冲突以及根据需要生成补偿命令（将这些命令发布到分发数据库，接着传送至订阅服务器）。为每个项目创建 INSERT、UPDATE 和 DELETE 存储过程。

还在发布服务器上创建存储过程，用于将发布服务器上的冲突信息记入日志并将冲突信息发送给相关的订阅服务器（可选）。当检测到冲突时该存储过程由队列读取器代理程序调用。

在队列中存储消息

带有排队更新选项的订阅服务器可以使用 Microsoft® SQL Server™ 2000 队列或 Microsoft Windows® 2000 Server 中的 Microsoft 消息队列 2.0 版作为队列机制。当选择排队更新时，默认使用 SQL Server 2000 队列，该队列对 SQL Server 的所有实例均可用。创建发布以后，可以使用"发布属性"对话框将队列更改为消息队列。这必须在激活发布的任何订阅以前进行。

若要查看哪些行具有正在队列中挂起的更改，请在订阅服务器的订阅数据库中执行 sp_getqueuedrows。

SQL Server 队列

当使用 SQL Server 2000 队列时，每个订阅服务器都有自己的队列，形式为订阅数据库中的 SQL Server 2000 表 (MSreplication_queue)。更新已发布的数据以后，触发器将所有消息存储于 SQL Server 2000 队列中，直到订阅服务器重新连接到网络。为进行更新订阅服务器和发布服务器必须互相连接并可用。

订阅服务器依靠队列读取器代理程序读取和清空队列。队列读取器代理程序读取订阅服务器上的消息，查找修改，并将更改传播到发布服务器。然后在每个订阅服务器上重复该过程。

当需要将排队更新应用于发布服务器时，使用 SQL Server 2000 队列要求三个服务器（订阅服务器、分发服务器和发布服务器）都互相连接并可用。在订阅服务器上进行的更新可以在订阅服务器、分发服务器和发布服务器未互相连接的情况下加以排队。订阅服务器上的 SQL Server 2000 队列可使用 sp_replqueuemonitor 存储过程进行监视。

SQL Server 队列：

  • 适用于所有 SQL Server 平台（Windows 98、Windows NT® 4.0 和 Windows 2000）。

  • 不需要安装其它组件。

  • 对订阅服务器上进行的更新排队时较快。

sp_getqueuedrows 存储过程返回一个结果集，该结果集由用户表中的行组成，而该用户表在队列中有挂起的还未由队列读取器代理程序获取的更新。此过程可用于标识会被认为是尝试性的行。

Microsoft 消息队列

如果在分发服务器和订阅服务器上运行的是 Windows 2000 Server，则可以选择使用 Microsoft 消息队列作为订阅服务器上的队列机制。除 SQL Server 2000 队列可用的功能外，消息队列还提供附加的路由、集中监视和管理功能。

当使用消息队列作为队列机制时，更新封装为消息并在两阶段提交协议 (2PC) 事务下放置在分发服务器上的队列中，该事务由 Microsoft 分布式事务处理协调器 (MS DTC) 管理。

当订阅服务器从网络断开连接时，消息队列将事务作为消息存储在订阅服务器上的高速缓存中，直到它们可以发送给分发服务器上的相应队列为止。必须在订阅服务器上和分发服务器上都启用消息队列。在分发服务器上运行的队列读取器代理程序异步读取排队消息，并将它们作为事务应用于适当的发布。

使用消息队列可提供 SQL Server 2000 队列所没有的优势。除传送功能外，它还提供集中队列管理和监视功能。这对于 SQL Server 2000 队列是不可能的，因为在 SQL Server 2000 队列中，队列在每个订阅服务器分发，没有在分发服务器上合并。

消息队列提供更好的脱机功能，包括在 SQL Server 未运行于订阅服务器的情况下将脱机更改传播到分发服务器上的队列。此外，在更新已发布的数据以后订阅服务器与网络重新连接时，消息队列不要求发布服务器可用。当订阅服务器恢复联机时消息队列自动传播消息，而不必依靠队列读取器代理程序读取和清空队列。当有许多订阅服务器时它也是较好的选择。

需要在每个订阅服务器和分发服务器上安装消息队列。排队更新使用以工作组模式安装在 Windows 2000 上的消息队列。这消除了在 Windows 2000 主域控制器上安装消息队列的需要，应当是首选安装方法，除非有其它的消息队列要求使得不能使用工作组模式（例如，工作组模式的消息队列不允许公用队列，且无法使用消息队列身份验证或加密）。

对于以工作组模式安装的消息队列，请将消息队列安装在分发服务器和订阅服务器上。对于不是以工作组模式安装的消息队列，请将消息队列服务器安装在主域控制器上，将消息队列独立客户端安装在分发服务器和订阅服务器上。

在分发服务器上和订阅服务器上安装消息队列

Windows

Windows NT

队列读取器代理程序

队列读取器代理程序是一个运行在分发服务器上的多线程代理程序。它负责从队列中获取消息并将它们应用于相应的发布。

队列读取器代理程序从每一个订阅服务器上的 SQL Server 2000 队列中读取消息，并将事务应用到发布。当使用消息队列时，队列读取器代理程序读取存储在创建于分发服务器的集中队列中的消息。

默认情况下，队列读取器代理程序使用 SQL Server 代理的安全上下文。当手工配置时，该代理支持发布服务器和分发服务器的集成和标准登录。与分发代理程序和合并代理程序不同，只存在一个队列读取器代理程序的实例来服务于所有的发布服务器和用于给定分发服务器的发布。

请参见

sp_replqueuemonitor


排队更新考虑事项

当使用排队更新时，请考虑下列事项：

  • 只有运行 SQL Server 2000 的订阅服务器支持排队更新。

  • 如果在同一个表中创建两个或多个项目，然后在相同的订阅服务器数据库中创建对这些项目的订阅，则应受下列限制：
    • 如果基于同一个表的多个项目在启用了排队更新的单个发布中，则不能创建该发布的排队更新订阅。

    • 如果基于同一个表的多个项目在不同的发布中，并且想要创建同一数据库中所有发布的订阅，则只有一个订阅可以是排队更新订阅。
  • 发布访问列表 (PAL) 必须包含至少一个 SQL Server 授权帐户。

  • 使用即时更新或排队更新的订户不能在订阅服务器上再次发布已复制数据。

  • 如果订阅服务器上的事务涉及多个数据库，则在发生冲突的情况下只为影响订阅数据库的更新生成补偿命令。

  • 合并发布中所包含的表也不能作为允许排队更新订阅的快照发布或事务发布的一部分进行发布。
在订阅服务器上修改数据

当在订阅服务器上修改已发布的数据时，请考虑下列事项：

  • 订阅服务器不能更新或插入 text 或 image 值，因为无法在触发器内从插入或删除的表读取这些值。同样，订阅服务器不能使用 WRITETEXT 或 UPDATETEXT 更新或插入 text 或 image 值，因为这些数据由发布服务器重写。但您可以将 text 和 image 列分区到独立的表中，并在一个事务内修改这两个表。使用合并复制对这些值进行同步处理。不能确保无冲突，因为如果数据未很好分区的话，会发生 text 或 image 表的更新。

  • 用于将数据行添加到表中的 INSERT 语句必须包含列的列表。

  • 建议订阅服务器表至少有一个唯一索引，且最好有用于快照复制的主键。对于事务复制这是必需的。

  • 尽管不带即时更新的快照复制不要求在表中使用主键，但带有即时更新订阅的快照复制或事务复制要求在发布表上使用主键。尽管快照复制不要求在表中使用主键，但排队更新确实要求使用主键。

  • 当使用排队更新时建议不要对主键列进行更新，因为主键用作所有查询的记录定位器。当冲突解决策略设置为首选订阅服务器时，对主键的更新应谨慎进行。如果对主键的更新在发布服务器和订阅服务器上都进行，则将得到带有不同主键的两行。

例如，如果某行在主键列中的值为"Bill"，且该值在发布服务器上更新为"William"，在订阅服务器上更新为"Will"，那么发布数据库和订阅数据库最终都将得到两行（一个带有主键"William"，另一个带有主键"Will"）。建议将主键更新限制于单个站点（例如，可以通过在订阅服务器上添加更新触发器限制主键更新，该触发器防止对参与主键的列的更新。在应用初始快照之前或之后，均可以使用脚本执行将该触发器添加到任何必要的订阅服务器上）。

  • 不允许对生成副本（例如，格式 UPDATE <column> SET <column> =<column>+1 的更新）的唯一键（包括主键）进行更新，这些更新也会因违反唯一性而被拒绝。这是因为在订阅服务器上所做的设置更新由复制作为受影响的每行的个别 UPDATE 语句进行传播。

  • 如果订阅服务器数据库进行了水平分区，且在分区中有在订阅服务器上存在而在发布服务器上不存在的行，那么订阅服务器将无法更新这些预先存在的行。在试图更新这些行时返回错误。应当先将这些行从表中删除，然后再次添加。
排队更新订阅的手工初始同步

如果对允许排队更新订阅的事务发布进行订阅，但是没有通过 SQL Server 自动初始化订阅，则所有对象（自定义存储过程、更改跟踪触发器和冲突表等）都将不会创建。需要按下列步骤手动创建这些对象：

  1. 编写发布服务器上的表创建脚本，并使用此脚本在 subscription 数据库中创建表。如果手动创建该脚本，应该包括主键约束。

  2. 在 publication 数据库中执行下列存储过程：
    • sp_scriptinsproc（指定 @article_id 参数）。

    • sp_scriptxupdproc（指定 @article_id 参数）。

    • sp_scriptxdelproc（指定 @article_id 参数）。

这些存储过程将为要应用于 subscription 数据库的自定义存储过程生成脚本。在 subscription 数据库中执行这些脚本。通过执行 sp_helparticle 可获得项目 ID 值。

  3. 在 publication 数据库中执行下列系统存储过程：
    • sp_makeconflicttable（指定 @publication 和 @article 参数）。

如果成功，则此存储过程返回 0，而如果不成功，则返回 1。这可以为给定项目的冲突表生成脚本。在 subscription 数据库中执行此脚本。

  4. 在订阅服务器上执行下列系统存储过程：
    • sp_addsynctriggers。有关更多信息，请参见 sp_addsynctriggers。


排队更新冲突的检测和解决

复制

排队更新冲突检测和解决

因为排队更新允许对多个位置上的相同数据进行修改，所以当在发布服务器上对数据进行同步处理时可能会发生冲突。排队更新的冲突检测和解决不同于合并复制时的处理。排队更新时，冲突检测和解决基于维护事务的原子性来进行。出于此要求，可以由用户定义的冲突解决策略的个数与合并复制相比很有限，合并复制为冲突解决提供更灵活的框架，但它是在行级别而不是在事务级别上处理冲突。

当在发布服务器上对更改进行同步处理时，Microsoft® SQL Server™ 2000 检测是否有冲突。然后它按照创建发布时所选择的解决策略来解决冲突。

冲突检测和解决会是费时且消耗大量资源的过程，最好通过创建数据分区以便不同的订阅服务器修改数据的不同子集，从而将应用程序中的冲突减到最小，以防由于发生冲突而使得用户的工作无法提交。

检测冲突

当创建一个发布并启用排队更新时，SQL Server 2000 向基础表添加带有默认值 newid() 的 uniqueidentifier 列 (MSrepl_tran_version)。当在发布服务器或订阅服务器上更改了已发布的数据时，该行接收一个新的全局唯一标识符 (GUID) 以表示存在新的行版本。队列读取器代理程序在同步过程中使用该列来确定是否存在冲突。

队列中的事务保留老的和新的行版本值。当事务应用于发布服务器时，将来自事务的 GUID 和发布中的 GUID 进行比较。如果存储在事务中的老的 GUID 与发布中的 GUID 相匹配，则更新发布并将订阅服务器所生成的新的 GUID 赋给该行。通过来自事务的 GUID 更新发布，使得发布中的行版本与事务中行版本相匹配。

如果存储在事务中的老的 GUID 与发布中的 GUID 不匹配，则检测到冲突。发布中的新的 GUID 指出存在两个不同的行版本：由订阅服务器提交的事务中的行版本和存在于发布服务器上的新的行版本。在这种情况下，在对本订阅服务器事务进行同步处理以前，另一个订阅服务器或发布服务器更新了发布中的同一行。

与合并复制不同，GUID 列并非用于标识行本身，而是用于检查行是否发生了更改。

解决冲突

当创建使用排队更新的发布时，冲突解决程序指示队列读取器代理程序如何处理同步过程中遇到的同一行的不同版本。默认情况下设置首选发布服务器冲突解决程序。只要不存在对发布的订阅，便可以在创建发布以后更改冲突解决策略。

可供选择的冲突解决程序有：

  • 首选发布服务器且将订阅重新初始化

  • 首选发布服务器

  • 首选订阅服务器

这些冲突解决程序以不同程度维护订阅服务器上的事务一致性。重新初始化订阅服务器提供了最高程度的事务一致性，而首选订阅服务器提供了最低程度的事务一致性。

记录冲突并可以使用冲突查看器来查看冲突。当将排队更新用于快照复制时，冲突解决策略限于使用重新初始化订阅服务器或首选发布服务器。首选订阅服务器冲突解决策略不可用。

重新初始化订阅服务器

重新初始化订阅服务器以解决冲突能够在订阅服务器上维护严格的事务一致性，但当发布包含大量数据时将十分费时。

当队列读取器代理程序检测到冲突，将拒绝队列中所有剩余的事务（包括冲突中的事务），并且将订阅服务器标记为重新初始化。为该发布生成的下一个快照将由分发代理程序应用于订阅服务器。

首选发布服务器

当冲突解决设置为首选发布服务器时，事务一致性的维护基于发布服务器上的数据。冲突的事务在启动该事务的订阅服务器上回滚。

队列读取器代理程序检测冲突，且生成补偿命令并通过在分发数据库中发布这些命令将其传播到订阅服务器。然后分发代理程序将这些补偿命令应用于冲突事务的起源订阅服务器。补偿操作更新订阅服务器上的行以与发布服务器上的行相匹配。

在应用补偿命令以前，可以读取最终将回滚到订阅服务器的事务的结果。这等同于脏读（读取未提交的隔离级别）。可能发生的后续非独立事务无补偿。但是遵守事务边界，一个事务内的所有操作或者提交，或者回滚（在冲突的情况下）。

首选订阅服务器

首选订阅服务器策略下的冲突检测意味着首选要更新发布服务器的上一次订阅服务器事务。在这种情况下，当检测到冲突时，仍使用由订阅服务器发送的事务，并更新发布服务器。该策略适合于此类更改不危害数据完整性的应用程序。

设置排队更新冲突解决策略

企业管理器

企业管理器

查看冲突

所有冲突记录在发布服务器上的冲突表中。这些冲突还可以传播到提交冲突事务的订阅服务器，并在其上进行查看。这可以通过选择允许分散冲突报表的发布属性来完成。当将排队更新用于快照复制时，分散冲突报表不可用，因此只可在发布服务器上查看冲突。

排队更新可用的冲突查看器使您可以查看发布服务器或订阅服务器上的冲突，但与合并复制不同，它不允许重新提交行。

允许分散冲突报表

企业管理器

企业管理器

查看冲突

企业管理器

企业管理器

请参见

合并复制冲突的检测和解决


排队更新和标识范围

通常对于快照复制和事务复制（只读或使用即时更新），如果发布表包含带有 identity 数据类型的列，则标识属性不传播到订阅服务器。

identity 属性用于自动提供数据的下一个数字值（例如 Customer ID 或 Order ID 之类的列）。当使用即时更新时，发布服务器决定该值，并且作为由订阅服务器起始的 2PC 事务的一部分，该值在发布服务器和订阅服务器间进行同步处理。

对于排队更新和以排队更新作为故障转移的即时更新，标识值必须在订阅服务器上指派，因为订阅服务器可能脱机，而且订阅服务器上的更新可能发送到队列中。在这种情况下，发布服务器将不能立即指派标识值。因此，当初始快照应用于订阅服务器时，标识属性也将加以传播。

为避免不同的订阅服务器指派相同的标识值，可以为各订阅服务器定义标识范围。当定义标识范围时，只允许一个订阅服务器指派特定范围内的值。

可以使用自动标识范围（SQL Server 2000 复制为您处理标识范围的指派）来管理标识值，或者可以使用检查约束和 Transact-SQL CREATE TABLE 语句的 IDENTITY 属性上的 NOT FOR REPLICATION 选项手工设置标识范围。

有关处理复制中的标识值的更多信息，请参见复制数据考虑事项。

如果使用可连接的订阅数据库功能，并且订阅数据库订阅的发布允许带有自动标识范围项目的排队更新，则在连接订阅数据库以后，需要运行分发代理程序以获得订阅服务器上的新的标识范围。有关更多信息，请参见可连接的订阅数据库。

请参见

带有即时更新和排队更新的标识范围


在即时更新中将排队更新作为故障转移

如果预期发布服务器和订阅服务器相互连接，但不希望当由于系统故障导致网络断开连接时丧失在订阅服务器上进行更新的能力，则可以使用以排队更新作为故障转移的即时更新。以排队更新作为故障转移的即时更新使您得以使用即时更新并在需要时切换到排队更新。

在这种情况下，在启用排队更新故障转移以前，2PC 用于将订阅服务器上进行的更新传播到发布服务器。在启用了排队更新故障转移以后，来自订阅服务器的事务封装入消息并发送到队列中。异步记录事务，并且当重新建立连接时将事务应用于发布服务器。

可以随时调用排队更新故障转移，但调用之后，在订阅服务器和发布服务器（消息队列情况下为分发服务器和发布服务器）相互连接，并且队列读取器代理程序已经将队列中的所有挂起消息应用于发布服务器之前，不能故障回复为即时更新。因为可能很容易修复妨碍即时更新的问题（例如断开连接的硬件），所以不自动调用排队更新。可能不需要或不希望分配资源以从排队更新切换回即时更新（这要求清空队列）。

将使用按需同步创建的请求订阅自动地添加到 Windows 同步管理器。通过打开订阅属性，然后在"同步"选项卡上选中"使用 Windows 同步管理器对该订阅进行同步"复选框，您可以将没有使用按需同步的请求订阅添加到 Windows 同步管理器。

启用以排队更新作为故障转移的即时更新

企业管理器

企业管理器

从即时更新切换到排队更新

企业管理器

企业管理器

Transact-SQL

Transact-SQL

Windows

Windows

请参见

带有即时更新和排队更新的标识范围

sp_helpreplfailovermode

sp_setreplfailovermode


转换已发布的数据

转换订阅（可用于快照复制或事务复制）可调节数据转换服务 (DTS) 的数据移动、转换映射和筛选功能。通过在复制拓扑中使用转换订阅，可以基于个别订阅服务器的要求自定义和发送发布的数据。

如何使用转换订阅的示例包括：

  • 基于每个订阅服务器创建发布数据的列和水平分区（自定义数据分区）。

  • 创建数据转换，例如数据类型映射（如整型到实数数据类型）、列操作（如串联名字列和姓氏列）、字符串操作、使用函数等。

在创建发布时设置允许转换的选项。设置了该选项并且生成了复制 DTS 包以后，发布的订阅服务器可以附加一个 DTS 包，并将该包作为复制数据流的一部分加以合并。Microsoft® SQL Server™ 2000 和 OLE DB 订阅服务器支持该功能（不支持 ODBC 订阅服务器）。

通过复制向导或编程（如使用 Microsoft Visual Basic®）为复制创建 DTS 包。还可以通过使用 DTS 设计器自定义一个 DTS 包以用于订阅服务器。

可转换的订阅主题假定您熟悉 DTS。有关 DTS 概念、DTS 编程和将 DTS 用作数据仓库策略的一部分的信息，请参见 DTS 基础。


如何转换已发布数据

当发布配置为允许 DTS 转换时，允许订阅服务器指定 DTS 包作为创建订阅的一部分。下面的关系图说明将数据应用于订阅服务器以前快照和后续增量更改如何进行转换。

快照

在应用快照的进程中，分发代理程序从 msdb 数据库装载复制 DTS 包（在 OLE DB 请求订阅服务器的情况下，装载保存的 .dts 文件）。用于 DTS 的 SQL Server 复制 OLE DB 提供程序将快照数据转换为 OLE DB 行集，该行集用于驱动 DTS 数据驱动的查询任务，此任务在将数据应用于订阅服务器以前执行所有指定的转换或筛选操作。这是 OLE DB 提供程序的一种特殊用途（计划只由复制使用），而不是 OLE DB 提供程序的常规用途。

当将 DTS 包加入复制数据流时，将发生下列事件和进程：

  • 创建一个 DTS 包，以快照 .bcp（大容量复制）文件作为包的源输入。

  • 由 DTS 包执行 SQL 任务中的脚本创建订阅服务器表。

  • 复制 DTS 包中所使用的数据驱动的查询任务使用 Transact-SQL INSERT 语句移动数据。当应用或重新初始化快照时，由 DTS 包对每行数据执行 INSERT 语句的等价物。

对于允许 DTS 转换的发布，以字符模式生成快照 .bcp 数据文件，因为本机格式 .bcp 文件不能用于 DTS。

只要发布允许转换已发布数据，则异类订阅服务器可对发布（以字符模式为此发布创建了快照）进行订阅。

增量更改

当发布服务器上发生增量更改时，分发代理程序检索需要从分发数据库复制的事务，并以与应用快照时所描述的相同方式处理这些事务。但是在这种情况下，数据源是 MSrepl_commands 表而不是 .bcp 字符模式数据文件。对于增量更改，数据驱动的查询任务除处理 INSERT 以外还处理 UPDATE 和 DELETE，并根据增量更改的类型和为它指定的事务映射，来应用事务内的各个语句的增量更改（例如，如果更改映射到带有 INSERT、UPDATE 或 DELETE 语句的事务的话）。

说明 当向允许转换已发布的数据的发布添加列或从这样的发布除去列时，DTS 包将需要重新生成。


使用复制向导创建可转换的订阅

使用复制向导创建可转换的订阅需要下列步骤：

  1. 使用创建发布向导创建一个新的快照发布或事务发布，并启用此发布允许可转换的订阅。

  2. 使用转换已发布数据向导（右击允许数据转换的发布并选择"定义已发布数据的转换"命令即可使用该向导）生成复制 DTS 包（定义分区中的列和行，并映射转换）。

  3. 使用强制订阅向导或请求订阅向导，创建包含现有复制 DTS 包的订阅来转换已发布的数据（创建订阅时该 DTS 包必须存在）。当创建可转换的订阅时，从标记为复制的现有 DTS 包中选择 DTS 包。

创建了复制 DTS 包以后，高级用户可以在 DTS 设计器中编辑 DTS 包，以便为单个订阅服务器自定义 DTS 包。

说明 必须在创建发布时使订阅可以使用 DTS 包，而不能修改现有发布以使用 DTS 包。

创建可转换的订阅

企业管理器


使用可转换的订阅创建自定义数据分区

在 Microsoft® SQL Server™ 的早期版本中，如果需要为订阅快照发布或事务发布的不同订阅服务器创建不同的数据分区，则必须为每个订阅服务器创建不同的发布。而通过 SQL Server 2000，可以使用可转换的订阅来为单个发布创建自定义数据分区，这些分区基于各个订阅服务器的要求提供不同的数据。可以基于每个订阅服务器创建行数据和列数据的分区，此时一个发布支持多个订阅。

创建带有可转换订阅的自定义数据分区的一个方法是使用转换已发布数据向导。创建发布并为其启用可转换订阅以后，在转换已发布数据向导中作为生成复制 DTS 包的进程的一部分创建数据分区。生成数据分区所需要的大部分工作在该向导的"列映射和转换"页上完成。


定义垂直分区

转换已发布数据向导的"定义转换"页列出已发布的表。若要垂直筛选已发布的数据，请通过单击该页上的某个表的转换（"..."）按钮选择该表，然后在"列映射和转换"页上，单击"列映射"选项卡，并清除想要从分区中排除的所有列。


定义水平分区

使用可转换的订阅，可以基于每个订阅服务器排除某些行。若要为可转换订阅水平对数据分区，必须：

  • 通过选择需要水平 DTS 分区的每个项目的属性中的"为水平 DTS 转换脚本提供支持"选项，使发布可以使用水平 DTS 分区。

  • 使用转换已发布数据向导生成 DTS 包。转换已发布数据向导的"定义转换"页列出已发布的表。若要对已发布数据水平分区，请通过单击该页中的某个表的转换（"..."）按钮选定该表。在后续的"列映射和转换"页上，单击"转换"选项卡。"转换"选项卡包含一个编辑框，使用该框编写定义水平分区的 Microsoft® ActiveX® 脚本。

  • 在 DTS 包内加入写入 DTS 对象模型的 Microsoft ActiveX 脚本。ActiveX 脚本需要指定筛选准则，并应能够检查下列情况：
  1. 新插入的行是否需要传播到订阅服务器。

  2. 发布服务器上更新的行是否不再满足分区准则并需要在订阅服务器上删除。

  3. 发布服务器上更新的行是否满足筛选准则并需要在订阅服务器上插入。

通过使用 UPDATE 的 XCALL 语法（这确保更新以后行的之前和之后值）可以支持步骤 2 和 3。这使 ActiveX 脚本可以确定行是否正在移入或移出分区。

用来定义水平分区的 ActiveX 脚本需要遵照以下示例中解释的几条准则。将只须提供两个函数 IsInPartition() 和 Transform()。不需要更改 Main() 函数。

还可以使用系统存储过程 sp_addarticle 和 sp_changearticle 为允许数据转换的快照发布或事务发布指定水平分区。

如果发布允许可转换订阅，则可将 sp_addarticle 的 @status 参数值设置为 64 以表示项目支持 DTS 水平分区。如果未设置参数，则当行移入或移出发布服务器上的更新所引起的分区时，在订阅服务器上插入或删除行是不可能的。如果设置了此状态，则已更新行之前的图像将由日志读取器代理程序发送给 distribution 数据库，然后再发送给分发代理程序中的 DTS 包。这将增加网络流量，所以应慎重使用。

如果发布允许数据转换，则 sp_changearticle 接受状态项目属性的 'dts horizontal partitions' 和 'no dts horizontal partitions' 值。当有活动订阅时（已为这些订阅生成了快照），不允许对属性进行更改。如果发布允许即时更新，则需要在更改属性后运行快照代理程序。先前生成的快照将过时。

自定义数据分区的验证

使用可转换订阅排除行或列并创建水平和垂直分区，意味着订阅服务器上的数据将与发布服务器上的数据不同。ROWCOUNT 和 CHECKSUM 验证将报告差异。通常情况下您不希望对这些订阅服务器运行验证。

合并复制可用的动态筛选没有该限制，其原因在于将验证与定义分区的 SQL Server 视图进行比较。

示例

若要只包含姓以字母 A 到 D 开头的客户，可以使用下列 Microsoft Visual Basic® 脚本版代码：

Function Main()
   '  If the current source data is the old values of the row before an update, verify if the old row is in the partition or not.
   '  ReplicationChangeType values:
   '   1 = Insert. Source data is from a row that was inserted at the source.
   '   2 = Update. Source data is from a row that was updated at the source. The data are values before the update.
   '   3 = Delete. Source data is from a row that was deleted at the source.
   '   4 = Before Update. Source data is from a row that was updated at the source. The data are values before the update.

   If DTSGlobalVariables("ReplicationChangeType").Value = 4 Then
   OldRowInPartition = IsInPartition()
   Main = DTSTransformStat_SkipRow
   Else    'Error check to prevent users from forgetting to enable the article for DTS horizontal partition.
   If DTSGlobalVariables("RelicationChangeType").Value=2 and IsEmpty(OldRowInPartition)=True Then
      Err.Raise 1, "Replication DTS ActiveX Script", "The article does not support DTS horizontal partitions."
   End If
If IsInPartition() Then
   'Set default return status, which means using the query type set by the replication process.
   Main = DTSTransformStat_OK
   Transform

   ' If it is an update, test to see if the row has just moved into the partition. If so, overwrite the query type to insert from update.
   If DTSGlobalVariables("ReplicationChangeType").Value = 2 And _
      Not OldRowInPartition Then
   Main = DTSTransformStat_InsertQuery
   End If
   Else

   ' If it is an update, test to see if the row has just moved out of the partition.
   ' If so, overwrite the query type to insert from update.
   If DTSGlobalVariables("ReplicationChangeType").Value = 2 And _
      OldRowInPartition Then
   Transform
   Main = DTSTransformStat_DeleteQuery
   Else
   Main = DTSTransformStat_SkipRow
   End If
   "
   End If
   End If
   End Function

Function Transform()
      DTSDestination("CustID") = DTSSource("CustID")
      DTSDestination("LName") = DTSSource("LName")
      DTSDestination("FName") = DTSSource("FName")
      DTSDestination("Item") = DTSSource("Item")
      DTSDestination("SaleAmt") = DTSSource("SaleAmt")
End Function
   Function IsInPartition()
   ' In partition if the first char is uppercase and begins with A, B, C or D.
    If Left(DTSSource("LName"), 1) <= "D"  Then
   IsInPartition = True
   Else
   IsInPartition = False
   End If
   End Function


使用分布式代理程序创建有效的自定义分区

当使用可转换的订阅创建数据分区时，建议使用强制订阅。如果打算使用可转换的请求订阅，则可以通过在使用 DCOM 的分发服务器上而不是在订阅服务器上运行分发代理程序，来减小通过网络发送的数据量。

该功能的优势是，筛选任务发生在分发服务器上，并且只将包含在分区中的数据通过网络发送。如果分发代理程序位于每个订阅服务器上，则所有已发布数据将在订阅服务器上进行筛选以前通过网络传播。远程代理程序激活最好工作在 Microsoft® Windows® 2000 上，并且在使用 Windows 98 和 Windows NT® 4.0 时需要附加的配置。有关为分布式请求代理程序配置复制的信息，请参见远程代理程序激活。


使用带有数据转换的可转换订阅

可以使用可转换订阅在发布服务器和订阅服务器之间进行基本数据转换和列操作，包括：

  • 更改数据类型（主键列的数据类型除外）。

  • 重命名列。

  • 串联列。

  • 从列析取子串，或向列添加字符。

  • 对列值应用函数。

在转换已发布数据向导中的"列映射和转换"页上的"转换"选项卡上，使用写入 DTS 对象模型的 Microsoft® ActiveX® 脚本映射转换（与定义分区时相同）。使用脚本代码，在 ActiveX 脚本编辑框中指定转换。例如，若要将已发布数据的第一个名称列和最后一个名称列串联为订阅服务器中的一个名称列，可以使用下列 Microsoft Visual Basic® 脚本版代码（函数的第二行显示了列串联）：

Function Main()
   DTSDestination("CustID") = DTSSource("CustID")
   DTSDestination("Name") = DTSSource("LName") & " " & DTSSource("FName")
   DTSDestination("Item") = DTSSource("Item")
   Main = DTSTransformStat_OK
End Function


DTS 包详细信息

使用包含 DTS 自定义任务的特定配置、连接设置和工作流的数据转换服务 (DTS) 包创建可转换订阅。

连接
  • 为连接分发数据库和向 DTS 包提供已发布数据（源连接），使用一种特殊的 OLE DB 提供程序：用于 DTS 的 Microsoft SQL Server 复制 OLE DB 提供程序。当创建可转换订阅时，该提供程序自动安装在 DTS 包中，且不能更改。该提供程序只可用于可转换订阅。

    从 DTS 包到订阅服务器的连接（目的连接）不使用用于 DTS 的 Microsoft SQL Server 复制 OLE DB 提供程序，它使用连接到订阅服务器所需的任何 OLE DB 提供程序。例如，可能使用用于 SQL Server 的 Microsoft OLE DB 提供程序将已转换的数据发送到 Microsoft® SQL Server™ 2000 订阅服务器。

  • 只有 SQL Server（用于 SQL Server 的 Microsoft OLE DB 提供程序）订阅服务器和其它 OLE DB 订阅服务器可以使用可转换订阅；ODBC 订阅服务器无法使用可转换订阅。
包存储

通过复制创建的 DTS 包在默认情况下保存为 DTS SQL Server 包（一个 DTS 保存选项，它将包保存在 msdb 数据库中的本地 SQL Server 表中）；但是包还可以保存为 DTS 结构化存储 (.dts) 文件。用于可转换订阅的包不能以其它可用的 DTS 保存格式（知识库、Microsoft Visual Basic® 脚本文件、Visual Basic .bas 文件等）保存。

包安全性

DTS 包只可以由以 sysadmin 角色操作的用户或包所有者读取或重写。因此，分发代理程序需要在分发服务器或订阅服务器站点上的 sysadmin 帐户或包所有者帐户下运行。可选包密码存储在分发服务器上的 MSDistribution_agents 内，或存储在 MSSubscription_properties 表中。如果包存储在分发服务器上，则所有发布访问列表 (PAL) 用户将具有为发布上的订阅定义的包密码的访问权限。如果包存储在订阅服务器上，则订阅服务器数据库的 db_owner 的成员具有访问权限。

包组件

用于可转换订阅的 DTS 包由以下几个 DTS 对象组成：

  • 订阅服务器（多个订阅服务器共享相同的连接）和发布服务器的连接。发布服务器的连接始终为用于 DTS 的 Microsoft SQL Server 复制 OLE DB 提供程序数据源。每个项目需要不同的发布服务器连接。

  • 一个或多个执行 SQL 任务。这些任务至少包括为每个已发布的项目按照项目创建表脚本。

  • 数据驱动的查询任务。该任务能够使用在订阅服务器上正确执行请求所需的数据移动操作匹配不同类型的复制更改请求（INSERT、DELETE、UPDATE）。每个项目的 DTS 包中都需要不同的数据驱动的查询任务。为使数据移动能够进行，目的列值必须绑定到 INSERT、DELETE 和 UPDATE 语句中的参数。数据驱动的查询任务处理所有通过基础数据抽取从分发数据库到订阅服务器的数据移动。对于快照，使用 InsertQuery 属性。

  • 如果稍后在 DTS 设计器中通过添加 Microsoft ActiveX® 脚本转换自定义了复制 DTS 包，则脚本中指定的返回状态必须更改为：
    Main = DTSTransformStat_OK
  • 由分发代理程序设置全局变量 ReplicationChangeType，以表示特定行的更改类型，该变量可以通过编程来访问。下面是可用的更改类型。
    更改类型 | 值 | 对策
    INSERT | 1 | 源数据来自在源处插入的行。
    UPDATE | 2 | 源数据来自在源处更新的行。数据是更新后的值。
    DELETE | 3 | 源数据来自在源处删除的行。
    BEFORE UPDATE | 4 | 源数据来自在源处更新的行。数据是更新前的值。这用于水平分区。

    可以选择声明全局变量。当使用全局变量时，变量值由分发代理程序设置。全局变量可以用于 ActiveX 脚本或其它转换服务器，以确定与当前行相关联的更改类型。下面是示例 Microsoft Visual Basic 代码，可以使用它来声明和使用该全局变量：

    Dim oConnProperty As DTS.OLEDBProperty
Dim gVar As Integer
Dim oGlobal As DTS.GlobalVariable
Set oGlobal = goPackage.GlobalVariables.New("ReplicationChangeType")
oGlobal.Name = "ReplicationChangeType"
oglobal.Value = 0
goPackage.GlobalVariables.Add oGlobal
Set oGlobal = Nothing
调试 DTS 包中的 ActiveX 脚本

可以调试可转换订阅 DTS 包中的 ActiveX 脚本。若要调试脚本，请进行以下操作：

  • 在"数据转换服务包属性"对话框中打开调试。

  • 从命令行或 ActiveX 控件运行分发代理程序。请不要在 SQL Server 代理 NT 服务下运行分发代理程序。

有关如何调试脚本的更多信息，请参见调试 ActiveX 脚本。

启用实时调试

企业管理器


限制和考虑事项

使用可转换订阅的限制和考虑事项包括：

  • 可转换订阅的快照数据仅限于字符模式；无法对本机格式（通常应用速度更快）使用数据转换服务 (DTS)。

  • 在为可转换订阅启用发布后，将无法禁用该选项；要禁用该选项，必须删除现有发布并创建新的发布。

  • 不能将可更新事务订阅服务器（双向事务更新）或排队更新订阅服务器功能与可转换订阅（转换沿一个方向映射：从发布服务器到订阅服务器）一起使用。

  • 如果更改了现有 DTS 包，且分发代理程序运行于连续模式，则分发代理程序必须关闭并重新启动，以使包更改生效。

  • 尽管创建可转换订阅会创建一个 DTS 包，但是这种类型的 DTS 包不能在复制外执行（从 DTS 设计器或命令行）。

  • 必须具有执行 DTS 包的适当访问权限，才能使用可转换订阅。

  • 将 DTS 转换引入复制数据流可能会影响性能。性能通常比将数据发送到没有 DTS 包的订阅服务器略慢。

  • 如果通过使用"发布属性"对话框的"筛选列"选项卡上的"添加列"或"除去列"按钮，或者通过使用 sp_repladdcolumn 或 sp_repldropcolumn 向已发布的表添加列或从该表除去列，则还需要除去并重新创建 DTS 包，以反映对元数据的更改。

  • WRITETEXT 和 UPDATETEXT 语句不能用于更新数据类型为 text、ntext 或 image 的列。


可选同步伙伴

要合并发布的订阅服务器可与订阅起源所在的发布服务器以外的其它服务器进行同步。与备用伙伴进行同步为订阅服务器提供这样的能力：即便主发布服务器不可用，也可同步数据。当移动订户可以访问与可选同步伙伴的更快或更可靠的网络连接时，该功能也十分有用。

以下是使用可选同步伙伴时的要求：

  • 该功能只在合并复制中可用。

  • 可选同步伙伴必须具有订阅所需的数据和架构。

  • 建议创建于备用服务器的发布应是创建于起始发布服务器的发布的克隆。

  • 发布属性必须指定订阅服务器可以与其它发布服务器同步。

  • 对于署名订阅（对发布服务器非匿名的订阅），订阅服务器必须在可选同步伙伴处启用，以便订阅服务器可以与该发布服务器进行数据同步。如果未启用，则合并代理程序将自动在发布服务器上添加订阅条目。

  • 对于署名订阅，将在可选同步伙伴处自动添加订阅，所添加订阅带有与主发布服务器处的订阅相同的特性。


可选同步伙伴工作方式

若要启用可选同步伙伴，请创建一个发布，然后修改其属性以允许订阅服务器与备用伙伴进行同步，或者请使用 SQL-DMO 或 Transact-SQL 系统存储过程创建启用了该属性的发布。接下来，请创建带有按需同步选项的请求订阅。

当需要使用备用伙伴同步数据时，可以使用 Windows 同步管理器、SQL Server 企业管理器或 SQL Server 合并复制 ActiveX® 控件，并从可用可选同步伙伴的列表中选择一个备用伙伴。当同步已发布的数据时，订阅起源的发布服务器是默认发布服务器。但是可以在 Windows 同步管理器中选择指定另一个同步伙伴作为默认发布服务器。

如果使用署名订阅，则必须在可选同步伙伴处启用订阅服务器，并在可选同步伙伴处创建与原订阅相同的订阅。

当订阅服务器将它的已发布数据与可选同步伙伴处的数据合并时，将进行检查以验证订阅服务器登录存在于发布访问列表 (PAL) 中，并确保订阅服务器在可选同步伙伴处启用（对于署名订阅）。

当使用匿名订阅的订阅服务器第一次与可选同步伙伴进行同步时，该订阅记录在订阅数据库中。该订阅将具有与主发布服务器处的订阅相同的特性。

启用订阅服务器以与可选同步伙伴进行同步

企业管理器

企业管理器

在可选同步伙伴处启用订阅服务器（对于署名订阅）

企业管理器

企业管理器

与可选同步伙伴对强制订阅进行同步处理

企业管理器

企业管理器

与可选同步伙伴对请求订阅进行同步处理

企业管理器

企业管理器

Windows

Windows NT

有关使用 SQL Server 合并复制 ActiveX 控件与可选同步伙伴进行同步的信息，请参见 SyncToAlternate 属性。


优化同步

当确定最近的更改是否已导致某行移入或移出订阅服务器的分区时，在合并复制过程中优化同步使您可以将网络传输量减到最小。在合并复制中提供一个选项，可以在发布服务器上存储更多信息，而不是通过网络将该信息传输到订阅服务器。虽然该选项可能导致发布服务器上的数据库较大，但它可以改善通过慢速链接进行同步的性能。但是，将有更多信息存储在发布服务器上，因而将需要额外的存储空间。

如果未使用优化同步设置，一个分区中的更改将导致合并进程再次验证发送到所有订阅服务器的数据的分区内容，即使更改只影响其中的一个或几个订阅服务器。

例如，如果根据客户所在的州筛选销售数据，且有一个客户从 Washington 移动到了 California，则该行需要从发送给 Washington 订阅服务器的数据分区中删除，并添加到发送给 California 订阅服务器的数据分区中。

如果未使用优化同步，则合并进程还将检查发送到其它订阅服务器（Idaho、Oregon 地区的订阅服务器等等）的分区的州值是否更改。合并进程无法知道 California 值更改以前是什么值。启用同步优化将使合并进程可以准确知道哪些分区受到影响，以及哪些订阅服务器需要清理。

通过在发布服务器上存储附加信息，Microsoft® SQL Server™ 2000 可以更快速地确定应发送给特定订阅服务器的筛选数据。当优化同步时，SQL Server 2000 在发布服务器上创建之前映象表，其中包含有关水平或联接筛选中使用的列的更改的附加信息。这些从 UPDATE 或 DELETE 到这样的列的之前映象，允许合并代理程序快速且准确地确定哪个订阅服务器可能需要向特定数据分区添加行或从特定数据分区删除行。

例如，如果某销售机构基于销售地域对数据进行分区和分发，并且启用发布以优化同步，则有关数据分区的信息将存储在发布服务器上的之前映象表中。如果销售地域变化，导致数据需要重新分区给多个订阅服务器，这将是更新和重新分发数据的较快进程，因为有关数据当前分区情况的信息已经在发布服务器上了。

如果您的应用程序允许用于行筛选的值对于某给定行频繁更改，这种优化会十分有用。例如，如果频繁改变或重整销售地域分配，通过这种优化可以在同步过程中获得显著性能改善。

存储在发布服务器中的信息量基于用于定义分区的列。例如，如果分区中的列总共 20 字节，而且有一千万行，则大约有额外的 200 MB 将存储在发布服务器中。如果只有 10,000 行，则 200 KB 将存储在发布服务器中。

注意 选择在发布服务器上维护附加的信息会导致 publication 数据库中的合并复制跟踪系统表的存储要求增加；不过，如果分区中包含的列 UPDATES 是非典型的，则性能收益通常值得维护附加的信息。

最大程度地减少通过网络发送的数据量

Transact-SQL

企业管理器

最大限度地减少使用 SQL Server 企业管理器在网络上发送的数据量

  • 当在"创建发布向导"中创建合并发布时，在"优化同步"页上选择"是，最小化数据量"。

  • 对于现有的合并发布，可以在"订阅选项"选项卡上查看"发布属性"中的优化同步选项。创建发布后不能更改此选项。


复制数据考虑事项

发布某些数据类型和属性时有一些特殊考虑。本节识别这些数据类型和属性并描述管理它们的解决方案，包括：

  • 标识范围管理。指定标识范围管理有助于在合并复制期间或在带有可更新订阅的快照或事务复制期间，控制如何在不同的订阅服务器上修改数据。

  • 具有特定用途的数据类型。不同的数据类型（如 uniqueidentifier 和 timestamp）在复制处理期间有特定的用途，包括解决在多个服务器上更改相同的数据时发生的冲突。

  • NOT FOR REPLICATION。使用 NOT FOR REPLICATION 选项可在分区环境中实现标识值范围。


在复制中使用 IDENTITY 值

在为某列指派 IDENTITY 属性时，系统自动为表中插入的新行生成连续递增的编号。因为标识值通常唯一，所以标识列常定义为主键。

在发布中包含标识列和可在订阅服务器上插入新行的复制拓扑中，可能需要额外的配置以免出现重复标识值或违反约束。

为说明如何管理带有副本的标识值，假定来自发布服务器 A 的三行数据（含标识值 1、2 和 3）

被复制到订阅服务器 A 而且订阅服务器 A 允许插入。如果同一项目中插入两个新行，一行在发布服务器 A，一行在订阅服务器 A，并且复制代理程序未采取其它措施，则两行数据的标识值都赋为 4。复制代理程序会尝试在发布服务器和订阅服务器之间复制新行。如果成功，每个副本中都存在标识值为 4 的两个不同的行。结果，每个发布项目将包含多个具有相同标识值的行。如果标识列定义为主键或定义有唯一约束，则不会复制数据。

复制提供几个选项以保证相同的标识值不赋给插入不同副本中的行，或避免发生违反主键约束。


管理标识值

可用以下方法管理标识值：

  • 通过给发布服务器和所有订阅服务器动态分配标识值范围，使 Microsoft® SQL Server™ 2000 复制可以自动管理标识列。

  • 定义标识列时使用 Transact-SQL NOT FOR REPLICATION 选项。

  • 如果标识列不是必需的，则用主键，而不是标识列（例如，组合键或 rowguid 列）。这种策略消除了复制数据中管理标识列的开销。
自动标识范围处理

在不同副本之间处理标识范围的最简单方法是使 SQL Server 2000 代为管理标识范围处理。若要使用自动标识范围处理，必须首先在创建发布时启用该功能，指派一套初始化发布服务器和订阅服务器标识范围值，然后指派决定何时创建新标识范围的阈值。

例如，将从 1000 到 2000 的标识范围指派给发布服务器，从 2001 到 3000 的标识范围给初始化订阅服务器，当和 80% 的阈值组合时，则工作情况如下：

  • 发布服务器的新插入行被指派从 1000 到 2000 范围的标识值。初始化订阅服务器上的新插入行，标识值范围从 2001 到 3000。

  • 当发布服务器或订阅服务器的标识值用到 80% 时，将为未来的插入项创建新标识范围。本例中，如果发布服务器的标识值从 1001 到 1800 已用，则已达到阈值。系统在发布服务器上创建一个新标识范围（从 3001 到 4000），且发布服务器中下一个插入的新行被赋予 3001 的标识值。在订阅服务器达到阈值后（假设订阅服务器在发布服务器之后达到阈值），则将在订阅服务器上创建新标识范围（从 4001 到 5000），指派给订阅服务器上插入的下一个新行的标识值是 4001。随着标识范围的使用，这一进程重复进行。

  • 每添加一个订阅服务器，都将用下一个可用起点添加与初始化订阅服务器范围长度相同的标识范围。

阈值设置应避免出现订阅服务器用尽标识值，并在分发代理或合并代理与订阅服务器同步前，无法插入新行的情况。然而，将阈值设置过低会产生大量闲置的标识值。应根据订阅服务器和同步调度的更新频率仔细设置阈值。

对于为标识范围管理启用的事务项目，需要定期检查和调整发布服务器和订阅服务器上的标识范围。在发布服务器中该工作由日志读取器代理程序完成，在订阅服务器中则由分发代理程序完成。

如果日志读取器代理程序或分发代理程序未以连续模式运行，在处理完所有命令后需要检查和做适当的调整。如果其中一个以连续模式运行，则在处理完所有命令后，将以 10 倍于代理程序轮询间隔的时间间隔进行检查和做适当的调整。代理程序启动后，命令一处理完就进行首次检查。

当服务器位于其标识范围之外时，运行日志读取器代理程序或分发代理程序以调整发布服务器或订阅服务器。如果代理程序以连续模式运行，可能需要重新启动才能立即调整标识范围。

也可以执行 sp_adjustpublisheridentityrange，根据事务或合并发布的阈值，显式调整发布服务器的标识范围。

可通过以下途径启用自动标识范围处理：

  • 在 SQL Server 企业管理器的"发布属性"对话框中。

  • 通过设置以下这些 sp_addmergearticle 存储过程中的选项。
参数 | 值 | 描述
@auto_identity_range | TRUE 或 FALSE | 启用 (TRUE) 或禁用 (FALSE) 自动标识范围处理。
@pub_identity_range | 整数值范围（例如，从 1001 到 2000） | 发布服务器的标识范围。
@identity_range | 整数值范围（例如，从 2001 到 3000） | 初始化订阅服务器的标识范围；用于附加订阅服务器的范围长度。
@threshold | 整数值阈值百分比（例如，90 相当于 90%） | 副本上使用的总标识值百分比，用于触发创建新标识范围。

手工标识范围处理

也可用检查约束和在 Transact-SQL CREATE TABLE 语句 IDENTITY 属性上的 NOT FOR REPLICATION 选项管理标识值。若要以编程方式指定标识范围，或要升级通过 Transact-SQL 语句管理标识范围的现有 SQL Server 实例，请使用 NOT FOR REPLICATION 选项。

用 NOT FOR REPLICATION 语句通知 SQL Server 2000 当提供显式值时，复制进程获得一个弃权声明，并且不应重置本地标识值的种子值。每个使用该选项的发布服务器都接收重置种子值的弃权声明。

以下代码示例说明如何在每个发布服务器上的不同范围执行标识：

  • 在发布服务器 A 上，从 1 开始以 1 递增。
    CREATE TABLE authors ( COL1 INT IDENTITY (1, 1) NOT FOR REPLICATION PRIMARY KEY )
  • 在发布服务器 B 上，从 1001 开始以 1 递增。
    CREATE TABLE authors ( COL1 INT IDENTITY (1001, 1) NOT FOR REPLICATION PRIMARY KEY )

激活 NOT FOR REPLICATION 选项之后，从复制代理到发布服务器 A 的连接插入带有诸如 1, 2, 3, 4 值的行。这些值（即 1, 2, 3, 4）不做任何更改地复制到发布服务器 B。出自发布服务器 B 上复制代理的连接接收值 1001, 1002, 1003 和 1004。那些值不做任何更改地复制到 A。当分发或合并所有数据后，两个发布服务器都有值 1, 2, 3, 4, 1001, 1002, 1003 和 1004。下一个在发布服务器 A 上本地插入的值是 5。下一个在发布服务器 B 上本地插入的值是 1005。

建议总是将 NOT FOR REPLICATION 选项与 CHECK 约束一起使用以确保指派的值在允许范围内。例如：

CREATE TABLE sales

(sale_id INT IDENTITY(100001,1)

NOT FOR REPLICATION

CHECK NOT FOR REPLICATION (sale_id <= 200000),

sales_region CHAR(2),

CONSTRAINT id_pk PRIMARY KEY (sale_id)

)

即使用 SET IDENTITY INSERT，所有本地插入的值也必须遵守范围。但是，复制进程仍然免于检查。

用其它列作为主键

如果不必使用标识列，则可通过用另一列作为主键或用组合列作主键，消除在复制数据中管理标识值唯一性的开销。

例如，可定义一个由标识列和另一列组成的主键，其中标识列的值并不唯一，而另一列在与标识列组合时将保证唯一性（例如，一个站点 ID 列 pk_id_plus_site）。本例中，组合键 pk_id_plus_site 由标识列和站点列组成。复制中，重复的标识值只能创建在不同的站点上，因此，这种情况下每个主键值总是唯一的。

ROWGUIDCOL 是一种可指派给具有 uniqueidentifier 值的列的属性，也是一种定义 128 位整数以保证唯一性的 SQL Server 2000 数据类型。同样，用 rowguid 列作为主键是替代使用标识列以保证唯一性的一种安全方式。


带有即时更新和排队更新的标识范围

对于允许即时更新，但不允许排队更新的发布（在快照复制和事务复制中），发布服务器控制标识值。因为复制代理不为订阅服务器上的列指派 IDENTITY 属性，所以不能用这种复制类型指派标识范围。只在发布服务器上创建 IDENTITY 属性，并使订阅服务器采用默认值为 0 的基本数字数据类型（例如，int）。如果分发代理初始化架构和数据（即订阅的同步类型设置为自动），则这些操作自动执行。下一个标识值总产生于发布服务器处并指派给插入订阅服务器的行。

如果带有排队更新，则标识值必须由订阅服务器指派，因为订阅服务器上新插入的行可能发送到队列，而不是直接到发布服务器。因为数据是异步发送的，所以与即时更新的情况不同，在发布服务器上没有将标识值立即指派到订阅服务器上新插入行的机制。

对于允许即时更新并用排队更新作为故障转移选项的发布，标识范围或自动或手工地指派给订阅服务器。订阅服务器上的插入行从指派的本地标识范围中产生标识值。订阅服务器的新行将被发送到队列，队列读取器代理从中选取该列并应用到带有正确（非重置）标识值的发布服务器。


管理复制 timestamp 数据

Microsoft® SQL Server™ 2000 timestamp 数据指数据库专用的递增二进制数，用于表示数据库中的数据修改发生的相对顺序；timestamp 数据与按年代顺序排列的时间和日历日期均无关。

uniqueidentifier 数据类型列用于检测这种复制类型的冲突；timestamp 数据不再用于冲突检测。有关这一变动涉及的升级问题的更多信息，请参见复制和升级。

timestamp 列的字面值被复制，但在订阅服务器上，复制值的数据类型被更改为 binary (8)。

对于包含 timestamp 列的合并复制和排队更新订阅服务器（包括用排队更新作为故障转移的即时更新）项目，仅复制 timestamp 列，但不复制其字面值。当相应的行应用到订阅服务器时，timestamp 值在初始化同步时间内重新生成。这使订阅服务器上的客户端应用程序得以将 timestamp 应用于像乐观锁定这样的功能。在那些情况下，应用程序用于执行乐观锁定的 ODBC 驱动程序、OLE DB 提供程序、DB-Library 游标或服务器游标将待更新行的 timestamp 值与原始行中的当前值进行比较。如果 timestamp 值不同，则表明行已更改，应用程序可采取适当的操作（回滚事务、重读数据，等等）。

处理 timestamp 数据即暗含冲突检测。对于随行级跟踪出现的冲突，必须在两个副本中更新同一行。对于随列别跟踪出现的冲突，必须在两个副本中更新同一行内的同一列。因为 timestamp 值随着行的更新而更改，除非采取特别措施，否则行级跟踪与列级跟踪之间的区别会随着 timestamp 列的出现而消失。如果启用列跟踪，每次两端同时更新，甚至发生在行中的不同列上时，两端 timestamp 值也会更改，并且标记列级冲突。列级跟踪总与行级跟踪以同样的方式有效地工作，不同列中更新的数据不会发生合并。

合并复制跟踪通过忽略 timestamp 的值解决该问题（事务复制中的"排队更新订阅服务器"选项只用行级跟踪检测冲突，所以这不是一个问题）。例如，假设一个合并复制表包含四列：一个 uniqueidentifier 列、一个 integer 列、一个 character 列和一个 timestamp 列。发布服务器上第一行中 integer 列的值将被更新，于是订阅服务器上第一行中 character 列的值也更改。当启用列级跟踪时，数据合并不发生冲突。如果在启用列级跟踪时，合并代理程序不忽略 timestamp 的值（如果用行级跟踪，则在任何情况下，都会检测到冲突），则该非冲突更新将被标记为冲突，数据也就不能正确合并。所以，如果 timestamp 列的值更改了，合并代理并不比较该列，也不进行任何操作。


使用 NOT FOR REPLICATION

Microsoft® SQL Server™ 2000 复制使用 NOT FOR REPLICATION 选项在分区环境中实现标识值范围。当用来自不同站点的行分区发布表时，NOT FOR REPLICATION 选项在事务或合并复制中特别有用。

当复制代理程序用任何登录连接到某个表时，该表上的所有 NOT FOR REPLICATION 选项都将被激活。设置该选项时，SQL Server 2000 在复制代理程序所添加的行上保留起始标识值，但是继续在其他用户所添加的行上增加标识值。当用户将某个新行添加到表时，标识值以通常的方式增加。当复制代理程序将该新行复制到订阅服务器时，在将该行插入到订阅服务器表中时不更改标识值。

例如，考虑这样的表，它包含从两个源插入的行：发布服务器 A 和发布服务器 B。通过将值从 1 增加到 1000 标识在发布服务器 A 上插入的行，通过将值从 1001 增加到 2000 标识在发布服务器 B 上插入的行。如果发布服务器 A 上的进程将行从本地插入到表中，则 SQL Server 指派第一行的值为 1，第二行的值为 2，依此类推。同样，如果发布服务器 B 上的进程将行从本地插入到表中，则指派第一行的值为 1001，第二行的值为 1002，依此类推。当将发布服务器 A 上的行复制到发布服务器 B 上时，标识值仍然是 1、2，依此类推，但将不重置发布服务器 B 上的本地种子值。

无论 IDENTITY 属性在复制中的作用如何，它本身不强制唯一性，而只插入下一个值。虽然可以使用 SET IDENTITY INSERT 提供显式值，但该函数不适合复制，因为它还重新赋值。NOT FOR REPLICATION 选项是专门为使用复制的应用程序创建的。例如，如果没有此选项，只要发布服务器 B（值为1001）中的第一行传播到发布服务器 A，则发布服务器 A 的下一个值将是 1002。NOT FOR REPLICATION 选项告诉 SQL Server 2000 当提供显式值时，复制进程获得一个弃权声明，并且不应重置本地值的种子值。每个使用此选项的发布服务器都获得相同的重新赋值弃权声明。

在复制可以处理标识属性之前，必须通过自定义存储过程对完整的列列表使用 INSERT、UPDATE 和 DELETE 语句。如果未使用完整的列列表，则将返回一个错误信息。

以下代码示例说明如何在每个发布服务器上的不同范围执行标识：

  • 在发布服务器 A 上，从 1 开始以 1 递增。
    CREATE TABLE authors ( COL1 INT IDENTITY (1, 1) NOT FOR REPLICATION PRIMARY KEY )
  • 在发布服务器 B 上，从 1001 开始以 1 递增。
    CREATE TABLE authors ( COL1 INT IDENTITY (1001, 1) NOT FOR REPLICATION PRIMARY KEY )

激活 NOT FOR REPLICATION 选项之后，从复制代理到发布服务器 A 的连接插入带有诸如 1, 2, 3, 4 值的行。这些值（即 1, 2, 3, 4）不做任何更改地复制到发布服务器 B。来自发布服务器 B 上的复制代理程序的连接获得值 1001、1002、1003 和 1004。这些值将不做任何更改地复制到 A。当分发或合并所有数据后，两个发布服务器都有值 1、2、3、4、1001、1002、1003 和 1004。下一个在发布服务器 A 上本地插入的值是 5。下一个在发布服务器 B 上本地插入的值是 1005。

建议始终将 NOT FOR REPLICATION 选项与 CHECK 约束一起使用，以确保指派的标识值在允许范围内。例如：

CREATE TABLE sales
(sale_id INT IDENTITY(100001,1)
    NOT FOR REPLICATION
    CHECK NOT FOR REPLICATION (sale_id <= 200000),
sales_region CHAR(2),
CONSTRAINT id_pk PRIMARY KEY (sale_id)
)

即使用 SET IDENTITY INSERT，所有本地插入的值也必须遵守范围。但是，复制进程仍然免于检查。

说明 如果使用的是带即时更新订阅服务器选项的事务复制，则不要使用 IDENTITY NOT FOR REPLICATION 设计。相反，只在发布服务器上创建 IDENTITY 属性，并使订阅服务器只使用基本数据类型（例如 int）。这样一来，就始终在发布服务器上生成下一个标识值。


管理和监视复制

Microsoft® SQL Server™ 2000 复制提供管理和监视复制代理程序、复制警报和复制进程的工具，以确保复制满足组织的需要。

监视复制可以帮助：

  • 为复制代理程序设置代理配置文件、调度、属性和提示。

  • 查看代理活动并解决疑难问题，包括验证代理上一次运行的时间、监视代理活动和分析复制性能。

  • 当复制代理程序出现事件时，通过复制警报接收提示。

  • 验证订阅以确保数据值与发布服务器和订阅服务器上的数据值相同。

  • 根据需要重新初始化对发布一个或全部的订阅。

  • 从中心位置管理复制代理程序。


用于管理和监视复制的工具

若要管理和监视代理程序，可以使用 SQL Server 企业管理器中的复制监视器、命令提示实用工具、Transact-SQL 系统存储过程，也可以使用用于复制的 Microsoft® ActiveX® 控件或 SQL-DMO 对象，这些对象可以用诸如 Microsoft Visual Basic® 和 Microsoft Visual C++® 这样的编程语言编写。Windows NT 性能监视器或 Windows 2000 系统监视器可以用来监视不同的复制进程发生的速率。


复制监视器

复制监视器是 SQL Server 企业管理器的一个组件，被设计用来查看复制代理程序的状态和解决分发服务器上的潜在问题。在 SQL Server 企业管理器中，复制监视器以节点的形式位于作为分发服务器的服务器下，当用户是 sysadmin 固定服务器角色成员时启用此服务器。复制监视器组还可作为企业管理器的顶层节点，处于可以监视和管理多个分发服务器的中央位置。

此外，对于非 sysadmin 固定服务器角色成员的用户，如果用分发数据库的 replmonitor 角色对他们进行了定义，则他们可以监视复制。系统管理员可以将任意用户添加到 replmonitor 角色中，这样该用户就可以通过 SQL Server 企业管理器中的复制监视器节点查看复制活动；但是，该用户不能管理复制。

在一个分发数据库中，用户可以只是 replmonitor 角色的一部分。他们只能查看他们是 replmonitor 角色的一部分的分发数据库中的代理程序。但是复制监视器节点上显示的状态却反映所有的代理程序。所以，用户可能多次看到错误状态（复制监视器节点、发布服务器或代理程序文件夹上的红 X），但是能查看的代理程序中没有一个显示出错误状态。这表明用户无法看见的代理程序正在显示错误状态。

例如，添加到 replmonitor 角色中的用户可以查看代理程序历史记录、错误信息以及错误分析详细信息，但他们不能更改代理程序配置文件、代理程序调度等等。尽管这个用户能够查看发布列表，但只能查看在发布访问列表 (PAL) 中包括该用户的发布的属性。

可以使用复制监视器执行以下任务：

  • 查看发布服务器列表、发布以及对分发服务器支持的发布的订阅。

  • 查看已调度的复制代理程序，并监视每个代理程序的实时状态和历史记录。

  • 设置并监视与复制事件相关的警报。

  • 管理代理程序和订阅，包括启动和停止代理程序以及重新初始化订阅。

配置完复制之后，也可以使用 Microsoft Windows NT® 或 Windows 2000 事件查看器查看 SQL Server™ 消息。有关事件查看器的信息，请参见 Microsoft Windows NT® 4.0 帮助或 Windows®2000 帮助。

启用复制监视器组

  1. 在企业管理器中，右击 SQL Server，然后单击"属性"。

  2. 在"复制"选项卡上，选择"显示复制监视器组"。另外，还可以选择在复制监视器组中将此服务器作为分发服务器添加。


复制代理程序实用工具

可以使用复制命令提示实用工具配置和启动复制代理程序活动。命令提示实用工具自动与 Microsoft® SQL Server™ 2000 一起安装。复制代理程序文件位于 \Microsoft SQL Server\80\Com 下。下表列出了复制实用工具的名称和文件名。

命令提示实用工具 | 文件名
复制快照代理程序实用工具 | snapshot.exe
复制分发代理程序实用工具 | distrib.exe
复制日志读取器代理程序实用工具 | logread.exe
复制队列读取器代理程序实用工具 | qrdrsvc.exe
复制合并代理程序实用工具 | replmerg.exe

说明 在通过复制监视器管理复制代理程序时，可以通过更改每个代理程序可用的命令行修改代理程序设置。若要访问该命令行，请右击某个特定的代理程序，单击"代理程序属性"，单击"步骤"选项卡，然后双击"运行代理程序"步骤。

有关更多信息，请参见命令提示实用工具入门。


用于复制的 ActiveX 控件

Microsoft® ActiveX® 控件允许自定义应用程序以配置和唤醒调用复制代理功能。这些控件支持所有的订阅类型，并且可以用分发服务器上的 SQL Server企业管理器监视这些控件。

程序员可以使用 ActiveX 控件进行复制，与使用任何标准的内置控件类似。这些控件是 SQL 快照控件、SQL 分发控件和 SQL 合并控件。

使用 ActiveX 控件进行复制的优点是：

  • 客户不依赖于负责执行除复制以外的其它作业的 SQL Server 代理。

  • 如果使用 SQL Server 代理启动了某个复制，则其它作业同样可以运行。

  • 如果正在使用请求订阅或匿名订阅复制到异类订阅服务器，则该订阅服务器上不能使用 SQL Server 代理。

  • 可以从许多编程环境如 Microsoft Visual Basic®、Visual Basic Scripting Edition、Microsoft Visual C++® 中唤醒调用 ActiveX 复制控件。

  • 应用程序可以控制复制发生的时间。例如，可以对使用复制 ActiveX 控件的菜单命令或 Web 页进行编程。

  • 应用程序可以使用 ActiveX 控件状态回叫处理程序以便设置一个进度栏，用以提供有关复制控件进度的反馈。

  • 应用程序可以决定如何获得自动运行复制代理程序的登录信息（例如，以硬编码或交互式方式运行）。

  • 在应用程序中嵌入复制控件提供了一种不用设置复杂的订阅服务器，就可以分发移动应用程序的方法。

  • 可以将控件设计为能够添加、拖动、重新初始化或验证订阅，并能够在订阅服务器上创建或附加数据库。

  • 可以设计应用程序以便在 Microsoft 同步管理器上注册订阅同步。

如果已经在 Microsoft Windows 同步管理器上注册了订阅，就不需要在该应用程序中嵌入控件。然后这个中心应用程序可以控制所有的同步。但是，Windows 同步管理器不允许指定订阅的某些自定义属性，例如它的替代主机名和包括 FTP 的订阅代理设置。ActiveX 控件对于这些管理活动非常有用。

有关更多信息，请参见使用 ActiveX 控件开发复制应用程序。


Windows NT 性能监视器和 Windows 2000 系统监视器

Windows 2000 系统监视器和 Windows NT 性能监视器可用于监视各个复制进程运行时的速度。使用性能监视器或系统监视器可以通过图表和报告来评价计算机的效率、确定和解决可能的问题（例如，资源使用不平衡、硬件不足或程序设计有问题等），并计划其他硬件需求。可以使用相关的复制计数器优化复制性能。

有关更多信息，请参见 Windows NT 和 Windows 2000 附带的性能监视器文档和系统监视器文档。


设置代理程序参数

每个复制代理程序都支持一组运行时参数，可以用它们控制代理程序的运行方式。有关各代理程序可使用的参数的更多信息，请参见复制命令提示实用工具文档。

例如，排除复制代理程序活动故障的一个非常有用的参数是 –output。此参数会将发生的所有操作和用于某个特定代理程序的错误信息写入文本文件中。

可以这样设置参数：

  • 通过运行标题为"运行代理"的代理作业步骤的命令行。

  • Microsoft® ActiveX® 组件的属性。

  • 通过集中的代理程序配置。

  • 通过代理程序命令提示实用工具。

请参见

复制分发代理程序实用工具

复制日志读取器代理程序实用工具

复制合并代理程序实用工具

复制队列读取器代理程序实用工具

复制快照代理程序实用工具


代理程序配置

在创建复制代理程序时，会将它与一个代理程序配置相关联，该配置在分发服务器上进行维护。该代理程序配置包含一组代理程序每次运行时都要用到的参数。在启动过程中，每个代理都会登录到分发服务器上并在它的配置文件中查询这些参数。

代理程序配置能使您很容易地更改与该配置关联的所有代理程序的主要参数。例如，如果有 20 个快照代理程序并且需要更改查询超时值，则可以更新这些快照代理程序使用的配置，这样此类型的所有代理程序在它们下一次运行时将自动使用新值。代理程序的不同实例可以有不同的配置。例如，使用远程访问服务 (RAS) 连接分发服务器的分发代理程序，可以使用一组更适合于慢速通信链接的参数。

将服务器配置为分发服务器时，将为每种代理程序类型安装一组默认的和预定义的配置。如果某个特定的配置没有与代理程序相关联，则 SQL Server 代理会将为这种代理程序类型使用默认的配置。

说明 为代理程序命令提示实用工具中的参数设置的值会覆盖代理程序配置中为同一个参数设置的值。

创建复制代理程序配置

企业管理器

如何创建复制代理程序配置（企业管理器）

Transact-SQL


复制代理程序

复制代理程序执行许多与复制有关的任务，包括创建架构和数据的副本、检查发布服务器或订阅服务器的更新，并传播服务器之间的更改。每个复制代理程序都有一个与它相关的代理配置文件、一些可以设置的代理属性以及代理调度及代理历史记录。

复制监视器能够管理复制代理的活动，把它们用图表表示出来。可以查看分发服务器支持的所有的快照代理程序、日志读取器代理程序、分发代理程序、队列读取器代理程序或合并代理程序的列表。可以选择分发服务器并单击复制监视器来显示这些代理程序的列表。在单击用于某个特定代理程序类型的文件夹时，会显示出分发服务器上属于此类型的所有代理程序。然后可以查看某个特定代理程序的详细活动。

独立代理程序和共享代理程序

独立代理程序是服务于一个订阅的代理程序。使用独立代理程序时，因为不管订阅何时需要同步，独立代理程序都可以随时启用，从而使滞后时间减少。

共享代理程序服务于多个订阅，是快照复制或事务复制的默认代理程序。当使用同一共享代理程序的多个订阅需要同步时，它们将会排队等候，共享代理程序一次服务一个订阅。

合并复制过程中使用的所有代理程序都是独立的代理程序。当独立代理程序与快照复制或事务复制一起使用时，务必注意防止相互依赖的事务在传送时顺序不对。


SQL Server 代理

SQL Server 代理安排并调度在复制中使用的代理程序，同时提供一种简单的方法来运行复制代理程序。在选择建立信任连接时，复制代理程序会在 SQL Server 代理启动帐户的安全环境下运行。SQL Server 代理同时还控制并监视除复制以外的一些其它操作，包括监视 SQLServerAgent 服务、维护错误日志、运行作业和启动其它进程。


快照代理程序

快照代理程序将与所有的复制类型一起使用。它将准备已发布表和已存储过程的架构和初始数据文件、存储快照文件，并将有关初始同步的数据插入分发数据库中。快照代理程序通常运行于分发服务器的 SQL Server 代理下，可通过 SQL Server 企业管理器或 ActiveX® 快照控件进行管理。每个发布都有一个快照代理程序。


快照代理程序配置

将服务器配置为分发服务器时，将安装快照代理程序的默认配置。默认配置文件中包含以下参数和值。

参数 | 默认值 | 描述
-BcpBatchSize | 100000 | 执行 bcp 操作时，批处理大小是作为一个事务发送到服务器的行数，也是在分发代理程序记录 bcp 进度消息之前必须发送的行数。在执行 bcp out 操作时，使用的固定批处理大小是 100.000。值为 0 表明没有记录消息。
-HistoryVerboseLevel | 2 | 在快照操作中记录的历史记录数量可以是： 1 = 总是更新相同状态（启动、进行中、成功等等）的前一条历史记录消息。如果没有相同状态的前一条记录存在，将插入一条新记录。 2 = 插入新的历史记录。如果该记录是用于闲置消息或长时间运行作业消息这样项目的记录，将更新以前的记录。 3 = 总是插入新记录，除非它是用于闲置消息的记录。 通过将值指定为 1 可以最小化历史记录对性能的影响。
-LoginTimeOut | 15 | 在代理程序尝试登录之前超时的秒数。
-MaxBcpThreads | 1 | 能以并行方式执行的大容量复制操作的数量。同时存在的线程和 ODBC 连接的最大数量小于 MaxBcpThreads，或小于出现在分发数据库中同步事务中的大容量复制请求的数量。MaxBcpThreads 必须大于零，并且没有硬编码上限。
-QueryTimeOut | 300 | 代理程序发出查询之前超时的秒数。


分发代理程序

分发代理程序将与快照复制和事务复制一起使用。它将快照文件和保存在分发数据库中的增量更改移动到订阅服务器上。分发代理程序通常运行在分发服务器上用于强制订阅的 SQL Server 代理下，或是运行在订阅服务器上用于请求订阅的 SQL Server 代理下。可以使用 SQL Server 企业管理器或 ActiveX® 分发控件管理该程序。既可以是每个订阅有一个分发代理程序（独立的代理程序）也可以是每个发布数据库和订阅数据库对共用一个分发代理程序（共享的代理程序）。


分发代理程序配置

将服务器配置为分发服务器时，将安装分发代理程序的默认配置。默认配置文件中包含以下参数和值。

参数 | 默认值 | 描述
-BcpBatchSize | 100000 | 大容量复制操作中要发送的行数。执行 bcp 操作时，批处理大小是作为一个事务发送到服务器上的行数，也是在分发代理程序记录 bcp 进度消息之前必须发送的行数。在执行 bcp out 操作时，使用的固定批处理大小是 1000。值为 0 表明没有记录消息。
-CommitBatchSize | 100 | 在发出 COMMIT 语句之前要被发到订阅服务器的事务数量。
-CommitBatchThreshold | 1000 | 在发出 COMMIT 语句之前要颁发到订阅服务器的复制命令的数量。
-HistoryVerboseLevel | 1 | 在分发操作中记录的历史记录数量可以是： 1 = 总是更新相同状态（启动、进行中、成功等等）的前一条历史记录消息。如果没有相同状态的前一条记录存在，将插入一条新记录。 2 = 插入新的历史记录，除非该记录是诸如闲置消息或长时间运行作业消息这样的记录，在这种情况下要更新以前的记录。 3 = 总是插入新记录，除非它是用于闲置消息的记录。 通过将值指定为 1 可以最小化历史记录对性能的影响。
-LoginTimeOut | 15 | 在代理程序尝试登录之前超时的秒数。
-MaxBcpThreads | 1 | 能以并行方式执行的大容量复制操作的数量。同时存在的线程和 ODBC 连接的最大数量小于 MaxBcpThreads，或小于出现在分发数据库中同步事务中的大容量复制请求的数量。MaxBcpThreads 的值必须大于零，并且没有硬编码上限。
-MaxDeliveredTransactions | 0 | 在一个同步中应用到订阅服务器的强制事务或请求事务的最大数量。值为 0 表示事务的最大数量没有限制。订阅服务器可以使用其它值以缩短来自发布服务器的请求同步的持续时间。
-PollingInterval | 10 | 为已复制的事务查询分发数据库的秒数。
-SkipErrors |  | 将跳过的错误数量。分发代理程序将忽略指出的数量的错误并继续按照它的计划执行任务。
-SkipFailureLevel | 1 | 启用分发代理程序以跳过错误。值为 0 表示分发代理程序将不会忽略任何错误。
-QueryTimeOut | 300 | 代理程序发出查询之前超时的秒数。
-TransactionsPerHistory | 100 | 记录历史记录的事务间隔。如果在上一个历史记录实例之后提交的事务数量大于此选项，将记录一条历史消息。值为 0 表明 TransactionsPerHistory 的值没有限制。


日志读取器代理程序

日志读取器代理程序将与事务复制一起使用。它将标记为复制的事务从发布服务器的事务日志移动到分发数据库中。每个标记为事务复制的数据库都有一个运行在分发服务器上且连接到发布服务器的日志读取器代理程序。


日志读取器代理程序配置

将服务器配置为分发服务器时，将安装日志读取器代理程序的默认配置。默认配置文件中包含以下参数和值。

参数 | 默认值 | 描述
-HistoryVerboseLevel | 1 | 在日志读取器操作中记录的历史记录数量可以是： 1 = 总是更新相同状态（启动、进行中、成功等等）的前一条历史记录消息。如果没有相同状态的前一条记录存在，将插入一条新记录。 2 = 插入新的历史记录，除非该记录是诸如闲置消息或长时间运行作业消息这样的记录，在这种情况下要更新以前的记录。 通过将值指定为 1 可以最小化历史记录对性能的影响。
-LoginTimeOut | 15 | 在代理程序尝试登录之前超时的秒数。
-PollingInterval | 10 | 为已复制事务查询日志的秒数。
-QueryTimeOut | 300 | 代理程序发出查询之前超时的秒数。
-ReadBatchSize | 500 | 从源读取事务的最大数量。对于日志读取器代理程序，源是发布数据库的事务日志。
-ReadBatchThreshold | 100 | 在分发代理程序将复制命令发布到订阅服务器之前，要从事务日志读取的复制命令的数量。


队列读取器代理程序

队列读取器代理程序用于快照复制或事务复制（使用排队更新选项），或者启用以排队更新作为故障转移选项的即时更新。

队列读取器代理程序是一个运行在分发服务器上的多线程代理程序。它负责从队列中获取消息并将它们应用于相应的发布。

队列读取器代理程序从每个订阅服务器上的 Microsoft® SQL Server™ 2000 队列中读取信息，并将这些事务应用于发布。默认情况下，此代理程序使用 SQL Server 代理的安全环境。与分发代理程序和合并代理程序不同，只存在一个队列读取器代理程序的实例来服务于所有的发布服务器和用于给定分发服务器的发布。


合并代理程序

合并代理程序与合并复制一起使用。合并代理程序在订阅服务器上应用初始快照，并移动和调节创建初始快照之后发生的增量数据更改。每个合并订阅都有自己的合并代理程序，此合并代理同时连接发布服务器和订阅服务器并对它们进行更新。对于强制订阅，合并代理程序通常运行在分发服务器的 SQL Server 代理下，而对于请求订阅，运行在订阅服务器的 SQL Server 代理下。可以使用 SQL Server 企业管理器或 ActiveX® 合并控件管理合并代理程序。


合并代理程序配置

将服务器配置为分发服务器时，将安装合并代理程序的默认配置。默认配置文件中包含以下参数和值。

参数 | 默认值 | 描述
-BcpBatchSize | 100000 | 大容量复制操作中要发送的行数。在执行 bcp 操作中同时应用架构更改时，合并代理程序会使用批处理大小确定何时记录进度消息。值为 0 表明没有记录消息。
-ChangesPerHistory | 100 | 记录了超过上载和下载消息量的阈值。
-DownloadGenerationsPerBatch | 100 | 将更改从发布服务器下载到订阅服务器时，在一个批处理中要处理的生成数量。生成被定义为在每个项目更改的逻辑组。不可靠通信链接的默认值是 10。 但是，在所有情况中，每个批处理中要处理的生成的实际数量都等于 UploadGenerationsPerBatch 设置的较大值或已发布项目的数量加 1。
-DownloadReadChangesPerBatch | 100 | 在更改从发布服务器下载到订阅服务器时，在一个批处理中要读取的更改的数量。
-DownloadWriteChangesPerBatch | 100 | 在更改从发布服务器下载到订阅服务器时，在一个批处理中要应用的更改的数量。
-FastRowCount | 1 | 指定在行数验证中要使用何种类型的行数计算方法。值为 1（默认值）表明是快速方法。值为 0 表明是完整的行数计算方法。
-HistoryVerboseLevel | 1 | 在合并操作中记录的历史记录数量可以是： 1 = 总是更新相同状态（启动、进行中、成功等等）的前一条历史记录消息。如果没有相同状态的前一条记录存在，将插入一条新记录。这种级别记录的消息数量最少。 2 = 插入新的历史记录，除非该记录是诸如闲置消息或长时间运行作业消息这样的记录，在这种情况下要更新以前的记录。这种级别记录了级别 1 消息，再加上其它的进行中消息。 3 = 总是插入新记录，除非它是用于闲置消息的记录。 通过设置 ChangesPerHistory 参数可以最小化历史记录对性能的影响。
-KeepAliveMessageInterval | 300 | 在历史记录线程检查是否任何现有的连接都在等待来字服务器响应前的秒数。可以增加该值以免在执行长时间运行的批处理时，被检查代理程序将该代理程序标记为置疑。
-LoginTimeOut | 15 | 在代理程序尝试登录之前超时的秒数。
-MaxDownloadChanges | 0 | 在特定的合并会话中希望下载的更改的最大数量。因为要处理完整的生成，所以下载的行数可能要超过指定的最大数量。
-MaxUploadChanges | 0 | 在特定的合并会话中希望上载的更改的最大数量。因为要处理完整的生成，所以上载的行数可能要超过指定的最大数量。
-NumDeadlockRetries | 5 | 在合并进程遇到一个死锁错误时，它尝试重试内部操作的次数。可以是 1 和 100 之间的任意值。
-PollingInterval | 60 | 在连续模式下，为数据更改而查询发布服务器或订阅服务器的秒数。
-QueryTimeOut | 300 | 代理程序发出查询之前超时的秒数。
-StartQueueTimeout | 0 | 当运行的合并进程数达到限制时，表示合并代理程序等待的最大秒数。如果达到了最大秒数而合并代理程序还在等待，则它将退出。"0"值意味着代理程序无限期地等待，不过可以取消此等待。
-UploadGenerationsPerBatch | 100 | 在将更改从订阅服务器上载到发布服务器时，在一个批处理中要处理的生成的数量。生成被定义为在每个项目更改的逻辑组。不可靠通信链接的默认值是 1。 但是，在所有情况中，每个批处理中要处理的生成的实际数量都等于 UploadGenerationsPerBatch 设置的较大值或已发布项目的数量加 1。
-UploadReadChangesPerBatch | 100 | 将更改从订阅服务器上载到发布服务器时，在一个批处理中读取的更改的数量。
-UploadWriteChangesPerBatch | 100 | 将更改从订阅服务器上载到发布服务器时，在一个批处理中应用的更改的数量。
-Validate | 0 | 指定在合并会话的结束时是否要执行验证。值 0（默认值）表明无须验证。值 1 表明只执行行数验证。值 2 表明执行数和校验值验证。值 3 表示二进制校验值验证（只在 SQL Server 2000 中才有）。
-ValidateInterval | 60 | 在设置为连续模式时验证订阅的时间（以分钟计）。


杂项代理程序

复制监视器中的杂项代理程序文件夹列出了清除和监视不同复制进程所需的代理程序。

代理程序历史记录清理代理程序

代理程序历史记录清理代理程序将复制代理程序历史记录从分发数据库中删除。默认情况下，该代理程序每隔 10 分钟运行一次。运行此代理程序对于管理分发数据库的大小很有帮助。

分发清理代理程序

分发清理代理程序将重复事务从分发数据库中删除。默认情况下，此代理程序为快照和事务发布每隔 72 小时运行一次。如果订阅在最大分发保持期内未进行同步处理，则分发清理代理程序可能停用订阅。有关更多信息，请参见订阅停用和过期。

过期订阅清理代理程序

此代理程序检测并删除已发布数据库中的过期订阅。如果某个订阅被停用，则过期订阅清理代理程序将删除此订阅。默认情况下，该代理程序每天运行一次。在清理过程当中或在发布保持期已过后运行复制代理程序时，将订阅标记为已过期。有关更多信息，请参见订阅停用和过期。

重新初始化存在数据验证失败的订阅的代理程序

重新初始化所有存在数据验证失败的订阅。默认情况下，不设置定时调度此代理程序。运行此代理程序自动检测验证失败的订阅，并标记这些订阅以进行重新初始化。标记订阅以进行重新初始化后，下一次合并代理程序或分发代理程序运行时，将在订阅服务器上应用新的快照。

复制代理程序检查代理程序

检测未活动地记录历史信息的复制代理程序默认情况下，此代理程序每隔 10 分钟运行一次，如果作业步骤失败，则将此失败写入 Windows 事件日志中。

请参见

匿名订阅

为事务复制制定计划

订阅停用和过期


查看代理程序历史记录

复制监视器"代理程序历史记录"对话框显示选定代理程序的会话摘要。当需要检查代理程序最近的活动，快速评估性能或检测错误趋向时这些记录将非常有用。为复制代理程序存储的历史记录信息的数量取决于分发保持期和历史记录清除代理程序运行的频率。

代理程序历史记录也包括几个会话历史记录（或视图）上的几个预定义的筛选，例如：

  • 全部会话。

  • 最近 24 小时内的会话。

  • 最近两天内的会话。

  • 最近七天内的会话。

  • 出错的会话。

下列历史记录列显示在"代理程序历史记录"对话框中。

列 | 值
状态 | "成功"图标；"错误"图标；"正在进行"图标（给定时间内只能有一个正在进行的会话）。
操作数 | 每个会话中操作的数量。
动作消息 | 如果会话在出错的情况下结束，则将报告最高级别的错误。
开始时间 | 此会话开始的时间。
结束时间 | 此会话结束的时间。
持续时间 | 代理程序会话的持续时间。
传送速率 | 已传送的命令与代理程序持续时间的比率。如果代理程序仍在运行，则该值反映了自会话开始后累积的计数。
延迟 | 从发布服务器上出现此操作到该操作传播到订阅服务器上之间的滞后时间。如果代理程序仍在运行，则该值反映了自会话开始后累积的计数。无法用于快照代理程序或合并代理程序。
转换数 | 在代理程序会话过程中传送的事务的总数。无法用于合并代理程序。
命令数 | 在代理程序会话过程中传送的命令的总数。无法用于合并代理程序。
Publisher_Inserts | 发布服务器上发生插入的次数。仅用于合并代理程序。
Publisher_Updates | 发布服务器上发生更新的次数。仅用于合并代理程序。
Publisher_Deletes | 发布服务器上发生删除的次数。仅用于合并代理程序。
Publisher_Conflicts | 发布服务器上发生冲突的次数。仅用于合并代理程序。
Subscriber_Inserts | 订阅服务器上发生插入的次数。仅用于合并代理程序。
Subscriber_Updates | 订阅服务器上发生更新的次数。仅用于合并代理程序。
Subscriber_Deletes | 订阅服务器上发生删除的次数。仅用于合并代理程序。
Subscriber_Conflicts | 订阅服务器上发生冲突的次数。仅用于合并代理程序。


处理代理程序错误

可以在复制监视器上监视当前的活动和每个复制代理程序的任务历史记录的详细信息。在代理程序运行时，它会将它的活动和消息的详细信息写入分发服务器的历史记录表中。

如果该代理程序在会话过程中遇到错误，可以将这些错误显示出来。错误的详细信息显示在"错误详细信息"对话框中。也可以在"会话详情"对话框中显示错误信息，或是右击某个代理程序，然后单击"错误详细信息"命令。

复制代理程序错误状态在 SQL Server 企业管理器中会用图标在复制监视器下的每个代理程序和每个节点上显示出来。若要让图标正确地反映复制代理程序的状态，必须手动刷新节点或启用自动刷新。

可以使用"刷新速率和设置"对话框执行以下任务：

  • 启动或禁用控制台目录树或细节窗格的自动刷新。

  • 指定控制台目录树或细节窗格的刷新周期（以秒为单位）。

  • 指定重新启动复制代理程序的非活动阈值。

  • 指定用于用于复制性能的 Windows NT 性能监视器或 Windows 2000 系统监视器文件设置。

在发布或代理程序视图上进行选择时，也可以自定义显示在细节窗格中的列。使用"选择列"对话框来选择要显示的列。

当焦点位于以下任意一个节点时，可以使用"选择列"对话框选择要显示的列：

  • 事务、快照或合并发布

  • 快照代理程序

  • 日志读取器代理程序

  • 分发代理程序

  • 合并代理程序
跳过事务复制中的错误

在事务复制过程中，可以指定在分发进程中可以跳过的错误。通常，当分发代理程序以连续模式运行，并且在遇到错误时，该代理程序和分发进程都会停止。通过指定不希望干扰复制的预期的错误或错误，该代理程序将记录这些错误信息，然后继续运行。

跳过错误最典型的方法是使用标题为"遇到数据一致性错误时继续"的分发代理程序配置文件。若要使用此配置文件，请右击分发代理程序，单击配置文件，然后选择此配置文件。然后，分发代理程序将跳过错误 2601、2627 和 20598。还可以创建自己的代理程序配置文件并利用 –SkipErrors 参数指定要跳过的错误。有关创建配置文件的更多信息，请参见代理程序配置。

注意 在典型的复制过程中，不应遇到任何需要跳过的错误。只有在预料到错误并且不希望它们影响复制这种独特的情况下（例如，在日志传送过程中由于故障转移到第二个发布服务器时）才能在事务复制过程中跳过错误。要谨慎使用跳过错误，并且应在了解了这些错误是什么，它出现的原因以及为什么要跳过它而不是解决它这些问题之后再使用跳过错误。

可以使用 SQL 分发 ActiveX® 控件在代理程序配置中指定应该跳过的错误（使用分发代理程序配置中的 –SkipErrors 参数），或者使用用于分发代理程序的命令行中的 –SkipErrors 参数指定。

例如，如果分发代理程序返回一个重复键违规错误，但您希望分发进程继续执行并且只是记录这条错误信息，则可以利用 –SkipErrors 命令行参数指定应跳过的错误数。

通常，分发代理程序是一个服务于多个发布和多个项目的共享代理程序。如果在该代理程序上指定了 –SkipErrors 参数，则使用这个分发代理程序的所有发布都将受影响。如果希望在某个指定的发布上跳过一个错误，请使用独立代理程序设置该发布，然后为该代理程序指定 –SkipErrors 命令行参数。

在代理程序命令行上指定 –SkipErrors 参数

  1. 在分发服务器上，展开"复制监视器"文件夹，单击"Distribution Agents"文件夹，右击某个代理程序，然后单击"代理程序属性"命令。

  3. 在"步骤"选项卡上，双击运行代理程序步骤。

  4. 如果此代理程序遇到错误，则在命令文本框中键入 –SkipErrors 并指定要跳过的错误数目（错误与错误相分隔；每个错误数之间用冒号分隔）。

更改复制监视器刷新速率和设置

企业管理器

企业管理器

请参见

SkipErrors 属性


远程代理程序激活

远程代理程序激活通过在另一台计算机上运行分发代理程序或合并代理程序，然后使用分布式组件对象模型 (DCOM)远程激活该代理程序，这允许减少分发服务器或订阅服务器上处理的数量。

可以在强制订阅或请求订阅上实施远程代理程序激活。对于每种订阅类型，需要执行以下任务：

  • 指明代理程序将在强制订阅或请求订阅向导中运行的位置。

  • 配置 DCOM 以远程激活代理程序。

  • 配置或创建指明代理程序运行位置的订阅。

建议在配置远程代理程序激活前安装定期强制订阅或请求订阅。不能在本地计算机上配置远程代理激活（例如，当订阅服务器和分发服务器驻留在同一计算机上时）。

Microsoft Windows NT® 4.0 或 Windows® 2000 上运行的 SQL Server™ 2000 支持远程代理激活，但在 Windows 98 上不支持。

远程代理程序激活和强制订阅

当分发服务器和订阅服务器都有连续可靠的连接时，强制订阅允许集中管理订阅。强制订阅为组织控制订阅发布的人员以及时间提供了便利。强制订阅对订阅服务器需要即时获得更新信息的情形也很有用处。

对于强制订阅，分发代理程序（用于快照复制或事务复制）或合并代理程序（用于合并复制）在分发服务器上运行；但是当强制订阅的数目增加时订阅服务器可能会超载。

远程代理程序激活使您得以将代理程序活动卸载到订阅服务器上，这将减少分发服务器上的处理量。使用 DCOM，可以远程激活代理程序并增加分发服务器可以处理的强制订阅的数目。

使用用于远程代理程序激活的 DCOM 与强制订阅时，分发服务器首先建立到订阅服务器的连接。连接建立后，分发服务器上的 SQL Server 代理程序使用 DCOM 激活订阅服务器上的分发代理程序或合并代理程序。

远程代理程序激活和请求订阅

请求订阅提供本地管理订阅同步的能力。这对如下的人员和机构很重要：

  • 经常外出且需要连接网络同步数据的人员。

  • 需要管理订阅同步的远程办公室，因为这些办公室与发布服务器或分发服务器没有可靠的、连续的连接。

对于请求订阅，分发代理程序或合并代理程序运行于订阅服务器上。通过将分发代理程序或合并代理程序活动卸载到分发服务器上并使用 DCOM 激活代理程序，可以减少订阅服务器上的处理量。

使用用于远程代理程序激活的 DCOM 与请求订阅时，订阅服务器首先建立到分发服务器的连接。连接建立后，订阅服务器上的 SQL Server 代理程序使用 DCOM 激活分发服务器上的分发代理程序或合并代理程序。

订阅安全性要求

创建订阅时，订阅代理程序或合并代理程序在 SQL Server 代理程序的安全上下文中运行。使用 SQL Server 代理程序的安全上下文时，分发代理程序建立到订阅服务器、分发服务器，必要时甚至到快照文件夹的连接。合并代理程序建立到订阅服务器、分发服务器、发布服务器，必要时甚至到快照文件夹的连接。可以查看订阅的安全要求，就好象 SQL Server 代理程序正在建立所有连接一样。

激活远程计算机上的代理程序后，此代理程序将在通过 DCOM 配置的安全上下文中运行。当为远程代理程序激活配置 DCOM 时，需要输入用户帐户用于激活分发代理程序或合并代理程序。最好提供一个与在原始激活计算机上的 SQL Server 代理程序帐户相同的自定义帐户。

创建订阅时启用远程代理程序激活

创建强制订阅或请求订阅后时，通过指定代理程序运行的位置启用远程代理程序激活。如果订阅服务器与分发服务器是同一个，则在强制订阅或请求订阅向导中看不到在其它服务器上运行代理程序的选项。

重要 指定在创建订阅时代理程序应在何处运行后，如果指定订阅应自动同步并且还没有为远程代理程序激活配置 DCOM 时，同步可能失败。

配置用于远程代理程序激活的 DCOM

DCOM 通过扩展组件对象模型 (COM) 来处理网络协议的低级别详细信息，以支持不同计算机、LAN、WAN 或 Internet 上对象之间的通讯。配置 DCOM 时，应考虑 SQL Server 代理程序现有的安全性以及将要使用的订阅类型。

对于强制订阅：

  • 使用远程代理程序激活更改现有强制订阅或创建新强制订阅前，必须在订阅服务器上配置 DCOM。

  • 必须具有对订阅服务器的管理特权。

  • 必须允许分发服务器上的 SQL Server 代理程序使用订阅服务器上的 DCOM。

  • 需要通过 DCOM 指定帐户或安全上下文，以允许分发代理程序或合并代理程序在订阅服务器上运行。

对于强制订阅：

  • 使用远程代理程序激活更改现有请求订阅或创建新的请求订阅前，必须在订阅服务器上配置 DCOM。

  • 必须在分发服务器上有管理特权。

  • 必须允许订阅服务器上的 SQL Server 代理程序使用分发服务器上的 DCOM。

  • 需要通过 DCOM 指定帐户或安全上下文，以允许分发代理程序或合并代理程序在分发服务器上运行。

配置 DCOM 以远程运行分发代理程序

Windows

企业管理器

配置 DCOM 以远程运行合并代理程序

Windows

企业管理器

为远程代理程序激活配置订阅

在订阅服务器或分发服务器上配置 DCOM 后，可以更改现有订阅或创建新订阅以便使用远程代理激活。创建新订阅时，可以验证 DCOM 配置是否正确。

重要 应该在分发服务器上为强制订阅的或在订阅服务器上为请求订阅的执行订阅配置。若在不正确的计算机上配置订阅，则如果安全上下文没有足够的权限启动远程位置上的分发代理程序或合并代理程序时，配置将失败。

启用强制订阅以使用远程代理程序激活

企业管理器

企业管理器

SQL-DMO

启用请求订阅以使用远程代理程序激活

企业管理器

企业管理器

SQL-DMO

配置现有订阅以使用远程代理程序激活

企业管理器

企业管理器

SQL-DMO


复制警报

SQL Server 企业管理器和 SQL Server 代理程序提供了通过警报监视事件（如复制代理程序错误）的方法。SQL Server 代理程序监视 Microsoft® Windows NT® 4.0 或 Microsoft Windows® 2000 应用程序日志，监视限定为其中一种定义警报的事件。如果发生这类事件，SQL Server 代理程序通过执行一项已定义的任务，或者通过向指定的操作员发送电子邮件或寻呼机消息自动做出响应。

可选择分发服务器和使用复制监视器显示服务器上所有与复制相关的警报的列表。

Microsoft SQL Server™ 2000 包括一组复制的预定义警报。可以配置这些警报以通知操作员有关复制状态。然后操作员可以手工干预复制进程或配置自动响应作业。支持自动响应作业的警报将其它信息输入 msdb..sysreplicationalerts 系统表。自定义 Transact-SQL 作业在响应警报时可以使用 sysreplicationalerts 中的信息。

当计算机配置为分发服务器时，需安装下列警报：

消息 ID | 预定义警报 | 导致警报激发的条件 | 在 sysreplicationalerts 中输入其它信息
14150 | 复制：代理程序成功 | 代理程序成功关闭。 | 是
14151 | 复制：代理程序失败 | 代理程序关闭时出现错误。 | 是
14152 | 复制：代理程序重试 | 重试操作不成功后关闭代理程序（代理程序遇到如服务器不能使用、死锁、连接失败或超时故障等错误）。 | 是
14157 | 复制：订阅清理 | 删除不活动的订阅。 | 否
20574 | 复制：订阅服务器数据验证失败 | 分发或合并代理程序数据验证失败。 | 是
20575 | 复制：订阅服务器已通过数据验证 | 分发或合并代理程序通过数据验证。 | 是
20572 | 复制：验证失败后重新初始化订阅 | 响应作业"数据验证失败时重新初始化订阅"成功重新初始化订阅。 | 否

查看应用程序日志

若要查看 Microsoft® Windows NT® 4.0 或 Windows® 2000 应用程序日志，请使用 Windows NT 4.0 或 Windows 2000 事件查看器。如果您是 Windows NT Administrators 组的成员，还可以查看远程应用程序日志。应用程序日志包含计算机上的 SQL Server 错误信息以及所有活动的信息。

当使用 Windows NT 应用程序日志时，每个 SQL Server 会话都将新事件写入现有应用程序日志；可以筛选日志只保留指定事件。与 SQL Server 错误日志不同，每次启动 SQL Server 时并不创建新的应用程序日志；不过，可以指定已记录的事件可以保留的时间长度。


自动响应警报

通常，当警报发生时，能够帮助您理解引起警报的原因以及应采取什么适当措施的唯一信息就包含在警报信息中。创建响应警报的作业非常耗时，因为首先必须解析和分析消息中的信息，然后将相关信息插入 Transact-SQL 命令中。Microsoft® SQL Server™ 2000 通过提供有关警报的其它信息，使自动响应作业更加容易。此信息存储在 sysreplicationalerts 系统表中。除了提供详细信息外，sysreplicationalerts 还提供以某种易由自定义程序使用的格式分析过的信息。

例如，如果订阅服务器 A 上的 pubs 数据验证检查失败，则SQL Server 将触发警报消息 20574，通知发生了该错误。接收到的消息可能是：

"Subscriber 'A', subscription to article 'authors' in publication 'pubs' failed data validation."

根据警报信息创建响应作业时，必须手工分析该消息中的订阅服务器名称、项目名称、发布名称和错误。不过，因为分发代理程序将相同的信息写入 sysreplicationalerts 中，以及如代理程序类型、警报时间、发布数据库、订阅服务器数据库和发布类型的详细信息，所以响应作业可以直接查询表中相关的信息。虽然无法将确切的行与警报的特定实例相关联，但是表有 status 列，可用于跟踪服务条目。此表中的条目保留到历史记录保持期结束。

例如，假设用 Transact-SQL 创建为警报消息 20574 提供服务的响应作业，则可以使用下列逻辑：

declare hc cursor local for select publisher, publisher_db, publication, publication_type, article, subscriber,
      subscriber_db, alert_id from
      msdb..sysreplicationalerts where
      alert_error_code = 20574 and status = 0
      for read only
open hc
fetch hc into  @publisher, @publisher_db, @publication, @publication_type, @article, @subscriber, subscriber_db, @alert_id
while (@@fetch_status <> -1)
begin
/* Do custom work  */
/* Update status to 1, which means the alert has been serviced. This prevents subsequent runs of this job from doing this again */
update msdb..sysreplicationalerts set status = 1 where alert_id = @alert_id
 fetch hc into  @publisher, @publisher_db, @publication, @publication_type, @article, @subscriber, @subscriber_db, @alert_id
end
close hc
deallocate hc


预定义响应作业

只要将计算机配置为分发服务器，下列预定义警报响应作业就安装好了。

预定义响应作业 | 响应警报 | 对策
数据验证失败时重新初始化订阅 | 复制：订阅服务器数据验证失败 | 重新初始化所有记录了 sysreplicationalerts 及 alert_error_code = 20574 的订阅。 如果为事务发布，则只重新初始化失败的项目。如果为合并发布，则重新初始化整个发布。

说明 Microsoft® SQL Server™ 2000 中包括的响应作业只提供给众所周知的响应，并可作为编写自己响应作业的示例。提供的响应作业在安装好后即与警报不相关。必须手工配置警报以调用适当的响应作业。

请参见

SQLServer 代理服务

验证已复制的数据


订阅停用和过期

如果在指定时间内订阅未同步，则可以停用订阅或订阅过期。发生什么操作取决于复制的类型和超过的保持期。

快照和事务复制订阅

如果在指定的时间内订阅未同步，则订阅可能被删除或自动标记为停用并要求重新初始化。订阅是否过期并被删除，或者是否被标记为停用并要求初始化，取决于它是否超过了发布的订阅过期属性或分发数据库的最大事务保持属性，以及是否为匿名订阅。

订阅停用

当订阅在分发数据库的最大事务保持期内未同步（例如，订阅的分发代理程序没有运行或无法连接订阅服务器），且分发数据库中存在等待拾取的更改时，在分发服务器上运行的分发清理代理程序将订阅标记为停用。默认情况下，事务复制的最大事务保持期为 72 小时，分发清理代理程序每隔 10 分钟运行一次。

如果发布服务器上无活动，即使订阅未在分发保持期内同步，也不会停用订阅。当订阅标记为非活动后，分发代理程序将失败，同时显示错误信息，通知用户已经停用订阅并需要对其重新初始化。然后订阅需要重新初始化，并且在订阅服务器上应用新的快照以后该订阅的复制才能继续。

除了停用在分发数据库的最大事务保持期内未同步的订阅外，分发清理代理程序还负责清理分发数据库中已随署名订阅传送到订阅服务器上的事务。

如果使用匿名订阅，则该代理程序将只清除分发数据库中已超过最大事务保持期的事务。在使用匿名订阅时，分发清理代理程序在保持期结束前不清理分发数据库中的事务，这是因为它不能确定使用匿名订阅的订阅服务器是否已接收到分发数据库中存储的事务。如果将保持期设置为很高的值，且正在使用匿名订阅，则分发数据库将因此增长很大。

修改分发服务器或者添加或修改分发数据库

企业管理器

企业管理器

订阅过期

如果订阅在发布的订阅过期时间内未同步（订阅的分发代理程序没有运行或无法连接订阅服务器），则订阅将过期，并由发布服务器上运行的过期订阅清理代理程序除去。

对于强制订阅，过期订阅清理代理程序（运行于发布服务器上）将删除发布服务器上的订阅以及与过期订阅相关的分发代理程序。这一事件将被记录为过期订阅清理代理程序的历史记录消息。需要为订阅服务器重新创建订阅以继续接收来自发布服务器的更改。

对于请求订阅，不能删除分发代理程序和订阅服务器上的订阅。下一次运行分发代理程序时，它将失败，并返回错误信息，指明与代理程序相关的订阅已过期并被删除。不过，还有不同的消息和需要采取的操作以便继续在订阅服务器上接收数据。如果使用署名订阅，则订阅服务器上将显示消息，说明与代理程序相关的订阅已被删除并需要重新创建。

同样也需要在订阅服务器上删除署名订阅并重新创建。如果正在使用匿名订阅，订阅服务器上将显示消息，说明已删除与代理程序相关的订阅，且随后的代理程序失败后，需要在订阅服务器上重新初始化订阅，以便在订阅服务器上应用新快照。

在发布属性的"常规"选项卡上指定订阅的发布保持期。事务发布的默认保持期为 336 小时。

设置发布保持期为"0"表示订阅永不会过期和永不会删除。

重要 如果订阅在最大分发保持期内未进行同步处理，则分发清理代理程序仍会停用订阅。

如果不想让订阅过期，则将发布保持期设置为"0"，或者禁用过期订阅清理代理程序。如果不想停用订阅，同时考虑到可能对分发数据库大小的影响，应将最大分发保持期设置为大于默认的 72 小时。

合并复制订阅

在默认情况下合并发布的订阅发布保持期设置为 14 天。如果同步之间的间隔时间大于此值，则可以指定：

  • 较长的保持期。

  • 订阅永不过期。

如果将保持期值设得很高，Microsoft® SQL Server™ 2000 在保持期结束前将无法清除发布和订阅数据库中的元数据。

将合并复制的保持期值设置得较低有助于减少合并跟踪表的增长。最好使用较低的设置（例如 14 天），前提是能够可靠地预测所有订阅服务器将比该保持期更频繁地定期进行同步处理。

任何再次发布者的保持期都必须设置为等于或小于在原发布服务器上设置的保持期。建议再次发布者上的保持期设置为与具有相同数据的所有发布服务器相同的值，以取得管理这些设置时的方便和一致性。

订阅停用

如果某个订阅已经停用，则过期订阅清理代理程序将删除此订阅。该代理程序每天运行一次。在清理订阅过程当中或在超出保持期以后运行合并代理程序时，将订阅标记为已过期。

过期订阅清理代理程序将查找在发布保持期内合并代理程序未运行的所有署名订阅和匿名订阅，删除这些订阅，并记录历史消息，指出订阅已过期并已删除。

对于强制订阅，过期订阅清除代理程序（在发布服务器和分发服务器上运行）将删除发布服务器上的订阅以及与过期的订阅相关的分发代理程序。对于请求订阅，无法删除订阅服务器上的合并代理程序和订阅。合并代理程序将失败，并会返回一个错误，指出与该代理程序相关的订阅已经过期。在代理程序失败之后可以重新初始化订阅服务器上的匿名订阅，以便在订阅服务器上应用新的快照。但是，需要删除并重新创建署名订阅。

即使过期订阅清理代理程序未运行并且订阅尚未清理，如果上一次同步是在发布保持期内进行的，则合并代理程序仍将失败。

将发布保持期设置为"0"意味着订阅将永不过期且不被删除；不过，如果订阅在最大分发保持期内未同步，则分发清理代理程序仍可能停用订阅。订阅的发布保持期在发布属性的"常规"选项卡上指定。


验证已复制的数据

因为订阅服务器上的数据与发布服务器上的数据不同步，所以复制过程中会经常遇到问题。Microsoft® SQL Server™ 2000 复制在复制过程发生时可以验证订阅服务器上的已复制数据，以确保订阅服务器上的数据与发布服务器上的数据匹配。

在测试是否已经接收并正确应用数据前，不必停止对发布服务器的更新并等待订阅服务器完全同步。可以验证快照复制、事务复制或合并复制中的数据。可以对特定订阅或某一发布的所有订阅执行验证。

内嵌数据验证的工作机制

SQL Server 通过计算发布服务器上的行数和/或校验值，并将这些值与订阅服务器上的行数和/或校验值比较来验证数据。为整个发布表计算一个值，为整个订阅表计算一个值，但计算不包括 text 或 image 列中的数据。

执行计算过程中，共享锁临时放在进行行数或校验值计算的表上，不过计算很快完成，共享锁很快被删除，这一过程通常只需几秒钟。

验证已复制的数据时，须考虑如下事项：

  • 验证失败是否真是一个问题？某些验证失败可以解释，可能无需重新初始化。

  • 如果验证失败确实是一个问题，应考虑使用不同的选项同步化数据，包括完整重新初始化、部分初始化某一先前状态或手工更新数据以使之同步。
验证事务复制的已复制数据

可以在事务复制、使用即时更新或排队更新的订阅或在数据的水平和垂直部分上执行验证。

可以选择下面任何一种验证方法：

  • 仅行数验证。

  • 行数验证和校验值验证。

  • 行数验证和二进制校验值验证（只能在运行 Microsoft SQL Server 2000 的订阅服务器上使用）。

可以使用 SQL Server 企业管理器或 Transact-SQL 系统存储过程配置验证。不管使用哪一种配置方式，运行验证时，将在发布服务器上执行存储过程。存储过程 sp_publication_validation 调用正被验证的每个项目的 sp_article_validation，而 sp_article_validation 调用每个表的 sp_table_validation，然后生成行数或校验值计算。命令 sp_table_validation 作为一个复制命令发布到使用日志读取器代理程序和分发代理程序的订阅服务器上，然后在订阅服务器上进行计算。

说明 运行 SQL Server 6.5 的订阅服务器只能使用仅行数验证，不能使用校验值验证。如果订阅服务器正在运行 SQL Server 2000，则可以根据二进制校验值计算进行验证。

通过创建调用 sp_publication_validation 或 sp_article_validation 的 Transact-SQL 作业，按时对已复制数据进行验证。

除非是 sysadmin 或 db_owner 角色的成员，否则必须对项目中使用的基表中的所有列具有 SELECT 权限（即使已将项目垂直分区），以便执行 sp_publication_validation。

校验值验证

当使用校验值时，32 位冗余检查 (CRC) 将逐列进行，而不是在数据页的物理行上进行。这使得表中的列可以任意顺序在数据页上排列，而对同一行计算的 CRC 值不变。发布上有行（水平）筛选或列（垂直）筛选时可以使用校验值验证。因为在验证较大的数据集时，校验值可能需要大量的处理器资源，所以，可能希望将验证安排在复制使用的服务器上的活动量最小时进行。

运行 SQL Server 7.0 的订阅服务器使用 SQL Server 7.0 中发布的校验值例程，这些例程生成的 CRC 值与使用 SQL Server 2000 生成的 CRC 值不同。SQL Server 7.0 中发布的校验值例程无法验证垂直分区或列偏移量不同的逻辑表结构（因为 DROP 和 ADD 列的 ALTER TABLE 语句不同）。

设置 Rowcount_only 参数

@rowcount_only 参数的数据类型为 smallint，接受下列值。

值 | 描述
0 | 执行 SQL Server 7.0 中发布的校验值功能。
1（默认值） | 仅执行行数检查。
2 | 执行 SQL Server 2000 中发布的校验值功能。

运行 SQL Server 7.0 的订阅服务器将此参数用作 bit 数据类型，而不是 smallint 数据类型，所以 SQL Server 将把此参数解释为"ON"。在运行 SQL Server 7.0 的订阅服务器上将此参数值设置为 2 时，将导致在订阅服务器上执行仅行数验证。如果需要为运行 SQL Server 7.0 的订阅服务器运行校验值验证，则将该参数设置为 0。运行 SQL Server 2000 的订阅服务器可以使用此同一值 (0)，但是校验值功能可能受 SQL Server 7.0 限制。

使用 SQL Server 企业管理器验证事务数据

  1. 在分发服务器上，展开"复制监视器"，展开"发布服务器"，然后展开一个特定的发布服务器。

  2. 右击事务发布，然后单击"验证订阅"命令。

  3. 选择验证所有订阅还是只验证特定订阅，若验证特定订阅，应在文本框中选取。

  4. 若要选择验证类型，单击"验证选项"。

  5. 选择根据已被缓存的表信息计算快速行数，还是通过直接查询表来计算实际的行数，或是计算快速行，且如果找到差异则计算实际的行数。

  6. 还可以选择启用比较校验值来验证数据、二进制校验值（如果订阅服务器正在运行 SQL Server 2000），还可以选择在完成验证后停止分发代理程序。

使用 Transact-SQL 系统存储过程验证事务数据

  • 若要验证发布中的所有项目并指定仅行数验证（默认）或校验值验证，请执行 sp_publication_validation。这将为发布中的每个项目调用 sp_article_validation。

  • 若要验证特定项目并指定仅行数验证或校验值验证，请执行 sp_article_validation。
验证和即时更新

在即时更新订阅上使用内嵌发布验证 (sp_publication_validation) 时，订阅服务器上的更改会导致发布验证在一段时间内失败。这一情况发生在发布服务器上已运行了发布验证之后，订阅服务器上可执行发布验证之前，在订阅服务器上进行数据更改之时。

使用事务复制（没有可更新的订阅）只能在发布服务器上进行更改，这样，执行 sp_publication_validation 后对发布服务器所做的更改，将在订阅服务器上运行验证后应用于订阅服务器。

不过，使用即时更新订阅时，可以在订阅服务器上修改数据。在发布服务器上运行验证后，对订阅服务器所做的更改将立即在订阅服务器上反映出来。因为在订阅服务器上进行更改之前，校验值和行数计算均基于发布表中的数据，所以验证将失败。为避免发生这种情况，执行验证期间应停止在订阅服务器上的所有数据修改工作。

验证事务复制的已复制数据时需要考虑的因素

下面是对事务复制进行验证时需要考虑的限制因素：

  • 可转换订阅不支持校验值验证，因为发布服务器与订阅服务器之间很可能发生校验值转换，而且校验值不会相同。

  • 配置为 DTS 水平分区的项目不支持行数验证，因为筛选条件保存为 DTS 包的一部分，而不像复制筛选位于发布服务器的视图中。

  • 对于异类订阅服务器，不支持对已复制数据的验证。
验证失败和警报

如果对发布服务器数据和订阅服务器数据的验证失败，则可以配置复制警报以通知失败消息（发送电子邮件消息或发送寻呼消息），还可以使订阅自动重新初始化。

配置验证失败的订阅自动重新初始化

  1. 在分发服务器上，展开"复制监视器"，单击"复制警报"，右击"复制"："订阅的数据验证失败"警报，然后单击"属性"命令。

  2. 在"常规"选项卡上，选择"启用"复选框。

  3. 在"响应"选项卡上，选择"执行作业"，然后在下拉框中，单击"重新初始化存在数据验证失败的订阅"。

  4. 若要向事件日志发送重新初始化确认消息，请右击"复制"："验证失败后订阅重新初始化"警报，单击"属性"。

  5. 在"常规"选项卡上，选择"启用"复选框。
验证合并复制的已复制数据

使用 SQL Server 企业管理器时，可以选择验证合并发布的所有订阅。使用 Transact-SQL 系统存储过程时，可以验证合并发布的所有订阅或指定订阅。

可以选择下列任何一种验证方法：

  • 仅行数验证

  • 校验值验证

若要请求验证合并订阅服务器上的已复制数据，可以使用：

  • SQL Server 企业管理器，使您可以验证发布的所有订阅。

  • 指定 –Validate 参数的合并代理程序命令行或合并代理程序命令提示实用工具。如果合并代理程序以连续模式运行，则在代理程序命令提示符下运行的 –Validate 参数将处理验证，直到达到 -ValidationInterval 值。合并过程完成后开始验证。

  • sp_validatemergepublication Transact-SQL 系统存储过程。该存储过程将处理整个发布范围内的验证，一次性地验证所有订阅（强制、请求和匿名）。

  • sp_validatemergesubscription Transact-SQL 系统存储过程，它在指定订阅的合并代理程序上运行一次验证。

    运行带 -Validate 参数的合并代理程序将导致 SQL Server 临时锁定订阅服务器表，以防止进一步的更改。SQL Server 然后计算订阅服务器和发布服务器上每个已复制表的行数或校验值。如果有差异，SQL Server 将锁定发布服务器上有差异的表，所有新数据更改则下载到订阅服务器上。下载完毕后，SQL Server 重新计算订阅服务器和发布服务器上的行数或校验值，并再次比较它们。完成验证后，SQL Server 删除订阅服务器和发布服务器表上的所有锁。

    可以通过在指定时间将 -Validate 添加到合并代理程序配置文件中来定期验证数据。因为内嵌验证可能会消耗一定时间，或者可能导致发布服务器和订阅服务器之间的意外争夺，所以应当在发布服务器和订阅服务器上活动最少时安排执行验证。

  • 如果合并验证失败，则可以通过使用 SQL Server 企业管理器配置名为"复制：订阅服务器数据验证失败"的复制警报来响应失败。这样，您就得到了失败通知，或者可以重新初始化订阅以确保订阅服务器上的数据与发布服务器上的数据同步。重新初始化订阅时应当小心，因为它可能消耗发布服务器、分发服务器和订阅服务器上大量资源，初始快照在订阅服务器上重新应用时，用户可能无法更新数据。

当验证合并复制时，其它选项将验证数据，如果数据未收敛，其它选项将处理订阅的部分重新初始化。此部分重新初始化将使订阅服务器回到前面数据处于同步状态的某一阶段。使用 SQL Server 企业管理器或 sp_resyncmergesubscription 中的"验证"和"重新同步订阅"选项时，可以重新同步合并订阅到指定的已知验证状态。这使您得以强制收敛或同步化订阅数据库到特定的即时点（如上次成功验证时）或到指定的日期。使用此方法重新同步订阅时，不重新应用快照。

使用 SQL Server 企业管理器验证合并数据

  1. 在分发服务器上，展开"复制监视器"，展开"发布服务器"，然后展开特定的发布服务器。

  2. 右击合并发布，然后单击"验证所有订阅"。

  3. 选择使用仅行数、行数和校验值或行数和比较二进制校验值验证方法（所有订阅服务器都必须运行 SQL Server 2000 才能使用此选项），验证已复制的数据。验证将发生在下一次合并代理程序运行时，其结果将显示在复制监视器中。

验证并重新同步化订阅

  • 展开"复制监视器"，展开"发布服务器"文件夹，然后展开已注册的发布服务器。右击发布，然后单击"验证并重新同步化订阅"。

  • 在发布数据库上的发布服务器或订阅数据库上的订阅服务器上执行 sp_resyncmergesubscription。

使用 Transact-SQL 系统存储过程验证合并数据

  • 为了在下一次合并代理程序运行时标记所有要验证的署名订阅和匿名订阅，请执行 sp_validatemergepublication。

  • 若要标记要验证的特定订阅，请执行 sp_validatemergesubscription 或 sp_validatemergepullsubscription。

使用合并代理程序命令行参数验证合并数据

  1. 在分发服务器上，展开"复制监视器"文件夹，单击"合并代理程序"文件夹，右击某个代理程序，然后单击"代理程序属性"命令。

  2. 在"步骤"选项卡上，双击运行代理程序步骤。

  3. 在命令文本框中键入 –validate，并为仅行数验证指定 1，为行数验证和校验值验证指定 2。验证将发生在下一次合并代理程序运行时，其成功或失败消息都将记录在合并代理程序历史记录中。

  4. 如果希望调度验证，请将合并代理程序命令行上的参数 –ValidateInterval 设置为希望验证发生的分钟数（默认设置为每 60 分钟验证一次）。


复制和异类数据源

Microsoft® SQL Server™ 2000 提供将数据复制到任何异类数据源的能力，条件是这些异类数据源在 Microsoft Windows® 2000、Microsoft Windows NT® Server 4.0 或 Windows 98 操作系统上提供 32 位的 ODBC 或 OLE DB 驱动程序。此外，SQL Server 2000 可以接收某些数据副本，这些数据副本是从 Microsoft Access、Microsoft Exchange、Oracle、DB2 Universal、DB2/MVS，以及 DB2 AS400 复制而来的。

异类订阅服务器

发布到异类数据源允许那些拥有不同数据库的公司可以继续将 SQL Server 2000 提供给那些使用其它数据库的个人或办公室。

将数据发布到异类数据源最简单的方法就是使用 OLE DB 或 ODBC，并且创建一个从发布服务器到 OLE DB 或 ODBC 订阅服务器的强制订阅。

SQL Server 2000 支持在 SQL Server 的不同版本间进行复制，并支持复制到运行 Microsoft SQL Server 2000 Windows CE 版 (SQL Server CE) 的订阅服务器。有关更多信息，请参见不同 SQL Server 版本间的复制和使用 SQL Server 2000 Windows CE 版本进行复制。

异类发布服务器

SQL Server 2000 可以订阅从 Oracle、DB2、Access 以及其它数据源中复制的快照或事务数据。这样，如果有的公司计划利用 SQL Server 来布署大的数据库或数据仓库，或者想布署 Internet 及 Intranet 应用程序，那么这些公司就可以访问各种数据源。然后，可以使用复制将数据合并进 SQL Server 2000，然后将它们放入为 SQL Server 2000 Analysis Services 设计的数据集市、数据仓库或多维数据库中。

若要执行由异类数据源发布到 SQL Server 2000 应用程序的快照或事务复制，请在 SQL Server 中配置第三方软件或使用用 SQL-DMO 和复制分发服务器接口生成的应用程序。

有关更多信息，请参见设计来自异类数据源的复制。


异类订阅服务器

Microsoft® SQL Server™ 2000 支持发布到异类数据源，条件是这些异类数据源在 Microsoft Windows® 2000、Microsoft Windows NT® 4.0 以及 Microsoft Windows 98 上提供 32 位 ODBC 或 OLE DB 驱动程序。SQL Server 的异类订阅服务器包括：

  • Microsoft Access 数据库。

  • Oracle 数据库。

  • 异类订阅服务器上的其它数据库，但这个异类订阅服务器必须符合 SQL Server ODBC 或 OLE DB 订阅服务器的条件。

将数据发布到异类订阅服务器最简单的方法就是使用 ODBC，并且创建一个从发布服务器到 ODBC 订阅服务器的强制订阅。作为一种替代方法，您也可以创建一个发布，然后再创建一个应用程序，该应用程序带有一个嵌入式分发控件。该嵌入式控件实现从订阅服务器到发布服务器的请求订阅。就 ODBC 订阅服务器而言，订阅数据库对于正在执行的复制没有管理能力。

ODBC/OLE DB 驱动程序支持

各种异类数据源的 ODBC 驱动程序及 OLE DB 提供程序都包含在 SQL Server 2000 光盘中。

支持到异类订阅服务器的复制的存储过程

SQL Server 2000 提供下面这些存储过程及扩展存储过程，以支持到 ODBC 订阅服务器的复制。

过程 | 描述
sp_enumdsn | 对于以特定 Windows NT 4.0 或 Windows 2000 用户帐户运行的服务器，此过程为该服务器报告所有已定义的 ODBC DSN。
sp_dsninfo | 如果安装了复制，那么从与当前服务器相关联的复制分发服务器检索 ODBC DSN 信息。

说明 SQL Server 企业管理器（推荐的工具）自动地使用这些存储过程来建立到 ODBC 订阅服务器的复制。只有当您并未使用 SQL Server 企业管理器时，才会直接使用这些存储过程。

异类订阅服务器的复制限制

对于到异类订阅服务器的复制有如下限制：

  • 复制到异类订阅服务器的表将采用异类数据源的表命名规则。

  • 在订阅服务器中创建表的架构文件在表名两旁不加引号，而且新表名依赖于创建它们的异类订阅服务器的行为。例如，如果有一个运行 Oracle 的订阅服务器，且在 Oracle 上创建的表的名称两旁没有引号，则将默认为 Oracle 服务器上的大写字母表名。如果在项目属性中指定名称为"Shipper"，该名称在 Oracle 订阅服务器上将变为"SHIPPER"。

  • 应用于使用分发代理程序的异类订阅服务器的事务在表名两旁有引号。

  • 不支持对 ODBC 订阅服务器的批处理语句（因为分发任务的"提交的批处理大小"选项被忽略了）。

  • ODBC DSN 必须遵照 SQL Server 2000 命名规则（因为 DSN 存储在 sysservers 表中）。

  • 如果 ODBC DSN 不是 SQL Server DSN，那么不支持在同步前截断的发布选项。对于选中了该选项的发布来说，不允许 ODBC 订阅服务器去订阅这种发布。

  • 要使用目标服务器上的引用的标识符字符（正如 ODBC 驱动程序所报告的那样）。

  • 为了同步，必须选择字符格式大容量复制方法（使用发布属性对话框中的创建发布向导）。对于有些发布，如果它们为同步选择了本机格式大容量复制方法，那么 ODBC 订阅服务器就不能订阅这种发布。

  • 对于所有异类订阅服务器，针对 CREATE TABLE 语句，只支持 NULL、NOT NULL、IDENTITY，以及常量 PRIMARY KEY。因此，在为异类订阅服务器创建了订阅之后，SQL Server 2000 并不支持将项目添加到发布。每次将项目添加到发布或从发布删除项目时，必须要对订阅重新初始化。


Access 订阅服务器

Microsoft® SQL Server™ 2000 包括 ODBC 驱动程序和 OLE DB 提供程序，OLE DB 提供程序支持 Microsoft Access 97 或 Microsoft Access 2000 对 SQL Server 发布的订阅。SQL Server 2000 安装程序会自动地安装该驱动程序及提供程序。

若要复制到 Access 订阅服务器，必须将合适的域用户帐户指派给 MSSQLServer 服务，这个域用户帐户与 SQL Server 代理所指派的域用户帐户相同。这样使该服务有通过网络连接到 .mdb 文件所必须的权限。使用控制面板中的服务应用程序可以完成这项工作。

说明 在远程服务器上注册 Access DSN 时，请提供 UNC 路径（并不是重定向的驱动器号）。

重要 如果未启用异类订阅服务器而在创建发布向导中创建订阅数据库，架构将发布到订阅服务器而数据则不发布到订阅服务器，并且不显示错误信息。若要启用异类订阅服务器，请在创建发布向导的"指定订阅服务器类型"页中，选择"异类数据源，例如 Oracle 或 Microsoft Access；运行 SQL Server CE 的设备；或运行 SQL Server 早期版本的服务器"。

映射到事务复制的 Jet-SQL 3.51 (Access 8) 的数据类型

当您复制到 ODBC 订阅服务器时，下表将事务复制的数据类型映射到 Access 订阅服务器，分发任务将 SQL Server 2000 数据类型映射到目标数据库中最相近的数据类型。

SQL Server 2000 数据类型 | Access Jet-SQL 3.51 数据类型
binary(n) | LONGBINARY
bit | BIT
char(n) | LONGTEXT
datetime | CHAR (23)
decimal | CHAR (30)
float | DOUBLE
image | LONGBINARY
int | LONG
int | LONG
money | CHAR (25)
nchar(n) | LONGTEXT
ntext | LONGTEXT
numeric | CHAR (30)
nvarchar(n) | LONGTEXT
real | SINGLE
smalldatetime | DATETIME
smallint | SHORT
smallmoney | DOUBLE
text | LONGTEXT
timestamp | BINARY (8)
tinyint | BYTE
uniqueidentifier | CHAR (36)
varbinary(n) | LONGBINARY
varchar(n) | LONGTEXT

映射到事务复制的 Jet-SQL 4.0 的数据类型

下表将事务复制的数据类型映射到 Access 订阅服务器。当复制到 ODBC 订阅服务器时，分发任务将 SQL Server 2000 数据类型映射到目标数据库中最相近的数据类型。

说明 对于快照复制、事务复制及合并复制来说，从 SQL Server 到 Jet-SQL 4.0 的数据类型映射是相同的。

SQL Server 2000 数据类型 | Microsoft Jet-SQL 4.0 数据类型
binary(n) | BINARY (n)
Bit | BIT
char(n) | CHAR (n)
datetime | DATETIME
decimal | DECIMAL
float | FLOAT
image | IMAGE
int | INT
money | CURRENCY
nchar(n) | NCHAR (n)
numeric | NUMERIC
nvarchar(n) | NCHAR VARYING (n)
real | REAL
smalldatetime | DATETIME
smallint | SMALLINT
smallmoney | CURRENCY
text | LONGTEXT
timestamp | BINARY
tinyint | BYTE
uniqueidentifier | GUID
varbinary(n) | VARBINARY (n)
varchar(n) | VARCHAR (n)


Oracle 订阅服务器

Microsoft® SQL Server™ 2000 包含 ODBC 驱动程序及 OLE DB 提供程序，它们在 Intel 计算机上支持 Oracle 对 SQL Server 发布的订阅。SQL Server 2000 安装程序自动地安装该驱动程序。

说明 为了复制到 Oracle ODBC 及 OLE DB 订阅服务器，您必须还要从 Oracle 或您的软件厂商那里获取合适的 Oracle SQL*Net 驱动程序。然后您还必须将该驱动程序安装在发布服务器及分发服务器上。

Oracle 订阅服务器的复制限制

当复制到 Oracle ODBC 订阅服务器时，会有如下限制：

  • 如果表的名称带有空格，那么将不会在 Oracle 订阅服务器上创建这些表的复制。复制将会因 Oracle 错误 ORA-00903 而失败：无效的表名称。

  • date 数据类型为小 datetime（范围从 4712 B.C. 到 4712 A.D.）。

    如果准备复制到 Oracle，请验证在复制的列中，SQL Server datetime 条目在上述范围之内。

  • 复制表只能有一个 text 或 image 数据类型的列，该数据类型被映射为 long raw。

  • datetime 数据类型被映射为 char4。

  • 对于 float 及 real 数据类型，SQL Server 2000 范围与 Oracle 范围不同。

下表将复制的数据类型映射到 Oracle 订阅服务器。

SQL Server 2000 数据类型 | Oracle 数据类型
bigint | NUMBER
binary | LONG RAW NOT NULL
bit | NUMBER (1, 0)
char | VARCHAR2 (900) NOT NULL
datetime | DATE
decimal | NUMBER (255, 3) NOT NULL
float | FLOAT NOT NULL
image | LONG RAW
int | NUMBER (255, 3) NOT NULL
money | NUMBER (255, 3) NOT NULL
nchar | VARCHAR2 (2000) NOT NULL
ntext | LONG
numeric | NUMBER (255, 3) NOT NULL
nvarchar | VARCHAR2 (2000) NOT NULL
real | FLOAT NOT NULL
smallint | NUMBER (255, 3) NOT NULL
smalldatetime | DATE NOT NULL
smallmoney | NUMBER (255, 3) NOT NULL
sql_variant | LONG
sysname | CHAR(255)
text | LONG
timestamp | RAW (255)
tinyint | NUMBER (255, 3) NOT NULL

Oracle 数据类型定义

下表列出了 Oracle 数据类型定义。

Oracle 数据类型 | 定义
CHAR | <=2000
DATE | Jan 1, 4712 B.C. 到 Dec 31, 4712 A.D.
DECIMAL | 同 Number 一样
FLOAT | 同 Number 一样
INTEGER | 同 Number 一样
LONG | <=2GB
LONG RAW | Raw 数据；同 Long 一样
LONG VARCHAR | 同 Long 一样
NUMBER | 1.0E-130 到 9.99..E125
SMALLINT | 同 Number 一样
RAW | 原始二进制数据 <=255 字节
ROWID | 唯一值
VARCHAR2 | <=4000 字节
VARCHAR | 同 Varchar2 一样
BLOB | 二进制大对象 <=4GB
COB | 字符大对象 <=4GB
NCLOB | 同 Clob 一样（对于多字节）
BFILE | 二进制操作文件的指针


IBM DB2/AS400 订阅服务器

通过包含 Microsoft 主机集成 Server 2000 的 OLE DB 提供程序和 ODBC 驱动器，可支持对 Microsoft® SQL Server™ 2000 发布的 IBM DB2/AS400 订阅。

下表将 SQL Server 2000 数据类型映射到 IBM DB2/AS400 数据类型。当复制到 OLE DB 或 ODBC 订阅服务器时，分发任务将 SQL Server 2000 数据类型映射到目标数据库中最相近的数据类型。

SQL Server 2000 数据类型 | DB2/AS400 数据类型
binary(n) | CHAR(8000) FOR BIT DATA
bit | SMALLINT
char(n) | CHAR (8000)
datetime | TIMESTAMP
decimal | DECIMAL
double precision | DOUBLE
float | FLOAT
image | VARCHAR(32739) FOR BIT DATA
int | INTEGER NOT NULL
money | DECIMAL (19, 4)
numeric | NUMERIC
real | REAL
smalldatetime | TIMESTAMP NOT NULL
smallint | SMALLINT
smallmoney | DECIMAL (10, 4) NOT NULL,
text | VARCHAR (32739)
timestamp | CHAR(8) FOR BIT DATA)
tinyint | SMALLINT NOT NULL
uniqueidentifier | CHAR (36)
varbinary(n) | VARCHAR(8000) FOR BIT DATA NOT NULL
varchar(n) | VARCHAR (8000) NOT NULL


IBM DB2/AS400 数据类型定义

下表列出了 IBM DB2/AS400 数据类型定义。

DB2/AS400 数据类型 | 定义
INT | 9
SMALLINT | 4
FLOAT | <=53
NUMERIC | 1 - 31 个数字
DECIMAL | 1 - 31 个数字
CHAR | <=32766
VARCHAR | <=32740
LONG VARCHAR | 由行中可用的空间决定
TIMESTAMP | Gregorian
GRAPHIC | <=16383
VARGRAPHIC | <=16370
LONG VARGRAPHIC | 由行中可用的空间决定
REAL | 8,7
DOUBLE | 17,16


IBM DB2/MVS 订阅服务器

通过 Microsoft 主机集成 Server 2000 附带的 OLE DB 提供程序和 ODBC 驱动程序，支持 IBM DB2/MVS 对 Microsoft® SQL Server™ 2000 发布的订阅。

下表将 SQL Server 2000 数据类型映射到 IBM DB2/MVS 数据类型。当复制到 OLE DB 或 ODBC 订阅服务器时，分发任务将 SQL Server 2000 数据类型映射到目标数据库中最相近的数据类型。

SQL Server 2000 数据类型 | DB2/MVS 数据类型
binary(n) | CHAR(254) FOR BIT DATA NOT NULL
bit | SMALLINT
char(n) | CHAR (254) NOT NULL
datetime | TIMESTAMP NOT NULL
decimal | DECIMAL (31, 3) NOT NULL
double precision | DOUBLE
float | FLOAT NOT NULL
image | VARCHAR(4045) FOR BIT DATA
int | INTEGER NOT NULL
money | DECIMAL (19, 4) NOT NULL
nchar(n) | VARCHAR (900) NOT NULL
numeric | NUMERIC (31, 3) NOT NULL
real | REAL NOT NULL
smalldatetime | TIMESTAMP NOT NULL
smallint | SMALLINT NOT NULL
smallmoney | DECIMAL (10, 4) NOT NULL
text | VARCHAR (4045)
timestamp | CHAR(8) FOR BIT DATA
tinyint | SMALLINT NOT NULL
uniqueidentifier | CHAR (38)
varbinary(n) | VARCHAR(4045) FOR BIT DATA NOT NULL
varchar(n) | VARCHAR (4045) NOT NULL


其它异类订阅服务器

本节包括运行 DB2/NT 或 DB2/6000 的订阅服务器的数据类型映射以及 ODBC 订阅服务器所需的驱动程序类型。

IBM DB2/NT

通过 Microsoft 主机集成 Server 2000 附带的 OLE DB 提供程序和 ODBC 驱动程序，支持 IBM DB2/NT 对 Microsoft® SQL Server™ 2000 发布的订阅。

下表将 SQL Server 2000 数据类型映射到 IBM DB2/NT 数据类型。当复制到 OLE DB 或 ODBC 订阅服务器时，分发任务将 SQL Server 2000 数据类型映射到目标数据库中最相近的数据类型。

SQL Server 2000 数据类型 | IBM DB2/NT 数据类型
binary(n) | CHAR(254) FOR BIT DATA NOT NULL
bit | SMALLINT
char(n) | CHAR (254) NOT NULL
datetime | TIMESTAMP
decimal | DECIMAL
double precision | DOUBLE
float | FLOAT
image | VARCHAR(4000) FOR BIT DATA
int | INTEGER NOT NULL
money | DECIMAL(19, 4)
numeric | NUMERIC
real | REAL
smalldatetime | TIMESTAMP NOT NULL
smallmoney | DECIMAL(10, 4)
text | VARCHAR (4000)
timestamp | CHAR(8) FOR BIT DATA)
tinyint | SMALLINT NOT NULL
uniqueidentifier | CHAR (38)
varbinary(n) | VARCHAR(4000) FOR BIT DATA NOT NULL
varchar(n) | VARCHAR (4000) NOT NULL

IBM DB2/6000

通过 Microsoft 主机集成 Server 2000 附带的 OLE DB 提供程序和 ODBC 驱动程序，支持 IBM DB2/6000 对 MSQL Server 2000 发布的订阅。

下表将 SQL Server 2000 数据类型映射到 IBM DB2/6000 数据类型。当复制到 OLE DB 或 ODBC 订阅服务器时，分发任务将 SQL Server 2000 数据类型映射到目标数据库中最相近的数据类型。

SQL Server 2000 数据类型 | IBM DB2/6000 数据类型
binary(n) | CHAR(254) FOR BIT DATA NOT NULL
Bit | SMALLINT
char(n) | CHAR (254) NOT NULL
Datetime | TIMESTAMP
Decimal | NUMERIC (28, 14) NOT NULL
Float | INTEGER NOT NULL
Image | VARCHAR(4000) FOR BIT DATA
Int | INTEGER(10) NOT NULL
Money | DECIMAL(19, 4)
Numeric | NUMERIC
Real | REAL
Smalldatetime | TIMESTAMP NOT NULL
Smallint | SMALLINT
Smallmoney | DECIMAL (10, 4) NOT NULL,
Text | VARCHAR (4000)
Timestamp | CHAR(8) FOR BIT DATA
Tinyint | SMALLINT NOT NULL
Uniqueidentifier | CHAR (38)
varbinary(n) | VARCHAR(4000) FOR BIT DATA NOT NULL
varchar(n) | VARCHAR (4000) NOT NULL

ODBC 驱动程序及 OLE DB 提供程序支持

各种异类数据源的 ODBC 驱动程序及 OLE DB 提供程序都包含在 SQL Server 2000 光盘中。

其它 ODBC 订阅服务器类型的驱动程序必须符合 SQL Server 2000 对普通 ODBC 订阅服务器的复制要求。ODBC 驱动程序：

  • 必须遵从一级 ODBC (ODBC level-1)。

  • 必须是 32 位的、线程安全的，并且是针对在其上运行分发进程的处理器构架（Intel 或 Alpha）的。

  • 必须有事务能力。

  • 必须支持数据定义语言 (DDL)。

  • 不能是只读的。

  • 必须支持长表名（如 MSreplication_subscriptions）。
使用 OLE DB 接口进行复制

SQL Server 2000 复制可以使用 OLE DB 接口，在使用 ICommand 接口的订阅服务器上执行 SQL 语句。OLE DB 提供程序必须支持事务复制的下列对象：

  • DataSource 对象

  • Session 对象

  • Command 对象

  • Rowset 对象

  • Error 对象
DataSource 对象接口

为了连接到数据源，需要下面这些接口：

  • IDBInitialize

  • IDBCreateSession

  • IDBProperties

如果提供程序支持 IDBInfo 接口，那么 SQL Server 2000 使用该接口以检索某些信息（例如被引用的标识符字符、最大 SQL 语句长度，以及表和列名称中最大字符数）。

Session 对象接口

需要下面这些接口：

  • IDBCreateCommand

  • ITransaction

  • ITransactionLocal

  • IDBSchemaRowset
Command 对象接口

需要下面这些接口：

  • ICommand

  • ICommandProperties

  • ICommandText

  • ICommandPrepare

  • IColumnsInfo

  • IAccessor

  • ICommandWithParameters

IAccessor 是创建参数存取程序所必需的。如果提供程序支持 IColumnRowset，SQL Server 2000 将使用该接口确定某列是否为标识列。

Rowset 对象接口

需要下面这些接口：

  • IRowset

  • IAccessor

  • IColumnsInfo

如果在订阅数据库中创建了一个被复制的表，那么应用程序将会在该表上打开一个行集。访问行集中的数据需要 IColumnsInfo 和 IAccessor。

Error 对象接口

使用下面这些接口以管理错误：

  • IErrorRecords

  • IErrorInfo

如果 OLE DB 提供程序支持 ISQLErrorInfo，那么请使用它。

有关 OLE DB 提供程序的更多信息，请参见与该 OLE DB 提供程序一同提供的文档。

说明 关于 OLE DB 的用法，主要的信息源是 OLE DB 软件开发工具包 (SDK) 中的《OLE DB 程序员参考 2.0 版》。


实现到 Access 订阅服务器的合并复制

当使用 Access 8 以后的 Microsoft® Access 版本时，可以为自己的 Access 数据库选择使用 SQL Server 2000 Desktop Engine 或者使用 Microsoft Jet 作为数据库引擎及数据存储。Desktop Engine 是一种基于 Microsoft SQL Server™ 2000 技术的数据存储，但是经过设计与优化，用于较小的计算机系统，例如一台计算机或小型工作组服务器。因为 Desktop Engine 基于与 SQL Server 相同的数据库引擎，所以大多数 Access 工程或客户端/服务器应用程序可以不加修改地运行在 Desktop Engine 或者 SQL Server 标准版或企业版上。但是，与其它版本的 SQL Server 不同，Desktop Engine 有 2 GB 数据库大小的限制，不支持对称多处理 (SMP)，并且不能是事务发布的发布服务器（但可以是事务发布的订阅服务器）。

如果您为自己的应用程序选择 Desktop Engine 或 SQL Server 作为数据库引擎，那么为了在 SQL Server 发布服务器和 Access 订阅服务器之间进行复制，就不再需要更多的步骤。运行 Access 的计算机出现在 SQL Server 企业管理器中，只是简单地作为另一个服务器。

如果为自己的 Access 应用程序选择 Microsoft Jet 作为数据库引擎，那么就必须启用 Jet 4.0 版数据库作为订阅服务器。为了完成这项工作，必须配置 SQL Server，以使用到每个 Jet 订阅服务器的数据库的 OLE DB 连接。完成这项工作的最简单方法是利用 SQL Server 企业管理器；但是还可以通过执行 sp_addlinkedserver，以编程方式将 Jet 数据库添加为链接服务器。

到 Access 订阅服务器的复制会受到下列限制：

  • Microsoft Jet 4.0 不支持区分大小写的排序次序。如果有某个 SQL Server 的实例安装了区分大小写的排序次序，那么不要使用它创建 Jet 4.0 订阅服务器的发布。

  • Microsoft Jet 4.0 不支持从运行在 DEC Alpha 服务器上的发布服务器到运行在其它平台上的 Jet 4.0 订阅服务器的强制订阅。在 Jet 4.0 订阅服务器创建请求订阅，而不要在 DEC Alpha 发布服务器创建强制订阅。

  • SQL Server 不支持来自 Jet 4.0 订阅服务器的已知请求订阅，但却支持匿名请求订阅。使用 Microsoft ActiveX® 复制控件可以实现该功能。

  • 不能同时将合并发布及事务发布从相同的发布数据库复制到一个 Jet 订阅服务器。

  • 当带 –validate 参数运行合并代理程序时，仅支持行数验证。当验证复制到 Jet 订阅服务器的数据时，不能使用校验和验证。

  • 列名不能与 Jet 复制期间所用的列相同。保留的列名包括：s_Generation、s_GUID、s_Lineage 和 s_ColLineage。


映射到合并复制的 Jet-SQL 4.0 的数据类型

下表将合并复制的数据类型映射到 Microsoft® Access 订阅服务器。当复制到 ODBC 订阅服务器时，分发任务将 Microsoft SQL Server™ 2000 数据类型映射到目标数据库上最相近的数据类型。

说明 对于快照复制、事务复制以及合并复制，从 SQL Server 2000 到 Jet-SQL 4.0 的数据类型映射是相同的。

SQL Server 2000 数据类型 | Microsoft Jet-SQL 4.0 数据类型
bigint | DECIMAL
binary(n) | BINARY (n)
bit | BIT
char(n) | CHAR (n)
datetime | DATETIME
decimal | DECIMAL
float | FLOAT
image | IMAGE
int | INT
money | CURRENCY
nchar(n) | NCHAR (n)
ntext | LONGTEXT
numeric | DECIMAL
nvarchar(n) | NCHAR VARYING (n)
real | REAL
smalldatetime | DATETIME
smallint | SMALLINT
smallmoney | CURRENCY
text | LONGTEXT
timestamp | BINARY
tinyint | BYTE
uniqueidentifier | GUID
varbinary(n) | VARBINARY (n)
varchar(n) | VARCHAR (n)


异类发布服务器

Microsoft® SQL Server™ 2000 可以订阅从 Oracle、DB2、Access 以及其它数据源发布的快照或事务数据。如果有些单位打算使用 SQL Server 布署大型数据库或数据仓库，或者布署 Internet 及 Intranet 应用程序，这将允许它们可以访问各种数据源。可以使用复制将那些数据合并到 SQL Server 2000 中，然后将这些数据放入数据集市、数据仓库或多维数据库，或者也可以随后将数据复制到其它数据源。

有些复制由异类数据源发布到 SQL Server 2000 应用程序，实现这种复制的方法包括：

  • 使用 SQL-DMO 及复制分发服务器接口生成应用程序。

  • 使用第三方工具。

Microsoft SQL Server 2000 还提供一个编程框架，使异类数据源能够成为 SQL Server 2000 复制框架内的快照和事务发布服务器。您可以将复制分发服务器接口与可编程 SQL-DMO 对象及第三方工具一同使用，以此用增量方式从异类发布服务器发布数据。

通过使用第三方工具，可以配置 Oracle、DB2 以及其它数据源，将它们作为 SQL Server 订阅服务器的合并发布服务器或增量发布服务器，SQL Server 订阅服务器随后可以将数据传播到其它 SQL Server 或异类数据源。

通过与 SQL Server 2000 复制集成，异类应用程序可以继承一套完整的复制功能，例如：

  • 远程存储及转发数据库和分发代理程序。

  • 异类订阅服务器，包括 Microsoft Access、Oracle 及 DB2。

  • 请求订阅。

  • 匿名订阅。

  • Internet 订阅。

  • 运行 Microsoft Windows® 98 的计算机上的订阅。

  • 独立的并可嵌入的分发代理程序。

  • 使用 SQL Server 企业管理器的监视和疑难解答工具。

  • 使用 SQL Server 代理的复制代理程序调度。

  • 警报及提示。

  • 性能监视。

异类数据源中的事务复制和快照复制的编程框架包括：

  • 用于管理及监视复制的可编程 SQL-DMO 复制对象。

  • 复制分发服务器接口，它用来存储异类发布服务器中被复制的事务。

  • 分发代理程序，它将事务转发到订阅服务器。

  • SQL Server 企业管理器，它可以用图形化方式管理和监视复制。

使用数据转换服务 (DTS)，可以将异类数据源用于创建快照复制发布。

请参见

设计来自异类数据源的复制


复制安全性

Microsoft® SQL Server™ 2000 复制使用组合的安全方法来保护应用程序中的数据和业务逻辑。

安全性 | 描述
角色要求 | 通过映射用户登录名到特定的 SQL Server 2000 角色，SQL Server 2000 允许用户只执行授权给该角色的复制活动和数据库活动。复制将某些权限授予 sysadmin 固定服务器角色、db_owner 固定数据库角色、当前登录以及 public 角色。
连接到分发服务器 | SQL Server 2000 提供分发服务器和发布服务器之间的安全管理链接。发布服务器可被看作受信任或不受信任的服务器。
快照文件夹安全性 | 通过备用的快照位置，用户可将自己的快照文件保存到分发服务器以外的地方（如网络共享、FTP 站点或可移动的媒体）。保存快照文件时，应确保复制代理程序具有适当的读写快照文件的权限。
发布访问列表 | 发布访问列表 (PAL) 允许用户确定哪些登录能够访问发布。SQL Server 2000 用默认的登录名创建 PAL，用户可根据需要增加或删除登录者。
代理程序登录安全性 | SQL Server 2000 要求每一位用户提供一个有效的登录帐户连接到服务器。当与发布服务器、分发服务器和订阅服务器连接时，复制代理程序必须使用有效的登录帐户。但是，当代理程序同时连接到不同的服务器时，也可使用不同的登录帐户和安全模式。
密码加密 | 自动加密 SQL Server 2000 复制中使用的密码以进一步提高安全性。
安全性和复制选项 | 通过筛选复制的数据可提高数据的安全性，在使用动态快照、即时更新和排队更新时还有其它安全考虑。
通过 Internet 进行复制及其安全性 | 通过 Internet 进行的不同类型的复制具有不同的安全级别。另外，使用 FTP 站点传送复制文件时，必须采取安全措施保护站点，同时使站点仍可由复制代理程序访问。


角色要求

Microsoft® SQL Server™ 2000 复制根据映射到用户登录名的角色来限制用户可执行的特定操作。复制已经向 sysadmin 服务器角色、db_owner 数据库角色和发布访问列表 (PAL) 中的登录者授予某些权限。

以下各表概述了常见复制操作的要求。

复制管理 | 成员资格要求
启用、修改或除去分发服务器。 | sysadmin 服务器角色。
启用、修改或除去发布服务器。 | sysadmin 服务器角色。
启用、修改或除去订阅服务器。 | sysadmin 服务器角色。
启用数据库进行复制。 | sysadmin 服务器角色。
创建或除去发布。 | sysadmin 服务器角色或 db_owner 数据库角色。
修改发布属性。 | sysadmin 服务器角色或 db_owner 数据库角色。如果登录在 PAL 范围内，即使用户不是 sysadmin 或 db_owner 角色成员，也能以只读方式查看发布属性。
创建或删除强制订阅。 | sysadmin 服务器角色或 db_owner 数据库角色。
创建请求订阅。 | sysadmin 服务器角色或 db_owner 数据库角色或 PAL 中的任何登录。
删除请求订阅。 | sysadmin 或 db_owner 数据库角色，或创建请求订阅登录者。
更新 PAL。 | sysadmin 服务器角色或 db_owner 数据库角色。
为通过 Internet 进行 FTP 下载启用快照。 | sysadmin 服务器角色或 db_owner 数据库角色。
使用复制监视器查看复制活动、错误和历史记录。用户不能修改代理程序配置文件、调度等，除非是 sysadmin 服务器角色成员。 | replmonitor 角色。

复制代理程序 | 成员资格要求
配置代理程序配置文件。 | sysadmin 服务器角色。
监视复制代理程序。 | sysadmin 服务器角色。
在发布服务器上，快照代理程序、日志读取器代理和合并代理程序的登录。 | 对于请求订阅，登录必须位于引用发布中发布访问列表中。对于强制订阅，登录必须是发布数据 db_owner（包括 sysadmin）的角色成员。
在分发服务器上，快照代理程序、日志读取器代理、分发代理程序和合并代理程序的登录。 | 对于请求订阅，登录必须位于引用发布中发布访问列表中或是分发数据库上 db_owner 数据库角色。对于强制订阅，登录必须是分发数据库的 db_owner（包括 sysadmin）的成员。
登录到订阅服务器的分发代理程序和合并代理程序。 | 对于强制订阅和请求订阅，登录都必须是订阅数据库中 db_owner（包括 sysadmin）的成员。
复制代理程序 | 成员资格要求
配置代理程序配置文件。 | sysadmin 服务器角色。

复制任务 | 成员资格要求
清除。 | sysadmin 服务器角色或分发数据库中的 db_owner 数据库角色。
调度作业。 | sysadmin 服务器角色或 msdb 数据库中的 db_owner 数据库角色。
在合并复制过程中合并数据。 | 合并进程要求在订阅服务器的 sysservers 表中包含一个发布服务器条目。如果该条目不存在，则 SQL Server 将尝试添加该条目。如果合并代理程序使用的登录无添加此条目的访问权限（如订阅数据库的 db_owner），则会返回一个错误。


连接到分发服务器

分发服务器可以是与发布服务器相同的服务器（本地分发服务器），也可以是与发布服务器不同的服务器（远程分发服务器）。当使用远程分发服务器时，可以配置发布服务器与分发服务器连接时的必要安全性。

发布服务器和远程分发服务器之间的连接是链接服务器和远程服务器的混合体。此连接使用 distributor_admin 登录。在远程分发服务器上，可以将发布服务器配置为受信任（即 distributor_admin 登录不需要密码）或非信任（即需要密码）。

建议对发布服务器与分发服务器的连接使用非信任连接，即需要 distributor_admin 密码。这样，通过限制访问提高了分发服务器的安全性。准备使用分发服务器的 sysadmin 或 db_owner 角色成员必须知道管理链接密码。在发布服务器上输入错误的 distributor_admin 密码将导致发布服务器上的复制配置失败。

警告 不要手工更改 distributor_admin 的密码。由于密码更改自动应用到本地发布上，因此总是在 SQL Server 企业管理器中使用 sp_changedistributor_password 或"发布服务器和分发服务器属性"的"分发服务器"选项卡。手工更改 distributor_admin 密码会引起使用本地分发服务器的发布失败。

在分发服务器上添加或更改密码

企业管理器

企业管理器

Transact-SQL

Transact-SQL

请参见

sp_adddistributor

sp_changedistributor_password


快照文件夹安全性

备用快照位置使用户可将快照文件存储在默认位置以外的位置，默认位置常常位于分发服务器上。备用位置可以在另一台服务器、网络共享或可移动的媒体（如光盘或可移动磁盘）上。

在网络共享上指定快照位置时，建议将此共享专用于快照存储和具有相同安全标准的文件。然后，赋予复制代理程序在此共享和在快照位置及相应文件夹中的写权限，以便写入快照文件。

访问快照文件的订阅服务器应具有读取快照位置和相应文件夹的权限。如果订阅服务器不能共享快照文件夹，则复制代理程序将无法访问该文件夹，复制也将因此失败。

在运行 Microsoft® Windows NT® 4.0 或 Microsoft Windows® 2000 操作系统的分发服务器上，默认情况下，快照文件夹使用 <drive>$ 共享和路径 \\<computer>\<drive>$\Mssql\Repldata\。在运行 Microsoft Windows 98 操作系统的分发服务器上，默认情况下，快照文件使用不带共享的 <drive> 和路径 <drive>:\Mssql7\Repldata。然而，用户可以将快照文件保存到默认位置以外的位置。

如果您的应用程序需要具有在运行 Windows 98 操作系统的服务器上创建请求订阅的能力，则必须将快照文件夹的路径改为发布服务器和订阅服务器上运行的复制代理程序可访问的网络路径。通过手工共享文件夹，可将本地路径更改为网络路径。

请参见

备用快照位置

通过 Internet 进行复制及其安全性


发布访问列表

用户创建发布后，Microsoft® SQL Server™ 2000 将为此发布创建一个发布访问列表 (PAL)。PAL 包含能够访问此发布的登录者列表。PAL 中包含的登录是 sysadmin 固定服务器角色成员和当前登录者。

PAL 的作用与 Microsoft Windows® 2000 访问控制列表相似。当用户或复制代理程序试图登录到发布服务器时，SQL Server 2000 首先检查此登录名是否属于 PAL 范围。如果必须进一步扩展或限制对某个发布的访问，则可以使用 SQL Server 企业管理器或 sp_grant_publication_access 和 sp_revoke_publication_access 存储过程添加或删除PAL 中的登录。

可以通过 SQL Server 企业管理器或编程用 PAL 来保护快照发布、事务发布或合并发布的安全。

说明 复制代理程序在能够访问发布前，其登录发布服务器和分发服务器的登录名必须已经存在于 PAL 中。用户登录名必须也存在于发布数据库中，或者数据库必须允许"guest"用户。如果使用的是远程分发服务器，则登录名必须同时存在于发布服务器和分发服务器上，然后才能添加到 PAL 中。因为复制代理程序在 SQL Server 代理程序下运行，所以 SQL Server 代理程序在 Windows NT 平台上运行时所使用的帐户必须存在于 PAL 中。

如果要在 PAL 中添加大量的用户登录名，请考虑先将这些登录名组成一个 Windows 2000 组，然后将该 Windows 2000 组添加到 PAL 中。

授权或废除对发布的访问权

企业管理器

企业管理器

Transact-SQL


代理登录安全性

 复制

代理程序登录安全性

复制实现登录安全性的方法是，要求用户提供有效的登录帐户和密码才能连接到发布服务器、分发服务器或订阅服务器。复制代理程序在 SQL Server 代理程序下运行，而且使用相关的登录和密码连接到各种复制对象，并在同步进程中执行其角色。

在 Microsoft® Windows® 98 操作系统上，SQL Server 代理程序和复制代理在登录到 Windows 操作系统的用户的安全帐户下运行。在 Microsoft Windows NT® 4.0 和 Windows 2000 操作系统上，复制代理在 SQLServerAgent 服务的登录帐户或安全环境下运行。每个代理程序连接一个或多个服务器，并且必须具有有效的登录以完成连接。

应用快照

当应用快照时，代理程序必须具备下列功能：

  • 快照代理程序与发布服务器上的发布数据库以及分发服务器上的分发数据库相连。存储快照文件时，快照代理程序还写入快照文件夹。
事务复制

事务复制中使用的代理程序必须具有以下功能：

  • 日志读取器代理与发布服务器上的发布数据库以及分发服务器上的分发数据库相连。

  • 在强制订阅中，默认情况下，分发代理程序位于分发服务器上，而且首先连接到分发服务器上的分发数据库。当连接到分发服务器后，分发代理程序连接到订阅服务器上的订阅数据库。应用快照文件时，分发代理程序还从快照文件夹中进行读取。

  • 在请求订阅中，默认情况下，分发代理程序位于订阅服务器上，而且首先连接到订阅服务器上的订阅数据库。当连接到订阅服务器后，分发代理程序连接分发服务器上的分发数据库。应用快照文件时，分发代理程序还从快照文件夹中进行读取。
合并复制

合并复制中使用的代理程序必须具有以下功能：

  • 在强制订阅中，合并代理程序位于分发服务器上，而且首先连接到分发服务器上的分发数据库。连接到分发服务器后，合并代理程序连接到订阅服务器上的订阅数据库，然后连接到发布服务器上的发布数据库。应用快照文件时，合并代理程序还从快照文件夹中进行读取。

  • 在请求订阅中，合并代理程序位于订阅服务器上，而且首先连接到订阅服务器上的订阅数据库。连接到订阅服务器后，合并代理程序连接到分发服务器上的分发数据库，然后连接到发布服务器上的发布数据库。应用快照文件时，合并代理程序还从快照文件夹中进行读取。

  • 合并复制要求在订阅服务器的 sysservers 表中包含一个发布服务器条目。如果该条目不存在，则 SQL Server 会在用户创建合并复制时添加该条目，或者由合并代理程序添加。如果使用的登录名无足够的权限将此条目添加到 sysservers 中，则会返回一个错误。

说明 对于控制多个同时连接的代理程序，Microsoft® SQL Server™ 允许为每个连接分别配置登录。例如，如果快照代理程序连接到发布服务器和分发服务器，那么每个连接可使用不同的登录。


安全性和复制选项

筛选已发布数据

通过筛选已发布的数据，可以限制对数据的访问，并指定可从订阅服务器获得的数据。可以通过任何类型的复制水平或垂直筛选数据，这样，按照用户要求和需求处理的分区可发布到订阅服务器上。

此外，可在合并复制中使用动态筛选，可通过事务复制创建自定义数据分区，以根据从订阅服务器中检索的值筛选行。例如，通过在合并复制动态筛选中使用 SUSER_SNAME 函数，可以只传播与订阅服务器上那些由 SUSER_SNAME 检索的值相关的行。

有关更多信息，请参见筛选已发布数据。

动态快照

动态快照为应用动态筛选过的合并复制快照带来了性能上的好处。通过使用 Microsoft® SQL Server™ 2000 大容量复制文件（而非一系列 INSERT 语句）将数据应用到特定的订阅服务器上，可以提高应用动态筛选过的合并复制初始快照的性能。

在使用动态快照时，必须满足以下安全条件：

  • 发布服务器上的 SQL Server 必须以混合安全模式运行。

  • 指定为发布服务器登录值的登录必须在发布访问列表 (PAL) 中，或者是发布数据库 sysadmin 角色或 db_owner 组的成员。此登录可以在创建动态快照作业向导中指定，也可以使用快照代理程序中的参数 -DynamicFilterLogin 指定。

  • 因为 SQL Server 在快照代理程序中添加和除去临时登录名，所以快照代理程序的发布服务器登录名必须是 securityadmin 服务器角色成员和发布数据库上的 db_owner 组成员，这样才能生成动态快照。

  • 为生成动态快照指定的动态筛选登录名必须是相应 PAL 的成员。

有关更多信息，请参见动态快照。

即时更新和排队更新

对于从同步触发器回到发布服务器的两阶段提交协议 (2PC) 连接，即时更新选项既支持动态远程过程调用 (RPC) 模式，也支持静态 RPC 模式。

在动态 RPC 模式中，同步触发器使用提供的服务器名称、登录和密码动态连接到发布服务器。有些用户不需要静态定义的从订阅服务器到发布服务器的链接服务器/远程服务器连接，而动态 RPC 模式为这些用户提供了增强的安全保障。安装强制订阅时，该模式也易于使用，因为发布服务器不必在订阅服务器上预定义。

在静态 RPC 模式中，同步触发器通过一个静态定义的服务器名称（在 sysservers 表中定义为链接服务器或远程服务器）连接到发布服务器。在订阅服务器上，该条目由管理员添加。创建强制订阅或请求订阅时自动设置配置模式。

  • 即时更新与发布服务器的订阅连接（由 sp_link_publication 控制）在创建登录映射时，对 SQL Server 身份验证可使用安全模式 0，对链接服务器定义可使用安全模式 2。发布访问列表 (PAL) 必须至少包括一个 SQL Server 身份验证帐户，除非用户使用安全模式 2 并配置了委托（通过配置委托可以设置 Windows 身份验证使用模式 2）。可以通过委托唤醒调用订阅服务器上的 INSERT、UPDATE 和 DELETE 触发器，以 Windows 用户帐户与发布服务器建立连接。若要设置委托，请参见 sp_addlinkedsrvlogin。

  • 当在 SQL Server 企业管理器中或在 sp_addsubscription 存储过程中使用强制订阅向导安装强制订阅时，默认配置在订阅服务器上使用动态 RPC。动态 RPC 默认使用不带密码的 sa 登录。这样做可以避免在网上发送登录或密码，而且可以使用 sp_link_publication 在订阅服务器上进行更改。

  • 当在 SQL Server 企业管理器中使用请求订阅向导建立请求订阅时，用户可选择所需的配置模式。如果选择静态 RPC，服务器名称必须已存在。如果选择动态 RPC，则必须提供登录和密码，同步触发器将用它们连接到发布服务器上。

  • 当使用存储过程安装请求订阅时，必须在调用订阅服务器上的 sp_addpullsubscription 后，还显式调用 sp_link_publication。

使用动态 RPC 时，Microsoft® SQL Server™ 2000 通过将复制命令添加到分发数据库以调用订阅服务器上的 sp_addsynctriggers 来处理登录和密码转发。在订阅服务器上执行时，sp_addsynctriggers 创建即时更新触发器，并配置链接服务器的连接。

订阅服务器上的即时更新存储过程在执行时检查发布服务器上的 PAL，确保执行 RPC 的用户帐户具有更新发布数据的权限。


通过 Internet 进行复制及其安全性

通过 Internet 进行的不同类型的复制具有不同的安全级别。另外，使用 FTP 站点传送复制文件时，必须采取安全措施保护站点，同时使站点仍可由复制代理程序访问。

虚拟专用网络

对于通过 Internet 执行的复制，使用虚拟专用网络 (VPN) 是最安全的选择。VPN 包括客户端软件，使得计算机可以通过 Internet（特殊情况下甚至是 Intranet）连接到专用计算机或服务器上的软件。用户可通过在两端加密和验证用户身份的办法来确保数据安全。通过 Internet 的 VPN 连接，其运作在逻辑上相当于站点间的广域网 (WAN) 链接。

VPN 通过一个网络连接另一个网络的组件。其实现方法是允许用户以 Internet 或其它公共网络（使用诸如 Microsoft® Windows NT 4.0 版或 Microsoft Windows 2000 操作系统中的 Microsoft 点对点通道协议 (PPTP) 或者 Windows 2000 操作系统中的第二层通道协议 (L2TP)）为通道。这个过程提供了与以前专用网络相同的安全性和功能。

有关更多信息，请参见 Windows 2000 文档中的"虚拟专用网络"部分或使用 VPN 通过 Internet 发布数据。

Microsoft 代理服务器

Microsoft® SQL Server™ 2000 复制与 Microsoft 代理服务器集成后，可通过 Internet，按照在 Microsoft Windows® NT 4.0 版或 Microsoft Windows 2000 Server 操作系统、代理服务器和 SQL Server 2000 上配置的安全性执行复制。

当存在防火墙时，通过 Microsoft 代理服务器配置复制为通过 Internet 复制数据提供了安全保障，未经授权的 Internet 用户不能获取内部网络资源，订阅服务器可连接到代理服务器上的某个特定端口，该端口限制订阅服务器只能访问得到授权的服务。

有关更多信息，请在 Microsoft Web 站点上搜索白皮书 "Configuring Proxy Server for SQL Server Replication"。

TCP/IP 和文件传输协议

对于通过 Internet 进行复制（不涉及防火墙）或对于传输快照文件，可以使用 TCP/IP 和文件传输协议 (FTP)。

如果使用 FTP 下载快照文件，请将 FTP 站点定义为无写访问权限。虽然这是许多服务的默认设置，但应确认在安装后该设置未发生变化。

注意 当订阅服务器从 FTP 站点完成应用初始快照文件后，使用 FTP 传送的文件就留在了订阅服务器的磁盘上。这些文件至少能被可访问此计算机的所有其它登录者看到。任何登录到此计算机的用户都能访问这些文件。为防止出现这种情况，应将高速缓存保持期的值设得小一些，并（或）在应用快照后清除 Microsoft Internet Explorer 高速缓存。

有关更多信息，请参见使用 TCP/IP 和 FTP 通过 Internet 发布数据。


增强复制性能

通过以下方式可增强应用程序中和网络上所有类型的复制的常规性能：

  • 设置分配给 Microsoft® SQL Server™ 2000 的最小内存量。

  • 使用单独的磁盘驱动器存放复制涉及的所有数据库的事务日志。

  • 考虑增加复制使用的服务器的内存。

  • 使用多处理器计算机。

  • 为分发数据库设置固定大小。

  • 只发布所需数量的数据。

  • 只在必要时和非高峰时间运行快照代理。

  • 将快照文件夹放在其它未存储数据库或日志文件的驱动器上。

  • 每个发布使用单独的快照文件夹。

  • 考虑使用压缩的快照文件。

  • 当复制到多个订阅服务器时减少分发频率。

  • 考虑使用请求订阅或匿名订阅。

  • 除初始测试、监视或调试期间外，其它时期均将复制代理程序的详细等级降至 0。

  • 连续运行代理程序代替过于频繁的调度。

  • 考虑使用 –UseInprocLoader 代理程序属性。
设置分配给 SQL Server 的最小内存量

默认情况下，SQL Server 2000 根据可用的系统资源动态地改变其内存需求。为避免复制活动中内存可用性差，请使用"最小服务器内存"选项设置最小可用内存。如果服务器是远程分发服务器或是发布服务器和分发服务器的组合，则必须分配至少 16 MB 的内存。有关更多信息，请参见服务器内存选项。

使用单独的磁盘驱动器放置复制中涉及的所有数据库

此方式应用于发布数据库、分发数据库和订阅数据库。通过将日志文件存储在与存储数据库不同的磁盘驱动器上，可减少写事务所需的时间。如果需要容错，可以使用独立冗余磁盘阵列 (RAID)-1 镜像该驱动器。其它数据库文件用 RAID 0 或 0+1（取决于容错的需要）。不管是否正在使用复制，这都是一个很好的做法。有关更多信息，请参见 RAID 等级和 SQL Server。

考虑增加复制使用的服务器的内存

如果需要提高复制性能，可考虑增加复制使用的服务器的内存。例如，如果计算机配置有 64 兆字节 (MB) 内存，可考虑将内存增加到 128 MB 或更多。可以使用 sp_configure 存储过程为 Microsoft® SQL Server™ 2000 分配附加内存。

使用多处理器计算机

SQL Server 2000 复制代理程序可利用服务器上的附加处理器。如果运行时 CPU 占用率很高，请考虑安装更快的 CPU 或多个 CPU（对称多处理）。

只发布所需数量的数据

由于复制易于设置，所以人们喜欢发布超出实际需要的数据。这会在分发数据库和快照文件中耗费额外资源，并降低所需数据的吞吐量。应该避免发布不必要的数据表并考虑不要过于频繁地更新发布。

只在必要时和非高峰时间运行快照代理程序

快照代理将发布服务器上已发布表中的数据大容量复制到分发服务器上"快照"文件夹的一个文件中。在 SQL Server 2000 中，为事务复制生成快照的进程不再在已发布的表上控制表锁。与此类似，对于 SQL Server 2000 中的合并复制，当快照生成时，并发得到提高而锁定期限减少。虽然这将减轻对并发连接用户的影响，但生成快照仍然是消耗大量资源的进程，所以最好还是在非高峰时间调度。

将快照文件夹放在其它未存储数据库或日志文件的驱动器上

与此类似，当为任何发布类型生成快照时，快照代理程序将在快照文件夹中有序写入数据。因为当复制更改时，快照代理程序总是将发布中数据的完整复本复制到磁盘上，所以，将快照文件夹放在不同于存放数据库或日志文件的驱动器上会减少磁盘争夺并帮助快照进程更快完成。

每个发布使用单独的快照文件夹

当指定与快照位置有关的发布属性时，可选择在默认的快照文件夹、可选快照文件夹或这两种文件夹中生成快照文件。当快照代理程序运行时，在这两个位置中生成快照文件需要附加的处理。这要比在单个位置为发布生成快照文件花费更多时间。

有关更多信息，请参见备用快照位置。

考虑使用压缩的快照

在可选快照文件夹中压缩快照文件可减少快照磁盘存储需求，并且在某些情况下，当快照文件用于因特网上的复制时，压缩快照文件能提高在因特网上传输快照文件的性能。但是，当生成快照文件时，压缩快照需要快照代理程序进行附加处理，而当应用快照文件时，还需要合并代理程序进行附加处理。在某些情况下，这可能会降低快照生成的速度，增加应用快照所花费的时间。使用压缩的快照时应综合考虑这些因素。

有关更多信息，请参见压缩快照文件。

当复制到多个订阅服务器时减少分发频率

如果调度与每个订阅服务器相关的分发和合并代理程序不太频繁地运行，一台单独的分发服务器便可向大量订阅服务器分发事务。分发代理程序或合并代理程序的初始运行时间是交错开的，这样，当它们首次启动时不会尝试同步启动。如果代理程序正按调度运行，则调度默认设置为不会使代理程序在规定的同一时刻同时运行。

考虑使用请求订阅或匿名订阅

分发代理程序或合并代理程序在用于强制订阅的分发服务器上运行，在用于请求订阅或匿名订阅的订阅服务器上运行。使用请求订阅或匿名订阅后，分发或合并代理程序处理从分发服务器移到订阅服务器上，从而使性能得到提高。

还可以使用远程代理程序激活来卸载代理程序处理。可以将代理程序处理移到用于强制订阅的订阅服务器上和用于请求订阅的分发服务器上。代理程序管理仍会在用于强制订阅的分发服务器上和用于请求订阅的订阅服务器上发生。有关更多信息，请参见远程代理程序激活。

匿名订阅对于因特网应用程序尤其有用，它们不要求将订阅服务器的有关信息存储在用于事务复制的分发服务器的分发数据库中，从而减少了用于合并复制的发布数据库中有关订阅服务器信息的存储。由于不必维护匿名订阅服务器的信息，对发布服务器和分发服务器的资源需求因此降低。

匿名订阅是一类特殊的请求订阅。在常规的请求订阅中，分发代理程序或合并代理程序在订阅服务器上运行（因此降低了对分发服务器资源的需求），但是仍然在发布服务器上存储信息。如果发布支持匿名订阅，将发布配置为始终有一个供新的订阅服务器使用的快照。

对于事务复制，这意味着每次快照代理程序运行时，都会生成一个新的快照。通常，如果没有新订阅服务器等待使用快照或没有订阅服务器需要在快照代理程序运行时重新初始化，就不会生成快照。所以，尽管匿名订阅服务器可以减少对分发服务器资源的需求，但折衷的办法还是应更经常地生成快照。如果使用合并复制，则不管发布支持的订阅的类型如何，快照代理程序运行时总会生成一个新的快照。

订阅服务器上的附加索引

如果需要将订阅数据库用于决策支持分析，并添加大量索引以支持这些查询，则应注意，这些附加索引可能会显著降低吞吐量，而分发代理程序或合并代理程序要通过此吞吐量将更改应用于订阅服务器。某些时候，主要是在订阅服务器上聚合数据，此时在发布服务器上创建一个索引视图，并使用事务复制将此索引视图以表的形式发布到订阅服务器，这可能会更加有效。有关更多信息，请参见索引视图。

订阅服务器上触发器中的应用程序逻辑

类似地，订阅服务器上用户定义的触发器中的附加业务逻辑可能也会降低复制订阅服务器更改的速度。对于事务复制，在用来应用复制命令的自定义存储过程中包含该逻辑会更有效。有关更多信息，请参见在项目中使用自定义存储过程。

明智地使用水平分区

如果事务发布是用水平分区的项目设置的，则日志读取器不得不在扫描事务日志时对受到表更新影响的每一行应用筛选。日志读取器的吞吐量将因此受到影响。如果获得最大吞吐量非常关键，应考虑使用 DTS 自定义分区完成自定义水平分区 。这使日志读取器代理程序得以尽快从已发布数据库日志中删除事务。这只会影响到选择使用 DTS 包筛选数据的订阅服务器，而不会影响所有具有筛选数据开销的订阅服务器。

同样，合并复制必须评估已更改或已删除的行，确定每次使更改同步的时间，以确定哪些订阅服务器应接收这些行。当利用水平分区减少订阅服务器上要求的数据子集时，此处理更为复杂，并且比发布表中的所有行时更慢。应仔细考虑降低每个订阅服务器的存储需求与获得最大吞吐量之间的权衡。

使用快速网络

通过使用速度为 100 Mbps 或更快的快速网络，可显著增强对订阅服务器更改的传播。

降低复制代理程序的详细等级

将分发代理程序或合并代理程序的 –HistoryVerboseLevel 参数和/或 –OutputVerboseLevel 参数降为最低详细级。这将减少插入到跟踪代理程序历史记录和输出中的新行数。而且，具有同样状态的先前历史记录消息将更新为新的历史记录信息。更改此代理程序参数会产生 10% 到 15% 甚至更高的显著的性能收益。

不过，应为测试、监视和调试提高 –HistoryVerboseLevel 等级，以便有尽可能多的关于代理程序活动的历史记录信息。

连续运行代理程序代替过于频繁的调度

设置连续运行代理程序而不是创建频繁调度（如每隔一分钟）将提高复制性能。当设置分发代理程序或合并代理程序连续运行时，无论更改何时发生，都能立即传播到拓扑连接中的其它服务器上。由于代理程序连续运行，不必启动和停止，这将导致运行代理程序的服务器执行更多的工作。

考虑使用 –UseInprocLoader 代理程序属性

–UseInprocLoader 代理程序属性可提高快照复制、事务复制和合并复制的初始快照的性能。

在向分发代理程序（对于快照复制或事务复制）或合并代理程序（对于合并复制）应用此属性之后，代理程序将在向订阅服务器应用快照文件时使用进程内 BULK INSERT 命令。

–UseInprocLoader 属性不能用于字符模式 bcp，而且 OLE DB 或 ODBC 订阅服务器也不能使用该属性。

重要 当使用 –UseInprocLoader 属性时，运行订阅服务器所使用的 SQL Server 2000 帐户必须对快照 .bcp 数据文件所在目录拥有读权限。在不使用 –UseInprocLoader 属性时，代理程序（对于异类订阅服务器）或代理程序所装载的 ODBC 驱动程序（对于 SQL Server 2000 订阅服务器）从文件中读取，因此不使用订阅服务器 SQL Server 2000 帐户的安全上下文。


增强快照复制性能

通过以下方式可增强应用程序中和网络上快照复制的性能：

  • 使用高质量的磁盘子系统。

  • 每个发布使用单独的快照文件夹。

  • 使用压缩的快照。

  • 使用本机 bcp。
使用高质量的磁盘子系统

由于快照复制大容量复制发布的完整复本，它将全部发布内容写入快照文件夹。磁盘子系统从磁盘读写数据的速度越快，快照完成得就越快。

每个发布使用单独的快照文件夹

当指定与快照位置有关的发布属性时，可选择在默认的快照文件夹、可选快照文件夹或这两种文件夹中生成快照文件。当快照代理程序运行时，在这两个位置中生成快照文件需要附加的处理。这要比在单个位置为发布生成快照文件花费更多时间。

有关更多信息，请参见备用快照位置。

考虑使用压缩快照

在可选快照文件夹中压缩快照文件可减少快照磁盘存储需求，并且在某些情况下，当快照文件用于因特网上的复制时，压缩快照文件能提高在因特网上传输快照文件的性能。但是，当生成快照文件时，压缩快照需要快照代理程序进行附加处理，而当应用快照文件时，还需要合并代理程序进行附加处理。在某些情况下，这可能会降低快照生成的速度，增加应用快照所花费的时间。使用压缩的快照时应综合考虑这些因素。

有关更多信息，请参见压缩快照文件。

考虑使用本机 bcp

当没有使用 ODBC 或 OLE DB 订阅服务器或使用可转换订阅并且有大量数据时，应考虑使用本机 bcp 模式将快照文件应用于订阅服务器。如果必须将信息从一个 Microsoft® SQL Server™ 实例复制到另一个上，则以本机格式存储信息非常有用。


增强快照和事务复制性能

通过以下方式可增强应用程序中和网络上的快照或事务复制性能：

  • 在专用服务器上配置分发服务器。

  • 增加分发服务器的内存。

  • 订阅一个发布的所有项目。

  • 当涉及大量行时使用存储过程复制。

  • 最小化事务和历史的保持期。
在专用服务器上配置分发服务器

通过配置分发过程专用的计算机可减少发布服务器上的处理开销。这可能同时增加发布服务器和分发服务器的性能。

增加分发服务器的内存

除了维护专用分发服务器的好处之外，可通过增加分发服务器的内存额外增加性能。如果分发服务器支持到大量订阅服务器的复制，这一点更加有效。例如，如果计算机配置有 64 兆字节 (MB) 内存，可考虑将内存增加到 128 MB 或更多。可以使用 sp_configure 存储过程给 Microsoft® SQL Server™ 2000 分配附加内存。

订阅一个发布的所有项目

在默认状态下，订阅包括一个发布的所有项目。由于不从发布中排除任何项目，分发代理可在同步过程中采用最佳查询。

当涉及大量行时使用存储过程复制

如果在发布服务器上执行单个指定的更新/删除操作影响到大量的行，则对每一受更新影响的行的更改将一一记录在数据库的事务日志中。日志读取器将这些更改作为单独的更新（在单一事务中）进行传播，并且当分发代理程序应用更改时，可能会比在发布服务器上的初始更新花费更长的时间。

如果所做的批处理更新有时会影响订阅服务器上的大量行，则应考虑使用存储过程更新已发布的表，并发布存储过程的执行。分发代理程序不是为每个受更新/删除影响的行都发送一个更新/删除，而是在订阅服务器上以同样的参数值执行同一过程。与作为个别的行更改发送更新/删除相比，使用存储过程使速度提高了很大的数量级。有关更多信息，请参见发布存储过程执行。

使用自定义存储过程更新订阅服务器

默认情况下，在为事务复制建立订阅服务器时，除了创建表和传播表外，应用快照于订阅服务器的进程也会在订阅服务器上为 INSERT、UPDATE 和 DELETE 创建一组存储过程。

随后，当对已发布的表进行更改时，日志读取器将构造存储过程调用，代替代表更改的 SQL 语句。然后，分发代理程序在应用更改于订阅服务器的同时执行此调用。这比 SQL 语句更为有效，它能提供显著的性能收益。

这些存储过程可进一步自定义，而且通常比在触发器中为诸如维护聚合表这样的操作添加特定订阅服务器逻辑更好。

有关更多信息，请参见在项目中使用自定义存储过程。

最小化事务和历史的保持期

在已复制事务和历史记录传送到订阅服务器之后，通过最小化它们存储在分发数据库中的时间，可减少分发服务器上使用的磁盘空间。

减少不必要的订阅重新初始化或过期

如果订阅服务器已很长时间未同步，则订阅可能被除去，或者被自动标记为停用和要求重新初始化。订阅是否过期、被除去或标记为停用和要求重新初始化，这些都取决于它是否超过了发布的订阅过期属性或分发数据库的最大事务保持期属性，以及是否为匿名订阅服务器。

如果不想让订阅过期，则将发布保持设置为"0"。如果不想让订阅停用，考虑到可能对分发数据库大小的影响，应将最大分发保持期设置为比默认的 72 小时高。有关更多信息，请参见订阅停用和过期。

使用高质量的磁盘子系统

由于快照复制复制发布中数据的完整复本，它将全部发布内容写入快照文件夹。磁盘子系统从磁盘读写数据的速度越快，快照完成得就越快。


增强事务复制性能

通过以下方式可增强应用程序中和网络上的事务复制性能：

  • 增加日志读取器代理读取的批处理大小。

  • 最小化日志历史和保持期。

  • 优化数据库设计以考虑复制的需要。

  • 使用自定义存储过程在订阅服务器上进行插入、更新和删除操作。

  • 避免水平筛选。
增加日志读取器代理读取的批处理大小

日志读取代理和分发代理支持调整事务读取和提交操作的批处理大小。批处理大小的默认值为 500 个事务。当要将大量事务写入一个发布数据库，但其中只有一小部分标记为复制时，则需要用 -ReadBatchSize 参数增加日志读取器读取的批处理大小。日志读取器代理程序从日志中读取特定数量的事务，不管这些事务是否标记为复制。有关更多信息，请参见使用可转换的订阅创建自定义数据分区。

最小化日志历史和保持期

可通过最小化日志历史和事务保持时间减少分发服务器上使用的磁盘空间。有关更多信息，请参见事务复制。

优化数据库设计以考虑复制的需要

水平分区会限制复制性能。应该考虑数据库的设计选项，在发布中定义项目时这些选项会减少筛选行的需要。也可以考虑使用自定义存储过程删除订阅服务器上不必要的行，或使用具有可转换订阅的自定义数据分区（有关的更多信息，请参见使用可转换的订阅创建自定义数据分区）。

使用自定义存储过程在订阅服务器上进行插入、更新和删除

当 Microsoft® SQL Server™ 2000 在订阅服务器上应用事务时，可以用自定义存储过程替代事务日志中的 INSERT、UPDATE 和 DELETE 语句。例如，分发代理程序可以不使用事务日志中的 INSERT 语句读取，而是在订阅服务器上运行一个存储过程来执行相同的操作。这些存储过程可进一步自定义，而且通常比在触发器中为诸如维护聚合表这样的操作添加特定订阅服务器逻辑更好。

避免水平筛选

对于在发布数据库日志中标明要复制的每一行，都要评估一次水平筛选准则集。这样做可以确定该行是否应该转移到分发数据库中。对于需要最大数据吞吐量的应用程序，项目的水平筛选可能不是最小化发送到每个订阅服务器的行的最佳选择。相反，使用具有可转换订阅的自定义数据分区开发表的自然分区可能是更好的选择（有关的更多信息，请参见使用可转换的订阅创建自定义数据分区)。


增强合并复制性能

通过以下方式可增强应用程序中和网络上的合并复制性能：

  • 在子集和联接筛选所使用的列上创建索引。

  • 生成初始快照前创建 ROWGUIDCOL 列。

  • 尽可能使用本机模式 bcp。

  • 增加合并代理程序处理的批处理大小。

  • 有大量订阅服务器时使用请求和匿名订阅。

  • 限制 text 和 image 列的使用。

  • 考虑使包含 text 和 image 列的表过度标准化。

  • 尽可能使用静态分区而不使用动态分区。

  • 对动态筛选的发布使用动态快照。

  • 限制子集筛选子句的复杂性。

  • 降低发布保持设置。

  • 带宽受限时选择列级跟踪。

  • 分区数据时优化同步。

  • 如果为引用完整性使用触发器，则控制项目处理顺序。

  • 使用全局订阅。

  • 间或重做合并复制系统表索引。

  • 不要过度使用联接筛选。

  • 修改数据库设计。

  • 限制或控制代理程序同时处理。

  • 考虑重新初始化订阅。
在子集和联接筛选所使用的列上创建索引

在已发布项目上使用筛选时，为筛选的 WHERE 子句中使用的每一列创建索引。如果没有索引，Microsoft® SQL Server™ 2000 就必须读取表中的每一行，以确定该行是否应包含在项目中（即在表的水平分区中）。有了索引后，SQL Server 2000 可快速找到要包含的行。如果 SQL Server 2000 只根据索引就能完全解析筛选的 WHERE 子句，处理速度将最快。

对用于 JOIN 筛选中的所有列进行索引也很重要。合并代理每次运行时，都要搜索基表以确定基表中和相关表中的哪些行将包含在项目中。通过在 JOIN 列上创建索引，可避免每次合并代理程序运行时，SQL Server 2000 都必须读取表中的每一行。

有关更多信息，请参见筛选已发布数据。

生成初始快照前创建 ROWGUIDCOL 列

通过创建一个可用在合并复制期间帮助跟踪更改的列，可以避免在重要时刻（以及磁盘和日志）性能间或降低，这种情况可能发生在等待快照代理程序更改表时。

合并复制要求每个已发布表具有 ROWGUIDCOL 列。如果在快照代理程序创建初始快照文件之前表中不存在 ROWGUIDCOL 列，那么此代理程序必须首先添加和填充此列。为了在合并复制期间生成快照时获得性能优势，请在使用合并复制发布前在每个表上创建 ROWGUID 列。该列可以取任何名称（默认情况下，快照代理程序使用 rowguid），但必须包含下列数据类型特性：

  • 数据类型为 UNIQUEIDENTIFIER。

  • 默认为 NEWID()。

  • ROWGUIDCOL 属性。

  • 列上的唯一索引。

在对发布服务器和订阅服务器上的更改进行跟踪和同步的过程中，ROWGUIDCOL 列经常用在合并复制中。

增加合并代理处理的批处理大小

在默认状态下，合并代理在发布服务器和订阅服务器之间上载和下载的每个批处理中处理 100 个生成。如果频繁更新单个表且在单个事务中更新大量行，可考虑增加每个批处理的生成数量。可设置合并代理配置文件中的 -DownloadGenerationsPerBatch 和 -UploadGenerationsPerBatch 参数。

有大量用户时使用请求订阅和匿名订阅

请求订阅将分发代理从分发服务器转移至订阅服务器。重新部署分发代理可减少分发服务器必须为每个请求订阅进行的处理量，并将处理开销转移至订阅服务器。通过创建请求订阅取代强制订阅，可释放更多的分发服务器处理能力，以执行其它复制或应用程序任务。创建匿名订阅后，由于不必存储关于订阅服务器的元数据，可进一步减少对分发服务器的资源需求。

尽可能使用本机模式 bcp

当创建发布时，可选择指定一个或多个订阅服务器作为 Microsoft Jet 4.0 (Microsoft Access) 数据库或 SQL Server for Windows® CE 数据库。为这些类型的订阅服务器启用支持可引起快照代理程序以字符格式存储快照文件，而不以本机 SQL Server 2000 格式存储。由于 SQL Server 2000 需要额外的处理时间和存储空间来处理和存储字符格式的文件，所以除非确认确实有这类订阅服务器，否则不要启用 SQL Server for Windows CE 或 Access 订阅服务器。

限制 text 和 image 列的使用

与其它列数据类型相比，text 和 image 列需要更多存储空间和处理工作。除非应用程序绝对必需，否则不要在项目中包含 text 和 image 列。

考虑使包含 text 和 image 列的表过度标准化

发生同步时，合并代理程序可能需要从分发服务器或订阅服务器中读取和传输整个数据行。如果该行包含 text 和 image 列，即使这些列可能还未更新，此进程仍会要求增加内存分配，从而对性能产生负面影响。为减少这种负面影响的发生，考虑将 text 和 image 列单独放在一个表中，并对其余的行数据采用一对一关系。

减少水平筛选的使用

当子集筛选或联接筛选用于筛选发布中的数据时，合并代理程序必须决定是否需要将行添加到订阅数据库或将其从订阅数据库中删除。然而，这将会减少必须传输到每个订阅服务器上的数据量，同时增加每次同步期间在发布服务器上所要求的处理量。如果未对数据进行水平筛选，则必须将所有的数据更改发送到每个订阅服务器上，并且合并代理程序可不必先为发布评估筛选准则就可以快速向订阅服务器发送数据。

若要让一些表收到许多活动而另一些表无需收到时，可在不同的发布中发布不相关的表。

尽可能使用静态分区而不使用动态分区

动态筛选和分区是 SQL Server 2000 复制的强大功能。然而，即使使用筛选列上的索引，SQL Server 2000 也必须读取动态分区里的每一行，并将其与筛选值进行比较。使用静态筛选和分区可减少完成合并过程所需的处理时间。

对动态筛选的发布使用动态快照

当用动态筛选对发布进行分区时，快照代理程序不能预先决定订阅服务器要求的数据。因此，在合并代理程序从快照文件夹中应用架构文件之后，它一定会为特定于其分区的所有数据请求插入。使用插入为大量数据处理初始快照要比使用 SQL Server 大容量复制工具处理同样的数据慢很多。

使用 SQL Server 2000，通过创建动态快照作业，可指导快照代理程序生成特定于每个订阅服务器的 bcp 文件。动态快照生成 bcp 文件，就好像已将静态筛选应用于发布一样。虽然这要求对于每个将要为订阅服务器生成的数据分区，以特殊的模式运行一次快照代理程序，但会显著改善合并代理程序在处理快照文件时应用数据所用的时间。

有关更多信息，请参见动态快照。

限制子集筛选子句的复杂性

使用子集筛选子句水平分区发布中的数据时，应限制筛选准则的复杂性。应经常评估子集筛选子句以决定发布数据的哪些更改行应与每个订阅服务器同步。限制筛选准则的复杂性有助于提高合并代理程序评估要发送给订阅服务器的行更改时的性能。避免使用合并子集筛选子句范围内的子选择。应考虑使用联接筛选，联接筛选在用于根据其它表中的子集筛选子句分区另一表中的数据时通常更有效。

说明 不要过度使用联接筛选。具有数打或更多表的联接筛选将影响性能。

有关更多信息，请参见筛选已发布数据。

减少发布保持设置

发布保持决定了在订阅服务器被认为没有同步以及需要发布服务器上的新快照之前，订阅服务器在没有同步化增量更改的情况下可工作多长时间。

此设置也控制在发布和订阅数据库中保持某些合并跟踪元数据的时间。还可控制合并跟踪元数据的增长，并且在某些情况下，如果降低了发布保持期设置，则在同步更改的同时观察提高的性能。选择足以支持订阅服务器脱机工作到扩展时间段结束的发布保持设置。

带宽受限时选择列等级跟踪

尽管业务应用程序通常需要驱动为合并发布选择行或列等级跟踪，但是在带宽可用性很低时，选择列等级跟踪对性能有益。数据更改的列等级跟踪允许合并代理程序通过网络为更改的行只发送更改列和 rowguidcol 属性。相反地，当使用行等级跟踪时。合并代理程序总是发送整个行。当应用程序频繁更改包含多列的表中的少数几列时，通过有限带宽网络只发送更改列可以提供更好的性能。

分区数据时优化同步

当向合并发布添加项目时，选择 @keep_partition_changes 选项可以显著减少合并代理程序决定是否将近来更改的行发送给订阅服务器时所花费的时间。

当应用程序更新子集筛选或联接筛选中使用的列时，合并代理程序必须做附加的工作，以决定在同步时，行更改是否需要为每个订阅服务器将行添加到分区中或从分区中删除。通过维护某些关于发布数据库中更改行的附加数据，合并代理程序可以更快地确定哪些与分区有关的行更改与每个订阅服务器相应。

注意 如果选择在发布服务器上维护这些附加的信息，则会导致对发布数据库中合并复制跟踪系统表存储需求的增加。然而，如果对分区中包含的列的更新是典型的，则性能方面的收益值得去维护附加信息。

有关更多信息，请参见优化同步。

如果为引用完整性使用触发器，则控制项目处理顺序

通过声明外键约束或由触发器执行的约束发布彼此相关的表时，合并代理程序需要按正确的顺序将更改应用于相关行上以传播所有更改。如果正在使用声明的引用完整性，SQL Server 将按照基于关系的顺序处理项目。通过按照基于待执行操作（例如，在相关子行前插入父行）的最优顺序处理项目，合并代理程序在同步期间处理项目时可避免附加的重试操作。

如果不使用声明的引用完整性，默认情况下，合并代理程序将按照项目通过存储过程添加到发布的顺序，或按照不能通过 SQL Server 企业管理器控制的 SQLDMO –项目顺序处理项目。

如果用触发器执行引用完整性，则合并代理程序不会将其识别为声明的引用完整性，所以需要注意项目的处理顺序。

使用全局订阅

当为本地或匿名合并订阅服务器同步化更改时，发布服务器也必须同步附加的系统跟踪数据，否则，这些数据对全局订阅则是不必要的。使用全局订阅可以在经常更新订阅服务器的情况下提高同步性能。

间或重做合并复制系统表索引

作为合并复制维护的一部分，应间或检查与合并复制相关的系统表的增长：MSmerge_contents、MSmerge_genhistory 和 MSmerge_tombstone。通过运行 DBCC Transact-SQL 命令定期重做这些表的索引。若要重做这些系统表的索引，在发布数据库上执行下列命令：

  • DBCC DBREINDEX ('MSmerge_contents')

  • DBCC DBREINDEX ('MSmerge_genhistory')

  • DBCC DBREINDEX ('MSmerge_tombstone')

另外，应使用 sp_mergecleanupmetadata 最小化合并系统表（特别是 MSmerge_history 表）的大小。有关更多信息，请参见合并复制的工作机制。

不要过度使用联接筛选

具有几个表（如数打或数百个表）的联接筛选将严重影响合并处理过程的性能。如果生成五个或更多表的联接筛选，建议最好考虑其它方案。其它方案可能会避免筛选主要是查找表、较小的表以及未受更改表这样的表。使这些表整个作为发布的组成部分。建议只在表之间使用联接筛选，这些表在订阅服务器间仔细分区是非常重要的。

修改数据库设计

数据库设计最终决定合并复制使用的查询的复杂性要求和处理资源要求，并将影响到合并性能。差的数据库设计或不符合合并发布的发布（或筛选）要求的数据库设计可能需要对数据库做某些结构性更改以便提高合并性能。具体地讲，添加列或表以支持动态分区逻辑会更有效，同时应确保筛选表达式中使用的列能够利用索引。适用普通的"为索引使用而优化查询"规则。如果一般性提到在所有筛选列上使用索引，而查询优化器未使用索引，则依照索引维护，实际效果可能相反，因为数据不是完全唯一的或表达式不能使用索引。有时，更改筛选表达式能使现有索引在原来不能使用的地方使用。

限制或控制同时代理程序处理

限制或控制多个同时快照代理程序或合并代理程序进程的数目，尤其是在包含大型数据集、复杂分区逻辑和大量合并更改时。sp_addmergepublication 的 @max_concurrent_merge 和 @max_concurrent_dynamic_snapshots 参数可帮助限制或控制进程数。

考虑重新初始化订阅

当需要将大量更改发送给订阅服务器时，用新的快照重新初始化这些订阅可能会比使用合并移动单个更改要快。

请参见

代理程序配置

创建索引

创建和修改标识符列

数据类型和表结构

动态筛选

为复制制定计划


备份和还原复制数据库

对于 Microsoft® SQL Server™ 2000，除定期备份和还原的准则及过程外，还应考虑复制所涉及的数据库备份和还原。

对于备份在快照复制、事务复制或合并复制中使用的数据库，考虑事项因服务器在复制中所担任的角色以及复制拓扑中故障出现的位置而异。

若要还原复制，请定期备份下列部分或全部服务器：

  • 发布服务器

  • 分发服务器

  • 订阅服务器

备份策略取决于快速还原复制环境的需要以及备份计划中可容忍的复杂程度。如果希望在减小数据丢失可能性的情况下，立即从备份还原任何副本，只需备份所有数据库。

维护发布服务器数据库的定期备份和利用 SQL Server 复制内置的重新初始化一个或多个按需订阅的能力，这两种方式都提供了简单恢复策略。该策略可用于支持拥有移动的、偶尔连接的订阅服务器的大型企业，这些订阅服务器本来不常在拓朴的每个节点上参与定期的备份管理。可进一步限制对发布数据库做定期备份，并且在需要还原整个复制环境时，依靠 SQL Server 复制脚本提供重建复制的方法。

另一个策略包括只备份发布服务器与分发服务器，条件是这两者同步。该策略使您得以完全还原复制环境。备份订阅服务器虽是可选的，但这样可减少从订阅服务器故障中恢复所需的时间。

基本备份计划会导致需要较长的时间还原复制环境。如果应用程序要求立即还原复制，可考虑将在本节后面部分描述的更加复杂的备份与恢复策略。

大多数情况下，在添加或更改复制对象（如项目和订阅）后，或在实施将影响复制的架构更改后，应该备份发布数据库与分发数据库。如果将分发数据库还原到更改发生前的版本，那么也应将发布数据库还原到更改发生前的版本。

不论采取何种备份策略，都应始终将复制设置的当前脚本存放在一个安全的位置。除定期备份发布服务器、分发服务器及订阅服务器外，还应该做上述工作。当全部服务器出现故障或需要设置测试环境时，用户可以通过更改服务器名称引用来修改脚本，并用该脚本帮助恢复以前的复制设置。

还应该对启用与禁用复制进行脚本设置。这些脚本是发布服务器备份或分发服务器备份的一部分。

有关生成用于设置或禁用复制的 SQL 脚本的更多信息，请参见编写复制脚本。

备份发布服务器

发布数据库是复制拓扑中数据的主要来源或集中来源，因此即使在最基本的恢复计划中也应包括定期备份发布服务器。若要备份发布服务器，需在其所在的服务器上定期备份发布数据库。先备份发布数据库，然后再做事务日志备份和/或差异数据库备份。还可以备份 master 和 msdb 系统数据库，以防整个系统丢失而不仅仅是发布数据库丢失。如果要向备用服务器传送事务日志，应定期备份 msdb 系统数据库（如果使用日志传送则必须使用该数据库）。

备份分发服务器

备份分发服务器包括备份分发数据库、msdb 数据库和 master 系统数据库。这使您得以从几乎任意类型的故障中恢复，而无需重新创建发布或重新配置复制。

备份分发服务器能保留发布快照以及应用程序的历史记录、错误和复制代理程序信息。因为无需重建复制，这使您得以在发生发布服务器或分发服务器故障时恢复得更快。尤其对于事务复制，该策略要求在发布数据库与分发数据库之间进行备份时协调一致。SQL Server 2000 自动处理这种协调。先备份分发数据库，然后做事务日志备份和差异数据库备份。

有关更多信息，请参见事务复制的备份和还原策略。

备份订阅服务器

全面的备份恢复策略可能在需要恢复时依靠重新初始化订阅，或者可能包括对每个订阅数据库和订阅服务器上的相关系统数据库进行定期备份。备份订阅服务器包括备份订阅数据库，或者可以选择备份 msdb 和 master 系统数据库。仅当订阅服务器使用请求订阅并且需要在系统全部丢失后能够还原时，才需要备份 msdb 和 master 数据库。

先备份订阅数据库，然后做事务日志备份和增量数据库备份。

说明 发生故障后重建复制时不要求备份每个订阅服务器。大多数情况下，定期备份发布服务器和分发服务器就应该足够了。如果重新初始化订阅服务器的成本明显大于从备份还原的成本，而且容易管理在企业内的副本间管理备份的复杂性，则应考虑备份订阅服务器。

请参见

验证已复制的数据


快照复制的备份和还原策略

对于复制不经常更改的数据，或不要求保持数据最新值（低滞后时间）的情况，快照数据是一种最好的数据复制方法。发生同步时，生成完整的快照并发送到订阅服务器。

因为快照复制通过生成并传递完整的复制快照来传播更改，所以不必要像在事务复制或合并复制中那样频繁地备份发布数据库。当更改现有发布属性或添加新发布时，需要备份发布数据库。

当备份发布服务器时，也需备份分发服务器。当备份正在进行时，不能添加新的快照发布或订阅。这样就确保当还原发布服务器及分发服务器时，它们包含相同的信息。

备份和还原发布数据库

日志读取器代理在备份和还原中的地位不如它在事务复制中那么重要。只有当更改现有发布（如添加或删除项目，或在发布数据库上所做的架构更改影响了发布）或者添加新发布时，才需备份发布数据库。

备份和还原分发数据库

在备份分发数据库前，建议先运行分发内容清除任务以确保清除任何不必要的信息，并且不会增加备份分发数据库所需的时间。

应同时备份分发数据库与发布数据库。在备份过程中，不要添加新的快照发布或订阅。

备份和还原 msdb 数据库

msdb 数据库包含在 SQL Server 代理程序控制下运行的复制代理程序的作业定义。若要提供附加安全性以防止出现整体系统故障，则无论在除去订阅、更改复制代理程序或将新发布服务器添加到分发服务器时，都必须对发布服务器、分发服务器和订阅服务器（使用请求订阅）上的 msdb 数据库进行定期备份。

备份和还原 master 数据库

当添加一个新的订阅服务器时，将在发布服务器的 master 数据库中的 sysservers 表内添加一条有关该订阅服务器的条目。当将一个新的发布服务器添加到分发服务器时，将在分发服务器的 master 数据库中的 sysservers 表内添加一条有关发布服务器的条目。

若要在发布服务器或分发服务器丢失后还原复制，必须在每次添加订阅服务器或发布服务器（分别添加）时备份发布服务器和分发服务器中的 master 数据库。


事务复制的备份和还原策略

Microsoft® SQL Server™ 2000 使您得以不用重新初始化订阅或者禁用并重新配置发布和分发即可还原事务复制数据库。还可以设置复制与日志传送一起使用，这样，不必重新配置复制即可使用备用服务器上。

若要在发布数据库或分发数据库丢失后恢复事务复制，而且无需重新初始化订阅或重新配置复制，则要求发布数据库和分发数据库还原到一致的即时点。在 SQL Server 7.0 版及更早的版本中，若要确保上述的一致即时点，只有通过同时手工备份发布数据库与分发数据库的方式，同时还要确保在备份过程中不对数据库做任何更改。而 SQL Server 2000 将自动在两个数据库之间处理备份的协调。

为确保能够随时还原发布服务器或分发服务器，SQL Server 2000 要求在发布数据库和分发数据库上将复制数据库选项 sync with backup 设为 true。如果使用该选项，需要经常备份发布数据库与分发数据库（通常要备份事务日志或做差异备份），因为备份的频率会确定复制将更改传递给订阅服务器的滞后时间。

重要 只有 SQL Server 2000 发布服务器支持该选项。如果将分发数据库设置为 sync with backup，就会像没有设置该选项那样对运行 SQL Server 7.0 及更早版本并使用分发数据库的发布服务器进行处理。

备份和还原发布数据库

通常情况下，日志读取器代理以连续模式运行，监视日志中是否有数据更改，并立即（通常在几秒内）将更改的数据传播到分发数据库。此外，由于发布数据库备份通常按调度时间发生，因此，日志读取器代理传输事务的速度可能比事务备份的速度要快。如果发布服务器出现故障并已还原，则分发数据库上可能已经包含了还原后的发布数据库中所没有的事务，原因就在于这些事务尚未备份。

通过在发布数据库上设置 sync with backup 选项，可确保日志读取器代理不会将尚未在发布数据库上备份的事务传播导到分发数据库。这样就确保了能够还原上次的备份，并且不会导致分发数据库中包含还原后的发布数据库所没有的事务。

使日志读取器代理与备份发布数据库同步意味着现已将复制滞后时间（将发布服务器上的更改传送到订阅服务器所需的时间，可以短至几秒钟）限制为与发布服务器上的备份频率相等。例如，如果每隔 5 分钟备份一次发布数据库的事务日志，复制滞后时间最多为 5 分钟再加上完成复制所需的时间。平均少于 5 分钟，但多于典型的事务复制滞后时间（一般为几十秒）。如果使日志读取器代理与备份同步，建议尽可能经常地备份发布数据库（在该数据库备份后紧接着日志和/或差异数据库备份）以减少更改出现在订阅服务器上所需的时间。

使发布数据库与备份同步

  • 执行 sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'。

说明 如果将 sync with backup 选项更改为 false，发布数据库的截断点将在日志读取器代理运行后进行更新，或者如果日志读取器代理持续运行，则截断点将在一个间隔后进行更新。最大间隔由 –MessageInterval 代理程序参数控制，该参数的默认值为 30 秒。

若要确定是否已在发布数据库上对 sync with backup 选项进行了设置，请使用 DatabasePropertyex() 内部函数的 IsSyncWithBackup 属性。也可运行系统存储过程 sp_helpdb 检查是否已设置该选项。

如果不能延长复制滞后时间，则不要在发布数据库上设置 sync with backup 选项。但是在这种情况下，如果发布数据库出现故障，则分发数据库有可能包含还原后的发布数据库所没有的事务，并且不能保证订阅服务器与发布服务器同步。

当 sync with backup 选项为 False 时还原发布数据库

如果不设置 sync with backup 选项并允许分发数据库包含已还原发布数据库没有的事务，就能从备份还原发布数据库并使复制得以继续运行，但是订阅服务器与发布服务器可能不再同步。为实现这一点：

  1. 还原发布数据库。此时，日志读取器代理检测出分发服务器的内容比发布服务器新，因此发出错误信息。

  2. 不带参数在发布数据库中运行 sp_replrestart。这将迫使复制继续运行，即使分发服务器与某些订阅服务器现在可能包含一些发布服务器不再拥有的数据。

  3. 确保分发代理程序（它现在可将重复的行传递给订阅服务器）即使在发生故障时也能继续运行。选择 –SkipError 分发代理程序配置，或者将 –SkipError 参数手工添加到分发代理程序的运行时参数中，并提供希望分发代理程序忽略的错误。有关更多信息，请参见分发代理程序配置。

注意 该方法将导致发布服务器数据与订阅服务器数据不一致。

备份和还原分发数据库

分发数据库可以还原为上次的备份状态，而无需重新配置复制或重新初始化订阅。通常情况下，日志读取器代理连接到发布数据库，扫描日志并检索接下来要复制的 N 个事务的集合，将这些事务传播到分发数据库，然后告知发布数据库已在分发数据库成功提交事务。

这时，发布数据库可以截断包含这些事务的日志部分（只要事务已备份）。如果分发数据库此时出现故障并还原为前一个备份状态，则日志读取器代理可能无法传送缺少的事务，因为包含这些事务的日志部分可能已被截断。

在分发数据库上设置 sync with backup 选项可确保不会在将所有事务传播到分发数据库之前截断发布数据库的日志。还可确保已对包含新事务的分发数据库进行了备份。分发数据库可以还原为上次的备份状态，日志读取器代理将能够传送还原后的分发数据库所缺少的事务。复制将不受任何影响继续运行。

重要 若要通过备份事务日志和设置 sync with backup 选项的方式更频繁地备份分发数据库，必须将分发数据库上 sp_dboption 的 trunc. log on chkpt 选项设置为 false。

与发布数据库不同的是，在分发数据库上设置 sync with backup 选项对复制滞后时间并无影响，但将推迟发布数据库上的日志截断，直到已备份了分发数据库中的相应事务。sync with backup 选项只有在发布服务器和分发服务器运行 SQL Server 2000 时才可用。

使分发数据库与备份同步

  • 执行 sp_replicationdboption '<distributiondatabasename>', 'sync with backup', 'true'

若要确定是否已在分发数据库上设置了 sync with backup 选项，请使用 databaseproperty() 内部函数的 IsSyncWithBackup 属性。还可运行系统存储过程 sp_helpdb 检查是否已设置该选项。

备份和还原订阅数据库

若要不重新初始化订阅而将订阅服务器还原为上次的备份状态，应确保事务在分发服务器上的最短保持期大于订阅服务器上的备份间隔频率。这将保证在还原订阅服务器时，订阅服务器所需的全部事务仍能从分发数据库中获得。还原订阅服务器时，分发代理程序将传送订阅服务器所缺少的全部事务。默认情况下，最短事务保持期为 O，而在大多数情况下，已传送给所有订阅服务器的事务将被删除。

设置分发服务器的最短事务保持期

  1. 在 SQL Server 企业管理器中，展开一个服务器组，展开分发服务器，右击 Replication 文件夹，然后单击"配置发布"、"订阅服务器"和"分发"按钮。

  2. 若要修改分发数据库，请单击分发数据库的"属性"按钮以更改事务保持期。

说明 不一定非要通过备份订阅服务器还原事务复制；但是，备份发布服务器和分发服务器却很重要。如果生成快照和重新初始化订阅的成本少于从备份还原订阅数据库所需的时间，则不必备份订阅数据库。

备份和还原 msdb 数据库

msdb 数据库包含在 SQL Server 代理服务控制下运行的复制代理程序的作业定义。若要提供附加安全性以防系统故障，则每当除去订阅或添加新订阅、或者更改复制代理程序时，都必须对分发服务器和使用请求订阅的订阅服务器上的 msdb 数据库进行定期备份。

如果可转换的订阅与任何事务或快照发布一起使用，则 msdb 数据库可能也包含用于复制的数据转换服务 (DTS) 包定义。若要提供防止系统故障的保障，必须也对分发服务器和使用可转换订阅的订阅服务器上的 msdb 数据库进行定期备份。这些操作应该在每次修改与发布相关联的 DTS 包时执行，或在每次除去订阅或添加新订阅时执行。这将确保能恢复最新的定义。备份并还原 msdb 数据库使您得以在分发服务器或订阅服务器完全丢失后还原复制。

备份和还原 master 数据库

当添加一个新的订阅服务器时，将在发布服务器的 master 数据库中的 sysservers 表内添加有关该订阅服务器的条目。在添加订阅服务器后或在分发服务器的 master 数据库的 sysservers 表内添加有关发布服务器的条目后，在发布服务器上备份 master 数据库。

若要在发布服务器或分发服务器丢失后还原复制，请在每次添加新订阅服务器或发布服务器（分别添加）时，备份发布服务器和分发服务器上的 master 数据库。


事务复制和日志传送

Microsoft® SQL Server™ 2000 事务复制可配置成与日志传送一起使用，以便在发布服务器出现故障时提供备用服务器恢复选项。

必须运行 Microsoft SQL Server 2000 企业版才能使用日志传送。复制和日志传送一同使用时有两种模式：同步和半同步。

同步模式

在同步模式中，发布数据库上设置了 sync with backup 选项。这将使日志读取器代理与发布数据库备份同步。在这种模式中，如果分发数据库尚未备份，则日志读取器代理不会将任何事务从发布服务器传播到分发数据库。这将确保订阅服务器的内容不会早于分发服务器；但是，这也意味着现已将复制滞后时间（将发布服务器上的更改显示在订阅服务器所需的时间，通常可以短至几秒钟）限制为大于或等于日志传送间隔时间。通常为 2 到 10 分钟。

采用同步模式的好处在于：将故障转移到新的发布服务器后，所有复制服务器均同步。

在同步模式中配置复制与日志传送一同使用

  1. 在发布数据库上，执行 '<publicationdatabasename>', 'sync with backup', 'true'。

    如果设置了此选项，直到事务通过数据库备份或日志备份进行备份后，日期读取器代理程序才处理事务。

  2. 为发布数据库设置日志传送。

  3. 当发布服务器出现故障时，使用 KEEP_REPLICATION 选项和 RESTORE LOG 还原上次的数据库日志。这将保留所有复制设置。

  4. 将备用服务器重命名为原始发布服务器的名称。复制功能将继续向订阅服务器分发数据更改。
半同步模式

如果同步模式中不接受延长的滞后时间，且允许备用发布服务器与订阅服务器不同步，则应使用半同步模式。

备用发布服务器与订阅服务器可能不同步，原因在于日志读取器代理的性能与备份不同步。该模式允许将可能尚未在发布服务器上备份并传送到备用服务器的事务传播到分发服务器，然后再传播到订阅服务器上尽管发布服务器与订阅服务器目前并不同步，仍可以重新启动复制。

在半同步模式中配置复制与日志传送一同使用

  1. 为发布数据库设置日志传送。

  2. 当发布服务器出现故障时，使用 KEEP_REPLICATION 选项和 RESTORE LOG 还原上次的数据库日志。这将保留所有复制设置。

  3. 将备用服务器重命名为原始发布服务器的名称。日志读取器代理可能会返回一条消息，指出发布数据库与分发数据库不同步。

  4. 执行 sp_replrestart。该存储过程可用于强制日志读取器代理忽略发布数据库日志中以前复制的所有事务。日志读取器代理将处理存储过程完成后所应用的事务。存储过程成功执行后，可重新启动日志读取器代理。

    重要 sp_replrestart 系统存储过程应只与日志传送一同使用。如果需要还原发布数据库并且没有使用 sync with backup 选项，也可在受控环境下使用该存储过程。该选项只在日志读取器无法处理发布数据库日志中复制的事务且无其它解决办法时才使用。

  5. 将分发代理程序的配置文件设置为跳过错误的配置文件，因为丢失的事务（有一些已经复制到订阅服务器）可能在发布服务器中重新应用。


合并复制的备份和还原策略

Microsoft® SQL Server™ 2000 使您得以不用重新初始化订阅或者禁用并重新配置发布服务器和订阅服务器即可还原事务复制数据库。使用合并复制，使您得以用存储在其它站点的最新数据使服务器与可能还未保存在最近备份中的更改重新同步。还可以配置复制与日志传送一起使用，这样，不必重新配置复制即可使用备用服务器。

因为合并复制将更改跟踪元数据直接存储到发布数据库和订阅数据库内，所以通常不要求将发布数据库和分发数据库还原到一致的即时点。当备份或还原发布数据库或订阅数据库时，也要将用于跟踪已复制更改的系统元数据备份或还原到与已复制数据一致的即时点。

合并复制确保集中拓扑内所有副本中的数据。当需要还原数据库备份时，通常有多种恢复选项，具体取决于需要还原的数据库的作用。

作为任何恢复策略的一部分，始终要将复制设置的当前脚本存放在某个安全位置。当服务器发生灾难性故障或需要设置测试环境时，可以通过更改几个服务器名称引用来修改脚本并用该脚本帮助恢复复制设置。不仅要编写当前复制设置的脚本，还应编写启用和禁用复制的脚本。

备份和还原发布数据库

当还原发布数据库时，可能需要重新初始化对任何已还原发布的所有订阅。可能还需要立即与包含最新数据的订阅服务器同步。重新初始化所有订阅提供了一个方便的机制，可将发布数据库的所有副本重置为与已还原发布数据库一致的状态。或者，可能需要使发布数据库立即与包含最新数据的订阅数据库同步，并尝试恢复任何与那个副本同步的更改，但该更改并不包括在发布数据库事务日志备份的最新发布数据库备份中。

例如，假设已备份发布数据库并已更改发布数据库，并且订阅数据库与发布数据库同步，然后从备份中还原发布数据库。有两种选择可以还原数据库：

  • 使发布数据库与订阅数据库同步，并且将以前在发布数据库内所做的所有更改（但并未在已还原的备份中显示）从订阅数据库上载到发布数据库。

  • 重新初始化对发布数据库中的发布的所有订阅。

如果将发布数据库还原到更早的即时点并作为从错误执行的批处理数据操作中恢复的机制，或者如果将发布数据库恢复到以前的状态，则可能需要重新初始化所有订阅。重新初始化所有订阅可将恢复扩展到企业内所有副本的更早状态。如果选择该选项，建议生成一个新的快照，用以在还原发布数据库后立即向重新初始化的订阅服务器传递。

若要执行复制配置或维护发布数据库中的活动，使这些更改与订阅数据库同步，然后将发布数据库还原到发生配置更改前的状态，可能需要重新初始化对已还原发布数据库内受影响的发布的所有订阅。无论同步何时发生，订阅数据库的发布定义都应与相应发布数据库中所显示的定义相同。

建议每当更改已复制对象架构（例如，添加或除去某列）或更改发布属性时，都应备份发布数据库（增量备份或完整备份），即使可能有定期执行的数据库和日志备份。有关影响复制配置或已复制对象架构的某些常用操作的说明，将在本主题后面部分介绍。

备份和还原分发数据库

当还原只包含合并复制的发布数据库时，并不总是需要将相应的分发数据库还原到一致的即时点。分发数据库作为同步历史记录和错误跟踪信息的公用存储，在合并复制中的作用有限。它不存储更改跟踪中使用的任何数据，也不提供将要转发到订阅数据库的合并复制更改的临时存储。大多数情况下，当为合并发布还原发布数据库备份时，并不需要还原分发数据库。例外情况是当已在影响复制配置或已复制对象架构的发布数据库或分发数据库内执行任何数据库维护活动时。

备份和还原订阅数据库

与备份发布数据库相同，当还原订阅数据库时，将复制更改跟踪数据还原到与已复制数据一致的状态。如果在还原后使订阅数据库与它的每个发布同步，将导致合并代理程序下载订阅数据库备份尚未从各种包含订阅服务器的发布数据库中接收到的任何更改。通常并不需要重新初始化订阅数据库，而且只在发布数据库与订阅数据库之间同步备份完成后的数据更改。

若要还原订阅数据库而无需重新初始化订阅，应确保已还原的数据库备份代表某种状态下的订阅数据库，在该状态下已同步定义的发布保持期内的所有订阅。若要将数据库（和事务日志）还原到发布保持期之前的某个即时点，需要重新初始化订阅数据库中的订阅。有关保持期的更多信息，请参见订阅停用和过期。

备份和还原重新发布的数据库

如果某个数据库从发布服务器订阅数据并依次将同样的数据发布给其它订阅数据库，称该数据库为重新发布的数据库。当还原重新发布的数据库时，请遵从本主题中的"备份和还原发布数据库"与"备份和还原订阅数据库"部分介绍的准则。

备份和还原 msdb 系统数据库

发布服务器中的 msdb 数据库包含在 SQL Server 代理程序控制下运行的复制代理程序的作业定义。分发服务器中的 msdb 数据库包含所有快照代理程序、使用请求订阅的代理程序及其它复制代理程序的作业调度、步骤、警报和其它作业组件。每个订阅服务器中的 msdb 数据库都包含所有请求订阅代理程序的相似作业信息。分发服务器中的 msdb 数据库还包含所有复制代理程序的代理程序配置文件信息。

若要在还原一个或多个已复制数据库时提供改进的恢复选项，应定期备份 msdb 数据库。此外，应确保每当在影响复制配置（特别是代理程序配置文件或代理程序属性）的发布数据库、分发数据库或订阅数据库中执行任何数据库维护活动时，应对 msdb 数据库进行精确备份。如果希望在分发服务器或订阅服务器丢失后还原复制，则必须备份 msdb 数据库。

备份和还原 master 数据库

通常并不需要定期备份 master 数据库；不过与备份 msdb 数据库相似，master 数据库也涉及存储有关任何 SQL Server 实例上的已复制数据库的有限配置信息。例如，当启用某服务器作为分发服务器、发布服务器或订阅服务器时，将更新分发服务器中的 master 数据库的 sysservers 表。若要在发布服务器或分发服务器中的 master 数据库丢失后还原复制，请备份发布服务器和分发服务器上的 master 数据库。建议每当在影响复制配置（特别更改已启用的发布服务器或订阅服务器）的发布数据库、分发数据库或订阅数据库中执行任何数据库维护活动时，对 master 数据库进行定期备份。

合并复制、日志传送和可选同步伙伴

Microsoft® SQL Server™ 2000 合并复制可配置成与日志传送一起使用，以便在发布服务器出现故障时提供备用服务器恢复选项。在产生订阅的发布服务器不可用时，合并复制还使订阅服务器得以与备用发布服务器同步。

可选同步伙伴可与支持合并复制的任何 SQL Server 2000 版本一起使用；但是，必须运行 Microsoft SQL Server 2000 企业版才能使用日志传送。因为合并复制直接在发布数据库中跟踪更改，合并复制只在半同步模式下的日志传送中有效。

半同步模式

在半同步模式中，如果在发生故障转移时，还未使用日志传送将主发布服务器与它的订阅服务器之间同步的任何更改传送到备用发布服务器，那么，备用发布服务器与它的订阅服务器有可能在故障转移时不同步。当从备份还原发布数据库时，可能需要在故障转移后重新初始化对发布的所有订阅，或者可以选择与包含最新数据的订阅服务器立即同步。一般情况下，如果主发布服务器发生故障，可立即同步并用日志传送帮助提供可更新副本的连续同步。

可选同步伙伴

与日志传送相似，当主发布服务器发生故障时，在合并复制中使用可选同步伙伴是支持连续同步的一个选择。可用日志传送将所有更改，包括架构更改、用户修改与数据库维护活动，发送到备用发布服务器。为发布服务器上定义的发布指定可选同步伙伴提供了一种方法，可使已复制表内的数据更改与产生订阅的发布服务器以外的服务器同步。与可选同步伙伴保持同步为订阅服务器提供这样的能力：即便主发布服务器不可用，也可同步数据。有关更多信息，请参见可选同步伙伴。

需要已更新备份的常用操作

除定期执行的备份外，建议在修改复制架构或拓扑后还更新发布数据库、分发数据库、订阅数据库、msdb 数据库及 master 数据库的备份。

在发生下列事项后备份发布数据库：

  • 创建新发布。

  • 更改包括筛选在内的任何发布属性。

  • 向现有发布中添加项目。

  • 在整个发布内执行对订阅的重新初始化。

  • 用复制架构更改改变任何已发布的表。

  • 执行请求脚本复制。

  • 清除合并元数据（运行 sp_mergecleanupmetadata）。

  • 更改任何项目属性，包括更改选定的项目冲突解决程序。

  • 除去任何发布。

  • 除去任何项目。

  • 禁用复制。

在发生下列事项后备份分发数据库：

  • 创建或修改复制代理程序配置文件。

  • 修改复制代理程序配置文件参数。

  • 更改任何强制订阅的复制代理程序属性（包括调度）。

在发生下列事项后备份订阅数据库：

  • 更改任何订阅属性。

  • 在发布服务器上更改订阅优先级。

  • 除去任何订阅。

  • 禁用复制。

在发生下列事项后备份 msdb 系统数据库：

  • 启用或禁用复制。

  • 添加或除去分发数据库（在分发服务器上）。

  • 启用或禁用发布数据库（在发布服务器上）。

  • 创建或修改复制代理程序配置文件（在分发服务器上）。

  • 修改任何复制代理程序配置文件参数（在分发服务器上）。

  • 更改任何强制订阅的复制代理程序属性（包括调度）（在分发服务器上）。

  • 更改任何请求订阅的复制代理程序属性（包括调度）（在订阅服务器上）。

在发生下列事项后备份 master 系统数据库：

  • 启用或禁用复制。

  • 添加或除去分发数据库（在分发服务器上）。

  • 启用或禁用发布数据库（在发布服务器上）。

  • 在任何数据库中添加第一个或除去最后一个发布（在发布服务器上）。

  • 在任何数据库中添加第一个或除去最后一个订阅（在订阅服务器上）。

  • 在分发发布者上启用或禁用发布服务器（在发布服务器和分发服务器上）。

  • 在分发发布者上启用或禁用订阅服务器（在订阅服务器和分发服务器上）。


将已复制数据库的备份还原到相同的服务器和数据库

创建数据库备份时，Microsoft® SQL Server™ 2000 为当前数据库中的所有用户表和系统表（包括 sysobjects）创建一个复本。它还为当前数据库创建一个完整的日志文件复本，包括自最近的日志读取事务后发生的所有事件。

将数据库还原到该数据库备份时所在的服务器和数据库时，SQL Server 2000 完全还原该数据库和日志。SQL Server 随后为已还原的数据库读取 master.dbo.sysdatabases.category 列，以确定是否应保留存储在目标数据库中的任何复制设置。

发布数据库

对于事务和合并发布数据库，如果 sysdatabases.category 列的设置指明为发布而启用数据库，则保留复制。对于事务和快照发布数据库，分类位的设置为 1。对于合并发布数据库，分类位的设置为 4。

大多数情况下，将备份还原到该备份创建时所在的服务器和数据库将保留复制设置。然而，如果要从中恢复的故障要求完全重新创建将要还原到的数据库，则需要运行 sp_replicationdboption，或者在还原备份前启用数据库用于事务和合并发布。

注意 如果未运行 sp_replicationdboption，复制设置将在还原操作中丢失。

分发数据库

单个分发服务器中可以存储多个分发数据库：直到由分发服务器提供服务的每个发布服务器有一个分发数据库。备份发布数据库时，创建与其相关联的分发数据库的协调备份很重要。同样，保持复制方案中的事务完整性通常也需要协调这两个数据库间的还原。而且，可能还要考虑协调备份和还原与发布数据库相关联的复制工作目录。这有助于减少在快照和事务复制方案中重新同步订阅服务器所需的时间。

与发布数据库一样，分发数据库也不能还原到任意位置。由于复制发布服务器、分发服务器和订阅服务器中的几个数据库和服务器名称相关性，必需还原到备份创建时的同一服务器和数据库，才能确保正确恢复所复制的数据流。在还原发布数据库时应只还原分发数据库，并始终还原到相同的服务器和数据库。还原分发数据库后，查阅复制代理程序配置文件以确认这些文件按照应用程序的要求设置。

订阅数据库

对于事务复制，订阅数据库包含表 MSreplication_subscriptions，该表存储表示在订阅服务器上接收到的最近事务的数据。备份订阅数据库时自动包含该表。

在还原或附加事务订阅数据库后，应该运行 sp_vupgrade_subscription_tables 以确保创建了所有需要的对象且版本正确。如果不运行 sp_vupgrade_subscription_tables，则复制所必需的对象可能在该订阅数据库中不存在。

合并订阅数据库在内部也作为一类发布数据库而被跟踪。由于此原因，计划备份和还原合并发布数据库时所考虑的事项同样适用于处理合并订阅数据库的情况。

请参见

MSreplication_subscriptions

sp_replicationdboption

sysdatabases

sysobjects


将已复制数据库的备份还原到其它服务器或数据库

将已复制数据库的备份还原到不是备份创建时所在的服务器或数据库时，将无法保留复制设置。对于发布数据库和合并订阅数据库，如果还原到的数据库或服务器与备份创建时所在的数据库或服务器不同，则在还原完整的数据库和日志后将自动删除数据库内的复制元数据。如有必要，可以使用此方法将数据恢复到其它的服务器或数据库，然后设置一个包含已还原数据库的新复制拓扑。