Ein Überblick über die herkömmliche Wiederherstellung
Wie bei allen relationalen Datenbanksystemen garantiert SQL Server die Dauerhaftigkeit von Daten durch die Implementierung einer Wiederherstellung nach einem Absturz. Dauerhaftigkeit im Akronym ACID, das sich auf die Eigenschaften von Transaktionen in relationalen Datenbanken bezieht, bedeutet, dass wir sicher sein können, dass unsere Daten sicher sind, wenn die Datenbank plötzlich ausfällt.
SQL Server implementiert diese Funktion mithilfe des Transaktionsprotokolls. Änderungen, die von allen Datenbearbeitungsvorgängen in SQL Server vorgenommen werden, werden im Transaktionsprotokoll erfasst, bevor sie (über den Checkpoint-Prozess) auf Datendateien angewendet werden, falls ein Rollback oder Rollforward erforderlich ist.
Der dreiphasige Wiederherstellungsprozess nach einem Absturz in SQL Server ist wie folgt:
Analyse – SQL Server liest das Transaktionslog vom letzten Prüfpunkt bis zum Ende des Transaktionslogs
Wiederholen – SQL Server gibt das Protokoll von der ältesten nicht festgeschriebenen Transaktion bis zum Ende des Protokolls wieder
Rückgängig machen – SQL Server liest das Protokoll vom Ende des Protokolls bis zur ältesten nicht festgeschriebenen Transaktion und macht alle Transaktionen rückgängig, die während des Absturzes aktiv waren
Erfahrene DBAs mussten irgendwann in ihrer Karriere die entmutigende Erfahrung machen, hilflos darauf zu warten, dass die Wiederherstellung nach einem Absturz einer sehr großen Datenbank abgeschlossen wird. Die Transaktion ROLLBACK verwendet einen ähnlichen Mechanismus wie der Crash-Recovery-Prozess. Microsoft hat den Wiederherstellungsprozess in SQL Server 2019 erheblich verbessert.
Beschleunigte Datenbankwiederherstellung
Beschleunigte Datenbankwiederherstellung ist eine neue Funktion, die auf Versionierung basiert und die Wiederherstellungsrate im Falle eines ROLLBACK oder einer Wiederherstellung nach einem Absturz erheblich erhöht.
In SQL Server 2019 ändern drei neue Mechanismen innerhalb der SQL Server-Engine die Art und Weise, wie die Wiederherstellung gehandhabt wird, und reduzieren effektiv die Zeit, die für die Durchführung eines Rollbacks/Rollforward erforderlich ist.
Persistenter Versionsspeicher (PVS) – Erfasst Zeilenversionen innerhalb der betreffenden Datenbank. Der Persistent Version Store kann aus Performance- oder Größengründen in einer separaten Dateigruppe definiert werden
Logisches Zurücksetzen – Verwendet die in PVS gespeicherten Zeilenversionen, um ein Rollback durchzuführen, wenn ein Rollback für eine bestimmte Transaktion aufgerufen wird oder wenn die Undo-Phase der Wiederherstellung nach einem Absturz aufgerufen wird.
sLog – Dies steht möglicherweise für sekundär protokollieren . Es handelt sich um einen In-Memory-Protokollstream, der zum Erfassen von Vorgängen verwendet wird, die nicht versioniert werden können. Wenn ADR in der Datenbank aktiviert ist, wird das sLog während der Analysephase der Wiederherstellung nach einem Absturz immer neu erstellt. Während der Wiederherstellung Phase wird das sLog anstelle des eigentlichen Transaktionsprotokolls verwendet, was den Prozess beschleunigt, da es sich im Speicher befindet und weniger Transaktionen enthält. Der traditionelle Wiederherstellungsprozess verarbeitet Transaktionen vom letzten Checkpoint. Das sLog wird auch während des Rückgängigmachens verwendet Phase.
Reiniger – Entfernt unnötige Zeilenversionen aus dem PVS. Microsoft stellt auch eine gespeicherte Prozedur bereit, um manuell eine Bereinigung unnötiger Zeilenversionen zu erzwingen.
-- LISTING 1: INVOKE THE BACKGROUND CLEANER USE TSQLV4_ADR GO EXECUTE sys.sp_persistent_version_cleanup; USE master GO EXECUTE master.sys.sp_persistent_version_cleanup 'TSQLV4_ADR';
Beschleunigte Datenbankwiederherstellung ist standardmäßig deaktiviert
Die Tatsache, dass ADR in SQL Server 2019 standardmäßig deaktiviert ist, mag für einige DBAs überraschend erscheinen, da es sich um eine so großartige Funktion handelt. ADR verwendet die Versionierung in der Benutzerdatenbank, in der es aktiviert ist. Dies kann sich erheblich auf die Datenbankgröße auswirken. Darüber hinaus müssen Sie möglicherweise das Datenbankwachstum sowie den möglichen Standort des PVS einplanen, um eine gute Leistung sicherzustellen, wenn ADR aktiviert ist. Daher ist es sinnvoll, diese Funktionalität bewusst zu aktivieren.
Das Experiment:Vorbereitungsphase
Wir haben ein Experiment eingerichtet, um die neue Funktion zu erkunden und die Auswirkungen von ADR auf die Größe des Transaktionsprotokolls sowie auf die Geschwindigkeit von ROLLBACK zu sehen. In unserem Experiment erstellen wir zwei identische Datenbanken mit einem einzigen Sicherungssatz und aktivieren dann ADR nur auf einer dieser Datenbanken. Listing 2 zeigt die vorbereitenden Schritte für die Aufgabe.
[expand title =”Code”]
-- LISTING 2: PREPARE THE DATABASES AND CONFIGURE ADR
-- 2a. Backup a sample database and restore as two identical databases
BACKUP DATABASE TSQLV4 TO DISK='TSQLV4.BAK' WITH COMPRESSION;
-- Restore Database TSQLV4_NOADR (ADR will not be enabled)
RESTORE DATABASE TSQLV4_NOADR FROM DISK='TSQLV4.BAK' WITH
MOVE 'TSQLV4' TO 'C:\MSSQL\DATA\TSQLV4_NOADR.MDF',
MOVE 'TSQLV4_log' TO 'E:\MSSQL\LOG\TSQLV4_NOADR_LOG.LDF';
-- Restore Database TSQLV4_ADR (ADR will be enabled)
RESTORE DATABASE TSQLV4_ADR FROM DISK='TSQLV4.BAK' WITH
MOVE 'TSQLV4' TO 'C:\MSSQL\DATA\TSQLV4_ADR.MDF',
MOVE 'TSQLV4_log' TO 'E:\MSSQL\LOG\TSQLV4_ADR_LOG.LDF';
-- 2b. Enable ADR in TSQLV4_ADR
USE [master]
GO
-- First create a separate filegroup and add a file to the filegroup
ALTER DATABASE [TSQLV4_ADR] ADD FILEGROUP [ADR_FG];
ALTER DATABASE [TSQLV4_ADR] ADD FILE ( NAME = N'TSQLV4_ADR01', FILENAME = N'C:\MSSQL\Data\TSQLV4_ADR01.ndf' ,
SIZE = 8192KB , FILEGROWTH = 65536KB ) TO FILEGROUP [ADR_FG]
GO
-- Enable ADR
ALTER DATABASE TSQLV4_ADR SET ACCELERATED_DATABASE_RECOVERY = ON (PERSISTENT_VERSION_STORE_FILEGROUP = ADR_FG);
GO
-- 2c. Check if all ADR is enabled as planned
SELECT name
, compatibility_level
, snapshot_isolation_state_desc
, recovery_model_desc
, target_recovery_time_in_seconds
, is_accelerated_database_recovery_on FROM SYS.DATABASES
WHERE name LIKE 'TSQLV4_%';
-- 2d. Check sizes of all files in the databases
SELECT DB_NAME(database_id) AS database_name
, name AS file_name
, physical_name
, (size * 8)/1024 AS [size (MB)]
, type_desc
FROM SYS.master_files
WHERE DB_NAME(database_id) LIKE 'TSQLV4_%';
-- 2e. Check size of log used
CREATE TABLE ##LogSpaceUsage (database_name VARCHAR(50)
, database_id INT, total_log_size_in_bytes BIGINT
, used_log_space_in_bytes BIGINT
, used_log_space_in_percent BIGINT
, log_space_in_bytes_since_last_backup BIGINT)
INSERT INTO ##LogSpaceUsage
EXEC sp_MSforeachdb @command1='
IF ''?'' LIKE ("TSQLV4_%")
SELECT DB_NAME(database_id), * FROM ?.SYS.dm_db_log_space_usage;'
SELECT * FROM ##LogSpaceUsage;
DROP TABLE ##LogSpaceUsage; [/expandieren]
Abb. 1 zeigt die Ausgabe der SQL-Anweisung in Abschnitt 2c von Listing 2. Wir haben auch die Größe der Datenbankdateien und die Nutzung der Transaktionsprotokolldatei erfasst. (siehe Abb. 3).
Abb. 1 Bestätigen Sie, dass ADR konfiguriert ist
Abb. 2 Dateigrößen der Datenbankdaten überprüfen
Abb. 3 Überprüfen Sie die Größe des für beide Datenbanken verwendeten Protokolls
Das Experiment:Ausführungsphase
Sobald wir die Details erfasst haben, die wir zum Fortfahren benötigen, führen wir den SQL-Code aus Listing 3 und 4 schrittweise aus. Die beiden Auflistungen sind gleichwertig, aber wir führen sie separat auf zwei identischen Datenbanken aus. Zuerst führen wir ein INSERT (Listing 3, 3a) durch, dann führen wir ein DELETE (Listing 3, 3b) aus, das wir anschließend rückgängig machen. Beachten Sie, dass wir sowohl beim INSERT als auch beim DELETE die Operationen in Transaktionen gekapselt haben. Beachten Sie auch, dass INSERT 50 Mal ausgeführt wird. In jeder Phase der Ausführung, also zwischen 3a, 3b und 3c, erfassen wir die Nutzung des Transaktionsprotokolls mit Hilfe des Codes in Listing 2,2e. Dies gilt auch für die Abschnitte 4a, 4b und 4c.
-- LISTING 3: EXECUTE DML IN TSQLV4_NOADR DATABASE -- 3a. Execute INSERT Statement in TSQLV4_NOADR Database USE TSQLV4_NOADR GO BEGIN TRAN SET STATISTICS IO ON; SET STATISTICS TIME ON; SELECT * INTO [Sales].[OrderDetails_noadr] FROM [Sales].[OrderDetails]; GO INSERT INTO [Sales].[OrderDetails_noadr] SELECT * FROM [Sales].[OrderDetails]; GO 50 COMMIT; -- 3b. Execute DELETE in TSQLV4_NOADR Database USE TSQLV4_NOADR GO BEGIN TRAN SET STATISTICS IO ON; SET STATISTICS TIME ON; DELETE FROM [Sales].[OrderDetails_noadr] GO -- 3c. Perform Rollback and Capture Time ROLLBACK;
Abb. 4 und 5 zeigen uns, dass die SELECT INTO-Operation in der TSQLV4_ADR-Datenbank, in der wir Accelerated Database Recovery aktiviert haben, 6 Millisekunden länger gedauert hat. Wir sehen auch in Abb. 6, dass wir eine größere Transaktionsprotokollnutzung in der TSQLV4_ADR-Datenbank haben. Das hat mich besonders überrascht, also habe ich das Experiment mehrmals wiederholt, um sicherzustellen, dass ich dieses Ergebnis konstant erhalte.
Abb. 4 Ausführungszeit für TSQLV4_NOADR einfügen
Abb. 5 Ausführungszeit für TSQLV4_ADR einfügen
Abb. 6 Verwendung des Transaktionsprotokolls nach Einfügungen
-- LISTING 4: EXECUTE DML IN TSQLV4_ADR DATABASE -- 4a. Execute INSERT Statement in TSQLV4_ADR Database USE TSQLV4_ADR GO BEGIN TRAN SET STATISTICS IO ON; SET STATISTICS TIME ON; SELECT * INTO [Sales].[OrderDetails_adr] FROM [Sales].[OrderDetails]; GO INSERT INTO [Sales].[OrderDetails_adr] SELECT * FROM [Sales].[OrderDetails]; GO 50 COMMIT; -- 4b. Execute DELETE in TSQLV4_ADR Database USE TSQLV4_ADR GO BEGIN TRAN SET STATISTICS IO ON; SET STATISTICS TIME ON; DELETE FROM [Sales].[OrderDetails_adr] GO -- 4c. Perform Rollback and Capture Time ROLLBACK;
Abb. 7 und 8 zeigen uns, dass der DELETE-Vorgang in der TSQLV4_ADR-Datenbank, in der wir die beschleunigte Datenbankwiederherstellung aktiviert haben, erheblich mehr Zeit in Anspruch genommen hat, obwohl in beiden Datenbanken die gleiche Anzahl von Zeilen gelöscht wurde. Dieses Mal haben wir jedoch eine größere Nutzung des Transaktionsprotokolls in der TSQLV4_NOADR-Datenbank.
Abb. 7 Ausführungszeit für TSQLV4_NOADR löschen
Abb. 8 Ausführungszeit für TSQLV4_ADR löschen
Abb. 9 Verwendung des Transaktionsprotokolls nach dem Löschen
Inzwischen wurde deutlich, dass DML-Vorgänge in Datenbanken mit aktiviertem ADR länger dauern. Dies erklärt teilweise, warum die Funktion überhaupt deaktiviert ist. Wenn man genau darüber nachdenkt, ist es sinnvoll, da SQL Server die Zeilenversionen im PVS speichern muss, während ein Einfüge-, Aktualisierungs- oder Löschvorgang ausgeführt wird. Unabhängig davon, wie viel Zeit die DML benötigt, stellen wir fest, dass die Ausgabe eines ROLLBACK mit eingeschaltetem ADR weniger als 1 Millisekunde dauert (siehe Abb. 10 – 13). In einigen Fällen kann das schnelle Rollback den Overhead der DML selbst kompensieren, aber nicht in allen Fällen!
Abb. 10 Ausführungszeit für ROLLBACK (nach DELETE) auf TSQLV4_NOADR
Abb. 11 Ausführungszeit für ROLLBACK (nach DELETE) auf TSQLV4_ADR
Abb. 12 Ausführungszeit für ROLLBACK (nach INSERT) auf TSQLV4_NOADR
Abb. 13 Ausführungszeit für ROLLBACK (nach DELETE) auf TSQLV4_ADR
Schlussfolgerung
Beschleunigte Datenbankwiederherstellung ist eine der großartigen Funktionen, die in SQL Server 2019 veröffentlicht wurden. Wie bei allen äußerst schönen Dingen im Leben muss jedoch jemand dafür bezahlen. ADR kann sich in bestimmten Szenarien negativ auf die Leistung auswirken, daher ist es wichtig, Ihr Szenario sorgfältig zu bewerten, bevor Sie ADR in Ihrer Produktionsdatenbank implementieren. Microsoft empfiehlt die beschleunigte Datenbankwiederherstellung ausdrücklich für Datenbanken, die Workloads mit sehr lang andauernden Transaktionen, übermäßigem Wachstum des Transaktionsprotokolls oder häufigen Ausfällen im Zusammenhang mit einer lang andauernden Wiederherstellung unterstützen.
Referenzen
Beschleunigte Datenbankwiederherstellung
Wie funktioniert die beschleunigte Datenbankwiederherstellung?
Beschleunigte Datenbankwiederherstellung
