Recovery Model

Fala aee pessoal, espero que estejam todos ótimos !!

No post de hoje, vamos bater um papo sobre um assunto extremamente importante, backup.

Mas Ithalo, o titulo do post é Recovery Model, e o assunto é backup?

Calma.. calma.. calma..

Para que o post não fique muito extenso, vamos dividi-lo em 3 partes (1 – Recovery Model, 2 – Backup – 3 Restore).

Acho muito provável que se você está aqui, certamente já fez um “ctrl + c” e “ctrl + v”,  em uma pastinha e em seguida colocou um _old na pastinha anterior, neh? Não minta pra mim…

E você está certissímo, na hora de recuperar os arquivos, tudo está ali, facinho.

Bom, mas e como é esta rotina no SQL SERVER?


Vamos entender!

Como tudo na nossa vida, até para fazer um backup nós precisaremos analisar um pouco antes de agir.

Primeiramente, quantas bases nós criamos dessa forma?

Criação de uma base teste

Ou ainda usando a query

CREATE DATABASE BASE_TESTE?

Claro que as duas formas funcionam, mas será que é a melhor forma?

Hoje quando criamos uma nova base, “suas configurações iniciais” são basicamente uma cópia da base model.

Consequentemente o Recovery Model da base que você está criando será exatamente igual da base “model”.

O Recovery  quê???

Bom vamos lá, “ Um modelo de recuperação é uma propriedade de banco de dados que controla como as transações são registradas, se o log de transações exige (e permite) backup e que tipos de operações de restauração estão disponíveis. ”

https://docs.microsoft.com/pt-br/sql/relational-databases/backup-restore/recovery-models-sql-server?view=sql-server-ver15

Mas o que isso tem a ver com o backup Ithalo?

Bora lá. Vamos executar a query abaixo:

SELECT recovery_model_desc  
   FROM sys.databases  
      WHERE name = 'Nome_da_Base' ; --Colocar o nome da base desejada 
GO  

Temos aqui 3 possibilidades de resultados: Simple, Full e Bulk-logged.

Vamos focar este post nos Recovery Model Full e Simple, caso tenha curiosidade em conhecer sobre o Bulk-logged, sugiro esse post do Fabiano Amorim

Uma outra forma de verificar o Recovery Model da sua base é clicar com o botão direito na base, properties -> options

Particularmente gosto mais de olhar via T-SQL.


Recovery Model

Quando executamos Insert – Delete – Update, no nosso banco de dados, antes de gravar de fato no MDF, primeiramente o SQL grava no LDF.

Sabendo-se que o SQL grava primeiramente no ldf, para em seguida “jogar” para o mdf, vamos agora entender a diferença entre Recovery Full e Recovery Simple.

Recovery Simple:

Quando executamos uma transação e nossa base de dados está configurada como Recovery Simple, assim que a transação é comitada, o SQL automaticamente limpa o ldf.

E aqui a gente precisa entender o cenário e a importância dessa base, pois uma vez que não temos dados no LDF, não podemos efetuar o backup do mesmo. Consequentemente em caso de “update sem where” o que vai nos salvar nesse caso é o último backup feito. Se seu ambiente você consegue executar este backup frequentemente, ou não existe problema em uma perda expressiva de dados. Este Recovery é joia!

Mas se você não pode ter uma perda grande de dados, e seu backup não é tão frequente, dê uma olhadinha no:

Recovery Full:

Se no recovery simple o SQL te ajuda a manter o ldf sempre limpinho, bonitinho, o FULL já faz o contrário disso, ele nunca limpa o ldf.

E, considerando o cenário descrito anteriormente, este recovery se torna no mínimo “mais viável” que o full, não é mesmo?

O grande problema aqui é que o ldf tende a ficar gigante e com isso, podemos ter um problema de espaço.

Para resolver este problema de espaço, basta que façamos o backup do ldf. E após o backup, automaticamente o SQL faz aquela limpeza.

Para maiores esclarecimentos aconselho assistirem este vídeo do Fabricio Lima.

No próximo post, vamos falar um pouco sobre os tipos de backups.

Espero que tenham gostado.

Um abraço!!

E até a próxima!!!

1 comentário

  1. Muita gente não sabe a diferença do Recovery Model FULL e SIMPLE. Já cansei de pegar Consultorias de Banco de Dados onde a base está com o Recovery Model FULL e sem fazer Backup de Log. Com isso, o arquivo de log cresce infinitamente até acabar com o espaço em disco e causar problemas mais sérios para o cliente. Portanto, esse assunto é de extrema importância em um Banco de dados! Mandou bem! =)

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *