TABELA DE VERIFICAÇÃO DBCC (Transact-SQL)

2025-05-20

Aplica-se a:SQL Server Banco de Dados SQL do Azure Instância Gerenciada SQL do Azure

Verifica a integridade de todas as páginas e estruturas que compõem a tabela ou o modo de exibição indexado.

Sintaxe

DBCC CHECKTABLE
(
    table_name | view_name
    [ , { 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 } ]
          [ , MAXDOP = number_of_processors ]
        }
    ]

Argumentos

| table_nameview_name

A tabela ou modo de exibição indexado para o qual executar verificações de integridade. Os nomes de tabelas ou exibições devem estar em conformidade com as regras para identificadores.

NOÍNDICE

Especifica que verificações intensivas de índices não clusterizados para tabelas de usuário não devem ser executadas. Isso diminui o tempo de execução geral. NOINDEX não afeta as tabelas do sistema porque as verificações de integridade são sempre executadas em todos os índices de tabelas do sistema.

index_id

O número de identificação do índice (ID) para o qual executar verificações de integridade. Se index_id for especificado, DBCC CHECKTABLE executa verificações de integridade somente nesse índice, juntamente com o heap ou o índice clusterizado.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Especifica que DBCC CHECKTABLE reparar os erros encontrados. Para usar uma opção de reparo, o banco de dados deve estar no modo de usuário único.

REPARAR_PERMITIR_PERDA_DE_DADOS

Tenta reparar todos os erros relatados. Esses reparos podem causar alguma perda de dados.
REPARAÇÃO_RÁPIDA

A sintaxe é mantida apenas para compatibilidade com versões anteriores. Nenhuma ação de reparo é executada.
REPARAR_RECONSTRUIR

Realiza reparos que não têm possibilidade de perda de dados. Isso pode incluir reparos rápidos, como reparar linhas ausentes em índices não clusterizados, e reparos mais demorados, como a reconstrução de um índice.

Esse argumento não repara erros envolvendo dados FILESTREAM.

Importante

Utilize as opções de REPARAÇÃO apenas como último recurso. Para reparar erros, recomendamos restaurar a partir de uma cópia de segurança. As operações de reparo não consideram nenhuma das restrições que possam existir nas tabelas ou entre elas. Se a tabela especificada estiver envolvida em uma ou mais restrições, recomendamos executáDBCC CHECKCONSTRAINTS após uma operação de reparo. Se tiver de utilizar REPAIR, execute DBCC CHECKTABLE sem uma opção de reparação para encontrar o nível de reparação a utilizar. Se você usar o nível de REPAIR_ALLOW_DATA_LOSS, recomendamos que faça backup do banco de dados antes de executar DBCC CHECKTABLE com essa opção.

ALL_ERRORMSGS

Exibe um número ilimitado de erros. Todas as mensagens de erro são exibidas por padrão. Especificar ou omitir esta opção não tem efeito.

EXTENDED_LOGICAL_CHECKS

Se o nível de compatibilidade for 100, introduzido no SQL Server 2008 (10.0.x), execute verificações de consistência lógica em um modo de exibição indexado, índices XML e índices espaciais, quando presentes.

Para obter mais informações, consulte Executando verificações de consistência lógica em índices na seção Comentários mais adiante neste artigo.

NO_INFOMSGS

Suprime todas as mensagens informativas.

TABLOCK

Faz com que DBCC CHECKTABLE se obtenha um bloqueio de tabela compartilhada em vez de usar um instantâneo de banco de dados interno. TABLOCK fará com que DBCC CHECKTABLE seja executado mais rápido em uma mesa sob carga pesada, mas diminui a simultaneidade disponível na tabela enquanto DBCC CHECKTABLE está em execução.

ESTIMATIVAAPENAS

Exibe a quantidade estimada de tempdb espaço necessária para executar DBCC CHECKTABLE com todas as outras opções especificadas.

