Skip to main content

Command Palette

Search for a command to run...

Accelerated Database Recovery (ADR) no SQL Server

Published
Accelerated Database Recovery (ADR) no SQL Server
S

O Prof. Landry Duailibe é especialista em Microsoft SQL Server desde 1999, Microsoft Certified Trainer, professor universitário e criador do canal SQL Server Expert no YouTube, onde compartilha conteúdo técnico semanal para DBAs e profissionais de dados. Já ajudou milhares de alunos a evoluírem suas habilidades com SQL Server e conquistarem melhores oportunidades na área de dados.

Este é um guia avançado, mas antes de entrar no ADR, vou começar revisando como o SQL Server se recupera no modo padrão (sem ADR). Em seguida, vou mostrar como o ADR funciona, quando habilitar.

Como funciona a recuperação sem ADR (padrão do SQL Server)

Quando o SQL Server precisa recuperar um banco (crash, restart inesperado ou após restore), ele segue o modelo ARIES (Algorithms for Recovery and Isolation Exploiting Semantics)

O modelo ARIES possui três fases:

  1. Analysis – varre o log para determinar o estado das transações no momento da parada.

  2. Redo – refaz operações commitadas para trazer o banco ao estado consistente.

  3. Undo – desfaz o que estava em andamento no momento da falha (varrendo o log “para trás”).

O problema clássico: transações longas. No modelo tradicional, o tempo de recuperação e de rollback é proporcional ao tamanho/duração da transação ativa mais longa. Além disso, o log de transações não pode ser truncado enquanto essas transações não forem recuperadas, motivo comum de crescimento do log.

Você pode verificar o motivo de retenção com:

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases

O campo log_reuse_wait_desc indica, por exemplo, ACTIVE_TRANSACTION, LOG_BACKUP, OLDEST_PAGE, etc.

O que é o ADR e por que ele existe

O Accelerated Database Recovery (ADR) redesenha o processo de recuperação para torná-lo rápido e consistente, mesmo na presença de transações longas. Os três benefícios principais:

  • Recuperação rápida e previsível (independente do tamanho da transação).

  • Rollback instantâneo de transações.

  • Trunca rapidamente o log, reduzindo crescimento desnecessário.

Como o ADR consegue isso

  • Versiona todas as modificações físicas e desfaz operações que não podem ser versionadas.

  • Introduz quatro componentes:

    • PVS (Persisted Version Store): armazena as versões de linhas no próprio banco (não na TempDB).

    • Logical Revert: desfaz no nível de linha, liberando locks imediatamente após erros.

    • SLOG (secondary log stream): log secundário de baixo volume para operações não versionadas, acelerando redo/undo.

    • Cleaner: limpa versões obsoletas no PVS de forma assíncrona.

Nota sobre snapshot/RCSI: com ADR habilitado, as versões de linha usadas por SNAPSHOT/RCSI também passam a residir no PVS do banco (em vez da TempDB). Em bases sem ADR, essas versões continuam na TempDB.


Onde o ADR está disponível e comportamento padrão

  • Disponível a partir do SQL Server 2019, desabilitado por padrão, habilitar por banco.

  • Azure SQL Database e Azure SQL Managed Instance o ADR está sempre habilitado.


Habilitando, checando e posicionando o PVS (filegroup dedicado)

Habilitar/Desabilitar ADR (por banco)

-- Habilitar
ALTER DATABASE [SeuBanco] SET ACCELERATED_DATABASE_RECOVERY = ON

-- Verificar status
SELECT name, is_accelerated_database_recovery_on
FROM sys.databases

-- Desabilitar
ALTER DATABASE [SeuBanco] SET ACCELERATED_DATABASE_RECOVERY = OFF

Colocando o PVS em um filegroup próprio (recomendado para isolar IO e facilitar capacity planning)

