排查Always On可用性组故障转移问题

  • 项目

注意

若要自动执行本文中所述的手动分析，请参阅 使用 AGDiag 诊断可用性组运行状况事件。

本文提供故障排除步骤，帮助你确定可用性组故障转移的原因。

Always On运行状况问题或故障转移的症状和影响

Always On通过不同的机制实现可靠的运行状况监视，以确保托管主副本 (replica) 、基础群集和系统运行状况的 Microsoft SQL Server 实例的运行状况。 确定 Windows 群集或Always On运行状况问题时，生产工作负荷会暂时中断。

检测到运行状况条件时，通常会发生以下事件序列。 在此疑难解答中，运行状况事件在引用以下事件时被提及：

  • 可用性组副本和数据库从主要角色转换为解析角色。

  • 可用性组数据库将转换为脱机，并且不再可访问。

  • Windows 群集将可用性组群集资源标记为失败。

  • Windows 群集尝试在原始或自动故障转移合作伙伴副本 (replica) ) 上恢复可用性组角色联机 (。

  • 如果可用性组角色通过Always On和 Windows 群集运行状况监视检测到其正常运行，则可用性组角色将成功联机。

如果成功，可用性组副本和数据库将转换为主要角色，可用性组数据库将联机并由应用程序访问。

应用程序无法访问可用性组数据库

检测到运行状况后，可用性组副本 (replica) ，数据库将转换为“解析”角色，可用性组数据库将脱机。 副本 (replica) 在原始副本 (replica) 服务器或故障转移伙伴副本 (replica) 服务器) 上以主要角色 (联机后，副本 (replica) 和数据库再次转换为联机。 当副本 (replica) 和数据库正在解析并且处于脱机状态时，尝试访问这些可用性组数据库的任何应用程序都会失败，并生成“错误 983”消息：Unable to access availability database...。 如果将 SQL Server 配置为记录失败的登录尝试，则也会在 Microsoft SQL Server 错误日志中记录此错误：

Logon Error: 983, Severity: 14, State: 1.

Logon Unable to access availability database '<databasename>' because the database replica is not in the PRIMARY or SECONDARY role. Connections to an availability database is permitted only when the database replica is in the PRIMARY or SECONDARY role. Try the operation again later.

可用性组在主要角色中重新联机之前处于“正在解决”角色中的时间段通常仅持续几秒钟甚至不到一秒。

识别和诊断Always On可用性组运行状况事件或故障转移

可以调查单个Always On运行状况事件，或者可能存在间歇性中断生产的最新或持续运行状况问题趋势。 以下问题可帮助你缩小范围并关联生产环境中可能与这些运行状况问题相关的最近更改：

  • Always On或群集运行状况事件趋势何时开始？
  • 运行状况事件是否发生在某一天？
  • 运行状况事件是否发生在一天中的某个时间？
  • 运行状况事件是否发生在当月的某一天或周？

如果检测到某个趋势，检查虚拟环境中的系统 (主机系统上的计划维护，) 、ETL 批处理和其他可能与这些运行状况事件相关的作业。 如果系统是虚拟机，请对主机系统进行调查，了解中断时可能引入的更改。

请考虑繁忙的临时生产工作负载，这些工作负载可能与运行状况问题 (的时间相关，例如，当用户首次登录到系统时，或在用户从午餐) 返回后。

注意

这是考虑计划收集整个周和整个月性能数据的好时机。 为了更好地了解系统何时最繁忙，可以测量 Windows 性能监视器计数器，例如 Processor Information::% Processor Time、 Memory::Available MBytes和 MSSQLServer:SQL Statistics::Batch Requests/sec。

2.查看群集日志

Windows 群集日志是最全面的日志，用于标识Always On或群集运行状况事件的种类，以及导致该事件的检测到的运行状况。 若要生成并打开群集日志，请执行以下步骤：

使用 Windows PowerShell 在运行运行状况事件时，在托管主副本 (replica) 的群集节点上生成 Windows 群集日志。 例如，使用“sql19agn1”作为基于SQL Server的服务器名称，在提升的 PowerShell 窗口中运行以下 cmdlet：

get-clusterlog -Node sql19agn1 -UseLocalTime

显示 PowerShell 窗口的屏幕截图，其中 sql19agn1 作为SQL Server名称。

注意

默认情况下，日志文件在 %WINDIR%\cluster\reports 中创建。

3. 在群集日志中查找运行状况事件

Always On使用多种运行状况监视机制来监视可用性组运行状况。 除了 Windows 群集运行状况事件 (其中 Windows 群集检测到群集节点之间的运行状况问题) 之外，Always On还有四种不同类型的运行状况检查：

  • SQL Server服务未运行
  • SQL Server租约超时
  • SQL Server运行状况检查超时
  • SQL Server内部运行状况问题

可以通过在群集日志中搜索字符串 [hadrag] Resource Alive result 0来查找这些Always On特定运行状况事件中的任何一个。 检测到这些事件中的任何一个时，此字符串将保存在群集日志中。 例如：

00001334.00002ef4::2019/06/24-18:24:36.153 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0.

可以使用工具查找群集日志中的所有运行状况事件，以便生成Always On运行状况问题的摘要报告。 这对于确定按时间顺序排列的趋势并确定特定类型的Always On健康状况是否重复非常有用。 以下屏幕截图显示如何使用文本编辑器 (NotePad++，在本例中，) 查找群集日志中包含字符串 [hadrag] Resource Alive result 0 的所有行：

显示用于在群集日志中查找所有运行状况事件的工具的屏幕截图。

确定触发故障转移的运行状况问题类型

若要确定在主副本 (replica) 的群集日志中找到的运行状况问题类型，请将它们与后续几节中所述的问题进行比较。

群集运行状况事件

Microsoft Windows 群集监视群集中成员服务器的运行状况。 如果检测到运行状况问题，可能会从群集中删除群集成员服务器。 此外，如果已配置为自动故障转移，则群集资源 (（包括已删除群集成员服务器上托管的可用性组角色) ）将移动到可用性组故障转移伙伴副本 (replica) 。

群集运行状况事件的症状

下面是群集日志中的群集运行状况事件示例。 若要找到它，可以搜索 Lost quorum 或 Cluster service has terminated ，因为可用性组角色更改或故障转移期间可能存在。

00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: Lost quorum (1)
00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: goingAway: 0, core.IsServiceShutdown: 0
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925)
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [NETFT] Cluster Service preterminate succeeded.
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925), executing OnStop
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM]: Shutting down, so unloading the cluster database.
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM] Shutting down, so unloading the cluster database (waitForLock: false).
000019cc.000019d0::2022/12/15-14:26:02.654 WARN [RHS] Cluster service has terminated. Cluster.Service.Running.Event got signaled.

