AlwaysOn AG 辅助副本具有高重做队列大小和估计恢复时间且重做速率良好的原因是什么？

Question

SQL14 是主服务器，SQL16 是辅助副本，它们使用同步提交可用性模式进行设置：

截至昨天，数据似乎停止从主服务器同步到副本服务器。今天早上我们暂停了可用性数据库，然后恢复了它。当我现在看到新数据通过时，这似乎再次启动了同步，但仪表板中的重做队列大小和估计恢复时间仍然很大并且还在继续增长。

我可以检查/做些什么来解决这个问题？

附加信息：服务器版本：SQL Server 2016 Enterprise - SP1（在主服务器和辅助服务器上）

此外，我们有一些长时间运行的索引重新组织/重新构建作业在早上早些时候在主服务器上失败。（那是大约 4 小时前的事，但现在这是否仍然可能是导致此问题的潜在因素？）

我注意到辅助服务器上的以下服务器日志（从最旧到最新）：

不知道里面有没有什么线索？

辅助节点上的 DBCC OPENTRAN 返回以下内容：

扩展事件会话以跟踪辅助节点上的等待：

Answer 1

所以这里有很多事情......（例如，这将是一个很长的答案，可能会经历多次迭代）：

首先，这个 AG 是否经历了故障转移？如果没有，那么检查主节点上的 ERRORLOG 是我建议您开始故障排除过程的地方；如果确实发生了故障转移，请检查正式称为主节点的节点上的 ERRORLOG以查看发生了什么。您可以在 SSMS 中使用笨拙的 UI，也可以使用未记录的扩展过程xp_readerrorlog，这是我的建议，因为这样可以更快地过滤掉噪音。例如，我建议开始寻找对 AG 名称的任何引用，如下所示并从那里挖掘：

xp_readerrorlog 0, 1, N'>>YOUR AG NAME HERE<<', NULL, '2019-11-18 12:00:00.000', '2019-11-19 15:00:00.000', NULL, NULL

检查上面的链接以了解命令周围的语法。

根据您找到的内容，扩展搜索以检查您的 Windows 事件日志 (eventvwr.msc)、群集日志 (cluadmin.msc)、应用程序日志等，如有必要，使用错误时间作为参考点。我高度怀疑这些日志将确定导致同步停止的原因，无论是与集群相关的问题，还是由于维护造成的打嗝等。基于此，如果您很难解释结果，我建议发布一个新问题.

其次，在 AG 中运行索引维护会导致 AG 同步延迟。无论 SQL Server 的版本（包括 SQL 2019）如何，都无法绕过它，尽管新版本往往恢复得更快。如果您觉得必须运行索引维护并且您有能力使应用程序脱机，我建议您运行脱机索引维护。将其作为离线REBUILDs执行并MAXDOP定义，因为离线索引重建操作不会在您的 AG 内造成严重的延迟。显然这种方法会导致中断，所以这不是一件容易的事。我确实支持这样一种环境，因为忽略索引维护会导致不必要的增长（并且在导致其他问题的多 TB 系统中）

说白了，SQL Server 社区中一个常见的误解是索引维护对数据库的性能非常重要。通常情况并非如此，因为索引碎片对执行计划行为的影响很小。只有当每页的平均空白接近令人震惊的水平时，碎片才会开始变得重要。老实说，在大多数情况下，索引维护基本上是一项非常昂贵的统计更新操作，这意味着处于统计更新之上，这通常不会导致阻塞，也不备份 AG。

最后，如果您想查看辅助节点落后多远并估计它们需要多长时间才能赶上，请尝试此查询，这是Jonathan Kehayias的此代码的变体：

SELECT ar.replica_server_name, 
       adc.database_name, 
       ag.name AS ag_name, 
       drs.is_local, 
       drs.synchronization_state_desc, 
       drs.synchronization_health_desc, 
       drs.last_redone_time, 
       drs.redo_queue_size, 
       drs.redo_rate, 
       (drs.redo_queue_size / drs.redo_rate) / 60.0 AS est_redo_completion_time_min,
       drs.last_commit_lsn, 
       drs.last_commit_time
FROM sys.dm_hadr_database_replica_states AS drs
INNER JOIN sys.availability_databases_cluster AS adc 
       ON drs.group_id = adc.group_id AND 
       drs.group_database_id = adc.group_database_id
INNER JOIN sys.availability_groups AS ag
       ON ag.group_id = drs.group_id
INNER JOIN sys.availability_replicas AS ar 
       ON drs.group_id = ar.group_id AND 
       drs.replica_id = ar.replica_id
ORDER BY 
       ag.name, 
       ar.replica_server_name, 
       adc.database_name;