AlwaysON : Log_Send_Queue_Size 正在增加，但 log_send_rate 一直在减少？

问题

1. 为什么尽管这两个数据库的 log_send_queue_size 越来越大，但 log_send_rate 却一直在下降？
2. 此时网络上没有带宽问题，其他数据库也没有遇到此问题。如果再次发生这种情况，除了必须在辅助数据库上手动恢复主数据库以重新同步该对之外，是否有推荐的修复方法？

环境 ：

SQL 2012，SP1 CU7（内部版本 3393）

Windows Server 2012 标准版（内部版本 9200）

10 个数据库的可用性组 (PRDDB1-AG1)

2 个 AG 副本，一个在伦敦，一个在纽约（LDSERVER1 和 NYSERVER1），主要在纽约，次要在伦敦。

AG1 内的 2 个数据库，E-DB1（50GB 日志文件）和T-DB2（250GB 日志文件）

数据库从客户端导入文件，T-DB2处理它们（大量日志活动），然后输出/更新数据库中的E-DB1数据。

此过程会针对两个数据库生成大量数据变动和日志活动。我们偶尔会在伦敦和纽约的数据库副本之间出现延迟高峰，最多可能每周最多一次或两次，但这些总是在几个小时内清除。

问题 ：

上周我们看到 log_send_queue_size 增加，而 log_send_rate 减少。这从星期一开始，一直持续到星期五晚上，当它被手动解决时（请参阅下面的修复部分）。在最低时，E-DB1 数据库的 log_send_rate 刚刚超过 100KB/秒，而 log_send_queue 超过 40GB。T-DB2 数据库的 log_send_rate 为 2000KB/秒，缩小到 300KB/秒，log_send_queue 超过 300GB。

这导致可用性组中这两个数据库的主副本和辅助副本之间的延迟量增加。其特点是在每个受影响的数据库的事务日志中累积日志活动，这是意料之中的。由于这种延迟，受影响的每个数据库的日志都会扩展到日志驱动器有空间不足的危险。

这种延迟只发生在这两个数据库上，尽管可用性组内所有数据库的事务活动出现了相当大的峰值，这是正常的。

在整个问题中，辅助节点上的重做队列没有增加，redo_rate 保持在高位。这意味着问题是由于两个受影响数据库的低发送率造成的。

尝试的步骤

1. 暂停 T-DB2 数据库的数据移动。我希望这会为优先数据库 E-DB1 释放网络带宽。没有效果。

2. 重新启动辅助节点 (LDPRDENTDB1)。没有效果。

使固定

3. 以下步骤解决了该问题。随着日志文件增长到超过 300GB，我需要在磁盘空间用完之前尽快清除和缩小它们。

   一个。从可用性组中删除了数据库。

   湾。删除了辅助数据库。

   C。将数据库重新添加回主要的可用性组（NYSERVER1，手动同步选项）。

   d。备份主数据库并恢复到辅助数据库（70GB 从纽约复制到 LD，不到 24 小时）

   e. 将数据库重新添加回辅助服务器上的可用性组。