PHYSICAL_ONLY

Limita a verificação à integridade da estrutura física da página, cabeçalhos de registro e estrutura física de árvores B. Projetada para fornecer uma pequena verificação geral da consistência física da tabela, essa verificação também pode detetar páginas rasgadas e falhas comuns de hardware que podem comprometer os dados. Uma execução completa de DBCC CHECKTABLE pode levar consideravelmente mais tempo do que em versões anteriores. Esse comportamento ocorre devido aos seguintes motivos:

As verificações lógicas são mais abrangentes.
Algumas das estruturas subjacentes a verificar são mais complexas.
Muitas novas verificações foram introduzidas para incluir os novos recursos.

Observação

A documentação usa o termo árvore B geralmente em referência a índices. Em índices de armazenamento em linha, o Mecanismo de Base de Dados implementa uma árvore B+. Isso não se aplica a índices de armazenamento em colunas ou a índices em tabelas com otimização de memória. Para obter mais informações, consulte o guia de arquitetura e design de índices do SQL Server e Azure SQL .

Portanto, o uso da PHYSICAL_ONLY opção pode causar um tempo de execução muito menor para DBCC CHECKTABLE mesas grandes e, portanto, é recomendado para uso frequente em sistemas de produção. Ainda recomendamos que uma execução completa de DBCC CHECKTABLE seja realizada periodicamente. A frequência dessas execuções depende de fatores específicos de empresas individuais e ambientes de produção. PHYSICAL_ONLY sempre implica NO_INFOMSGS e não é permitido com nenhuma das opções de reparo.

Observação

Especificar PHYSICAL_ONLY faz com que DBCC CHECKTABLE ignore todas as verificações de dados FILESTREAM.

DATA_PURITY

Causas DBCC CHECKTABLE para verificar a tabela para valores de coluna que não são válidos ou fora do intervalo. Por exemplo, o DBCC CHECKTABLE deteta colunas com valores de data e hora maiores ou menores do que o intervalo aceitável para o tipo de dados data/hora ; ou decimal ou colunas de tipo de dados numérico aproximado com valores de escala ou precisão que não são válidos.

As verificações de integridade do valor da coluna são habilitadas por padrão e não exigem a opção DATA_PURITY. Para bancos de dados atualizados de versões anteriores do SQL Server, você pode usar DBCC CHECKTABLE WITH DATA_PURITY para localizar e corrigir erros em uma tabela específica, no entanto, as verificações de valor de coluna na tabela não são habilitadas por padrão até DBCC CHECKDB WITH DATA_PURITY que tenham sido executadas sem erros no banco de dados. Depois disso, DBCC CHECKDB verifique DBCC CHECKTABLE a integridade do valor da coluna por padrão.

Os erros de validação relatados por essa opção não podem ser corrigidos usando as opções de reparo DBCC. Para obter informações sobre como corrigir manualmente esses erros, consulte Solucionar problemas de erros de consistência do banco de dados relatados pelo DBCC CHECKDB.

Se PHYSICAL_ONLY for especificado, as verificações de integridade da coluna não serão executadas.

MAXDOP

Aplica-se a: SQL Server 2014 (12.x) Service Pack 2 e versões posteriores.

Substitui o grau máximo de paralelismo opção de configuração de sp_configure para a instrução. O MAXDOP pode exceder o valor configurado com sp_configure. Se MAXDOP exceder o valor configurado com o Administrador de Recursos, o Mecanismo de Banco de Dados usará o valor MAXDOP do Administrador de Recursos, descrito em ALTER WORKLOAD GROUP (Transact-SQL). Todas as regras semânticas usadas com a opção de configuração de grau máximo de paralelismo são aplicáveis quando você usa a dica de consulta MAXDOP. Para obter mais informações, consulte Configurar o grau máximo de paralelismo Opção de configuração do servidor.

Observação

Se MAXDOP estiver definido como zero, o servidor escolhe o grau máximo de paralelismo.