标识此事件的另一种方法是搜索 Windows 系统事件日志：

Critical SQL19AGN1.CSSSQL 1135 Microsoft-Windows-FailoverClusterin Node Mgr NT AUTHORITY\SYSTEM Cluster node 'SQL19AGN2' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Critical SQL19AGN1.CSSSQL 1177 Microsoft-Windows-FailoverClusterin Quorum Manager NT AUTHORITY\SYSTEM The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

诊断群集运行状况事件

Windows 事件日志 (事件 1135 和 1177 中的错误) 表明网络连接是导致该事件的原因。 这是检测到群集运行状况问题的最常见原因。 以下示例显示其他群集成员服务器无法与此托管可用性组主副本 (replica) 的服务器通信，并且此问题触发了从群集中删除群集节点：

00000fe4.00001edc::2022/12/14-22:44:36.870 INFO [NODE] Node 1: New join with n3: stage: 'Attempt Initial Connection' status (10060) reason: 'Failed to connect to remote endpoint <endpoint address>'
00000fe4.00001620::2022/12/15-14:26:02.050 INFO [IM] got event: Remote endpoint <endpoint address> unreachable from <endpoint address>
00000fe4.00001620::2022/12/15-14:26:02.050 WARN [NDP] All routes for route (virtual) local <local address> to remote <remote address> are down
00000fe4.0000179c::2022/12/15-14:26:02.053 WARN [NODE] Node 1: Connection to Node 2 is broken. Reason GracefulClose(1226)' because of 'channel to remote endpoint <endpoint address> is closed'

