Behandeln von Problemen bei der Warteschlange für die Wiederherstellung (redo) in einer Always On-Verfügbarkeitsgruppe

Zusammenfassung

Dieser Artikel hilft Ihnen bei der Problembehandlung von Warteschlangen für die Wiederherstellung (auch als Redo-Warteschlangen bezeichnet) auf einem sekundären Replikat in einer SQL Server Always On-Verfügbarkeitsgruppe. Es wird erläutert, was die Wiederherstellungswarteschlange ist, wie Sie die Größe der Redo-Warteschlange und die Redo-Rate überprüfen, wie Sie die Werte interpretieren und wie Sie häufige Ursachen von Redo-Verzögerungen diagnostizieren und beheben, einschließlich blockierter Redo-Threads und Single-Thread-Redo.

Was die Wiederherstellungswarteschlange ist

Änderungen am primären Replikat in einer Verfügbarkeitsgruppendatenbank werden an jedes sekundäre Replikat in derselben Verfügbarkeitsgruppe gesendet. Nachdem die Änderungen zu einem sekundären Replikat gelangt sind, werden sie zuerst in die Transaktionsprotokolldatei der Verfügbarkeitsgruppendatenbank geschrieben (gehärtet). Microsoft SQL Server dann den Wiederherstellungs- oder Redo-Vorgang verwendet, um diese Protokolldatensätze auf die Datenbankdateien anzuwenden.

Wenn Änderungen im Transaktionsprotokoll schneller eintreffen und erhärten, als sie erneut ausgeführt werden können, wird eine Wiederherstellungswarteschlange angezeigt. Diese Warteschlange ist die Gruppe der gehärteten Protokolldatensätze, die noch nicht auf die Datenbank angewendet werden.

Symptome und Auswirkungen der Wiederherstellungswarteschlange

Veraltete Daten auf sekundären Replikaten

Schreibgeschützte Workloads, die sekundäre Replikate abfragen, erhalten möglicherweise veraltete Daten. Wenn die Wiederherstellungswarteschlange auftritt, werden die letzten Änderungen in der primären Replikatdatenbank noch nicht auf der sekundären Datenbank angezeigt, wenn Sie dieselben Daten abfragen.

Die Änderungen treffen auf dem Sekundärserver ein und werden in die Datenbankprotokolldatei geschrieben, können jedoch erst gelesen werden, wenn Redo sie auf die Datendateien anwendet.

Weitere Informationen finden Sie im Abschnitt "Datenlatenz im sekundären Replikat " unter "Unterschiede zwischen den Verfügbarkeitsmodi für eine AlwaysOn-Verfügbarkeitsgruppe".

Längere Failover-Zeit oder überschrittenes RTO

Recovery Time Objective (RTO) ist die maximale Ausfallzeit der Datenbank, die eine Organisation tolerieren kann, und wie schnell die Organisation die Verwendung der Datenbank nach einem Ausfall wiedererlangen kann. Wenn auf einem sekundären Replikat eine große Recovery-Warteschlange vorhanden ist und ein Failover auftritt, kann der REDO-Vorgang auf dem neuen primären Replikat länger dauern als die RTO. Nach Abschluss des Redo-Vorgangs geht die Datenbank in die primäre Rolle über und entspricht dem Zustand, der vor dem Failover bestand. Eine längere Wiederholungszeit verzögert, wie schnell die Produktion fortgesetzt wird.

Diagnosetools melden eine ungesunde Verfügbarkeitsgruppe

Wenn die Redo-Warteschlange beträchtlich ist, zeigt das Always On-Dashboard in SQL Server Management Studio (SSMS) die Verfügbarkeitsgruppe möglicherweise als fehlerhaft an.

Überprüfen der Wiederherstellungswarteschlange

Die Wiederherstellungswarteschlange ist eine Maßeinheit pro Datenbank. Sie können es über das Always On-Dashboard im primären Replikat überprüfen oder die sys.dm_hadr_database_replica_states dynamische Verwaltungsansicht (DYNAMIC Management View, DMV) für das primäre oder sekundäre Replikat abfragen. Die Leistungsindikatoren im Leistungsmonitor melden außerdem die Größe der Wiederherstellungswarteschlange und die Redo-Rate. Überprüfen Sie diese Zähler auf dem sekundären Replikat.

In den nächsten Abschnitten werden Methoden zur aktiven Überwachung der Wiederherstellungswarteschlange der Datenbank einer Verfügbarkeitsgruppe beschrieben.

Abfrage sys.dm_hadr_database_replica_states

