Problembehandlung bei der Wiederherstellungswarteschlange in einer Always On Verfügbarkeitsgruppe

  • Artikel

Dieser Artikel enthält Lösungen für Probleme im Zusammenhang mit der Wiederherstellungswarteschlange.

Was ist Wiederherstellungswarteschlange?

Änderungen, die am primären Replikat in einer Verfügbarkeitsgruppendatenbank vorgenommen werden, werden an alle sekundären Replikate gesendet, die in derselben Verfügbarkeitsgruppe definiert sind. Nachdem diese Änderungen bei den sekundären Replikaten eintreffen, werden sie zuerst in die Transaktionsprotokolldatei der Verfügbarkeitsgruppendatenbank geschrieben. Microsoft SQL Server verwendet dann den Wiederherstellungs- oder Wiederholungsvorgang, um die Datenbankdateien zu aktualisieren.

Wenn die Änderungen an einer Verfügbarkeitsgruppe eintreffen und in der Datenbanktransaktionsprotokolldatei schneller als wiederhergestellt werden können, wird eine Wiederherstellungswarteschlange gebildet. Diese Warteschlange besteht aus gehärteten Transaktionsprotokolltransaktionen, die nicht wiederhergestellt und in der Datenbank wiederhergestellt wurden.

Symptome und Auswirkungen der Wiederherstellung (Wiederholung) in der Warteschlange

Das Abfragen von primären und sekundären Replikaten gibt unterschiedliche Ergebnisse zurück.

Schreibgeschützte Workloads, die sekundäre Replikate abfragen, können veraltete Daten abfragen. Wenn eine Wiederherstellungswarteschlange ausgeführt wird, werden Änderungen an Daten in der primären Replikatdatenbank möglicherweise nicht in der sekundären Datenbank wider, wenn Sie dieselben Daten abfragen.

Obwohl Änderungen in der sekundären Datenbank eintreffen und in die Datenbankprotokolldatei geschrieben werden, werden die Änderungen erst abgefragt, wenn sie wiederhergestellt und in den Datenbankdateien wiederhergestellt wurden. Der Wiederherstellungsvorgang macht diese Änderungen lesbar.

Weitere Informationen finden Sie im Abschnitt "Datenlatenz auf sekundären Replikaten" von "Unterschiede zwischen Verfügbarkeitsmodi für eine Always On Verfügbarkeitsgruppe".

Die Failoverzeit ist länger, oder die RTO wird überschritten.

Recovery Time Objective (RTO) ist die maximale Datenbankausfallzeit, die ein organization verarbeiten kann. RTO beschreibt auch, wie schnell die organization nach einem Ausfall wieder zugriff auf die Datenbank erhalten kann. Wenn bei einem Failover eine erhebliche Wiederherstellungswarteschlange auf einem sekundären Replikat vorhanden ist, kann die Wiederherstellung länger dauern. Nach der Wiederherstellung wechselt die Datenbank in die primäre Rolle und stellt den Zustand der Datenbank dar, die vor dem Failover vorhanden war. Eine längere Wiederherstellungszeit kann verzögern, wie schnell die Produktion nach einem Failover fortgesetzt wird.

Verschiedene Diagnosefeatures melden verfügbarkeitsgruppenwiederherstellung in der Warteschlange

Im Falle der Wiederherstellungswarteschlange meldet die Always On Dashboard in SQL Server Management Studio (SSMS) möglicherweise eine fehlerhafte Verfügbarkeitsgruppe.

Überprüfen auf Wiederherstellungswarteschlange (Wiederholen)

Die Wiederherstellungswarteschlange ist eine datenbankspezifische Messung, die mithilfe der Always On Dashboard auf dem primären Replikat oder mithilfe der sys.dm_hadr_database_replica_states Dynamische Verwaltungssicht (Dynamic Management View, DMV) auf dem primären oder sekundären Replikat überprüft werden kann. Leistungsmonitor Leistungsindikatoren überprüfen die Wiederherstellungswarteschlange und die Wiederherstellungsrate. Diese Leistungsindikatoren müssen anhand des sekundären Replikats überprüft werden.

In den nächsten Abschnitten finden Sie Methoden zum aktiven Überwachen ihrer Wiederherstellungswarteschlange für Die Verfügbarkeitsgruppendatenbank.

Sys.dm_hadr_database_replica_states abfragen