可以在群集日志中搜索节点连接失败的证据。 从群集日志中找到 Lost quorum的位置，向后搜索 、、 和 is broken等Failed to connect to remote endpointunreachable字符串。

解决群集运行状况事件

确保群集运行状况监视适用于主机环境。 有关 Microsoft Azure 中托管SQL Server Always On可用性组的详细信息，请参阅 Windows Server 故障转移群集概述 - 在 Azure VM 上SQL Server。

如有必要，请考虑联系 Microsoft Windows 高可用性支持人员以打开支持事件。

SQL Server服务关闭：Always On运行状况事件

Always On运行状况监视可以检测托管可用性组主副本 (replica) SQL Server服务是否不再运行。

SQL Server服务关闭的症状

下面是可用性组角色“ag”的群集日志报告示例，该示例指示失败，因为 QueryServiceStatusEx 返回了进程 ID 0：

00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] QueryServiceStatusEx returned a process id 0
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] SQL server service is not alive
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] Resource Alive result 0.
00001898.0000185c::2023/02/27-13:27:41.121 WARN [RHS] Resource ag IsAlive has indicated failure.

诊断和解决 SQL 服务关闭事件

检查 Windows 系统事件日志，并SQL Server错误日志中是否有意外SQL Server关闭。

如果SQL Server因系统关闭或管理关闭而关闭，则会在SQL Server错误日志中看到以下条目：

2023-03-10 09：38：46.73 spid9s SQL Server正在终止，以响应服务控制管理器的“停止”请求。 这只是一条信息性消息。 无需用户操作。

Windows 系统事件日志将显示以下错误条目：

信息 3/10/2023 9：41：06 AM 服务控制管理器 7036 无 SQL Server (MSSQLSERVER) 服务已进入停止状态。

如果SQL Server意外关闭，Windows 系统事件日志会显示以下错误条目：

错误 3/10/2023 8：37：46 AM 服务控制管理器 7034 无 SQL Server (MSSQLSERVER) 服务意外终止。 () ，它已执行此操作 1 次。

检查SQL Server错误日志的末尾以获取线索。 如果错误日志突然结束，这意味着它已被强制关闭。 例如，如果使用任务管理器终止了SQL Server，则SQL Server错误报告不会显示有关可能导致进程关闭的任何内部问题的任何信息。

如果SQL Server内部运行状况问题导致SQL Server意外终止，则可能存在致命异常的线索 (包括在 SQL 错误日志末尾) 生成转储文件诊断。 查看线索并采取必要的操作。 如果找到转储文件，请考虑打开联系 Microsoft SQL Server支持部门，并提供SQL Server错误日志和转储文件内容以供进一步调查。

租约超时：Always On运行状况事件

Always On使用“租约”机制监视安装了 SQL Server 的计算机的运行状况。 默认租约超时为 20 秒。

Always On租约超时事件的症状

下面是群集日志中Always On租约超时的示例输出。 可以搜索这些字符串，在群集日志中查找租约超时。

00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Availability Group lease is no longer valid 
00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0. 
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:35:57.0, 98.068572, 509227008.000000, 0.000395, 0.000350 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:7.0, 12.314941, 451817472.000000, 0.000278, 0.000266 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:17.0, 17.270742, 416096256.000000, 0.000376, 0.000292 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:27.0, 38.399895, 416301056.000000, 0.000446, 0.000304 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:37.0, 100.000000, 417517568.000000, 0.001292, 0.000666

有关租约超时的详细信息，请参阅Always On可用性组的租约、群集和运行状况检查超时的机制和准则中的租用机制部分。

诊断并解决Always On租约超时事件

有两个main问题可能会触发租约超时：

  • SQL Server转储文件诊断：当SQL Server检测到某些内部运行状况事件（例如访问冲突、断言或计划程序死锁）时，它会在 SQL Server \LOG 文件夹中生成诊断转储文件 (.mdmp) 。

  • 系统范围的性能问题：租约超时不一定表示SQL Server运行状况问题。 相反，它可能指示系统范围的运行状况问题，也影响基于SQL Server的服务器的运行状况。 有关更详细的故障排除步骤，请参阅 MSSQLSERVER_19407。

1. SQL Server转储文件诊断

SQL Server可能会检测到内部运行状况问题，例如访问冲突、断言或死锁计划程序。 在这种情况下，程序在SQL Server进程的 SQL Server \LOG 文件夹中生成一个小型转储文件 (.mdmp) ，用于诊断。 将微型转储文件写入磁盘时，SQL Server进程会冻结几秒钟。 在此期间，SQL Server进程中的所有线程都处于冻结状态。 这包括由Always On运行状况监视监视的租用线程。 因此，Always On可能会检测到租约超时。

**Dump thread - spid = 0, EC = 0x0000000000000000
***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\LOG\SQLDump0001.txt
* *******************************************************************************
*
* BEGIN STACK DUMP:
*   11/02/14 21:21:10 spid 1920
*
* Deadlocked Schedulers
*
* *******************************************************************************
* -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000002BA
Error: 19407, Severity: 16, State: 1.
The lease between availability group 'ag' and the Windows Server Failover Cluster has expired. A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster. To determine whether the availability group is failing over correctly, check the corresponding availability group resource in the Windows Server Failover Cluster.

若要解决此问题，必须调查转储文件诊断的根本原因。 请考虑联系 Microsoft SQL Server支持部门，提供SQL Server错误日志和转储文件内容，以便进一步调查。

2. CPU 使用率较高或其他系统性能问题

租约超时指示影响整个系统（包括SQL Server）的性能问题。 若要诊断系统问题，Always On运行状况诊断群集日志中报告性能监视器数据，并包括租约超时事件。 性能数据跨越大约 50 秒，导致租约超时事件，报告 CPU 使用率、可用内存和磁盘延迟。

下面是报告的性能数据示例，其中显示了群集日志中的租约超时。 在此示例输出中，可能与租约超时相关的高整体 CPU 利用率。

00000f90.000015c0::2020/08/07-14:16:41.378 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00000f90.000015c0::2020/08/07-14:16:41.382 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:20.0, 83.266073, 31700828160.000000, 0.018094, 0.015752
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:30.0, 93.653224, 31697063936.000000, 0.038590, 0.026897
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:40.0, 94.270691, 31696265216.000000, 0.166000, 0.038962
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:50.0, 90.272016, 31695409152.000000, 0.215141, 0.106084
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:16:1.0, 99.991336, 31695892480.000000, 0.046983, 0.035440

如果性能数据在租约超时时显示 CPU 使用率高、内存不足或磁盘延迟较高，请开始在主副本 (replica) 收集全天性能监视器数据，以调查这些症状。 通过捕获较长时间的性能监视器数据，可以更好地识别这些资源的基线值和峰值，并在发生租约超时时监视这些资源的变化。 收集此数据时，请考虑SQL Server中是否有某些计划或临时工作负载与这些资源问题和运行状况事件的时间相关。

还应捕获报告相同系统资源使用情况的计数器，包括以下内容：

  • Processor Information::% Processor Time
  • Memory::Available MBytes
  • Logical Disk::Avg. Disk sec/Read
  • Logical Disk::Avg. Disk sec/Write
  • Logical Disk::Avg. Disk Read Queue Length
  • Logical Disk::Avg. Disk Write Queue Length
  • MSSQLServer:SQL Statistics::Batch Requests/sec

运行状况检查超时：Always On运行状况事件

当可用性组副本 (replica) 转换为主要角色时，Always On运行状况监视将建立与 SQL Server 实例的本地 ODBC 连接。 在连接和监视Always On时，如果SQL Server在为可用性组的运行状况设置的时间段内未通过 ODBC 连接做出响应检查超时 (默认值为 30 秒) ，则会触发运行状况检查超时事件。 在这种情况下，如果可用性组配置为执行此操作，则可用性组将从主要角色转换为“解析”角色并启动故障转移。

有关运行状况检查超时的详细信息，请参阅Always On可用性组的租约、群集和运行状况检查超时机制和指南中的“运行状况检查超时操作”部分。

