Estou trabalhando na implementação do método de Paul Randal de espalhar manualmente o DBCC CHECKDB por vários dias para bancos de dados muito grandes, que consiste basicamente em:
- Dividindo as tabelas no banco de dados aproximadamente igualmente entre 7 baldes
- Executando um DBCC CHECKALLOC duas vezes por semana
- Executando um DBCC CHECKCATALOG uma vez por semana
- Executando um DBCC CHECKTABLE em um balde a cada dia da semana
Alguém já usou essa técnica? Algum script existente por aí?
Estou preocupado que isso não cubra realmente tudo o que CHECKDB faz; a documentação do Books Online para CHECKDB diz que além de CHECKALLOC, CHECKCATALOG e CHECKTABLE, também:
- Valida o conteúdo de cada exibição indexada no banco de dados.
- Valida a consistência no nível do link entre os metadados da tabela e os diretórios e arquivos do sistema de arquivos ao armazenar dados varbinary(max) no sistema de arquivos usando FILESTREAM. (somente SQL 2008)
- Valida os dados do Service Broker no banco de dados.
Então, aqui estão as minhas questões:
Essas verificações adicionais são necessárias/importantes? (As exibições indexadas provavelmente são um pouco mais preocupantes para mim, acho que ainda não estamos usando o Service Broker ou o FILESTREAM.)
Em caso afirmativo, existem maneiras de realizar essas verificações adicionais separadamente?
CHECKALLOC e CHECKCATALOG parecem rodar muito rapidamente, mesmo em dbs grandes. Algum motivo para não executá-los todos os dias?
(Observação: esta será uma rotina padrão para milhares de bancos de dados existentes em centenas de servidores, ou pelo menos todos os bancos de dados de um determinado tamanho. Isso significa que opções como reestruturar todos os bancos de dados para usar CHECKFILEGROUP não são realmente práticas para nós.)
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 crescimento maciço dos bancos de dados, é muito difícil encontrar uma janela de manutenção quando você afirma estar disponível 24 horas por dia, 7 dias por semana. Ao longo dos anos, a equipe do SQL Server implementou vários mecanismos que detectam as formas mais comuns de corrupção, especialmente relacionadas à corrupção física causada por hardware.
O SQL Server 2005 e superior tem PAGE_VERIFY = CHECKSUM , que pode ajudá-lo a detectar proativamente a corrupção física nas páginas do banco de dados, adicionando assim uma soma de verificação a cada página à medida que é gravada no sistema de E/S e valida a soma de verificação à medida que é lida do disco.
Além disso, o backup (completo ou diferencial) com CHECKSUM garantirá a detecção de qualquer corrupção de E/S causada por hardware.
Portanto, do lado da corrupção do hardware, o SQL Server faz um bom trabalho ao detectá-la e relatá-la. (Certifique-se de definir alertas importantes relacionados à corrupção também).
Dito isto, ainda corrupção lógica , erros induzidos pelo scribbler - onde 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 em execução no modo kernel do Windows e/ou SQL Server Bugs , etc são indetectáveis usando métodos acima e, portanto, CHECKDB entra em cena.
DBCC CHECKDB executa verificações mais completas que incluem a verificação de cabeçalhos de página para possíveis danos que não são detectáveis por qualquer outro meio.
Em vez de reinventar a roda, eu recomendo fortemente que você dê uma olhada na solução SQL Server Integrity Check da Ola
Executando DBCC CHECKDB com eficiência:
Você só precisa ser criativo quando estiver apertado na janela de manutenção com bancos de dados enormes ou um grande número de bancos de dados para executar o CHECKDB.
Depois de participar do treinamento SQLSkills, o que implementei em meu ambiente é:
DBCC CHECKTABLEjunto com execuçãoDBCC CHECKALLOCeDBCC CHECKCATALOGDBCC CHECKTABLEeDBCC CHECKALLOC.DBCC CHECKCATALOGPara que você possa ter uma ideia de quanto tempo geralmente leva para que suas verificações sejam executadas.NOINDEXopção, pois isso acelerará a operação, pois não verifica os índices não clusterizados nas tabelas do usuário. Isso tem alguma vantagem, pois não é tão crítico quanto a corrupção de dados, pois nenhum dado é perdido e você pode descartar e recriar o índice, se necessário.Obviamente, a edição Enterprise pode tirar proveito da execução paralela de instruções DBCC, mas fique atento à configuração MAXDOP, pois ela pode acabar consumindo toda a sua CPU. Isso pode ser limitado pelo Resource Governor.
Observação: se você estiver usando a coluna SPARSE, seu CHECKDB ficará muito lento, conforme descrito aqui .
Por fim, é como evitar a corrupção do banco de dados utilizando todo o conjunto de ferramentas disponíveis + sua fé no sistema de hardware do servidor de banco de dados e, mais importante, no valor dos seus dados.
Algumas excelentes referências:
Você pode executar
DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKSdiretamente nas exibições indexadas . A verificação de exibições indexadas pode ser problemática em determinadas circunstâncias , portanto, esteja preparado para investigar qualquer resultado falso positivo. (Paul Randal também menciona nos comentários ao artigo referenciado que falsos negativos também são possíveis, mas não tenho experiência direta disso.)Não há suporte para executar o Service Broker ou
FILESTREAMverificações separadamente, não.Não que eu saiba.
Você também pode considerar a execução
DBCC CHECKCONSTRAINTS. Esta verificação não está incluída emDBCC CHECKDB, independentemente de quaisquer opções que você possa especificar. Você também pode querer pensar em correr ocasionalmenteCHECKDB, conforme e quando as circunstâncias permitirem.