SQL合并复制 – 压缩快照

我有一个中央SQL 2005作为发布者/分发者在我们公司设置了合并复制，客户端都是SQL 2005 Express。

在我们的远程分支机构，我们在初始同步时间方面有困难。该数据库是〜2GB，第一次运行需要一个多小时。在解决这个问题时，我注意到我可以指定一个备用的快照位置，然后可以select压缩它。

我试过（压缩），它显着压缩，但我想知道我应该知道什么时候打开它。我注意到这是一个单一的.cab文件压缩forms与以前的所有个人脚本文件。

最大的问题是CAB文件只能这么大。如果试图使CAB文件大于所支持的大小，则快照代理将崩溃。我认为这个限制是2 Gig。

压缩快照需要很多的CPU资源。有些人可能没有CPU的余力。而通过局域网，实际上没有任何意义，因为创build快照的时间将会增加，传输时间也不会实际减less。

如果两者都被选中，则使用这两个设置。如果两者都启用，则不能告诉它使用一个或另一个。

在你的情况下（快照~2GB）这绝对不是正确的初始化复制方式（通过应用快照）。事实上，你永远不应该从发行商一方初始化订阅。而是使用备份还原策略。 http://technet.microsoft.com/en-us/library/ms152488.aspx

备份发布数据库。 RAR（压缩）备份文件并通过任何方式将其发送给用户。
在订阅数据库上恢复它。确保在选项页面上取消选中保留复制设置（WITH KEEP_REPLICAITON）。我通常更喜欢检查覆盖现有的数据库。当然还记得要validation这些文件名，因为它们是出版商目前的path。
创build订阅并确保取消选中向导中的“初始化订阅”，因为您已经手动对其进行了初始化。

我想知道为什么他们将这个解决scheme标记为自2005年以来弃用，如果MS不能提出替代scheme。

“事实上，你永远不应该从发行商方面初始化订阅” – 不知道从哪里来，但我绝对不认为这是真的。您应该在出版物上创build快照，也可以select将其发布到分发服务器，然后从此处进行初始化。备份还原策略是一个即将被弃用的备选scheme，不是推荐的方法。

mrdenny是正确的，与压缩的快照文件夹的折衷是压缩发布者所需的处理能力，并且为订阅者解压缩。对于较小的快照，您可以从非压缩的快照中获得更好的性能，但是对于较大的快照（如您的），使用压缩可能会获得更好的性能，试验将有助于确定更好的方法。