下面是群集日志中报告的Always On运行状况检查超时：

0000211c.00002d70::2021/02/24-02:50:01.890 WARN [RES] SQL Server Availability Group: [hadrag] Failed to retrieve data column. Return code -1
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Resource Alive result 0.
0000211c.00002594::2021/02/24-02:50:02.453 WARN [RHS] Resource AG IsAlive has indicated failure.
00001278.00002ed8::2021/02/24-02:50:02.453 INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'AG', gen(0) result 1/0.

诊断并解决Always On运行状况检查超时事件

以下部分可帮助你查看SQL Server日志，了解你可能找到的“面包屑”事件，这些事件与检测到和报告的Always On运行状况检查超时相关。 此处查看的日志包括) 确认运行状况检查超时的群集日志 (、system_health (SQL Server \LOG 文件夹) 中找到的扩展事件日志和SQL Server错误日志，以及 Windows 系统事件日志。 使用这些日志和其他日志查找有助于确定运行状况检查超时原因的关联事件。

1.检查无收益计划程序事件

Always On运行状况检查超时通常是由SQL Server中的“未产生”事件引起的。 当SQL Server检测到线程未在计划程序上生成时，它将报告发生了无产计划程序事件。 如果在同一计划程序上看到没有收到 CPU 时间的其他任务，则这是无收益计划程序的主要标志。 此行为可能导致这些任务执行延迟，并导致分配给特定 CPU 时间计划器的工作负荷“饥饿”。

若要检查无收益计划程序事件，请执行以下步骤：

  1. 检查SQL Serversystem_health扩展事件日志，以确定在发生Always On运行状况检查超时事件时，是否报告了某种非生成计划程序事件。 你可能会发现的非生成事件包括：

    • scheduler_monitor_non_yielding_ring_buffer_recorded
    • scheduler_monitor_non_yielding_iocp_ring_buffer_recorded
    • scheduler_monitor_stalled_dispatcher_ring_buffer_recorded
    • scheduler_monitor_non_yielding_rm_ring_buffer_recorded

  2. 打开主副本 (replica) 上的SQL Server系统运行状况扩展事件日志，以显示可疑运行状况检查超时的时间。

  3. 在“SQL Server Management Studio (SSMS) ”中，转到“文件>打开”，然后选择“合并扩展事件文件”。

  4. 选择“添加”按钮。

  5. 在“文件打开”对话框中，导航到 SQL Server \LOG 目录中的文件。

  6. 长按 Control，然后选择名称以 system_health_xxx.xel开头的文件。

  7. 选择“ 打开>确定”。

  8. 筛选结果。 右键单击 名称 列下面的事件，然后选择“ 按此值筛选”。

    显示如何检查非生成计划程序事件的屏幕截图。

  9. 定义筛选器以对 名称 列中的值包含 yield的行进行排序，如以下屏幕截图所示。 这将返回日志中 system_health 可能已记录的各种非生成事件。

    显示如何对名称包含收益的行进行排序的屏幕截图。

  10. 比较时间戳，以查看运行状况检查超时时是否存在非生成事件。下面是群集日志中报告的运行状况检查超时：

    0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1: [hadrag] Resource Alive result 0.

    可以看到，在运行状况检查超时时发生了非生成事件。

    显示运行状况检查超时期间发生的非生成事件的屏幕截图。

如果检测到非生成事件，检查非生成事件的原因。 请考虑联系SQL Server支持团队来调查无结果事件。

2.检查SQL Server错误日志

查看SQL Server错误日志，了解在运行状况检查超时时关联事件。这些事件可能会提供“面包屑”，建议采取进一步措施确定运行状况检查超时的根本原因。

例如，以下日志条目显示群集日志中发生了运行状况检查超时：

0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Resource Alive result 0.

在SQL Server错误日志中，在运行状况检查超时数秒内，SQL Server报告检测到严重的 I/O 延迟：

2021-02-23 20:49:54.64 spid12s SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\agdb_log.ldf] in database id 12. The OS file handle is 0x0000000000001594. The offset of the latest long I/O is: 0x000030435b0000. The duration of the long I/O is: 26728 ms.

