我在我们公司设置了合并复制，以中央 SQL 2005 作为发布者/分发者，客户端都是 SQL 2005 Express。
在我们的远程分支中，我们在初始同步时间方面遇到了困难。数据库约为 2GB，首次运行需要一个多小时。在排除故障时，我注意到我可以指定备用快照位置，然后可以选择压缩它。
我尝试了这个（压缩），它压缩效果非常好，但我想知道打开它时应该注意什么。我注意到它是一个压缩形式的单个 .cab 文件，而不是之前的所有单个脚本文件。
有什么收获？
为什么不总是使用压缩格式？
如果两者都被选中，默认和备用压缩，我该如何告诉它使用其中一个？
答案1
最大的问题是 CAB 文件的大小是有限的。如果尝试将 CAB 文件的大小设为大于所支持的大小，快照代理将崩溃。我认为限制是 2 GB。
压缩快照需要大量的 CPU 能力。有些人可能没有足够的 CPU 能力。而且在 LAN 上，这实际上没有任何意义，因为创建快照的时间会增加，而传输时间并没有真正减少。
如果同时选中两个，则将使用这两个设置。如果同时启用两个，则无法指示它使用其中一个。
答案2
就您的情况而言（快照约 2GB），这绝对不是初始化复制的正确方法（通过应用快照）。事实上，您永远不应该从发布者端初始化订阅。而是使用备份-恢复策略。 http://technet.microsoft.com/en-us/library/ms152488.aspx
- 备份出版物 db.rar（压缩）备份文件并通过任何方式将其发送给订阅者。
- 在订阅数据库上恢复它。确保在“选项”页面上取消选中“保留复制设置（WITH KEEP_REPLICAITON）”。我通常更喜欢选中“覆盖现有数据库”。当然，记得验证文件名，因为它们的路径与发布者处存在的路径相同。
- 创建订阅并确保在向导中取消选中初始化订阅，因为您已经手动初始化它。
如果微软无法提出替代方案，我很奇怪为什么他们自 2005 年起就将此解决方案标记为已弃用。
答案3
“事实上，你永远不应该从发布者端初始化订阅”——不知道这句话从何而来，但我绝对不认为这是真的。你应该在发布上创建快照，可以选择将其发布到分发服务器，然后从那里初始化。备份-恢复策略是一种即将被弃用的替代方案，不是推荐的方法。
mrdenny 是正确的，压缩快照文件夹的代价是发布者需要压缩处理能力，而订阅者需要解压处理能力。对于较小的快照，非压缩快照的性能会更好，但对于较大的快照（如您的快照），使用压缩可能会获得更好的性能，试验将有助于确定更好的方法。