故障转移后，可用性组数据库处于“正在恢复”状态的时间过长

Question

架构： \n我在多子网故障转移群集上运行 2 节点同步提交 AlwaysOn 配置。主节点位于欧洲，辅助节点位于美国。我的可用性组中只有一个数据库，即 SCOM 的 OperationsManager db。

\n\n

\n\n

问题： \n当我启动故障转移时，数据库在几秒钟内成功从主节点故障转移到辅助节点。然而，新的辅助（旧的主）数据库进入恢复/恢复阶段并在那里停留大约 30 分钟。我在故障恢复到原始主数据库时也经历了同样的事情，所以这是一个双向发生的问题。

\n\n

调查结果： \n我在互联网上搜索了此问题并阅读了文档来调查该问题。当从主数据库到辅助数据库的角色更改完成后，新的辅助数据库将经历 3 个阶段：

\n\n

同步状态： \xe2\x80\x9c 未同步\xe2\x80\x9d ；数据库状态：在线

\n\n

同步状态： \xe2\x80\x9c 未同步\xe2\x80\x9d ；数据库状态：正在恢复

\n\n

同步状态： \xe2\x80\x9cREVERTING\xe2\x80\x9d ；数据库状态：正在恢复

\n\n

就我而言，所有时间都花在最后一步上。我还通过查看性能计数器“ SQLServer：数据库副本日志剩余用于撤消”来监视撤消过程

\n\n

我在故障转移测试之前检查了主站点，以发现任何长时间运行的事务或打开的事务，但找不到。故障转移后，“用于撤消的剩余日志”约为 30MB，辅助数据库需要 30 分钟才能返回“已同步”状态。考虑到我们在同步提交模式下运行并且主数据库上的工作负载很小，恕我直言，重做阶段不应花费 30 分钟。

\n\n

SQL Server 错误日志：我发现了这个奇怪的消息。

\n\n

于 2019 年 2 月 22 日下午 2:55 在 LSN (2558:107841:1) 的数据库“OperationsManager”中启动的事务“RECEIVE MSG”（ID 0x000000004d52c65a 0001:01c4e415）的远程强化失败。
于 2019 年 2 月 22 日下午 2:59 在 LSN (2558:107843:46) 的数据库“OperationsManager”中启动的事务“GhostCleanupTask”（ID 0x000000004d6d15aa 0001:01c4eaa0）的远程强化失败。

\n\n

故障转移开始:\n

\n\n

故障转移结束:\n

\n\n

总而言之

\n\n

您以前见过这个问题吗？您有什么建议吗？

\n

Answer 1

每当数据库恢复运行时间较长时，无论是正常恢复还是 AG 故障转移，需要检查的一件事是 VLF 计数。拥有大量 VLF（数千或数万）或异常大小的 VLF（一到两个极大的 VLF）将导致此过程变得缓慢如爬行。

\n\n

在有问题的数据库上运行以下命令：

\n\n

USE YourDatabaseName;\nGO\n\nDBCC LOGINFO;\n

注意：如果您使用的是 SQL Server 2016 SP2 或更高版本，则可以使用此动态管理功能而不是 DBCC 命令：sys.dm_db_log_info

\n\n

返回的行数就是您拥有的 VLF 数。如果该数字非常大，或者该FileSize列显示 VLF 中的极端异常值，那么您可以通过（在较高级别上）解决缓慢恢复问题：

\n\n

\n\n

修复 VLF 大小问题的详细信息已在其他地方广泛介绍，这里是一个示例：A Busy/Accidental DBA\xe2\x80\x99s Guide toManaging VLFs

\n