查看系统事件日志，了解可能与运行状况检查超时事件相关的系统线索。 查看 Windows 系统事件日志时，你可能会发现同一运行状况检查超时同时报告的 I/O 问题：

02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"Reset to device, \Device\<device ID>, was issued."
02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"The IO operation at logical block address <block address> for Disk 6 (PDO name: \Device\<device ID>) was retried."

SQL Server运行状况：Always On运行状况事件

Always On监视不同类型的SQL Server运行状况事件。 当它承载可用性组主副本 (replica) 时，SQL Server使用不同的组件持续运行sp_server_diagnostics报告SQL Server运行状况。 检测到任何运行状况问题时，sp_server_diagnostics报告该特定组件的错误，然后将结果发送回Always On运行状况检测过程。 报告错误时，如果可用性组配置为执行此操作，可用性组角色会显示失败状态和可能的故障转移。

Always On SQL Server运行状况事件的症状

下面是群集日志中报告的sp_server_diagnosticsSQL Server运行状况问题的示例。 SQL Server报告系统组件中的“错误”状态以Always On运行状况监视，并且“contoso-ag”可用性组已转换为失败状态。

注意

SQL Server运行状况问题会生成与运行状况检查超时类似的报告。这两个运行状况事件都报告 Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel。 SQL Server运行状况事件的区别在于，它报告SQL Server组件已从“警告”更改为“错误”。

INFO [RES] SQL Server Availability Group: [hadrag] SQL Server component 'system' health state has been changed from 'warning' to 'error' at 2019-06-20 15:05:52.330
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Resource Alive result 0.
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
WARN [RHS] Resource contoso-ag IsAlive has indicated failure.
INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'contoso-ag', gen(0) result 1/0.

诊断和解决SQL Server运行状况事件

SQL Server运行状况报告的运行状况问题类型应指示根本原因分析的方向。

默认情况下，部署可用性组时， FAILURE_CONDITION_LEVEL 设置为 3。 这会激活对某些运行状况配置文件的监视，但并非所有SQL Server运行状况配置文件。 在默认级别，当SQL Server产生过多的转储文件、写入访问冲突或孤立的旋转锁时，Always On会触发运行状况事件。 将可用性组设置为最高级别 4 或 5 将扩展监视的SQL Server运行状况问题的类型。 有关SQL Server运行状况Always On监视器的详细信息，请参阅为可用性组配置灵活的自动故障转移策略 - SQL Server Always On。

若要确定Always On特定的运行状况问题，请执行以下步骤：

  1. 打开主副本 (replica) 上SQL Server群集诊断扩展事件日志，以显示可疑SQL Server运行状况事件发生的时间。

  2. 在 SSMS 中，转到 “文件>打开”，然后选择“ 合并扩展事件文件”。

  3. 选择“添加”。

  4. 在“文件打开”对话框中，导航到 SQL Server \LOG 目录中的文件。

  5. 按 Control，选择名称匹配 <servername>_<instance>_SQLDIAG_xxx.xel的文件，然后选择“ 打开>确定”。

    显示如何选择名称与特定名称匹配的文件的屏幕截图。

    你将在 SSMS 中看到一个新的选项卡式窗口，其中包含扩展事件，如以下屏幕截图所示。

  6. 若要调查SQL Server运行状况问题，请找到component_health_result其state_desc值为 的 error。 下面是将错误报告回Always On运行状况监视的系统组件事件示例：

    报告错误的系统组件事件的屏幕截图。

  7. 双击下窗格中 的数据 列。 这会在新的 SSMS 窗口窗格中打开详细的组件数据以供查看。 系统组件数据如下所示：

    详细组件数据的屏幕截图。

    请注意，“totalDumprequests=186”数据指示在此SQL Server上生成了过多的转储文件诊断事件。 这是系统组件报告错误状态的原因。 当Always On运行状况监视收到此错误状态时，会触发可用性组运行状况事件。 还可以验证系统组件数据中提供的数据是否未检测到写入访问冲突或孤立的旋转锁。

    如有必要，请联系SQL Server支持部门，以建立支持事件，以进一步帮助找到这些内部SQL Server健康问题的根本原因。