Problembehandlung beim Failover Always On Verfügbarkeitsgruppen

Hinweis

Informationen zum Automatisieren der in diesem Artikel beschriebenen manuellen Analyse finden Sie unter Verwenden von AGDiag zum Diagnostizieren von Integritätsereignissen für Verfügbarkeitsgruppen.

Dieser Artikel enthält Schritte zur Problembehandlung, mit denen Sie ermitteln können, warum für Ihre Verfügbarkeitsgruppe ein Failover ausgeführt wurde.

Symptome und Auswirkungen von Always On Integritätsproblem oder Failover

Always On implementiert eine robuste Integritätsüberwachung über verschiedene Mechanismen, um die Integrität der Microsoft-SQL Server instance sicherzustellen, die das primäre Replikat, den zugrunde liegenden Cluster und die Systemintegrität hostet. Die Produktionsworkload wird vorübergehend unterbrochen, wenn ein Windows-Cluster oder Always On Integritätsproblem erkannt wird.

Wenn eine Integritätsbedingung erkannt wird, tritt in der Regel die folgende Abfolge von Ereignissen auf. In dieser Problembehandlung werden Integritätsereignisse in Bezug auf die folgenden Ereignisse erwähnt:

• Verfügbarkeitsgruppenreplikate und Datenbanken wechseln von der primären Rolle zur Auflösenden Rolle.

• Verfügbarkeitsgruppendatenbanken wechseln in den Offlinemodus und sind nicht mehr zugänglich.

• Windows-Cluster kennzeichnet die gruppierte Verfügbarkeitsgruppenressource als fehlerhaft.

• Windows-Cluster versucht, die Verfügbarkeitsgruppenrolle wieder online zu schalten (auf dem ursprünglichen oder automatischen Failoverpartnerreplikat).

• Die Verfügbarkeitsgruppenrolle wird erfolgreich online geschaltet, wenn sie von Always On und der Integritätsüberwachung des Windows-Clusters als fehlerfrei erkannt wird.

Bei erfolgreicher Ausführung wechseln die Verfügbarkeitsgruppenreplikate und -datenbanken in die primäre Rolle, und die Verfügbarkeitsgruppendatenbanken werden online geschaltet und sind für Ihre Anwendung zugänglich.

Anwendungen können nicht auf die Verfügbarkeitsgruppendatenbanken zugreifen.

Wenn eine Integritätsbedingung erkannt wird, wechseln das Verfügbarkeitsgruppenreplikat und die Datenbanken in die Rolle Auflösen, und die Verfügbarkeitsgruppendatenbanken werden offline geschaltet. Nachdem das Replikat in der primären Rolle (auf dem ursprünglichen Replikatserver oder dem Replikatserver des Failoverpartners) online geschaltet wurde, wechseln das Replikat und die Datenbanken wieder in den Onlinemodus. Während das Replikat und die Datenbanken aufgelöst werden und offline sind, schlagen alle Anwendungen, die versuchen, auf diese Verfügbarkeitsgruppendatenbanken zuzugreifen, fehl und generieren die Meldung "Fehler 983": Unable to access availability database.... Dieser Fehler wird auch im Fehlerprotokoll von Microsoft SQL Server aufgezeichnet, wenn SQL Server so konfiguriert ist, dass fehlgeschlagene Anmeldeversuche aufgezeichnet werden:

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.

Der Zeitraum, in dem sich die Verfügbarkeitsgruppe in der Rolle Auflösen befindet, bevor sie in der primären Rolle wieder online geschaltet wird, dauert in der Regel nur wenige Sekunden oder sogar weniger als eine Sekunde.

Identifizieren und Diagnostizieren von Integritätsereignissen Always On Verfügbarkeitsgruppen oder failover

1. Identifizieren Always On Gesundheitstrends

