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

• 制作原始数据库的副本，将其冻结，通过飞机将文件发送给订阅服务器，并在没有快照的情况下启动复制：这是传统上使用旧版SQL进行的操作，但对我来说听起来有些混乱将不得不将我的发布者的数据置于只读模式，并停止所有复制，直到操作完成。
• 创建数据快照，将快照文件发送到国外，将其安装在订阅服务器上，并在复制属性中将新快照位置指示为备用位置。这对我来说听起来很公平(无需暂停正在进行的复制，无需冻结数据)，但是就这一点而言，微软的帮助并没有帮助。

我相信你们当中有些人已经遇到过这种情况。选择是什么？

编辑：当然，有人会说"你为什么不试一试你的想法"，但是要花几个小时(多个sql-servers，虚拟机实例以及所有类似的东西...)，我当时以为这样做的人只需要2分钟就能解释他的想法。如果有人接受放松2分钟的时间来节省我数小时的辛苦工作，我将是最快乐的人...

解决方案

我们只是经历了这样的事情，而且还不是很漂亮。即使涉及的所有服务器都是本地服务器，仍然花费了很长时间。

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

我可以提供的最佳建议是确保每个站点都具有良好的备份。这样，至少不必将数据手工传送给订户。

从加利福尼亚州洛杉矶复制数据到中国时，我必须做类似的事情。使用常规方法加载该快照将需要44天。

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

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

此方法仅花费了大约28个小时，而不是一个多月。

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