Die sys.dm_hadr_database_replica_states DMV meldet eine Zeile für jede Verfügbarkeitsgruppendatenbank. Eine Spalte im Bericht ist redo_queue_size. Dieser Wert ist die Größe der Wiederherstellungswarteschlange, gemessen in Kilobyte. Sie können eine Abfrage einrichten, die der folgenden Abfrage ähnelt, um alle 30 Sekunden einen beliebigen Trend in der Größe der Wiederherstellungswarteschlange zu überwachen. Die Abfrage wird auf dem primären Replikat ausgeführt. Es verwendet das is_local=0 Prädikat, um die 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, in der die Daten für das sekundäre Replikat gemeldet werden, in denen redo_queue_size und redo_rate relevant sind.

Überprüfen der Wiederherstellungswarteschlange in Always On Dashboard

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

  1. Öffnen Sie das Always On-Dashboard in SSMS, indem Sie mit der rechten Maustaste auf eine Verfügbarkeitsgruppe in SSMS Objekt-Explorer klicken.

  2. Wählen Sie Dashboard anzeigen aus.

    Die Verfügbarkeitsgruppendatenbanken werden zuletzt aufgelistet, und es werden einige Daten für die Datenbanken gemeldet. Obwohl Redo Queue Size (KB) und Redo Rate (KB/s) standardmäßig nicht aufgeführt sind, können Sie sie dieser Ansicht hinzufügen, wie im Screenshot im nächsten Schritt gezeigt.

  3. Klicken Sie zum Hinzufügen dieser Indikatoren mit der rechten Maustaste auf die Kopfzeile oberhalb der Datenbankberichte, und wählen Sie aus der Liste der verfügbaren Spalten aus.

  4. Um die Größe der Wiederholungswarteschlange (KB) und die Wiederholungsrate (KB/s) hinzuzufügen, klicken Sie mit der rechten Maustaste auf die Kopfzeile, die im folgenden Screenshot rot hervorgehoben ist.

    Screenshot: Hinzufügen der Leistungsindikatoren Größe der Wiederholungswarteschlange (KB) und Wiederholungsrate (KB/s)

    Standardmäßig aktualisiert der Always On Dashboard automatisch alle 60 Sekunden die Größe der Wiederholungswarteschlange (KB) und die Wiederholungsrate (KB/s).

    Screenshot: Aktualisierungsindikatoren, die alle 60 Sekunden festgelegt sind

Überprüfen der Wiederherstellungswarteschlange in Leistungsmonitor

Die Größe der Wiederherstellungswarteschlange ist für jedes sekundäre Replikat und jede sekundäre Datenbank eindeutig. Führen Sie daher die folgenden Schritte aus, um die Wiederherstellungswarteschlange einer Verfügbarkeitsgruppendatenbank zu überprüfen:

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

  2. Wählen Sie die Schaltfläche Hinzufügen (Indikator) aus.

  3. Wählen Sie unter Verfügbare Leistungsindikatorendie Option SQLServer:Datenbankreplikat und dann Wiederherstellungswarteschlange und Bytes/Sekunde erneut aus.

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

  5. Wählen Sie Hinzufügen>OK aus.

    Hier sehen Sie, wie eine zunehmende Wiederherstellungswarteschlange aussehen könnte.

    Screenshot: Zunahme der Wiederherstellungswarteschlange

Interpretieren von Werten für die Wiederherstellungswarteschlange

In diesem Abschnitt wird erläutert, wie Sie die Werte interpretieren können, die sich auf die Im vorherigen Abschnitt ermittelte Wiederherstellungswarteschlange beziehen.

Wann ist die Wiederherstellungswarteschlange ein Problem? Wie viel Wiederherstellungswarteschlange sollten Sie tolerieren?

Sie können davon ausgehen, dass, wenn die Wiederherstellungswarteschlange den Wert 0 meldet, bedeutet dies, dass zum Zeitpunkt dieses Berichts keine Wiederherstellungswarteschlange stattfindet. Wenn Ihre Produktionsumgebung jedoch ausgelastet ist, sollten Sie davon ausgehen, dass die Wiederherstellungswarteschlange auch in einer fehlerfreien AlwaysOn-Umgebung häufig einen anderen Wert als 0 meldet. Während der typischen Produktion sollten Sie davon ausgehen, dass dieser Wert zwischen 0 und einem Wert ungleich 0 schwankt.

Wenn Sie beobachten, dass die Wiederherstellungswarteschlange im Laufe der Zeit immer größer wird, ist eine weitere Untersuchung erforderlich. Diese zusätzliche Aktivität gibt an, dass sich etwas geändert hat. Wenn Sie ein plötzliches Wachstum in der Wiederherstellungswarteschlange feststellen, sind die folgenden Messungen für die Problembehandlung nützlich:

  • Protokollwiederherstellungsrate (KB/s) (AlwaysOn-Dashboard)
  • Redo_rate im DMV-sys.dm_hadr_database_replica_states