Sie können ein einzelnes Always On Integritätsereignis untersuchen, oder es gibt einen aktuellen oder fortlaufenden Trend von Integritätsproblemen, die die Produktion zeitweilig unterbrechen. Die folgenden Fragen können Ihnen helfen, aktuelle Änderungen in Ihrer Produktionsumgebung einzugrenzen und zu korrelieren, die möglicherweise mit diesen Integritätsproblemen zusammenhängen:

• Wann hat der Trend zu Always On- oder Clusterintegritätsereignissen begonnen?
• Treten die Integritätsereignisse an einem bestimmten Tag auf?
• Treten die Integritätsereignisse zu einer bestimmten Tageszeit auf?
• Treten die Integritätsereignisse an einem bestimmten Tag oder einer bestimmten Woche des Monats auf?

Wenn Sie einen Trend erkennen, überprüfen Sie die geplante Wartung des Systems (das Hostsystem in einer virtuellen Umgebung), ETL-Batches und andere Aufträge, die möglicherweise mit diesen Integritätsereignissen korrelieren. Wenn es sich bei dem System um einen virtuellen Computer handelt, untersuchen Sie das Hostsystem auf Änderungen, die möglicherweise zum Zeitpunkt der Ausfälle eingeführt wurden.

Berücksichtigen Sie ausgelastete Ad-hoc-Produktionsworkloads, die mit dem Zeitpunkt der Integritätsprobleme korrelieren können (z. B. wenn sich Benutzer zum ersten Mal am System anmelden oder nachdem Benutzer vom Mittagessen zurückkehren).

Hinweis

Dies ist ein guter Zeitpunkt, um einen Plan zum Sammeln von Leistungsdaten während der Woche und des Monats in Betracht zu ziehen. Um besser zu verstehen, wann das System am stärksten ausgelastet ist, können Sie Windows-Leistungsindikatoren wie Processor Information::% Processor Time, Memory::Available MBytesund MSSQLServer:SQL Statistics::Batch Requests/secmessen.

2. Überprüfen des Clusterprotokolls

Das Windows-Clusterprotokoll ist das umfassendste Protokoll, das verwendet werden kann, um die Art des Always On- oder Clusterintegritätsereignisses sowie den erkannten Integritätszustand zu identifizieren, der das Ereignis verursacht hat. Führen Sie die folgenden Schritte aus, um das Clusterprotokoll zu generieren und zu öffnen:

Verwenden Sie Windows PowerShell, um das Windows-Clusterprotokoll auf dem Clusterknoten zu generieren, der das primäre Replikat zum Zeitpunkt des Integritätsereignisses hostet. Führen Sie beispielsweise das folgende Cmdlet in einem PowerShell-Fenster mit erhöhten Rechten aus, indem Sie "sql19agn1" als SQL Server-basierten Servernamen verwenden:

get-clusterlog -Node sql19agn1 -UseLocalTime     

Hinweis

Standardmäßig wird die Protokolldatei in %WINDIR%\cluster\reports erstellt.

3. Suchen des Integritätsereignisses im Clusterprotokoll

Always On verwendet mehrere Integritätsüberwachungsmechanismen, um die Integrität von Verfügbarkeitsgruppen zu überwachen. Zusätzlich zu einem Windows-Clusterintegritätsereignis (bei dem der Windows-Cluster ein Integritätsproblem zwischen den Clusterknoten erkennt), verfügt Always On über vier verschiedene Arten von Integritätsprüfungen:

• Der SQL Server Dienst wird nicht ausgeführt.
• Timeout für SQL Server Lease
• Timeout bei SQL Server Integritätsprüfung
• Ein SQL Server internes Integritätsproblem

Sie können jedes dieser Always On bestimmten Integritätsereignissen finden, [hadrag] Resource Alive result 0indem Sie das Clusterprotokoll nach der Zeichenfolge durchsuchen. Diese Zeichenfolge wird im Clusterprotokoll gespeichert, wenn eines dieser Ereignisse erkannt wird. Zum Beispiel:

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

