Olá Pessoal,

Estou aqui para compartilhar com vocês mais um caso do dia a dia que aconteceu comigo no dia de ontem.

Estava eu feliz da vida trabalhando em meu home office, quando recebi um e-mail de alerta indicando corrupção de dados em um dos meus 12 clientes que realizo a administração e o monitoramento remoto do banco deles.

Como corrupção de dados é aquele tipo de problema que a adrenalina sobe na hora e o coração bate mais forte, rapidamente já realizei um acesso remoto para analisar o problema.

Logando no servidor e realizando o CHECKDB nas bases, identifiquei 6 bases de dados corrompidas (incluindo a base MSDB). E eram MUITAS corrupções, inclusive em páginas internas do SQL Server.

Aí que entra um cara lindo chamado BACKUP DO LOG!!!!

A corrupção aconteceu nas páginas de dados do SQL Server (arquivo .mdf). Felizmente os arquivos de log estavam intactos.

Como o backup do log guarda todas as alterações na base uma a uma (insert/update/delete/etc), mesmo acontecendo uma corrupção na base às 12h, se o SQL Server ainda conseguir rodar um backup do log dessa base às 12h:10min, esse backup do log vai estar limpo (sem corrupção).

Olha que coisa linda!!!

Se eu fizesse um backup FULL ele estaria com dados corrompidos pois iria ler todas as páginas de dados do SQL.

Seguem os passos realizados (dica de ouro):

1 – Parei o acesso as bases de dados.

2 – Fiz um último backup do Log

3 – Restaurei o backup FULL que é feito na madrugada

4 – Restaurei todos os backups do Log até o backup feito no passo 2

5 – Executei um novo CHECKDB em todas as 6 bases de dados e nenhuma delas indicou corrupção de dados

Pronto!!! Bases restauradas sem corrupção até o último instante que o sistema estava funcionando e sem nenhuma perda de dados.

Corrupção de Dados + Alertas + Backup = DBA Salvo + Empresa sem perda de dados!!!

Há 1 ano, esse cliente não tinha nenhum DBA monitorando o banco de dados.

Ou seja:

• Ele não tinha uma rotina de backup do Log
• Ele não tinha alertas no banco de dados
• Ele não tinha um DBA realizando dois testes de restore (FULL + Logs)  por mês

Dessa forma, ele poderia demorar para identificar o problema de corrupção e perder informações valiosas da empresa.

Eu sempre digo que corrupções são raras, mas acontecem. Nesse caso, foi devido a um desligamento forçado do servidor somado a algum problema de hardware.

Para refletir:

• O banco de dados da sua empresa está preparado para esse tipo de problema?
• Algum colaborador está capacitado para analisar e resolver essas falhas?

Ou você treina alguém, ou você contrata alguém ou você está correndo risco de perder dados.

Espero ter ajudado.

Gostou dessa dica?

Cadastre seu e-mail para receber novos Posts e curta minha Página no Facebook para receber Dicas de Leituras e Eventos sobre SQL Server.

Confira mais experiências do Dia a Dia de um DBA no meu Treinamento de Tarefas do Dia a Dia de um DBA.

Abraços,

Fabrício Lima

MCITP – Database Administrator

Consultor e Instrutor SQL Server

Trabalha com SQL Server desde 2006