Abrufen der Baselineraten für die Wiederholungsrate

Überwachen Sie während einer fehlerfreien AlwaysOn-Leistung die Wiederholungsrate für Ihre ausgelasteten Verfügbarkeitsgruppendatenbanken. Wie sehen sie während der üblicherweise ausgelasteten Geschäftszeiten aus? Wie hoch sind diese Raten in Wartungszeiten, wenn große Transaktionen (Indexneuerstellungen, ETL-Prozesse) einen höheren Transaktionsdurchsatz auf dem System ermöglichen? Sie können diese Werte vergleichen, wenn Sie das Wachstum der Wiederherstellungswarteschlange beobachten, um festzustellen, was sich geändert hat. Die Workload ist möglicherweise größer als üblich. Wenn die Wiederholungsrate niedriger ist, ist möglicherweise eine weitere Untersuchung erforderlich, um den Grund zu ermitteln.

Workloadvolumes wichtig

Wenn Sie über große Workloads verfügen (z. B. eine UPDATE-Anweisung für eine Million Zeilen, eine Indexneuerstellung für eine 1 Terabyte-Tabelle oder sogar einen ETL-Batch, der Millionen von Zeilen einfügt), sollten Sie mit einem gewissen Wachstum der Wiederherstellungswarteschlange rechnen, entweder sofort oder im Laufe der Zeit. Dies wird erwartet, wenn plötzlich eine große Anzahl von Änderungen in der Verfügbarkeitsgruppendatenbank vorgenommen wird.

Diagnostizieren der Warteschlange für die Wiederherstellung (Wiederholen)

Nachdem Sie die Wiederherstellungswarteschlange für eine bestimmte Verfügbarkeitsgruppendatenbank für sekundäre Replikate identifiziert haben, stellen Sie eine Verbindung mit dem sekundären Replikat her, und fragen Sie dann ab sys.dm_exec_requests , um die wait_type Wiederherstellungsthreads und wait_time zu ermitteln. Hier sehen Sie eine Abfrage, die in einer Schleife ausgeführt werden kann. Sie suchen nach einer hohen Häufigkeit von mindestens einem Wartetyp und sogar nach Wartezeiten für diese Wartetypen. Hier sehen Sie eine Beispielabfrage, die jede Sekunde ausgeführt wird und die Wartetypen und Wartezeiten für die Verfügbarkeitsgruppe "agdb" meldet:

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 sinnvolle Ausgabe des Wartetyps sollte beobachtet werden, dass die Wiederherstellungswarteschlange zunimmt, wenn Sie eine der zuvor beschriebenen Methoden verwenden, um diese Bedingung zu überwachen.

In diesem Beispiel werden einige E/A-bezogene Wartetypen gemeldet (PAGEIOLATCH_UP, PAGEIOATCH_EX). Überwachen Sie, um zu überprüfen, ob diese Wartetypen weiterhin die größten wait_times Werte aufweisen, wie in der nächsten Spalte angegeben.

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

SQL Server Typen von Wiederholungswartevorgängen

Wenn ein Wartetyp identifiziert wird, lesen Sie den folgenden Artikel SQL Server 2016/2017: Wiederholungsmodell und Leistung des sekundären Replikats für Verfügbarkeitsgruppen– Microsoft Tech Community als Querverweis für gängige Wartetypen, die eine Wiederherstellungswarteschlange verursachen, und hilfe beim Beheben des Problems.

Blockierte Wiederholungsthreads auf sekundären Berichtsservern

Wenn Ihre Lösung die Berichterstellung (Abfragen) für Verfügbarkeitsgruppendatenbanken auf dem sekundären Replikat leitet, erhalten diese schreibgeschützten Abfragen Schemastabilitätssperren (Sch-S). Diese Sch-S-Sperren können Redothreads daran hindern, Schemaänderungssperren (Sch-M) abzurufen (auch als "Schemaänderungssperren" oder LCK_M_SCH_Mbezeichnet), um Änderungen an der Datendefinitionssprache (Data Definition Language, DDL) vorzunehmen, z ALTER TABLE . B. oder ALTER INDEX. Ein blockierter Wiederholungsthread kann keine Protokolldatensätze anwenden, bis er die Blockierung aufgehoben hat. Dies kann zu einer Wiederherstellungswarteschlange führen.

Öffnen Sie die AlwaysOn_health Xevent-Ablaufverfolgungsdateien auf dem sekundären Replikat mithilfe von SSMS, um nach verlaufsbezogenen Beweisen für eine blockierte Wiederholung zu suchen. Suchen lock_redo_blocked Sie nach Ereignissen.