Sie können ein Tool verwenden, um alle Integritätsereignisse im Clusterprotokoll zu finden, sodass Sie einen zusammenfassenden Bericht zu Always On Integritätsproblemen generieren können. Dies kann nützlich sein, um chronologische Trends zu identifizieren und zu bestimmen, ob eine bestimmte Art von Always On Gesundheitszustand wiederholt wird. Der folgende Screenshot zeigt, wie Sie einen Text-Editor (in diesem Fall NotePad++) verwenden, um alle Zeilen im Clusterprotokoll zu finden, die die [hadrag] Resource Alive result 0 Zeichenfolge enthalten:

Ermitteln der Art des Integritätsproblems, das das Failover ausgelöst hat

Um die Art von Integritätsproblemen zu ermitteln, die Sie im Clusterprotokoll des primären Replikats finden, vergleichen Sie sie mit den In den nächsten Abschnitten beschriebenen Problemen.

Clusterintegritätsereignis

Microsoft Windows-Cluster überwacht die Integrität der Mitgliedsserver im Cluster. Wenn ein Integritätsproblem erkannt wird, wird möglicherweise ein Clustermitgliedsserver aus dem Cluster entfernt. Außerdem werden die Clusterressourcen (einschließlich der Verfügbarkeitsgruppenrolle, die auf dem entfernten Clustermitgliedsserver gehostet wird) in das Failoverpartnerreplikat der Verfügbarkeitsgruppe verschoben, wenn es für das automatische Failover konfiguriert ist.

Symptome von Clusterintegritätsereignissen

Hier sehen Sie ein Beispiel für ein Clusterintegritätsereignis im Clusterprotokoll. Um sie zu finden, können Sie nach oder Cluster service has terminated suchenLost quorum, da entweder während der Änderung der Verfügbarkeitsgruppenrolle oder des Failovers vorhanden ist.

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.

Eine weitere Möglichkeit, dieses Ereignis zu identifizieren, besteht darin, das Windows-Systemereignisprotokoll zu durchsuchen:

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.

Diagnostizieren eines Clusterintegritätsereignisses

Die Fehler im Windows-Ereignisprotokoll (Ereignisse 1135 und 1177) deuten darauf hin, dass die Netzwerkkonnektivität eine Ursache für das Ereignis ist. Dies ist der häufigste Grund dafür, dass ein Clusterintegritätsproblem erkannt wird. Das folgende Beispiel zeigt, dass andere Clustermitgliedsserver nicht mit diesem Server kommunizieren konnten, der das primäre Replikat der Verfügbarkeitsgruppe hostet, und dass dieses Problem die Entfernung des Clusterknotens aus dem Cluster ausgelöst hat:

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'

Sie können das Clusterprotokoll nach Hinweisen auf einen Verbindungsfehler mit dem Knoten durchsuchen. Suchen Sie an dem Speicherort im Clusterprotokoll, an dem Sie gefunden haben Lost quorum, rückwärts nach Zeichenfolgen wie Failed to connect to remote endpoint, unreachableund is broken.

Auflösen eines Clusterintegritätsereignisses

Stellen Sie sicher, dass die Überwachung der Clusterintegrität für die Hostumgebung geeignet ist. Weitere Informationen zu SQL Server Always On Verfügbarkeitsgruppen, die in Microsoft Azure gehostet werden, finden Sie unter Übersicht über Windows Server-Failovercluster – SQL Server auf Azure-VMs.

Wenden Sie sich ggf. an den Microsoft Windows-Hochverfügbarkeitssupport, um einen Supportvorfall zu erstellen.

SQL Server Dienst ist ausgefallen: Ein Always On-Integritätsereignis

Always On Integritätsüberwachung kann erkennen, ob der SQL Server Dienst, der das primäre Replikat der Verfügbarkeitsgruppe hostet, nicht mehr ausgeführt wird.

