Partilhar via

DBCC CHECKDB (Transact-SQL)

  • Artigo

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 de banco de dados, uma validação de 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 não serão executadas verificações intensivas de índices não clusterizados para tabelas de usuário. 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 REPAIR apenas como um ú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 é um recurso compatível, mas nem sempre é a melhor opção para colocar um banco de dados em um estado fisicamente consistente. Se for bem-sucedida, a opção REPAIR_ALLOW_DATA_LOSS poderá resultar em perdas de dados. Na verdade, ela pode resultar em mais dados perdidos do que se um usuário restaurar o banco de dados por meio do último backup válido.

    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. Ela é um recurso de emergência recomendado somente quando a restauração de um backup não é possível.

    Alguns 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 a fim de serem resolvidos. Qualquer dado desalocado não é mais acessível nem recuperável pelo usuário e o conteúdo exato dos dados desalocados não pode ser determinado. Portanto, a integridade referencial pode não ser precisa após a desalocação de linhas ou páginas porque as restrições de chave estrangeira não estão marcadas nem mantidas como parte da 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 o 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

Como DBCC CHECKDB são completamente registrados e recuperáveis com qualquer uma das opções REPAIR, a Microsoft sempre recomenda que um usuário faça uso de DBCC CHECKDB com qualquer opção REPAIR em uma transação (execute BEGIN TRANSACTION antes de executar o comando) a fim de 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. Caso ele não queira aceitar os resultados da operação de reparo, pode executar ROLLBACK TRANSACTION para desfazer esses efeitos.

Para reparar erros, recomendamos restaurar de um backup. Operações de reparo não consideram nenhuma das restrições que podem existir em tabelas 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 for necessário 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 fará com que DBCC CHECKDB seja executado mais rapidamente em um banco de dados sob alta carga, mas diminuirá a simultaneidade disponível nele enquanto DBCC CHECKDB estiver em execução.

Importante

TABLOCK limita as verificações que são realizadas, 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 muito mais tempo para ser concluída do que nas 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 grandes bancos de dados 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 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.

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 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 de 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.

Aviso

Se MAXDOP for definido como zero, o SQL Server escolherá o grau máximo de paralelismo para uso.

Comentários

DBCC CHECKDB não examina índices desabilitados. Para obter mais informações sobre índices desabilitados, confira 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, confira Requisitos do tipo definido pelo usuário.

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.

Desde o SQL Server 2005 (9.x) Service Pack 2, a execução de DBCC CHECKDB não limpa mais o cache do plano da 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. A limpeza do cache do plano gera uma recompilação de todos os planos de execução posteriores e pode provocar uma queda 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 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 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.
  • 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 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).

Para saber 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, confira Exibir o tamanho do arquivo esparso de um instantâneo de banco de dados (Transact-SQL) e a seção Uso de 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 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

  1. DBCC CHECKDB cria um banco de dados de instantâneo interno.

  2. O banco de dados de instantâneo interno é criado usando arquivos físicos. Por exemplo, no caso de um banco de dados database_id = 10 com os três arquivos E:\Data\my_DB.mdf, E:\Data\my_DB.ndf e E:\Data\my_DB.ldf, o banco de dados de instantâneo interno será criado usando os 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.

  3. Os novos arquivos são marcados como arquivos esparsos no nível do sistema de arquivos. O tamanho no disco usado pelos novos arquivos aumentará com base na quantidade de dados atualizados no banco de dados de origem durante o comando DBCC CHECKDB. O tamanho dos novos arquivos será igual ao do arquivo .mdf ou .ndf.

  4. 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 ocuparão espaço e poderão causar falhas em execuções futuras de DBCC CHECKDB. Nesse caso, é possível excluir esses novos arquivos depois de confirmar que não há nenhum comando DBCC CHECKDB sendo executado.

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 ficam visíveis com o uso de utilitários de arquivo comuns, como o Windows Explorer. Portanto, no SQL Server 2012 (11.x) e versões anteriores, é possível encontrar as mensagens de erro 7926 e 5030 ao executar o comando DBCC CHECKDB para arquivos de banco de dados localizados em um volume formatado em ReFS. Isso ocorre porque os fluxos de arquivos não podem ser criados no RefS (sistema de arquivos resiliente).

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 use o atributo FILESTREAM, DBCC CHECKDB verificará se há um mapeamento um-para-um entre os diretórios e os arquivos do sistema de arquivos e entre as linhas e colunas da tabela e os valores das colunas. DBCC CHECKDB poderá reparar a corrupção se você especificar a opção REPAIR_ALLOW_DATA_LOSS. Para reparar dano de FILESTREAM, o DBCC excluirá quaisquer linhas de tabela que não tiverem 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, 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

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 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.

Observação

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 arquivo de despejo (SQLDUMP<nnnn>.txt) é 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, 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 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 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 geralmente irrecuperáveis sejam colocados online 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 estiver definido como modo de emergência, o banco dedados será marcado como READ_ONLY, o registro em log será desabilitado e o acesso será limitado aos membros da função de servidor fixa sysadmin.

Observação

Não é possível executar o comando DBCC CHECKDB no modo de emergência de uma transação do usuário e reverter essa transação após a execução.

Quando o banco de dados está em modo de emergência e REPAIR_ALLOW_DATA_LOSS é executado com a cláusula DBCC CHECKDB, 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. A reconstrução do log de transações pode resultar na perda de consistência transacional.

Aviso

A opção REPAIR_ALLOW_DATA_LOSS é um recurso do SQL Server com suporte. No entanto, não sempre é a melhor opção para colocar um banco de dados em um estado fisicamente consistente. Se for bem-sucedida, a opção REPAIR_ALLOW_DATA_LOSS poderá resultar em perdas de dados. Na verdade, ela pode resultar em mais dados perdidos do que se um usuário restaurar o banco de dados por meio do último backup válido. 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. Ela é um recurso de emergência recomendado somente quando a restauração de um backup não é possível.

Depois de recriar o log, não há nenhuma garantia ACID completa.

Após a recriação do log, DBCC CHECKDB será executado automaticamente e relatará e corrigirá 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ção será deixado ao seu tamanho padrão e deve ser ajustado manualmente para o tamanho recente.

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 poderá 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.

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:

  1. 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).
  2. Execute DBCC CHECKDB.
  3. 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.
  4. 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.

Conjuntos de resultados

DBCC CHECKDB retorna o conjunto de resultados a seguir. Os valores podem variar, exceto quando as opções ESTIMATEONLY, PHYSICAL_ONLY ou NO_INFOMSGS são 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

Exige associação à função de servidor fixa sysadmin ou à 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

Confira também