SQL Server 发布订阅 发布类型详解

数据通常在服务器之间进行复制，以支持下列应用程序和要求：

数据通常在服务器和客户端（包括工作站、便携式电脑、Tablet 和设置）之间复制，以支持下列应用程序：

快照处理通常用于为事务和合并发布提供初始的数据集和数据库对象，但快照复制还可为其自身所用。 当符合以下一个或多个条件时，使用快照复制本身是最合适的：

• 很少更改数据。

• 在一段时间内允许具有相对发布服务器已过时的数据副本。

• 复制少量数据。

• 在短期内出现大量更改。

在数据更改量很大，但很少发生更改时，快照复制是最合适的。 例如，如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新，那么建议在数据更改后复制完整的数据快照。

事务复制通常用于服务器到服务器环境中，在以下各种情况下适合采用事务复制：

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

• 从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短。

• 应用程序需要访问中间数据状态。 例如，如果某一行更改了五次，事务复制将允许应用程序响应每次更改（例如，激发触发器），而不只是响应该行最终的数据更改。

• 发布服务器有大量的插入、更新和删除活动。

• 发布服务器或订阅服务器不是 SQL Server 数据库（例如，Oracle）。

默认情况下，事务发布订阅服务器应作只读处理，因为更改并不传播回发布服务器。 但是，事务复制确实提供了允许在订阅服务器上进行更新的选项。 有关详细信息，请参阅本主题中的“在订阅服务器中更新数据”部分。

合并复制通常用于服务器到客户端的环境中。 合并复制适用于下列各种情况：

• 多个订阅服务器可能会在不同时间更新同一数据，并将这些更改传播到发布服务器和其他订阅服务器。

• 订阅服务器需要接收数据，脱机进行更改，并在随后与发布服务器和其他订阅服务器同步更改。

• 每个订阅服务器都需要不同分区的数据。

• 可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。

• 应用程序需要最终的数据更改结果，而不是访问中间数据状态。 例如，在订阅服务器与发布服务器同步前，如果订阅服务器上的行更改了五次，则该行将只在发布服务器上更改一次，以反映最终数据更改（也就是更改为第五个值）。

合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。 由于更新是在多个节点上进行的，同一数据可能由发布服务器和多个订阅服务器进行了更新。 因此，在合并更新时可能会产生冲突，合并复制提供了多种处理冲突的方法。