几年来，我们一直在使用 SQL Server 合并复制来同步数据中心之间的数据，但现在我们遇到了一个严重的性能问题。这可能是因为我们今年同步的数据量增加了很多。我们的发布者是英国的一个永远在线的数据中心。我们的订阅者是一个移动数据中心，它环游世界，每次开启的时间长达一周，每年大约 25 次。然而，它在旅途中也会花费同样多的时间（如果不是更多的话）处于关闭状态——它是一个经常旅行的数据中心！
我们有 5 个数据库在这些服务器上同步。但是，我们的一个数据库在订阅者停机期间有大量数据更改，我们的问题是，当服务器启动时，需要几天时间才能赶上 - 其他数据库都很好。从发布者到订阅者的下载速度约为每秒 1.5 行（当我们有数十万行时，这很烦人），但奇怪的是，从订阅者到发布者的上传速度大约快十倍。
我已检查/尝试过的事情：• 所有表在设置了 rowguid 属性的 guid 列上都有非聚集主键 • 更改生成平衡阈值无济于事 • 将代理配置文件设置为高容量无济于事 • 在发布者和订阅者上运行跟踪显示查询都运行得非常快（通常少于 20 m/s，但某些查询批次之间存在 200 m/s 左右的间隙）• 对我们的 WAN 链路的分析表明我们有大量带宽备用 • 对我们的服务器的分析表明我们有大量 Ram 和 CPU 备用
某些用户所在的位置确实存在高延迟，但这似乎并没有产生影响 - 300 m/s 或 100 m/s，我们仍然会得到同样糟糕的性能。
我确实想知道一件事 - 每次成功处理订阅者中的一行时，复制都会向发布者确认吗？如果我们有数千行数据，并且线路上有延迟，那么如果它确认每个项目，这是否会使问题更加严重？如果确实发生这种情况，是否有办法在发布者和订阅者之间批量处理消息？
我们将非常高兴收到您提供的任何帮助！
答案1
我们最终查明了此事。
我们使用 nvarchar(max) 列阻止了使用批处理进行复制。过去需要 3 小时才能完成的工作，现在只需更改数据类型，只需 50 秒即可完成。
以下是我们学到的教训：“nvarchar(max) 是复制杀手”
谢谢