Observações

Observação

Para executar DBCC CHECKTABLE em todas as tabelas do banco de dados, use DBCC CHECKDB.

Para a tabela especificada, DBCC CHECKTABLE verifica o seguinte:

As páginas de dados de índice, linha, LOB e estouro de linha estão vinculadas corretamente.
Os índices estão em sua ordem de classificação correta.
Os ponteiros são consistentes.
Os dados em cada página são razoáveis, incluindo colunas computadas.
As compensações de página são razoáveis.
Cada linha na tabela base tem uma linha correspondente em cada índice não clusterizado e vice-versa.
Cada linha em uma tabela particionada ou índice está na partição correta.
Consistência em nível de link entre o sistema de arquivos e a tabela ao armazenar dados varbinary(max) no sistema de arquivos usando FILESTREAM.

Executar verificações de consistência lógica em índices

A verificação da consistência lógica nos índices varia de acordo com o nível de compatibilidade do banco de dados, da seguinte forma:

Se o nível de compatibilidade for 100 (SQL Server 2008 (10.0.x)) ou superior:
- A menos que NOINDEX seja especificado, DBCC CHECKTABLE executa verificações de consistência física e lógica em uma única tabela e em todos os seus índices não clusterizados. No entanto, em índices XML, índices espaciais e exibições indexadas, apenas verificações de consistência física são executadas por padrão.
- Se WITH EXTENDED_LOGICAL_CHECKS for especificado, verificações lógicas serão executadas em uma exibição indexada, índices XML e índices espaciais, quando presentes. Por padrão, as verificações de consistência física são executadas antes das verificações de consistência lógica. Se NOINDEX também for especificado, apenas as verificações lógicas serão executadas.
  
  Essas verificações de consistência lógica cruzam a tabela de índice interna do objeto de índice com a tabela de usuário à qual ela está se referindo. Para encontrar linhas periféricas, uma consulta interna é construída para executar uma interseção completa das tabelas interna e de usuário. A execução dessa consulta pode ter um efeito muito alto no desempenho e seu progresso não pode ser rastreado. Portanto, recomendamos que você especifique WITH EXTENDED_LOGICAL_CHECKS somente se suspeitar de problemas de índice que não estejam relacionados a corrupção física ou se somas de verificação no nível da página tiverem sido desativadas e você suspeitar de corrupção de hardware no nível da coluna.
- Se o índice for um índice filtrado, DBCC CHECKTABLE executa verificações de consistência para verificar se as entradas de índice satisfazem o predicado do filtro.
A partir do SQL Server 2016 (13.x), verificações adicionais em colunas computadas persistentes, colunas UDT e índices filtrados não serão executadas por padrão para evitar as avaliações de expressão dispendiosas. Essa alteração reduz consideravelmente a duração do CHECKTABLE em bancos de dados que contêm esses objetos. No entanto, as verificações de consistência física desses objetos são sempre concluídas. Somente quando EXTENDED_LOGICAL_CHECKS a opção é especificada é que as avaliações de expressão são realizadas, além de já apresentar verificações lógicas (exibição indexada, índices XML e índices espaciais) como parte da EXTENDED_LOGICAL_CHECKS opção.
Se o nível de compatibilidade for 90 (SQL Server 2005 (9.x)) ou inferior, a menos que NOINDEX seja especificado, DBCC CHECKTABLE execute verificações de consistência física e lógica em uma única tabela ou exibição indexada e em todos os seus índices não clusterizados e XML. Não há suporte para índices espaciais.

Para saber o nível de compatibilidade de um banco de dados

Exibir ou alterar o nível de compatibilidade de um banco de dados

Instantâneo do banco de dados interno

DBCC CHECKTABLE usa um instantâneo de banco de dados interno para fornecer a consistência transacional que deve ter para executar essas verificações. Para obter mais informações, consulte Exibir o tamanho do arquivo esparso de um de instantâneo de banco de dados (Transact-SQL) e a seção de uso de instantâneo de banco de dados interno DBCC em DBCC (Transact-SQL).

