Verbesserte Wiederherstellung von Datenbanken

Gilt für: SQL Server 2019 (15.x) und höhere Versionen Azure SQL-Datenbank Azure SQL verwaltete InstanzSQL-Datenbank in Microsoft Fabric

Die beschleunigte Datenbankwiederherstellung (ADR) verbessert die Verfügbarkeit der Datenbank, insbesondere bei langen Transaktionen, indem der Wiederherstellungsvorgang des Datenbankmoduls neu gestaltet wird.

ADR ist in SQL Server 2019 (15.x) neu und in SQL Server 2022 (16.x) verbessert. ADR ist auch in Azure SQL-Datenbank, azure SQL Managed Instance, Azure Synapse Analytics (nur dedizierter SQL-Pool) und SQL-Datenbank in Microsoft Fabric verfügbar.

Hinweis

ADR ist immer in Azure SQL-Datenbank, azure SQL Managed Instance und SQL-Datenbank in Fabric aktiviert.

Dieser Artikel enthält eine Übersicht über den ADR. Mehr über die Arbeit mit ADR finden Sie unter Verwalten der beschleunigten Datenbankwiederherstellung.

Weitere Informationen zur Transaktionsprotokoll- und Datenbankwiederherstellung finden Sie in SQL Server-Transaktionsprotokollarchitektur und -Verwaltungshandbuch und Übersicht über Wiederherstellung und Datenbankreparatur (SQL Server).

Übersicht

Die Hauptvorteile der schnellen Datenbankwiederherstellung sind:

• Schnelle und konsistente Datenbankwiederherstellung

  Lange ausgeführte Transaktionen wirken sich nicht auf die Gesamtwiederherstellungszeit aus, wodurch eine schnelle und konsistente Datenbankwiederherstellung unabhängig von der Anzahl der aktiven Transaktionen im System oder deren Größe ermöglicht wird.

• Sofortiges Transaktionsrollback

  Der Transaktionsrollback erfolgt sofort, unabhängig von dem Zeitpunkt, zu dem die Transaktion aktiv war, oder die Anzahl der vorgenommenen Aktualisierungen.

• Drastische Protokollkürzung

  Das Transaktionsprotokoll wird auch bei aktiven, zeitintensiven Transaktionen konsequent verkürzt, sodass der Vorgang kontrollierbar bleibt.

Der herkömmliche Datenbankwiederherstellungsprozess

Ohne ADR folgt die Datenbankwiederherstellung dem ARIES Wiederherstellungsmodell und besteht aus drei Phasen, die im folgenden Diagramm veranschaulicht und ausführlich erläutert werden:

• Die Analysephase

  Die Datenbank-Engine führt einen Vorwärts-Scan des Transaktionsprotokolls ab dem Beginn des letzten erfolgreichen Prüfpunkts (oder der ältesten modifizierten Seiten-Protokollfolgenummer (LSN)) bis zum Ende aus, um den Zustand jeder Transaktion zu dem Zeitpunkt zu ermitteln, an dem die Engine beendet wurde.

• Die Rollforwardphase

  Das Datenbank-Engine führt einen Vorwärtsscan des Transaktionsprotokolls von der ältesten nicht abgeschlossenen Transaktion bis zum Ende durch. Dieser Vorgang wiederholt alle abgeschlossenen Vorgänge, um den Zustand der Datenbank zum Zeitpunkt des Absturzes wiederherzustellen.

• Die Rollbackphase

  Für jede Transaktion, die zum Zeitpunkt des Absturzes aktiv war, durchläuft das Datenbankmodul das Protokoll rückwärts und macht die Vorgänge, die diese Transaktion ausgeführt hat, rückgängig.

• Mit dem herkömmlichen Datenbankwiederherstellungsprozess kann die Wiederherstellung nach einem Absturz lange dauern, wenn eine lange ausgeführte Transaktion aktiv war.

  Die Zeit für die Wiederherstellung des Datenbankmoduls von einem unerwarteten Neustart ist (ungefähr) proportional zur Größe 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.

• Das Abbrechen oder Zurücksetzen einer großen Transaktion kann viel Zeit in Anspruch nehmen, da sie dieselbe Rückgängig-Machungs-Wiederherstellungsphase verwendet wie zuvor beschrieben.

