DBCC CHECKDB (Transact-SQL)

• 12/14/2017
• 22 minutos para ler
• • p
  • M
  • m
  • M
  • P
  • +3

Candidata-se a: ServidorSQL (todas as versões suportadas) Base de dados SQL de Azure

Verifica a integridade lógica e física de todos os objectos da base de dados especificada, executando as seguintes operações:

• Executar o DBCC CHECKALLOC na base de dados.
• Executar o DBCC CHECKTABLE em cada tabela e visualização na base de dados.
• Executar o DBCC CHECKCATALOG na base de dados.
• Validar o conteúdo de cada visualização indexada na base de dados.
• Valida a consistência em nível de linha entre metadados de tabelas e diretórios e arquivos do sistema de arquivos ao armazenar dados varbinários(max) no sistema de arquivos usando FILESTREAM.
• Valida os dados do Corretor de Serviços 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 informações mais detalhadas sobre as verificações que estes comandos realizam, veja as descrições destes comandos.

Transact-SQL Syntax Conventions

Syntax

DBCC CHECKDB ) ] } ] ] 

Argumentos

nome_da_base de dados | 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 for especificado 0, é utilizada a base de dados actual. Os nomes da base de dados devem estar de acordo com as regras para identificadores.

NOINDEX
Especifica que não devem ser realizadas verificações intensivas de índices não incluídos para tabelas de usuários. Isto diminui o tempo total de execução. NOINDEX não afeta as tabelas do sistema porque as verificações de integridade são sempre executadas em índices de tabelas do sistema.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Especifica que o DBCC CHECKDB repara os erros encontrados. Use as opções REPAIR apenas como último recurso. A base de dados especificada deve estar em modo de usuário único para usar uma das seguintes opções de reparo.

REPAIR_ALLOW_DATA_LOSS
Testes para reparar todos os erros reportados. Estas reparações podem causar alguma perda de dados.

REPAIR_FAST
Mantém a sintaxe para compatibilidade retroativa apenas. Nenhuma ação de reparo é realizada.

REPAIR_REBUILD
Realiza reparos que não têm nenhuma possibilidade de perda de dados. Isto pode incluir reparos rápidos, tais como reparos de linhas ausentes em índices não incluídos, e reparos mais demorados, como a reconstrução de um índice.
Este argumento não repara erros envolvendo dados do FILESTREAM.

ALL_ERRORMSGS
Exibe todos os erros reportados 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 para aquelas mensagens geradas a partir do banco de dados tempdb.

EXTENDED_LOGICAL_CHECKS
Se o nível de compatibilidade for 100 ( SQL Server 2008) ou superior, executa verificações de consistência lógica em uma visualização indexada, índices XML e índices espaciais, quando presentes.
Para mais informações, veja Executando Verificações de Consistência Lógica em Índices, na seção Observações, mais adiante neste tópico.

NO_INFOMSGS
Suprime todas as mensagens informativas.

TABLOCK
Faz com que o DBCC CHECKDB obtenha bloqueios ao invés de usar um snapshot interno da base de dados. Isto inclui um bloqueio exclusivo (X) a curto prazo na base de dados. O TABLOCK fará com que o DBCC CHECKDB execute mais rapidamente em um banco de dados sob carga pesada, mas diminui a concorrência disponível no banco de dados enquanto o DBCC CHECKDB estiver em execução.

ESTIMATEONLY
Exibe a quantidade estimada de espaço tempdb necessário para executar o 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 da integridade da estrutura física da página e dos cabeçalhos dos registros e a consistência da alocação do banco de dados. Esta verificação é projetada para fornecer uma pequena verificação aérea da consistência física do banco de dados, mas também pode detectar páginas rasgadas, falhas de checksum e falhas comuns de hardware que podem comprometer os dados de um usuário.
Uma execução completa do DBCC CHECKDB pode levar consideravelmente mais tempo para ser concluída do que as versões anteriores. Este comportamento ocorre porque:

• As verificações lógicas são mais abrangentes.
• algumas das estruturas subjacentes a serem verificadas são mais complexas.
• Muitas novas verificações foram introduzidas para incluir as novas funcionalidades.
  Por isso, usar a opção PHYSICAL_ONLY pode causar um tempo de execução muito menor para o DBCC CHECKDB em grandes bases de dados e é recomendado para uso frequente em sistemas de produção. Nós ainda recomendamos que uma execução completa do DBCC CHECKDB seja realizada periodicamente. A frequência destas execuções depende de fatores específicos de negócios individuais e ambientes de produção.
  Este argumento sempre implica NO_INFOMSGS e não é permitido com qualquer uma das opções de reparo.

DATA_PURITY
Faz com que o DBCC CHECKDB verifique na base de dados os valores da coluna que não são válidos ou que estão fora do intervalo. Por exemplo, o DBCC CHECKDB detecta colunas com valores de data e hora que são maiores ou menores que o intervalo aceitável para o tipo de dados de data e hora; ou colunas de tipo de dados decimais ou aproximados-numéricos com valores de escala ou precisão que não são válidos.
Verificações de integridade do valor da coluna são ativadas por padrão e não requerem a opção DATA_PURITY. Para bancos de dados atualizados de versões anteriores do SQL Server, as verificações do valor da coluna não são ativadas por padrão até que o DBCC CHECKDB COM DATA_PURITY tenha sido executado sem erros no banco de dados. Depois disso, o DBCC CHECKDB verifica a integridade do valor da coluna, por padrão. Para mais informações sobre como o CHECKDB pode ser afetado pela atualização do banco de dados de versões anteriores do SQL Server, veja a seção Observações mais adiante neste tópico.

Erros de validação relatados por esta opção não podem ser corrigidos usando as opções de reparo do DBCC. Para informações sobre como corrigir manualmente esses erros, veja o artigo 923247 da Base de Conhecimento: Troubleshooting DBCC error 2570 no SQL Server 2005 e versões posteriores.

MAXDOP
Applies to: SQL Server ( SQL Server 2014 (12.x) SP2 e posteriores).

Overte o grau máximo de configuração de paralelismo da opção sp_configure para a instrução. O MAXDOP pode exceder o valor configurado com sp_configure. Se o MAXDOP exceder o valor configurado com o Resource Governor, o Mecanismo de Banco de Dados do SQL Server usa o valor do Resource Governor MAXDOP, descrito em ALTER WORKLOAD GROUP. Todas as regras semânticas usadas com o grau máximo de paralelismo de configuração são aplicáveis quando você usa a dica de consulta MAXDOP. Para mais informações, veja Configurar o grau máximo de paralelismo Opção de Configuração do Servidor.

Remarks

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

Se um tipo definido pelo usuário estiver marcado como sendo byte ordenado, 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 com ordem de byte causa erro 2537 quando o DBCC CHECKDB é executado. Para obter mais informações, consulte User-Defined Type Requirements.

Porque o banco de dados de recursos é modificável apenas no modo usuário único, o comando DBCC CHECKDB não pode ser executado diretamente nele. Entretanto, quando o DBCC CHECKDB é executado contra o banco de dados mestre, um segundo CHECKDB também é executado internamente no banco de dados de recursos. Isto significa que o DBCC CHECKDB pode retornar resultados extras. O comando retorna resultados extras quando nenhuma opção está definida, ou quando a opção PHYSICAL_ONLY ou ESTIMATEONLY está definida.

Iniciar com o SQL Server 2005 (9.x) SP2, executando o DBCC CHECKDB não limpa mais o cache do plano para a instância do SQL Server. Antes do SQL Server 2005 (9.x) SP2, 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 posterior 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

Verificação de consistência lógica em índices varia de acordo com o nível de compatibilidade do banco de dados, como segue:

• Se o nível de compatibilidade for 100 (SQL Server 2008) ou superior:
• Anterior NOINDEX é especificado, o DBCC CHECKDB executa verificações de consistência física e lógica em uma única tabela e em todos os seus índices não incluídos. Entretanto, em índices XML, índices espaciais e vistas indexadas apenas verificações de consistência física são executadas por padrão.
• Se WITH EXTENDED_LOGICAL_CHECKS for especificado, verificações lógicas são executadas em uma vista 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 sã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 que ele está referenciando. Para encontrar linhas remotas, uma consulta interna é construída para executar uma interseção completa das tabelas interna e do usuário. A execução desta consulta pode ter um efeito muito alto no desempenho, e o 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 à corrupção física, ou se os checksums de nível de página tiverem sido desativados e você suspeitar de corrupção de hardware em nível de coluna.

• Se o índice for um índice filtrado, o DBCC CHECKDB executa verificações de consistência para verificar se as entradas do índice satisfazem o predicado do filtro.
• Se o nível de compatibilidade for 90 ou menos, a menos que NOINDEX seja especificado, o DBCC CHECKDB realiza verificações de consistência física e lógica em uma única tabela ou visualização indexada e em todos os seus índices não incluídos e XML. Índices espaciais não são suportados.
• Iniciar com o SQL Server 2016, verificações adicionais em colunas computadorizadas persistentes, colunas UDT, e índices filtrados não serão executados por padrão para evitar as caras avaliações de expressão. Esta alteração reduz muito a duração do CHECKDB em relação a bancos de dados que contenham estes objetos. Entretanto, as verificações de consistência física desses objetos são sempre concluídas. Somente quando a opção EXTENDED_LOGICAL_CHECKS for especificada, as avaliações de expressão serão executadas além das verificações lógicas já apresentadas (visão indexada, índices XML e índices espaciais) como parte da opção EXTENDED_LOGICAL_CHECKS.

Para aprender o nível de compatibilidade de uma base de dados

• Ver ou alterar o nível de compatibilidade de uma base de dados

Snapshot da base de dados interna

DBCC CHECKDB usa um snapshot interno da base de dados para a consistência transacional necessária para realizar estas verificações. Isto evita o bloqueio e problemas de concurrência quando estes comandos são executados. Para mais informações, consulte Ver o tamanho do arquivo esparso de um instantâneo do banco de dados (Transact-SQL) e a seção Utilização de instantâneo do banco de dados interno do DBCC no DBCC (Transact-SQL). Se um instantâneo não puder ser criado, ou se TABLOCK for especificado, o DBCC CHECKDB adquire bloqueios para obter a consistência necessária. Neste caso, um bloqueio exclusivo de banco de dados é 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 falha quando executado contra master se um snapshot de banco de dados interno não pode ser criado.Executar o DBCC CHECKDB contra tempdb não executa nenhuma alocação ou verificação de catálogo e deve adquirir bloqueios de tabela compartilhada para executar verificações de tabela. Isto porque, por razões de performance, instantâneos do banco de dados não estão disponíveis no tempdb. Isto significa que a consistência transaccional necessária não pode ser obtida. No Microsoft SQL Server 2012 ou numa versão anterior do SQL Server, pode encontrar mensagens de erro quando executa o comando DBCC CHECKDB para um banco de dados que tem os seus ficheiros localizados num volume formatado em ReFS. Para mais informações, veja o artigo 2974455 da Base de Conhecimento: Comportamento do DBCC CHECKDB quando o banco de dados do SQL Server está localizado em um volume ReFS.

Checking and Repairing FILESTREAM Data

Quando o FILESTREAM está habilitado para um banco de dados e uma tabela, você pode opcionalmente armazenar grandes objetos binários (BLOBs) varbinários(max) no sistema de arquivos. Por exemplo, se uma tabela contém uma coluna varbinary(max) que usa o atributo FILESTREAM, o DBCC CHECKDB verifica se existe um mapeamento um-para-um entre os diretórios e arquivos do sistema de arquivos e as linhas, colunas e valores das colunas da tabela. O DBCC CHECKDB pode reparar a corrupção se você especificar a opção REPAIR_ALLOW_DATA_LOSS. Para reparar a corrupção do FILESTREAM, o DBCC irá apagar quaisquer linhas de tabela que estejam faltando dados do sistema de arquivos.