Die sys.dm_hadr_database_replica_states DMV gibt für jede Datenbank einer Verfügbarkeitsgruppe eine Zeile zurück. In redo_queue_size der Spalte wird die Größe der Wiederherstellungswarteschlange in Kilobyte angezeigt. Um den Trend in der Wiederherstellungswarteschlange alle 30 Sekunden zu überwachen, richten Sie eine Abfrage wie die folgende ein. Führen Sie es auf dem primären Replikat aus. Es verwendet das is_local=0 Prädikat, um Daten für das sekundäre Replikat zu melden, wo redo_queue_size und redo_rate relevant sind.

WHILE 1=1
BEGIN
SELECT drcs.database_name, ars.role_desc, drs.redo_queue_size, drs.redo_rate,
ars.recovery_health_desc, ars.connected_state_desc, ars.operational_state_desc, ars.synchronization_health_desc, *
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ars.replica_id=drcs.replica_id
JOIN sys.dm_hadr_database_replica_states drs ON drcs.group_database_id=drs.group_database_id
WHERE ars.role_desc='SECONDARY' AND drs.is_local=0
waitfor delay '00:00:30'
END

So sieht die Ausgabe aus.

Screenshot der Ausgabe für die Abfrage, die die Daten für das sekundäre Replikat meldet, bei dem redo_queue_size und redo_rate relevant sind.

Überprüfen Sie die Wiederherstellungswarteschlange im Always On-Dashboard.

Führen Sie die folgenden Schritte aus, um die Wiederherstellungswarteschlange zu überprüfen:

  1. Wählen Sie in SSMS Objekt-Explorer eine Verfügbarkeitsgruppe aus, und halten Sie sie gedrückt (oder klicken Sie mit der rechten Maustaste darauf), um das Kontextmenü zu öffnen.

  2. Wählen Sie " Dashboard anzeigen" aus.

    Die Verfügbarkeitsgruppendatenbanken werden zuletzt aufgelistet, wobei einige Daten für jede Datenbank gemeldet werden. Redo Queue Size (KB) und Redo Rate (KB/sec) werden standardmäßig nicht angezeigt, Sie können sie jedoch der Ansicht hinzufügen, wie im nächsten Schritt gezeigt.

  3. Wenn Sie diese Indikatoren hinzufügen möchten, wählen Sie die Kopfzeile oberhalb der Datenbankberichte aus (oder klicken Sie mit der rechten Maustaste darauf), und wählen Sie dann die anzuzeigenden Spalten aus.

  4. Um Redo-Warteschlangengröße (KB) und Redo-Rate (KB/sec) hinzuzufügen, wählen Sie den im folgenden Screenshot rot hervorgehobenen Spaltenkopf aus und halten Sie ihn gedrückt (oder klicken Sie mit der rechten Maustaste darauf).

    Screenshot, der das Hinzufügen der Zähler

    Standardmäßig aktualisiert das Always On-Dashboard die Größe der Redo-Warteschlange (KB) und die Redo-Rate (KB/s) alle 60 Sekunden automatisch.

    Screenshot mit Aktualisierungszählern, die auf alle 60 Sekunden festgelegt sind.

Überprüfen Sie die Wiederherstellungswarteschlange im Leistungsmonitor

Jedes sekundäre Replikat und jede Datenbank verfügt über eine eigene Größe der Wiederherstellungswarteschlange. Führen Sie die folgenden Schritte aus, um die Wiederherstellungswarteschlange für eine Verfügbarkeitsgruppendatenbank zu überprüfen:

  1. Öffnen Sie den Leistungsmonitor auf dem sekundären Replikat.

  2. Wählen Sie die Schaltfläche "Hinzufügen " (Zähler) aus.

  3. Wählen Sie unter Verfügbare LeistungsindikatorenSQLServer:Database Replica aus und anschließend die Leistungsindikatoren Recovery Queue und Redone Bytes/sec.

  4. Wählen Sie im Listenfeld "Instanz " die Verfügbarkeitsgruppendatenbank aus, die Sie für die Wiederherstellungswarteschlange überwachen möchten.

  5. Klicken Sie auf Hinzufügen>OK.

    So könnte die Erhöhung der Wiederherstellungswarteschlange aussehen.

    Screenshot, der einen Anstieg der Warteschlangenbildung bei der Wiederherstellung zeigt.

Werte der Wiederherstellungswarteschlange interpretieren

In diesem Abschnitt wird erläutert, wie Sie die im vorherigen Abschnitt gesammelten Wiederherstellungswarteschlangenwerte interpretieren.

Wenn die Wiederherstellungswarteschlange ein Problem darstellt

Ein Wert der Wiederherstellungswarteschlange von 0 bedeutet, dass zum Zeitpunkt des Berichts kein Redo-Rückstand vorliegt. In einer ausgelasteten Produktionsumgebung meldet die Wiederherstellungswarteschlange häufig einen Wert ungleich Null, auch wenn die Verfügbarkeitsgruppe fehlerfrei ist. Während der typischen Produktion erwarten Sie, dass der Wert zwischen 0 und einem Wert ungleich Null schwankt.

