执行查询时合并复制失败

Question

今天早上我的合并复制工作正常。从一两个小时前开始，我的同步状态窗口一直显示此消息：

线程 ID 3108 将等待 15 秒，然后重试发布者“MSI-SQL-MAS01”上的查询。

谁能告诉我这是怎么回事？该数据库大小为 500Gb，而且使用率也很高。但是，复制必须工作，我们需要保持订阅者处的数据库同步。

这也是我在一分钟左右后看到的：

在发布者 'MSI-SQL-MAS01' 上执行的查询失败，因为连接被选为死锁的受害者。如果在合并过程进行内部重试后仍然看到此错误，请重新运行合并过程。

就像我刚才说的，今天早上复制工作正常。我还像建议的错误一样重新启动了合并代理，但没有结果。

我也试过

更新 sysmergepublications 集 [generation_leveling_threshold] = 0

在订阅者和发布者数据库中，但似乎没有运气……有时也会出现以下错误：

合并进程正在重试对文章“xx”所做的失败操作 - 原因：“合并进程无法同步行。”。

提前致谢。

---

我再也看不到我以前的错误了。我现在唯一得到的是：

“合并进程正在重试对文章 'xx' 进行的失败操作 - 原因：'合并进程无法同步该行。'。”

探查器对我来说毫无意义。我没有看到任何相关信息。

如果我重新初始化订阅，它会做什么？我希望我不需要为此创建新快照，因为此时这是不可能的。数据库大小超过 500Gb，快照需要 9 多个小时才能完成。数据库一直在生产中并且使用非常频繁，因此锁定数据库以创建快照实际上是行不通的。

---

好吧，这就是我在冲突查看器中看到的：

'master_server' 和 'slave_server' 都更新了同一行。解析器选择来自“master_server”的更新作为获胜者。

当我们的应用程序连接到主服务器时，如何在主服务器和从服务器上更新同一行？看起来有些东西正在用不同的内容更新两台服务器上的同一行并导致合并代理崩溃？

Answer 1

我怀疑问题不是合并复制，而是死锁。获取包含死锁图的 Profiler 跟踪，并从那里进行故障排除。如果您在一段时间后仍无法弄清楚问题的根源，请尝试重新初始化订阅。