Tempo aproximado para leitura: 00:04:12 min

Dúvida
Como verificar a integridade da base de dados?

Ambiente
Framework - Framework (Linha RM) - Banco de Dados - Todas as versões

Solução
Em cenário de Banco de Dados corrompidos ou com baixa integridade, muitas vezes os backups também estão corrompidos devido à falta de verificação da integridade física e lógica da base, antes da realização dos backups: Se você fizer backups de uma base corrompida, estará gerando backups corrompidos!

Neste artigo, falaremos rapidamente sobre a importância da verificação diária da integridade física e lógica da base de dados SQL Server.

Seguem algumas dicas para evitar esse tipo de problema:

1. Faça a verificação diária da integridade da base antes de realizar os backups. Pode ser criado um plano de manutenção ou pode um job que executa o comando dbcc checkdb nas bases de dados;
2. O Recovery Model Full é requisitado em casos extremos, como o restore de páginas corrompidas, porém poderá acarretar em um alto consumo do disco;

   O log do SQL Server poderá crescer mais ou menos a depender do recovery model escolhido.
   
   O recovery model simple, irá logar as transações realizadas, porém ao escolher este nível de recuperação o SQL Server entende que sua tolerância para perda de dados não envolve recuperação point in time ou backups full e diferencial são suficientes. Desta forma, ao atingir um certo volume o SQL Server automaticamente realiza um checkpoint em background e confirma as transações pendentes no log para o arquivo de dados. Caso seu recovery esteja como simple e seu log esteja crescendo rapidamente e não retornando a um tamanho gerenciável, existem algumas ações a serem realizadas.

   - Checkpoints manuais
   - Shrink file

   Caso ainda assim, tenha dificuldade em reduzir o log, pode existir alguma configuração na instância relacionada a replicações realizadas no passado ou alguma outra configuração voltada a este cenário impactando o processo de checkpoint.

   Caso esteja utilizando o recovery full, o responsável mais comum por realizar o processo de checkpoint sem a intervenção do DBA é o processo de backup do log de transação. Ao se realizar o backup, o processo de checkpoint é realizado de forma automática no momento deste backup, mantendo os arquivos de log em produção em tamanhos gerenciáveis. Para isso, é necessário escolher a periodicidade do backup de log conforme o seu negócio.
   
   Caso o seu recovery model seja full e o processo de backup de log não esteja sendo realizado, este pode ser o problema relacionado ao crescimento dos arquivos. 
   
   Caso não seja o DBA da empresa, sugiro que alinhe estas informações com o mesmo para tomada de decisão.

3. Verifique a integridade física dos dispositivos de armazenamento. Utilize softwares como o ScanDisk do Windows para avaliar possíveis problemas como bad sectors;
4. Realize verificações periódicas nas baterias dos no-breaks;
5. Faça testes de restauração dos backups para prevenir qualquer tipo de eventualidade. Exemplo: falhas de integridade, problemas na compactação, defeitos na mídia etc.

Sendo assim, a verificação da integridade da base de dados é tão importante quanto à realização do próprio backup. Não deixe de inserir essa verificação nas suas rotinas de manutenção.

Saiba mais
DBCC CHECKDB
Modelos de recuperação (SQL Server)