Symptome des Herunterfahrens SQL Server Diensts

Im Folgenden finden Sie ein Beispiel für den Clusterprotokollbericht für die Verfügbarkeitsgruppenrolle "ag", der auf einen Fehler hinweist, da QueryServiceStatusEx eine Prozess-ID 0zurückgegeben wurde:

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.

Diagnostizieren und Beheben von Ereignissen beim Herunterfahren des SQL-Diensts

Überprüfen Sie das Windows-Systemereignisprotokoll und SQL Server Fehlerprotokoll auf unerwartetes SQL Server Herunterfahren.

Wenn SQL Server durch ein Herunterfahren des Systems oder ein administratives Herunterfahren heruntergefahren wurde, wird der folgende Eintrag im SQL Server Fehlerprotokoll angezeigt:

2023-03-10 09:38:46.73 spid9s SQL Server wird als Reaktion auf eine "Stop"-Anforderung von Service Control Manager beendet. Dies ist nur eine Informationsmeldung. Es ist keine Benutzeraktion erforderlich.

Das Windows-Systemereignisprotokoll würde den folgenden Fehlereintrag anzeigen:

Informationen 10.03.2023 09:41:06 Uhr Service Control Manager 7036 None Der SQL Server -Dienst (MSSQLSERVER) ist in den Zustand "Beendet" eingetreten.

Das Windows-Systemereignisprotokoll zeigt den folgenden Fehlereintrag an, wenn SQL Server unerwartet heruntergefahren wird:

Fehler 3/10/2023 8:37:46 AM Service Control Manager 7034 None Der SQL Server -Dienst (MSSQLSERVER) wurde unerwartet beendet. Es hat dies 1 Mal(n) getan.

Überprüfen Sie das Ende des SQL Server Fehlerprotokolls auf Hinweise. Wenn das Fehlerprotokoll abrupt beendet wird, bedeutet dies, dass es mit Gewalt heruntergefahren wurde. Wenn SQL Server instance mithilfe des Task-Managers beendet wurde, enthält der SQL Server Fehlerbericht keine Informationen zu internen Problemen, die möglicherweise zum Herunterfahren des Prozesses geführt haben.

Wenn ein SQL Server internes Integritätsproblem dazu geführt hat, dass SQL Server unerwartet beendet wurde, gibt es am Ende des SQL-Fehlerprotokolls möglicherweise Hinweise auf eine mögliche schwerwiegende Ausnahme (einschließlich der generierten Diagnose einer Sicherungsdatei). Überprüfen Sie die Hinweise, und ergreifen Sie die erforderlichen Maßnahmen. Wenn Sie eine Speicherabbilddatei gefunden haben, sollten Sie sich an den Microsoft SQL Server-Support wenden und das SQL Server Fehlerprotokoll und den Inhalt der Speicherabbilddatei zur weiteren Untersuchung bereitstellen.

Leasetimeout: Ein Always On-Integritätsereignis

Always On verwendet einen Leasemechanismus, um die Integrität des Computers zu überwachen, auf dem SQL Server installiert ist. Das Standardmäßige Leasetimeout beträgt 20 Sekunden.

Symptome von Timeoutereignissen für Always On Lease

Hier sehen Sie eine Beispielausgabe eines Always On Leasetimeouts aus dem Clusterprotokoll. Sie können diese Zeichenfolgen durchsuchen, um ein Leasetimeout im Clusterprotokoll zu finden.

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

Weitere Informationen zum Leasetimeout finden Sie im Abschnitt Leasemechanismus unter Mechanismen und Richtlinien für Timeouts für Lease-, Cluster- und Integritätsüberprüfungen für Always On Verfügbarkeitsgruppen.

Diagnostizieren und Beheben von Timeoutereignissen Always On Lease

Es gibt zwei Standard Probleme, die ein Leasetimeout auslösen können:

