Freigeben über

MSSQLSERVER_35267

  • Artikel

Gilt für: SQL Server

Details

attribute Wert
Produktname SQL Server
Ereignis-ID 35267
Ereignisquelle MSSQLSERVER
Komponente SQLEngine
Symbolischer Name HADR_DISCONNECTED_DB
Meldungstext Die Verbindung "Always On Availability Groups" mit %S_MSG Datenbank wurde für die Datenbank '%S_MSG '%.*ls' auf dem Verfügbarkeitsreplikat '%.*ls' mit Replikat-ID beendet: {%.8x-%.4x-%.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x%.2x}. Diese Meldung dient nur zu Informationszwecken. Es ist keine Benutzeraktion erforderlich.

Erklärung

Diese Meldung tritt auf, wenn ein Verfügbarkeitsgruppenreplikat seine Verbindung mit den Remotereplikaten auf dem Datenbankspiegelungsendpunkt verliert. Im Folgenden finden Sie Beispiele dafür, wie Sie diesen Fehler sehen können:

Always On Availability Groups connection with secondary database terminated for primary database 'ContosoDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.

Always On Availability Groups connection with primary database terminated for secondary database 'ContosoDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.

Wie Sie sehen können, kann der Fehler im primären Replikat angezeigt werden, das angibt, dass die Kommunikation mit dem sekundären Replikat verloren gegangen ist, oder umgekehrt.

Fehler 35267 ist normalerweise intermittiert und kann sich selbst lösen, wenn sich die zugrunde liegende Ursache selbst löst. Beispielsweise kann sich ein zeitweiliges Netzwerkproblem selbst beheben, und die Verbindung kann sich erneut einrichten.

In vielen Fällen ist der Remoteknoten, mit dem der lokale Knoten eine Verbindung herstellen möchte, möglicherweise nicht einmal über den Verbindungsfehler informiert. Daher wird dieser Fehler möglicherweise nur auf einem der Replikate ausgelöst, nicht beide.

Fehler 35267 kann manchmal zusammen mit Fehler 35206 auftreten, der ausgelöst wird, wenn ein signifikanter Zeitraum ohne eine erfolgreiche Verbindung abgelaufen ist (z. B. mehr als 10 Sekunden).

A connection timeout has occurred on a previously established connection to availability replica 'PRODSQL' with id [xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx].  Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

Always On Availability Groups connection with primary database terminated for secondary database 'ContosoHRDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
Always On Availability Groups connection with primary database terminated for secondary database 'ContosoFinDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
Always On Availability Groups connection with primary database terminated for secondary database 'ContosoMktngDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.

Die AG-Verbindung mit dem Remotereplikat kann zu verschiedenen Problemen führen, die lokale Replikate betreffen. Wenn die AG z. B. den SYNCHRON-Modus verwendet und die Verbindung verloren geht, wartet das lokale Replikat möglicherweise auf eine Bestätigung von der Remote. Daher wird das Transaktionsprotokoll nicht abgeschnitten, und das Transaktionsprotokoll ist nicht mehr verfügbar (Fehler MSSQLSERVER_9002) und später nicht mehr verfügbar (Fehler MSSQLSERVER_9001). Hier ist ein Beispiel für eine Gruppe von Fehlern, bei denen dies aufgetreten ist. Der Grund für das Vollständige des Transaktionsprotokolls ist "AVAILABILITY_REPLICA", was bedeutet, dass dieses Replikat auf das Remoteprotokoll wartet, um die angewendeten Protokolldatensätze zu bestätigen.

Error: 9002, Severity: 17, State: 9.
The transaction log for database 'ContosoAnalyticsDb' is full due to 'AVAILABILITY_REPLICA'.
Error: 3314, Severity: 21, State: 3.
During undoing of a logged operation in database 'ContosoAnalyticsDb' (page (1:32573799) if any), an error occurred at log record ID (7672713:36228:159). Typically, the specific failure is logged previously as an error in the operating system error log. Restore the database or file from a backup, or repair the database.
State information for database 'ContosoAnalyticsDb' - Hardened Lsn: '(7672713:38265:1)'    Commit LSN: '(7672712:1683087:46)'    Commit Time: 'JuN  10 2022  5:51AM'

