O DBCC CHECKDB é vital para que os bancos de dados do SQL Server tenham 100% de certeza de que não há corrupção. No entanto, devido ao grande número de bancos de dados, é muito difícil encontrar uma janela de manutenção quando você afirma estar 24 horas por dia, 7 dias por semana. Ao longo dos anos, a equipe do SQL Server implementou vários mecanismos que detectarão as formas mais comuns de corrupção, especialmente relacionadas à corrupção física causada pelo hardware.
O SQL Server 2005 e superior tem PAGE_VERIFY = CHECKSUM, que pode ajudá-lo a detectar de maneira proativa a corrupção física nas páginas do banco de dados, adicionando uma soma de verificação a cada página conforme é gravada no sistema de E / S e valida a soma de verificação conforme é lida no disco.
Além disso, backup (completo ou diferencial) com CHECKSUM garantirá a detecção de qualquer corrupção de E / S causada pelo hardware.
Portanto, do lado da corrupção do hardware, o SQL Server faz um bom trabalho ao detectá-lo e relatá-lo. (Certifique-se de definir alertas importantes relacionados à corrupção também).
Dito isto, ainda corrupção lógica , os erros do scribbler induziram - em que as páginas na memória são corrompidas por código de terceiros em execução no processo do SQL Server ou por drivers ou outro software com privilégios suficientes executando no modo de kernel do Windows e / ou SQL Server Erros , etc, são indetectáveis usando os métodos acima e, portanto, o CHECKDB entra em cena.
O DBCC CHECKDB executa verificações mais completas que incluem a verificação de cabeçalhos de páginas em busca de possíveis danos que não são detectáveis por nenhum outro meio.
Algum script existente por aí?
Em vez de reinventar a roda, eu recomendo que você dê uma olhada na solução SQL Server Integrity Check da Ola
Execução eficiente do DBCC CHECKDB:
Você só precisa ser criativo quando está com dificuldades na janela de manutenção, com bancos de dados enormes ou número alto de bancos de dados para executar o CHECKDB.
Depois de participar do treinamento do SQLSkills, o que eu implementei no meu ambiente é:
- priorize quais tabelas são críticas para verificar.
- separar as tabelas em grupos com diferentes prioridades e, em seguida, executar
DBCC CHECKTABLE, juntamente com o funcionamento DBCC CHECKALLOCeDBCC CHECKCATALOG
- Crie uma tabela de trabalho que armazene os nomes das tabelas com prioridades. Apenas certifique-se de que todas as tabelas de alta prioridade (que são muito grandes) não estejam em um grupo, caso contrário o seu CHECKDB não será concluído.
- Você pode até ter uma coluna de tempo limite em sua tabela de trabalho que orquestrará quando seu CHECKDB será morto depois de passar pela janela de manutenção
- Adicionar o tempo que levou por tabela para corrida
DBCC CHECKTABLE, DBCC CHECKALLOCe DBCC CHECKCATALOG. Para que você possa ter uma idéia de quanto tempo geralmente leva para que seus cheques sejam executados.
- Você pode até executar com a
NOINDEXopção, pois isso acelerará a operação, pois não verifica os índices não clusterizados nas tabelas de usuários. Isso tem alguma vantagem, pois não é tão crítico quanto a corrupção de dados, pois nenhum dado é perdido e você pode eliminar e recriar o Índice, se necessário.
Obviamente, a edição Enterprise pode tirar proveito da execução paralela de instruções DBCC, mas observe a configuração do MAXDOP, pois ela pode levar toda a sua CPU. Isso pode ser bastante limitado pelo Administrador de Recursos.
Nota: Se você estiver tendo a coluna SPARSE, seu CHECKDB ficará lento como descrito aqui .
Finalmente, é como evitar a corrupção do banco de dados utilizando todo o conjunto de ferramentas disponível + sua fé no sistema de hardware do servidor de banco de dados e, o mais importante, o valor dos seus dados.
Algumas excelentes referências: