Beschleunigte Datenbankwiederherstellung in Azure SQL

  • Artikel

Gilt für:Azure SQL-DatenbankAzure SQL Managed Instance

Die beschleunigte Datenbankwiederherstellung (Accelerated Database Recovery, ADR) ist ein Feature der SQL Server-Datenbank-Engine, das die Datenbankverfügbarkeit erheblich verbessert, insbesondere bei zeitintensiven Transaktionen. Dies ist auf einen Neuentwurf des Wiederherstellungsverfahrens der SQL Server-Datenbank-Engine zurückzuführen.

ADR ist derzeit für Azure SQL-Datenbank, Azure SQL Managed Instance, Datenbanken in Azure Synapse Analytics und SQL Server auf Azure-VMs (ab SQL Server 2019) verfügbar. Informationen zu ADR in SQL Server finden Sie unter Verwalten der schnelleren Datenbankwiederherstellung.

Hinweis

ADR ist in Azure SQL-Datenbank und Azure SQL Managed Instance standardmäßig aktiviert. Das Deaktivieren von ADR in Azure SQL-Datenbank und Azure SQL Managed Instance wird nicht unterstützt.

Ü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.

Standardprozess zur Datenbankwiederherstellung

Die Datenbankwiederherstellung basiert auf dem ARIES-Wiederherstellungsmodell und umfasst drei Phasen. Diese Phasen sind im folgenden Diagramm dargestellt und werden im darauffolgenden Diagramm ausführlicher erläutert.

current recovery process

  • Die Analysephase

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

  • Die Rollforwardphase

    Vorwärts-Scan des Transaktionsprotokolls von der ältesten Transaktion ohne Commit bis zum Ende, um die Datenbank in den Zustand zum Zeitpunkt des Absturzes zu versetzen, indem alle Commit-Vorgänge erneut durchgeführt werden.

  • Die Rollbackphase

    Für jede Transaktion, die zum Zeitpunkt des Absturzes aktiv war, wird das Protokoll in umgekehrter Richtung durchlaufen, um die von dieser Transaktion durchgeführten Vorgänge rückgängig zu machen.

Basierend auf diesem Entwurf ist die Zeit, die die SQL Server-Datenbank-Engine für die Wiederherstellung nach einem unerwarteten Neustart benötigt, ungefähr proportional zur Größe der Transaktion, die zum Zeitpunkt des Absturzes im System am längsten aktiv war. 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 Wiederherstellungsprozess bei zeitintensiven Transaktionen (z. B. bei umfangreichen Masseneinfügungsvorgängen oder Indexerstellungvorgängen für eine große Tabelle) sehr lange dauern.

Auch das Abbrechen bzw. Durchführen eines Rollbacks für eine Transaktion kann bei diesem Entwurf sehr lange dauern, da die gleiche Rückgängig/Wiederherstellen-Phase wie oben beschrieben genutzt wird.

Darüber hinaus kann die SQL Server-Datenbank-Engine das Transaktionsprotokoll nicht kürzen, wenn Transaktionen mit langer Laufzeit vorhanden sind, da die entsprechenden Protokolldatensätze für die Wiederherstellungs- und Rollbackprozesse benötigt werden. Aufgrund dieser Eigenschaft der SQL Server-Datenbank-Engine bestand bei einigen Kunden das Problem, dass das Transaktionsprotokoll sehr groß wird und sehr viel Festplattenspeicher belegt.

Prozess für die schnellere Datenbankwiederherstellung

Mit ADR wird auf die obigen Probleme reagiert, indem das Wiederherstellungsverfahren des SQL Server-Datenbankmoduls vollständig neu entworfen wurde, um Folgendes zu erreichen:

  • 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. Bei ADR wird das Transaktionsprotokoll nur ab dem letzten erfolgreichen Prüfpunkt verarbeitet (bzw. ab der Protokollfolgenummer (Log Sequence Number, LSN) der ältesten modifizierten Seite). 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 des Absturzes aktiv waren, werden als „Abgebrochen“ gekennzeichnet. Daher können Versionen, die von diesen Transaktionen generiert werden, von gleichzeitigen Benutzerabfragen ignoriert werden.

Die schnelle Datenbankwiederherstellung (ADR) besteht aus den gleichen drei Phasen wie der aktuelle Wiederherstellungsprozess. Wie diese Phasen für ADR durchgeführt werden, ist im folgenden Diagramm dargestellt und wird im darauffolgenden Diagramm ausführlicher erläutert.

