Verificação de Integridade – Uma rotina necessária.

Hoje irei abordar o tema da verificação de integridade no SQL Server, ou simplesmente sobre o famoso CheckDB. 
O comando CheckDB é um Database Console Command, ou simplesmente DBCC, categorizado como um DBCC de verificação. Este comando é a única maneira de se ler todas as páginas de uma base de dados, sendo a sua execução muito custosa a nível de CPU, Memória e I/O. Vale ressaltar que no SQL Server Enterprise Edition, este comando é executado em múltiplas threads, o que faz a sua execução ser mais rápida.
Como o CheckDB é executado
Pouca gente tem essa curiosidade, mas o CheckDb não corre directamente na base de dados. É criado um snapshot da base de dados, que fica escondido, e as verificações correm sobre este snapshot.
Normalmente as pessoas só percebem isso quando o CheckDB falha, e ao verem a mensagem, percebem que um tal snapshot não pôde ser criado.
A propósito, no caso de haver um erro como este, temos duas opções:
  1. Criar um processo em que é criado um snapshot manualmente com posterior execução do CheckDB sobre este snapshot.
  2. Executar o CheckDB com a opção TABLOCK. Porém, isso poderá trazer problemas já que a BD será alvo de locks por parte do CHECKDB.
Onde quando executar?
Recomenda-se que o CheckDB seja executa no mínimo uma vez por semana. Este procedimento é necessário em todas as DBs, incluindo as system databases e DBs em read-only.

Alguns factos interessantes:

  • Os planos de manutenção do SQL Server ignoram a TempDB…Porém, se a TempDB for corrompida, a instância irá parar! Atenção a esta situação.
  • Ao se executar o CheckDB na master, estaremos a verificar a base de dados (escondida) Resource.

Qual o objectivo do CheckDB?
O CheckDb tem duas funções, a principal é a detecção de inconsistência, e a segunda a correcção das mesmas. Atenção que esta comando verifica a consistência da estrutura da base de dados, não dos dados.
Detecção de inconsistências
O comando CheckDB segue alguns passos na sua execução, passando pelas seguintes fases:
  • Verificação das estruturas alocadas, como GAM, SGAM, PFS, IAM.
  • Verificação de consistência de tabelas e todos os seus índices, assegurando que as páginas de uma tabelas podem ser lidas e tem uma estrutura válida.
  • Verificação dos catálogos de sistema.
Correcção de inconsistências
Após a sua execução, teremos informação sobre a presença de possíveis páginas corrompidas, o que o   próprio CheckDB pode “corrigir”. 
O CheckDB tem uma opção que permite a correcção da estrutura da base de dados, porém os dados existentes nest página serão perdidos. Esta opção é a “REPAIR_ALLOW_DATA_LOSS“, e basicamente a pagina corrompida é deixada de lado, enquanto uma nova página introduzida no seu lugar. Assim, a estrutura ficará consistente, mas os dados contos nesta página serão perdidos. Após a execução deste comando, uma verificação baseada em backups antigos deverá ser feita, de forma a se identificar os dados perdidos e recupera-los.
Outra opção para correcção de inconsistência é a “REPAIR_REBUILD“, que é utilizada para correcção de nonclustered indexes. Neste caso não há perca de dados.
Apesar de haverem opções para correcção, o CheckDB tem as seguintes limitações:
  • Páginas PFS, tabelas de sistema e erros detectados na utilização da opção data purity não podem ser reparados com o CheckDB.
  • Para execução de um comando de repair, a base de dados deverá estar em modo SINGLE_USER.
Opções de execução
Falando sobre opções, temos as seguintes opções na execução do CheckDB:
  • NO_INFOMSGS: Evita o output the mensagens informativas.
  • ALL_ERRORMSDGS: Permite o output de todas as mensagens de erro.
    • Comportamento padrão desde o SQL Server 2008 SP1.
  • NOINDEX: Não verifica os nonclusterd indexes.
  • DATA_PURITY: Valida os dados conforme o tipo de dados da coluna em que está contido.
    • Comportamento padrão desde o SQL Server 2005.
  • ESTIMATEONLY: Estima o valor a ser utilizado pela TempDB.
    • Segundo o Paul Randal, esta opção não esta funcionando correctamente nas versões actuais.
  • TABLOCK: Utiliza locks ao invés de criar um snapshot.
    • Útil quando há problemas na criação do snapshot.
  • EXTENDED_LOGICAL_CHECKS: validação extra em colunas XML e índices Spatial.
  • PHYSICAL_ONLY: Salta a maioria das verificações lógicas.
    • Utiliza muito menos recursos, mas uma execução “full” deverá ser feita constantemente, por razões obvias.

Outras Considerações
Sendo o CheckDB um processo que utiliza muitos recursos, em alguns casos pode demorar muito tempo para ser executado, é frequente não termos tempo para executa-lo dentro da janela de manutenção. Para dar a volta a este problema, recomenda-se que cada passo (interno) dado pelo CheckDB seja executado de forma isolada. Isso pode ser feito ao se executar os seguintes comandos: 
  • CHECKALLOC
  • CHECKTABLE
  • CHECKCATALOG
  • CHECKFILEGROUP
Executando cada dia um destes comandos, conseguimos garantir uma verificação completa, mas de forma faseada.

Outra boa abordagem é a utilização da opção “WITH CHECKSUM” nos backups, isso nos permitirá a validação dos checksums das páginas de uma DB, além da possibilidade de se efectuar um restore com a opção “VERIFY ONLY”. Este método é útil, mas não substitui o CheckDB.

Bem, eu tento sempre escrever o mínimo possível, mas sai o que sai… Espero que este post tenha sigo útil!! Qualquer coisa, estou disponível!!

Até a próxima!!