針對AlwaysOn可用性群組的故障轉移進行疑難解答

總結

本文提供故障排除步驟，幫助您判斷為何您的 Always On 可用性群組在 SQL Server 中失敗。 它會一步步說明如何在 Windows 叢集日誌中辨識健康事件，診斷常見原因如叢集健康事件、租約逾時、健康檢查逾時，以及 SQL Server 健康問題，並針對每一項套用修正方法。

注意

若要將本文所述的手動分析自動化，請參閱 使用 AGDiag 診斷可用性群組健康情況事件。

Always On 健康問題與故障移轉對工作負載的影響

AlwaysOn 會透過不同的機制實作健全的健康情況監視，以確保裝載主要復本、基礎叢集和系統健全狀況之Microsoft SQL Server 實例的健康情況。 當偵測到 Windows 叢集或 Always On 的健康狀況問題時，生產工作負載會暫時中斷。

偵測到健康情況時，通常會發生下列事件序列。 在此疑難排解中，提及的健康情況事件是指下列事件：

  • 可用性群組復本和資料庫會從主要角色轉換到解析角色。

  • 可用性群組資料庫會轉換成離線，且無法再存取。

  • Windows 叢集會將可用性群組叢集資源標示為失敗。

  • Windows 叢集會嘗試讓可用性群組角色重新上線（在原始或自動故障轉移夥伴復本上）。

  • 如果AlwaysOn和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.

可用性群組在重新以主要角色上線之前，處於 Resolving 角色的這段期間，通常只會持續幾秒鐘，甚至不到一秒。

識別和診斷 AlwaysOn 可用性群組健康情況事件或故障轉移

你可能會調查單一的 Always On 健全狀況事件，或者近期出現或持續存在的健全狀況問題趨勢，這些問題會間歇性地中斷生產作業。 以下問題可協助你縮小範圍，並連結生產環境近期可能與這些健康問題相關的變化：

  • Always On 或叢集健康狀態事件趨勢是從何時開始的？
  • 健康事件是否發生在特定某一天？
  • 健康情況事件是否發生在一天中的某個時間？
  • 健康情況事件是否發生在當月的特定日或一周？

如果您偵測到趨勢，請檢查系統上的排程維護（虛擬環境中的主機系統）、ETL 批次，以及其他可能與這些健康情況事件相互關聯的作業。 如果系統是虛擬機，請調查主機系統是否曾在故障發生當時引入任何變更。

考慮忙碌的臨時生產工作負載，這些工作負載可能與健康問題發生時間相關（例如使用者首次登入系統時，或午休回來後）。

注意

這是考慮在一周和一個月內收集效能數據之計劃的好時機。 若要進一步了解系統何時最忙碌，您可以測量 Windows 性能監視器計數器，例如 Processor Information::% Processor Time、 Memory::Available MBytes和 MSSQLServer:SQL Statistics::Batch Requests/sec。

檢視叢集日誌

Windows 叢集日誌是用來識別 Always On 或叢集健康狀態事件類型，以及導致該事件發生之偵測到的健康狀況最完整的日誌。 若要產生並開啟叢集記錄檔，請遵循下列步驟：

使用 Windows PowerShell 在健康情況事件時裝載主要複本的叢集節點上產生 Windows 叢集記錄。 例如，在已提升權限的 PowerShell 視窗中執行下列 Cmdlet，並使用 sql19agn1 作為 SQL Server 型伺服器名稱：

get-clusterlog -Node sql19agn1 -UseLocalTime

顯示 PowerShell 視窗的螢幕快照，其中包含 sql19agn1 做為 SQL Server 名稱。

注意

根據預設，記錄檔會在 %WINDIR%\cluster\reports 中建立。

在群組日誌中找到健康事件

AlwaysOn 會使用數種健康情況監視機制來監視可用性群組健康情況。 除了 Windows 叢集健康情況事件（其中 Windows 叢集偵測到叢集節點之間的健康情況問題），AlwaysOn 還有四種不同類型的健康情況檢查：

  • SQL Server 服務未執行
  • SQL Server 租約的逾時
  • SQL Server 健康情況檢查逾時
  • SQL Server 內部健康狀態問題

您可以藉由搜尋字串 [hadrag] Resource Alive result 0的叢集記錄檔，找出其中任何一個 AlwaysOn 特定健康情況事件。 叢集日誌在偵測到這些事件時會儲存此字串。 例如：

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

您可以使用工具來尋找叢集記錄中的所有健康情況事件，以便產生AlwaysOn健康情況問題的摘要報告。 此報告能幫助您識別時間趨勢，並判斷某項Always On健康狀況是否反覆發作。 下列螢幕快照顯示如何使用文字編輯器（在此案例中為 NotePad++）來尋找包含 [hadrag] Resource Alive result 0 字串的叢集記錄中的所有行：

顯示可找出叢集記錄檔中所有健康狀態事件之工具的螢幕擷取畫面。

找出並修復觸發故障轉移的健康問題

要找出主要副本叢集日誌中的健康問題，請將其與以下章節所述的問題進行比較。 AG 故障轉移的常見原因包括：

  • 叢集健康事件
  • SQL Server 服務已停止運作（Always On 健全狀況事件）
  • 租約暫停（Always On 健康事件）
  • 健康檢查暫停（Always On 健康事件）
  • SQL Server 健康狀態（Always On 健康事件）

叢集健康狀態事件

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 容錯移轉叢集概觀 - Azure VM 上的 SQL Server。

如有必要，請考慮聯絡 Microsoft Windows 高可用性支援，以提出支援事件。

SQL Server 服務已停止運作：Always On 健康狀態事件

AlwaysOn 健康情況監視可以偵測裝載可用性群組主要複本的 SQL Server 服務是否不再執行。

徵兆

以下是可用性群組角色 'ag' 的叢集記錄報告範例，顯示因為 QueryServiceStatusEx 傳回處理序識別碼 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 錯誤記錄檔末尾可能會找到可能發生嚴重例外的線索（包括產生記憶體傾印診斷檔案）。 檢閱線索並採取必要行動。 如果您找到傾印檔案，請考慮聯絡 Microsoft SQL Server 支援團隊，並提供 SQL Server 錯誤記錄和傾印檔案內容，以供進一步調查。

租約暫停：一個永遠在線的健康活動

Always On 使用「租約」機制來監控安裝 SQL Server 的電腦健康狀況。 預設的租約逾時時間是20秒。

徵兆

這是叢集日誌中 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 租約逾時事件

有兩個主要原因可能導致租約逾期：

  • SQL Server 記憶體傾印：當 SQL Server 偵測到某些內部健康狀態事件，例如存取違規、判斷提示失敗或排程器死結時，它會在 SQL Server \LOG 資料夾中產生診斷傾印檔案（.mdmp）。 產生記憶體傾印的程式會暫時暫停 SQL Server 執行。 在此期間，租賃機制可偵測服務回應不足並觸發行動。 如需詳細資訊，請參閱 傾印產生的影響。

  • 系統整體效能問題：租約逾時不一定代表 SQL Server 健康問題。 反而，它可能表示整個系統的健康狀況有問題，而這也會影響以 SQL Server 為基礎的伺服器健康狀況。

    • 系統上的高 CPU 使用量（接近 100%）。
    • 記憶體不足狀況 - 虛擬記憶體不足，和/或其中一個程序正被分頁到磁碟。
    • WSFC 因失去法定節點數而離線。
    • VM 遭到節流，影響效能並導致租用到期。

解決方法

如需詳細的疑難解答步驟，請參閱 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使用率高、記憶體狀況低或磁碟延遲高，請開始在主副本上收集整天的效能監視器資料以調查這些症狀。 透過長期捕捉效能監控資料，您可以更好地識別這些資源的基線與峰值值，並在租約逾時時監控這些資源的變化。 當您收集此數據時，請考慮 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 會使用健康情況檢查機制來監視 SQL Server 的健康情況，以及用戶端應用程式連線的能力。

徵兆

當可用性群組複本轉換成主要角色時，Always On 健康情況監視會建立與 SQL Server 實例的本機 ODBC 連線。 當 Always On 連線並監控時，如果 SQL Server 在你設定的可用性群組健康檢查逾時時間內（預設為 30 秒）內沒有透過 ODBC 連線回應，Always On 會觸發健康檢查逾時事件。 在此情況下，可用性群組會從主要角色轉換至解析角色，並在設定為執行此動作時起始故障轉移。