Screenshot, der die Überprüfung auf historische Beweise für eine blockierte Wiederholung zeigt.

Verwenden Sie Leistungsmonitor, um die Auswirkungen blockierter Wiederholungen auf die Wiederherstellungswarteschlange aktiv zu überwachen. Fügen Sie die Leistungsindikatoren SQL Server::D atabase Replica::Redo blocked/sec und SQL Server::D atabase Replica::Recovery Queue hinzu. Der folgende Screenshot zeigt einen ALTER TABLE ALTER COLUMN Befehl, der für das primäre Replikat ausgeführt wird, während eine Abfrage mit langer Ausführungsdauer für dieselbe Tabelle auf dem sekundären Replikat ausgeführt wird. Der Zähler Wiederholungsblockierung/Sekunde gibt an, dass der ALTER TABLE ALTER COLUMN Befehl ausgeführt wird. Während die Abfrage mit langer Ausführungsdauer in derselben Tabelle auf dem sekundären Replikat ausgeführt wird, führen alle nachfolgenden Änderungen am primären Replikat zu einer Erhöhung der Wiederherstellungswarteschlange.

Screenshot: Monitor für den Wartetyp der Schemaänderungssperre

Überwachen Sie den Wartetyp der Schemaänderungssperre, den der Wiederholungsthread abzurufen versucht. Verwenden Sie dazu die zuvor beschriebene Abfrage, um die Wartetypen zu überprüfen, die für Wiederholungsvorgänge sys.dm_exec_requestsfür gemeldet werden. Sie können die zunehmende Wartezeit für die LCK_M_SCH_M in der laufenden Wiederholungsblockierung beobachten.

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

Singlethread-Wiederholung

SQL Server die parallele Wiederherstellung für sekundäre Replikatdatenbanken in Microsoft SQL Server 2016 eingeführt. Wenn beim Ausführen von SQL Microsoft Server 2012 oder Microsoft SQL Server 2014 Wiederherstellungswarteschlangen auftreten, können Sie ein Upgrade auf eine höhere Version des Programms durchführen, um die Wiederholungsleistung in Ihrer Produktionsumgebung zu verbessern.

Eine Singlethread-Wiederholung kann auch in späteren, fortgeschritteneren SQL Server Versionen erfolgen, in denen eine parallele Wiederherstellungsarchitektur verwendet wird. In diesen Versionen kann ein SQL Server instance bis zu 100 Threads für eine parallele Wiederholung verwenden. Abhängig von der Anzahl der Prozessoren und Verfügbarkeitsgruppendatenbanken werden parallele Wiederholungsthreads bis zu maximal 100 Threads insgesamt zugeordnet. Wenn der 100-Thread-Wiederholungsgrenzwert erreicht wird, wird einigen Datenbanken in der Verfügbarkeitsgruppe ein einzelner Wiederholungsthread zugewiesen.

Um zu bestimmen, ob ihre Verfügbarkeitsgruppendatenbank die parallele Wiederherstellung verwendet, stellen Sie eine Verbindung mit dem sekundären Replikat her, und verwenden Sie die folgende Abfrage, um die Anzahl der Zeilen (Threads) zu bestimmen, die die Wiederherstellung für die Verfügbarkeitsgruppendatenbank anwenden. Wenn es sich bei der Datenbank "agdb" im folgenden Beispiel um einen einzelnen Thread handelt und ihr Befehl lautet DB STARTUP, kann die Wiederherstellungsworkload von der parallelen Wiederherstellung profitieren.

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 die parallele Wiederherstellung verwendet.

Wenn Sie überprüfen, ob Ihre Datenbank eine Singlethread-Wiederholung verwendet, überprüfen Sie den zuvor beschriebenen Algorithmus, um festzustellen, ob SQL Server die Anzahl von 100 Arbeitsthreads überschreitet, die für die parallele Wiederherstellung vorgesehen sind. Eine solche Bedingung kann der Grund dafür sein, dass die Datenbank "agdb" nur einen einzelnen Thread für die Wiederherstellung verwendet.

SQL Server 2022 verwendet jetzt einen neuen parallelen Wiederherstellungsalgorithmus, sodass Arbeitsthreads für die parallele Wiederherstellung basierend auf der Workload zugewiesen werden. Dadurch entfällt die Chance, dass eine ausgelastete Datenbank in einer Singlethread-Wiederherstellung verbleibt. Weitere Informationen finden Sie im Abschnitt Threadverwendung nach Verfügbarkeitsgruppen von "Voraussetzungen, Einschränkungen und Empfehlungen für Always On Verfügbarkeitsgruppen".