Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

Ripristino accelerato del database in SQL Server 2019

Una panoramica del recupero tradizionale

Come con tutti i sistemi di database relazionali, SQL Server garantisce la durabilità dei dati implementando il ripristino da arresto anomalo. La durabilità nell'acronimo ACID che fa riferimento alle caratteristiche delle transazioni nei database relazionali significa che possiamo essere certi che se il database si guasta improvvisamente, i nostri dati sono al sicuro.

SQL Server implementa questa funzionalità utilizzando il registro delle transazioni. Le modifiche apportate da tutte le operazioni di manipolazione dei dati in SQL Server vengono acquisite nel registro delle transazioni prima di essere applicate ai file di dati (attraverso il processo di checkpoint) nel caso sia necessario eseguire il rollback o il roll forward.

Il processo di ripristino da arresto anomalo in tre fasi in SQL Server è il seguente:

  • Analisi – SQL Server legge il registro delle transazioni dall'ultimo checkpoint fino alla fine del registro delle transazioni

  • Ripeti – SQL Server riproduce il registro dalla transazione non vincolata meno recente alla fine del registro

  • Annulla – SQL Server legge il registro dalla fine del registro alla transazione non vincolata meno recente e ripristina tutte le transazioni attive durante l'arresto anomalo

I DBA esperti a un certo punto della loro carriera avrebbero avuto l'esperienza scoraggiante di aspettare impotenti il ​​completamento del ripristino da crash su un database molto grande. Transaction ROLLBACK utilizza un meccanismo simile al processo di ripristino da arresto anomalo. Microsoft ha migliorato notevolmente il processo di ripristino in SQL Server 2019.

Recupero accelerato del database

Il ripristino accelerato del database è una nuova funzionalità basata sul controllo delle versioni che aumenta notevolmente la velocità di ripristino in caso di ROLLBACK o ripristino da un arresto anomalo.

In SQL Server 2019, tre nuovi meccanismi all'interno del motore di SQL Server modificano il modo in cui viene gestito il ripristino e riducono efficacemente il tempo necessario per eseguire un rollback/rollforward.

  • Persistent Version Store (PVS) – Acquisisce le versioni di riga all'interno del database in questione. Il Persistent Version Store può essere definito in un gruppo di file separato per motivi di prestazioni o dimensioni

  • Ripristino logico – Utilizza le versioni di riga archiviate in PVS per eseguire il rollback quando viene richiamato un rollback per una determinata transazione o quando viene richiamata la fase di annullamento del ripristino da arresto anomalo.

  • sLog – Questo probabilmente sta per secondario registro . È un flusso di registro in memoria utilizzato per acquisire operazioni di cui non è possibile eseguire la versione. Quando l'ADR è abilitato nel database, lo sLog viene sempre ricostruito durante la fase di analisi del crash recovery. Durante il ripristino fase, viene utilizzato lo sLog anziché il registro delle transazioni effettivo, rendendo il processo più veloce poiché si trova in memoria e contiene meno transazioni. Il tradizionale processo di recupero gestisce le transazioni dall'ultimo checkpoint. Lo sLog viene utilizzato anche durante l'annulla fase.

  • Detergente – Rimuove le versioni di riga non necessarie dal PVS. Microsoft fornisce anche una stored procedure per forzare manualmente la pulizia delle versioni di riga non necessarie.

-- 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';

Il ripristino accelerato del database è disattivato per impostazione predefinita

Il fatto che ADR sia disattivato in SQL Server 2019 per impostazione predefinita potrebbe sembrare sorprendente per alcuni DBA dato che sembra essere una funzionalità così eccezionale. ADR utilizza il controllo delle versioni nel database utente in cui è abilitato. Ciò può influire in modo significativo sulle dimensioni del database. Inoltre, potrebbe essere necessario pianificare la crescita del database e la possibile posizione del PVS per garantire buone prestazioni se ADR è abilitato. Quindi ha senso abilitare deliberatamente questa funzionalità.

L'esperimento:fase preparatoria

Abbiamo impostato un esperimento per esplorare la nuova funzionalità e vedere l'impatto dell'ADR sulla dimensione del registro delle transazioni e sulla velocità di ROLLBACK. Nel nostro esperimento, creiamo due database identici utilizzando un unico set di backup e quindi abilitiamo ADR solo su uno di questi database. Il Listato 2 mostra le fasi preparatorie per l'attività.

[expand title =”Codice”]

-- 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;

[/espandi]

