重新发布数据

更新日期： 2006 年 12 月 12 日

在重新发布模式中，发布服务器将数据发送至订阅服务器，后者再将数据重新发布至任意数目的其他订阅服务器。 当发布服务器必须通过低速或昂贵的通信链接向订阅服务器发送数据时，这很有用。 如果在链接的远端有许多订阅服务器，那么使用重新发布服务器可将大量分发负荷转移到链接的远端。

重新发布数据分为下列几个步骤：

1. 在发布服务器上创建发布。
2. 为重新发布的订阅服务器创建对发布的订阅。
3. 初始化订阅。 必须先初始化订阅，才可在重新发布的订阅服务器上创建发布，否则复制将失败。
4. 在重新发布的订阅服务器上的订阅数据库中创建发布。
5. 在重新发布的订阅服务器上为其他订阅服务器创建对发布的订阅。
6. 初始化订阅。

注意：
如果在重新发布拓扑中使用合并复制，则所有重新发布的订阅服务器都必须使用服务器订阅。 有关订阅类型的详细信息，请参阅订阅发布。

在下图中，发布服务器和重新发布服务器都作为其自身的本地分发服务器。 如果将它们都设置为使用远程分发服务器，则各分发服务器需要与其发布服务器位于低速或昂贵的通信链接的同一端。 发布服务器必须通过可靠、高速的通信链接连接到远程分发服务器。

任何服务器都可以既作为发布服务器又作为订阅服务器。 例如，在下图中，在伦敦对某个表的发布必须分发至美国的四个不同城市：芝加哥、纽约、圣地亚哥和西雅图。 之所以选择位于纽约的服务器来订阅源于伦敦的发布表，是因为纽约站点满足下列条件：

• 返回伦敦的网络链接相对可靠。
• 伦敦到纽约的通信成本可以接受。
• 从纽约到美国所有其他订阅服务器站点有良好的网络通信线路。
  

复制支持以下重新发布方案：

1您应当为合并发布设置 @published_in_tran_pub 属性。 默认情况下，事务复制将订阅服务器上的表视为只读。 如果合并复制对事务订阅中的表进行了数据更改，则可能发生数据无法收敛的情况。 为避免这种风险，建议您在合并发布中将所有此类表都指定为仅供下载。 这样可以防止合并订阅服务器向表中上载数据更改。 有关详细信息，请参阅使用仅下载项目优化合并复制的性能。

请参阅

概念

配置分发
发布数据和数据库对象
订阅发布
初始化订阅
同步数据

帮助和信息

获取 SQL Server 2005 帮助

更改历史记录