今天上午，在执行两个新表的例行数据库部署之后，我注意到事务复制停止了3个多小时。 当恢复复制时，它会在3个多小时后恢复，就好像什么都没发生一样，在订户的数据中留下了3个小时的间隔。 例如，复制在凌晨3:30停止，然后在早上6:30恢复，但在上午3:30到6:30之间没有复制数据。
没有发现复制错误，没有数据库/服务器错误，复制监视器显示零延迟。 交易日志相当大（能力为61％），但是没有发现错误。 在没有任何内容被复制的3小时内，sp_replmonitorsubscriptionpendingcmds显示没有未决事务。
我能够确定数据停止stream动，因为我们有一个不断logging应用程序事件的表。 在这个时期唯一的工作就是重build一张大表，大约10亿行。 工作复制停顿前30分钟开始工作，总共持续了40分钟。
我们的环境由两个configuration为对等事务复制的大型数据库组成。 我们不会像预期的那样利用环境。 一个数据库是我们面向数据库的主要客户，而另一个则是实时报告，而不是读写这两个数据库。 如果主数据库损坏，我们最初认为点对点是一种廉价的灾难恢复解决scheme。 迄今为止，我们还没有使用它，事后应该使用简单的事务复制来代替。
一旦复制开始在发布者和订阅者数据库之间再次stream动复制监视器显示一些延迟，并且sp_replmonitorsubscriptionpendingcmds显示未决事务。 大约90分钟后，等待时间为零，一切恢复正常，但用户数据有3个多小时的差距。
我不明白这是怎么发生的，没有任何错误？ 我会想象如果复制停止突然它会发生，因为一个例外。 我做了一些Googlesearch，发现了有关Replication Agent Stalls的一些信息，但没有定论。 我不知道发生了什么，也没有太多的事情要继续下去。 有谁知道解决这个问题的最佳方法？ 有人曾经经历过这个吗？ 有人能帮助我指出正确的方向吗？ 任何帮助将不胜感激。