排查处于还原状态的可用性组数据库问题

本文可帮助你排查处于还原状态的可用性组数据库问题。

什么是还原状态？

当辅助服务器必须撤消已应用的更改才能与主服务器同步时，将发生还原状态。

在正常操作期间，可用性组主副本和次要副本保持连接状态，以便主副本上的更改与次要副本主动同步。

在故障转移期间，此连接状态将中断。 新的主副本联机后，主副本与次要副本（s）之间的连接将重新建立。 在此初始连接状态期间，会协商一个公共恢复点，在该恢复点中，新辅助数据库应启动恢复，以便它与主数据库同步。

如果在故障转移时运行大型事务，则新的辅助数据库日志领先于主副本数据库。 协商的新通用恢复点需要辅助副本从主副本接收页面，以便其处于同步可以恢复的状态。 还原过程也称为“撤消重做”。

还原过程本质上是缓慢的，经常发生，通常很少注意到触发还原状态的小型事务。 当故障转移中断大型事务时，通常会注意到还原状态，导致将许多页面从主副本发送到辅助数据库，以将辅助副本数据库还原为可恢复状态。

可用性组数据库在还原状态的症状和效果

当数据库处于次要副本还原状态时，数据库不会同步，因此不会从主副本接收更改。 主副本上的数据库突然丢失可能会导致数据丢失。

AlwaysOn 仪表板报表在主服务器上未同步

故障转移可用性组后，你可能会发现辅助数据库在故障转移成功时报告为未同步。 Always On 仪表板报告 主要副本上未同步 ，在 辅助副本上还原 。

AlwaysOn 仪表板报表在主服务器上未同步	Always On 仪表板报表还原到辅助数据库

Always On DMV 报告主数据库上未同步

在主数据库上查询以下 AlwaysOn 可用性组（AG）动态管理视图（DMV）时，数据库处于 NOT 同步 状态。

SELECT DISTINCT ar.replica_server_name, drcs.database_name, drs.database_id, drs.synchronization_state_desc, drs.database_state_desc
FROM sys.availability_replicas ar 
JOIN sys.dm_hadr_database_replica_states drs 
ON ar.replica_id=drs.replica_id 
JOIN sys.dm_hadr_database_replica_cluster_states drcs
ON drs.group_database_id=drcs.group_database_id

在辅助数据库上查询 DMV 时，可用性组数据库处于 REVERTING 状态。

只读工作负荷和报告工作负荷无法访问辅助数据库

还原辅助数据库时，无法访问或查询该数据库。 这些只读工作负荷处于脱机状态并中断。 根据数据库处于还原状态的时间，可能需要将这些工作负荷重新路由到另一个次要副本或主副本（如果这些工作负荷至关重要）。

如果具有只读工作负荷（例如路由到次要副本的报告工作负荷），则这些批可能会失败并显示消息 922：

正在恢复 Msg 922、级别 14、状态 1、第 2 行数据库“agdb”。 请等待恢复操作完成。

尝试登录到处于还原状态的辅助副本数据库的应用程序无法连接并引发错误 18456：

2023-01-26 13：01：13.100 登录错误：18456，严重性：14，状态：38。 2023-01-26 13：01：13.100 用户“<UserName> 登录失败。 原因：无法打开显式指定的数据库“agdb”。 [客户端： <本地计算机>]

如果审核失败的登录名，也可以在 SQL Server 错误日志中报告此错误。

估计还原状态的剩余时间

使用以下方法之一估算还原状态的剩余时间：

使用 AlwaysOn_health XEvent 会话

AlwaysOn_health扩展事件日志有一个hadr_trace_message事件，该事件每五分钟报告还原状态进度。

使用 SQL Server Management Studio（SSMS）连接到辅助副本对象资源管理器并钻取到管理、扩展事件和会话。 右键单击 AlwaysOn_health 事件，然后选择“ 观看实时数据”。 应获得一个新的选项卡式窗口，报告还原操作的当前状态。 状态通过 hadr_trace_message 事件每五分钟报告一次，并报告还原操作的完成百分比。

注意

扩展事件 hadr_trace_message 已添加到 SQL Server 2019 及更高版本中的最新累积更新。 必须运行最新的累积更新，才能在扩展事件会话中 AlwaysOn_health 观察此扩展事件。

估算还原完成情况时，次要副本上的 SQL Server 错误日志没有太大帮助。 在下图中，可以在还原状态下从 10：08 观察到 11：03，几乎没有报告。 辅助副本收到来自主副本的所有页面后，现在可以回滚在触发还原状态的原始主副本上运行的事务。 恢复从 11：03 运行到 11：05。 恢复完成后不久，数据库应开始与主副本同步，并在辅助数据库处于还原状态时赶上主数据库所做的所有更改。

使用 性能监视器 监视还原完成时间

使用性能计数器 SQL Server：数据库副本：需要撤消的总日志和 SQL Server：Database Replica：Log Remaining for Undo 监视状态进度，并选择实例的可用性组数据库。 在以下屏幕截图中的示例中， “需要撤消 的日志总数”报告为 56.3 mb， “撤消的 日志剩余量”正在缓慢下降到 0 ，报告正在恢复进度。

除了等待之外，还有哪些其他选项？

Microsoft建议估计还原状态完成的时间。

将次要副本添加到可用性组

如果可用性组中只有两个副本（如果可能），请添加另一个辅助副本，以提供高可用性和冗余，并在其他辅助副本完成还原时主动与主副本同步。

重要

不要故障转移到数据库处于还原状态的副本。 这可能会导致需要从备份还原的不可用数据库。 不要重启辅助副本实例，它不会加速此过程，并且可能会破坏处于还原状态的辅助副本数据库的状态。

如何解决失败的只读工作负荷

由于还原中的辅助副本数据库不可访问，只读工作负荷会失败。 更新读取意向路由表，以将流量路由回主副本或其他辅助副本，直到受影响的辅助副本数据库完成还原过程。

避免还原状态 - 监视大型事务

如果在计划的故障转移期间频繁观察此状态，请实现在故障转移之前检查大型事务的过程。 以下查询报告系统上任何打开事务的事务开始时间和当前时间，并提供事务的输入缓冲区。

SELECT tat.transaction_begin_time, getdate() AS 'current time', es.program_name, es.login_time, es.session_id, tst.open_transaction_count, eib.event_info
FROM sys.dm_tran_active_transactions tat
JOIN sys.dm_tran_session_transactions tst ON tat.transaction_id=tst.transaction_id
JOIN sys.dm_exec_sessions es ON tst.session_id=es.session_id 
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) eib WHERE es.is_user_process = 1
ORDER BY tat.transaction_begin_time ASC