Se um instantâneo não puder ser criado ou TABLOCK for especificado, DBCC CHECKTABLE adquire um bloqueio de tabela compartilhada para obter a consistência necessária.

Observação

Se DBCC CHECKTABLE for executado contra tempdb, ele deve adquirir um bloqueio de tabela compartilhada. Isso ocorre porque, por motivos de desempenho, os instantâneos do banco de dados não estão disponíveis no tempdb. Isso significa que a consistência transacional necessária não pode ser obtida.

Verificar e reparar dados FILESTREAM

Quando FILESTREAM está habilitado para um banco de dados e tabela, você pode, opcionalmente, armazenar varbinary(max) objetos binários grandes (BLOBs) no sistema de arquivos. Ao usar DBCC CHECKTABLE em uma tabela que armazena BLOBs no sistema de arquivos, o DBCC verifica a consistência no nível do link entre o sistema de arquivos e o banco de dados.

Por exemplo, se uma tabela contiver uma coluna varbinary(max) que usa o atributo FILESTREAM, DBCC CHECKTABLE verificará se há um mapeamento um-para-um entre diretórios do sistema de arquivos e arquivos e linhas, colunas e valores de coluna da tabela. DBCC CHECKTABLE pode reparar a corrupção se você especificar a opção REPAIR_ALLOW_DATA_LOSS. Para reparar a corrupção do FILESTREAM, o DBCC excluirá todas as linhas da tabela que estão faltando dados do sistema de arquivos e excluirá todos os diretórios e arquivos que não são mapeados para uma linha, coluna ou valor de coluna da tabela.

Verificar objetos em paralelo

Por padrão, DBCC CHECKTABLE executa a verificação paralela de objetos. O grau de paralelismo é determinado automaticamente pelo processador de consultas. O grau máximo de paralelismo é configurado da mesma maneira que o de consultas paralelas. Para restringir o número máximo de processadores disponíveis para verificação DBCC, use sp_configure. Para obter mais informações, consulte Configurar o grau máximo de paralelismo Opção de configuração do servidor.

A verificação paralela pode ser desativada usando o sinalizador de rastreamento 2528. Para obter mais informações, consulte Sinalizadores de rastreamento (Transact-SQL).

Observação

Durante uma DBCC CHECKTABLE operação, os bytes armazenados em uma coluna de tipo definida pelo usuário ordenada por bytes devem ser iguais à serialização computada do valor de tipo definido pelo usuário. Se isso não for verdade, a DBCC CHECKTABLE rotina relatará um erro de consistência.

Observação

Esse recurso não está disponível em todas as edições do SQL Server. Para obter mais informações, consulte a verificação de consistência paralela na seção de gerenciabilidade do RDBMS de Edições e recursos com suporte do SQL Server 2022.

Compreender as mensagens de erro DBCC

Após a conclusão do comando DBCC CHECKTABLE, uma mensagem é gravada no log de erros do SQL Server. Se o comando DBCC for executado com êxito, a mensagem indicará uma conclusão bem-sucedida e a quantidade de tempo que o comando foi executado. Se o comando DBCC parar antes de concluir a verificação devido a um erro, a mensagem indica que o comando foi encerrado, um valor de estado e a quantidade de tempo que o comando executou. A tabela a seguir lista e descreve os valores de estado que podem ser incluídos na mensagem.

Estado	Descrição
0	O erro número 8930 foi gerado. Isso indica uma corrupção de metadados que causou o encerramento do comando DBCC.
1	O erro número 8967 foi gerado. Houve um erro interno do DBCC.
2	Ocorreu uma falha durante o reparo do banco de dados no modo de emergência.
3	Isso indica uma corrupção de metadados que causou o encerramento do comando DBCC.
4	Foi detetada uma violação de afirmação ou acesso.
5	Ocorreu um erro desconhecido que encerrou o comando DBCC.

