Accelerated Database Recovery no SQL Server 2019

Muitos DBAs sabem o quanto é ruim quando o SQL Server sofre um crash por qualquer motivo e fica no status “in-recovery”, esse status indica que o banco de dados está lendo o log file e fazendo as operações necessárias para trazer o banco para um estado consistente. Durante esse tempo (que pode ser longo), o banco fica indisponível para qualquer coisa. Não há muito o que se possa fazer a não ser acompanhar o log da instância e esperar…
O Accelerated Database Recovery promete resolver este problema.

O tradicional processo de recovery no SQL Server consiste de 3 fases:

• Análise: o log file é lido de trás pra frente, a partir do último checkpoint, marcando as transações como committed (confirmadas) e uncommitted (não confirmadas).
• Redo: o log file é lido de trás para frente, a partir da uncommitted transaction mais antiga, e refaz todas as transações.
• Undo: o log file é lido do fim para trás e faz rollback de todas as transações não confirmadas (uncommitted).

Dessa forma, o tempo de recovery da instância é diretamente afetado pelo tamanho da transação mais longa no momento do desastre.

A arquitetura do Accelerated Database Recovery

O novo processo (ADR) vem resolver esse problema criando alguns componentes que farão o recovery do banco ser muito mais rápido:

• Persisted Version Store (PVS): Responsável por versionar os registros no próprio banco de dados ao invés de usar a tempdb, como acontece no isolation level SNAPSHOT, por exemplo.
• Secondary Log (sLog): versão “in-memory” do log tradicional (tLog). É utilizado para guardar os dados de operações não-versionadas (como DDLs ou aquisição de locks, por exemplo). Esse log é persistido em disco a cada checkpoint.
• Logical Revert: Utiliza o PVS para desfazer as transações não confirmadas, assim o scan do transaction log é evitado.
• Cleaner: Remove as versões que não serão mais necessárias para um eventual recovery.

Dessa forma, o tempo de recovery é absurdamente menor pois o transaction log é lido a partir do último checkpoint e não mais a partir da última uncommitted transaction.

Vamos ver isso na prática. Vou criar um banco de dados, iniciar uma transação e fazer várias inserções.

Demonstração

CREATE DATABASE [ADR_DEMO]
GO

USE [ADR_DEMO]
GO

CREATE TABLE tblTeste (
    A INT IDENTITY (1,1) NOT NULL PRIMARY KEY,
    B UNIQUEIDENTIFIER DEFAULT NEWID(),
    C UNIQUEIDENTIFIER DEFAULT NEWID(),
    D DATETIME DEFAULT GETDATE()
                    )
GO

BEGIN TRAN  
WHILE (1=1)
        INSERT INTO tblTeste (B) VALUES (NEWID())

Deixei esse script rodar por cerca de 2 minutos e então dei um restart na instância do SQL Server:

Verificando o log da instância, constatamos que o recovery levou cerca de 26 segundos para ser finalizado:

Agora faremos o mesmo teste novamente, mas dessa vez utilizando o Accelerated Database Recovery:

ALTER DATABASE ADR_DEMO SET ACCELERATED_DATABASE_RECOVERY = ON;

-- Esta nova coluna na sys.databases indica se a feature está ativa.

SELECT name, is_accelerated_database_recovery_on from sys.databases

Repetimos o procedimento: execução do script e restart da instância. O rollback é instantâneo!

Um adendo: essa feature é habilitada por padrão no Azure SQL Database.

Conclusão

Então se seu banco já ficou indisponível um bom tempo esperando o recovery ou tem várias longas transações possivelmente fazendo uso intenso do transaction log, talvez o ADR seja pra você.

Espero que tenham gostado, pessoal. Até a próxima.