• SQL Server Diagnose der Sicherungsdatei: Wenn SQL Server bestimmte interne Integritätsereignisse erkennt, z. B. eine Zugriffsverletzung, eine Assertion oder einen Planer-Deadlock, wird eine Diagnosedumpdatei (.mdmp) im SQL Server \LOG-Ordner generiert.

• Systemweites Leistungsproblem: Ein Leasetimeout weist nicht unbedingt auf ein SQL Server Integritätsproblem hin. Stattdessen könnte dies auf ein systemweites Integritätsproblem hinweisen, das sich auch auf die Integrität des SQL Server-basierten Servers auswirkt. Ausführlichere Schritte zur Problembehandlung finden Sie unter MSSQLSERVER_19407.

1. Diagnose SQL Server Sicherungsdatei

SQL Server kann ein internes Integritätsproblem erkennen, z. B. eine Zugriffsverletzung, assertion oder deadlocked scheduler. In diesem Fall generiert das Programm eine Miniabbilddatei (.mdmp) im ordner SQL Server \LOG des SQL Server Prozesses für die Diagnose. Der SQL Server Prozess wird für mehrere Sekunden gesperrt, während die Miniabbilddatei auf den Datenträger geschrieben wird. Während dieser Zeit befinden sich alle Threads innerhalb des SQL Server Prozesses in einem fixierten Zustand. Dies schließt den Leasethread ein, der von Always On Integritätsüberwachung überwacht wird. Daher kann Always On ein Leasetimeout erkennen.

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

Um dieses Problem zu beheben, muss die Diagnose der Sicherungsdatei auf die Grundursache untersucht werden. Wenden Sie sich an den Support von Microsoft SQL Server, um das SQL Server Fehlerprotokoll und den Inhalt der Speicherabbilddatei zur weiteren Untersuchung bereitzustellen.

2. Hohe CPU-Auslastung oder anderes Systemleistungsproblem

Ein Leasetimeout weist auf ein Leistungsproblem hin, das sich auf das gesamte System auswirkt, einschließlich SQL Server. Um das Systemproblem zu diagnostizieren, meldet Always On Integritäts-Diagnose Leistungsüberwachungsdaten im Clusterprotokoll und schließt das Leasetimeoutereignis ein. Die Leistungsdaten umfassen etwa 50 Sekunden bis zum Leasetimeoutereignis und melden die CPU-Auslastung, freien Arbeitsspeicher und Datenträgerlatenz.

Hier sehen Sie ein Beispiel für die gemeldeten Leistungsdaten, das ein Leasetimeout im Clusterprotokoll zeigt. In dieser Beispielausgabe eine hohe CPU-Gesamtauslastung, die möglicherweise mit dem Leasetimeout zusammenhängt.

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

Wenn die Leistungsdaten eine hohe CPU-Auslastung, eine geringe Arbeitsspeicherbedingung oder eine hohe Datenträgerlatenz zum Zeitpunkt eines Leasetimeouts aufweisen, beginnen Sie mit dem Sammeln Leistungsmonitor Daten für den ganzen Tag auf dem primären Replikat, um diese Symptome zu untersuchen. Durch das Erfassen von Leistungsmonitordaten über einen längeren Zeitraum können Sie Baseline- und Spitzenwerte für diese Ressourcen besser identifizieren und Änderungen in diesen Ressourcen überwachen, wenn ein Leasetimeout auftritt. Berücksichtigen Sie beim Sammeln dieser Daten, ob bestimmte geplante oder Ad-hoc-Workloads in SQL Server vorhanden sind, die mit dem Zeitpunkt dieser Ressourcenprobleme und Integritätsereignisse korrelieren.

Sie sollten auch Leistungsindikatoren erfassen, die die gleiche Systemressourcennutzung melden, einschließlich der folgenden:

• 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

Timeout der Integritätsprüfung: Ein Always On-Integritätsereignis

