有没有其他人遇到过这个？你的情况是如何解决的？它是由 SQL Server 之外的因素引起的吗？副本（主要到次要）或存储 IO 之间的网络传输？
我尝试询问基础架构团队是否可以在 VMWare vCenter 中检查某种类型的 QoS 或 DRS 策略，以防止对 VM 进行节流或洗牌。
此特定 VM 是 ASYNC 模式下的异地节点。该消息发生在一天中的不同时间并针对多个数据库。大多数情况下每天发生一次，但有时最多每天发生 4 次。间隔即。上午 3 点至 6 点，上午 10 点至下午 12 点。似乎取决于主节点上的活动工作负载。这只是一条信息性消息，之后同步确实进行得很好。
- - -原始信息 - - -
来自：不回复
发送：2017 年 8 月 11 日星期五凌晨 3:37
至：海勒姆
主题：SQL Server 警报系统：\SVRSQL02 上出现“其他用户错误”
日期/时间：2017 年 8 月 11 日凌晨 3:36:43
描述： Always On 可用性组传输检测到可用性数据库“MyDB”缺少日志块。最后应用的日志块的 LSN 是 (69168:224114:0)。将重新启动日志扫描以解决此问题。这只是一条信息性消息。无需用户操作。
评论：（无）
作业运行：（无）
我考虑启用跟踪标志 9587 以将 AG 恢复为顺序处理，但这似乎会降低性能。
Always On 可用性组主副本上的事务吞吐量低
症状：当您在 SQL Server 2016 中配置 Always On 可用性组时，您可能会遇到间歇性的低吞吐量期。发生此问题时，您可能还会注意到 HADR_SYNC_COMMIT 进程的等待时间很长。
此外，辅助副本实例上的错误日志报告以下错误：
错误：19432，严重性：16，状态：0 Always On 可用性组传输检测到可用性数据库“”缺少日志块。最后应用的日志块的 LSN 是 (xxx:xxxxxxxx:x)。将重新启动日志扫描以解决此问题。这只是一条信息性消息。无需用户操作。
解决方法：要解决此问题，请将跟踪标志 9587 添加为参与 Always On 可用性组配置的副本实例的启动参数。
SQL Server 的未来更新将不再需要使用跟踪标志 9587。此标志会导致可用性组的传输层恢复为顺序处理，从而禁用 SQL Server 2016 中 Always On 可用性组的性能吞吐量改进。除非您是遇到“症状”部分中描述的问题，我们不建议您应用跟踪标志 9587。
属性：文章 ID：3201336 - 上次审核：2016 年 10 月 25 日 - 修订：1
适用于：Microsoft SQL Server 2016 Standard、Microsoft SQL Server 2016 Enterprise、Microsoft SQL Server 2016 Developer