Verwalten der beschleunigten Datenbankwiederherstellung

Artikel
07/12/2024

Gilt für: SQL Server 2019 (15.x)

Dieser Artikel enthält Informationen zu bewährten Methoden zum Verwalten und Konfigurieren der beschleunigten Datenbankwiederherstellung (Accelerated Database Recovery, ADR) in SQL Server 2019 (15.x) und höheren Versionen. Weitere Informationen zu ADR in Azure SQL finden Sie unter Beschleunigte Datenbankwiederherstellung in Azure SQL.

Hinweis

In Azure SQL-Datenbank und Azure SQL Managed Instance ist die beschleunigte Datenbankwiederherstellung (ADR) für alle Datenbanken aktiviert und kann nicht deaktiviert werden. Wenn Sie Probleme mit der Speichernutzung, hohen Abbruchraten für Transaktionen und anderen Faktoren feststellen, können Sie Problembehandlung bei beschleunigter Datenbankwiederherstellung heranziehen oder den Azure-Support kontaktieren.

Zielgruppe der schnelleren Datenbankwiederherstellung

Viele Kunden betrachten die beschleunigte Datenbankwiederherstellung (ADR) als wertvolle Technologie zur Verbesserung der Wiederherstellungszeit. Machen Sie die Entscheidung, welche Datenbanken ADR verwenden sollten, von der Anhäufung der folgenden Faktoren abhängig. Werten Sie die folgenden Faktoren aus, und beurteilen Sie, ob die Anhäufung der Faktoren für oder gegen die Verwendung von ADR spricht.

ADR wird für Workloads mit unvermeidlichen zeitintensiven Transaktionen empfohlen. In Fällen, in denen bei zeitintensiven Transaktionen die Gefahr einer Zurücksetzung besteht, kann ADR hilfreich sein.
ADR wird für Arbeitsauslastungen empfohlen, bei denen aktive Transaktionen mitunter dazu führen, dass die Transaktionsprotokolle stark anwachsen.
ADR wird für Workloads empfohlen, bei denen es vorgekommen ist, dass die Datenbank länger nicht verfügbar war, da die SQL Server-Wiederherstellung lange gedauert hat (wie bei einem unerwarteten SQL Server-Neustart oder einem manuellen Transaktionsrollback).
ADR wird für Datenbanken, die für Datenbankspiegelung registriert sind, nicht unterstützt.
ADR wird aufgrund des persistenten Singlethread-Versionsspeichers (PvS) nicht für Datenbanken mit einer Größe von mehr als 100 Terabyte empfohlen.
Wenn Ihre Anwendung viele nicht batchbasierte, inkrementelle Updates wie z. B. das Aktualisieren eines Datensatzes bei jedem Zugriff auf bzw. Einfügen in eine Zeile ausführt, ist Ihre Workload möglicherweise für ADR nicht optimal. Erwägen Sie, die Anwendungsabfragen nach Möglichkeit bis zum Ende des Befehls in Batchupdates umzuschreiben und eine große Anzahl kleiner Updatetransaktionen zu reduzieren.

Bewerten, ob Ihre Workload für ADR geeignet ist

Sobald Sie ADR in Ihrer Workload aktiviert haben, achten Sie auf Anzeichen dafür, dass der persistente Versionsspeicher (PVS) nicht mithalten kann. Sie sollten die ADR-Integrität mithilfe der Methoden unter Problembehandlung für die beschleunigte Datenbankwiederherstellung überwachen.

ADR wird nicht für Datenbankumgebungen mit einer hohen Anzahl von Aktualisierungen/Löschungen wie z. B. OLTP mit hohem Volumen empfohlen, ohne dass dem PVS-Bereinigungsprozess ein Zeitraum der Ruhe/Wiederherstellung zur Verfügung steht, in dem der Speicherplatz freimachen kann. In der Regel lassen Geschäftsbetriebszyklen diese Zeit zu, aber in einigen Szenarien sollten Sie den PVS-Bereinigungsprozess manuell initiieren, um die Bedingungen der Anwendungsaktivität zu nutzen.

