DBCC CHECKDB (Transact-SQL)

Artigo
03/05/2025

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

Verifica a integridade lógica e física de todos os objetos do banco de dados especificado com a execução das seguintes operações:

Executa DBCC CHECKALLOC no banco de dados.
Executa DBCC CHECKTABLE em cada tabela e exibição no banco de dados.
Executa DBCC CHECKCATALOG no banco de dados.
Valida o conteúdo de toda exibição indexada do banco de dados.
Valida a consistência no nível do link entre arquivos e diretórios do sistema de arquivos e dos metadados de tabela ao armazenar dados varbinary(max) no sistema de arquivos usando FILESTREAM.
Valida os dados Agente de Serviço no banco de dados.

Isso significa que os comandos DBCC CHECKALLOC, DBCC CHECKTABLE ou DBCC CHECKCATALOG não precisam ser executados separadamente de DBCC CHECKDB. Para obter informações mais detalhadas sobre as verificações executadas, consulte as descrições desses comandos.

Há suporte ao DBCC CHECKDB em bancos de dados que contêm tabelas com otimização de memória, mas nos quais a validação ocorre somente em tabelas baseadas em disco. No entanto, como parte do backup e recuperação do banco de dados, uma validação CHECKSUM é feita para arquivos em grupos de arquivos com otimização de memória.

Como as opções de reparo do DBCC não estão disponíveis para tabelas com otimização de memória, faça backup dos bancos de dados regularmente e teste os backups. Se ocorrerem problemas de integridade de dados em uma tabela com otimização de memória, você deverá restaurar o último backup válido.

Convenções de sintaxe de Transact-SQL

Sintaxe

