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