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

本文主要是介绍SQL Server 发布订阅 发布类型详解，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

MicrosoftSQL Server 提供了三种复制类型。 每种复制类型都适合于不同应用程序的要求。 根据应用程序需要，可以在拓扑中使用一种或多种复制类型：

• 快照复制

• 事务复制

• 合并复制

为了帮助您选择适当的复制类型，此主题提供了有关下列内容的信息：

• 复制方案

  本部分简要描述了复制的多种常用情况，还提供了指向更加详细描述的链接。

• 复制类型

  本部分描述了每个复制类型所适合的应用程序要求。

• 在订阅服务器上更新数据

  本部分描述了需要在订阅服务器上更新数据的应用程序的可用选项。

我们建议您先要通读方案描述，找出与应用程序要求最匹配的方案，然后单击链接查看详细信息。 如果找不到与业务要求近似匹配的方案，或者希望得到有关复制类型的其他信息，则请阅读“复制类型”。 如果应用程序需要在一个或多个订阅服务器上更新，则请阅读“在订阅服务器中更新数据”，以确定可使用的适当技术。

复制方案可以分为两大类： 在服务器到服务器环境中复制数据和在服务器与客户端间复制数据。 服务器到服务器方案使用事务复制（有时也可使用快照复制）实现；服务器和客户端方案使用合并复制实现。

服务器到服务器方案

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

服务器和客户端方案

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

快照复制

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

• 很少更改数据。

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

• 复制少量数据。

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

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

事务复制

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

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

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

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

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

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

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

合并复制

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

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

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

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

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

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

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

下列类型的复制和复制选项允许在订阅服务器上进行更改，并使这些更改流向发布服务器：

这篇关于SQL Server 发布订阅 发布类型详解的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！