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.
Gilt für:
SQL Server
Nachdem Sie ein erzwungenes manuelles Failover einer Verfügbarkeitsgruppe auf ein sekundäres Replikat mit asynchronem Commit durchgeführt haben, stellen Sie möglicherweise fest, dass der Datenverlust Ihr Recovery Point Objective (RPO) überschreitet. Oder wenn Sie den potenziellen Datenverlust eines asynchronen Commit-Sekundärreplikats mit der in Überwachen der Leistung für Always On-Verfügbarkeitsgruppen beschriebenen Methode berechnen, stellen Sie fest, dass er Ihr RPO überschreitet.
Ein sekundäres Replikat mit synchronem Commit garantiert keinen Datenverlust, der potenzielle Datenverlust eines sekundären Replikats mit asynchronem Commit hängt jedoch davon ab, wie viele Protokolldaten auf dem sekundären Replikat noch auf die dauerhafte Speicherung auf dem Datenträger warten.
In den folgenden Abschnitten werden häufige Ursachen für einen hohen möglichen Datenverlust eines sekundären Replikats im asynchronen Commitmodus beschrieben. Dabei wird davon ausgegangen, dass kein systemisches Leistungsproblem in Ihrer Serverinstanz besteht, das nicht im Zusammenhang mit Verfügbarkeitsgruppen steht.
Eine hohe Netzwerklatenz oder ein niedriger Netzwerkdurchsatz führt zur Protokollanhäufung beim primären Replikat.
Die häufigste Ursache für die Überschreitung der RPO bei Datenbanken besteht darin, dass sie nicht schnell genug an das sekundäre Replikat gesendet werden können.
Erklärung
Das primäre Replikat aktiviert die Flusssteuerung für die Protokollsendung, wenn es die maximal zulässige Anzahl von unbestätigten Nachrichten, die über das sekundäre Replikat gesendet werden, überschritten hat. Erst, wenn einige dieser Nachrichten bestätigt wurden, können weitere Protokollblöcke an das sekundäre Replikat gesendet werden. Da ein Datenverlust nur dann verhindert werden kann, wenn dieser auf dem sekundären Replikat festgeschrieben wurde, vergrößert sich durch die Anhäufung nicht gesendeter Protokollnachrichten der mögliche Datenverlust.
Diagnose und Lösung
Eine große Anzahl von Nachrichten, die erneut an das sekundäre Replikat gesendet werden, kann auf eine hohe Netzwerklatenz und auf Netzwerkrauschen zurückzuführen sein. Sie können auch den DMV-Wert log_send_rate mit dem Leistungsobjekt „Geleerte Protokollbytes/Sekunde“ abgleichen. Wenn Protokolle schneller auf den Datenträgern geleert werden, als sie gesendet werden, kann der mögliche Datenverlust ins Unermessliche steigen.
Es ist außerdem hilfreich, die zwei Leistungsobjekte SQL Server:Availability Replica > Flow Control Time (ms/sec) und SQL Server:Availability Replica > Flow Control/sec zu überprüfen. Wenn Sie diese beiden Werte multiplizieren, sehen Sie für die letzte Sekunde, wie viel Zeit damit verbracht wurde, darauf zu warten, dass die Flusssteuerung aufgehoben wird. Je länger die Wartezeit bei der Flusssteuerung, desto niedriger ist die Sendegeschwindigkeit.
Die folgenden Metriken sind hilfreich bei der Diagnose von Netzwerklatenz und -durchsatz. Sie können andere Windows-Tools wie ping.exe und Netzwerkmonitor verwenden, um Latenz und Netzwerkauslastung auszuwerten.
DMV
sys.dm_hadr_database_replica_states, log_send_queue_sizeDMV
sys.dm_hadr_database_replica_states, log_send_rateLeistungsindikator
SQL Server:Database > Log Bytes Flushed/secLeistungsindikator
SQL Server:Database Mirroring > Send/Receive Ack TimeLeistungsindikator
SQL Server:Availability Replica > Bytes Sent to Replica/secLeistungsindikator
SQL Server:Availability Replica > Bytes Sent to Transport/secLeistungsindikator
SQL Server:Availability Replica > Flow Control Time (ms/sec)Leistungsindikator
SQL Server:Availability Replica > Flow Control/secLeistungsindikator
SQL Server:Availability Replica > Resent Messages/sec
Versuchen Sie zur Behandlung dieses Problems, ein Upgrade für Ihre Netzwerkbandbreite durchzuführen oder unnötigen Netzwerkdatenverkehr zu beseitigen oder zu verringern.
Ein Datenträger-E/A-Engpass verlangsamt die Protokollfestschreibung beim sekundären Replikat.
Abhängig von der Bereitstellung der Datenbankdateien kann die Protokollhärtung aufgrund von E/A-Konkurrenz mit der Reporting-Workload verlangsamt werden.
Erklärung
Ein Datenverlust wird verhindert, sobald der Protokollblock in die Protokolldatei festgeschrieben wurde. Aus diesem Grund ist es wichtig, die Protokolldatei von der Datendatei zu isolieren. Wenn die Protokolldatei und die Datendatei beide auf derselben Festplatte liegen, verbraucht ein Reporting-Workload mit intensiven Lesezugriffen auf die Datendatei dieselben E/A-Ressourcen, die für die Protokollhärtung benötigt werden. Eine langsame Loghärtung kann zu einer verzögerten Bestätigung an das primäre Replikat führen, was ein übermäßiges Auslösen der Flusssteuerung und lange Wartezeiten durch die Flusssteuerung verursachen kann.
Diagnose und Lösung
Wenn Sie sichergestellt haben, dass das Netzwerk nicht unter hoher Latenz oder geringem Durchsatz leidet, sollten Sie die sekundäre Replik auf E/A-Engpässe untersuchen. Abfragen von SQL Server: Minimieren von Datenträger-E/As sind nützlich, um Konflikte zu identifizieren. Beispiele aus diesem Artikel werden der Übersichtlichkeit halber unten aufgeführt.
Mit dem folgenden Skript können Sie die Anzahl der Lese- und Schreibvorgänge zu allen Daten- und Protokolldateien für jede Verfügbarkeitsdatenbank anzeigen, die auf einer Instanz von SQL Server ausgeführt wird. Diese ist nach der durchschnittlichen E/A-Verzögerungszeit in Millisekunden sortiert. Beachten Sie, dass die Zahlen kumulativ ausgehend vom letzten Zeitpunkt sind, an dem die Serverinstanz gestartet wurde. Aus diesem Grund sollten Sie nach einiger Weile die Differenz zwischen zwei Messungen messen.
SELECT DB_NAME(database_id) AS
[Database Name] ,
file_id ,
io_stall_read_ms ,
num_of_reads ,
CAST(io_stall_read_ms / ( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,
io_stall_write_ms ,
num_of_writes ,
CAST(io_stall_write_ms / ( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms] ,
io_stall_read_ms + io_stall_write_ms AS [io_stalls] ,
num_of_reads + num_of_writes AS [total_io] ,
CAST(( io_stall_read_ms + io_stall_write_ms ) / ( 1.0 + num_of_reads
+ num_of_writes) AS NUMERIC(10,1)) AS [avg_io_stall_ms]
FROM sys.dm_io_virtual_file_stats(NULL, NULL)
WHERE DB_NAME(database_id) IN (SELECT DISTINCT database_name FROM sys.dm_hadr_database_replica_cluster_states)
ORDER BY avg_io_stall_ms DESC;
Die nächste Abfrage stellt eine Point-in-Time-Momentaufnahme (nicht kumulativ) der auf Ihrem System ausstehenden E/A-Anforderungen bereit.
SELECT DB_NAME(mf.database_id) AS [Database] ,
mf.physical_name ,
r.io_pending ,
r.io_pending_ms_ticks ,
r.io_type ,
fs.num_of_reads ,
fs.num_of_writes
FROM sys.dm_io_pending_io_requests AS r
INNER JOIN sys.dm_io_virtual_file_stats(NULL, NULL) AS fs ON r.io_handle = fs.file_handle
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.file_id = mf.file_id
ORDER BY r.io_pending , r.io_pending_ms_ticks DESC;
Sie können vergleichen, wie sich Lese- und Schreib-E/A zueinander verhalten, um E/A-Konflikte zu identifizieren.
Im Folgenden werden einige weitere Leistungsindikatoren aufgeführt, mit denen Sie E/A-Engpässe diagnostizieren können:
Physischer Datenträger: Alle Indikatoren
Physischer Datenträger: Durchschn. Sek./Übertragung
SQL Server: Datenbanken > Wartezeit für Protokollleerungen
SQL Server: Datenbanken > Wartevorgänge für Protokollleerungen/Sekunde
SQL Server: Datenbanken > Protokollpool-Datenträgerlesevorgänge/Sekunde
Wenn Sie einen E/A-Engpass identifizieren und die Protokoll- und Datendatei auf derselben Festplatte platziert haben, sollten Sie im ersten Schritt die Daten- und die Protokolldatei auf separaten Datenträgern platzieren. Durch diese bewährte Vorgehensweise wird verhindert, dass die meldende Workload den Übertragungsprotokollpfad vom primären Replikat zum Protokollpuffer sowie dessen Fähigkeit zur Festschreibung der Transaktion auf dem sekundären Replikat beeinträchtigt.