Always On Availability Groups connection with secondary database terminated for primary database 'ContosoAnalyticsDb' on the availability replica 'SQL2019DB' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.

Database ContosoAnalyticsDb was shutdown due to error 3314 in routine 'XdesRMReadWrite::RollbackToLsn'. Restart for non-snapshot databases will be attempted after all connections to the database are aborted.

Error during rollback. shutting down database (location: 1).
Error: 9001, Severity: 21, State: 5.
The log for database 'ContosoAnalyticsDb' is not available. Check the operating system error log for related error messages. Resolve any errors and restart the database.

Recovery of database 'ContosoAnalyticsDb' (6) is 0% complete (approximately 60177 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.

Ursache

  • Netzwerkverbindungsprobleme können zwischen den primären und sekundären Replikaten bestehen.
  • SQL Server- oder Betriebssystemprobleme in den primären oder sekundären Replikaten führen dazu, dass Threads nicht ausgeführt werden können. Beispiele:
    • SQL OS Scheduler-Probleme (Nichtertragungs- oder Deadlock-Scheduler)
    • Geringer Arbeitsspeicher auf dem Computer, der zum Kürzen aller Prozesse im System führt, einschließlich SQL Server
    • Betriebssystemprobleme, die dazu führen, dass Prozesse nicht mehr reagieren
  • Langsame E/A-Probleme, die zeitweilig lange Wartezeiten auf das primäre oder sekundäre Replikat verursachen

Aktion des Benutzers

In den nachstehenden Informationen werden die häufigeren Szenarien beschrieben, es handelt sich jedoch nicht um eine vollständige Liste der Schritte zur Problembehandlung. Die spezifischen Gründe für das Auftreten dieses Problems können eine lange Liste der Möglichkeiten umfassen.

Verbindungsprobleme

Um verbindungsprobleme vom SQL Server zu überprüfen, bei dem der Fehler an den Remote-SQL Server ausgelöst wird, können Sie die folgenden Schritte in Betracht ziehen:

Schritt 1. Stellen Sie sicher, dass der Endpunkt auf dem Remote-SQL Server aktiv ist.

Führen Sie die folgende Abfrage aus, um den Endpunkt zu ermitteln:

SELECT
 tep.name as EndPointName,
 sp.name As CreatedBy,
 tep.type_desc,
 tep.state_desc,
 tep.port
FROM
 sys.tcp_endpoints tep
INNER JOIN sys.server_principals sp ON tep.principal_id = sp.principal_id
WHERE tep.type = 4

Schritt 2. Testen der Konnektivität mit dem Remoteendpunkt

Verwenden Sie Test-NetConnection , um die Konnektivität zu überprüfen. Wenn der Endpunkt überwacht und die Verbindung erfolgreich ist, suchen Sie nach der TcpTestSucceeded : True. Ersetzen Sie ServerName oder IP_Address durch Remote SQL Server und die Portnummer durch die des Datenbankspiegelungsendpunkts.

Test-NetConnection -ComputerName <ServerName> -Port <port_number>
Test-NetConnection -ComputerName <IP_address> -Port <port_number>

Schritt 3. Erfassen einer Netzwerkablaufverfolgung

Zeitweilige Netzwerkfehler sind häufig schwierig aufzuspüren, es sei denn, Sie erfassen eine Netzwerkablaufverfolgung, die Netzwerkzurücksetzungen (verworfene Pakete) oder ähnliche Probleme anzeigt. Weitere Informationen finden Sie unter 0300 Intermittierendes oder periodisches Netzwerkproblem

SQL Server-Zeitplanprobleme

Wenn die SQL Server-Arbeitsthreads aus verschiedenen Gründen probleme mit dem Planer auftreten, können die Threads, die eingehende Anforderungen des Diensts senden, vorübergehend nicht mehr reagieren, während die Zeitplanungsprobleme zuletzt auftreten.

Schritt 4. Überprüfen auf Zeitplanprobleme in SQL Server

Ein typisches Problem mit einem Nichtertragszeitplaner wird im SQL Server-Fehlerprotokoll nach 70 Sekunden Nichtertragsstatus aufgezeichnet. SQL Server überprüft jedoch den Status von Planern häufiger als dies und meldet diese zwischengeschalteten nicht ertragenden Zustände in erweiterten Ereignissen. Wenn Sie Planerprobleme auf dem Remoteknoten ermitteln, die dem Zeitpunkt des Fehlers 35267 entsprechen, konzentrieren Sie sich auf die erste Lösung. Hier erfahren Sie, wie Sie auf kurzlebige Vorkommen von Terminplanungsproblemen überprüfen können, die den Schwellenwert von 70 Sekunden nicht erreichen, aber für 10 oder 20 Sekunden auftreten.

Verwenden der erweiterten Ereignisdatei " Systemintegrität "

  1. Suchen Sie die Erweiterte Ereignisdatei "Systemintegrität " aus dem Zeitpunkt des Ereignisses.
  2. Doppelklicken Sie auf die system_health_0_xxxxxxxxxxxxxxxxxx.xel Datei, um sie in SQL Server Management Studio (SSMS) zu öffnen. Alternativ können sys.fn_xe_file_target_read_file Sie die Datei als Tabelle anzeigen oder importieren, um die Filterung zu vereinfachen.
  3. Suchen Sie nach Vorkommen scheduler_monitor_non_yielding_ring_buffer_recorded Ereignisses. Wenn Sie feststellen, ist dies ein Hinweis darauf, dass SQL Server nicht ertragende Schedulerereignisse erkannt hat und diese aufgezeichnet. Diese Ereignisse werden vor den tatsächlichen Nicht-Yiedling-Speicherabbildern und Fehlerprotokolleinträgen aufgezeichnet, die nach 60-70 Sekunden des zustandsfremden Zustands auftreten. Mit anderen Worten, Sie können die scheduler_monitor_non_yielding_ring_buffer_recorded verwenden, um kurzlebige Probleme mit nicht zurückgegebenen Zeitplanern zu erkennen, die nicht im Fehlerprotokoll protokolliert werden, aber noch aufgetreten sind. Dies könnte Gründe für zeitweilige oder kurzlebige Konnektivität zwischen AG-Knoten sein.

Verwenden des Diagnoseprotokolls

  1. Suchen Sie das Diagnoseprotokoll im Verzeichnis \Log ab dem Zeitpunkt des Ereignisses (gilt für Windows-Clustersysteme). Das Dateinamenformat ist wie folgt SERVERNAME_MSSQLSERVER_SQLDIAG_x_xxxxxxxxxxxxxxxxxx.xel.

  2. Doppelklicken Sie, um die Datei in SQL Server Management Studio (SSMS) zu öffnen. Alternativ können sys.fn_xe_file_target_read_file Sie die Datei als Tabelle anzeigen oder importieren, um die Filterung zu vereinfachen.

  3. Suchen Sie nach dem Öffnen in SSMS eine Instanz component_health_result Ereignisses, klicken Sie mit der rechten Maustaste auf Folgendes, und wählen Sie "Spalte in Tabelle anzeigen" aus: Komponente, state_desc

  4. Klicken Sie dann mit der rechten Maustaste auf jede Spalte, und wählen Sie "Nach diesem Wert filtern" aus, um die folgenden Filter anzuwenden:

    • das component_health_result-Ereignis , das nur angezeigt wird
    • component field='query processing'
    • <> state_desc "sauber".

  5. Doppelklicken Sie dann auf die Datenspalte , um die XML-Daten zu öffnen und den Wert in der ersten Zeile anzuzeigen trackingNonYieldingScheduler .

  6. Wenn sich der Wert von 0x0 diesem unterscheidet, bedeutet sql Server, dass frühe Anzeichen eines nicht ertragenden Zeitplans erkannt und hier gemeldet werden.

    Nachfolgend finden Sie ein Beispiel, in dem SQL Server eine bedingung ohne Ertrag mit einer Planeradresse "0x4fedb840040" erkannt hat:

     <queryProcessing maxWorkers="9600" workersCreated="2574" workersIdle="1883" tasksCompletedWithinInterval="175591" pendingTasks="3" ... trackingNonYieldingScheduler="0x4fedb840040">

Betriebssystem mit geringem Arbeitsspeicher

Es kann verschiedene Probleme auf Betriebssystemebene (Os) geben, die einen solchen zeitweiligen Mangel an Reaktion auslösen. Ein gängiger Speicher ist geringer Arbeitsspeicher. Führen Sie auf dem Remote-AG-Knoten, auf dem das verdächtige Problem auftritt, die folgenden Schritte aus:

Schritt 5. Überprüfen auf Betriebssystemspeicherprobleme, die zu SQL Server-Speicher paging auf datenträger führen

  1. Überprüfen Sie das Windows System-Ereignisprotokoll auf Fehler, die auf einen niedrigen physischen oder virtuellen Arbeitsspeicher hinweisen.

  2. Überprüfen Sie im SQL Server-Fehlerprotokoll oder im Ereignisprotokoll der Windows-Anwendung auf Fehler 17890, ob geringer Arbeitsspeicher auf dem Computer zu einer Kürzung aller Prozesse im System führt, einschließlich SQL Server. Der Fehler sieht wie folgt aus:

    A significant part of SQL Server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 3383250, committed (KB):    9112480, memory utilization: 37%.

    Detaillierte T-Shooting-Schritte finden Sie unter MSSQLSERVER_17890

Schritt 6. Konfigurieren des maximalen Serverspeichers und sperren von Seiten im Arbeitsspeicher ordnungsgemäß

  1. Konfigurieren Sie sql Server Max Server Memory auf einen Wert, der die Verwendung des Betriebssystems und anderer Prozesse zulässt, arbeitsspeicher verfügbar ist. Ein empfohlener Wert zum Festlegen des maximalen Serverspeichers für SQL Server auf maximal 75 % der RAM-Größe auf dem System. Weitere Informationen finden Sie unter Serverspeicherkonfigurationsoptionen
  2. Aktivieren Sie die Option "Seiten sperren" (Windows), um eine massive Auslagerung des SQL Server-Puffercaches zu verhindern.

Langsame Datenträger-E/A

In einigen Fällen kann eine übermäßige langsame E/A dazu führen, dass die SQL Server-Threads vorübergehend nicht mehr reagieren, was dazu führen kann, dass das andere AG-Replikat getrennt wird.

Schritt 7. Beheben von langsamen E/A-Problemen

Wenn Fehler auftreten, die auf langsame E/A hinweisen, beheben Sie die zugrunde liegenden Gründe für langsame E/A.

SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [F:\TLOG\ContosoDb.ldf] in database id 9.  The OS file handle is 0x00000000000003BC.  The offset of the latest long I/O is: 0x0000003d26f600
SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [F:\DATA\t38data\ContosoDb2.mdf] in database id 7.  The OS file handle is 0x000000000000118C.  The offset of the latest long I/O is: 0x00000000012000
SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [F:\DATA\t38data\ContosoDb.mdf] in database id 9.  The OS file handle is 0x000000000000134C.  The offset of the latest long I/O is: 0x00000000012000

Always On Availability Groups connection with primary database terminated for secondary database 'ContosoDb2' on the availability replica 'SQLNODE1\INSTANCE19' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
Always On Availability Groups connection with primary database terminated for secondary database 'ContosoDb' on the availability replica 'SQLNODE1\INSTANCE19' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
  • Aktualisieren sie alle Gerätetreiber und Firmware, oder führen Sie andere Diagnosen aus, die Ihrem E/A-Subsystem zugeordnet sind.
  • Der Datenträgerzugriff kann durch Filtertreiber verlangsamt werden, z. B. ein Antivirenprogramm. Um die Zugriffsgeschwindigkeit zu erhöhen, schließen Sie die SQL Server-Datendateien aus den aktiven Virenscans aus.
  • Arbeiten Sie mit Ihrem Hardwareanbieter und Systemadministrator zusammen, um die Ursache für langsame E/A zu diagnostizieren und zu beheben.

Ausführliche Anweisungen finden Sie unter Problembehandlung für langsame SQL Server-Leistung durch E/A-Probleme und MSSQLSERVER_833.