选择适当的复制类型
Microsoft SQL Server 提供了三种复制类型。 每种复制类型都适合于不同应用程序的要求。 根据应用程序需要，可以在拓扑中使用一种或多种复制类型：
快照复制
事务复制
合并复制
为了帮助您选择适当的复制类型，此主题提供了有关下列内容的信息：
复制方案
本部分简要描述了复制的多种常用情况，还提供了指向更加详细描述的链接。
复制类型
本部分描述了每个复制类型所适合的应用程序要求。
在订阅服务器上更新数据
本部分描述了需要在订阅服务器上更新数据的应用程序的可用选项。
我们建议您先要通读方案描述，找出与应用程序要求最匹配的方案，然后单击链接查看详细信息。 如果找不到与业务要求近似匹配的方案，或者希望得到有关复制类型的其他信息，则请阅读“复制类型”。 如果应用程序需要在一个或多个订阅服务器上更新，则请阅读“在订阅服务器中更新数据”，以确定可使用的适当技术。
复制方案
复制方案可以分为两大类： 在服务器到服务器环境中复制数据和在服务器与客户端间复制数据。 服务器到服务器方案使用事务复制（有时也可使用快照复制）实现；服务器和客户端方案使用合并复制实现。
服务器到服务器方案
数据通常在服务器之间进行复制，以支持下列应用程序和要求：
方案 |
说明 |
|---|---|
提高伸缩性和可用性 |
通过维护不断更新的数据副本，可以将读取活动扩展到多台服务器。 执行计划系统维护和非计划系统维护期间，应为同一数据维护多个副本以实现数据冗余，这一点至关重要。 有关详细信息，请参阅改善伸缩性和可用性。 |
数据仓库和报表 |
数据仓库和报表服务器通常使用联机事务处理 (OLTP) 服务器中的数据。 使用复制在 OLTP 服务器和报表与决策支持系统之间移动数据。 有关详细信息，请参阅数据仓库和报告。 |
集成来自多个站点的数据 |
数据通常从各个远程办事处“汇入”总部并在总部进行整合。 同样，数据也可以从总部复制到远程办事处。 有关详细信息，请参阅集成来自多个站点（服务器）的数据。 |
集成异类数据 |
有些应用程序要依赖于发送至或来自非 Microsoft SQL Server 的数据库的数据。 使用复制集成来自非 SQL Server 数据库的数据。 有关详细信息，请参阅集成异类数据。 |
卸载批处理 |
批处理操作由于通常会占用过多资源而无法在 OLTP 服务器上运行。 使用复制将批处理任务卸载到专用批处理服务器上。 有关详细信息，请参阅卸载批处理。 |
服务器和客户端方案
数据通常在服务器和客户端（包括工作站、便携式电脑、Tablet 和设置）之间复制，以支持下列应用程序：
方案 |
说明 |
|---|---|
与移动用户交换数据 |
许多应用程序要求数据可用于远程用户，包括销售人员、送货司机等。 这些应用程序包括客户关系管理 (CRM) 应用程序、销售自动化 (SFA) 应用程序和现场自动化 (FFA) 应用程序。 有关详细信息，请参阅与移动用户交换数据。 |
消费者销售点 (POS) 应用程序 |
POS 应用程序（如结算终端和 ATM 机）要求将数据从远程站点复制到中心站点。 有关详细信息，请参阅使用者销售点 (POS) 应用程序。 |
集成来自多个站点的数据 |
应用程序通常集成来自多个站点的数据。 例如，支持区域办事处的应用程序可能要求数据在区域办事处和总部之间单向或双向流动。 有关详细信息，请参阅集成来自多个站点（客户端）的数据。 |
复制类型
快照复制
快照处理通常用于为事务和合并发布提供初始的数据集和数据库对象，但快照复制还可为其自身所用。 当符合以下一个或多个条件时，使用快照复制本身是最合适的：
很少更改数据。
在一段时间内允许具有相对发布服务器已过时的数据副本。
复制少量数据。
在短期内出现大量更改。
在数据更改量很大，但很少发生更改时，快照复制是最合适的。 例如，如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新，那么建议在数据更改后复制完整的数据快照。
事务复制
事务复制通常用于服务器到服务器环境中，在以下各种情况下适合采用事务复制：
希望发生增量更改时将其传播到订阅服务器。
从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短。
应用程序需要访问中间数据状态。 例如，如果某一行更改了五次，事务复制将允许应用程序响应每次更改（例如，激发触发器），而不只是响应该行最终的数据更改。
发布服务器有大量的插入、更新和删除活动。
发布服务器或订阅服务器不是 SQL Server 数据库（例如，Oracle）。
默认情况下，事务发布订阅服务器应作只读处理，因为更改并不传播回发布服务器。 但是，事务复制确实提供了允许在订阅服务器上进行更新的选项。 有关详细信息，请参阅本主题中的“在订阅服务器中更新数据”部分。
合并复制
合并复制通常用于服务器到客户端的环境中。 合并复制适用于下列各种情况：
多个订阅服务器可能会在不同时间更新同一数据，并将这些更改传播到发布服务器和其他订阅服务器。
订阅服务器需要接收数据，脱机进行更改，并在随后与发布服务器和其他订阅服务器同步更改。
每个订阅服务器都需要不同分区的数据。
可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。
应用程序需要最终的数据更改结果，而不是访问中间数据状态。 例如，在订阅服务器与发布服务器同步前，如果订阅服务器上的行更改了五次，则该行将只在发布服务器上更改一次，以反映最终数据更改（也就是更改为第五个值）。
合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。 由于更新是在多个节点上进行的，同一数据可能由发布服务器和多个订阅服务器进行了更新。 因此，在合并更新时可能会产生冲突，合并复制提供了多种处理冲突的方法。
在订阅服务器上更新数据
下列类型的复制和复制选项允许在订阅服务器上进行更改，并使这些更改流向发布服务器：
复制类型 |
何时使用... |
|---|---|
合并复制 |
|
对等事务复制 |
有关详细信息，请参阅对等事务复制。 |
带有更新订阅的事务复制 |
有关详细信息，请参阅事务复制的可更新订阅。 |