|

Como Verificar a Integridade de um Banco de Dados no SQL Server

PorRenato Sanches
Compartilhe :

O comando DBCC CHECKDB verifica a consistência e a integridade de todos os objetos de um banco de dados: tabelas, índices, catálogo do sistema e alocação de espaço em disco. É o comando de diagnóstico mais completo do SQL Server para identificar corrupção de dados, e costuma ser o primeiro passo quando um banco começa a apresentar erros inesperados.

Se você já sabe qual tabela específica investigar, veja também o post sobre DBCC CHECKTABLE, que faz a mesma verificação de forma pontual, sem precisar varrer o banco inteiro.

Sintaxe

DBCC CHECKDB
(
    'nome_do_banco'
    [ , { NOINDEX | REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
)
[ WITH
    {
        [ ALL_ERRORMSGS ]
        [ , EXTENDED_LOGICAL_CHECKS ]
        [ , NO_INFOMSGS ]
        [ , TABLOCK ]
        [ , ESTIMATEONLY ]
        [ , { PHYSICAL_ONLY | DATA_PURITY } ]
        [ , MAXDOP = numero_de_processadores ]
    }
]

Exemplo básico

DBCC CHECKDB('Banco1');

Rodar DBCC CHECKDB sem nenhuma opção de reparo é sempre seguro: ele apenas identifica e relata problemas, sem alterar nada no banco.

O que o CHECKDB verifica, na prática

DBCC CHECKDB combina várias verificações internas em um único comando:

  • Alocação de espaço: confere se as estruturas de páginas e extents do banco estão consistentes.
  • Integridade de cada tabela e view indexada: equivalente a rodar DBCC CHECKTABLE em todos os objetos do banco.
  • Consistência do catálogo do sistema: confere se as informações internas de metadados (tabelas, colunas, tipos etc.) estão íntegras.
  • Conteúdo das colunas do tipo Service Broker, quando aplicável.

Por reunir todas essas checagens, DBCC CHECKDB costuma demorar mais e consumir mais recursos do que verificar uma tabela isolada, principalmente em bancos grandes.

Parâmetros mais usados

  • NOINDEX: ignora a checagem intensiva de índices não clusterizados, deixando a verificação mais rápida e menos completa.
  • REPAIR_ALLOW_DATA_LOSS, REPAIR_FAST, REPAIR_REBUILD: opções de reparo automático. Funcionam da mesma forma que em DBCC CHECKTABLE; veja o post sobre CHECKTABLE para o detalhamento de cada uma e os cuidados necessários antes de usá-las.
  • ALL_ERRORMSGS: retorna todas as mensagens de erro encontradas. Por padrão, o SQL Server mostra apenas as primeiras 200.
  • NO_INFOMSGS: suprime mensagens informativas, deixando a saída com apenas os erros relevantes.
  • TABLOCK: usa locks em vez de um snapshot interno do banco, o que costuma deixar a execução mais rápida, mas reduz a concorrência durante a verificação.
  • ESTIMATEONLY: mostra só a estimativa de espaço necessário no tempdb, sem executar a verificação de fato.
  • PHYSICAL_ONLY: limita a verificação à estrutura física das páginas, pulando checagens lógicas mais demoradas. É uma boa opção para rotinas diárias em bancos grandes, deixando as checagens completas para uma janela de manutenção maior.
  • DATA_PURITY: verifica se há valores de coluna inválidos ou fora do intervalo permitido. Recomendado principalmente para bancos atualizados a partir de versões anteriores ao SQL Server 2005.
  • EXTENDED_LOGICAL_CHECKS: em bancos com nível de compatibilidade 100 (SQL Server 2008) ou superior, adiciona verificações lógicas em views indexadas, índices XML e espaciais.
  • MAXDOP: disponível desde o SQL Server 2014, limita o número de processadores usados durante a verificação, útil para reduzir o impacto do CHECKDB em servidores de produção enquanto ele roda.

Reparando problemas encontrados

Assim como em DBCC CHECKTABLE, as opções REPAIR_REBUILD e REPAIR_ALLOW_DATA_LOSS costumam exigir que o banco esteja no modo SINGLE_USER:

ALTER DATABASE Banco1 SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

DBCC CHECKDB('Banco1', REPAIR_REBUILD);

ALTER DATABASE Banco1 SET MULTI_USER;

Antes de rodar qualquer reparo, especialmente REPAIR_ALLOW_DATA_LOSS:

  • Garanta um backup atualizado do banco. Essa opção pode excluir dados corrompidos para restaurar a consistência, e essa perda é irreversível.
  • Se houver um backup íntegro disponível, restaurar o banco a partir dele costuma ser mais seguro do que reparar com perda de dados.
  • Rode DBCC CHECKDB sem opções de reparo primeiro, para entender a extensão do problema antes de decidir o próximo passo.

Rotina de verificação em produção

Como DBCC CHECKDB verifica o banco inteiro, ele costuma ser agendado para rodar periodicamente (semanalmente é uma frequência comum) através de um job do SQL Server Agent, de preferência em um horário de menor uso do sistema. Detectar corrupção nesse tipo de rotina, antes que ela afete a aplicação, facilita bastante a recuperação, principalmente enquanto ainda há um backup recente e íntegro disponível.

Conclusão

DBCC CHECKDB é o comando certo quando você precisa verificar a integridade do banco de dados como um todo, combinando checagens de alocação, tabelas, índices e catálogo do sistema em um único comando. Assim como em DBCC CHECKTABLE, rodá-lo sem opções de reparo é sempre seguro; use REPAIR_REBUILD e REPAIR_ALLOW_DATA_LOSS com cautela, de preferência com um backup atualizado em mãos.

Posts Similares