Wenn der PVS-Bereinigungsprozess über einen längeren Zeitraum ausgeführt wird, werden Sie möglicherweise feststellen, dass die Anzahl abgebrochener Transaktionen und damit auch die PVS-Größe zunimmt. Nutzen Sie die sys.dm_tran_aborted_transactions-DMV, um die Anzahl abgebrochener Transaktionen zu melden, und nutzen Sie sys.dm_tran_persistent_version_store_stats, um die Start-/Endzeiten der Bereinigung zusammen mit der PVS-Größe zu melden. Weitere Informationen finden Sie unter sys.dm_tran_persistent_version_store_stats.
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.
Workloads mit zeitintensiven Abfragen in SNAPSHOT- oder READ COMMITTED SNAPSHOT-Isolationsmodi können die ADR-PVS-Bereinigung in anderen Datenbanken verzögern, wodurch sich die PVS-Datei vergrößert. Weitere Informationen finden Sie im Abschnitt über lange aktive Momentaufnahmescans in der Problembehandlung bei beschleunigter Datenbankwiederherstellung. Dies gilt für Instanzen von SQL Server und Azure SQL Managed Instance oder in einem Pool für elastische Azure SQL-Datenbank.

Best Practices für die beschleunigte Datenbankwiederherstellung

Dieser Abschnitt enthält Anleitungen und Empfehlungen für ADR.

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 des PVS in eine andere Dateigruppe. Diese Option ist für Azure SQL-Datenbank und Azure SQL Managed Instance nicht verfügbar.
Stellen Sie sicher, dass in der Datenbank genügend Speicherplatz vorhanden ist, um die PVS-Nutzung zu berücksichtigen. Wenn die Datenbank nicht genügend Platz für das PVS-Wachstum bietet, kann ADR keine Versionen generieren. Mit ADR nimmt der Versionsspeicher weniger Speicherplatz in Anspruch als der tempdb-Versionsspeicher.
Vermeiden Sie mehrere zeitintensive Transaktionen in der Datenbank. Obwohl ein Ziel von ADR darin besteht, die Datenbankwiederherstellung aufgrund von Wiederholungen 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 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).

Aktivieren und Steuern von ADR

Hinweis

In Azure SQL-Datenbank und Azure SQL Managed Instance ist die beschleunigte Datenbankwiederherstellung (ADR) für alle Datenbanken aktiviert und kann nicht deaktiviert oder in eine andere Dateigruppe verlagert werden.

ADR ist in SQL Server 2019 (15.x) standardmäßig deaktiviert und kann mithilfe der DDL-Syntax gesteuert werden:

ALTER DATABASE [DB] SET ACCELERATED_DATABASE_RECOVERY = {ON | OFF};

Verwenden Sie diese Syntax, um zu steuern, ob die Funktion aktiviert oder deaktiviert ist, und legen Sie eine bestimmte Dateigruppe für die Daten des persistenten Versionsspeichers (Persistent Version Store, PVS) fest. Wenn keine Dateigruppe angegeben wird, wird der PVS in der PRIMARY-Dateigruppe gespeichert.

Zum Ändern dieses Zustands ist eine exklusive Sperre für die Datenbank erforderlich. Dies bedeutet, dass der ALTER DATABASE-Befehl blockiert wird, bis alle aktiven Sitzungen abgeschlossen sind, und alle neuen Sitzungen auf den ALTER DATABASE-Befehl warten. Wenn es wichtig ist, den Vorgang abzuschließen und die Sperre zu entfernen, können Sie die Terminierungsklausel WITH ROLLBACK [IMMEDIATE | AFTER {number} SECONDS | NO_WAIT] verwenden, um alle aktiven Sitzungen in der Datenbank abzubrechen. Weitere Informationen finden Sie unter ALTER DATABASE SET-Optionen (Transact-SQL).

Verwalten der Dateigruppe des persistenten Versionsspeichers

Die ADR-Funktion basiert auf der Versionierung von Änderungen, wobei verschiedene Versionen eines Datenelements im PVS gespeichert sind. Es gibt Überlegungen hinsichtlich der Suche nach dem Speicherort des PVS und der Verwaltung der Größe der Daten im PVS.