-- 1) Criar filegroup e arquivo(s) de dados
ALTER DATABASE [SeuBanco] ADD FILEGROUP [VersionStoreFG]
GO
ALTER DATABASE [SeuBanco]
ADD FILE (
  NAME = N'VersionStore',
  FILENAME = N'E:\DATA\VersionStore.ndf',
  SIZE = 500MB, FILEGROWTH = 64MB
) TO FILEGROUP [VersionStoreFG]

-- 2) Desligar ADR para permitir a troca do PVS
ALTER DATABASE [SeuBanco] SET ACCELERATED_DATABASE_RECOVERY = OFF
GO

-- Forçar limpeza do PVS atual e aguardar terminar
EXEC sys.sp_persistent_version_cleanup N'SeuBanco'

-- Validar que zerou
SELECT DB_NAME(database_id) AS db_name, persistent_version_store_size_kb
FROM sys.dm_tran_persistent_version_store_stats
WHERE DB_NAME(database_id) = N'SeuBanco'

-- 3) Reativar ADR já apontando para o novo FG
ALTER DATABASE [SeuBanco] SET ACCELERATED_DATABASE_RECOVERY = ON
(PERSISTENT_VERSION_STORE_FILEGROUP = [VersionStoreFG])

Monitorando PVS e efeitos do ADR

Use a DMV abaixo para acompanhar o tamanho/ritmo do PVS:

SELECT DB_NAME(database_id) as Banco,
persistent_version_store_size_kb / 1024.0 as PVS_MB
FROM sys.dm_tran_persistent_version_store_stats
WHERE persistent_version_store_size_kb > 0

Para o log, continue rastreando log_reuse_wait_desc e ajuste a rotina de backups de log conforme necessário.


Ajustes importantes no SQL Server 2022

O SQL Server 2022 trouxe MTVC – Multi-Threaded Version Cleanup, permitindo paralelizar a limpeza do PVS. Por padrão, usa 1 thread por instância; você pode aumentar com sp_configure:

EXEC sp_configure 'show advanced options', 1
RECONFIGURE

-- Suba gradualmente
EXEC sp_configure 'ADR Cleaner Thread Count', 2
RECONFIGURE WITH OVERRIDE

Interações críticas (replicação, CDC, AG, etc.)

  • Replicação transacional / CDC: para permitir que o Log Reader colete mudanças, o truncamento agressivo do ADR é atenuado. Planeje tamanho de log e janelas de captura.

  • Always On AG: ADR reduz tempos de redo em secundários e acelera failovers (menos indisponibilidade).


Quando usar (ou não) ADR

Use ADR se você enfrenta:

  • Transações longas;

  • Crescimento recorrente do log por retenção;

  • Janelas de indisponibilidade durante crash/failover/rollback.

Reavalie se o workload é OLTP extremamente write-intensive com altíssima taxa de rollback, gerando quantidade grande de versionamentos de linhas e pressão no cleaner.

Notas de versão (2025 Preview)

O SQL Server 2025 CTP permite habilitar ADR na TempDB, trazendo rollback instantâneo e truncamento agressivo também para transações que usam objetos temporários. Se for habilitar, reserve espaço para PVS na TempDB.

Conclusão

O ADR não é só “ligar e esquecer”, ele resolve indisponibilidade por transações longas, mas exige acompanhamento constante do PVS. Com bom planejamento (filegroup dedicado, métricas, e ajustes graduais), você terá benefícios como rollback instantâneo e menor tempo de recuperação.

Fui, mas volto com mais SQL Server em breve!

✍️ Sobre o autor
O Prof. Landry é especialista em Microsoft SQL Server desde 1999, Microsoft Trainer, Professor Universitário e criador do canal SQL Server Expert no YouTube, com conteúdo técnico semanal para DBAs e profissionais de dados.

🚀 Quer aprender mais sobre SQL Server?
👉 Me acompanhe no LinkedIn e inscreva-se no canal para não perder nenhuma dica prática!

More from this blog

S

SQL Server Expert

30 posts

O SQL Server Expert é o blog oficial do Prof. Landry Duailibe, dedicado a profissionais de dados que desejam dominar o Microsoft SQL Server em profundidade.