集成来自多个站点（服务器）的数据
很多公司都在不同的地方设有办事处或机构，这些办事处或机构收集和处理的数据必须发送到中央位置。 例如：
库存数据可以从本地仓库的多个服务器中“汇总”或合并到公司总部的中央服务器。
来自公司内部各个独立业务部门的信息可以发送到中央服务器。
来自各个分散位置的订单处理信息可以合并到一起。
在某些情况下，数据还将从中央位置发送到远程位置。 这些数据在远程位置通常为只读数据，如仅限在中央位置进行更新的一组产品库存表。
下面的关系图显示了一种典型的方案，此方案中数据从远程位置进行汇总。 只读数据也将发送到每个远程位置。
.gif "向区域办事处复制数据")
Adventure Works Cycles 示例
Adventure Works Cycles 是一家虚构的制造公司，用于演示数据库概念和方案。有关详细信息，请参阅AdventureWorks 示例数据库。
Adventure Works Cycles 在美国国内有很多区域销售办事处。 这些办事处以两种方式使用复制：
为履行订单和生成报表提供订单信息。 数据在每个销售办事处进行收集和处理，然后复制到中心办公室。
为移动销售人员提供数据和订购功能。 此方案在与移动用户交换数据主题中进行介绍。
此方案的一般要求
针对区域办事处的应用程序通常有下列要求，在相应复制解决方案中必须考虑到这些要求：
系统必须保持事务的一致性。
系统的滞后时间应较短： 远程位置的更新必须快速到达中心位置。
系统的吞吐量应较大： 应能处理大量事务的复制。
复制处理在远程位置所需开销应为最小。
数据更改可能会沿两个方向流动： 某些情况下，除了数据从远程位置合并到中央位置之外，只读数据也将发送到远程位置。
中央位置所需数据可能是每个远程位置上可用的数据子集。
用于此方案的复制类型
MicrosoftSQL Server 使用出版业的术语来描述复制系统的组件。 这些组件包括发布服务器、订阅服务器、发布、项目和订阅。
在上面的关系图中，每个远程位置都是发布服务器。 远程位置上的一些或所有数据包含在发布中，并且，每个数据表都是一个项目（项目也可以是其他数据库对象，如存储过程）。 中央位置是这些发布的订阅服务器，可将架构和数据作为订阅来接收。
中央位置还可作为发送到远程位置的数据的发布服务器使用。 每个远程位置都从中央位置订阅发布。
有关系统组件的详细信息，请参阅复制发布模型概述。
SQL Server 针对不同应用程序的要求提供了不同的复制类型： 快照复制、事务复制以及合并复制。 此方案最好用事务复制来实现，事务复制非常适合于处理上一部分中所述的要求。 有关事务复制的详细信息，请参阅事务复制概述和事务复制的工作机制。
按照设计，事务复制可处理此方案下列主要要求：
事务的一致性
较短的滞后时间
大吞吐量
尽量小的开销
.gif "注意") 注意 |
|---|
相似的方案可以用合并发布实现。 如果应用程序需要冲突解决或需要为每个远程位置提供唯一数据集的筛选器，请使用合并复制。 有关详细信息，请参阅集成来自多个站点（客户端）的数据。 |
实现此方案的步骤
若要实现此方案，必须先创建一个发布和一些订阅，然后对各个订阅进行初始化。 有关各步骤的详细信息，请单击下面的链接：
在对订阅进行了初始化且数据开始在发布服务器和订阅服务器之间流动之后，您可能需要查阅以下主题，了解常见管理任务和监视任务的有关信息：