Aktivieren von ADR ohne Angabe einer Dateigruppe

Dieser Vorgang erfordert exklusiven Zugriff auf die Datenbank.

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON;
GO

Wenn keine PVS-Dateigruppe angegeben wird, werden die PVS-Daten in der PRIMARY-Dateigruppe gespeichert.

So aktivieren Sie ADR und geben als Speicherort für den PVS eine Dateigruppe an

Sie können ADR so konfigurieren, dass neben der Standarddateigruppe PRIMARY eine andere Dateigruppe zum Speichern von PVS-Daten verwendet wird.

Bevor Sie ADR in einer anderen Dateigruppe als PRIMARY aktivieren, müssen Sie die Dateigruppe und die Datendatei erstellen.

Erstellen Sie die Dateigruppe VersionStoreFG und erstellen Sie eine neue Datendatei in der Dateigruppe. Zum Beispiel:

ALTER DATABASE [MyDatabase] ADD FILEGROUP [VersionStoreFG];
GO
ALTER DATABASE [MyDatabase] ADD FILE ( NAME = N'VersionStoreFG'
, FILENAME = N'E:\DATA\VersionStore.ndf'
, SIZE = 8192KB , FILEGROWTH = 65536KB )
TO FILEGROUP [VersionStoreFG];
GO

Aktivieren Sie ADR erst, nachdem die Dateigruppe und eine sekundäre Datendatei erstellt wurden, und geben Sie an, dass der PVS in einer bestimmten Dateigruppe gespeichert werden soll. Dieser Vorgang erfordert exklusiven Zugriff auf die Datenbank.

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = [VersionStoreFG]);

So deaktivieren Sie die ADR-Funktion

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

Auch nach dem Aktivieren der ADR-Funktion werden im persistenten Versionsspeicher Versionen gespeichert, die vom System für die logische Wiederherstellung weiterhin benötigt werden.

Ändern des Speicherorts des PVS in eine andere Dateigruppe

In SQL Server kann es aus verschiedenen Gründen notwendig sein, den Speicherort des PVS in eine andere Dateigruppe zu ändern. Dies ist dann zum Beispiel der Fall, wenn der PVS mehr Speicherplatz benötigt oder eine schnellere Speicherung erforderlich ist.

Der Speicherort des PVS wird in drei Schritten geändert.

Deaktivieren Sie die ADR-Funktion.

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

Warten Sie, bis alle im PVS gespeicherten Versionen freigegeben werden können.

Um ADR mit einem neuen Speicherort für den persistenten Versionsspeicher aktivieren zu können, müssen Sie zunächst sicherstellen, dass alle Versionsinformationen aus dem vorherigen PVS-Speicherort gelöscht wurden. Um dieses Cleanup zu erzwingen, führen Sie den folgenden Befehl aus:
```
EXEC sys.sp_persistent_version_cleanup [database name];
```
Die gespeicherte Prozedur sys.sp_persistent_version_cleanup erfolgt synchron. Dies bedeutet, dass sie erst vollständig ausgeführt wird, bis alle Versionsinformationen im aktuellen PVS gelöscht wurden. Nach Durchführen des Cleanups können Sie überprüfen, ob die Versionsinformationen tatsächlich entfernt wurden. Führen Sie dazu eine sys.dm_tran_persistent_version_store_stats-Abfrage für DMV durch, und untersuchen Sie den persistent_version_store_size_kb-Wert.
```
SELECT DB_Name(database_id), persistent_version_store_size_kb 
FROM sys.dm_tran_persistent_version_store_stats where database_id = [MyDatabaseID];
```
Wenn der Wert von persistent_version_store_size_kb 0 ist, können Sie die ADR-Funktion erneut aktivieren und den PVS so konfigurieren, dass er sich in der neuen Dateigruppe befindet.

Aktivieren Sie ADR, wobei Sie den neuen PVS-Speicherort angeben:

ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = [VersionStoreFG]);

Teilen über