Accelerated Database Recovery (ADR) no SQL Server

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:
Analysis – varre o log para determinar o estado das transações no momento da parada.
Redo – refaz operações commitadas para trazer o banco ao estado consistente.
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 só 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!





