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

Question

题

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/sec，缩小到 300KB/sec，log_send_queue 超过 300GB。

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

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

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

尝试的步骤

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

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

使固定

3. 以下步骤解决了该问题。由于日志文件已增长到 300GB 以上，我需要在磁盘空间用完之前立即清除和缩小它们。

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

   湾 删除了辅助数据库上的数据库。

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

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

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

Answer 1

回答我自己的问题，未来的读者将从中受益：

当您使用 Service Broker、数据库镜像和可用性组时，SQL Server 2012 数据库的延迟似乎可能会更长。这是固定在SQL server 2012 SP2 CU1. 有KB 2976982一个拼写错误（AlawysOn）。因此，如果您通过AlwaysON 进行搜索，它不会显示。

应用补丁后，问题得到解决。