Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Zusammenfassung
In einer SQL Server AlwaysOn-Verfügbarkeitsgruppe tritt ein Verbindungstimeout auf, wenn ein Replikat innerhalb des Zeitraums keine Antwort von seinem SESSION_TIMEOUT Partnerreplikat empfängt. Das SQL Server Fehlerprotokoll meldet diese zeitweiligen Timeouts als Fehler 35201, 35206 und 35267. Diese Timeouts können die Verfügbarkeitsgruppe in einem Zustand "Nicht synchronisieren " belassen. Häufige Ursachen sind ein Anwendungsproblem, z. B. eine hohe CPU-Auslastung oder ein nicht nachgebender Scheduler, oder ein Netzwerkproblem, z. B. Latenz oder Paketverluste. Dieser Artikel hilft Ihnen, Zeitüberschreitungsfehler bei Verbindungen zu interpretieren und die Grundursache mithilfe der SQL Server-Fehlerprotokolle, dynamischen Verwaltungssichten (DMVs) von Always On, Extended Events und Netzwerkablaufverfolgungen zu diagnostizieren. Außerdem wird erläutert, wie Sie die Timeouts mindern können, einschließlich der Frage, wie die Einstellung des Verfügbarkeitsgruppenreplikats SESSION_TIMEOUT angepasst wird.
Symptome und Auswirkungen von intermittierenden Verbindungstimeouts
Primäre und sekundäre Replikate geben unterschiedliche Ergebnisse zurück.
Schreibgeschützte Workloads, die sekundäre Replikate abfragen, können veraltete Daten abfragen. Wenn es zeitweise zu Zeitüberschreitungen bei der Verbindung mit dem Replikat kommt, werden Änderungen an den Daten in der Datenbank des primären Replikats bei einer Abfrage derselben Daten noch nicht in der sekundären Datenbank angezeigt. Weitere Informationen finden Sie im Abschnitt Datenlatenz auf dem sekundären Replikat.
Verfügbarkeitsgruppe für Diagnoseberichte nicht synchronisiert
Das Always On-Dashboard in SQL Server Management Studio (SSMS) meldet möglicherweise eine fehlerhafte Verfügbarkeitsgruppe mit Replikaten im Zustand "Nicht synchronisieren".
Wenn Sie die SQL Server Fehlerprotokolle für diese Replikate überprüfen, werden möglicherweise Meldungen wie die folgenden angezeigt, die ein Verbindungstimeout zwischen den Replikaten in der Verfügbarkeitsgruppe angeben.
Hier sehen Sie das Fehlerprotokoll aus dem primären Replikat.
2023-02-15 07:10:55.500 spid43s Always On availability groups connection with secondary database terminated for primary database 'agdb' on the availability replica 'SQL19AGN2' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.
Hier sehen Sie das Fehlerprotokoll aus dem sekundären Replikat.
2023-02-15 07:11:03.100 spid31s A connection time-out has occurred on a previously established connection to availability replica 'SQL19AGN1' with id [<replicaid>]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.
2023-02-15 07:11:03.100 spid31s Always On Availability Groups connection with primary database terminated for secondary database 'agdb' on the availability replica 'SQL19AGN1' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.
Zeitweilige Verbindungsprobleme können sich auf die Failoverbereitschaft eines sekundären Replikats auswirken.
Wenn Sie die Verfügbarkeitsgruppe für automatisches Failover konfigurieren und der synchrone Failoverpartner zeitweise die Verbindung mit dem primären Failover trennt, schlägt das automatische Failover möglicherweise fehl.
Sie können sys.dm_hadr_database_replica_cluster_states abfragen, um zu überprüfen, ob die Verfügbarkeitsgruppendatenbank failoverbereit ist. Hier ist ein Beispiel für die Ergebnisse, wenn der Spiegelungsendpunkt im sekundären Replikat beendet wird.
SELECT drcs.database_name, drcs.is_failover_ready, ar.replica_server_name, ars.role_desc, ars.connected_state_desc,
ars.last_connect_error_description, ars.last_connect_error_number, ar.endpoint_url
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.availability_replicas ar ON ars.replica_id=ar.replica_id
JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ar.replica_id=drcs.replica_id
WHERE ars.role_desc='SECONDARY'
Automatisches Failover bringt die Verfügbarkeitsgruppe möglicherweise nicht online in der primären Rolle auf dem Failoverpartnercomputer, wenn das Failover mit einem Replikatverbindungstimeout übereinstimmt.
Bedeutung der Verbindungstimeoutfehler
Der Standardwert für die Verfügbarkeitsgruppenreplikateinstellung SESSION_TIMEOUT beträgt 10 Sekunden. Sie konfigurieren diese Einstellung für jedes Replikat. Es bestimmt, wie lange das Replikat wartet, um eine Antwort vom Partnerreplikat zu erhalten, bevor ein Verbindungstimeout gemeldet wird. Wenn ein Replikat keine Antwort vom Partnerreplikat erhält, meldet es ein Verbindungstimeout im Microsoft SQL Server Fehlerprotokoll und im Windows Anwendungsprotokoll. Das Replikat, das das Timeout meldet, versucht sofort, eine erneute Verbindung herzustellen, und versucht weiterhin alle fünf Sekunden.
Normalerweise erkennt und meldet nur ein Replikat das Verbindungstimeout. Beide Replikate können jedoch gleichzeitig das Verbindungstimeout melden. Je nachdem, ob das Verbindungstimeout für eine zuvor hergestellte Verbindung oder eine neue Verbindung aufgetreten ist, sind unterschiedliche Versionen dieser Nachricht vorhanden.
Message 35206 A connection timeout has occurred on a previously established connection to availability replica '<replicaname>' with id [<replicaid>]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.
Message 35201 A connection timeout has occurred while attempting to establish a connection to availability replica '<replicaname>' with id [<replicaid>]. Either a networking or firewall issue exists, or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.
Das Partnerreplikat erkennt möglicherweise kein Timeout. Wenn dies der Fall ist, wird möglicherweise Nachricht 35201 oder 35206 angezeigt. Wenn dies nicht der Fall ist, meldet sie einen Verbindungsverlust an jede der Verfügbarkeitsgruppendatenbanken.
Message 35267 Always On Availability Groups connection with primary/secondary database terminated for primary/secondary database '<databasename>' on the availability replica '<replicaname>' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.
Hier sehen Sie ein Beispiel dafür, was SQL Server dem Fehlerprotokoll meldet. Wenn Sie den Spiegelungsendpunkt im primären Replikat beenden, erkennt das sekundäre Replikat ein Verbindungstimeout, und Nachrichten 35206 und 35267 werden im sekundären Replikatfehlerprotokoll gemeldet.
2023-02-15 07:11:03.100 spid31s A connection timeout has occurred on a previously established connection to availability replica 'SQL19AGN1' with id [<replicaid>]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.
2023-02-15 07:11:03.100 spid31s Always On Availability Groups connection with primary database terminated for secondary database 'agdb' on the availability replica 'SQL19AGN1' with Replica ID:[<replicaid>]. This is an informational message only. No user action is required.
In diesem Beispiel hat das primäre Replikat kein Verbindungstimeout erkannt, da es weiterhin mit dem sekundären Replikat kommunizieren konnte. Es wurde für jede Datenbank in der Verfügbarkeitsgruppe die Meldung 35267 ausgegeben. Hier gibt es nur eine Datenbank, 'agdb'.
2023-02-15 07:10:55.500 spid43s Always On Availability Groups connection with secondary database terminated for primary database 'agdb' on the availability replica 'SQL19AGN2' with Replica ID: {<replicaid>}. This is an informational message only. No user action is required.
Ursachen für Replikatverbindungstimeouts
Anwendungsproblem
SQL Server ist möglicherweise zu ausgelastet, um die Verbindung mit dem Spiegelungsendpunkt innerhalb des Zeitraums der Verfügbarkeitsgruppe SESSION_TIMEOUT zu bedienen, was zu einem Verbindungstimeout führt. Hier sind einige häufige Gründe:
SQL Server hat eine CPU-Auslastung von 100 Prozent. Diese Bedingung bedeutet, dass SQL Server oder eine andere Anwendung jeweils alle verfügbaren CPU für Sekunden verbraucht.
SQL Server weist nicht reagierende Schedulerereignisse auf. SQL Server-Threads sind dafür verantwortlich, die CPU für andere Threads freizugeben, damit diese ihre Arbeit abschließen können. Wenn ein Thread nicht rechtzeitig die Ausführung abgibt, kann dies die Verbindung mit dem Spiegelungsendpunkt verzögern und zu einem Timeout führen.
Bei SQL Server kommt es zu einer Erschöpfung der Workerthreads, zu Arbeitsspeichermangel oder zu Anwendungsproblemen, die die Fähigkeit beeinträchtigen, die Verbindung zum Spiegelungsendpunkt zu bedienen.
Netzwerkproblem
Sammeln Sie Netzwerkablaufverfolgungen für die primären und sekundären Replikate, wenn der Fehler auftritt, und überprüfen Sie sie dann auf Netzwerklatenz und verworfene Pakete.
Diagnose von Zeitüberschreitungen bei der Replikatverbindung
In diesem Abschnitt wird erläutert, wie Sie die SQL-Server-Protokolle analysieren, um Anwendungsprobleme zu diagnostizieren, die SQL Server daran hindern, die Verbindung mit dem Partnerreplikat zu bedienen. Anhand dieser Tipps können Sie die Ursache für die Replikatverbindungstimeouts ermitteln. Es endet mit erweiterten Anleitungen zum Sammeln von Netzwerkablaufverfolgungen, wenn die Verbindungstimeouts auftreten, damit Sie den Netzwerkstatus überprüfen können.
Zeitpunkt und Ort von Zeitüberschreitungen bei Replikatverbindungen bewerten
Überprüfen Sie den Verlauf, die Häufigkeit und Trends der Verbindungstimeouts. Die Nachrichten im SQL Server Fehlerprotokoll sind eine gute Quelle für diese Überprüfung. Wo werden die Verbindungstimeouts gemeldet? Werden sie konsistent auf dem primären oder dem sekundären Replikat gemeldet? Wann sind die Fehler aufgetreten? Sind sie in einer bestimmten Woche des Monats, Wochentags oder Tageszeit aufgetreten? Entspricht andere geplante Wartung oder Batchverarbeitung den Zeiten, zu denen die Verbindungstimeouts beobachtet werden? Diese Bewertung kann Ihnen dabei helfen, den Umfang einzugrenzen und die Zeitüberschreitungen bei Verbindungen zu korrelieren, um die Grundursache zu identifizieren.
Überprüfen der AlwaysOn_health erweiterten Ereignissitzung
Die AlwaysOn_health erweiterte Ereignissitzung wurde erweitert, um das ucs_connection_setup Ereignis einzuschließen, das ausgelöst wird, wenn ein Replikat eine Verbindung mit seinem Partnerreplikat aufbaut. Dieses Ereignis kann hilfreich sein, wenn Sie Probleme mit dem Verbindungstimeout beheben.
Notiz
Das ucs_connection_setup erweiterte Ereignis ist ab SQL Server 2019 CU15 verfügbar. Weitere Informationen finden Sie unter Konfigurieren erweiterter Ereignisse für Verfügbarkeitsgruppen.
Always On-dynamische Verwaltungsansichten (DMVs) abfragen
Sie können die Always On-DMVs abfragen, um weitere Informationen über den Verbindungsstatus des Replikats zu erhalten. Diese Abfrage meldet nur den verbundenen Zustand und alle Fehler, die dem Verbindungstimeout zum Zeitpunkt der Auftreten der Probleme zugeordnet sind. Wenn die Verbindungsprobleme nur zeitweise auftreten, lässt sich der Zustand der unterbrochenen Verbindung durch die Abfrage möglicherweise nicht ohne Weiteres erfassen.
SELECT ar.replica_server_name, ars.role_desc, ars.connected_state_desc,
ars.last_connect_error_description, ars.last_connect_error_number, ar.endpoint_url
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.availability_replicas ar ON ars.replica_id=ar.replica_id
Das folgende Beispiel zeigt einen dauerhaften getrennten Zustand, da der Spiegelungsendpunkt des primären Replikats beendet wurde. Wenn Sie das primäre Replikat abfragen, kann die Always On-DMV Informationen zum primären und zu allen sekundären Replikaten liefern (der Endpunkt ist auf dem primären Replikat deaktiviert).
Wenn Sie das sekundäre Replikat abfragen, gibt das Always On DMV nur Informationen zum sekundären Replikat aus.
Überprüfen der erweiterten Ereignissitzung "Always On"
Stellen Sie mithilfe von SSMS Objekt-Explorer eine Verbindung mit jedem Replikat her, und öffnen Sie die
AlwaysOn_healtherweiterten Ereignisdateien.Wechseln Sie in SSMS zu "Datei>öffnen", und wählen Sie dann "Erweiterte Ereignisdateien zusammenführen" aus.
Wählen Sie die Schaltfläche Hinzufügen aus.
Wechseln Sie im Dialogfeld "Datei öffnen" zu den Dateien im verzeichnis SQL Server \LOG.
Halten Sie STRG gedrückt, und wählen Sie dann die Dateien aus, deren Name mit AlwaysOn_healthxxx.xel beginnt.
Wählen Sie "Öffnen" und dann "OK" aus.
In SSMS wird ein neues Fenster mit Registerkarten angezeigt, das die AlwaysOn-Ereignisse enthält.
Der folgende Screenshot zeigt die
AlwaysOn_healthDaten aus dem sekundären Replikat. Das erste umrissene Feld zeigt den Verbindungsverlust an, nachdem der Endpunkt des primären Replikats beendet wurde. Das zweite umrissene Feld zeigt den Verbindungsfehler an, der auftritt, wenn das sekundäre Replikat das nächste Mal versucht, eine Verbindung mit dem primären Replikat herzustellen.
Überprüfen, ob nicht ertragende Ereignisse Verbindungstimeouts verursachen
Einer der häufigsten Gründe dafür, dass ein Verfügbarkeitsreplikat die Partnerreplikatverbindung nicht bedienen kann, ist ein nicht ertragsorientierter Scheduler. Weitere Informationen zu nicht nachgebenden Schedulern finden Sie unter Problembehandlung bei SQL Server-Scheduling und -Yielding.
SQL Server erfasst Nicht-Yielding-Schedulerereignisse, die nur 5 bis 10 Sekunden dauern. Sie meldet diese Ereignisse im TrackingNonYieldingScheduler Datenpunkt in der sp_server_diagnostics query_processing Komponentenausgabe.
Führen Sie die folgenden Schritte aus, um nach Nicht-Yielding-Ereignissen zu suchen, die zu Timeouts bei Replikatverbindungen führen können.
Erstellen Sie einen SQL-Agent-Auftrag, der alle fünf Sekunden sp_server_diagnostics aufzeichnet.
Planen Sie diesen Auftrag auf dem Server, der das Verbindungstimeout nicht meldet. Das heißt, das Server A-Replikat meldet das Verbindungstimeout im Fehlerprotokoll. Richten Sie in diesem Fall den SQL-Agent-Auftrag auf dem Partnerreplikat Server B ein. Alternativ dazu erstellen Sie den Auftrag auf beiden Replikaten, wenn bei beiden Replikaten Verbindungszeitüberschreitungen auftreten.
Führen Sie das folgende T-SQL-Skript aus, um einen Auftrag zu erstellen, der alle fünf Sekunden ausgeführt wird
sp_server_diagnostics, fügt die Ausgabe an eine Textdatei an und startet dann den Auftrag. Im folgenden Beispiel wird dersp_server_diagnostics 5Befehl alle fünf Sekunden ausgeführt. Also muss dieser Job nicht so geplant werden, dass er alle fünf Sekunden ausgeführt wird. Starten Sie einfach den Auftrag, und er wird alle fünf Sekunden ausgeführt, bis er gestoppt wird.USE [msdb] GO DECLARE @ReturnCode INT SELECT @ReturnCode = 0 DECLARE @jobId BINARY(16) EXEC @ReturnCode = msdb.dbo.sp_add_job @job_name=N'Run sp_server_diagnostics', @owner_login_name=N'sa', @job_id = @jobId OUTPUT /****** Object: Step [Run SP_SERVER_DIAGNOSTICS] Script Date: 2/15/2023 4:20:41 PM ******/ EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'Run SP_SERVER_DIAGNOSTICS', @subsystem=N'TSQL', @command=N'sp_server_diagnostics 5', @database_name=N'master', @output_file_name=N'D:\cases\2423\sp_server_diagnostics_output.out', @flags=2 EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)' EXEC sp_start_job 'Run sp_server_diagnostics'Notiz
Ersetzen Sie in diesen Befehlen
@output_file_namedurch einen gültigen Pfad, und geben Sie einen Dateinamen an.
Analysieren der Ergebnisse
Beachten Sie beim Auftreten eines Verbindungstimeouts den Zeitstempel des Timeoutereignisses, das im SQL Server Fehlerprotokoll angezeigt wird. Für die Replikate im folgenden Beispiel meldet SQL19AGN1 die Zeitüberschreitungen bei den Replikatverbindungen. Daher erstellen Sie einen SQL-Agent-Auftrag auf SQL19AGN2dem Partnerreplikat. Anschließend wird ein Verbindungstimeout im SQL19AGN1 Fehlerprotokoll bei 07:24:31 gemeldet.
Überprüfen Sie als Nächstes die Ausgabe des SQL-Agent-Auftrags, der sp_server_diagnostics etwa zum gemeldeten Zeitpunkt ausführt. Überprüfen Sie insbesondere den TrackingNonYieldingScheduler Datenpunkt in der query_processing Komponentenausgabe. Die Ausgabe meldet, dass auf Server SQL19AGN2 ein nicht reagierender Scheduler (als hexadezimaler Wert ungleich null) ungefähr zu dem Zeitpunkt erfasst wurde (um 07:24:33), zu dem die Zeitüberschreitung der Replikatverbindung auf SQL19AGN1 gemeldet wurde (um 07:24:31).
Notiz
Die folgende sp_server_diagnostics-Ausgabe wird konkateniert, um sowohl die create_time- (Zeitstempel) als auch die query_processing TrackingNonYieldingScheduler-Ergebnisse anzuzeigen.
Untersuchen eines nicht ertragenden Zeitplanereignisses
Wenn Sie in den vorherigen Diagnoseschritten festgestellt haben, dass ein nicht nachgebendes Ereignis die Zeitüberschreitung der Replikatverbindung verursacht hat, führen Sie die folgenden Schritte aus.
Identifizieren Sie die Arbeitslasten, die in SQL Server ausgeführt werden, zum Zeitpunkt, zu dem die ereignisse, die keine Rendite haben, auftreten.
Ähnlich wie bei den Zeitüberschreitungen von Replikatverbindungen sollten Sie nach Trends bei diesen Ereignissen im Verlauf des Monats, des Tages oder der Woche suchen, in denen sie auftreten.
Erfassen Sie die Leistungsmonitor-Ablaufverfolgung auf dem System, auf dem das nicht reagierende Ereignis erkannt wurde.
Sammeln Sie Schlüsselleistungsindikatoren für Systemressourcen, einschließlich Prozessor::% Prozessorzeit, Arbeitsspeicher::Verfügbare MBytes, logischer Datenträger::Avg Disk Queue Length, and Logical Disk::Avg Disk sec/Transfer.
Öffnen Sie bei Bedarf einen SQL Server-Supportfall, um weitere Unterstützung bei der Ermittlung der Grundursache dieser nicht reagierenden Ereignisse zu erhalten. Teilen Sie die Protokolle, die Sie zur weiteren Analyse gesammelt haben.
Sammeln einer Netzwerkablaufverfolgung während eines Verbindungstimeouts
Wenn die vorherige Diagnose der SQL Server Anwendung keine Ursache liefert, überprüfen Sie das Netzwerk. Um das Netzwerk erfolgreich zu analysieren, müssen Sie eine Netzwerkablaufverfolgung sammeln, die die Zeit des Verbindungstimeouts abdeckt.
Das folgende Verfahren startet eine Windows netsh Netzwerkablaufverfolgung für die Replikate, für die die Verbindungstimeouts in den SQL Server Fehlerprotokollen gemeldet werden. Eine geplante Windows-Aufgabe wird ausgelöst, wenn einer der SQL-Server-Verbindungsfehler im Anwendungsprotokoll protokolliert wird. Die geplante Aufgabe führt einen Befehl aus, um die netsh Netzwerkablaufverfolgung zu beenden, sodass die wichtigsten Netzwerkablaufverfolgungsdaten nicht überschrieben werden. Bei diesen Schritten wird auch ein Pfad von *F:* für die Batch- und Ablaufverfolgungsprotokolle vorausgesetzt. Passen Sie diesen Pfad an Ihre Umgebung an.
Starten Sie eine Netzwerkablaufverfolgung für die beiden Replikate, in denen die Verbindungstimeouts auftreten, wie im folgenden Codeausschnitt gezeigt.
netsh trace start capture=yes persistent=yes overwrite=yes maxsize=500 tracefile=f:\trace.etlErstellen Sie stoptrace.bat. Sie können diese Datei in einer Eingabeaufforderung mit Administratorrechten erstellen.
echo netsh trace stop > F:\stoptrace.batErstellen Sie geplante Aufgaben in Windows, die die
netshNachverfolgung bei den Ereignissen 35206 oder 35267 beenden. Sie können diese Aufgaben in einer Eingabeaufforderung mit Administratorrechten erstellen.schtasks /Create /tn Event35206Task /tr F:\stoptrace.bat /SC ONEVENT /EC Application /MO *[System/EventID=35206] /f /RL HIGHEST schtasks /Create /tn Event35267Task /tr F:\stoptrace.bat /SC ONEVENT /EC Application /MO *[System/EventID=35267] /f /RL HIGHESTNachdem das Ereignis auftritt und die Netzwerkablaufverfolgungen beendet und erfasst werden, löschen Sie die
ONEVENTAufgaben.schtasks /Delete /tn Event35206Task /F schtasks /Delete /tn Event35267Task /F
Die Analyse der Netzwerkablaufverfolgung fällt nicht in den Umfang dieser Problembehandlung. Wenn Sie die Netzwerkablaufverfolgung nicht interpretieren können, wenden Sie sich an das Microsoft SQL Server-Supportteam, und stellen Sie die Ablaufverfolgung zusammen mit anderen angeforderten Protokolldateien für die Ursachenanalyse bereit.
Verringern der Verbindungstimeouts
Möglicherweise können Sie die Verbindungszeitüberschreitungen abmildern, indem Sie die SESSION_TIMEOUT-Eigenschaft des Verfügbarkeitsgruppenreplikats anpassen. Diese Einstellung ist pro Replikat, passen Sie sie also für das primäre und jedes betroffene sekundäre Replikat an. Der Standardwert ist 10 Sekunden, sodass Sie 15 Sekunden als nächsten Wert ausprobieren können. Hier ist ein Beispiel für die Syntax.
ALTER AVAILABILITY GROUP ag
MODIFY REPLICA ON 'SQL19AGN1' WITH (SESSION_TIMEOUT = 15);