Best Practices

Recomendamos que você use a opção PHYSICAL_ONLY para uso freqüente em sistemas de produção. Usando PHYSICAL_ONLY pode reduzir muito o tempo de execução do DBCC CHECKDB em grandes bancos de dados. Nós também recomendamos que você execute periodicamente o DBCC CHECKDB sem opções. A frequência com que você deve executar essas execuções depende de negócios individuais e seus ambientes de produção.

Checking Objects in Parallel

Por padrão, o DBCC CHECKDB executa a verificação paralela de objetos. O grau de paralelismo é automaticamente determinado pelo processador da consulta. O grau 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 mais informações, consulte Configurar o grau máximo de paralelismo Opção de Configuração do Servidor. A verificação paralela pode ser desativada usando o trace flag 2528. Para mais informações, veja Trace Flags (Transact-SQL).

Understanding DBCC Error Messages

Após o comando DBCC CHECKDB terminar, uma mensagem é escrita para o log de erros do SQL Server. Se o comando DBCC for executado com sucesso, a mensagem indica o sucesso e a quantidade de tempo que o comando foi executado. Se o comando DBCC parar antes de completar a verificação por causa de um erro, a mensagem indica que o comando foi terminado, um valor de estado e a quantidade de tempo que o comando foi executado. A tabela seguinte lista e descreve os valores de estado que podem ser incluídos na mensagem.

State	Description
0	Error number 8930 was raised. Isto indica uma corrupção nos metadados que terminou o comando DBCC.
>1	>Error número 8967 foi levantado. Houve um erro interno no DBCC.
2	Ocorreu uma falha durante o reparo da base de dados em modo de emergência.
>3	Isto indica uma corrupção nos metadados que terminou o comando DBCC.
> 4	Foi detectada uma afirmação ou violação de acesso.
>5	Ocorreu um erro desconhecido que terminou o comando DBCC.

Error Reporting

Um arquivo dump (SQLDUMP*nnnn*.txt) é criado no diretório LOG do SQL Server sempre que DBCC CHECKDB detecta um erro de corrupção. Quando os recursos de coleta de dados de Uso de Recursos e Relatórios de Erro são habilitados para a instância do SQL Server, o arquivo é automaticamente encaminhado para a Microsoft. Os dados coletados são usados para melhorar a funcionalidade do SQL Server. O arquivo dump 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 o grupo do administrador local. O comando DBCC não falha se o processo de coleta de dados falhar.

Resolvendo Erros

Se algum erro for reportado pelo DBCC CHECKDB, recomendamos restaurar o banco de dados a partir do backup do banco de dados em vez de executar o REPAIR com uma das opções REPAIR. Se não existir uma cópia de segurança, a execução do reparo corrige os erros reportados. A opção de reparação a usar é especificada no final da lista de erros reportados. No entanto, corrigir os erros usando a opção REPAIR_ALLOW_DATA_LOSS pode requerer a exclusão de algumas páginas e, portanto, alguns dados.

Em algumas circunstâncias, valores podem ser inseridos no banco de dados que não são válidos ou fora da faixa de variação com base no tipo de dados da coluna. O DBCC CHECKDB pode detectar valores de coluna que não são válidos para todos os tipos de dados da coluna. Portanto, executar o DBCC CHECKDB com a opção DATA_PURITY em bancos de dados que foram atualizados a partir de versões anteriores do SQL Server pode revelar erros de valores de colunas pré-existentes. Como o SQL Server não pode reparar esses erros automaticamente, o valor da coluna deve ser atualizado manualmente. Se CHECKDB detectar tal erro, CHECKDB retorna 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 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 o backup da base de dados.

Resolução de erros no modo de emergência da base de dados