Wenn die Wiederherstellungswarteschlange im Laufe der Zeit wächst, untersuchen Sie dies weiter. Wachstum zeigt an, dass sich etwas geändert hat. Wenn plötzliches Wachstum angezeigt wird, sind die folgenden Messungen für die Problembehandlung nützlich:

  • Rate der Protokollwiederholung (KB/s) (Always On-Dashboard)
  • redo_rate in sys.dm_hadr_database_replica_states

Basis-Wiederherstellungsraten festlegen

Überwachen Sie bei ordnungsgemäßer Always On-Leistung die Redo-Rate Ihrer stark ausgelasteten Verfügbarkeitsgruppendatenbanken. Erfassen Sie die Durchsatzraten während typischer Geschäftszeiten sowie in Wartungsfenstern, wenn große Transaktionen (z. B. der Neuaufbau von Indizes oder ETL-Prozesse) für einen höheren Durchsatz sorgen. Vergleichen Sie diese Basiswerte, wenn Sie ein Wachstum der Wiederherstellungswarteschlange feststellen, um zu ermitteln, was sich geändert hat. Die Arbeitsauslastung kann größer als üblich sein, oder die Wiederholungsrate ist niedriger als erwartet, was weitere Untersuchungen erfordert.

Workload-Volumen berücksichtigen

Hohe Arbeitslasten (wie etwa eine UPDATE-Anweisung für eine Million Zeilen, der Neuaufbau eines Indexes für eine 1 TB große Tabelle oder ein ETL-Batch, der Millionen von Zeilen einfügt) führen in der Regel zu einem gewissen Anwachsen der Wiederherstellungswarteschlange, entweder sofort oder im Laufe der Zeit. Dieses Wachstum wird erwartet, wenn in der Verfügbarkeitsgruppendatenbank plötzlich viele Änderungen vorgenommen werden.

Diagnose der Wiederherstellungswarteschlange

Nachdem Sie die Wiederherstellungswarteschlange für eine bestimmte Datenbank einer Verfügbarkeitsgruppe auf einem sekundären Replikat identifiziert haben, stellen Sie eine Verbindung mit dem sekundären Replikat her, und fragen Sie dann sys.dm_exec_requests ab, um die wait_type und wait_time für Wiederherstellungsthreads zu überprüfen. Sie suchen nach einer hohen Häufigkeit von mindestens einem Wartetyp und großen Wartezeiten für diese Wartetypen. Die folgende Beispielabfrage wird alle fünf Sekunden ausgeführt und meldet Wartetypen und Wartezeiten für die Verfügbarkeitsgruppendatenbank agdb:

WHILE (1=1)
BEGIN
SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')
waitfor delay '00:00:05.000'
END

Wichtig

Für eine aussagekräftige Ausgabe zum Wartetyp sollte die Wiederherstellungswarteschlange anwachsen, wenn Sie diese Daten mit einer der zuvor beschriebenen Methoden erfassen.

Im folgenden Beispiel werden einige E/A-bezogene Wartetypen gemeldet (PAGEIOLATCH_UP, PAGEIOLATCH_EX). Überwachen Sie, ob diese Wartetypen weiterhin die größten wait_time Werte anzeigen, wie in der nächsten Spalte angegeben.

Screenshot der größten Wartezeiten, die in der nächsten Spalte gemeldet wurden.

Identifizieren von Wiederherstellungswartetypen

Nachdem Sie einen Wartetyp identifiziert haben, verwenden Sie das sekundäre Replikatwiederherstellungsmodell und die Leistung der Verfügbarkeitsgruppe als Querverweis für allgemeine Wartetypen, die eine Wiederherstellungswarteschlange verursachen, und anleitungen zum Beheben des Problems.

Blockierte Wiederherstellungsthreads auf schreibgeschützten sekundären Replikaten

Wenn Ihre Lösung Berichtsabfragen (Abfragen) an Verfügbarkeitsgruppendatenbanken auf einem sekundären Replikat richtet, erwerben diese schreibgeschützten Abfragen Schema-Stabilitätssperren (Sch-S). Sch-S-Sperren können Redo-Threads daran hindern, Schemamodifikationssperren (Sch-M) zu erwerben, die auch als Schemaänderungssperren oder LCK_M_SCH_M bezeichnet werden und zum Anwenden von Änderungen der Datendefinitionssprache (DDL) wie ALTER TABLE oder ALTER INDEX erforderlich sind. Ein blockierter Redo-Thread kann Protokolldatensätze erst verarbeiten, wenn er wieder entsperrt wird, was zu einem Rückstau bei der Wiederherstellung führt.

