Continuando a linha de posts sobre Backup e já partindo para um intermédio entre Segurança dos dados e Disponibilidade, o foco da vez é o famoso Recovery Model, ou simplesmente Modelo de Recuperação.
Venho escrevendo sobre backup ultimamente pois tenho ciência que é um dos pontos fortes e de mais necessidades no que se refere à Administração de banco de dados, pois uma vez perdidos, sem backup seus dados jamais serão recuperados, e então pouco adianta tunning, segurança de acesso, etc etc...
O Modelo de recuperação de um banco de dados está intimamente ligado ao assunto Backup, visto que baseado no modelo de recuperação configurado para determinada base de dados, você terá ou não possibilidades de recovery bem como uma diferenciação na administração e manutenção desta determinada base.
Antes da criação de uma nova base de dados é necessário bastante planejamento para esta, visto que ela requer diversos cuidados prévios para que não fuja ao controle, como:
- Definição da política de backup a ser adotada para a mesma.
- Definição do Recovery Model a ser configurado.
- Definição de permissões de acesso, entre outras.
Para um bom entendimento sobre Recovery Model, e porque este deve ser tratado "com carinho", segue minhas considerações sobre cada um dos três tipos:
Recovery Model "Simple"
- Este é o modelo que requer menor esforço administrativo relacionado ao controle do tamanho do log de transações, porém é o que mais expõe o banco ao qual está configurado à perda de dados, este Recovery Model não permite backup do log de transações e consequentemente não permite restaurações além do momento do término do backup (Full ou Diferencial).
- Benefícios e aplicação: Pelo motivo de as transações não serem logadas, não requer administração ativa do log de transações, aplica-se este Recovery Model principalmente em ambientes de Homologação, Testes e Desenvolvimento, desde que estes permitam (com base no negócio) que haja perda de dados não presentes em backups previamente realizados.
- Principais Riscos: Deve-se ter total atenção, para erroneamente não configurar este modelo de recuperação em ambientes de produção com a finalidade de contenção do tamanho do arquivo de log de transações (.ldf), pois como é conhecida uma famosa frase no meio dos DBAs: "DBA Administra banco de dados, Milagre a gente não faz".
Recovery Model "Bulk-Logged":
- Certamente um dos Modelos de Recuperação mais complexos e de menor entendimento presentes no SQL Server, este permite que operações de Bulk-Insert sejam minimamente logadas, ou seja, operações de inserção de grande massa de dados, caso fossem logadas normalmente aumentariam o tamanho do log de transações de modo que este poderia fugir ao controle, estourar espaço em disco, dentre outros problemas.
- Benefícios e aplicação: Quando há grandes e frequentes inserções de massa de dados, conforme previamente citado, há um grande benefício na utilização do modelo de recuperação "Bulk-Logged", pois este evita que o Administrador da base de dados perca o controle do tamanho do log de transações.
- Advertência: Como não existe "almoço grátis", paga-se um preço por esta "mágica" realizada pelo recovery model Bulk-Logged. Embora o arquivo de Log de Transações (.ldf) não cresça com a inserção de dados em massa (Bulk Operations), o backup de log levará consigo todos os extents (conjunto de 8 páginas de dados) que contem páginas alteradas nestas operações, logo é vantajoso utilizá-lo por não aumentar o tamanho do arquivo, porém é necessário ter em mente que seu backup de log conterá não todas as páginas, mas todos os extents que tiveram páginas alteradas. Portando, utilize-o com moderação.
Recovery Model "Full"
"Com grandes poderes vem grandes responsabilidades" - (Benjamin Parker).
- Não há dúvidas de que este seja o mais poderoso dentre todos os modelos de recuperação no SQL Server, o que te permite maior segurança em relação à não exposição a perda de dados. Em contrapartida, é o que existe maior esforço administrativo e atenção quando à manutenção de um banco com teste modelo configurado.
- Benefícios: É possível que sua exposição à perda de dados seja bem próximo a zero, uma vez que este modelo de recuperação permite a realização de restores em um ponto específico no tempo, restore em pontos prévios à falhas, restore com auxílios do backup tail do log, dentre outros.
- Principais Riscos: Tendo configurado o modelo de recuperação Full, obrigatoriamente deve-se realizar frequentemente o backup do log de transações, uma vez que para garantir toda este leque de opções de recuperação, as transações são logadas e fazem com que o arquivo de log de transações cresça a medida que o banco é utilizado. O overhead administrativo é muito maior em relação aos demais modelos de recuperação. Caso não se tenha o cuidado de fazer backups de logs frequentemente, ou por exemplo um job de backup falhe, corre-se um grande risco de estouro de espaço e com isto, o SQL Server fica impossibilidade de gravar novas transações, uma vez que não terá espaço suficiente para registrar estas transações no arquivo de log.
Este foi apenas um overview sobre "RECOVERY MODEL" no SQL Server, quaisquer dúvidas ou sugestões fique a vontade para comentar, criticar, elogiar ou o que quer que tenha vontade de escrever no espaço para comentários....
Abraços, e obrigado pela leitura.
Edvaldo Castro
@edvaldocastro