如需詳細了解健康情況檢查逾時，請參閱 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 錯誤日誌（兩者皆位於 SQL Server \LOG 資料夾中），以及 Windows 系統事件日誌。 利用這些及其他日誌尋找相關事件，幫助你釐清健康檢查逾時的原因。

1. 檢查是否有排程器未讓出控制權的事件

Always On 健康檢查逾時通常是因為 SQL Server 中的「非妥協」事件所引起。 當 SQL Server 偵測到排程器執行緒未讓步時，會回報排程器發生非讓步事件。 如果你在同一排程器上看到其他任務沒有接收 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 系統健康擴展事件日誌，直到懷疑健康檢查逾時的時間點。

  3. 在SQL Server Management Studio（SSMS）中，請前往 File>Open，選擇 合併擴展事件檔案。

  4. 選取新增按鈕。

  5. 在 File Open 對話框中，前往 SQL Server \LOG 目錄中的檔案。

  6. 按住 Control，然後選取名稱以 system_health_xxx.xel 開頭的檔案。

  7. 選取 開啟>確定。

  8. 篩選結果。 在 name 資料行下方的事件上按一下滑鼠右鍵，然後選取 [依此值篩選]。

    顯示如何檢查未讓出控制權的排程器事件的螢幕擷取畫面。

  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 支援團隊，以調查這些未讓出事件。

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 健康狀態事件

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 會觸發健康狀態事件。 將可用性群組設為第四或第五級，可以擴大監控的 SQL Server 健康問題類型。 如需 SQL Server Always On 健康狀態監視器的詳細資訊，請參閱 設定可用性群組的彈性自動故障轉移原則 - SQL Server Always On。

若要識別 AlwaysOn 特定健康情況問題，請遵循下列步驟：

  1. 開啟主要復本上的 SQL Server 叢集診斷擴充事件記錄檔，並查看發生疑似 SQL Server 健康狀態事件時的時間點。

  2. 在 SSMS 中，移至 [>]，然後選取 [合併擴充事件檔案]。

  3. 選取 新增。

  4. 在 File Open 對話框中，前往 SQL Server \LOG 目錄中的檔案。

  5. 按 [控件]，選取名稱相符 <servername>_<instance>_SQLDIAG_xxx.xel的檔案，然後選取 [ 開啟>確定]。

    顯示如何選取名稱符合特定名稱之檔案的螢幕快照。

    你會在 SSMS 中看到一個新的分頁視窗，裡面包含了擴展事件，如下圖所示。

  6. 若要調查 SQL Server 健康狀況問題，請找出 state_desc 值為 error 的 component_health_result。 以下是向 Always On 健康狀態監視回報錯誤的系統元件事件範例：

    回報錯誤的系統元件事件的螢幕快照。

  7. 在下方窗格中，按兩下 data 欄。 此動作會以新的 SSMS 視窗窗格開啟詳細元件資料供審查。 以下是系統元件資料的外觀：

    詳細元件數據的螢幕快照。

    totalDumprequests=186 資料顯示，此 SQL Server 上產生了過多傾印檔案診斷事件。 此條件會讓系統元件報告錯誤狀態。 當 Always On 健康狀態監視接收到這個錯誤狀態時，會觸發可用性群組健康狀態事件。 你也可以根據系統元件資料中提供的資料，檢查是否未偵測到寫入存取違規或孤立的自旋鎖。

解決方法

根據你發現的問題類型，請適當處理。 如 Configure a flexible automatic failover policy for an availability group - SQL Server Always On 一文所述，各種不同的問題都可能導致這種情況。 範例包括：

  • SQL Server 服務已關閉。
  • 租約已逾時。
  • 可用性複本處於失敗狀態。
  • 由孤立的自旋鎖、存取違規，或在短時間內產生過多記憶體傾印所產生的記憶體傾印。
  • SQL Server 內部資源集區中的持續性記憶體不足狀況。
  • 偵測排程器死結。
  • 偵測到無法解決的死結。

如有需要，請聯絡 SQL Server 支援，開啟支援事件，以獲得進一步協助找出這些內部 SQL Server 健康問題的根本原因。

  • Last updated on