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
Nach einem automatischen Failover oder einem geplanten manuellen Failover ohne Datenverlust für eine Verfügbarkeitsgruppe stellen Sie möglicherweise fest, dass die Failoverzeit Ihre Recovery Time Objective (RTO) überschritten hat. Oder wenn Sie die Failoverzeit eines sekundären Replikats mit synchronem Commit (z. B. eines automatischen Failoverpartners) mithilfe der in Überwachen der Leistung von Always On-Verfügbarkeitsgruppen beschriebenen Methode abschätzen, stellen Sie fest, dass sie Ihre RTO überschreitet.
Wenn Ihr automatische Failover trotzdem nicht abgeschlossen wurde, lesen Sie Problembehandlung bei automatischen Failover in SQL Server 2012 Always On-Umgebungen.
In den folgenden Abschnitten werden die häufigsten Ursachen für eine Failover-Zeit beschrieben, die den RTO überschreitet.
Eine meldende Workload verhindert die Ausführung des Wiederholungsthreads.
Der Wiederholungsthread auf dem sekundären Replikat wird durch eine lang andauernde schreibgeschützte Abfrage an der Durchführung von Änderungen an der Datendefinitionssprache (DDL) gehindert.
Erklärung
Auf dem sekundären Replikat rufen die schreibgeschützten Abfragen Schemastabilitätssperren (Sch-S) ab. Diese Sch-S-Sperren können den Redo-Thread daran hindern, Sperren zur Schemamodifikation (Sch-M) zu erhalten, um DDL-Änderungen vorzunehmen. Ein blockierter Redo-Thread kann keine Logdatensätze anwenden, bis die Blockierung aufgehoben ist. Sobald die Blockierung aufgehoben wurde, kann dieser bis zum Ende des Protokolls aufholen und die Fortsetzung des nachfolgenden Prozesses zur Rückgängigmachung und den Failoverprozess zulassen.
Diagnose und Lösung
Wenn der Wiederholungsthread blockiert wurde, wird ein erweitertes Ereignis namens sqlserver.lock_redo_blocked generiert. Darüber hinaus können Sie die DMV „sys.dm_exec_request“ für das sekundäre Replikat abfragen, um herauszufinden, welche Sitzung den REDO-Thread blockiert, und dann entsprechende Korrekturmaßnahmen treffen. Die folgende Abfrage gibt die Sitzungs-ID der schreibgeschützten Abfrage zurück, die den Wiederholungsthread blockiert.
select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource
from sys.dm_exec_requests where command = 'DB STARTUP'
Sie können die Reporting-Workload zu Ende laufen lassen; dadurch wird der Redo-Thread entsperrt. Alternativ können Sie den Redo-Thread sofort entsperren, indem Sie den Befehl KILL (Transact-SQL) für die blockierende Sitzungs-ID ausführen.
Ein Wiederholungsthread gerät aufgrund von Ressourcenkonflikten in den Rückstand.
Eine umfangreiche meldende Workload auf dem sekundären Replikat hat das sekundäre Replikat verlangsamt, weshalb der Wiederholungsthread in den Rückstand geraten ist.
Erklärung
Bei der Anwendung von Protokolldatensätzen auf das sekundäre Replikat liest der Wiederholungsthread die Protokolldatensätze vom Protokolldatenträger und greift dann für jeden Protokolldatensatz auf die Datenseiten zu, um den Protokolldatensatz anzuwenden. Der Seitenzugriff kann E/A-gebunden sein (beim Zugriff auf den physischen Datenträger), wenn sich die Seite noch nicht im Pufferpool befindet. Wenn eine E/A-gebundene meldende Workload vorhanden ist, konkurriert die meldende Workload mit dem Wiederholungsthread um E/A-Ressourcen und kann den Wiederholungsthread verlangsamen.
Diagnose und Lösung
Anhand der folgenden DMV-Abfrage können Sie erkennen, wie weit der Wiederholungsthread im Rückstand liegt, indem Sie die Diskrepanz zwischen last_redone_lsn und last_received_lsn messen.
select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,
last_redone_lsn, last_redone_time
from sys.dm_hadr_database_replica_states
Wenn der Wiederholungsthread tatsächlich im Rückstand liegt, müssen Sie der Ursache für die Leistungsbeeinträchtigung beim sekundären Replikat auf den Grund gehen. Wenn es einen E/A-Konflikt mit der Berichtsworkload gibt, können Sie mithilfe von Resource Governor die von der Berichtsworkload verwendeten CPU-Zyklen steuern und dadurch bis zu einem gewissen Grad indirekt die in Anspruch genommenen E/A-Zyklen kontrollieren. Wenn die meldende Workload 10 Prozent der CPU verbraucht, die Workload jedoch E/A-gebunden ist, können Sie zur Drosselung von Leseworkloads den CPU-Ressourceneinsatz mithilfe des Resource Governor auf 5 % beschränken, wodurch die Auswirkungen auf die E/A minimiert werden.