Quando uma base de dados tiver sido definida para o modo de emergência usando a instrução ALTER DATABASE, o DBCC CHECKDB pode executar alguns reparos especiais na base de dados se a opção REPAIR_ALLOW_DATA_LOSS estiver especificada. Esses reparos podem permitir que bancos de dados normalmente irrecuperáveis sejam trazidos de volta on-line em um estado fisicamente consistente. Estes 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 a base de dados é definida para o modo de emergência, a base de dados é marcada como READ_ONLY, o registo é desactivado e o acesso é limitado aos membros da função do servidor fixo sysadmin.

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

• DBCC CHECKDB usa páginas que foram marcadas como inacessíveis por causa de erros de E/S ou checksum, como se os erros não tivessem ocorrido. Fazendo 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, devido à corrupção do log de transações, a recuperação do banco de dados não for bem sucedida, o log de transações é reconstruído. A reconstrução do log de transação 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. Entretanto, a base de dados pode conter uma ou mais inconsistências transacionais. Se o comando DBCC CHECKDB CHECKCONSTRAINTS falhar, o banco de dados não poderá ser reparado.

Executar o DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS em bancos de dados replicados

Executar o comando DBCC CHECKDB com a opção REPAIR_ALLOW_DATA_LOSS pode afetar os bancos de dados de usuários (bancos de dados de publicação e de assinaturas) e o banco de dados de distribuição usado pela replicação. As bases de dados de publicação e subscrição incluem tabelas publicadas e tabelas de metadados de replicação. Esteja ciente dos seguintes problemas potenciais nestas bases de dados:

• Tabelas publicadas. Ações executadas pelo processo CHECKDB para reparar dados corruptos de usuários podem não ser replicadas:
• Fundir replicação usa triggers para rastrear 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.
• Replicação transacional usa o log de transações para rastrear as alterações nas tabelas publicadas. O Log Reader Agent então move essas alterações para o banco de dados de distribuição. Algumas reparações do DBCC, embora logadas, não podem ser replicadas pelo Log Reader Agent. Por exemplo, se uma página de dados for desalocada pelo processo CHECKDB, o Log Reader Agent não traduz isto para uma instrução DELETE; portanto, a alteração não é replicada.
• Replicação de tabelas de metadados. As ações executadas pelo processo CHECKDB para reparar tabelas de metadados de replicação corrompidas requerem a remoção e 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:

1. Quiesce o sistema: Parar a atividade no banco de dados e em todos os outros bancos de dados na topologia de replicação, e depois tentar sincronizar todos os nós. Para mais informações, veja Quiesce a Replication Topology (Replication Transact-SQL Programming).
2. Execute DBCC CHECKDB.
3. Se o relatório DBCC CHECKDB incluir reparos para qualquer tabela no banco de dados de distribuição ou qualquer tabela de metadados de replicação em um banco de dados de usuário, remova e reconfigure a replicação. Para mais informações, consulte Desativar publicação e distribuição.
4. Se o relatório DBCC CHECKDB incluir reparos para quaisquer tabelas replicadas, execute a validação dos dados para determinar se existem diferenças entre os dados no banco de dados de publicação e de assinatura.

Sets de resultados

DBCC CHECKDB retorna o seguinte conjunto de resultados. 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 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 servidor fixo sysadmin ou à função base de dados fixa db_owner.

Exemplos

A. Verificando tanto a base de dados actual como outra base de dados

O exemplo seguinte executa DBCC CHECKDB para a base de dados actual e para a base de dados AdventureWorks2012.

-- Check the current database. DBCC CHECKDB; GO -- Check the AdventureWorks2012 database without nonclustered indexes. DBCC CHECKDB (AdventureWorks2012, 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 

Veja Também

DBCC (Transact-SQL)
Veja o Tamanho do Arquivo Espaçado de um Instantâneo de Banco de Dados (Transact-SQL)
sp_helpdb (Transact-SQL)
Tabelas do Sistema (Transact-SQL)