Verwalten der beschleunigten Datenbankwiederherstellung

  • Artikel

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

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

Hinweis

In Azure SQL-Datenbank und Azure SQL verwaltete Instanz ist die beschleunigte Datenbankwiederherstellung (ADR) für alle Datenbanken aktiviert und kann nicht deaktiviert werden. Wenn Sie Probleme mit der Speichernutzung, einer hohen Abbruchtransaktion und anderen Faktoren beobachten, überprüfen Sie die Problembehandlung bei der beschleunigten Datenbankwiederherstellung , oder wenden Sie sich an den Azure-Support.

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 transaktionen mit langer Ausführung empfohlen, die nicht vermieden werden können. In Fällen, in denen lange ausgeführte Transaktionen zum Risiko eines Rollbacks führen, 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. Verwenden Sie DMVsys.dm_tran_aborted_transactions, um die Anzahl der abgebrochenen Transaktionen zu melden und sys.dm_tran_persistent_version_store_stats die sauber Start-/Endzeiten 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 lang ausgeführten Abfragen in SNAPSHOT- oder READ COMMITTED SNAPSHOT-Isolationsmodi können ADR PVS sauber up in anderen Datenbanken verzögern, wodurch die PVS-Datei vergrößert wird. Weitere Informationen finden Sie im Abschnitt zu langen aktiven Momentaufnahme Überprüfungen in der Problembehandlung für die beschleunigte Datenbankwiederherstellung. Dies gilt für Instanzen von SQL Server und Azure SQL verwaltete Instanz oder in einem Azure SQL-Datenbank elastischen Pool.

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 verwaltete Instanz 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 lange ausgeführte Transaktionen in der Datenbank. Obwohl ein Ziel von ADR darin besteht, die Datenbankwiederherstellung aufgrund von Wiederholungen zu beschleunigen, können mehrere lange ausgeführte Transaktionen die Version sauber up verzögern und die Größe der 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 enthält 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. Die Problemumgehung kann sein, die Indizes einzeln und schrittweise abzulegen und dann die Tabelle abzulegen. 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 verwaltete Instanz ist die beschleunigte Datenbankwiederherstellung (ADR) für alle Datenbanken aktiviert und kann nicht in eine andere Dateigruppe deaktiviert oder verschoben 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 an, dass die PVS in einer Dateigruppe gespeichert werden soll

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 Dateigruppe aktivieren PRIMARY, müssen Sie die Dateigruppe und die Datendatei erstellen.

Erstellen Sie die VersionStoreFG Dateigruppe, und erstellen Sie eine neue Datendatei in der Dateigruppe. 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 die 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.

  1. Deaktivieren Sie die ADR-Funktion.

    ALTER DATABASE [MyDatabase] SET ACCELERATED_DATABASE_RECOVERY = OFF;
GO

  2. 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 persistent_version_store_size_kb lautet 0, können Sie das ADR-Feature erneut aktivieren und das PVS so konfigurieren, dass er sich in der neuen Dateigruppe befindet.

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

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

Nächste Schritte