Wenn ein Verfügbarkeitsgruppenreplikat in die primäre Rolle übergibt, stellt Always On Integritätsüberwachung eine lokale ODBC-Verbindung mit dem SQL Server instance her. Wenn Always On verbunden ist und überwacht wird, wird ein Timeout der Integritätsprüfung ausgelöst, wenn SQL Server nicht innerhalb des Zeitraums reagiert, der für das Timeout der Integritätsprüfung der Verfügbarkeitsgruppe festgelegt ist (Standard: 30 Sekunden). In diesem Fall wechselt die Verfügbarkeitsgruppe von der primären Rolle in die Rolle Auflösen und initiiert ein Failover, wenn dies konfiguriert ist.

Weitere Informationen zu Timeouts bei Integritätsprüfungen finden Sie im Abschnitt "Timeoutvorgang der Integritätsprüfung" unter Mechanismen und Richtlinien für Timeouts für Lease, Cluster und Integritätsprüfung für Always On Verfügbarkeitsgruppen.

Hier sehen Sie ein Always On Integritätsüberprüfungstimeout, das im Clusterprotokoll gemeldet wird:

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.

Diagnostizieren und Beheben Always On Timeoutereignisses für die Integritätsprüfung

Der folgende Abschnitt hilft Ihnen, die SQL Server-Protokolle auf "Bread Crumb"-Ereignisse zu überprüfen, die Sie möglicherweise finden und die mit Always On Integritätsüberprüfungstimeouts korrelieren, die erkannt und gemeldet werden. Die hier überprüften Protokolle umfassen das Clusterprotokoll (in dem das Timeout für die Integritätsprüfung bestätigt wurde), die system_health erweiterten Ereignisprotokolle und SQL Server Fehlerprotokolle (beide im Ordner SQL Server \LOG) und das Windows-Systemereignisprotokoll. Verwenden Sie diese und andere Protokolle, um nach korrelierenden Ereignissen zu suchen, die Ihnen dabei helfen können, die Ursache des Timeouts für die Integritätsprüfung einzugrenzen.

1. Überprüfen auf nicht liefernde Schedulerereignisse

Das timeout der Always On Integritätsprüfung wird häufig durch ereignisse verursacht, die in SQL Server nicht auftreten. Wenn SQL Server erkennt, dass ein Thread für einen Planer nicht zurückgegeben wurde, meldet er, dass ein nicht zurückgegebenes Planerereignis aufgetreten ist. Wenn auf demselben Planer andere Aufgaben angezeigt werden, die keine CPU-Zeit empfangen, ist dies das primäre Zeichen eines nicht liefernden Schedulers. Dieses Verhalten kann zu einer verzögerten Ausführung dieser Aufgaben führen und Workloads "verhungern", die einem bestimmten Planer der CPU-Zeit zugewiesen sind.

Führen Sie die folgenden Schritte aus, um nach nicht liefernden Schedulerereignissen zu suchen:

1. Überprüfen Sie die SQL Server system_health erweiterten Ereignisprotokolle, um zu ermitteln, ob ein nicht lieferndes Planerereignis um die Zeit des timeout-Ereignisses der Always On Integritätsprüfung gemeldet wurde. Zu den ereignissen, die Sie möglicherweise nicht finden, gehören die folgenden:

   • 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. Öffnen Sie die SQL Server Ereignisprotokolle für erweiterte Systemintegrität auf dem primären Replikat bis zum Zeitpunkt des vermuteten Timeouts für die Integritätsprüfung.

3. Wechseln Sie in SQL Server Management Studio (SSMS) zu Datei > öffnen, und wählen Sie Erweiterte Ereignisdateien zusammenführen aus.

4. Klicken Sie auf die Schaltfläche Hinzufügen.

5. Navigieren Sie im Dialogfeld Datei öffnen zu den Dateien im Verzeichnis SQL Server \LOG.

6. Halten Sie CTRL gedrückt, und wählen Sie dann die Dateien aus, deren Namen mit system_health_xxx.xelbeginnen.

