Como solucionar problemas de erros de consistência de banco de dados relatados pelo DBCC CHECKB

Traduções deste artigo Traduções deste artigo
ID do artigo: 2015748 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Sintomas

Quando o DBCC CHECKDB (ou outros comandos similares como CHECKTABLE) são executados, uma mensagem semelhante à seguinte é gravada para o log de erros do SQL Server:

2010-03-31 22:07:06.34 spid53 DBCC CHECKDB (mydb) executado pelo MYDOMAIN\theuser 15 erros encontrados e corrigidos 0 erros. Tempo decorrido: 0 horas 0 minutos 0 segundos. o instantâneo de banco de dados interno dividiu LSN de ponto = 00000026:0000089 d: 0001 e primeiro LSN = 00000026:0000089 c: 0001. Esta é apenas uma mensagem informativa. Nenhuma ação é necessária.

Essa mensagem mostra quantos erros de consistência de banco de dados foram encontrados e quantas foram corrigidas (se a opção de reparação foi usada com o comando). Esta mensagem também é gravada para o Log de eventos do aplicativo Windows como uma mensagem de nível de informação com EventID = 8957 (mesmo se erros são relatados esta mensagem é uma mensagem de nível de informações).

As informações na mensagem começando com "internal database snapshot..." é exibida somente se o DBCC CHECKDB foi executado on-line, que é se o banco de dados não está no modo SINGLE_USER. Isso ocorre porque um DBCC CHECKDB on-line, um instantâneo de banco de dados interno é usado para apresentar um conjunto consistente de dados para verificar.

Este artigo não discutirá como solucionar cada erro específico relatado pelo DBCC CHECKDB, mas em vez disso, a abordagem geral se erros são relatados. Qualquer referência a CHECKDB neste artigo também se aplica a DBCC CHECKTABLE e CHECKFILEGROUP, a menos que especificamente declarado.

Causa

DBCC CHECKDB verifica a consistência física e lógica de páginas do banco de dados, linhas, páginas de alocação, relações de índice, integridade referencial de tabela do sitema e outras verificações de estrutura. Se as verificações falharem (dependendo das opções que você escolheu), os erros serão relatados como parte do comando.

A causa desses problemas pode variar de corrupção de sistema de arquivos subjacente problemas de hardware do sistema, problemas de driver, páginas corrompidas na memória ou problemas com o mecanismo do SQL Server. Ler a seção de resolução para obter mais informações sobre como localizar a causa dos erros que são relatados.

Resolução

A primeira solução melhor se DBCC CHECKDB relata erros de consistência é restaurar a partir de um bom backup. No entanto, se você não pode restaurar de um backup, CHECKDB oferece um recurso para reparar os erros. Se problemas de nível de sistema como o hardware ou o sistema de arquivos podem estar causando esses problemas, é recomendável que corrigir esses primeiro antes de restaurar ou executar o reparo.

Quando você executa o DBCC CHECKDB uma recomendação é fornecida para indicar que a opção de reparação mínima que é necessária para corrigir todos os erros. Essas mensagens podem ser algo como o seguinte:

CHECKDB encontrado 0 erros de alocação e 15 erros de consistência no banco de dados 'mydb'.
REPAIR_ALLOW_DATA_LOSS é o nível mínimo de reparo para os erros encontrados pelo DBCC CHECKDB (mydb

A recomendação de reparo é o nível mínimo de reparação para tentar resolver todos os erros de CHECKDB. Isso não significa que essa opção de reparação realmente corrigirá todos os erros. Além disso, nem todos os erros relatados podem exigir este nível de reparo para resolver o erro. Isso significa que nem todos os erros relatados por CHECKDB quando repair_allow_data_loss é recomendável resultará em perda de dados. Utilitário Reparar deve ser executado para determinar se a resolução para o erro resultará em perda de dados. Uma técnica para ajudar a restringir qual será o nível de correção para cada tabela é usar DBCC CHECKTABLE para qualquer tabela relatar um erro. Isso mostrará o nível mínimo de reparo para uma determinada tabela.

Para encontrar a causa de por que ocorreram erros de consistência de banco de dados, considere estes métodos:

  • Verifique o Log de eventos de sistema do Windows para qualquer nível do sistema, o driver ou o disco erros relacionados ao
  • Verificar a integridade do sistema de arquivos com o comando chkdsk.
  • Execute qualquer diagnóstico fornecido pelos fabricantes de hardware para o computador e/ou o sistema de disco.
  • Trabalhar com o seu fornecedor de hardware ou o fabricante do dispositivo para garantir que:
    • Os dispositivos de hardware e a configuração confirma os requisitos de e/s do SQL Server
    • Os drivers de dispositivo e outros componentes de software de suporte de todos os dispositivos no caminho de i/o são atualizados
  • Considere o uso de um utilitário como SQLIOSim na mesma unidade que os bancos de dados que relataram erros de consistência. SQLIOSim é uma ferramenta independente do mecanismo do SQL Server para testar a integridade de i/o para o sistema de disco. Observe que o SQLIOSim é fornecido com o SQL Server 2008 e não não reuiqre um download separado.
  • Verifique se há outros erros relatados pelo SQL Server, como violações de acesso. Esses tipos de problemas podem levar à corrupção de banco de dados então não se esqueça de resolver esses erros pela primeira vez.
  • Certifique-se de que seus bancos de dados estão usando a opção PAGE_VERIFY CHECKSUM. Se erros de soma de verificação estão sendo gerados, são indicadores de que a consistência erros ocorreram depois do SQL Server já escreveu páginas em disco para que o sistema de disco deve ser verificado cuidadosamente. Consulte como solucionar problemas de erro 824 no SQL Server para obter mais informações sobre erros de soma de verificação.
  • Procure erros de Msg 832 o log de erros. Estes são indicadores de páginas pode ser danificado enquanto estiverem no cache antes gravadas no disco. Consulte como solucionar problemas de Msg 832 no SQL Server para obter mais informações.
  • Tente restaurar um backup de banco de dados que você sabe que é "Limpar" (sem erros de CHECKDB) e backups de log de transação, que você sabe se estender a hora em que o erro foi encontrado. Se você pode "Repetir" esse problema ao restaurar um backup de banco de dados "limpa" e a transação registra e entre em contato com o suporte técnico da Microsoft para obter assistência.
  • Erros de pureza de dados podem ser um problema com o aplicativo, inserir e atualizar os dados inválidos em tabelas do SQL Server. Para obter mais informações sobre como solucionar problemas de dados pureza erros consulte o seguinte artigo: solução de problemas de DBCC erro 2570 em server SQL 2005

Mais Informações

Para obter detalhes sobre a sintaxe do DBCC CHECKDB e informações/opções sobre como executar o comando, leia o tópico SQL Server Books Online sobre o comando DBCC CHECKDB.

Se algum erro foi encontrado por CHECKDB, mensagens adicionais como a seguir são relatadas no log de erros para fins de relatório de erros:

2010-03-31 22:07:06.34 spid53 usando 'dbghelp. dll' versão '4.0.5'
2010-03-31 22:07:06.35 spid53 * * despejo thread - spid = 0, EC = 0x00000000855F5EB0
2010-03-31 22:07:06.35 spid53 * * * despejo da pilha está sendo enviada para C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\LOG\SQLDump0012.txt
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53 * iniciar despejo de pilha:
2010-03-31 22:07:06.35 spid53 * 31/10/03 22:07:06 spid 53
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53 * corrupção de banco de dados do DBCC
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53 * bytes 84 do Buffer de entrada -
2010-03-31 22:07:06.35 spid53 * dbcc checkdb(mydb)
2010-03-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
2010-03-31 22:07:06.35 spid53      * -------------------------------------------------------------------------------
2010-03-31 22:07:06.35 spid53 * pequeno despejo de pilha
2010-03-31 22:07:06.38 spid53 assinatura de pilha para o despejo é 0x00000000000001E8
processo de despejo externo 2010-03-31 22:07:07.42 spid53 retornar código 0x20002001.
As informações de erro foi enviadas para o relatório de erros do Watson.

Os arquivos usados para relatório de erros incluem um SQLDump < nnn >. txt. Este arquivo pode ser útil para fins de histórico que contém uma lista dos erros encontrados no CHECKDB em um formato XML.

Para saber quando a última vez que DBCC CHECKDB foi executada sem erros detectados para um banco de dados (o último conhecido limpa CHECKDB), verifique o log de erros do SQL Server para uma mensagem semelhante ao seguinte para o seu banco de dados ou banco de dados de sistema (essa mensagem é gravada como uma mensagem de nível de informações no Log de eventos de aplicativo do Windows com EventID = 17573):

2010-04-01 10:13:59.80 spid7s CHECKDB do banco de dados 'mestre' encerrado sem erros 22:11:11.417 de 2010-03-31 (horário local). Esta é uma mensagem informativa não é necessária nenhuma ação de usuário

Observação: este é um artigo de ?PUBLICAÇÃO RÁPIDA? criado diretamente pela organização de suporte da Microsoft. As informações aqui contidas são fornecidas no presente estado, em resposta a questões emergentes. Como resultado da velocidade de disponibilização, os materiais podem incluir erros tipográficos e poderão ser revisados a qualquer momento, sem aviso prévio. Consulte os Termos de Uso para ver outras informações.

Propriedades

ID do artigo: 2015748 - Última revisão: quarta-feira, 7 de maio de 2014 - Revisão: 1.0
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 R2 Enterprise
  • Microsoft SQL Server 2008 R2 Standard
  • Microsoft SQL Server 2008 R2 Web
  • Microsoft SQL Server 2008 R2 Workgroup
  • Microsoft SQL Server 2012 Developer
  • Microsoft SQL Server 2012 Enterprise
  • Microsoft SQL Server 2012 Express
  • Microsoft SQL Server 2012 Standard
  • Microsoft SQL Server 2012 Web
  • Microsoft SQL Server 2014 Developer
  • Microsoft SQL Server 2014 Enterprise
  • Microsoft SQL Server 2014 Express
  • Microsoft SQL Server 2014 Standard
  • Microsoft SQL Server 2014 Web
Palavras-chave: 
kbmt KB2015748 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.
Clique aqui para ver a versão em Inglês deste artigo: 2015748

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com