DBCC CHECKTABLE (Transact-SQL)
Aplica-se a:
SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do Azure
Verifica a integridade de todas as páginas e estruturas que compõem a tabela ou a exibição indexada.
Convenções de sintaxe de Transact-SQL
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 ]
}
]
Observação
Para ver a sintaxe do Transact-SQL para o SQL Server 2014 e versões anteriores, confira a Documentação das versões anteriores.
Argumentos
table_name | view_name
A tabela ou exibição indexada na qual executar verificações de integridade. Os nomes de tabela ou de exibição precisam estar em conformidade com as regras para identificadores.
NOINDEX
Especifica que não deve-se executar verificações intensivas de índices não clusterizados para tabelas de usuário. Isto reduz o tempo de execução geral. O NOINDEX não afeta tabelas do sistema porque as verificações de integridade são sempre executadas em todos os índices dessas tabelas.
index_id
O número de ID (identificação do índice) no qual executar as verificações de integridade. Se index_id for especificado, DBCC CHECKTABLE só executará verificações de integridade nesse índice, com o heap ou índice clusterizado.
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Especifica que DBCC CHECKTABLE repara os erros encontrados. Para usar uma opção de reparo, o banco de dados deve estar em modo de usuário único.
REPAIR_ALLOW_DATA_LOSS
Tenta reparar todos os erros relatados. Esses reparos podem provocar alguma perda de dados.
REPAIR_FAST
A sintaxe é mantida apenas para compatibilidade com versões anteriores. Nenhuma ação de reparo é executada.
REPAIR_REBUILD
Executa reparos que não têm nenhuma possibilidade de perda de dados. Isso pode incluir reparos rápidos, como reparo de linhas perdidas em índices não clusterizados e reparos mais demorados, como a recriação de um índice.
Esse argumento não repara erros que envolvem dados de FILESTREAM.
Importante
Use as opções REPAIR apenas como um último recurso. Para reparar erros, recomendamos restaurar de um backup. As operações de reparo não consideram nenhuma das restrições que podem existir nas tabelas ou entre elas. Se a tabela especificada estiver envolvida em uma ou mais restrições, recomendamos a execução de DBCC CHECKCONSTRAINTS após uma operação de reparo. Se for necessário usar REPAIR, execute DBCC CHECKTABLE sem uma opção de reparo para localizar o nível de reparo a ser usado. Para usar o nível REPAIR_ALLOW_DATA_LOSS, recomenda-se fazer backup do banco de dados antes de executar DBCC CHECKTABLE com esta 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 têm nenhum efeito.
EXTENDED_LOGICAL_CHECKS
Se o nível de compatibilidade for 100, introduzido no SQL Server 2008 (10.0.x), executa verificações de consistência lógica em uma exibição indexada, em índices XML e em índices espaciais, quando presentes.
Saiba mais em Execução de 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 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 rapidamente em uma tabela sob alta carga, mas diminuirá a simultaneidade disponível nela enquanto DBCC CHECKTABLE estiver em execução.
ESTIMATEONLY
Exibe a quantidade estimada de espaço tempdb necessário 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, dos cabeçalhos de registros e da estrutura física de árvores B. Criada para fornecer uma pequena verificação de sobrecarga da consistência física da tabela, essa verificação também pode detectar páginas interrompidas e falhas comuns de hardware que podem comprometer os dados. Uma execução completa de DBCC CHECKTABLE pode demorar consideravelmente mais do que nas versões anteriores. Esse comportamento ocorre devido às seguintes razões:
- As verificações lógicas são mais abrangentes.
- Algumas das estruturas subjacentes a serem verificadas são mais complexas.
- Foram introduzidas muitas verificações novas para incluir os novos recursos.
Observação
A documentação do SQL Server usa o termo árvore B geralmente em referência a índices. Em índices de armazenamento de linha, o SQL Server implementa uma árvore B+. Isso não se aplica a índices columnstore ou armazenamentos de dados na memória. Para obter mais informações, confira o Guia de arquitetura e design do índice do SQL Server e SQL do Azure.
Portanto, usar a opção PHYSICAL_ONLY pode causar um tempo de execução muito menor para DBCC CHECKTABLE em tabelas grandes e, portanto, é recomendado para uso frequente em sistemas de produção. Também é recomendado realizar uma execução completa periódica de DBCC CHECKTABLE. A frequência dessas execuções depende de fatores específicos aos negócios e ambientes de produção individuais. 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
Faz com que DBCC CHECKTABLE verifique a tabela em busca de valores de coluna inválidos ou que estão fora do intervalo. Por exemplo, DBCC CHECKTABLE detecta colunas com valores de data e hora maiores ou menores que o intervalo aceitável para o tipo de dados datetime ou colunas de tipo de dados decimais ou numéricos aproximados com escala ou valores de precisão inválidos.
As verificações de integridade de valor da coluna estã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, é possível 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 ser executado sem erros no banco de dados. Depois disso, DBCC CHECKDB e DBCC CHECKTABLE verificam a integridade de valor de coluna por padrão.
Os erros de validação relatados por esta opção não podem ser corrigidos usando as opções de reparo do DBCC. Para obter informações sobre como corrigir esses erros manualmente, confira o artigo 923247 da Base de Dados de Conhecimento: Solução de problemas do erro 2570 do DBCC no SQL Server 2005 e em versões posteriores.
Se PHYSICAL_ONLY for especificado, as verificações de integridade de coluna não serão executadas.
MAXDOP
Aplica-se a: SQL Server 2014 (12.x) Service Pack 2 e versões posteriores.
Substitui a opção de configuração max degree of parallelism de sp_configure da instrução. O MAXDOP pode ultrapassar o valor configurado com sp_configure. Se MAXDOP exceder o valor configurado com o Resource Governor, o Mecanismo de Banco de Dados usará o valor de MAXDOP do Resource Governor, descrito em ALTER WORKLOAD GROUP (Transact-SQL). Todas as regras semânticas usadas com a opção de configuração grau máximo de paralelismo são aplicáveis ao usar a dica de consulta MAXDOP. Para obter mais informações, veja Configurar a opção max degree of parallelism de configuração de servidor.
Observação
Se MAXDOP estiver definido como 0, o servidor escolherá o max degree of parallelism.
Comentários
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:
- Páginas de dados de estouro de linha, índice, em linha e LOB estão vinculadas corretamente.
- Os índices estão na ordem de classificação correta.
- Os ponteiros são consistentes.
- Os dados em cada página são razoáveis, inclusive colunas computadas.
- Deslocamentos de página são razoáveis.
- Cada linha da tabela base tem uma linha correspondente em cada índice não clusterizado e vice-versa.
- Cada linha de um índice ou tabela particionada está na partição correta.
- A consistência no nível do 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 de consistência lógica em índices varia de acordo com o nível de compatibilidade do banco de dados, da seguinte maneira:
Se o nível de compatibilidade for 100 [SQL Server 2008 (10.0.x)] ou superior:
A menos que
NOINDEXseja especificado,DBCC CHECKTABLEexecutará verificações de consistência física e lógica em uma única tabela e em todos os respectivos índices não clusterizados. Entretanto, em índices XML, índices espaciais e exibições indexadas, por padrão são executadas somente as verificações de consistência física.Se
WITH EXTENDED_LOGICAL_CHECKSfor 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. SeNOINDEXtambém estiver especificado, apenas as verificações lógicas serão executadas.Essas verificações de consistência lógica comparam a tabela de índice interna do objeto de índice com a tabela do usuário à qual se está fazendo referência. Para localizar linhas externas, uma consulta interna é construída para executar uma interseção completa das tabelas internas e do 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 especificar
WITH EXTENDED_LOGICAL_CHECKSapenas se você suspeitar de problemas de índice que não estão relacionados à dano físico ou se as somas de verificação em nível de página foram desativadas e você suspeitar de dano de hardware em nível de coluna.Se o índice for filtrado,
DBCC CHECKTABLEexecutará verificações de consistência a fim de analisar se as entradas do índice atendem ao predicado do filtro.
Desde o 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 avaliações de expressão caras. Essa alteração reduz drasticamente a duração de
CHECKTABLEnos 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 a opçãoEXTENDED_LOGICAL_CHECKSé especificada, as avaliações de expressão são executadas, além das verificações lógicas já presentes (exibição indexada, índices XML e índices espaciais), como parte da opçãoEXTENDED_LOGICAL_CHECKS.Se o nível de compatibilidade for 90, ou seja, SQL Server 2005 (9.x), ou inferior, a menos que
NOINDEXseja especificado,DBCC CHECKTABLEexecutará 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
Instantâneo de banco de dados interno
DBCC CHECKTABLE usa um instantâneo de banco de dados interno para fornecer a consistência transacional necessária a fim de executar essas verificações. Para saber mais, confira Exibir o tamanho do arquivo esparso de um instantâneo de banco de dados (Transact-SQL) e a seção Uso do instantâneo de banco de dados interno do DBCC em DBCC (Transact-SQL).
Se não for possível criar um instantâneo ou TABLOCK estiver especificado, DBCC CHECKTABLE obterá um bloqueio de tabela compartilhada exclusivo para adquirir a consistência necessária.
Observação
Se DBCC CHECKTABLE for executado em tempdb, deverá adquirir um bloqueio de tabela compartilhada. Isso ocorre porque, por motivos de desempenho, os instantâneos de banco de dados não estão disponíveis em tempdb. Isso significa que não é possível obter a consistência transacional exigida.
Verificar e reparar os dados FILESTREAM
Quando FILESTREAM está habilitado para um banco de dados e uma tabela, é possível armazenar opcionalmente BLOBs (objetos binários grandes) varbinary(max) 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 os diretórios e arquivos do sistema de arquivos e as linhas, colunas e valores de coluna da tabela. DBCC CHECKTABLE poderá 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 não tiverem dados do sistema de arquivos e 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 é automaticamente determinado pelo processador de consulta. O grau máximo de paralelismo é configurado da mesma maneira como o de consultas paralelas. Para restringir o número máximo de processadores disponíveis para a verificação do DBCC, use sp_configure. Para obter mais informações, veja Configurar a opção max degree of parallelism de configuração de servidor.
A verificação paralela pode ser desabilitada usando o sinalizador de rastreamento 2528. Para obter mais informações, confira Sinalizadores de rastreamento (Transact-SQL).
Observação
Durante uma operação DBCC CHECKTABLE, os bytes armazenados em uma coluna de tipo definido pelo usuário ordenada por byte devem ser iguais à serialização computada do valor do tipo definido pelo usuário. Se não for true, a rotina DBCC CHECKTABLE relatará um erro de consistência.
Observação
Este recurso não está disponível em todas as edições do SQL Server. Para saber mais, confira a verificação de consistência paralela na seção Gerenciamento de RDBMS de Edições e recursos do SQL Server 2022 com suporte.
Entender as mensagens de erro do 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 o tempo de execução do comando. Se o comando DBCC parar antes de concluir a verificação devido a um erro, a mensagem indicará que o comando foi finalizado, um valor de estado e a duração da execução do comando. A tabela a seguir lista e descreve os valores de estado que podem ser incluídos na mensagem.
| Estado | Descrição |
|---|---|
| 0 | O número do erro 8930 foi gerado. Isso indica um dano de metadados que provocou a finalização do comando DBCC. |
| 1 | O erro número 8967 foi gerado. Ocorreu um erro interno de DBCC. |
| 2 | Ocorreu uma falha durante o reparo do banco de dados em modo de emergência. |
| 3 | Isso indica um dano de metadados que provocou a finalização do comando DBCC. |
| 4 | Uma declaração ou violação de acesso foi detectada. |
| 5 | Ocorreu um erro desconhecido que finalizou o comando DBCC. |
Relatório de erros
Um mini-arquivo de despejo (SQLDUMP<nnnn>.txt) é criado no diretório LOG do SQL Server sempre que DBCC CHECKTABLE detecta um erro de corrupção. Quando a coleta de dados Uso de Recursos e os recursos de Relatório de Erros recursos estão habilitados para a instância do SQL Server, o arquivo é encaminhado automaticamente ao Microsoft. Os dados coletados são usados para aprimorar a funcionalidade do SQL Server.
O arquivo de despejo contém os resultados do comando DBCC CHECKTABLE e a saída do diagnóstico adicional. O arquivo tem DACLs (listas de controle de acesso discricionário) 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 do administrador local. O comando do DBCC não falhará se o processo de coleta de dados falhar.
Resolver erros
Se DBCC CHECKTABLE relatar algum erro, restaure o banco de dados com base no backup do banco de dados em vez de executar REPAIR com uma das opções REPAIR. Se não existir nenhum backup, a execução de REPARAR poderá corrigir os erros relatados. A opção REPAIR a ser usada é especificada no fim da lista de erros relatados. No entanto, corrigir os erros usando a opção REPAIR_ALLOW_DATA_LOSS pode exigir que algumas páginas e, portanto, dados sejam excluídos.
O reparo pode ser executado sob uma transação do usuário para permitir que o usuário reverta as alterações feitas. Se os reparos forem revertidos, o banco de dados ainda conterá erros e deverá ser restaurado com base em um backup. Depois de concluir todos os reparos, faça backup do banco de dados.
Conjuntos de resultados
DBCC CHECKTABLE retorna o conjunto de resultados a seguir. 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 retornará 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 precisa 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
a. Verificar uma tabela específica
O exemplo a seguir verifica a integridade da página de dados da tabela HumanResources.Employee do 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 sobrecarga baixa da tabela Employee 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 por meio de acesso a sys.indexes.
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);
Confira também
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de