DBCC CHECKDB (Transact-SQL)
Verifica a integridade lógica e física de todos os objetos do banco de dados especificado executando as seguintes operações:
Executa DBCC CHECKALLOC no banco de dados.
Executa DBCC CHECKTABLE em cada tabela e exibição do banco de dados.
Executa DBCC CHECKCATALOG no banco de dados.
Valida o conteúdo de toda exibição indexada do banco de dados.
Valida consistência em nível de vinculação entre metadados da tabela e diretórios e arquivos do sistema de arquivos ao armazenar dados varbinary(max) no sistema de arquivos usando FILESTREAM.
Valida os dados Service Broker no banco de dados.
Isso significa que os comandos DBCC CHECKALLOC, DBCC CHECKTABLE ou DBCC CHECKCATALOG não precisam ser executados separadamente do DBCC CHECKDB. Para obter informações mais detalhadas sobre as verificações executadas, consulte as descrições desses comandos.
.gif "Ícone de vínculo de tópico")
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 } ]
}
]
]
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 estiver especificado ou se 0 estiver especificado, o banco de dados atual será usado. Os nomes de bancos de dados devem atender às regras de identificadores.NOINDEX
Especifica que não devem ser executadas verificações intensivas de índices não clusterizados de tabelas de usuário. Isto reduz o tempo de execução geral. NOINDEX não afeta tabelas do sistema porque as verificações de integridade sempre são executadas em todos os índices de tabela do sistema.REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Especifica que DBCC CHECKDB repara os erros encontrados. 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.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. Isso pode incluir reparos rápidos, como reparo de linhas perdidas em índices não clusterizados e reparos mais demorados, como a recriação de um índice.REPAIR_REBUILD não repara erros que envolvem dados de FILESTREAM.
.gif "Observação importante")
ImportanteUse as opções REPAIR apenas como um último recurso. 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 executar 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. Se você usar o nível de REPAIR_ALLOW_DATA_LOSS, recomendamos fazer backup do banco de dados antes de executar DBCC CHECKDB com essa opção.
ALL_ERRORMSGS
Exibe todos os erros relatados por objeto. No SQL Server 2008 Service Pack 1 (SP1), todas as mensagens de erro são exibidas por padrão. Especificar ou omitir esta opção não tem nenhum efeito. Em versões anteriores do SQL Server (salvo SQL Server 2005 SP3), somente as primeiras 200 mensagens de erro de cada objeto eram exibidas se ALL_ERRORMSGS não fosse especificado. As mensagens de erro são classificadas por ID de objeto, exceto para as mensagens geradas no banco de dados tempdb.No SQL Server Management Studio, o número máximo de mensagens de erro retornadas é 1000. Usando o Management Studio, pode ser necessário executar DBCC CHECKDB várias vezes para obter uma lista completa de erros quando ALL_ERRORMSGS estiver especificado. Ao especificar ALL_ERRORMSGS, é recomendável executar o comando DBCC usando o utilitário sqlcmd ou agendando um trabalho do SQL Server Agent para executar o comando e direcionar a saída para um arquivo. Qualquer um desses métodos garantirá que uma única execução do comando relatará todas as mensagens de erro.
EXTENDED_LOGICAL_CHECKS
Se o nível de compatibilidade for 100 (SQL Server 2008) ou superior, executará verificações de consistência lógica em uma exibição indexada, índices XML e índices espaciais, quando presentes.Para obter mais informações, consulte "Executando verificações de consistência lógica em índices" na seção "Comentários" deste tópico.
NO_INFOMSGS
Suprime todas as mensagens informativas.TABLOCK
Faz com que DBCC CHECKDB obtenha bloqueios em vez de usar um instantâneo do 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 com mais rapidez em um banco de dados sob carga pesada, mas reduz a simultaneidade disponível no banco de dados durante sua execução. Para obter mais informações sobre bloqueios, consulte Modos de bloqueio.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 no 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 é projetada 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.A conclusão de uma execução completa de DBCC CHECKDB pode levar consideravelmente mais tempo do que em 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, o uso da opção PHYSICAL_ONLY pode resultar em um tempo de execução muito mais curto de DBCC CHECKDB em grandes bancos de dados, e é recomendada para uso freqüente em sistemas de produção. Ainda é recomendável executar um DBCC CHECKDB completo periodicamente. A freqüência dessas execuções depende de fatores específicos para negócios e ambientes de produção individuais.
PHYSICAL_ONLY sempre implica em NO_INFOMSGS e não é permitido com nenhuma das opções de reparo.
.gif "Observação")
ObservaçãoA especificação de PHYSICAL_ONLY faz com que DBCC CHECKDB ignore todas as verificações de dados FILESTREAM.
DATA_PURITY
Faz com que o DBCC CHECKDB verifique valores de colunas no banco de dados que não são válidos ou estão fora do intervalo. Por exemplo, o DBCC CHECKDB detecta colunas com valores de data e hora que são maiores ou menores do que o intervalo aceitável para o tipo de dados datetime, ou colunas de tipo de dados decimal ou numérico aproximado com valores de escala ou precisão que não são válidos.Para bancos de dados criados no SQL Server 2005 e posterior, verificações de integridade de valor de coluna são habilitadas por padrão e não requerem a opção DATA_PURITY. Para bancos de dados atualizados de versões anteriores do SQL Server, verificações de valores de colunas 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 obter mais informações sobre como o CHECKDB pode ser afetado com a atualização de banco de dados de versões anteriores do SQL Server, consulte a seção Comentários, posteriormente neste tópico.
Se PHYSICAL_ONLY estiver especificado, não serão executadas verificações de integridade de colunas.
Erros de validação relatados por essa opção não podem ser corrigidos usando opções de reparo de DBCC. Para obter informações sobre como corrigir esses erros manualmente, consulte o artigo 923247 da Base de Dados de Conhecimento: Troubleshooting DBCC error 2570 in SQL Server 2005.
Comentários
Em versões anteriores do SQL Server, os valores de contagem de linhas por tabela e por índice e de contagens de páginas podem se tornar incorretos. Em determinadas circunstâncias, um ou mais desses valores podem até se tornar negativos. No SQL Server 2005 e em versões posteriores, esses valores são sempre mantidos da forma correta. Portanto, bancos de dados criados no SQL Server 2005 e versões posteriores nunca devem conter contagens incorretas; entretanto, bancos de dados atualizados para o SQL Server 2005 e posterior podem. Isso não é um dano de nenhum dado armazenado no banco de dados. O DBCC CHECKDB foi aprimorado para detectar quando qualquer uma dessas contagens se torna negativa. Quando contagens negativas são detectadas, a saída do DBCC CHECKDB contém um aviso e uma recomendação para executar DBCC UPDATEUSAGE para corrigir o problema.
O DBCC CHECKDB não examina índices desabilitados. Para obter mais informações sobre índices desabilitados, consulte Desabilitando índices.
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. Se não houver uma serialização consistente de tipos definidos pelo usuário ordenados por byte, o erro 2537 ocorrerá quando DBCC CHECKDB for executado. Para obter mais informações, consulte Requisitos do tipo definido pelo usuário.
Como o banco de dados Recursos pode ser modificado apenas em modo de usuário único, o comando DBCC CHECKDB não pode ser executado nele diretamente. No entanto, quando DBCC CHECKDB é executado no banco de dados mestre, um segundo CHECKDB também é executado internamente no banco de dados Resource. 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.
Em versões do SQL Server 2005 anteriores ao SP2, a execução de DBCC CHECKDB limpa o cache do plano para a instância do SQL Server. 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. No SP2 e posterior, a execução de DBCC CHECKDB não limpa o cache do plano.
Executando verificações de consistência lógica em índices
A verificação de consistência lógica em índices varia de acordo com o nível de compatibilidade do banco de dados, da seguinte maneira:
Se o nível de compatibilidade for 100 (SQL Server 2008) ou superior:
A menos que NOINDEX esteja especificado, DBCC CHECKDB executará verificações de consistência física e lógica em uma única tabela e em todos os í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 estiver especificado, verificações lógicas serão executadas em uma exibição indexada, em índices XML e em í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 afetar bastante o desempenho e não é possível controlar seu andamento. 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 executará verificações de consistência para verificar se as entradas do índice atendem ao predicado do filtro.
Se o nível de compatibilidade for 90 ou inferior, a menos que NOINDEX esteja 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 índices XML e não clusterizados. Não há suporte para índices espaciais.
Para obter informações sobre o nível de compatibilidade de um banco de dados
Instantâneo do banco de dados interno
DBCC CHECKDB usa um instantâneo do banco de dados interno para fornecer a consistência transacional necessária para executar essas verificações. Isso evita bloqueio e problemas de simultaneidade quando esses comandos são executados. Para obter mais informações, consulte Compreendendo tamanhos de arquivo esparso em instantâneos do banco de dados e a seção Uso de instantâneo no banco de dados interno DBCC em DBCC (Transact-SQL). Se um instantâneo não puder ser criado, ou se a opção TABLOCK estiver especificada, DBCC CHECKDB irá adquirir 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 compartilhados são necessários para executar as verificações de tabela.
O DBCC CHECKDB falhará quando executado no master se um instantâneo do banco de dados interno não puder ser criado.
A execução de DBCC CHECKDB no tempdb não executa verificações de alocação nem de catálogo e deve adquirir bloqueios de tabela compartilhada para executar verificações de tabela. Isso porque, por razões de desempenho, instantâneos de banco de dados não estão disponíveis no tempdb. Isso significa que a consistência transacional exigida não pode ser obtida.
Verificando e reparando dados FILESTREAM
Quando FILESTREAM está habilitado para um banco de dados e 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, DBCC verifica a consistência em nível de vinculação 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 existe um mapeamento de um para um entre diretórios do sistema de arquivos e arquivos e linhas da tabela, colunas e valores da coluna. DBCC CHECKDB poderá reparar dano se você especificar a opção REPAIR_ALLOW_DATA_LOSS. Para reparar dano de FILESTREAM, DBCC excluirá todas as linhas da tabela que não têm dados do sistema de arquivos e excluirá todos os diretórios e arquivos que não mapeiam para uma linha de tabela, coluna ou valor de coluna.
Práticas recomendadas
É recomendável usar a opção PHYSICAL_ONLY para uso freqüente em sistemas de produção. O uso de PHYSICAL_ONLY pode reduzir significativamente o tempo de execução do DBCC CHECKDB em bancos de dados grandes. Também é recomendável executar DBCC CHECKDB periodicamente sem opções. A freqüência dessas execuções depende das execuções de negócios individuais e de seus ambientes de produção.
Verificando 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 DBCC, use sp_configure. Para obter mais informações, consulte Opção max degree of parallelism. A verificação paralela pode ser desabilitada usando o sinalizador de rastreamento 2528. Para obter mais informações, consulte Sinalizadores de rastreamento (Transact-SQL).
Compreendendo mensagens de erro DBCC
Depois que o comando DBCC CHECKDB é concluído, 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 erro número 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 do 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. |
Relatório de erros
Um arquivo de despejo (SQLDUMPnnnn.txt) é criado no diretório LOG do SQL Server sempre que DBCC CHECKDB detecta um erro de dano. Quando os recursos de coleta de dados Uso de Recursos e Relatório de Erros são habilitados para a instância do SQL Server, o arquivo é automaticamente encaminhado à 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 saídas de diagnóstico adicionais. O acesso é limitado à conta de serviço do SQL Server e aos membros da função sysadmin. Por padrão, a função sysadmin contém todos os membros do grupo BUILTIN\Administradores do Windows e do grupo de administradores locais. O comando DBCC não falhará se o processo de coleta de dados falhar.
Resolvendo erros
Se qualquer erro for relatado pelo DBCC CHECKDB, é recomendável restaurar o banco de dados do backup em vez de executar REPAIR 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, a correção de erros usando a opção REPAIR_ALLOW_DATA_LOSS pode exigir que algumas páginas e, portanto, alguns dados, sejam excluídos.
Em determinadas circunstâncias, podem ser inseridos valores no banco de dados que são inválidos ou estão fora do intervalo baseado no tipo de dados da coluna. No SQL Server 2000, o DBCC CHECKDB não executa verificações de intervalo ou de integridade nesses valores de coluna. No entanto, no SQL Server 2005 e versões posteriores, o DBCC CHECKDB pode detectar valores de coluna inválidos para todos os tipos de dados de colunas. Portanto, a execução de 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 preexistentes de valores de colunas. Como o SQL Server não pode reparar estes erros automaticamente, o valor da coluna deve ser atualizado manualmente. Se o CHECKDB detectar esse tipo de erro, ele retornará um aviso, o erro número 2570 e informações para identificar a linha afetada e corrigir o erro manualmente.
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.
Resolvendo erros no modo de emergência do banco de dados
Quando um banco de dados foi configurado como modo de emergência com a instrução ALTER DATABASE, o DBCC CHECKDB poderá executar alguns reparos especiais no banco de dados se a opção REPAIR_ALLOW_DATA_LOSS estiver 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 um último recurso e somente quando não for possível restaurar o banco de dados de um backup. Quando o banco de dados está definido no modo de emergência, o banco dedados é marcado como READ_ONLY, o log é desabilitado e o acesso é limitado aos membros da função de servidor fixa sysadmin.
| Observação |
|---|
Não é possível executar o comando DBCC CHECKDB em 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 com a cláusula REPAIR_ALLOW_DATA_LOSS é executada, as seguintes ações são executadas:
O DBCC CHECKDB usa páginas que foram marcadas como inacessíveis devido a erros de E/S ou de 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.
O DBCC CHECKDB tenta recuperar o banco de dados usando técnicas normais de recuperação baseadas em log.
Se, devido a danos no log de transações, a recuperação do banco de dados não tiver êxito, o log de transações será reconstruído. A reconstrução do log de transações pode resultar na perda de consistência transacional.
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 poderá conter uma ou mais inconsistências transacionais. É recomendável executar 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.
Executando 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 bancos de dados de 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. Ações executadas pelo processo CHECKDB para reparar dados de 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 disparados. 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 sejam 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 converterá isso em uma instrução DELETE. Portanto a alteração não será replicada.
Tabelas de metadados de replicação. 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.
Se você precisar 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:
Feche o sistema para novas sessões: 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, consulte Como confirmar uma topologia de replicação (Programação Transact-SQL de replicação).
Execute DBCC CHECKDB.
Se o relatório do DBCC CHECKDB incluir reparos de qualquer tabela no banco de dados de distribuição ou de qualquer tabela 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 Removendo a replicação.
Se o relatório do DBCC CHECKDB incluir reparos de qualquer tabela replicada, execute validação de dados para determinar se existem diferenças entre os dados do banco de dados de publicação e de assinatura. Para obter mais informações, consulte Os dados do Publicador e do Assinante não correspondem.
Conjuntos de resultados
O DBCC CHECKDB retorna o conjunto de resultados a seguir. Os valores poderão variar, exceto quando as opções ESTIMATEONLY, PHYSICAL_ONLY ou NO_INFOMSGS estiverem 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.
O DBCC CHECKDB retorna o conjunto de resultados (mensagem) a seguir quando NO_INFOMSGS está especificado:
The command(s) completed successfully.
O DBCC CHECKDB retorna o conjunto de resultados a seguir quando PHYSICAL_ONLY está 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.
O DBCC CHECKDB retorna o conjunto de resultados a seguir quando ESTIMATEONLY está 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 a associação na função de servidor fixa sysadmin ou na função de banco de dados fixa db_owner.
Exemplos
A. Verificando os bancos de dados atual e o AdventureWorks
O exemplo a seguir executa DBCC CHECKDB para os bancos de dados atual e o AdventureWorks.
-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks, NOINDEX);
GO
B. Verificando 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
Histórico de alterações
Conteúdo atualizado |
|---|
Na definição de PHYSICAL_ONLY, removida a "estrutura física de árvores B" da lista de itens verificados quando essa cláusula for especificada. |
Na definição de ALL_ERRORMSGS, uma nova funcionalidade é descrita no SQL Server 2008 SP1. |