DBCC CHECKDB
    [ [ ( database_name | database_id | 0
        [ , NOINDEX
        | , { 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

database_name | database_id | 0

O nome ou a ID do banco de dados para o qual executar verificações de integridade. Se não for especificado ou se 0 for especificado, o banco de dados atual será usado. Os nomes de banco de dados precisam estar em conformidade com as regras de identificadores.

NOINDEX

Especifica que verificações intensivas de índices não clusterizados para tabelas de usuário não são executadas. Essa opção diminui o tempo de execução geral. O NOINDEX não afeta as tabelas do sistema porque as verificações de integridade são sempre executadas nos índices delas.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Especifica que DBCC CHECKDB repara os erros encontrados. Use as opções de REPAIR_* apenas como último recurso. O banco de dados especificado deve estar em modo de usuário único para usar uma das opções de reparo a seguir.

REPAIR_ALLOW_DATA_LOSS

Tenta reparar todos os erros relatados. Esses reparos podem provocar alguma perda de dados.

Aviso

A opção REPAIR_ALLOW_DATA_LOSS pode resultar em mais perda de dados do que se você restaurar de um último backup bom conhecido. Consulte Aviso de perda de dados com REPAIR_ALLOW_DATA_LOSS

A Microsoft sempre recomenda como o principal método de recuperação para os erros relatados por DBCC CHECKDB uma restauração do usuário com base no último backup adequado conhecido. A opção REPAIR_ALLOW_DATA_LOSS não é uma alternativa de restauração de um backup adequado conhecido. É uma opção de último recurso recomendada para uso somente se a restauração de um backup não for possível.

Certos erros, que só podem ser reparados usando a opção REPAIR_ALLOW_DATA_LOSS, podem envolver a desalocação de uma linha, página ou série de páginas para limpar os erros. Todos os dados desalocados não são mais acessíveis ou recuperáveis para o usuário e o conteúdo exato dos dados desalocados não pode ser determinado. Portanto, a integridade referencial pode não ser precisa depois que linhas ou páginas são desalocadas porque as restrições de chave estrangeira não são verificadas ou mantidas como parte desta operação de reparo. O usuário deve inspecionar a integridade referencial do banco de dados (usando DBCC CHECKCONSTRAINTS) após usar a opção REPAIR_ALLOW_DATA_LOSS.

Antes de realizar o reparo, é necessário criar cópias físicas dos arquivos do banco de dados. Isso inclui o arquivo de dados primário (.mdf), quaisquer arquivos de dados secundários (.ndf), todos os arquivos de log de transação (.ldf) e outros contêineres que formam o banco de dados, como catálogos de texto completo, pastas de fluxos de arquivo, dados otimizados para memória e assim por diante.

Antes de executar o reparo, considere alterar o estado do banco de dados para o modo EMERGENCY, tentar extrair o máximo de informações possível das tabelas críticas e salvar esses dados.
REPAIR_FAST

Mantém a sintaxe 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. Essa opção pode incluir reparos rápidos, como reparar linhas ausentes 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

Como DBCC CHECKDB com qualquer uma das opções de REPAIR_* são completamente registradas e recuperáveis, a Microsoft sempre recomenda que um usuário use DBCC CHECKDB com qualquer REPAIR_* opções dentro de uma transação (execute BEGIN TRANSACTION antes de executar o comando) para que o usuário possa confirmar que deseja aceitar os resultados da operação. Em seguida, o usuário pode executar COMMIT TRANSACTION para fazer commit de todo o trabalho realizado pela operação de reparo. Se o usuário não quiser aceitar os resultados da operação, ele poderá executar uma ROLLBACK TRANSACTION para desfazer os efeitos das operações de reparo.

Para reparar erros, recomendamos restaurar de um backup. As operações de reparo não consideram nenhuma das restrições que podem existir em ou entre tabelas. 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 você precisar usar REPAIR_*, execute DBCC CHECKDB 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 CHECKDB com esta opção.

ALL_ERRORMSGS

Exibe todos os erros relatados por objeto. Todas as mensagens de erro são exibidas por padrão. Especificar ou omitir esta opção não têm nenhum efeito. As mensagens de erro são classificadas pela ID de objeto, exceto as mensagens geradas pelo banco de dados tempdb.

EXTENDED_LOGICAL_CHECKS

Se o nível de compatibilidade for 100, introduzido no SQL Server 2008 (10.0.x), essa opção executará verificações de consistência lógica em uma exibição indexada, em índices XML e em índices espaciais, quando presentes.

Para saber mais, confira Executar verificações de consistência lógica em índices mais adiante neste artigo.

NO_INFOMSGS

Suprime todas as mensagens informativas.

TABLOCK

Faz com que DBCC CHECKDB obtenha bloqueios em vez de usar um instantâneo de banco de dados interno. Isso inclui um bloqueio exclusivo (X) de curto prazo no banco de dados. TABLOCK faz com que DBCC CHECKDB sejam executados mais rapidamente em um banco de dados sob carga pesada, mas diminui a simultaneidade disponível no banco de dados enquanto DBCC CHECKDB está em execução.

Importante

TABLOCK limita as verificações executadas; DBCC CHECKCATALOG não é executado no banco de dados e os dados do Service Broker não são validados.

ESTIMATEONLY

Exibe a quantidade estimada de espaço tempdb necessária para executar DBCC CHECKDB com todas as outras opções especificadas. A verificação real do banco de dados não é executada.

PHYSICAL_ONLY

Limita a verificação à integridade da estrutura física da página e dos cabeçalhos de registros e a consistência da alocação do banco de dados. Essa verificação foi desenvolvida para fornecer uma pequena verificação de sobrecarga da consistência física do banco de dados, mas ela também pode detectar páginas interrompidas, falhas de soma de verificação e falhas comuns de hardware que podem comprometer os dados de um usuário.

Uma execução completa de DBCC CHECKDB pode levar consideravelmente mais tempo para ser concluída do que as versões anteriores. Esse comportamento ocorre porque:

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.

Portanto, usar a opção PHYSICAL_ONLY pode causar um tempo de execução muito menor para DBCC CHECKDB em bancos de dados grandes e é recomendado para uso frequente em sistemas de produção. Também é recomendado realizar uma execução completa periódica de DBCC CHECKDB. A frequência dessas execuções depende de fatores específicos aos negócios e ambientes de produção individuais.

Este argumento sempre implica NO_INFOMSGS e não é permitido com nenhuma das opções de reparo.

Aviso

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

DATA_PURITY

Faz com que DBCC CHECKDB verifique o banco de dados em busca de valores de coluna inválidos ou que estão fora do intervalo. Por exemplo, DBCC CHECKDB 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éricas aproximadas com escala ou valores de precisão inválidos.

As verificações de integridade de valor de 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, as verificações de valor de coluna não são habilitadas por padrão até que o DBCC CHECKDB WITH DATA_PURITY tenha sido executado sem erros no banco de dados. Depois disso, DBCC CHECKDB verifica a integridade de valores de coluna por padrão. Para saber como CHECKDB pode ser afetado pela atualização do banco de dados de versões anteriores do SQL Server, veja a seção “Comentários” posteriormente neste artigo.

Aviso

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

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 manualmente esses erros, consulte MSSQLSERVER_2570.

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 para a instrução. O MAXDOP pode exceder o valor configurado com sp_configure. Se MAXDOP exceder o valor configurado com o Resource Governor, o Mecanismo de Banco de Dados do SQL Server usará o valor MAXDOP do Resource Governor, descrito em ALTER WORKLOAD GROUP. Todas as regras semânticas usadas com a opção de configuração max degree of parallelism são aplicáveis quando você usa a dica de consulta MAXDOP. Para obter mais informações, consulte Configuração do servidor: grau máximo de paralelismo.

Aviso

Se MAXDOP estiver definido como zero, o SQL Server escolherá o max degree of parallelism a ser usado.

Comentários

DBCC CHECKDB não examina índices desabilitados. Para obter mais informações sobre índices desabilitados, consulte Desabilitar índices e restrições.

Se um tipo definido pelo usuário estiver marcado como sendo ordenado por byte, deverá existir apenas uma serialização do tipo definido pelo usuário. Não ter uma serialização consistente de tipos definidos pelo usuário ordenados por byte causa o erro 2537 quando DBCC CHECKDB é executado. Para obter mais informações, consulte Criando tipos de User-Defined – requisitos.

Como o banco de dados de recursos só pode ser modificado no modo de usuário único, o comando DBCC CHECKDB não pode ser executado diretamente nele. No entanto, quando DBCC CHECKDB é executado no banco de dados mestre, um segundo CHECKDB também é executado internamente no banco de dados de recursos. Isso significa que DBCC CHECKDB pode retornar resultados extras. O comando retorna conjuntos de resultados extras quando nenhuma opção está definida ou quando a opção PHYSICAL_ONLY ou ESTIMATEONLY está definida.

No SQL Server 2005 (9.x) Service Pack 2 e versões posteriores, executar DBCC CHECKDB não limpa mais o cache de planos para a instância do SQL Server. Antes do SQL Server 2005 (9.x) Service Pack 2, a execução de DBCC CHECKDB limpa o cache do plano. Limpar o cache de planos causa a recompilação de todos os planos de execução posteriores e pode causar uma redução repentina e temporária no desempenho da consulta.

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 de pelo menos 100, introduzido no SQL Server 2008 (10.0.x):
A menos que NOINDEX seja especificado, DBCC CHECKDB executará 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_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 estiver especificado, apenas as verificações lógicas serão executadas.

Essas verificações de consistência lógica cruzam a verificação da tabela de índice interna do objeto de índice com a tabela de usuário que ele 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 significativo no desempenho e seu progresso não pode ser rastreado. Portanto, recomendamos especificar WITH EXTENDED_LOGICAL_CHECKS apenas 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 CHECKDB executa verificações de consistência para analisar se as entradas do índice atendem ao predicado do filtro.
Se o nível de compatibilidade for 90 ou menos, a menos que NOINDEX seja especificado, DBCC CHECKDB executará verificações de consistência física e lógica em uma única tabela ou exibição indexada e em todos os respectivos índices não clusterizados e XML. Não há suporte para índices espaciais.
No SQL Server 2016 (13.x) e versões posteriores, verificações adicionais em colunas computadas persistentes, colunas UDT e índices filtrados não são executadas por padrão para evitar as avaliações de expressão caras. Essa alteração reduz muito a duração de CHECKDB em relação aos bancos de dados que contêm esses objetos. No entanto, as verificações de consistência física desses objetos sempre são concluídas. Somente quando a opção EXTENDED_LOGICAL_CHECKS é especificada, as avaliações de expressão são executadas, além das verificações lógicas já presentes como parte da opção EXTENDED_LOGICAL_CHECKS (exibição indexada, índices XML e índices espaciais).

Saiba 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 de banco de dados interno

DBCC CHECKDB usa um instantâneo de banco de dados interno para a consistência transacional necessária a fim de executar essas verificações. Isso evita bloqueio e problemas de simultaneidade quando esses comandos são executados. Para obter mais informações, consulte Exibir o tamanho do arquivo esparso de um de instantâneo de banco de dados e a seção de uso de instantâneo de banco de dados interno do DBCC no DBCC. Se não for possível criar um instantâneo ou TABLOCK estiver especificado, DBCC CHECKDB obterá bloqueios a fim de adquirir a consistência necessária. Nesse caso, um bloqueio de banco de dados exclusivo é necessário para executar as verificações de alocação, e bloqueios de tabela compartilhados são necessários para executar as verificações de tabela.

DBCC CHECKDB falhará se for executado no banco de dados master quando não for possível criar um instantâneo de banco de dados interno.

A execução de DBCC CHECKDB em tempdb não realiza nenhuma verificação de alocação ou catálogo e deve adquirir bloqueios de tabela compartilhada a fim de executar verificações de tabela. 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 necessária.

Como o DBCC CHECKDB cria um banco de dados de instantâneo interno começando com o SQL Server 2014

DBCC CHECKDB cria um banco de dados de instantâneo interno.
O banco de dados de instantâneo interno é criado usando arquivos físicos. Por exemplo, para um banco de dados com database_id = 10 que tem três arquivos E:\Data\my_DB.mdf, E:\Data\my_DB.ndfe E:\Data\my_DB.ldf, o banco de dados de instantâneo interno é criado usando arquivos E:\Data\my_DB.mdf_MSSQL_DBCC11 e E:\Data\my_DB.ndf_MSSQL_DBCC11. O database_id do instantâneo é database_id + 1. Observe também que os novos arquivos são criados na mesma pasta usando a convenção de nomenclatura <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>. Nenhum arquivo esparso é criado para o log de transações.
Os novos arquivos são marcados como arquivos esparsos no nível do sistema de arquivos. O Size on Disk usado pelos novos arquivos aumenta com base na quantidade de dados atualizada no banco de dados de origem durante o comando DBCC CHECKDB. O Tamanho dos novos arquivos é o mesmo arquivo que o arquivo .mdf ou .ndf.
Os novos arquivos são excluídos no final do processamento de DBCC CHECKDB. Esses arquivos esparsos criados por DBCC CHECKDB têm o conjunto de atributos "Excluir ao fechar".

Aviso

Se o sistema operacional encontrar um desligamento inesperado enquanto o comando DBCC CHECKDB estiver em andamento, esses arquivos não serão limpos. Eles assumem espaço e podem causar falhas em execuções futuras de DBCC CHECKDB. Nesse caso, você pode excluir esses novos arquivos depois de confirmar que não há nenhum comando DBCC CHECKDB sendo executado no momento.

Os novos arquivos ficam visíveis com o uso de utilitários de arquivo comuns, como o Windows Explorer.

Observação

Antes do SQL Server 2014 (12.x), os fluxos de arquivo nomeados eram usados para criar os arquivos de instantâneo interno. Os fluxos de arquivo nomeados usaram o formato <filename.extension>:MSSQL_DBCC<database_id_of_snapshot>. Os fluxos de arquivos nomeados não são visíveis usando utilitários de arquivo comuns, como o Windows Explorer. Portanto, no SQL Server 2012 (11.x) e nas versões anteriores, você pode encontrar mensagens de erro 7926 e 5030 ao executar o comando DBCC CHECKDB para arquivos de banco de dados localizados em um volume formatado. Isso ocorre porque os fluxos de arquivos não podem ser criados em do Sistema de Arquivos Resiliente (RefS).

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 CHECKDB em um banco de dados 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 CHECKDB verifica se há um mapeamento um-para-um entre diretórios do sistema de arquivos e arquivos e linhas de tabela, colunas e valores de coluna. DBCC CHECKDB poderá reparar a corrupção se você especificar a opção REPAIR_ALLOW_DATA_LOSS. Para reparar a corrupção filestream, o DBCC exclui todas as linhas de tabela que estão faltando dados do sistema de arquivos.

Práticas recomendadas

É recomendável usar a opção PHYSICAL_ONLY para uso frequente em sistemas de produção. O uso de PHYSICAL_ONLY pode reduzir bastante o tempo de execução de DBCC CHECKDB em grandes bancos de dados. Também é recomendado executar DBCC CHECKDB periodicamente sem opções. A frequência dessas execuções depende das execuções de negócios individuais e de seus ambientes de produção.

Na Instância Gerenciada de SQL do Azure, o espaço de armazenamento disponível deve acomodar todo o arquivo de instantâneo do banco de dados interno criado pelo DBCC CHECKDB, independentemente de quanto dele é realmente usado pelos dados. Isso pode levar a uma situação em que a execução DBCC CHECKDB em um banco de dados muito grande, mas esparso (o tamanho dos dados é muito menor que o tamanho do arquivo de banco de dados) falha devido à falta de espaço na instância gerenciada de SQL. Se DBCC CHECKDB consumir todo o espaço de armazenamento disponível durante a execução, você receberá a seguinte mensagem de erro:

Msg 1133, Level 16, State 3, Line 1
The managed instance has reached its storage limit. To storage usage for the managed instance cannot exceed (...) MBs.
You might need to temporarily scale up your SQL managed instance storage capacity before running `DBCC CHECKDB` again.

Verificar objetos em paralelo

Por padrão, DBCC CHECKDB executa a verificação paralela de objetos. O grau de paralelismo é automaticamente determinado pelo processador de consulta. O grau de máximo de paralelismo é configurado da mesma forma que as 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, consulte Configuração do servidor: grau máximo de paralelismo. A verificação paralela pode ser desabilitada usando o sinalizador de rastreamento 2528. Para obter mais informações, consulte sinalizadores de rastreamento.

Observação

Esse 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 CHECKDB, uma mensagem é gravada no log de erros do SQL Server. Se o comando DBCC for executado com êxito, a mensagem indicará êxito e o tempo de execução do comando. Se o comando DBCC parar antes de concluir a verificação por causa de um erro, a mensagem indicará que o comando foi finalizado, um valor de estado e o tempo de 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 nos metadados que finalizou o 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 nos metadados que finalizou o comando DBCC.
`4`	Uma declaração ou violação de acesso foi detectada.
`5`	Ocorreu um erro desconhecido que finalizou o comando DBCC.

SQL Server registra a data e a hora em que uma verificação de consistência foi executada em um banco de dados sem erros (ou verificação de consistência "limpa"). Isso é conhecido como a last known clean check. Quando um banco de dados é iniciado pela primeira vez, essa data é gravada no EventLog (EventID-17573) e no log de erros no seguinte formato:

CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

Relatório de erros

Um despejo de pilha (SQLDump<nnnn>.txt, SQLDump<nnnn>.log, SQLDump<nnnn>.mdmp) é criado no diretório LOG do SQL Server sempre que DBCC CHECKDB 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 CHECKDB e a saída do diagnóstico adicional. O acesso é limitado à conta de serviço do SQL Server e aos membros da função sysadmin. Por padrão, a função de sysadmin contém todos os membros do grupo BUILTIN\Administrators 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 algum erro for relatado por DBCC CHECKDB, recomendamos restaurar o banco de dados do backup do banco de dados, em vez de executar DBCC CHECKDB com uma das opções de REPAIR_*. Se não existir nenhum backup, a execução de REPAIR corrigirá os erros relatados. A opção de reparo 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 a exclusão de algumas páginas e, portanto, de alguns dados.

Em algumas circunstâncias, valores inválidos ou que estão fora do intervalo com base no tipo de dados da coluna podem ser inseridos no banco de dados. DBCC CHECKDB pode detectar valores de coluna inválidos para todos os tipos de dados de coluna. Portanto, executar DBCC CHECKDB com a opção DATA_PURITY em bancos de dados atualizados de versões anteriores do SQL Server pode revelar erros de valor de coluna preexistentes. Como o SQL Server não pode reparar esses erros automaticamente, o valor de coluna deve ser atualizado manualmente. Se CHECKDB detectar esse erro, CHECKDB retornará um aviso, o número de erro 2570 e informações para identificar a linha afetada e corrigir manualmente o erro.

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 de um backup. Depois de concluir os reparos, faça um backup do banco de dados.

Resolver erros no modo de emergência do banco de dados

Quando um banco de dados foi definido para o modo de emergência por meio da instrução ALTER DATABASE, DBCC CHECKDB pode executar alguns reparos especiais nele caso a opção REPAIR_ALLOW_DATA_LOSS seja especificada. Esses reparos podem permitir que bancos de dados normalmente irrecuperáveis sejam colocados online novamente em um estado fisicamente consistente. Esses reparos devem ser usados como último recurso e somente quando não é possível restaurar o banco de dados com base em um backup. Quando o banco de dados é definido como modo de emergência, o banco de dados é marcado como READ_ONLY, o registro em log é desabilitado e o acesso é limitado a membros do sysadmin função de servidor fixa.

Observação

Você não pode executar o comando DBCC CHECKDB no modo de emergência dentro de uma transação de usuário e reverter a transação após a execução.

Quando o banco de dados está em modo de emergência e DBCC CHECKDB é executado com a cláusula REPAIR_ALLOW_DATA_LOSS, as seguintes ações são executadas:

DBCC CHECKDB usa páginas marcadas como inacessíveis devido a erros de E/S ou soma de verificação, como se os erros não tivessem ocorrido. Isso aumenta as chances de recuperação de dados do banco de dados.
DBCC CHECKDB tenta recuperar o banco de dados usando técnicas regulares de recuperação baseadas em log.
Se a recuperação do banco de dados não for bem-sucedida devido à corrupção do log de transações, esse log será recriado. Recompilar o log de transações pode resultar na perda de consistência transacional.

Aviso

A opção REPAIR_ALLOW_DATA_LOSS pode resultar em mais perda de dados do que se você restaurar de um último backup bom conhecido. Consulte Aviso de perda de dados com REPAIR_ALLOW_DATA_LOSS

Se o comando DBCC CHECKDB for bem-sucedido, o banco de dados estará em um estado fisicamente consistente e o status dele será definido como ONLINE. No entanto, o banco de dados pode conter uma ou mais inconsistências transacionais. É recomendável executar o DBCC CHECKCONSTRAINTS para identificar qualquer falha na lógica de negócios e fazer backup do banco de dados imediatamente.

Se o comando DBCC CHECKDB falhar, o banco de dados não poderá ser reparado.

Aviso de perda de dados com REPAIR_ALLOW_DATA_LOSS

A opção REPAIR_ALLOW_DATA_LOSS é um recurso do SQL Server com suporte. No entanto, pode nem sempre ser a melhor opção para levar um banco de dados a um estado fisicamente consistente. Se bem-sucedida, a opção REPAIR_ALLOW_DATA_LOSS poderá resultar em alguma perda de dados.

Na verdade, isso pode resultar em mais dados perdidos do que se um usuário restaurasse o banco de dados do último backup bom conhecido. A Microsoft sempre recomenda como o principal método de recuperação para os erros relatados por DBCC CHECKDB uma restauração do usuário com base no último backup adequado conhecido.

A opção REPAIR_ALLOW_DATA_LOSSnão é uma alternativa de restauração com base em um backup adequado conhecido. É uma opção de último recurso recomendada para uso somente se a restauração de um backup não possível.

Depois que ele recompila o log, não há nenhuma garantia acid completa.

Depois que ele recompila o log, DBCC CHECKDB é executado automaticamente e os relatórios e corrige problemas de consistência física.

Restrições de consistência de dados lógicos e lógica de negócios imposta devem ser validadas manualmente.

O tamanho do log de transações é deixado para seu tamanho padrão e deve ser ajustado manualmente de volta ao seu tamanho recente.

Executar DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS em bancos de dados replicados

A execução do comando DBCC CHECKDB com a opção REPAIR_ALLOW_DATA_LOSS pode afetar os bancos de dados do usuário (bancos de dados de publicação e assinatura) e o banco de dados de distribuição usado pela replicação. Bancos de dados de publicação e assinatura incluem tabelas publicadas e tabelas de metadados de replicação. Fique atento aos seguintes problemas potenciais nesses bancos de dados:

Tabelas publicadas. As ações executadas pelo processo CHECKDB para reparar dados do usuário corrompidos podem não ser replicadas:
A replicação de mesclagem usa gatilhos para controlar alterações em tabelas publicadas. Se linhas forem inseridas, atualizadas ou excluídas pelo processo CHECKDB, os gatilhos não serão acionados. Portanto, a alteração não será replicada.
A replicação transacional usa o log de transações para controlar alterações em tabelas publicadas. Em seguida, o Log Reader Agent move essas alterações para o banco de dados de distribuição. Alguns reparos do DBCC, embora registrados, não podem ser replicados pelo Agente de Leitor de Log. Por exemplo, se uma página de dados for desalocada pelo processo CHECKDB, o Agente de Leitor de Log não converterá essa desalocação em uma instrução DELETE. Portanto, a alteração não será replicada.
Tabelas de metadados de replicação. As ações executadas pelo processo CHECKDB para reparar tabelas de metadados de replicação corrompidas requerem a remoção e a reconfiguração da replicação.

Para executar o comando DBCC CHECKDB com a opção REPAIR_ALLOW_DATA_LOSS em um banco de dados de usuário ou de distribuição, façao seguinte:

Pare o sistema: Pare as atividades do banco de dados e de todos os outros bancos de dados da topologia da replicação e tente sincronizar todos os nós. Para obter mais informações, confira Como confirmar uma topologia de replicação (Programação Transact-SQL de replicação).
Execute DBCC CHECKDB.
Se o relatório DBCC CHECKDB incluir reparos para quaisquer tabelas no banco de dados de distribuição ou quaisquer tabelas de metadados de replicação em um banco de dados do usuário, remova e reconfigure a replicação. Para obter mais informações, consulte Desabilitar a publicação e a distribuição.
Se o relatório DBCC CHECKDB incluir reparos para quaisquer tabelas replicadas, execute a validação de dados a fim de determinar se há diferenças entre os dados nos bancos de dados de publicação e assinatura.

Conjunto de resultados

DBCC CHECKDB retorna o conjunto de resultados a seguir. Os valores podem variar, exceto quando as opções ESTIMATEONLY, PHYSICAL_ONLYou NO_INFOMSGS forem especificadas:

DBCC results for 'model'.
Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.
Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.
Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.
Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.

DBCC results for 'sys.sysrowsetcolumns'.
There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.

DBCC results for 'sys.sysrowsets'.
There are 97 rows in 1 pages for object 'sys.sysrowsets'.

DBCC results for 'sysallocunits'.
There are 195 rows in 3 pages for object 'sysallocunits'.
There are 0 rows in 0 pages for object "sys.sysasymkeys".

DBCC results for 'sys.syssqlguides'.
There are 0 rows in 0 pages for object "sys.syssqlguides".

DBCC results for 'sys.queue_messages_1977058079'.
There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".

DBCC results for 'sys.queue_messages_2009058193'.
There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".

DBCC results for 'sys.queue_messages_2041058307'.
There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".

CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB retorna o seguinte conjunto de resultados (mensagem) quando NO_INFOMSGS é especificado:

The command(s) completed successfully.

DBCC CHECKDB retorna o seguinte conjunto de resultados quando PHYSICAL_ONLY é especificado:

DBCC results for 'model'.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB retorna o conjunto de resultados a seguir quando ESTIMATEONLY é especificado.

Estimated TEMPDB space needed for CHECKALLOC (KB)
-------------------------------------------------
13

(1 row(s) affected)

Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
57

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Permissões

Requer associação no sysadmin função de servidor fixa ou a função de banco de dados fixa db_owner.

Exemplos

a. Verificar o banco de dados atual e outro banco de dados

O exemplo a seguir executa DBCC CHECKDB para o banco de dados atual e o banco de dados AdventureWorks2022.

-- Check the current database.
DBCC CHECKDB;
GO

-- Check the AdventureWorks2022 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2022, NOINDEX);
GO

B. Verificar o banco de dados atual, suprimindo mensagens informativas

O exemplo a seguir verifica o banco de dados atual e suprime todas as mensagens informativas.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Compartilhar via

DBCC CHECKDB (Transact-SQL)

Sintaxe

Argumentos

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Comentários

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

Saiba o nível de compatibilidade de um banco de dados

Instantâneo de banco de dados interno

Como o DBCC CHECKDB cria um banco de dados de instantâneo interno começando com o SQL Server 2014

Verificar e reparar os dados FILESTREAM

Práticas recomendadas

Verificar objetos em paralelo

Entender as mensagens de erro do DBCC

Relatório de erros

Resolver erros

Resolver erros no modo de emergência do banco de dados

Aviso de perda de dados com REPAIR_ALLOW_DATA_LOSS

Executar DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS em bancos de dados replicados

Conjunto de resultados

Permissões

Exemplos

a. Verificar o banco de dados atual e outro banco de dados

B. Verificar o banco de dados atual, suprimindo mensagens informativas

Comentários

Recursos adicionais

Compartilhar via

DBCC CHECKDB (Transact-SQL)

Sintaxe

Argumentos

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Comentários

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

Saiba o nível de compatibilidade de um banco de dados

Instantâneo de banco de dados interno

Como o DBCC CHECKDB cria um banco de dados de instantâneo interno começando com o SQL Server 2014

Verificar e reparar os dados FILESTREAM

Práticas recomendadas

Verificar objetos em paralelo

Entender as mensagens de erro do DBCC

Relatório de erros

Resolver erros

Resolver erros no modo de emergência do banco de dados

Aviso de perda de dados com REPAIR_ALLOW_DATA_LOSS

Executar DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS em bancos de dados replicados

Conjunto de resultados

Permissões

Exemplos

a. Verificar o banco de dados atual e outro banco de dados

B. Verificar o banco de dados atual, suprimindo mensagens informativas

Conteúdo relacionado

Comentários

Recursos adicionais