Modelos de Recuperação no SQL Server: Simple, Full e Bulk-Logged

O recovery model de uma base SQL Server controla como a informação do transaction log é gerida e quais opções de backup e restore estão disponíveis. Existem três modelos: Simple, Full e Bulk-Logged. A escolha deve ser uma decisão de recuperação, não uma reação rápida a um ficheiro de log que cresceu.

Por que o recovery model é importante

Cada transação é registada no transaction log para manter consistência. O recovery model influencia quando o espaço inativo do log pode ser reutilizado e se transaction-log backups fazem parte da estratégia.

Por isso ele afeta diretamente quanto trabalho pode ser perdido e se point-in-time recovery é possível.

Simple recovery model

Em Simple, SQL Server pode reutilizar espaço inativo do log depois dos checkpoints adequados. Transaction-log backups não são suportados. A recuperação depende normalmente de backups de dados, como full e differential.

Simple pode ser adequado quando perder alterações desde o último backup é aceitável ou quando os dados podem ser recriados a partir de outra fonte.

Full recovery model

Full é utilizado quando o negócio precisa de recuperação mais fina e log backups. Depois de a log chain estar corretamente estabelecida, log backups regulares permitem recuperar para um ponto específico no tempo, desde que toda a cadeia necessária esteja disponível.

Um detalhe importante: em Full, fazer full backup não substitui os log backups. Sem log backups regulares, o log pode continuar a crescer.

Bulk-Logged recovery model

Bulk-Logged é uma variação de Full que permite minimal logging em determinadas operações bulk, reduzindo o uso de log nesses cenários. Continua a exigir transaction-log backups, mas a recuperação durante operações minimamente registadas tem limitações adicionais.

Normalmente é utilizado de forma controlada, não como configuração permanente sem motivo.

Recovery model e estratégia de backup precisam combinar

Escolher Full sem fazer log backups não cria uma estratégia completa. Escolher Simple e ao mesmo tempo exigir point-in-time recovery também é contraditório. O modelo e os backups precisam responder ao mesmo objetivo do negócio. Para uma explicação específica, consulte os tipos de backup no SQL Server.

Exemplo de escolha baseada no requisito

Uma base de reporting reconstruída todas as noites a partir de outra fonte e que pode perder alterações temporárias do dia pode funcionar com Simple. Já uma base de pedidos onde perder 30 minutos de transações é inaceitável normalmente exige Full com log backups frequentes.

Mudar recovery model exige planeamento

O comando é simples, mas as consequências não são. Ao passar de Simple para Full é preciso estabelecer corretamente a cadeia de backups. Ao passar de Full para Simple, o DBA muda o tipo de recuperação que será possível no futuro e deve rever os jobs de log backup.

Recovery model não é solução rápida para um log cheio

Mudar uma base de produção de Full para Simple apenas porque o log cresceu pode destruir a estratégia de recuperação. Primeiro investiga por que o log não está a truncar ou por que está a crescer: podem faltar log backups, existir transações longas, condições de availability replica ou operações muito grandes. Explore como diagnosticar um SQL Server lento para aprofundar este ponto.

Perguntas que o DBA deve fazer

• Quanto dado recente o negócio pode perder?
• Point-in-time recovery é necessário?
• Com que frequência podem ocorrer log backups?
• Onde serão guardados os backups?
• Quanto tempo demora o restore?
• Existem tecnologias de alta disponibilidade dependentes do recovery model?
• A estratégia de restore já foi testada?

Como consultar o recovery model

SELECT name, recovery_model_desc
FROM sys.databases
ORDER BY name;

Como alterar

ALTER DATABASE [Sales]
SET RECOVERY FULL;

O comando é fácil. Decidir se ele é correto é o verdadeiro trabalho de DBA. O artigo complementar sobre o trabalho de um DBA de SQL Server desenvolve este tema.

Formação relacionada

No curso de DBA SQL Server da Goalbi Academy, recovery models são ligados diretamente a estratégia de backups, log chains e exercícios de restore.

Ver o curso de Administração de Bases de Dados SQL Server

Precisa de ajuda para escolher o curso certo?

Se não tiver a certeza por onde começar, contacte a Goalbi Academy e diga-nos qual é o seu nível atual e o que pretende aprender.

Contactar a Goalbi Academy

Referências

Recovery Models (SQL Server) - SQL Server

Set database recovery model - SQL Server

Transaction log backups - SQL Server