Öffnen Sie die AlwaysOn_health Ablaufverfolgungsdateien für erweiterte Ereignisse im sekundären Replikat mithilfe von SSMS, um nach historischen Nachweisen eines blockierten Wiederholens zu suchen. Suchen Sie nach lock_redo_blocked Ereignissen.

Screenshot, der die Überprüfung auf historische Belege für einen blockierten Redo-Vorgang zeigt.

Verwenden Sie Leistungsmonitor, um die Auswirkungen blockierter Wiederholungsvorgänge auf die Wiederherstellungswarteschlange aktiv zu überwachen. Fügen Sie die SQL Server:Database Replica\Redo blocked/sec- und SQL Server:Database Replica\Recovery Queue-Leistungsindikatoren hinzu. Der folgende Screenshot zeigt ein ALTER TABLE ALTER COLUMN-Kommando, das gegen die primäre Replik ausgeführt wird, während auf derselben Tabelle auf der sekundären Replik eine lang andauernde Abfrage ausgeführt wird. Der Zähler Redo-Blockierungen/Sek. erreicht Spitzenwerte, wenn der ALTER TABLE ALTER COLUMNBefehl ausgeführt wird. Während die lang andauernde Abfrage für dieselbe Tabelle auf dem sekundären Replikat aktiv ist, vergrößern alle nachfolgenden Änderungen auf dem Primärreplikat die Wiederherstellungswarteschlange.

Screenshot eines Monitors für den Wartetyp der Schemaänderungssperre.

Überwachen Sie den Wartetyp für die Schemaränderungssperre, den der Redo-Thread zu erwerben versucht. Verwenden Sie die vorherige Abfrage, um die in sys.dm_exec_requests für Redo-Vorgänge gemeldeten Wartetypen zu überprüfen. Sie können sehen, wie die Wartezeit für LCK_M_SCH_M ansteigt, während das Redo blockiert ist.

Screenshot, der die zunehmende Wartezeit für LCK_M_SCH_M zeigt.

Single-Thread-Wiederherstellung

SQL Server 2016 führte die parallele Wiederherstellung für Datenbanken sekundärer Replikate ein. Wenn Sie eine frühere Version ausführen, z. B. SQL Server 2014 oder SQL Server 2012, führen Sie ein Upgrade auf eine unterstützte Version durch, um paralleles Wiederholen und verbesserte Redo-Leistung zu erhalten.

Single-Thread-Redo kann auch in SQL Server 2016 bis SQL Server 2019 auftreten, die die Architektur der parallelen Wiederherstellung verwenden. In diesen Versionen kann eine SQL Server Instanz bis zu 100 Threads für parallele Wiederholungen verwenden. Das System weist den Datenbanken der Verfügbarkeitsgruppe parallele Redo-Threads basierend auf der Anzahl der Prozessoren und Datenbanken zu, bis zu insgesamt 100 Threads. Wenn die 100-Thread-Grenze erreicht ist, weist das System einigen Datenbanken in der Verfügbarkeitsgruppe einen einzelnen Wiederholungsthread zu.

Um zu überprüfen, ob ihre Verfügbarkeitsgruppendatenbank parallele Wiederherstellung verwendet, stellen Sie eine Verbindung mit dem sekundären Replikat her, und führen Sie die folgende Abfrage aus, um die Zeilen (Threads) zu zählen, die die Wiederherstellung für die Datenbank anwenden. Im folgenden Beispiel kann die Wiederherstellungsauslastung von paralleler Wiederherstellung profitieren, wenn die agdb Datenbank über eine einzelne Zeile und den zugehörigen Befehl verfügt DB STARTUP.

SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN ('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')

Screenshot, der zeigt, wie Sie ermitteln können, ob ihre Verfügbarkeitsgruppendatenbank parallele Wiederherstellung verwendet.

Wenn Ihre Datenbank Single-Thread-Redo verwendet, prüfen Sie anhand des zuvor beschriebenen Algorithmus, ob SQL Server die 100 für die parallele Wiederherstellung vorgesehenen Workerthreads überschreitet. Das Erreichen dieser Grenze kann der Grund dafür sein, dass agdb nur einen einzigen Redo-Thread verwendet.

SQL Server 2022 und höher verwenden einen parallelen Wiederherstellungsalgorithmus, der Workerthreads basierend auf der Arbeitslast zuweist, wodurch verhindert wird, dass eine ausgelastete Datenbank beim Single-Thread-Redo verbleibt. Weitere Informationen finden Sie im Abschnitt Threadverwendung nach Verfügbarkeitsgruppen von „Voraussetzungen, Einschränkungen und Empfehlungen für Always On-Verfügbarkeitsgruppen“.

Verwandte Inhalte

  • Last updated on