• Das Datenbankmodul kann das Transaktionsprotokoll nicht kürzen, wenn langlaufende Transaktionen vorhanden sind, da ihre entsprechenden Protokolldatensätze für die Wiederherstellungs- und Rollbackprozesse benötigt werden. Daher kann das Transaktionsprotokoll sehr groß sein und viel Speicherplatz verbrauchen.

Der schnellere Prozess der Datenbankwiederherstellung

ADR befasst sich mit früheren Problemen des herkömmlichen Wiederherstellungsmodells, indem der Wiederherstellungsprozess der Datenbank-Engine vollständig neu gestaltet wurde:

• Stellen Sie die Wiederherstellungszeit konstant fest, da es nicht mehr erforderlich ist, das Transaktionsprotokoll vom Anfang der ältesten aktiven Transaktion zu scannen. Mit ADR wird das Transaktionsprotokoll nur ab dem letzten erfolgreichen Prüfpunkt (oder der LSN der ältesten modifizierten Seite) verarbeitet. Daher ist die Wiederherstellungszeit nicht von lang andauernden Transaktionen betroffen und ist in der Regel sofort gegeben.

• Minimieren Sie den erforderlichen Transaktionsprotokollspeicher, da es nicht mehr erforderlich ist, das Protokoll für die gesamte Transaktion beizubehalten. Folglich kann das Transaktionsprotokoll beim Auftreten von Prüfpunkten und Sicherungen konsequent abgeschnitten werden.

Auf hoher Ebene erzielt ADR eine schnelle Datenbankwiederherstellung durch Versionsverwaltung aller physischen Datenbankänderungen und nur das Rückgängigmachen von nichtversionierten Vorgängen, die eingeschränkt 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.

Der ADR-Wiederherstellungsprozess hat die gleichen drei Phasen wie der herkömmliche Wiederherstellungsprozess. Die Funktionsweise dieser Phasen mit ADR wird im folgenden Diagramm veranschaulicht:

• Die Analysephase

  Der Prozess bleibt mit dem herkömmlichen Wiederherstellungsmodell identisch, mit der Ergänzung des Rekonstruierens des sekundären Protokolldatenstroms (SLOG) und des Kopierens von Protokolldatensätzen für nichtversionierte Vorgänge.

• Die Rollforwardphase

  Diese Phase ist in zwei Teilphasen unterteilt:

  • Teilphase 1

    Wiederholen vom SLOG (älteste Transaktion ohne Commit bis zum letzten Prüfpunkt). „Wiederholen“ ist ein schneller Vorgang, da er möglicherweise nur einige Datensätze aus dem SLOG verarbeiten muss.

  • Teilphase 2

    Wiederholen vom Transaktionsprotokoll beginnt beim letzten erfolgreichen Prüfpunkt (anstelle der ältesten Transaktion ohne Commit).

• Die Rollbackphase

  Die Rollbackphase mit ADR wird nahezu unmittelbar abgeschlossen, indem mithilfe von SLOG nicht versionierte Vorgänge und persistenter Versionsspeicher (Persisted Version Store, PVS) mithilfe logischer Wiederherstellung rückgängig gemacht werden, um ein versionsbasiertes Rollback auf Zeilenebene durchzuführen.

Eine Erläuterung der beschleunigten Datenbankwiederherstellung finden Sie in diesem achtminütigen Video:

Komponenten der ADR-Wiederherstellung

Die vier wichtigsten Komponenten von ADR sind:

• Persistenter Versionsspeicher (PVS)

  Der permanente Versionsspeicher (PVS) ist ein Datenbankmodulmechanismus zum Beibehalten von Zeilenversionen in der Datenbank selbst anstelle des herkömmlichen Versionsspeichers in der tempdb-Datenbank. Mithilfe des PVS lassen sich Ressourcen isolieren und die Verfügbarkeit von lesbaren sekundären Datenbanken verbessern.

  PVS speichert Zeilenversionen entweder direkt auf Datenseiten, die geändert werden, oder in einer separaten Systemtabelle. Weitere Informationen finden Sie unter Speicherplatz, der vom persistenten Versionsspeicher (PVS)verwendet wird.

• 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
  • Während des Prüfpunktprozesses auf dem Datenträger gespeichert
  • Wird beim Commit von Transaktionen periodisch gekürzt
  • Beschleunigt das Wiederholen und Rückgängigmachen 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.

Workloads, die von ADR profitieren

ADR ist besonders vorteilhaft für Workloads, die Folgendes haben:

• Lang laufende Transaktionen.
• Aktive Transaktionen, die dazu führen, dass das Transaktionsprotokoll erheblich zunimmt.
• Lange Ausfallzeiten der Datenbank aufgrund von lange andauernden Wiederherstellungsvorgängen (z. B. durch unerwarteten Dienstneustart oder manuelle Rückabwicklung einer Transaktion).

ADR wird in Datenbanken mit Datenbankspiegelung, einer älteren und veralteten Funktion für hohe Verfügbarkeit, nicht unterstützt.

Bewährte Methoden für ADR

• Vermeiden Sie unnötige lang andauernde Transaktionen. Obwohl ADR die Datenbankwiederherstellung auch bei langen Transaktionen beschleunigt, können solche Transaktionen die Versionsbereinigung verzögern und die Größe der PVS erhöhen.

• Vermeiden Sie große Transaktionen, die DDL-Vorgänge enthalten. ADR verwendet den mechanismus für den sekundären Protokolldatenstrom (SLOG), um DDL-Vorgänge nachzuverfolgen, die in der Wiederherstellung verwendet werden. SLOG wird nur verwendet, während die Transaktion aktiv ist. SLOG wird überprüft, sodass große Transaktionen, die SLOG verwenden, vermieden werden können, um die Gesamtleistung zu verbessern. Diese Szenarien können dazu führen, dass der SLOG mehr Speicherplatz benötigt:

  • Viele DDLs werden in einer Transaktion ausgeführt. Beispiel: In einer Transaktion werden schnell hintereinander temporäre Tabellen erstellt und gelöscht.
  • Eine Tabelle umfasst eine sehr große Anzahl von Partitionen/Indizes, die geändert werden. Beispielsweise würde eine DROP TABLE-Operation für eine solche Tabelle eine große Reservierung von SLOG-Speicher erfordern, wodurch sich das Abschneiden des Transaktionsprotokolls und die Ausführung von Vorgängen zum Rückgängigmachen/Wiederholen verzögern würde. Zur Umgehung dieses Problems löschen Sie die Indizes einzeln und nacheinander und löschen anschließend die Tabelle.

  Weitere Informationen zu SLOG finden Sie unter ADR-Wiederherstellungskomponenten.

• Verhindern oder reduzieren Sie unnötige abgebrochene Transaktionen. Eine hohe Transaktionsabbruchrate erhöht die Last für die PVS-Bereinigung und verringert die ADR-Leistung. Die Abbrüche können durch eine hohe Anzahl von Deadlocks, doppelte Schlüssel, Einschränkungsverletzungen oder Timeouts bei Abfragen verursacht werden. Im DMV sys.dm_tran_aborted_transactions werden alle abgebrochenen Transaktionen in der Datenbankmodul-Instanz angezeigt. Die Spalte nested_abort zeigt an, dass ein Commit der Transaktion durchgeführt wurde, aber einige Teile abgebrochen wurden (Sicherungspunkte oder geschachtelte Transaktionen), die den PVS-Bereinigungsprozess verzögern können.

• Stellen Sie sicher, dass genügend Speicherplatz in der Datenbank vorhanden ist, um die PVS-Nutzung zu berücksichtigen. Wenn die Datenbank nicht genügend Platz zum Vergrößern von PVS hat, kann ADR möglicherweise keine Versionen generieren, was dazu führt, dass DML-Anweisungen fehlschlagen.

• Wenn ADR mit schreibintensiven Workloads aktiviert ist, kann die Transaktionsprotokollgenerierungsrate erheblich steigen, da Zeilenversionen protokolliert werden, die in PVS geschrieben wurden. Dies kann die Größe von Transaktionsprotokollsicherungen erhöhen.

• Wenn Sie Transaktionsreplikation, Momentaufnahmereplikationoder Change Data Capture (CDC)verwenden, ist das aggressive Protokollabkürzungsverhalten von ADR deaktiviert, damit der Protokollleser Änderungen aus dem Transaktionsprotokoll sammeln kann. Stellen Sie sicher, dass das Transaktionsprotokoll ausreichend groß ist.

  Wenn Sie CDC oder Änderungsfeed in der Azure SQL Database verwenden, müssen Sie möglicherweise die Dienstebene oder die Rechenkapazität erhöhen, um sicherzustellen, dass genügend Transaktionsprotokollspeicher für die Anforderungen aller Workloads verfügbar ist. Ebenso müssen Sie in der von Azure SQL verwalteten Instanz möglicherweise die maximale Speichergröße ihrer Instanz erhöhen.