7. Wählen Sie Ok öffnen> aus.

8. Filtern Sie die Ergebnisse. Klicken Sie mit der rechten Maustaste auf ein Ereignis unter der Namensspalte , und wählen Sie Filter by this Value (Nach diesem Wert filtern) aus.

   

9. Definieren Sie einen Filter zum Sortieren von Zeilen, in denen die Werte in der Spalte name enthalten yieldsind, wie im folgenden Screenshot gezeigt. Dadurch werden alle Arten von ereignissen zurückgegeben, die möglicherweise in den system_health Protokollen aufgezeichnet wurden.

   

10. Vergleichen Sie die Zeitstempel, um festzustellen, ob zum Zeitpunkt des Timeouts der Integritätsprüfung Ereignisse ohne Ergebnis vorhanden waren. Hier sehen Sie das Im Clusterprotokoll gemeldete Timeout für die Integritätsprüfung:

    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.
    

    Sie können sehen, dass zum Zeitpunkt des Timeouts der Integritätsprüfung nicht zurückgegebene Ereignisse aufgetreten sind.

    

Wenn ereignisse ohne Ergebnis erkannt werden, überprüfen Sie die Ursache des nicht liefernden Ereignisses. Wenden Sie sich an das supportteam von SQL Server, um die nicht liefernden Ereignisse zu untersuchen.

2. Überprüfen des SQL Server Fehlerprotokolls

Überprüfen Sie das SQL Server Fehlerprotokoll zum Zeitpunkt des Timeouts der Integritätsprüfung, um Ereignisse zu korrelieren. Diese Ereignisse können "Brotkrümel" bereitstellen, die weitere Schritte vorschlagen, um die Grundursache der Timeouts für die Integritätsprüfung einzugrenzen.

Der folgende Protokolleintrag zeigt beispielsweise, dass im Clusterprotokoll ein Timeout für die Integritätsprüfung aufgetreten ist:

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.

Im SQL Server Fehlerprotokoll meldet SQL Server innerhalb von Sekunden nach dem Timeout der Integritätsprüfung, dass eine schwerwiegende E/A-Latenz erkannt wurde:

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.

Überprüfen Sie das Systemereignisprotokoll auf mögliche Systemhinweise, die sich auf das Timeoutereignis der Integritätsprüfung beziehen können. Wenn Sie das Windows-Systemereignisprotokoll überprüfen, finden Sie möglicherweise ein E/A-Problem, das gleichzeitig für dasselbe Integritätschecktimeout gemeldet wird:

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-Integrität: Ein Always On-Integritätsereignis

Always On überwacht verschiedene Arten von SQL Server-Integritätsereignissen. Während es ein primäres Replikat einer Verfügbarkeitsgruppe hostet, wird SQL Server kontinuierlich ausgeführtsp_server_diagnostics, die SQL Server Integrität mithilfe verschiedener Komponenten meldet. Wenn Integritätsprobleme erkannt werden, sp_server_diagnostics meldet einen Fehler für diese bestimmte Komponente und sendet die Ergebnisse zurück an den Always On Integritätserkennungsprozess. Wenn ein Fehler gemeldet wird, zeigt die Rolle Verfügbarkeitsgruppe den Fehlerstatus und ein mögliches Failover an, wenn die Verfügbarkeitsgruppe dafür konfiguriert ist.

Symptome von Always On SQL Server Integritätsereignissen

Hier sehen Sie ein Beispiel für ein SQL Server Integritätsproblem, das von im Clusterprotokoll gemeldet wirdsp_server_diagnostics. SQL Server meldet einen Fehlerzustand in der Systemkomponente an Always On Integritätsüberwachung, und die Verfügbarkeitsgruppe "contoso-ag" wird in den Status "Fehler" übergestellt.

Hinweis

