Een overzicht van traditioneel herstel
Zoals bij alle relationele databasesystemen, garandeert SQL Server de duurzaamheid van gegevens door crashherstel te implementeren. Duurzaamheid in het acroniem ACID, dat verwijst naar de kenmerken van transacties in relationele databases, betekent dat we er zeker van kunnen zijn dat als de database plotseling uitvalt, onze gegevens veilig zijn.
SQL Server implementeert deze mogelijkheid met behulp van het transactielogboek. Wijzigingen die zijn aangebracht door alle bewerkingen voor gegevensmanipulatie in SQL Server worden vastgelegd in het transactielogboek voordat ze worden toegepast op gegevensbestanden (via het controlepuntproces) voor het geval het nodig is om terug of vooruit te rollen.
Het driefasige crashherstelproces in SQL Server is als volgt:
Analyse – SQL Server leest het transactielogboek vanaf het laatste controlepunt tot het einde van het transactielogboek
Opnieuw – SQL Server speelt het logboek opnieuw af vanaf de oudste niet-vastgelegde transactie tot het einde van het logboek
Ongedaan maken – SQL Server leest het logboek vanaf het einde van het logboek tot de oudste niet-vastgelegde transactie en zet alle transacties terug die actief waren tijdens de crash
Ervaren DBA's zouden op een bepaald moment in hun carrière de ontmoedigende ervaring hebben gehad om hulpeloos te wachten op het voltooien van crashherstel in een zeer grote database. Transactie ROLLBACK gebruikt een soortgelijk mechanisme als het crashherstelproces. Microsoft heeft het herstelproces aanzienlijk verbeterd in SQL Server 2019.
Versneld databaseherstel
Versneld databaseherstel is een nieuwe functie op basis van versiebeheer die de herstelsnelheid aanzienlijk verhoogt in het geval van een ROLLBACK of herstel na een crash.
In SQL Server 2019 wijzigen drie nieuwe mechanismen binnen de SQL Server-engine de manier waarop herstel wordt afgehandeld en verminderen ze effectief de tijd die nodig is om een rollback/rollforward uit te voeren.
Persistent Version Store (PVS) – Legt rijversies vast binnen de betreffende database. De Persistent Version Store kan om prestatie- of grootteredenen in een aparte bestandsgroep worden gedefinieerd
Logisch terugzetten – Gebruikt de rijversies die zijn opgeslagen in PVS om een rollback uit te voeren wanneer een rollback wordt aangeroepen voor een bepaalde transactie of wanneer de ongedaanmakingsfase van crashherstel wordt aangeroepen.
sLog – Dit staat mogelijk voor secundair logboek . Het is een in-memory logstream die wordt gebruikt om bewerkingen vast te leggen waarvoor geen versiebeheer mogelijk is. Wanneer ADR is ingeschakeld in de database, wordt de sLog altijd opnieuw opgebouwd tijdens de analysefase van crashherstel. Tijdens het opnieuw fase, wordt de sLog gebruikt in plaats van het daadwerkelijke transactielogboek, waardoor het proces sneller gaat omdat het in het geheugen zit en minder transacties bevat. Het traditionele herstelproces verwerkt transacties vanaf het laatste controlepunt. De sLog wordt ook gebruikt tijdens het ongedaan maken fase.
Schoonmaker – Verwijdert onnodige rijversies uit de PVS. Microsoft biedt ook een opgeslagen procedure om handmatig het opschonen van onnodige rijversies te forceren.
-- 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';
Versneld databaseherstel is standaard uitgeschakeld
Het feit dat ADR standaard is uitgeschakeld in SQL Server 2019 kan voor sommige DBA's verrassend lijken, aangezien het zo'n geweldige functie lijkt te zijn. ADR maakt gebruik van versiebeheer in de gebruikersdatabase waarin het is ingeschakeld. Dit kan de grootte van de database aanzienlijk beïnvloeden. Bovendien moet u mogelijk plannen voor de groei van de database en de mogelijke locatie van de PVS om goede prestaties te garanderen als ADR is ingeschakeld. Het is dus logisch om deze functionaliteit bewust in te schakelen.
Het experiment:voorbereidende fase
We hebben een experiment opgezet om de nieuwe functie te verkennen en de impact van ADR op de grootte van het transactielogboek en op de snelheid van ROLLBACK te zien. In ons experiment maken we twee identieke databases met behulp van een enkele back-upset en vervolgens schakelen we ADR alleen in op een van deze databases. Lijst 2 toont de voorbereidende fasen voor de taak.
[uitbreiden titel =”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; [/uitbreiden]
Fig. 1 toont de uitvoer van de SQL-instructie in Listing 2 sectie 2c. We hebben ook de grootte van de databasebestanden en het gebruik van transactielogbestanden vastgelegd. (zie Afb. 3).
Afb. 1 Bevestig dat ADR is geconfigureerd
Afb. 2 Bekijk de bestandsgrootten van databasegegevens
Afb. 3 Controleer de grootte van het logbestand dat voor beide databases wordt gebruikt
Het experiment:uitvoeringsfase
Zodra we de details hebben vastgelegd die we nodig hebben om verder te gaan, voeren we de SQL-code van Listings 3 en 4 in fasen uit. De twee lijsten zijn equivalent, maar we voeren ze afzonderlijk uit op twee identieke databases. Eerst doen we een INSERT (Lijst 3, 3a), dan voeren we een DELETE uit (Lijst 3, 3b) die we vervolgens terugdraaien. Merk op dat we in zowel de INSERT als de DELETE de bewerkingen hebben ingekapseld in transacties. Houd er ook rekening mee dat de INSERT 50 keer wordt uitgevoerd. In elke fase van uitvoering, d.w.z. tussen 3a, 3b en 3c, leggen we het gebruik van het transactielogboek vast met behulp van de code in Listing 2,2e. Dit is hetzelfde voor de secties 4a, 4b en 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;
Afb. 4 en 5 laten ons zien dat de SELECT INTO-bewerking 6 milliseconden langer duurde in de TSQLV4_ADR-database waar we Accelerated Database Recovery hebben ingeschakeld. We zien ook in figuur 6 dat we een groter transactielogboekgebruik hebben in de TSQLV4_ADR-database. Ik was hier bijzonder verbaasd over, dus herhaalde ik het experiment verschillende keren om er zeker van te zijn dat ik dit resultaat consistent kreeg.
Afb. 4 Voer uitvoeringstijd in voor TSQLV4_NOADR
Afb. 5 Voer uitvoeringstijd in voor TSQLV4_ADR
Afb. 6 Transactielogboekgebruik na invoegingen
-- 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;
Afb. 7 en 8 laten ons zien dat de DELETE-bewerking aanzienlijk meer tijd kostte om te voltooien in de TSQLV4_ADR-database waar we versneld databaseherstel hebben ingeschakeld, hoewel hetzelfde aantal rijen in beide databases was verwijderd. Deze keer hebben we echter meer transactielogboekgebruik in de TSQLV4_NOADR-database.
Afb. 7 Verwijder uitvoeringstijd voor TSQLV4_NOADR
Afb. 8 Verwijder de uitvoeringstijd voor TSQLV4_ADR
Afb. 9 Transactielogboekgebruik na verwijdering
Het werd inmiddels duidelijk dat DML-bewerkingen langer duren in databases met ADR ingeschakeld. Dit verklaart gedeeltelijk waarom de functie in de eerste plaats is uitgeschakeld. Als we er diep over nadenken, is het logisch omdat SQL Server de rijversies in de PVS moet opslaan terwijl een invoeg-, bijwerk- of verwijderbewerking wordt uitgevoerd. Hoe lang de DML ook duurt, we stellen vast dat het uitgeven van een ROLLBACK met ADR ingeschakeld minder dan 1 milliseconde duurt (zie afbeeldingen 10 – 13). In sommige gevallen kan de snelle rollback de overhead van de DML zelf compenseren, maar niet in alle gevallen!
Afb. 10 Uitvoeringstijd voor ROLLBACK (na DELETE) op TSQLV4_NOADR
Afb. 11 Uitvoeringstijd voor ROLLBACK (na DELETE) op TSQLV4_ADR
Afb. 12 Uitvoeringstijd voor ROLLBACK (na INSERT) op TSQLV4_NOADR
Afb. 13 Uitvoeringstijd voor ROLLBACK (na DELETE) op TSQLV4_ADR
Conclusie
Versneld databaseherstel is een van de geweldige functies die in SQL Server 2019 zijn uitgebracht. Maar zoals met alle buitengewoon mooie dingen in het leven, moet iemand ervoor betalen. ADR kan in bepaalde scenario's een negatieve invloed hebben op de prestaties, dus het is belangrijk om uw scenario zorgvuldig te evalueren voordat u ADR in uw productiedatabase implementeert. Microsoft raadt Accelerated Database Recovery specifiek aan voor databases die workloads ondersteunen met zeer langlopende transacties, overmatige groei van transactielogboeken of frequente uitval in verband met een langdurig herstel.
Referenties
Versneld databaseherstel
Hoe werkt versneld databaseherstel?
Versneld databaseherstel