En översikt över traditionell återhämtning
Som med alla relationsdatabassystem garanterar SQL Server datas hållbarhet genom att implementera kraschåterställning. Hållbarhet i akronymen ACID som hänvisar till egenskaperna hos transaktioner i relationsdatabaser gör att vi kan vara säkra på att om databasen plötsligt misslyckas är vår data säker.
SQL Server implementerar denna funktion med hjälp av transaktionsloggen. Ändringar som görs av alla datamanipulationsoperationer i SQL Server registreras i transaktionsloggen innan de tillämpas på datafiler (genom checkpoint-processen) om det behövs för att rulla tillbaka eller rulla framåt.
Den trefasiga kraschåterställningsprocessen i SQL Server är som följer:
Analys – SQL Server läser transaktionsloggen från den senaste kontrollpunkten till slutet av transaktionsloggen
Gör om – SQL Server spelar upp loggen från den äldsta oengagerade transaktionen till slutet av loggen
Ångra – SQL Server läser loggen från slutet av loggen till den äldsta oengagerade transaktionen och återställer alla transaktioner som var aktiva under kraschen
Erfarna DBA:er skulle någon gång i sin karriär ha haft den nedslående upplevelsen att vänta hjälplöst på att kraschåterställning skulle slutföras på en mycket stor databas. Transaktions ROLLBACK använder en liknande mekanism som kraschåterställningsprocessen. Microsoft har förbättrat återställningsprocessen avsevärt i SQL Server 2019.
Accelererad databasåterställning
Accelererad databasåterställning är en ny funktion baserad på versionshantering som avsevärt ökar återställningshastigheten vid en ROLLBACK eller återställning från en krasch.
I SQL Server 2019 modifierar tre nya mekanismer inom SQL Server-motorn sättet på vilket återställning hanteras och minskar effektivt den tid som krävs för att utföra en rollback/framåtrullning.
Persistent Version Store (PVS) – Fångar radversioner inom databasen i fråga. Persistent Version Store kan definieras i en separat filgrupp av prestanda- eller storleksskäl
Logisk återställning – Använder radversionerna som är lagrade i PVS för att utföra återställning när en återställning åberopas för en viss transaktion eller när ångrafasen av kraschåterställning åberopas.
sLog – Detta står möjligen för sekundär logg . Det är en loggström i minnet som används för att fånga operationer som inte kan versioneras. När ADR är aktiverat i databasen, byggs sLog alltid om under analysfasen av kraschåterställning. Under gör om fasen används sLog snarare än själva transaktionsloggen vilket gör processen snabbare eftersom den sitter i minnet och innehåller färre transaktioner. Den traditionella återställningsprocessen hanterar transaktioner från den sista kontrollpunkten. sLogen används också under ångra fas.
Renare – Tar bort onödiga radversioner från PVS. Microsoft tillhandahåller också en lagrad procedur för att manuellt tvinga fram en rensning av onödiga radversioner.
-- 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';
Accelererad databasåterställning är avstängd som standard
Det faktum att ADR är avstängd i SQL Server 2019 som standard kan verka förvånande för vissa DBA:er med tanke på att det verkar vara en så bra funktion. ADR använder versionshantering i användardatabasen där den är aktiverad. Detta kan påverka databasens storlek avsevärt. Dessutom kan du behöva planera för databastillväxten samt den möjliga platsen för PVS:n för att säkerställa bra prestanda om ADR är aktiverat. Så det är vettigt att medvetet aktivera den här funktionen.
Experimentet:förberedande fas
Vi satte upp ett experiment för att utforska den nya funktionen och se effekten av ADR på storleken på transaktionsloggen samt på hastigheten för ÅTERSTÄLLNING. I vårt experiment skapar vi två identiska databaser med en enda säkerhetskopia och sedan aktiverar vi ADR endast på en av dessa databaser. Lista 2 visar de förberedande stadierna för uppgiften.
[expandera titel =”Kod”]
-- 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; [/expand]
Fig. 1 visar utdata från SQL-satsen i Lista 2 avsnitt 2c. Vi fångade också storleken på databasfilerna och användningen av transaktionsloggfilen. (se fig. 3).
Fig. 1 Bekräfta att ADR är konfigurerad
Fig. 2 Granska filstorlekar för databasdata
Fig. 3 Kontrollera storleken på loggen som används för båda databaserna
Experimentet:exekveringsfasen
När vi har fångat de detaljer vi behöver för att fortsätta, exekverar vi SQL-koden från listor 3 och 4 i etapper. De två listorna är likvärdiga, men vi kör dem på två identiska databaser separat. Först gör vi en INSERT (Listing 3, 3a), sedan utför vi en DELETE (Listing 3, 3b) som vi sedan rullar tillbaka. Lägg märke till att i både INSERT och DELETE har vi kapslat in operationerna i transaktioner. Notera också att INSERT exekveras 50 gånger. Vid varje exekveringsstadium, dvs mellan 3a, 3b och 3c, fångar vi transaktionslogganvändningen med hjälp av koden i Listing 2,2e. Detta är samma sak för avsnitten 4a, 4b och 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;
Fig. 4 och 5 visar oss att SELECT INTO-operationen tog 6 millisekunder mer i TSQLV4_ADR-databasen där vi aktiverade Accelerated Database Recovery. Vi ser också i fig. 6 att vi har större användning av transaktionsloggar i databasen TSQLV4_ADR. Jag blev särskilt förvånad över detta, så jag upprepade experimentet flera gånger för att säkerställa att jag fick det här resultatet konsekvent.
Fig. 4 Infoga exekveringstid för TSQLV4_NOADR
Fig. 5 Infoga körtid för TSQLV4_ADR
Fig. 6 Transaktionslogganvändning efter infogning
-- 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;
Fig. 7 och 8 visar oss att DELETE-operationen tog betydligt längre tid att slutföras i TSQLV4_ADR-databasen där vi aktiverade Accelerated Database Recovery trots att samma antal rader raderades i båda databaserna. Den här gången har vi dock större användning av transaktionsloggar i databasen TSQLV4_NOADR.
Fig. 7 Ta bort exekveringstid för TSQLV4_NOADR
Fig. 8 Ta bort exekveringstid för TSQLV4_ADR
Fig. 9 Transaktionslogganvändning efter borttagningar
Vid det här laget började det bli uppenbart att DML-operationer tar längre tid i databaser med ADR aktiverat. Detta förklarar delvis varför funktionen är avstängd i första hand. När man tänker djupt på det är det vettigt eftersom SQL Server måste lagra radversionerna i PVS medan en infogning, uppdatering eller borttagning körs. Oavsett hur lång tid DML tar, finner vi att utfärdandet av en ROLLBACK med ADR påslagen tar mindre än 1 millisekund (se Fig. 10 – 13). I vissa fall kan den snabba återställningen kompensera för överkostnaderna för själva DML, men inte i alla fall!
Fig. 10 exekveringstid för ROLLBACK (Efter DELETE) på TSQLV4_NOADR
Fig. 11 Körningstid för ROLLBACK (Efter DELETE) på TSQLV4_ADR
Fig. 12 exekveringstid för ROLLBACK (efter INSERT) på TSQLV4_NOADR
Fig. 13 Exekveringstid för ROLLBACK (Efter DELETE) på TSQLV4_ADR
Slutsats
Accelererad databasåterställning är en av de fantastiska funktionerna som släppts i SQL Server 2019. Men som med alla extremt trevliga saker i livet måste någon betala för det. ADR kan ha en negativ inverkan på prestanda i vissa scenarier, så det är viktigt att utvärdera ditt scenario noggrant innan du implementerar ADR i din produktionsdatabas. Microsoft rekommenderar specifikt Accelerated Database Recovery för databaser som stöder arbetsbelastningar med mycket långa transaktioner, överdriven ökning av transaktionsloggar eller frekventa avbrott relaterade till en långvarig återställning.
Referenser
Accelererad databasåterställning
Hur fungerar accelererad databasåterställning?
Accelererad databasåterställning