Comunicação de erros

Um arquivo de minidespejo (SQLDUMP<nnnn>.txt) é criado no diretório do SQL Server LOG sempre que DBCC CHECKTABLE deteta um erro de corrupção. Quando os recursos de coleta de dados de Uso de Recursos e Relatório de Erros são habilitados para a instância do SQL Server, o arquivo é encaminhado automaticamente para a Microsoft. Os dados coletados são usados para melhorar a funcionalidade do SQL Server.

O arquivo de despejo contém os resultados do comando DBCC CHECKTABLE e saída de diagnóstico adicional. O arquivo tem listas de controle de acesso discricionário (DACLs) restritas. O acesso é limitado à conta de serviço do SQL Server e aos membros da função sysadmin. Por padrão, a função sysadmin contém todos os membros do grupo BUILTIN\Administradores do Windows e do grupo de administradores locais. O comando DBCC não falhará se o processo de coleta de dados falhar.

Resolver erros

Se DBCC CHECKTABLE relatar erros, recomendamos restaurar o banco de dados a partir do backup do banco de dados em vez de executar REPAIR com uma das opções REPAIR. Se não houver backup, executar REPAIR pode corrigir os erros relatados. A opção REPAIR a ser usada é especificada no final da lista de erros relatados. No entanto, a correção dos erros usando a REPAIR_ALLOW_DATA_LOSS opção pode exigir que algumas páginas e, portanto, dados, sejam excluídos.

O reparo pode ser executado sob uma transação de usuário para permitir que o usuário reverta as alterações que foram feitas. Se os reparos forem revertidos, o banco de dados ainda conterá erros e deverá ser restaurado a partir de um backup. Depois de concluir todos os reparos, faça backup do banco de dados.

Conjuntos de resultados

DBCC CHECKTABLE retorna o seguinte conjunto de resultados. O mesmo conjunto de resultados será retornado se você especificar apenas o nome da tabela ou qualquer uma das opções.

DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKTABLE retorna o seguinte conjunto de resultados se a opção ESTIMATEONLY for especificada:

Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
21
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Permissões

O usuário deve ser o proprietário da tabela ou ser membro da função de servidor fixa sysadmin, da função de banco de dados fixa db_owner ou da função de banco de dados fixa db_ddladmin.

Exemplos

Um. Verifique uma tabela específica

O exemplo a seguir verifica a integridade da página de dados da HumanResources.Employee tabela no banco de dados AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee');
GO

B. Executar uma verificação de baixa sobrecarga da tabela

O exemplo a seguir executa uma verificação de baixa sobrecarga da Employee tabela no banco de dados AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee') WITH PHYSICAL_ONLY;
GO

C. Verificar um índice específico

O exemplo a seguir verifica um índice específico, obtido acessando sys.indexeso .

DECLARE @indid int;
SET @indid = (SELECT index_id
              FROM sys.indexes
              WHERE object_id = OBJECT_ID('Production.Product')
                    AND name = 'AK_Product_Name');
DBCC CHECKTABLE ('Production.Product',@indid);

Partilhar via

TABELA DE VERIFICAÇÃO DBCC (Transact-SQL)

Sintaxe

Argumentos

| table_nameview_name

NOÍNDICE

index_id

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATIVAAPENAS

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Observações

Executar verificações de consistência lógica em índices

Para saber o nível de compatibilidade de um banco de dados

Instantâneo do banco de dados interno

Verificar e reparar dados FILESTREAM

Verificar objetos em paralelo

Compreender as mensagens de erro DBCC

Comunicação de erros

Resolver erros

Conjuntos de resultados

Permissões

Exemplos

Um. Verifique uma tabela específica

B. Executar uma verificação de baixa sobrecarga da tabela

C. Verificar um índice específico

Ver também

Comentários

Recursos adicionais