Dividindo o DBCC CHECKDB por vários dias

10

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 consistem basicamente em:

  • Dividindo as tabelas no banco de dados aproximadamente igualmente entre 7 buckets
  • Executando um DBCC CHECKALLOC duas vezes por semana
  • Executando um DBCC CHECKCATALOG uma vez por semana
  • Executando um DBCC CHECKTABLE em um balde por dia da semana

Alguém já usou essa técnica? Algum script existente por aí?

Estou preocupado que isso possa não cobrir tudo o que o 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 todas as visualizações indexadas 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. (Apenas SQL 2008)
  • Valida os dados do Service Broker no banco de dados.

Então, aqui estão as minhas questões:

  1. Essas verificações adicionais são necessárias / importantes? (As visualizações indexadas provavelmente são um pouco mais preocupantes para mim, acho que ainda não estamos usando o Service Broker ou o FILESTREAM.)

  2. Em caso afirmativo, existem maneiras de realizar essas verificações adicionais separadamente?

  3. O CHECKALLOC e o CHECKCATALOG parecem executar muito rapidamente, mesmo em dbs grandes. Alguma razão para não executá-las todos os dias?

(Observação: essa será uma rotina padrão para milhares de bancos de dados existentes em centenas de servidores ou pelo menos para todos os bancos de dados com um determinado tamanho. Isso significa que opções como reestruturar todos os bancos de dados para usar o CHECKFILEGROUP não são realmente práticas para nós.)

sql-server dbcc-checkdb vldb BradC
fonte
Paul respondeu a uma versão desta pergunta nos comentários em seu blog. Ele disse: "Não se preocupe com a validação de exibição indexada. Ela está desativada por padrão a partir de 2008 porque não estava encontrando problemas".
BradC 26/08/13
Estou trabalhando para fazer o mesmo - algum conselho / ajuda que você encontrou, já que provavelmente já implementou isso?
scsimon
11
@scsimon Consegui que funcionasse bem, veja esta pergunta relacionada à estratégia específica que usei para dividir as tabelas. Eu acho que finalmente fiz uma lista principal de todas as tabelas em todos os bancos de dados (grandes) em todo o servidor para dividir os "buckets" diários, o que me proporcionou uma divisão muito mais uniforme do que dividir a lista de cada banco de dados individualmente. Bancos de dados menores Eu apenas fiz um DBCC completo todos os dias e não fazia parte da divisão.
BradC

Respostas:

6

Essas verificações adicionais são necessárias / importantes? (As visualizações indexadas provavelmente são um pouco mais preocupantes para mim, acho que ainda não estamos usando o Service Broker ou o FILESTREAM.)

Você pode executar DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS diretamente nas visualizações indexadas . A verificação de visualizações indexadas pode ser problemática em determinadas circunstâncias , portanto, esteja preparado para investigar quaisquer falsos positivos resultantes. (Paul Randal também menciona nos comentários ao artigo mencionado que falsos negativos também são possíveis, mas não tenho experiência direta com isso.)

Em caso afirmativo, existem maneiras de realizar essas verificações adicionais separadamente?

Não há suporte para executar o Service Broker ou FILESTREAMverificações separadamente, não.

CHECKALLOCe CHECKCATALOGparecem correr muito rapidamente, mesmo em grandes dbs. Alguma razão para não executá-las todos os dias?

Não que eu esteja ciente.

Você também pode considerar correr DBCC CHECKCONSTRAINTS . Esta verificação é não incluído no DBCC CHECKDB, independentemente de quaisquer opções que você pode especificar. Você também pode pensar em correr ocasionalmenteCHECKDB , como e quando as circunstâncias permitirem.

Paul White 9
fonte
6

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:

Kin Shah
fonte