• Isolieren Sie für SQL Server den PVS-Versionsspeicher in einer Dateigruppe auf einer höheren Speicherebene, z. B. High-End-SSD oder erweitertes SSD oder Persistent Memory (PMEM), manchmal auch als Storage Class Memory (SCM) bezeichnet. Weitere Informationen finden Sie unter Ändern des Speicherorts der PVS in eine andere Dateigruppe.

• Überwachen Sie das Fehlerprotokoll für SQL Server auf PreallocatePVS-Einträge. Wenn PreallocatePVS Einträge vorhanden sind, müssen Sie möglicherweise die ADR-Fähigkeit erhöhen, Seiten mithilfe einer Hintergrundaufgabe vorab zuzuweisen. Die Vorabzuweisung von PVS-Seiten im Hintergrund verbessert die ADR-Leistung, indem teurere PVS-Zuweisungen im Vordergrund reduziert werden. Sie können die ADR Preallocation Factor Serverkonfiguration verwenden, um diesen Betrag zu erhöhen. Weitere Informationen finden Sie unter Serverkonfiguration: „ADR Preallocation Factor“.

• Für SQL Server 2022 (16.x) und höher sollten Sie die Multithread-PVS-Bereinigung aktivieren, wenn die Singlethread-Saubererleistung nicht ausreicht. Weitere Informationen finden Sie unter Serverkonfiguration: ADR Bereinigungs-Thread-Anzahl.

• Wenn Sie Probleme wie die hohe Datenbankraumnutzung durch PVS oder langsame PVS-Bereinigung beobachten, lesen Sie Überwachen und Beheben von Problemen mit der beschleunigten Datenbankwiederherstellung.

ADR-Verbesserungen in SQL Server 2022

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.

Die gleichen Verbesserungen sind auch in Azure SQL-Datenbank, azure SQL Managed Instance, Azure Synapse Analytics (nur dedizierter SQL-Pool) und SQL-Datenbank in Microsoft Fabric verfügbar.

• Bereinigung von Benutzertransaktionen

  Bereinigen Sie Seiten, die aufgrund eines Fehlers beim Sperrenabruf nicht durch den regulären Prozess bereinigt werden können.

  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-Seitenverfolgung

  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 PVS-Bereinigung

  PVS Cleaner hat die Effizienz der Versionsbereinigung verbessert, um zu verbessern, wie das Datenbankmodul Zeilenversionen für abgebrochene Transaktionen verfolgt und erfasst. Dies führt zu Verbesserungen der Speicher- und Speicherauslastung.

• Persistenter Versionsspeicher auf Transaktionsebene (PVS)

  Diese Verbesserung ermöglicht es ADR, Versionen zu bereinigen, die zu zugesicherten Transaktionen gehören, unabhängig davon, ob im System abgebrochene Transaktionen vorhanden sind. 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 reduziertes PVS-Wachstum, auch wenn die PVS-Bereinigung langsam ist oder fehlschlägt.

• Bereinigung von Versionen mit mehreren Threads

  In SQL Server 2019 (15.x) wird der Bereinigungsprozess innerhalb einer Datenbankmodulinstanz mit einem einzelnen Thread versehen.

  Ab SQL Server 2022 (16.x) wird die Multithread-Versionsbereinigung unterstützt. Dadurch können mehrere Datenbanken auf derselben Datenbankmodulinstanz parallel bereinigt oder eine einzelne Datenbank schneller bereinigt werden. Weitere Informationen finden Sie unter Serverkonfiguration: ADR Bereinigungs-Thread-Anzahl.

  Ein neues erweitertes Ereignis, tx_mtvc2_sweep_stats, wurde zur Überwachung der ADR PVS Multithread-Version-Bereinigung hinzugefügt.

Zugehöriger Inhalt

• Verwalten der beschleunigten Datenbankwiederherstellung
• Überwachung und Problembehandlung bei der beschleunigten Datenbankwiederherstellung