ADR recovery process

  • Die Analysephase

    Der Prozess bleibt derselbe, wird jedoch durch die SLOG-Rekonstruktion und das Kopieren von Protokolldatensätzen für Vorgänge ohne Versionsverwaltung ergänzt.

  • Die Rollforwardphase

    Aufgeteilt in zwei Phasen (P)

    • Phase 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.

    • Phase 2

      Die Wiederholung über das Transaktionsprotokoll beginnt ab dem letzten Prüfpunkt (anstatt ab 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.

Komponenten der ADR-Wiederherstellung

Die vier wichtigsten Komponenten von ADR sind:

  • Persistenter Versionsspeicher (PVS)

    Der persistente Versionsspeicher ist ein neuer Mechanismus der SQL Server-Datenbank-Engine, mit dem die in der Datenbank generierten Zeilenversionen beibehalten werden, nicht die im herkömmlichen tempdb-Versionsspeicher. Mit dem persistenten Versionsspeicher wird die Ressourcenisolation ermöglicht und die Verfügbarkeit von lesbaren sekundären Replikaten verbessert.

  • Logische Wiederherstellung

    Die logische Wiederherstellung ist der asynchrone Prozess zur Durchführung des Rückgängigmachens basierend auf der Zeilenebenenversion – mit sofortigem Transaktionsrollback und Rückgängig-Vorgang für alle Vorgänge mit Versionsangabe. Die logische Wiederherstellung erfolgt wie folgt:

    • Alle abgebrochenen Transaktionen werden nachverfolgt und für andere Transaktionen als unsichtbar markiert.
    • Es wird ein Rollback mithilfe von PVS für alle Benutzertransaktionen ausgeführt, anstatt das Transaktionsprotokoll physisch zu scannen und die Änderungen einzeln rückgängig zu machen.
    • Nach dem Abbruch der Transaktion werden alle Sperren sofort aufgehoben. Da der Abbruch das einfache Markieren von Änderungen im Arbeitsspeicher beinhaltet, ist der Prozess sehr effizient, sodass die Sperren nicht sehr lange aufrechterhalten werden müssen.

  • SLOG

    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.

Muster bei der beschleunigten Datenbankwiederherstellung (ADR)

Die folgenden Arten von Workloads profitieren am meisten von ADR:

  • ADR wird für Workloads mit zeitintensiven Transaktionen empfohlen.
  • ADR wird für Workloads empfohlen, bei denen aktive Transaktionen mitunter dazu führen, dass die Transaktionsprotokolle stark anwachsen.
  • ADR wird für Arbeitsauslastungen empfohlen, die aufgrund einer zeitintensiven Wiederherstellung (z. B. durch einen unvorhergesehenen Dienstneustart oder einen manuellen Transaktionsrollback) über längere Zeiträume nicht verfügbar waren.

Best Practices für die beschleunigte Datenbankwiederherstellung

  • Vermeiden Sie zeitintensive Transaktionen in der Datenbank. Obwohl ein Ziel von ADR darin besteht, die Datenbankwiederherstellung zum Rollforward von Transaktionen mit langer Laufzeit zu beschleunigen, können zeitintensive Transaktionen die Versionsbereinigung verzögern und die Größe des PVS erhöhen.

  • Vermeiden Sie große Transaktionen mit Datendefinitionsänderungen oder DDL-Vorgängen. ADR verwendet einen SLOG-Mechanismus, um die bei der Wiederherstellung verwendeten DDL-Vorgänge nachzuverfolgen. Der SLOG wird nur verwendet, während die Transaktion aktiv ist. Für den SLOG wird ein Prüfpunkt verwendet, sodass die Vermeidung großer Transaktionen, die SLOG verwenden, die Gesamtleistung verbessern kann. 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 können Sie die Indizes einzeln und nacheinander löschen und anschließend die Tabelle löschen. Weitere Informationen zum SLOG finden Sie unter ADR-Wiederherstellungskomponenten.

  • Vermeiden oder reduzieren Sie unnötige Abbruchsituationen. Eine hohe Abbruchrate 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 oder andere Einschränkungsverletzungen verursacht werden.

    • Die dynamische Verwaltungssicht sys.dm_tran_aborted_transactions zeigt alle abgebrochenen Transaktionen für die SQL Server-Instanz an. 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 blockieren können. Weitere Informationen finden Sie unter sys.dm_tran_aborted_transactions (Transact-SQL).

    • Verwenden Sie sys.sp_persistent_version_cleanup, um den PVS-Bereinigungsprozess zwischen Arbeitsauslastungen oder während eines Wartungsfensters manuell zu aktivieren. Weitere Informationen finden Sie unter sys.sp_persistent_version_cleanup.

  • Wenn Sie Probleme mit der Speichernutzung, hohen Abbruchraten für Transaktionen und anderen Faktoren feststellen, finden Sie weitere Informationen unter Problembehandlung der beschleunigten Datenbankwiederherstellung (ADR) in SQL Server.

Nächste Schritte