Verbesserte Wiederherstellung von Datenbanken
Gilt für: 
SQL Server 2019 (15.x) und höhere Versionen Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics
Durch die beschleunigte Datenbankwiederherstellung (Accelerated Database Recovery, ADR) wird die Verfügbarkeit von Datenbanken enorm verbessert, insbesondere bei zeitintensiven Transaktionen. Hierfür wurde der Wiederherstellungsprozess der SQL-Datenbank-Engine vollständig überarbeitet.
ADR ist in SQL Server 2019 (15.x) neu und in SQL Server 2022 (16.x) verbessert. ADR ist auch für Datenbanken in Azure SQL-Datenbank, Azure SQL Managed Instance und Azure Synapse SQL verfügbar. ADR ist in SQL-Datenbank und SQL Managed Instance standardmäßig aktiviert und kann nicht deaktiviert werden. Weitere Informationen zu ADR in Azure SQL finden Sie unter Beschleunigte Datenbankwiederherstellung in Azure SQL.
Dieser Artikel bietet eine Übersicht über die ADR-Funktion. Mehr über die Arbeit mit ADR finden Sie unter Verwalten der beschleunigten Datenbankwiederherstellung.
Übersicht
Die Hauptvorteile der schnellen Datenbankwiederherstellung sind:
Schnelle und konsistente Datenbankwiederherstellung
Mit ADR haben zeitintensive Transaktionen keinen Einfluss auf die gesamte Wiederherstellungszeit und ermöglichen eine schnelle und konsistente Wiederherstellung der Datenbank, unabhängig von der Anzahl der aktiven Transaktionen im System und deren Größe.
Sofortiges Transaktionsrollback
Mit ADR erfolgt das Transaktionsrollback sofort, unabhängig davon, wann die Transaktion aktiv war oder wie viele Updates ausgeführt wurden.
Drastische Protokollkürzung
Durch ADR wird das Transaktionsprotokoll auch bei aktiven, zeitintensiven Transaktionen konsequent verkürzt, sodass der Vorgang kontrollierbar bleibt.
Der aktuelle Prozess zur Datenbankwiederherstellung
Ohne ADR folgt die Datenbankwiederherstellung in SQL Server dem ARIES-Wiederherstellungsmodell, der aus drei Phasen besteht. Diese werden im folgenden Diagramm dargestellt und anschließend näher erläutert.
Die Analysephase
SQL Server führt einen Vorwärtsscan des Transaktionsprotokolls vom Beginn des letzten erfolgreichen Prüfpunkts (oder der LSN der letzten fehlerhaften Seite) bis zum Ende durch, um den Zustand jeder Transaktion zu dem Zeitpunkt zu bestimmen, an dem SQL Server angehalten wurde.
Die Rollforwardphase
SQL Server führt einen Vorwärtsscan des Transaktionsprotokolls von der ältesten Transaktion ohne Commit bis zum Ende durch, um die Datenbank in den Zustand zu versetzen, in dem sie sich zum Zeitpunkt des Absturzes befand. Hierzu werden alle bestätigten Vorgänge noch mal ausgeführt.
Die Rollbackphase
Für jede Transaktion, die zum Zeitpunkt des Absturzes aktiv war, durchläuft SQL Server das Protokoll rückwärts und macht die Vorgänge rückgängig, die die jeweilige Transaktion ausgeführt hat.
Hiervon ausgehend ist die Zeitspanne, die die Datenbank-Engine für die Wiederherstellung nach einem unerwarteten Neustart benötigt, (ungefähr) proportional zum Umfang der längsten aktiven Transaktion im System zum Zeitpunkt des Absturzes. Die Wiederherstellung erfordert ein Rollback aller unvollständigen Transaktionen. Die erforderliche Zeitspanne verhält sich proportional zum Umfang der von der Transaktion ausgeführten Aufgaben und der Dauer ihrer Aktivität. Daher kann der SQL Server-Wiederherstellungsprozess bei zeitintensiven Transaktionen (z.B. umfangreiche Vorgänge bei Masseneinfügungen und Indexerstellungen für eine große Tabelle) sehr lange dauern.
Auch das Abbrechen oder Rollback einer umfangreichen Transaktion, die auf diesem Konzept basiert, kann ebenfalls lange dauern, da die gleiche Rollback- und Wiederherstellungsphase wie oben beschrieben durchlaufen wird.
Darüber hinaus kann die Datenbank-Engine das Transaktionsprotokoll bei zeitintensiven Transaktionen nicht abschneiden, da die entsprechenden Protokolldatensätze für die Wiederherstellungs- und Rollbackprozesse benötigt werden. Infolgedessen werden einige Transaktionsprotokolle sehr groß und belegen extrem viel Speicherplatz.
Der schnellere Prozess der Datenbankwiederherstellung
ADR löst die oben genannten Probleme, indem es den Wiederherstellungsprozess der Datenbank-Engine komplett neu gestaltet:
- Wählen Sie eine konstante Zeit bzw. die umgehende Wiederherstellung, indem Sie vermeiden, dass das Protokoll vom/zum Anfang der ältesten aktiven Transaktion gescannt werden muss. Mit ADR wird das Transaktionsprotokoll nur ab dem letzten erfolgreichen Prüfpunkt (oder der Protokollfolgenummer (LSN) der ältesten fehlerhaften Seite) verarbeitet. Dadurch wird die Wiederherstellungszeit nicht durch zeitintensive Transaktionen beeinflusst.
- Minimieren Sie den erforderlichen Speicherplatz für das Transaktionsprotokoll, da das Protokoll für die gesamte Transaktion nicht mehr verarbeitet werden muss. Folglich kann das Transaktionsprotokoll beim Auftreten von Prüfpunkten und Sicherungen konsequent abgeschnitten werden.
Im Allgemeinen wird mit ADR eine schnelle Datenbankwiederherstellung erreicht, da dieses Feature alle physischen Datenbankänderungen versioniert und nur logische Vorgänge rückgängig macht, die begrenzt sind und fast sofort rückgängig gemacht werden können. Alle Transaktionen, die zum Zeitpunkt eines Absturzes aktiv waren, werden als abgebrochen markiert, sodass alle durch diese Transaktionen erzeugten Versionen von gleichzeitigen Benutzerabfragen ignoriert werden können.
Die schnelle Datenbankwiederherstellung (ADR) besteht aus den gleichen drei Phasen wie der aktuelle Wiederherstellungsprozess. Der Ablauf dieser Phasen in Verbindung mit ADR ist in der folgenden Abbildung dargestellt.
Die Analysephase
Der Prozess bleibt derselbe, wird jedoch durch die Rekonstruktion von SLOG (System Log Stream, Systemprotokollstream) und das Kopieren von Protokolldatensätzen für nicht versionierte Vorgänge ergänzt.
Die Rollforwardphase
Diese Phase ist in zwei Teilphasen unterteilt:
Teilphase 1
Rollforward aus SLOG (älteste Transaktion ohne Commit bis zum letzten Prüfpunkt). Hierbei handelt es sich um einen schnellen Vorgang, da nur wenige Datensätze aus dem SLOG verarbeitet werden müssen.
Teilphase 2
Rollforward vom Transaktionsprotokoll beginnt beim letzten Prüfpunkt (anstelle der ältesten Transaktion ohne Commit).
Die Rollbackphase
Die Rollbackphase mit ADR wird nahezu unmittelbar abgeschlossen, indem unter Verwendung des SLOG versionierte Vorgänge und persistenter Versionsspeicher (Persisted Version Store, PVS) per logischer Wiederherstellung rückgängig gemacht werden, um ein versionsbasiertes Rollback auf Zeilenebene durchzuführen.
Sie können sich auch dieses 8-minütige Video ansehen, in dem die schnelle Datenbankwiederherstellung erklärt wird:
Komponenten der ADR-Wiederherstellung
Die vier wichtigsten Komponenten von ADR sind:
Persistenter Versionsspeicher (PVS)
Der persistente Versionsspeicher ist ein Datenbank-Engine-Mechanismus, mit dem die Zeilenversionen erhalten bleiben, die in der Datenbank selbst erstellt wurden, und nicht im herkömmlichen
tempdb-Versionsspeicher. Mithilfe des PVS lassen sich Ressourcen isolieren und die Verfügbarkeit von lesbaren sekundären Datenbanken verbessern. In SQL Server 2019 (15.x) gibt es einen PVS-Thread pro Instanz. Ab SQL Server 2022 (16.x) gibt es pro Datenbank einen PVS-Bereinigungsthread.Logische Wiederherstellung
Die logische Wiederherstellung ist der asynchrone Prozess, der für das versionsbasierte Rückgängigmachen auf Zeilenebene zuständig ist und somit ein unmittelbares Rollback und Zurücksetzen für alle versionierten Vorgänge ermöglicht.
- Verfolgt alle abgebrochenen Transaktionen
- Führt ein Rollback mit dem PVS für alle Benutzertransaktionen durch
- Gibt alle Sperren sofort nach Transaktionsabbruch frei
SLOG
Der SLOG (Secondary Log Stream) ist ein sekundärer In-Memory-Protokolldatenstrom, der Protokolldatensätze für nicht versionierte Vorgänge (wie z. B. die Invalidierung eines Metadatencache oder das Einrichten von Sperren) speichert. Merkmale des SLOG:
- Geringe Datenmenge und wenig Speicherbedarf
- Persistent auf Datenträgern durch Serialisierung während des Prüfpunktverfahrens
- Wird beim Commit von Transaktionen periodisch gekürzt
- Beschleunigt das Rollforward und Rollback durch ausschließliche Verarbeitung von nicht versionierten Vorgängen
- Ermöglicht ein konsequentes Abschneiden des Transaktionsprotokolls, wobei nur die erforderlichen Protokolldatensätze beibehalten werden
Bereinigung
Die Bereinigung ist ein asynchroner Prozess, der periodisch reaktiviert wird und nicht benötigte Seitenversionen bereinigt.
ADR-Verbesserungen in SQL Server 2022 (16.x)
Es wurden verschiedene Verbesserungen für den persistenten Versionsspeicher (PVS) sowie die Skalierbarkeit insgesamt vorgenommen. Weitere Informationen zu neuen Features von SQL Server 2022 (16.x) finden Sie unter Neuerungen in SQL Server 2022 (16.x).
Bereinigung von Benutzertransaktionen
Löschen Sie Seiten, die aufgrund eines Sperrfehlers durch den regulären Prozess nicht bereinigt werden konnten.
Mit diesem Feature können Benutzertransaktionen die Bereinigung auf Seiten ausführen, die aufgrund von Sperrkonflikten auf Tabellenebene nicht durch den regulären Bereinigungsprozess gelöscht werden konnten. Durch diese Verbesserung wird sichergestellt, dass der ADR-Bereinigungsprozess nicht unbegrenzt fehlerhaft ist, da Benutzerarbeitslasten keine Sperren auf Tabellenebene erwerben können.
Reduzieren des Speicherbedarfs für die PVS-Seitennachverfolgung
Diese Verbesserung verfolgt PVS-Seiten auf Ebene der horizontalen Datenbankpartition, um den Speicherbedarf zu verringern, der zum Verwalten von Seiten mit Versionsangabe erforderlich ist.
Verbesserungen bei der Bereinigung der beschleunigten Datenbankwiederherstellung (Accelerated Data Recovery, ADR)
Bei der beschleunigten Datenwiederherstellung (Accelerated Data Recovery, ADR) wurde die Effizienz der Versionsbereinigung verbessert, um die Art und Weise zu optimieren, in der SQL Server abgebrochene Versionen einer Seite nachverfolgt und aufzeichnet, was zu Verbesserungen bei Arbeitsspeicher und Kapazität führt.
Persistenter Versionsspeicher (PVS) auf Transaktionsebene
Diese Verbesserung ermöglicht es ADR, Versionen zu bereinigen, die zu Transaktionen mit Commit gehören, unabhängig davon, ob es abgebrochene Transaktionen im System gibt. Mit dieser Verbesserung kann die Zuordnung von PVS-Seiten aufgehoben werden, auch wenn die Bereinigung keinen erfolgreichen Sweepvorgang abschließen kann, um die Zuordnung der abgebrochenen Transaktion zu kürzen.
Das Ergebnis dieser Verbesserung ist ein geringeres Anwachsen des persistenten Versionsspeichers (PVS), auch wenn die ADR-Bereinigung langsam oder fehlerhaft ist.
Bereinigung von Versionen mit mehreren Threads
In SQL Server 2019 (15.x) verfügt der Bereinigungsprozess innerhalb einer SQL Server-Instanz nur über einen Thread.
Ab SQL Server 2022 (16.x) verwendet dieser Prozess eine Versionsbereinigung mit mehreren Threads. Dadurch können mehrere Datenbanken in derselben SQL Server-Instanz parallel bereinigt werden. Diese Verbesserung ist nützlich, wenn Sie über mehrere große Datenbanken verfügen.
Um die Anzahl der Threads für die Skalierbarkeit der Versionsbereinigung anzupassen, legen Sie
ADR Cleaner Thread Countaufsp_configurefest. Die Threadanzahl wird auf die Anzahl der Kerne für die Instanz begrenzt.Als optimale Vorgehensweise empfehlen wir, genau die Anzahl von ADR-Cleaner-Threads zu verwenden, die der Anzahl Ihrer Datenbanken entspricht. Wenn Sie z. B. die Konfiguration einer SQL Server-Instanz mit zwei Datenbanken für
ADR Cleaner Thread Countauf4festlegen, weist der ADR-Cleaner weiterhin nur einen Thread pro Datenbank zu, sodass die anderen zwei Threads im Leerlauf bleiben.Im folgenden Beispiel wird die Threadanzahl auf
4geändert:EXEC sp_configure 'ADR Cleaner Thread Count', '4'; RECONFIGURE WITH OVERRIDE;Neue erweiterte Ereignisse
Ein neues erweitertes Ereignis,
tx_mtvc2_sweep_stats, wurde für die Telemetrie auf dem ADR PVS Multi-Thread Version Cleaner hinzugefügt.
Bewährte Methoden und Anleitungen
Anleitungen zu Workloads, die für ADR empfohlen und nicht empfohlen werden, finden Sie unter Verwalten der schnelleren Datenbankwiederherstellung.
Wichtig
In Azure SQL-Datenbank werden Leerlauftransaktionen (Transaktionen, die für sechs Stunden nichts in das Transaktionsprotokoll geschrieben haben) automatisch beendet, um Ressourcen freizugeben.