|

Como Verificar a Integridade de uma Tabela no SQL Server

PorRenato Sanches
Compartilhe :

O comando DBCC CHECKTABLE verifica a integridade física e lógica de uma tabela ou view indexada no SQL Server, identificando problemas de corrupção de dados. É uma das ferramentas mais importantes para diagnosticar erros em um banco que apresenta comportamento inconsistente, como erros de leitura, resultados inesperados ou falhas ao acessar determinadas linhas.

Sintaxe

DBCC CHECKTABLE
(
    'tabela' | 'view'
    [ , { NOINDEX | index_id } ]
    [ , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
)
[ WITH
    {
        [ ALL_ERRORMSGS ]
        [ , EXTENDED_LOGICAL_CHECKS ]
        [ , NO_INFOMSGS ]
        [ , TABLOCK ]
        [ , ESTIMATEONLY ]
        [ , { PHYSICAL_ONLY | DATA_PURITY } ]
    }
]

Exemplo básico

DBCC CHECKTABLE('Tabela1');

Parâmetros

  • NOINDEX: ignora a checagem intensiva de índices não clusterizados. Deixa a verificação mais rápida, mas menos completa.
  • REPAIR_ALLOW_DATA_LOSS: tenta reparar todos os erros reportados. Pode causar perda de dados, já que alguns reparos envolvem excluir as linhas ou páginas corrompidas. Use apenas como último recurso.
  • REPAIR_REBUILD: executa todos os reparos possíveis sem risco de perda de dados, incluindo reparos mais demorados, como reconstrução de índices.
  • REPAIR_FAST: opção obsoleta, mantida apenas por compatibilidade com scripts antigos; atualmente não executa nenhuma ação de reparo além do que REPAIR_REBUILD já faz.
  • ALL_ERRORMSGS: retorna todas as mensagens de erro encontradas por objeto. Por padrão, o SQL Server exibe apenas as primeiras 200.
  • TABLOCK: obtém locks na tabela em vez de usar um snapshot interno do banco de dados. Costuma deixar a verificação mais rápida, mas reduz a concorrência durante a execução.
  • ESTIMATEONLY: exibe apenas a quantidade estimada de espaço que seria necessária no tempdb, sem de fato executar a verificação.
  • PHYSICAL_ONLY: limita a verificação à integridade da estrutura física das páginas, pulando as checagens lógicas. É bem mais rápido e costuma ser suficiente para detectar corrupção de disco no dia a dia.
  • EXTENDED_LOGICAL_CHECKS: em bancos com nível de compatibilidade 100 (SQL Server 2008) ou superior, executa verificações lógicas adicionais em views indexadas, índices XML e índices espaciais.
  • DATA_PURITY: verifica se há valores de coluna inválidos ou fora do intervalo permitido pelo tipo de dado. Recomendado principalmente em bancos que foram atualizados a partir de versões anteriores ao SQL Server 2005, já que versões mais antigas não faziam essa validação automaticamente.

Antes de usar as opções de reparo

As opções REPAIR_ALLOW_DATA_LOSS e REPAIR_REBUILD costumam exigir que o banco de dados esteja no modo SINGLE_USER antes de serem executadas:

ALTER DATABASE NomeDoBanco SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

DBCC CHECKTABLE('Tabela1', REPAIR_REBUILD);

ALTER DATABASE NomeDoBanco SET MULTI_USER;

Alguns pontos importantes antes de rodar qualquer opção de reparo:

  • Sempre tenha um backup atualizado antes de rodar REPAIR_ALLOW_DATA_LOSS. Como o próprio nome indica, essa opção pode excluir dados corrompidos para restaurar a consistência da tabela, e essa perda é irreversível.
  • Prefira restaurar a tabela (ou o banco) a partir de um backup íntegro, quando disponível, em vez de reparar com REPAIR_ALLOW_DATA_LOSS. O reparo é uma alternativa para quando não há backup utilizável.
  • Rodar DBCC CHECKTABLE sem nenhuma opção de reparo é sempre seguro: ele só identifica e relata problemas, sem alterar nada na tabela.

DBCC CHECKTABLE ou DBCC CHECKDB?

Se você precisa verificar todas as tabelas do banco de uma vez, em vez de rodar DBCC CHECKTABLE tabela por tabela, use DBCC CHECKDB, que verifica a integridade do banco de dados inteiro (incluindo todas as tabelas e views indexadas):

DBCC CHECKDB('NomeDoBanco');

Internamente, DBCC CHECKDB executa verificações equivalentes às de DBCC CHECKTABLE para cada objeto do banco, então CHECKTABLE costuma ser mais útil quando você já sabe qual tabela específica investigar, evitando o custo de verificar o banco inteiro.

Rotina de verificação

Em ambientes de produção, é recomendado agendar DBCC CHECKDB para rodar periodicamente (por exemplo, semanalmente, via um job do SQL Server Agent), em vez de depender apenas de verificações manuais quando um problema já apareceu. Detectar corrupção cedo facilita bastante a recuperação, principalmente quando ainda existe um backup recente e íntegro disponível.

Conclusão

DBCC CHECKTABLE é a ferramenta certa para investigar a integridade de uma tabela específica. Rodá-lo sem opções de reparo é sempre seguro; já as opções REPAIR_REBUILD e REPAIR_ALLOW_DATA_LOSS devem ser usadas com cautela, de preferência só depois de garantir um backup atualizado, e o modo SINGLE_USER costuma ser necessário para executá-las.

Posts Similares