Ein SQL Server Integritätsproblem generiert einen ähnlichen Bericht wie das Timeout der Integritätsprüfung. Beide Integritätsereignisse melden Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel. Der Unterschied für ein SQL Server Integritätsereignis besteht darin, dass es meldet, dass die SQL Server Komponente von "warning" in "error" geändert wurde.

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.

Diagnostizieren und Beheben von SQL Server Integritätsereignissen

Die Art des Integritätsproblems, das von SQL Server Integrität gemeldet wird, sollte die Richtung der Ursachenanalyse bestimmen.

Wenn Sie eine Verfügbarkeitsgruppe bereitstellen, wird standardmäßig auf FAILURE_CONDITION_LEVEL drei festgelegt. Dadurch wird die Überwachung einiger, aber nicht aller SQL Server Integritätsprofile aktiviert. Auf der Standardebene löst Always On ein Integritätsereignis aus, wenn SQL Server zu viele Speicherabbilddateien, eine Schreibzugriffsverletzung oder einen verwaisten Spinlock erzeugt. Wenn Sie die Verfügbarkeitsgruppe auf Ebene 4 oder fünf festlegen, werden die Arten von SQL Server Integritätsproblemen erweitert, die überwacht werden. Weitere Informationen zu den SQL Server Integritätsmonitoren Always On finden Sie unter Konfigurieren einer flexiblen richtlinie für automatisches Failover für eine Verfügbarkeitsgruppe – SQL Server Always On.

Führen Sie die folgenden Schritte aus, um das Always On spezifischen Integritätsproblem zu identifizieren:

1. Öffnen Sie die SQL Server erweiterten Ereignisprotokolle der Clusterdiagnose auf dem primären Replikat bis zum Zeitpunkt des auftretens des vermuteten SQL Server Integritätsereignisses.

2. Wechseln Sie in SSMS zu Datei>öffnen, und wählen Sie dann Erweiterte Ereignisdateien zusammenführen aus.

3. Wählen Sie Hinzufügen.

4. Navigieren Sie im Dialogfeld Datei öffnen zu den Dateien im Verzeichnis SQL Server \LOG.

5. Drücken Sie CTRL, wählen Sie die Dateien aus, deren Namen übereinstimmen<servername>_<instance>_SQLDIAG_xxx.xel, und wählen Sie dann Ok öffnen> aus.

   

   In SSMS wird ein neues Registerkartenfenster mit den erweiterten Ereignissen angezeigt, wie im folgenden Screenshot gezeigt.

6. Um ein SQL Server Integritätsproblem zu untersuchen, suchen Sie die component_health_result , deren state_desc Wert isterror. Hier sehen Sie ein Beispiel für ein Systemkomponentenereignis, das einen Fehler an Always On Integritätsüberwachung zurückgibt:

   

7. Doppelklicken Sie im unteren Bereich auf die Datenspalte . Dadurch werden die detaillierten Komponentendaten in einem neuen SSMS-Fensterbereich zur Überprüfung geöffnet. Die Systemkomponentendaten sehen wie folgt aus:

   

   Beachten Sie, dass die "totalDumprequests=186"-Daten darauf hindeuten, dass in diesem SQL Server zu viele Diagnoseereignisse für Sicherungsdateien generiert wurden. Dies ist der Grund, warum die Systemkomponente einen Fehlerzustand gemeldet hat. Wenn Always On Integritätsüberwachung diesen Fehlerzustand empfängt, löst sie ein Integritätsereignis der Verfügbarkeitsgruppe aus. Sie können auch überprüfen, ob keine Schreibzugriffsverletzungen oder verwaisten Spinlocks aus den Daten erkannt wurden, die in den Systemkomponentendaten bereitgestellt werden.

   Wenn dies erforderlich ist, wenden Sie sich an SQL Server Support, um einen Supportvorfall zu öffnen, um weitere Unterstützung bei der Suche nach der Grundursache für diese internen SQL Server Gesundheitsprobleme zu erhalten.