DBCC CHECKDB (Transact-SQL)
Aplica-se a:
SQL ServerBanco de Dados SQL do AzureInstância Gerenciada SQL do Azure
Verifica a integridade lógica e física de todos os objetos no banco de dados especificado executando as seguintes operações:
Executa DBCC CHECKTABLE em todas as tabelas e exibições no banco de dados.
Valida o conteúdo de cada exibição indexada no banco de dados.
Valida a consistência no nível de link entre metadados de tabela e diretórios e arquivos do sistema de arquivos ao armazenar dados de varbinary(max) no sistema de arquivos usando FILESTREAM.
Valida os dados do Service Broker no banco de dados.
Isso significa que os comandos DBCC CHECKALLOC, DBCC CHECKTABLEou DBCC CHECKCATALOG não precisam ser executados separadamente do DBCC CHECKDB. Para obter informações mais detalhadas sobre as verificações que esses comandos executam, consulte as descrições desses comandos.
DBCC CHECKDB é suportado em bancos de dados que contêm tabelas com otimização de memória, mas a validação só ocorre em tabelas baseadas em disco. No entanto, como parte do backup e recuperação do 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 DBCC não estão disponíveis para tabelas com otimização de memória, você deve fazer backup de seus bancos de dados regularmente e testar os backups. Se ocorrerem problemas de integridade de dados em uma tabela com otimização de memória, você deverá restaurar a partir do último backup em boas condições.
Transact-SQL convenções de sintaxe
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 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 das bases de dados devem estar em conformidade com as regras relativas aos identificadores de .
NOÍNDICE
Especifica que verificações intensivas de índices não clusterizados para tabelas de usuário não são executadas. Essa escolha diminui o tempo de execução geral.
NOINDEX não afeta as tabelas do sistema porque as verificações de integridade são sempre executadas nos índices das tabelas do sistema.
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Especifica que DBCC CHECKDB repara os erros encontrados. Utilize as opções REPAIR_* apenas como último recurso. O banco de dados especificado deve estar no modo de usuário único para usar uma das seguintes opções de reparo.
REPAIR_ALLOW_DATA_LOSSTenta reparar todos os erros relatados. Esses reparos podem causar alguma perda de dados.
Advertência
A opção
REPAIR_ALLOW_DATA_LOSSpode resultar em mais perda de dados do que se você restaurar a partir de um último backup em boas condições. Consulte Aviso de perda de dados com REPAIR_ALLOW_DATA_LOSSA Microsoft sempre recomenda uma restauração do usuário a partir do último backup em boas condições como o método principal para se recuperar de erros relatados pelo
DBCC CHECKDB. A opçãoREPAIR_ALLOW_DATA_LOSSnão é uma alternativa para restaurar a partir de um backup em boas condições. É uma opção de emergência último recurso recomendada para uso somente se a restauração a partir 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 deslocalização de uma linha, página ou série de páginas para limpar os erros. 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 quaisquer linhas ou páginas são desalocadas porque as restrições de chave estrangeira não são verificadas ou mantidas como parte dessa operação de reparo. O usuário deve inspecionar a integridade referencial de seu banco de dados (usandoDBCC CHECKCONSTRAINTS) depois de usar a opçãoREPAIR_ALLOW_DATA_LOSS.Antes de executar o reparo, você deve criar cópias físicas dos arquivos que pertencem a esse 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ções (.ldf) e outros contêineres que formam o banco de dados, incluindo catálogos de texto completo, pastas de fluxo de arquivos, 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
EMERGENCYe tentar extrair o máximo de informações possível das tabelas críticas e salvar esses dados.REPAIR_FASTMantém a sintaxe apenas para compatibilidade com versões anteriores. Nenhuma ação de reparo é executada.
REPAIR_REBUILDRealiza reparos que não têm 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 reconstrução de um índice.
Esse argumento não repara erros envolvendo dados 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 quaisquer opções de REPAIR_* 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 comprometer todo o trabalho feito pela operação de reparo. Se o usuário não quiser aceitar os resultados da operação, ele pode executar um ROLLBACK TRANSACTION para desfazer os efeitos das operações de reparo.
Para reparar erros, recomendamos restaurar a partir de uma cópia de segurança. As operações de reparo não consideram nenhuma das restrições que possam existir nas tabelas ou entre elas. Se a tabela especificada estiver envolvida em uma ou mais restrições, recomendamos executáDBCC CHECKCONSTRAINTS após uma operação de reparo. Se tiver de utilizar REPAIR_*, execute DBCC CHECKDB sem uma opção de reparação para encontrar o nível de reparação a utilizar. Se você usar o nível de REPAIR_ALLOW_DATA_LOSS, recomendamos que faça backup do banco de dados antes de executar DBCC CHECKDB com essa 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 tem efeito. As mensagens de erro são classificadas por ID de objeto, exceto as mensagens geradas a partir de 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 um modo de exibição indexado, índices XML e índices espaciais, quando presentes.
Para obter mais informações, consulte 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 obtenham 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 seja executado 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 que são realizadas; DBCC CHECKCATALOG não é executado no banco de dados e os dados do Service Broker não são validados.
ESTIMATIVAAPENAS
Exibe a quantidade estimada de espaço de tempdb necessário 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 dos cabeçalhos de página e registro e à consistência de alocação do banco de dados. Essa verificação foi projetada para fornecer uma pequena verificação geral da consistência física do banco de dados, mas também pode detetar páginas rasgadas, 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 verificar são mais complexas.
- Muitas novas verificações foram introduzidas 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. Ainda recomendamos que uma execução completa de DBCC CHECKDB seja realizada periodicamente. A frequência dessas execuções depende de fatores específicos de empresas individuais e ambientes de produção.
Este argumento implica sempre NO_INFOMSGS e não é permitido com nenhuma das opções de reparação.
Advertência
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 que não são válidos ou estão fora do intervalo. Por exemplo, o DBCC CHECKDB deteta colunas com valores de data e hora maiores ou menores do que o intervalo aceitável para o tipo de dados data/hora ; ou decimal ou colunas de tipo de dados numérico aproximado com valores de escala ou precisão que não são válidos.
As verificações de integridade do valor da coluna são habilitadas por padrão e não exigem a opção DATA_PURITY. Para bancos de dados atualizados de versões anteriores do SQL Server, as verificações de valor de coluna não são habilitadas por padrão até que DBCC CHECKDB WITH DATA_PURITY tenha sido executado sem erros no banco de dados. Depois disso, DBCC CHECKDB verifica a integridade do valor da coluna por padrão. Para obter mais informações sobre como CHECKDB pode ser afetado pela atualização do banco de dados de versões anteriores do SQL Server, consulte a seção Comentários mais adiante neste artigo.
Advertência
Se PHYSICAL_ONLY for especificado, as verificações de integridade da coluna não serão executadas.
Os erros de validação relatados por essa opção não podem ser corrigidos usando as opções de reparo DBCC. Para obter informações sobre como corrigir manualmente esses erros, consulte MSSQLSERVER_2570.
MAXDOP
Aplica-se ao: 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 Administrador de Recursos, o Mecanismo de Banco de Dados do SQL Server usará o valor MAXDOP Administrador de Recursos, 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.
Advertência
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 desativados. 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 bytes, deve haver 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 bytes causa o erro 2537 quando DBCC CHECKDB é executado. Para obter mais informações, consulte Criando tipos de User-Defined - Requisitos.
Como o do banco de dados Resource é modificável apenas 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 , uma segunda CHECKDB também é executada 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 é definida ou quando a opção PHYSICAL_ONLY ou ESTIMATEONLY é definida.
No SQL Server 2005 (9.x) Service Pack 2 e versões posteriores, a execução do DBCC CHECKDB não limpa mais o cache de plano para a instância do SQL Server. Antes do SQL Server 2005 (9.x) Service Pack 2, a execução do DBCC CHECKDB limpa o cache do plano. A limpeza do cache do plano causa a recompilação de todos os planos de execução posteriores e pode causar uma diminuição súbita e temporária no desempenho da consulta.
Executar verificações de consistência lógica em índices
A verificação da consistência lógica nos índices varia de acordo com o nível de compatibilidade do banco de dados, da seguinte forma:
Se o nível de compatibilidade for pelo menos 100 (introduzido no SQL Server 2008 (10.0.x)):
A menos que
NOINDEXseja especificado,DBCC CHECKDBexecuta verificações de consistência física e lógica em uma única tabela e em todos os seus índices não clusterizados. No entanto, em índices XML, índices espaciais e exibições indexadas, apenas verificações de consistência física são executadas por padrão.Se
WITH EXTENDED_LOGICAL_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 for especificado, apenas as verificações lógicas serão executadas.
Essas verificações de consistência lógica cruzam a tabela de índice interna do objeto de índice com a tabela do usuário à qual ele está se referindo. Para encontrar linhas periféricas, uma consulta interna é construída para executar uma interseção completa das tabelas interna e de usuário. A execução dessa consulta pode ter um efeito significativo no desempenho e seu progresso não pode ser rastreado. Portanto, recomendamos que você especifique WITH EXTENDED_LOGICAL_CHECKS somente se suspeitar de problemas de índice que não estejam relacionados a corrupção física ou se somas de verificação no nível da página tiverem sido desativadas e você suspeitar de corrupção de hardware no nível da coluna.
Se o índice for um índice filtrado,
DBCC CHECKDBexecuta verificações de consistência para verificar se as entradas de índice satisfazem o predicado do filtro.Se o nível de compatibilidade for 90 ou menos, a menos que
NOINDEXseja especificado,DBCC CHECKDBexecuta verificações de consistência física e lógica em uma única tabela ou exibição indexada e em todos os seus índices XML e não clusterizados. 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 dispendiosas. Essa alteração reduz consideravelmente a duração do
CHECKDBem bancos de dados que contêm esses objetos. No entanto, a verificação de consistência física desses objetos é sempre concluída. Somente quandoEXTENDED_LOGICAL_CHECKSopção é especificada, as avaliações de expressão são realizadas, além das verificações lógicas que já estão presentes como parte da opçãoEXTENDED_LOGICAL_CHECKS(exibição indexada, índices XML e índices espaciais).
Saiba o nível de compatibilidade de um banco de dados
Instantâneo do banco de dados interno
DBCC CHECKDB usa um instantâneo de banco de dados interno para a consistência transacional necessária para executar essas verificações. Isso evita problemas de bloqueio e 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 DBCC em DBCC. Se não for possível criar um snapshot ou TABLOCK for especificado, DBCC CHECKDB adquire bloqueios para obter 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 compartilhada são necessários para executar as verificações de tabela.
DBCC CHECKDB falhará quando executado no banco de dados master se não for possível criar um instantâneo interno do banco de dados.
A execução de DBCC CHECKDB contra tempdb não executa nenhuma verificação de alocação ou catálogo e deve adquirir bloqueios de tabela compartilhados para executar verificações de tabela. Isso ocorre porque, por motivos de desempenho, os instantâneos do banco de dados não estão disponíveis no tempdb. Isso significa que a consistência transacional necessária não pode ser obtida.
Como DBCC CHECKDB cria um banco de dados de instantâneo interno começando com o SQL Server 2014
DBCC CHECKDBcria 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 = 10que tenha três arquivosE:\Data\my_DB.mdf,E:\Data\my_DB.ndfeE:\Data\my_DB.ldf, o banco de dados de instantâneo interno é criado usando arquivosE:\Data\my_DB.mdf_MSSQL_DBCC11eE:\Data\my_DB.ndf_MSSQL_DBCC11. Odatabase_iddo 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 Tamanho do no disco usado pelos novos arquivos aumenta com base na quantidade de dados atualizados no banco de dados de origem durante o comando
DBCC CHECKDB. A Tamanho do dos novos arquivos é o mesmo arquivo que o arquivo.mdfou.ndf.Os novos ficheiros são eliminados no final do
DBCC CHECKDBprocessamento. Esses arquivos esparsos que são criados porDBCC CHECKDBtêm os atributos "Excluir ao fechar" definidos.
Advertência
Se o sistema operacional encontrar um desligamento inesperado enquanto o comando DBCC CHECKDB estiver em andamento, esses arquivos não serão limpos. Eles ocupam espaço e podem potencialmente causar falhas em futuras execuções 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 são visíveis usando utilitários de arquivo comuns, como o Windows Explorer.
Observação
Antes do SQL Server 2014 (12.x), os fluxos de arquivos nomeados eram usados para criar os arquivos de instantâneo internos. Os fluxos de arquivo nomeado usado 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 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 ReFS-formatado volume. Isso ocorre porque os fluxos de arquivos não podem ser criados em sistema de arquivos resiliente (RefS).
Verificar e reparar dados FILESTREAM
Quando FILESTREAM está habilitado para um banco de dados e tabela, você pode, opcionalmente, armazenar varbinary(max) objetos binários grandes (BLOBs) no sistema de arquivos. Ao usar DBCC 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 verificará se há um mapeamento um-para-um entre diretórios e arquivos do sistema de arquivos e linhas, colunas e valores de coluna da tabela.
DBCC CHECKDB pode reparar a corrupção se você especificar a opção REPAIR_ALLOW_DATA_LOSS. Para reparar a corrupção FILESTREAM, DBCC exclui todas as linhas da tabela que estão faltando dados do sistema de arquivos.
Melhores práticas
Recomendamos que você use a opção PHYSICAL_ONLY para uso frequente em sistemas de produção. O uso PHYSICAL_ONLY pode reduzir muito o tempo de execução para DBCC CHECKDB em bancos de dados grandes. Também recomendamos que você execute periodicamente DBCC CHECKDB sem opções. A frequência com que você deve executar essas execuções depende de empresas individuais e seus ambientes de produção.
Na Instância Gerenciada SQL do Azure, o espaço de armazenamento disponível deve acomodar todo o arquivo de instantâneo do banco de dados interno criado por DBCC CHECKDB, independentemente de quanto dele é realmente usado pelos dados. Isso pode levar a uma situação em que a execução de DBCC CHECKDB em um banco de dados muito grande, mas esparso (o tamanho dos dados é muito menor do que o tamanho do arquivo de banco de dados) falha devido à falta de espaço em sua instância gerenciada SQL. Se DBCC CHECKDB consome 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 é determinado automaticamente pelo processador de consultas. O grau máximo de paralelismo é configurado como consultas paralelas. Para restringir o número máximo de processadores disponíveis para verificação DBCC, use sp_configure. Para obter mais informações, consulte Configuração do servidor : grau máximo de paralelismo. A verificação paralela pode ser desativada usando o sinalizador de rastreamento 2528. Para obter mais informações, consulte Rastrear sinalizadores.
Observação
Esse recurso não está disponível em todas as edições do SQL Server. Para obter mais informações, consulte a verificação de consistência paralela na seção de gerenciabilidade do RDBMS de Edições e recursos com suporte do SQL Server 2022.
Compreender as mensagens de erro DBCC
Após a conclusão do comando DBCC CHECKDB, uma mensagem é gravada no log de erros do SQL Server. Se o comando DBCC for executado com êxito, a mensagem indica o êxito e a quantidade de tempo que o comando foi executado. Se o comando DBCC parar antes de concluir a verificação devido a um erro, a mensagem indica que o comando foi encerrado, um valor de estado e a quantidade de tempo que o comando foi executado. A tabela a seguir lista e descreve os valores de estado que podem ser incluídos na mensagem.
| Estado | Descrição |
|---|---|
0 |
O erro número 8930 foi gerado. Isso indica uma corrupção nos metadados que encerrou o comando DBCC. |
1 |
O erro número 8967 foi gerado. Houve um erro interno do DBCC. |
2 |
Ocorreu uma falha durante o reparo do banco de dados no modo de emergência. |
3 |
Isso indica uma corrupção nos metadados que encerrou o comando DBCC. |
4 |
Foi detetada uma violação de afirmação ou acesso. |
5 |
Ocorreu um erro desconhecido que encerrou o comando DBCC. |
O SQL Server registra a data e a hora em que uma verificação de consistência foi executada para um banco de dados sem erros (ou verificação de consistência "limpa"). Isto é conhecido como o 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 do SQL Server LOG sempre que DBCC CHECKDB deteta um erro de corrupção. Quando os recursos de coleta de dados de Uso de Recursos e Relatório de Erros são habilitados para a instância do SQL Server, o arquivo é encaminhado automaticamente para a Microsoft. Os dados coletados são usados para melhorar a funcionalidade do SQL Server.
O arquivo de despejo contém os resultados do comando DBCC CHECKDB e saída de 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 sysadmin contém todos os membros do grupo Windows BUILTIN\Administrators e do grupo do administrador local. O comando DBCC não falhará se o processo de coleta de dados falhar.
Resolver erros
Se algum erro for relatado pelo DBCC CHECKDB, recomendamos restaurar o banco de dados a partir do backup do banco de dados, em vez de executar DBCC CHECKDB com uma das opções REPAIR_*. Se não houver backup, a execução do reparo corrige os erros relatados. A opção de reparo a ser usada é especificada no final 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, alguns dados.
Em algumas circunstâncias, podem ser inseridos no banco de dados valores que não são válidos ou estão fora do intervalo com base no tipo de dados da coluna.
DBCC CHECKDB pode detetar valores de coluna que não são válidos para todos os tipos de dados de coluna. Portanto, executar DBCC CHECKDB com a opção DATA_PURITY em bancos de dados que foram atualizados de versões anteriores do SQL Server pode revelar erros de valor de coluna preexistentes. Como o SQL Server não pode reparar automaticamente esses erros, o valor da coluna deve ser atualizado manualmente. Se CHECKDB detetar esse erro, CHECKDB retornará um aviso, o número do erro 2570 e informações para identificar a linha afetada e corrigir manualmente o erro.
O reparo pode ser executado sob uma transação de usuário para permitir que o usuário reverta as alterações que foram feitas. Se os reparos forem revertidos, o banco de dados ainda conterá erros e deverá ser restaurado a partir de um backup. Após a conclusão dos reparos, faça 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 usando a instrução ALTER DATABASE, DBCC CHECKDB pode executar alguns reparos especiais no banco de dados se a opção REPAIR_ALLOW_DATA_LOSS for 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 você não puder restaurar o banco de dados a partir de um backup. Quando o banco de dados é definido para o modo de emergência, o banco de dados é marcado como READ_ONLY, o registro em log é desabilitado e o acesso é limitado aos membros do sysadmin função de servidor fixa.
Observação
Não é possível 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á no modo de emergência e DBCC CHECKDB com a cláusula REPAIR_ALLOW_DATA_LOSS é executado, as seguintes ações são executadas:
DBCC CHECKDBusa páginas que foram marcadas como inacessíveis devido a erros de E/S ou soma de verificação, como se os erros não tivessem ocorrido. Fazer isso aumenta as chances de recuperação de dados do banco de dados.DBCC CHECKDBtenta 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, o log de transações será reconstruído. A reconstrução do log de transações pode resultar na perda de consistência transacional.
Advertência
A opção REPAIR_ALLOW_DATA_LOSS pode resultar em mais perda de dados do que se você restaurar a partir de um último backup em boas condições. 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 do banco de dados será definido como ONLINE. No entanto, o banco de dados pode conter uma ou mais inconsistências transacionais. Recomendamos que você execute DBCC CHECKCONSTRAINTS para identificar quaisquer falhas de lógica de negócios e fazer backup imediato do banco de dados.
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 com suporte do SQL Server. No entanto, nem sempre pode ser a melhor opção para trazer um banco de dados para um estado fisicamente consistente. Se for bem-sucedida, a opção REPAIR_ALLOW_DATA_LOSS pode 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 a partir do último backup em boas condições. A Microsoft sempre recomenda uma restauração do usuário a partir do último backup em boas condições como o método principal para se recuperar de erros relatados pelo DBCC CHECKDB.
A opção REPAIR_ALLOW_DATA_LOSS não é uma alternativa para restaurar a partir de um backup em boas condições. É uma opção de emergência último recurso recomendada para uso somente se a restauração a partir de um backup não for possível.
Depois de reconstruir o log, não há garantia total de ACID.
Depois de reconstruir o log, DBCC CHECKDB é executado automaticamente e relata e corrige problemas de consistência física.
A consistência dos dados lógicos e as restrições impostas pela lógica de negócios 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.
Execute 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. Os bancos de dados de publicação e assinatura incluem tabelas publicadas e tabelas de metadados de replicação. Esteja ciente dos seguintes problemas potenciais nesses bancos de dados:
Tabelas publicadas. As ações executadas pelo processo de
CHECKDBpara reparar dados corrompidos do usuário podem não ser replicadas:A replicação de mesclagem usa gatilhos para controlar alterações em tabelas publicadas. Se as linhas forem inseridas, atualizadas ou excluídas pelo processo de
CHECKDB, os gatilhos não serão acionados; portanto, a alteração não é 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 DBCC, embora registrados, não podem ser replicados pelo Log Reader Agent. Por exemplo, se uma página de dados for desalocada pelo processo
CHECKDB, o Log Reader Agent não traduzirá essa desalocação para uma instrução DELETE; portanto, a alteração não é replicada.Tabelas de metadados de replicação. As ações executadas pelo processo de
CHECKDBpara reparar tabelas de metadados de replicação corrompidas exigem a remoção e a reconfiguração da replicação.
Se você tiver que executar o comando DBCC CHECKDB com a opção REPAIR_ALLOW_DATA_LOSS em um banco de dados de usuário ou banco de dados de distribuição:
Desativar o sistema: interrompa a atividade no banco de dados e em todos os outros bancos de dados na topologia de replicação e tente sincronizar todos os nós. Para obter mais informações, consulte desativar uma topologia de replicação (replicação Transact-SQL programação).
Execute
DBCC CHECKDB.Se o relatório
DBCC CHECKDBincluir reparos para quaisquer tabelas no banco de dados de distribuição ou quaisquer tabelas de metadados de replicação em um banco de dados de usuário, remova e reconfigure a replicação. Para obter mais informações, consulte Desabilitarde publicação e distribuição .Se o relatório de
DBCC CHECKDBincluir reparos para quaisquer tabelas replicadas, execute a validação de dados para determinar se há diferenças entre os dados nos bancos de dados de publicação e assinatura.
Conjunto de resultados
DBCC CHECKDB retorna o seguinte conjunto de resultados. Os valores podem variar, exceto quando as opções ESTIMATEONLY, PHYSICAL_ONLYou 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 seguinte conjunto de resultados 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 à função de servidor fixa sysadmin ou à função de banco de dados fixa db_owner.
Exemplos
Um. Verifique o banco de dados atual e outro
O exemplo a seguir executa DBCC CHECKDB para o banco de dados atual e para 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. Verifique 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