La Fig. 1 mostra l'output dell'istruzione SQL nel Listato 2 sezione 2c. Abbiamo anche acquisito la dimensione dei file di database e l'utilizzo del file di registro delle transazioni. (vedi Fig. 3).

Fig. 1 Conferma che ADR è configurato

Fig. 2 Esamina le dimensioni dei file di dati del database

Fig. 3 Verifica la dimensione del registro utilizzato per entrambi i database

L'esperimento:fase di esecuzione

Una volta acquisiti i dettagli di cui abbiamo bisogno per procedere, eseguiamo il codice SQL dai Listing 3 e 4 in più fasi. I due elenchi sono equivalenti, ma li stiamo eseguendo separatamente su due database identici. Per prima cosa, eseguiamo un INSERT (Listato 3, 3a), quindi eseguiamo un DELETE (Listato 3, 3b) che successivamente eseguiremo il rollback. Si noti che sia in INSERT che in DELETE abbiamo incapsulato le operazioni nelle transazioni. Inoltre, prendi nota che INSERT viene eseguito 50 volte. Ad ogni fase dell'esecuzione, cioè tra 3a, 3b e 3c, catturiamo l'utilizzo del log delle transazioni con l'aiuto del codice nel Listato 2,2e. Lo stesso vale per le sezioni 4a, 4b e 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 e 5 ci mostrano che l'operazione SELECT INTO ha richiesto 6 millisecondi in più nel database TSQLV4_ADR in cui abbiamo abilitato il ripristino accelerato del database. Vediamo anche in Fig. 6 che abbiamo un maggiore utilizzo del registro delle transazioni nel database TSQLV4_ADR. Ne sono rimasto particolarmente sorpreso, quindi ho ripetuto l'esperimento più volte per assicurarmi di ottenere questo risultato in modo coerente.

Fig. 4 Inserire il tempo di esecuzione per TSQLV4_NOADR

Fig. 5 Inserire l'ora di esecuzione per TSQLV4_ADR

Fig. 6 Utilizzo del registro delle transazioni dopo gli inserimenti 

-- 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 e 8 ci mostrano che l'operazione DELETE ha richiesto molto più tempo per essere completata nel database TSQLV4_ADR in cui abbiamo abilitato il ripristino accelerato del database anche se lo stesso numero di righe è stato eliminato in entrambi i database. Questa volta, tuttavia, abbiamo un maggiore utilizzo del registro delle transazioni nel database TSQLV4_NOADR.

Fig. 7 Elimina il tempo di esecuzione per TSQLV4_NOADR

Fig. 8 Elimina il tempo di esecuzione per TSQLV4_ADR

Fig. 9 Utilizzo del registro delle transazioni dopo le eliminazioni

Ormai stava diventando ovvio che le operazioni DML richiedevano più tempo nei database con ADR abilitato. Questo spiega in parte perché la funzione è disattivata in primo luogo. Pensandoci profondamente, ha senso poiché SQL Server deve archiviare le versioni di riga nel PVS mentre è in esecuzione un'operazione di inserimento, aggiornamento o eliminazione. Qualunque sia il tempo impiegato dal DML, troviamo che l'emissione di un ROLLBACK con ADR attivato richiede meno di 1 millisecondo (vedi Fig. 10 – 13). In alcuni casi, il rapido rollback può compensare l'overhead del DML stesso, ma non in tutti i casi!

Fig. 10 Tempo di esecuzione per ROLLBACK (dopo DELETE) su TSQLV4_NOADR

Fig. 11 Tempo di esecuzione per ROLLBACK (dopo DELETE) su TSQLV4_ADR

Fig. 12 Tempo di esecuzione per ROLLBACK (dopo INSERT) su TSQLV4_NOADR

Fig. 13 Tempo di esecuzione per ROLLBACK (dopo DELETE) su TSQLV4_ADR

Conclusione

Il ripristino accelerato del database è una delle fantastiche funzionalità rilasciate in SQL Server 2019. Tuttavia, come per tutte le cose estremamente belle della vita, qualcuno deve pagare per questo. L'ADR può avere un impatto negativo sulle prestazioni in determinati scenari, quindi è importante valutare attentamente lo scenario prima di implementare l'ADR nel database di produzione. Microsoft consiglia specificamente il ripristino accelerato del database per i database che supportano carichi di lavoro con transazioni di lunga durata, crescita eccessiva del registro delle transazioni o interruzioni frequenti legate a un ripristino di lunga durata.

Riferimenti

  1. Recupero accelerato del database

  2. Come funziona il ripristino accelerato del database?

  3. Recupero accelerato del database