Freigeben über

Mögliche Fehler während der Datenbankspiegelung

Physische, Betriebssystem- oder SQL Server-Probleme können zu einem Fehler in einer Datenbankspiegelungssitzung führen. Die Datenbankspiegelung überprüft nicht regelmäßig, ob die Komponenten, von denen Sqlservr.exe abhängt, ordnungsgemäß funktionieren oder ausgefallen sind. Bei einigen Arten von Fehlern meldet die betroffene Komponente jedoch einen Fehler bei Sqlservr.exe. Ein von einer anderen Komponente gemeldeter Fehler wird als schwerwiegender Fehlerbezeichnet. Um andere Fehler zu erkennen, die andernfalls unbemerkt bleiben würden, implementiert die Datenbankspiegelung einen eigenen Timeoutmechanismus. Wenn ein Spiegelungstimeout auftritt, wird bei der Datenbankspiegelung davon ausgegangen, dass ein Fehler aufgetreten ist und ein weicher Fehler deklariert wird. Einige Fehler, die auf Ebene der SQL Server-Instanz auftreten, führen jedoch nicht dazu, dass die Spiegelung in einen Timeout führt und können unbemerkt bleiben.

Von Bedeutung

Fehler in anderen Datenbanken als der gespiegelten Datenbank können in einer Datenbankspiegelungssitzung nicht erkannt werden. Darüber hinaus wird ein Datenträgerfehler nicht erkannt, es sei denn, die Datenbank wird aufgrund eines Datenträgerfehlers neu gestartet.

Die Geschwindigkeit der Fehlererkennung und daher die Reaktionszeit der Spiegelungssitzung auf einen Fehler hängt davon ab, ob der Fehler hart oder weich ist. Bestimmte Hardwarefehler, wie z. B. Netzwerkfehler, werden sofort gemeldet. In bestimmten Fällen kann jedoch die Meldung von Hardwarefehlern durch komponentenspezifische Timeoutzeitspannen verzögert werden. Bei weichen Fehlern bestimmt die Länge des Spiegelungszeitlimits die Geschwindigkeit der Fehlererkennung. Standardmäßig sind hierfür 10 Sekunden festgelegt. Dies ist der empfohlene Mindestwert.

Ausfälle aufgrund von schweren Fehlern

Mögliche Ursachen für harte Fehler sind die folgenden Bedingungen (aber nicht beschränkt auf):

  • Eine unterbrochene Verbindung oder ein fehlerhaftes Kabel

  • Eine fehlerhafte Netzwerkkarte

  • Eine Änderung des Routers

  • Änderungen an der Firewall

  • Endpunktneukonfigurationen

  • Ausfall des Laufwerks mit dem Transaktionsprotokoll

  • Ein Betriebssystem- oder Prozessfehler

Wenn beispielsweise das Protokolllaufwerk in der Prinzipaldatenbank nicht mehr reagiert und fehlschlägt, informiert das Betriebssystem Sqlservr.exe, dass ein schwerwiegender Fehler aufgetreten ist.

Einige Komponenten, z. B. Netzwerkkomponenten und einige IO-Subsysteme, verfügen über eigene Timeouts, um Fehler zu ermitteln. Solche Timeouts sind unabhängig von der Datenbankspiegelung, die keine Kenntnis von ihnen hat und sich ihres Verhaltens völlig nicht bewusst ist. In diesen Fällen erhöht die Timeoutverzögerung die Zeit zwischen einem Fehler und dem Zeitpunkt, zu dem die Datenbankspiegelung den daraus resultierenden schwerwiegenden Fehler erhält.

Hinweis

Die aktive Fehlerprüfung, die für die Datenbankspiegelung durchgeführt wird, erfolgt nur bei weichen Fehlern. Weitere Informationen finden Sie nachfolgend in diesem Thema unter "Fehler aufgrund von Softwarefehlern".

Um die im Netzwerk auftretenden Fehlerbedingungen interpretieren zu können, erkundigen Sie sich bei einem Netzwerkingenieur, welche Fehlermeldungen an einen Port gesendet werden, wenn die folgenden Ereignisse bei einer TCP-Verbindung auftreten:

  • DNS funktioniert nicht.

  • Die Kabel sind nicht angeschlossen.

  • Microsoft Windows verfügt über eine Firewall, die einen bestimmten Port blockiert.

  • Die Anwendung, die einen Port überwacht, erzeugt einen Fehler.

  • Ein Windows-Server wurde umbenannt.

  • Ein Windows-basierter Server wird neu gestartet.

Hinweis

