針對AlwaysOn可用性群組故障轉移進行疑難解答
注意
若要將本文所述的手動分析自動化,請參閱 使用 AGDiag 診斷可用性群組健康情況事件。
本文提供疑難解答步驟,可協助您判斷可用性群組為何故障轉移。
AlwaysOn 健康情況問題或故障轉移的徵兆和影響
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.
可用性群組在主要角色上線之前處於解析角色的期間,通常只會持續幾秒鐘甚至少於一秒。
識別和診斷 AlwaysOn 可用性群組健康情況事件或故障轉移
1.識別 AlwaysOn 健康情況趨勢
您可以調查單一 Always On 健康情況事件,或可能有間歇性中斷生產之健康情況問題的最新或持續趨勢。 下列問題可協助您縮小並關聯生產環境中最近可能與這些健康問題相關的變更:
- AlwaysOn 或叢集健康情況事件趨勢何時開始?
- 健康情況事件發生在某一天嗎?
- 健康情況事件是否發生在一天中的某個時間?
- 健康情況事件是否發生在當月的特定日或一周?
如果您偵測到趨勢,請檢查系統上的排程維護(虛擬環境中的主機系統)、ETL 批次,以及其他可能與這些健康情況事件相互關聯的作業。 如果系統是虛擬機,請調查主機系統是否有可能在中斷時引入的變更。
請考慮忙碌的臨機操作生產工作負載,這些工作負載可能與健康情況問題的時間相互關聯(例如,當使用者第一次登入系統,或在使用者從午餐返回之後)。
注意
這是考慮在一周和一個月內收集效能數據之計劃的好時機。 若要進一步了解系統何時最忙碌,您可以測量 Windows 性能監視器計數器,例如 Processor Information::% Processor Time
、 Memory::Available MBytes
和 MSSQLServer:SQL Statistics::Batch Requests/sec
。
2.檢閱叢集記錄
Windows 叢集記錄檔是用來識別 AlwaysOn 或叢集健康情況事件種類以及偵測到造成事件之健全狀況狀況的最完整記錄。 若要產生並開啟叢集記錄檔,請遵循下列步驟:
使用 Windows PowerShell 在健康情況事件時裝載主要複本的叢集節點上產生 Windows 叢集記錄。 例如,使用 'sql19agn1' 作為 SQL Server 伺服器名稱,在提升許可權的 PowerShell 視窗中執行下列 Cmdlet:
get-clusterlog -Node sql19agn1 -UseLocalTime
注意
根據預設,記錄檔會在 %WINDIR%\cluster\reports 中建立。
3.在叢集記錄中尋找健康情況事件
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健康情況問題的摘要報告。 這很適合用來識別時間趨勢,並判斷特定類型的 AlwaysOn 健康情況是否為週期性。 下列螢幕快照顯示如何使用文字編輯器(在此案例中為 NotePad++)來尋找包含 [hadrag] Resource Alive result 0
字串的叢集記錄中的所有行:
判斷觸發故障轉移的健全狀況問題種類
若要判斷您在主要複本叢集記錄檔中找到的健全狀況問題種類,請將其與後續幾節所述的問題進行比較。
叢集健康情況事件
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
的叢集記錄檔位置,向後搜尋 、、 和 is broken
等Failed to connect to remote endpoint
unreachable
字串。
解決叢集健康情況事件
請確定叢集健康情況監視適用於主機環境。 如需裝載於 Azure Microsoft SQL Server Always On 可用性群組的詳細資訊,請參閱 Windows Server 故障轉移叢集概觀 - Azure VM 上的 SQL Server。
如有必要,請考慮連絡 Microsoft Windows 高可用性支援,以開啟支援事件。
SQL Server 服務已關閉:Always On 健康情況事件
AlwaysOn 健康情況監視可以偵測裝載可用性群組主要複本的 SQL Server 服務是否不再執行。
SQL Server 服務關機的徵兆
以下是可用性群組角色 'ag' 的叢集記錄報告範例,指出因為傳回進程標識碼0
而QueryServiceStatusEx
失敗:
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 錯誤記錄檔和傾印檔案內容,以進行進一步調查。
租用逾時:AlwaysOn 健康情況事件
AlwaysOn 會使用「租用」機制來監視安裝 SQL Server 之計算機的健全狀況。 默認租用逾時為20秒。
AlwaysOn 租用逾時事件的徵兆
以下是叢集記錄中 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
如需租用逾時的詳細資訊,請參閱 AlwaysOn 可用性群組的租用機制和租用、叢集和健康情況檢查逾時指導方針一節。
診斷和解決AlwaysOn租用逾時事件
有兩個主要問題可以觸發租用逾時:
SQL Server 傾印檔案診斷:當 SQL Server 偵測到某些內部健康情況事件,例如存取違規、判斷提示或排程器死結時,它會在 SQL Server \LOG 資料夾中產生診斷傾印檔案 (.mdmp)。
整個系統的效能問題:租用逾時不一定表示 SQL Server 健全狀況問題。 相反地,它可能會指出整個系統的健全狀況問題,也會影響 SQL Server 伺服器的健康情況。 如需更詳細的疑難解答步驟,請參閱 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 健康情況事件
當可用性群組複本轉換成主要角色時,Always On 健康情況監視會建立與 SQL Server 實例的本機 ODBC 連線。 雖然 AlwaysOn 已連線並監視,但如果 SQL Server 在可用性群組健康狀態檢查逾時設定的期間內未回應 ODBC 連線,則會觸發健康情況檢查逾時事件。 在此情況下,可用性群組會從主要角色轉換至解析角色,並在設定為執行此動作時起始故障轉移。
如需健康情況檢查逾時的詳細資訊,請參閱 AlwaysOn 可用性群組的租用、叢集和健康情況檢查逾時指導方針中的<健康情況檢查逾時作業>一節。
以下是叢集記錄中報告的 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 記錄中您可能會發現且與偵測到和報告之 AlwaysOn 健康情況檢查逾時相關的「階層面包碎」事件。 此處檢閱的記錄包括叢集記錄檔(確認健康情況檢查逾時的位置)、 system_health
擴充事件記錄檔和 SQL Server 錯誤記錄檔(這兩者都位於 SQL Server \LOG 資料夾中),以及 Windows 系統事件記錄檔。 使用這些和其他記錄來尋找可協助您界定健康情況檢查逾時原因的相互關聯事件。
1.檢查是否有非產生排程器事件
Always On 健康情況檢查逾時通常是由 SQL Server 中的「非產生」事件所造成。 當 SQL Server 偵測到線程未在排程器上產生時,它會報告發生非產生排程器事件。 如果您在未收到 CPU 時間的相同排程器上看到其他工作,這是非產生排程器的主要標誌。 此行為可能會導致這些工作延遲執行,以及指派給特定 CPU 時間排程器的「饑餓」工作負載。
若要檢查非產生排程器事件,請遵循下列步驟:
檢查 SQL Server
system_health
擴充事件記錄檔,以判斷在 AlwaysOn 健康情況檢查逾時事件前後是否報告某種類型的非產生排程器事件。 您可能會發現的非產生事件包括下列專案: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
在主要復本上開啟 SQL Server 系統健康情況擴充事件記錄檔,到可疑健康情況檢查逾時的時間。
在 SQL Server Management Studio (SSMS) 中,移至 [檔案開啟],然後選取 [合併擴充事件檔案]。>
選取新增按鈕。
在 [ 開啟 檔案] 對話框中,流覽至 SQL Server \LOG 目錄中的檔案。
按住 Control,然後選取名稱開頭為
system_health_xxx.xel
的檔案。選取 [開啟>確定]。
篩選結果。 以滑鼠右鍵按兩下 [名稱] 資料行底下的事件,然後選取 [依此值篩選]。
定義篩選條件,以排序名稱數據行中的值包含
yield
的數據列,如下列螢幕快照所示。 這會傳回記錄檔中system_health
可能記錄的所有非產生事件。比較時間戳,以查看健康情況檢查逾時時是否有非產生事件。以下是叢集記錄中所報告的健康情況檢查逾時:
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 健康情況:AlwaysOn 健康情況事件
AlwaysOn 會監視不同類型的 SQL Server 健康情況事件。 雖然它裝載可用性群組主要復本,但 SQL Server 會使用不同的元件,持續在 SQL Server 健康情況上執行 sp_server_diagnostics
報告。 偵測到任何健康情況問題時, sp_server_diagnostics
報告該特定元件的錯誤,然後將結果傳回 AlwaysOn 健康情況偵測程式。 回報錯誤時,可用性群組角色會顯示失敗狀態,如果可用性群組已設定為執行此動作,則為可能的故障轉移。
AlwaysOn SQL Server 健康情況事件的徵兆
以下是叢集記錄中所 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
設定為三個。 這會啟動監視部分,但並非所有 SQL Server 健康情況配置檔。 在預設層級,當 SQL Server 產生太多傾印檔案、寫入存取違規或孤立的線程同步鎖定時,Always On 會觸發健康情況事件。 將可用性群組設定為層級 4 或 5,將會擴充受監視的 SQL Server 健全狀況問題類型。 如需 SQL Server 健全狀況 Always On 監視器的詳細資訊,請參閱 設定可用性群組的彈性自動故障轉移原則 - SQL Server Always On。
若要識別 AlwaysOn 特定健康情況問題,請遵循下列步驟:
開啟主要復本上的 SQL Server 叢集診斷擴充事件記錄檔,到發生可疑 SQL Server 健康情況事件的時間。
在 SSMS 中,移至 [>檔案開啟],然後選取 [合併擴充事件檔案]。
選取 [新增]。
在 [ 開啟 檔案] 對話框中,流覽至 SQL Server \LOG 目錄中的檔案。
按 [控件],選取名稱相符
<servername>_<instance>_SQLDIAG_xxx.xel
的檔案,然後選取 [ 開啟>確定]。您會在包含擴充事件的 SSMS 中看到新的索引標籤視窗,如下列螢幕快照所示。
若要調查 SQL Server 健全狀況問題,請找出
component_health_result
其state_desc
值為error
的 。 以下是將錯誤回報回 Always On 健康情況監視的系統元件事件範例:按兩下 下方窗格中的數據 行。 這會在新的SSMS視窗窗格中開啟詳細元件數據以供檢閱。 以下是系統元件資料的外觀:
請注意,'totalDumprequests=186' 數據表示此 SQL Server 上產生太多傾印檔案診斷事件。 這是系統元件回報錯誤狀態的原因。 當AlwaysOn健康情況監視收到此錯誤狀態時,它會觸發可用性群組健康情況事件。 您也可以確認系統元件數據中未偵測到任何寫入存取違規或孤立的線程同步鎖定。
如有必要,請連絡 SQL Server 支援人員以開啟支援事件,以進一步協助找出這些內部 SQL Server 健康情況問題的根本原因。