排查 AlwaysOn 可用性组的故障转移问题

总结

本文提供故障排除步骤，帮助你确定 SQL Server 中的 Always On 可用性组为何发生故障转移。 它逐步讲解如何在Windows群集日志中识别运行状况事件、诊断群集运行状况事件、租用超时、运行状况检查超时和SQL Server运行状况问题等常见原因，并为每个事件应用修补程序。

备注

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

Always On 运行状况问题和故障转移如何影响工作负荷

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

当检测到健康状况异常时，通常会依次发生以下事件。 在此疑难解答中，提到的运行状况事件是指以下事件：

  • 可用性组副本和数据库从主角色过渡到解析角色。

  • 可用性组数据库过渡到脱机状态，不再可访问。

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

  • Windows 群集尝试使可用性组角色重新联机（在原始或自动故障转移伙伴副本上）。

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

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

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

当系统检测到运行状况问题时，可用性组副本和数据库会转换为“正在解析”角色，并且可用性组数据库会转为脱机状态。 在副本于原始副本服务器或故障转移伙伴副本服务器上以主角色联机后，该副本和数据库都将恢复为联机状态。 虽然副本和数据库正在解析并且处于脱机状态，但尝试访问这些可用性组数据库的任何应用程序都失败并生成“错误 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.

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

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

你可能需要调查单个“Always On”运行状况事件，或者最近出现或持续存在的运行状况问题可能会间歇性地中断生产。 以下问题可帮助你缩小排查范围，并将生产环境中最近的更改与这些运行状况问题关联起来：

  • AlwaysOn 或群集运行状况事件趋势何时开始？
  • 健康事件是否发生在某一天？
  • 健康事件是否发生在一天中的某个特定时间？
  • 运行状况事件是否在每月的某一天或某一周发生？

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

考虑那些繁忙的临时性生产工作负载，它们可能与运行状况问题出现的时间相关（例如，在用户首次登录系统时，或在用户午休返回后）。

备注

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

查看群集日志

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

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

get-clusterlog -Node sql19agn1 -UseLocalTime

显示将 sql19agn1 用作 SQL Server 名称的 PowerShell 窗口的屏幕截图。

备注

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

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

AlwaysOn 使用多个运行状况监视机制来监视可用性组运行状况。 除了 Windows 群集运行状况事件（其中 Windows 群集检测到群集节点中的运行状况问题），AlwaysOn 还具有四种不同类型的运行状况检查：

  • 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.

可以使用工具查找群集日志中的所有运行状况事件，以便生成 AlwaysOn 运行状况问题的摘要报告。 此报告可帮助你识别时间顺序趋势，并确定特定的 AlwaysOn 运行状况状况是否定期出现。 以下屏幕截图显示了如何使用文本编辑器（在本例中为 NotePad++）查找包含字符串的群集日志 [hadrag] Resource Alive result 0 中的所有行：

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

识别并修复触发故障转移的运行状况异常

若要识别主副本群集日志中的运行状况问题，请将这些问题与以下各节中描述的问题进行比较。 AG 故障转移的常见原因包括：

  • 群集运行状况事件
  • SQL Server 服务已停止（Always On 运行状况事件）
  • 租约超时（AlwaysOn 运行状况事件）
  • 运行状况检查超时（AlwaysOn 运行状况事件）
  • SQL Server 运行状况（AlwaysOn 运行状况事件）

群集运行状况事件

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

现象

下面是群集日志中群集运行状况事件的示例。 若要找到它，请搜索 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）中的错误表明网络连接是事件发生的原因。 这种情况是导致检测到群集健康问题的最常见原因。 以下示例显示其他群集成员服务器无法与承载可用性组主副本的此服务器通信，并且此问题触发了从群集中删除群集节点：

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的群集日志中的位置，向后搜索字符串，例如 Failed to connect to remote endpoint， unreachable和 is broken。

解决方案

确保群集运行状况监视适用于主机环境。 有关托管在 Microsoft Azure 中的 SQL Server Always On 可用性组的详细信息，请参阅 Windows Server Failover Cluster overview - SQL Server on Azure VMs。

如有必要，可考虑联系 Microsoft Windows 高可用性支持团队来提交支持事件。

SQL Server 服务已关闭：AlwaysOn 运行状况事件

AlwaysOn 运行状况监视可以检测托管可用性组主副本的 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 is terminating in response to a 'stop' request from Service Control Manager. This is an informational message only. No user action is required.

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

Information 3/10/2023 9:41:06 AM Service Control Manager 7036 None The SQL Server (MSSQLSERVER) service entered the stopped state.

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

Error 3/10/2023 8:37:46 AM Service Control Manager 7034 None The SQL Server (MSSQLSERVER) service terminated unexpectedly. It has done this 1 time(s).

检查 SQL Server 错误日志的末尾是否有线索。 如果错误日志突然结束，则此条件表示发生了强制关闭。 例如，如果使用任务管理器终止了SQL Server，则SQL Server错误报告不会显示任何可能导致进程关闭的内部问题的任何信息。

解决方案

确保授权的数据库和系统管理员有权访问系统，以最大程度地减少SQL Server服务意外终止。 检查事件日志后，调查服务为何必须意外终止。

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

租约超时：Always On 健康事件

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

现象

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

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 可用性组中租约、群集和运行状况检查超时的工作原理和指南中的“租约机制”部分。

诊断并修复 AlwaysOn 租约超时事件

两个主要问题可能会触发租约超时：

  • SQL Server 内存转储：当 SQL Server 检测到某些内部运行状况事件（例如访问冲突、断言或计划程序死锁）时，它会在 SQL Server \LOG 文件夹中生成诊断转储文件（.mdmp）。 生成内存转储的过程会使 SQL Server 短暂暂停执行。 在此期间，租约机制可以检测到服务无响应并触发相应操作。 有关更多信息，请参阅转储生成的影响。

  • 系统范围的性能问题：租约超时不一定指示SQL Server运行状况问题。 相反，它可以指示系统范围的运行状况问题，这也会影响基于 SQL Server 的服务器运行状况。

    • 系统上 CPU 使用率高（接近 100%）。
    • 内存不足情况 - 虚拟内存不足和/或某个进程正在被换出到磁盘。
    • WSFC 由于失去仲裁而脱机。
    • VM 节流会影响性能并导致租约到期。

解决方案

有关详细故障排除步骤，请参阅 MSSQLSERVER_19407。 下面是两个最常见的问题：

1. SQL服务器转储文件诊断

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）的性能问题。 若要诊断系统问题，AlwaysOn 运行状况诊断报告群集日志中的性能监视器数据，并包括租约超时事件。 性能数据涵盖租约超时事件发生前约 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 使用率高、内存不足或磁盘延迟较高，则开始在主副本上收集全天的性能监视器数据，以排查这些症状。 通过在较长时间内捕获性能监视器数据，可以更好地识别这些资源的基线和峰值，并在发生租约超时时监视这些资源的更改。 收集此数据时，请考虑 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

运行状况检查超时：AlwaysOn 运行状况事件

AlwaysOn 使用运行状况检查机制来监视 SQL Server 的运行状况，以及客户端应用程序连接的能力。

现象

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

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

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

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.

诊断并修复 AlwaysOn 运行状况检查超时事件

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

1. 检查是否存在非让出调度程序事件

AlwaysOn 运行状况检查超时通常是由SQL Server中的“非生成”事件引起的。 当 SQL Server 检测到某个线程未在调度程序上让出执行权时，它会报告发生了非让出调度程序事件。 如果你看到同一调度程序上的其他任务得不到 CPU 时间，这种情况就是调度程序不让出 CPU 的主要迹象。 此行为可能会导致这些任务延迟执行，并使分配给特定调度程序的工作负载无法获得足够的 CPU 时间。

若要检查非让出调度程序事件，请执行以下步骤：

  1. 检查 SQL Server system_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. 打开主副本上的 SQL Server“system health”扩展事件日志，并定位到疑似运行状况检查超时的时间点。

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

  4. 选择“添加”按钮。

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

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

  7. 选择打开>和确定。

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

    显示如何检查未让出执行权的调度程序事件的屏幕截图。

  9. 定义筛选器以对名称列中的值包含yield的行进行排序，如以下屏幕截图所示。 此筛选器会筛选出可能记录在 system_health 日志中的各种非收益事件。

    展示如何对名称包含 yield 的行进行排序的屏幕截图。

  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 支持团队，以排查不让出 CPU 的事件。

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 运行状况：AlwaysOn 运行状况事件

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

现象

下面是群集日志中由 sp_server_diagnostics 报告的 SQL Server 运行状况问题示例。 SQL Server 将系统组件中的“错误”状态报告给 AlwaysOn 运行状况监视，并且“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。

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

  1. 打开主副本上的 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. 在下方窗格中双击 data 列。 此操作将在新的 SSMS 窗口窗格中打开详细组件数据以供查看。 下面是系统组件数据的外观：

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

    totalDumprequests=186数据表明，此 SQL Server 上生成了过多的转储文件诊断事件。 此条件导致系统组件报告错误状态。 当 AlwaysOn 运行状况监视收到此错误状态时，它会触发可用性组运行状况事件。 您还可以根据系统组件数据中提供的数据，检查是否未检测到写访问违规或孤立的自旋锁。

解决方案

根据发现的问题类型，相应地解决该问题。 正如为可用性组配置灵活的自动故障转移策略 - SQL Server Always On一文中所述，不同问题都可能导致这种情况。 示例包括：

  • SQL Server 服务停止。
  • 租约超时。
  • 可用性副本处于故障状态。
  • 由孤立自旋锁、访问冲突或短时间内生成过多内存转储导致的内存转储。
  • SQL Server 内部资源池中的持久内存不足条件。
  • 检测调度器死锁。
  • 检测到无法解决的死锁。

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

  • Last updated on