MS-SQL Server 2005：使用备用快照位置初始化合并订阅

Question

一年前我们开始了一些海外合并复制，到目前为止一切都很好。我的问题是，我们的系统中现在有如此多的数据，以至于订阅者的服务器上的任何崩溃都将是一场灾难：以标准方式重新初始化订阅将需要几天时间（我们的连接肯定很慢，但已经非常非常昂贵）！我一直在跟进的想法如下：

1. 复制原件 数据库，冻结它，发送文件 乘飞机到订户，和 无需启动复制 快照：这是 传统上与老年人一起完成 SQL 的版本，但听起来 对我来说有点乱：我会的 将我的发布者的数据放入 只读模式并停止所有 复制直到操作完成 完成。
2. 制作数据快照， 将快照文件发送到国外， 将它们安装在订阅者上，并且 指示新的快照位置 作为一个备用位置 复制属性。这个 对我来说听起来很公平（没有必要暂停正在进行的复制，没有数据冻结），但是，在这个 点，微软帮助不... 帮助。

我相信你们中的一些人已经经历过这种情况。你的选择是什么？

编辑：当然，有人可以说“你为什么不试试你的想法”，但这需要几个小时（sql-servers、虚拟机和所有这些东西的多个实例......） , 我在想那个人只需要 2 分钟就可以解释他的想法。如果有人愿意腾出 2 分钟的时间来为我节省数小时的辛勤工作，我将是最幸福的人......

Answer 1

在将数据从加利福尼亚州洛杉矶复制到中国时，我不得不做类似的事情。使用普通方法加载快照需要 44 天。

我所做的是将 SQL 复制配置为使用快照的本地路径。然后我禁用了事务工作（在你的情况下是合并工作）。然后我运行了快照。我将快照压缩并将文件从加利福尼亚通过 FTP 传输到中国。当他们到达中国时，我将它们解压缩并将它们放在我在加利福尼亚使用的相同文件夹路径中。

然后我从中国服务器上的命令行运行 distrib.exe。这会将数据加载到中国的表中。加载快照后，我关闭了中国服务器上的分发器，并启动了加利福尼亚服务器上的普通分发器。

这种方法只用了大约 28 小时，而不是一个多月。

如果您的数据需要几天时间才能到达目的地，那么您将需要编辑发布并增加可以排队的数据量，否则订阅者将超时并且新的快照将需要服用。

Answer 2

我们刚刚经历了这样的事情，它并不漂亮。即使涉及的所有服务器都是本地的，但仍然需要很长时间。

只是为了让事情变得更加困难，至少对于 SQL 2000，如果压缩的 cab 超过 4 Gig，则快照将失败。

我能提供的最佳建议是确保每个站点都有可用的良好备份。这样一来，至少不必将数据随身携带给订户。