Die Spiegelung schützt nicht vor Problemen, die für den Clientzugriff auf die Server spezifisch sind. Ziehen Sie beispielsweise einen Fall in Betracht, in dem ein öffentlicher Netzwerkadapter Clientverbindungen mit der Prinzipalserverinstanz verarbeitet, während eine Karte der privaten Netzwerkschnittstelle den gesamten Spiegelungsverkehr zwischen Serverinstanzen verarbeitet. In diesem Fall würde ein Fehler des öffentlichen Netzwerkadapters verhindern, dass Clients auf die Datenbank zugreifen, obwohl die Datenbank weiterhin gespiegelt wird.

Fehler aufgrund weicher Fehler

Bedingungen, die zu Spiegelungstimeouts führen können, umfassen Folgendes (aber nicht beschränkt auf):

  • Netzwerkfehler, wie z. B. Timeouts für TCP-Verbindungen, gelöschte oder beschädigte Pakete oder Pakete in falscher Reihenfolge.

  • Ein Betriebssystem, ein Server oder eine Datenbank, die nicht reagiert.

  • Ein Windows-Servertimeout.

  • Unzureichende Verarbeitungsressourcen, wie z. B. Überlastung der CPU oder des Datenträgers, volles Transaktionsprotokoll oder unzureichender Arbeitsspeicher oder nicht genügend Threads. In diesen Fällen müssen Sie den Timeoutzeitraum erhöhen, die Arbeitsauslastung reduzieren oder die Hardware an die Arbeitsauslastung anpassen.

Der Spiegelungsmechanismus Time-Out

Da weiche Fehler nicht direkt von einer Serverinstanz erkannt werden können, kann ein weicher Fehler dazu führen, dass eine Serverinstanz auf unbestimmte Zeit wartet. Um dies zu verhindern, implementiert die Datenbankspiegelung einen eigenen Timeoutmechanismus, basierend auf jeder Serverinstanz in einer Spiegelsitzung, die einen Ping für jede geöffnete Verbindung in einem festen Intervall sendet.

Um eine Verbindung geöffnet zu halten, muss eine Serverinstanz einen Ping für diese Verbindung im definierten Timeoutzeitraum sowie die Zeit empfangen, die zum Senden eines weiteren Pings erforderlich ist. Durch den Empfang eines Pings innerhalb des Timeoutzeitraums wird angezeigt, dass die Verbindung weiterhin offen ist und dass die Serverinstanzen über diese Verbindung kommunizieren. Beim Empfangen eines Pings setzt eine Serverinstanz den Timeoutzähler für diese Verbindung zurück.

Wenn während des Timeoutzeitraums kein Ping für eine Verbindung empfangen wird, berücksichtigt eine Serverinstanz das Timeout der Verbindung. Die Serverinstanz schließt die Timeoutverbindung und behandelt das Timeoutereignis entsprechend dem Zustand und dem Betriebsmodus der Sitzung.

Selbst wenn der andere Server tatsächlich ordnungsgemäß funktioniert, wird ein Timeout als Fehler gewertet. Wenn der Timeoutwert für eine Sitzung zu kurz für die regelmäßige Reaktionsfähigkeit eines Partners ist, können falsche Fehler auftreten. Ein falscher Fehler tritt auf, wenn eine Instanz eines Servers erfolgreich eine andere kontaktiert, deren Antwortzeit so langsam ist, dass die Pings nicht empfangen werden, bevor die Timeout-Periode abläuft.

In Sitzungen mit hoher Leistung beträgt der Timeoutzeitraum immer 10 Sekunden. Dies reicht im Allgemeinen aus, um falsche Fehler zu vermeiden. In Sitzungen mit hoher Sicherheit beträgt der Standardtimeoutzeitraum 10 Sekunden, Sie können die Dauer jedoch ändern. Es wird empfohlen, die Timeoutzeitspanne für die Spiegelung immer auf mindestens 10 Sekunden festzulegen, um irrtümliche Fehler zu vermeiden.

So ändern Sie den Timeoutwert (nur hochsicherheitsmodus)

So zeigen Sie den aktuellen Timeoutwert an

Reagieren auf einen Fehler

Unabhängig vom Fehlertyp reagiert eine Serverinstanz, die einen Fehler erkennt, entsprechend basierend auf der Rolle der Instanz, dem Betriebsmodus der Sitzung und dem Status einer anderen Verbindung in der Sitzung. Informationen dazu, was beim Verlust eines Partners auftritt, finden Sie unter Betriebsmodi für die Datenbankspiegelung.

Siehe auch

Schätzen der Dienstunterbrechung während des Rollenwechsels (Datenbankspiegelung)
Betriebsmodi für Datenbankspiegelung
Rollenwechsel während einer Datenbank-Spiegelungssitzung (SQL Server)
Datenbankspiegelung (SQL Server)

  • Last updated on