合并复制同步很慢

Question

我遇到了一个无法预料的问题，sub 掉线了（一般错误，可能是连接问题），现在我重新连接了 sub，它的重新同步速度非常慢。它似乎下载了大约 1000 个更改，然后在那里放置了大约一个小时，然后再添加 1000 个。

任何想法为什么这会如此缓慢？这只是一个几十人的桌子，我觉得这不会在星期一之前赶上（当我有用户打算上网时）。

任何帮助表示赞赏！谢谢！

更新

它现在已经运行了超过 24 小时，并且正在慢慢地咀嚼记录，但速度仍然非常缓慢。它现在在上面的镜头和“使用订阅者分配的分区 ID 枚举过滤文章中的更改”之间切换。是的，有一个过滤器，但自从我第一次设置复制以来它就一直存在，以前从未引起过问题。

第二次更新

当我进入复制监视器时出现错误：

The replication agent has not logged a progress message in 10 minutes. This might indicate an unresponsive agent or high system activity. Verify that records are being replicated to the destination and that connections to the Subscriber, Publisher, and Distributor are still active.

但奇怪的是，系统活动为零，并且我在此发布上有另一个订阅者工作，以及从同一发布者到同一订阅者的辅助复制工作正常。我试过停止和重新启动，拍摄并应用新的快照，但似乎没有任何效果。没有阻塞的进程，没有死锁的活动查询或我能想到的任何其他检查。

要清楚：

• 出版物 A => Sub 1: WORKING
• 出版物 A => Sub 2: NOT WORKING
• 出版物 B => Sub 1: WORKING
• 出版物 B => Sub 2: WORKING

如果有人有任何帮助，我将不胜感激。

Answer 1

有很多因素会影响复制。我遇到的一些常见因素与网络缓慢、阻塞和存储问题有关。但可能是一个因素是虚拟日志文件的性能问题。如果您正在初始化一个包含大量数据的数据库，并且默认的增长因子已到位，那么 sql server 将一次将数据增长 1mb，将日志一次增长 10%。要检查 VLF 问题，请运行 dbcc loginfo。如果该命令返回超过 100 条记录，我会担心。如果它返回数千条记录，那么它将对性能产生真正的影响。关于这个主题有很多文章。基本修复是将所有数据和日志文件的自动增长设置调整为合理的大小，然后缩小日志文件并将其初始化回原始大小。我会检查所有数据库，包括分发数据库。分发数据库分发事务速度缓慢也可能有其他原因。我过去在几个事务复制系统上经历过这种情况，并且对每次纠正此问题的影响感到惊讶。

我还怀疑锁定了出版商。识别复制中涉及的 spid，并使用动态管理视图 sys.dm_os_waiting_tasks 来确定这些会话中涉及哪些等待。这将有助于确定这些订阅正在等待什么。