En oversigt over traditionel genopretning
Som med alle relationelle databasesystemer garanterer SQL Server holdbarheden af data ved at implementere nedbrudsgendannelse. Holdbarhed i akronymet ACID, som refererer til karakteristika for transaktioner i relationelle databaser betyder, at vi kan være sikre på, at hvis databasen pludselig svigter, er vores data sikre.
SQL Server implementerer denne funktion ved hjælp af transaktionsloggen. Ændringer foretaget af alle datamanipulationsoperationer i SQL Server fanges i transaktionsloggen, før de anvendes på datafiler (gennem checkpoint-processen), hvis det er nødvendigt at rulle tilbage eller rulle fremad.
Den trefasede nedbrudsgendannelsesproces i SQL Server er som følger:
Analyse – SQL Server læser transaktionsloggen fra det seneste kontrolpunkt til slutningen af transaktionsloggen
Gentag – SQL Server afspiller loggen fra den ældste ikke-forpligtede transaktion til slutningen af loggen
Fortryd – SQL Server læser loggen fra slutningen af loggen til den ældste ikke-forpligtede transaktion og nulstiller alle transaktioner, der var aktive under nedbruddet
Erfarne DBA'er ville på et eller andet tidspunkt i deres karriere have haft den nedslående oplevelse at vente hjælpeløst på, at crash recovery blev fuldført på en meget stor database. Transaktion ROLLBACK bruger en lignende mekanisme som crash recovery-processen. Microsoft har forbedret gendannelsesprocessen betydeligt i SQL Server 2019.
Accelereret databasegendannelse
Accelereret databasegendannelse er en ny funktion baseret på versionering, der markant øger gendannelseshastigheden i tilfælde af en ROLLBACK eller gendannelse fra et nedbrud.
I SQL Server 2019 ændrer tre nye mekanismer i SQL Server-motoren måden, hvorpå gendannelse håndteres, og reducerer effektivt den tid, der kræves til at udføre en rollback/rollforward.
Persistent Version Store (PVS) – Indfanger rækkeversioner i den pågældende database. Persistent Version Store kan defineres i en separat filgruppe af ydeevne- eller størrelsesårsager
Logisk tilbagevenden – Bruger rækkeversionerne, der er gemt i PVS, til at udføre tilbagerulning, når en tilbagerulning påkaldes for en bestemt transaktion, eller når fortrydelsesfasen for gendannelse af nedbrud påkaldes.
sLog – Dette står muligvis for sekundær log . Det er en log-stream i hukommelsen, der bruges til at fange operationer, der ikke kan versioneres. Når ADR er aktiveret i databasen, genopbygges sLog'et altid under analysefasen af crash recovery. Under gentag fase, bruges sLog snarere end selve transaktionsloggen, hvilket gør processen hurtigere, da den sidder i hukommelsen og indeholder færre transaktioner. Den traditionelle gendannelsesproces håndterer transaktioner fra det sidste kontrolpunkt. sLog'et bruges også under fortryd fase.
Renere – Fjerner unødvendige rækkeversioner fra PVS. Microsoft tilbyder også en lagret procedure til manuelt at gennemtvinge en oprydning af unødvendige rækkeversioner.
-- 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';
Accelereret databasegendannelse er som standard slået FRA
Det faktum, at ADR er slået fra i SQL Server 2019 som standard, kan virke overraskende for nogle DBA'er, da det ser ud til at være så fantastisk en funktion. ADR bruger versionsstyring i den brugerdatabase, hvor den er aktiveret. Dette kan påvirke databasestørrelsen betydeligt. Derudover skal du muligvis planlægge databasevæksten samt den mulige placering af PVS for at sikre god ydeevne, hvis ADR er aktiveret. Så det giver mening bevidst at aktivere denne funktionalitet.
Eksperimentet:forberedende fase
Vi satte et eksperiment op for at udforske den nye funktion og se virkningen af ADR på størrelsen af transaktionsloggen samt på hastigheden af TILBAGE. I vores eksperiment opretter vi to identiske databaser ved hjælp af et enkelt backupsæt, og så aktiverer vi kun ADR på én af disse databaser. Liste 2 viser de forberedende stadier til opgaven.
[expand title =”Kode”]
-- 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; [/udvid]
Fig. 1 viser outputtet af SQL-sætningen i liste 2 afsnit 2c. Vi fangede også størrelsen af databasefilerne og brugen af transaktionslogfilen. (se fig. 3).
Fig. 1 Bekræft, at ADR er konfigureret
Fig. 2 Gennemgå databasedatafilstørrelser
Fig. 3 Tjek størrelsen på log, der bruges til begge databaser
Eksperimentet:Udførelsesfasen
Når vi har fanget de detaljer, vi skal bruge for at fortsætte, udfører vi SQL-koden fra lister 3 og 4 i trin. De to lister er ækvivalente, men vi udfører dem på to identiske databaser separat. Først laver vi en INSERT (Listing 3, 3a), derefter udfører vi en DELETE (Listing 3, 3b), som vi efterfølgende ruller tilbage. Bemærk, at vi i både INSERT og DELETE har indkapslet operationerne i transaktioner. Bemærk også, at INSERT udføres 50 gange. På hvert trin af udførelsen, dvs. mellem 3a, 3b og 3c, fanger vi brugen af transaktionsloggen ved hjælp af koden i Listing 2,2e. Dette er det samme for sektionerne 4a, 4b og 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 og 5 viser os, at SELECT INTO-operationen tog 6 millisekunder mere i TSQLV4_ADR-databasen, hvor vi aktiverede Accelerated Database Recovery. Vi ser også i fig. 6, at vi har større brug af transaktionslog i TSQLV4_ADR-databasen. Jeg var især overrasket over dette, så jeg gentog eksperimentet flere gange for at sikre, at jeg fik dette resultat konsekvent.
Fig. 4 Indsæt eksekveringstid for TSQLV4_NOADR
Fig. 5 Indsæt eksekveringstid for TSQLV4_ADR
Fig. 6 Transaktionslogbrug efter indsættelser
-- 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 og 8 viser os, at DELETE-operationen tog betydeligt længere tid at blive gennemført i TSQLV4_ADR-databasen, hvor vi aktiverede Accelerated Database Recovery, selvom det samme antal rækker blev slettet i begge databaser. Denne gang har vi dog større brug af transaktionslog i TSQLV4_NOADR-databasen.
Fig. 7 Slet eksekveringstid for TSQLV4_NOADR
Fig. 8 Slet eksekveringstid for TSQLV4_ADR
Fig. 9 Transaktionslogbrug efter sletninger
Nu var det ved at blive tydeligt, at DML-operationer tager længere tid i databaser med ADR aktiveret. Dette forklarer til dels, hvorfor funktionen er slået fra i første omgang. Når man tænker dybt over det, giver det mening, da SQL Server skal gemme rækkeversionerne i PVS, mens en indsættelses-, opdaterings- eller sletningsoperation kører. Uanset hvor lang tid DML'en tager, finder vi ud af, at udstedelse af en ROLLBACK med ADR slået TIL tager mindre end 1 millisekund (se fig. 10 – 13). I nogle tilfælde kan den hurtige tilbagerulning kompensere for selve DML'ens overhead, men ikke i alle tilfælde!
Fig. 10 eksekveringstid for ROLLBACK (efter SLETT) på TSQLV4_NOADR
Fig. 11 Udførelsestid for ROLLBACK (Efter SLETT) på TSQLV4_ADR
Fig. 12 Udførelsestid for ROLLBACK (Efter INSERT) på TSQLV4_NOADR
Fig. 13 Udførelsestid for ROLLBACK (Efter SLETT) på TSQLV4_ADR
Konklusion
Accelereret databasegendannelse er en af de fantastiske funktioner, der er udgivet i SQL Server 2019. Men som med alle ekstremt gode ting i livet, skal nogen betale for det. ADR kan have en negativ effekt på ydeevnen i visse scenarier, så det er vigtigt at evaluere dit scenarie omhyggeligt, før du implementerer ADR i din produktionsdatabase. Microsoft anbefaler specifikt Accelerated Database Recovery til databaser, der understøtter arbejdsbelastninger med meget langvarige transaktioner, overdreven vækst af transaktionslogfiler eller hyppige udfald relateret til en langvarig genopretning.
Referencer
Accelereret databasegendannelse
Hvordan fungerer accelereret databasegendannelse?
Accelereret databasegendannelse