Como resolver erros de consistência da base de dados reportados DBCC CHECKB

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática… erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 2015748
Sintomas

Quando são executados o DBCC CHECKDB (ou outros comandos semelhantes como CHECKTABLE), é escrita uma mensagem semelhante ao seguinte a ERRORLOG de servidor de SQL:

03-2010-31 22:07:06.34 spid53 DBCC CHECKDB (mydb) executado por MYDOMAIN\theuser encontrou 15 erros e reparado 0 erros. Tempo decorrido: 0 horas, 0 minutos e 0 segundos.Instantâneo da base de dados interna tem de dividir ponto LSN = 00000026:0000089 d: 0001 e primeiro LSN = 00000026:0000089 c: 0001.Esta é apenas uma mensagem informativa. Não é necessária nenhuma acção do utilizador.

Mostra esta mensagem foram encontrados erros de consistência de base de dados quantos e quantas foram reparadas (se uma opção de reparação foi utilizada com o comando). Esta mensagem também é escrita para o registo de eventos de aplicação do Windows como uma mensagem de nível de informação com EventID = 8957 (mesmo que os erros são comunicados esta mensagem é uma mensagem de nível de informação).

As informações na mensagem de "base de dados interna do instantâneo...", começando só aparece se DBCC CHECKDB foi executadaonline, que é se a base de dados não está no modo SINGLE_USER. Isto acontece porque o para um CHECKDB de DBCC online, um instantâneo de base de dados interna é utilizado para apresentar um conjunto consistente de dados a verificar.

Este artigo será explica como resolver problemas relacionados com cada erro específico reportado DBCC CHECKDB mas em vez disso cuja abordagem geral se forem comunicados erros. Qualquer referência a CHECKDB neste artigo também se aplica a DBCC CHECKTABLE e CHECKFILEGROUP salvo indicação especificamente.

Causa

DBCC CHECKDB verifica a consistência física e lógica de páginas de base de dados, linhas, páginas de atribuição, relações de índice, integridade referencial de tabela de resolução e outros controlos de estrutura. Se qualquer uma destas verificações falharem (consoante as opções que seleccionou), serão comunicados erros como parte do comando.

A causa destes problemas pode variar de danos no sistema de ficheiros, subjacentes problemas de hardware do sistema, o controlador emite, páginas danificadas na memória ou problemas com o motor do servidor SQL. Leia a secção de resolução para obter mais informações sobre como localizar a causa dos erros comunicados.

Resolução

A solução em primeiro lugar, melhor se DBCC CHECKDB comunicar erros de consistência deve restaurar a partir de uma cópia de segurança correcta. No entanto, se for possível restaurar a partir de uma cópia de segurança, em seguida, CHECKDB fornece uma funcionalidade para reparar erros. Se a problemas de nível de sistema, tal como o sistema de ficheiros ou hardware poderão estar a causar estes problemas, recomenda-se que corrigir estes primeiro antes de restaurar ou executar a reparação.

Quando executar DBCC CHECKDB uma recomendação é fornecida para indicar que a opção de reparação mínimo necessário para reparar todos os erros. Estas mensagens poderão ter um aspecto semelhante ao seguinte:

CHECKDB encontrar erros de atribuição de 0 e 15 erros de consistência na base de dados 'mydb'.
repair_allow_data_loss é o nível de reparação mínimas para os erros encontrados pelo DBCC CHECKDB (mydb

A recomendação de reparação é o nível mínimo de reparação para tentar resolver todos os erros de CHECKDB. Isto significa que esta opção de reparação efectivamente irá corrigir todos os erros. Além disso, nem todos os erros comunicados podem exigir este nível de reparação para resolver o erro. Isto significa que nem todos os erros comunicados pelo CHECKDB quando repair_allow_data_loss é recomendado irão resultar na perda de dados. Reparação tem de ser executada para determinar se a resolução para um erro irá resultar na perda de dados. Uma técnica para ajudar a limitar o que irá ser o nível de reparação para cada tabela é utilizar DBCC CHECKTABLE para qualquer tabela comunicar um erro. Isto vai mostrar que o nível mínimo de reparação para uma determinada tabela.

Para identificar a causa do porque ocorreram erros de consistência da base de dados, considere estes métodos:

  • Verifique no registo de eventos de sistema do Windows para qualquer disco, controlador ou nível de sistema relacionados com erros
  • Verificar a integridade do sistema de ficheiros com o comando chkdsk.
  • Execute quaisquer diagnósticos fornecidos pelos fabricantes de hardware para o computador e/ou o sistema de disco.
  • Trabalhar com o fornecedor de hardware ou o fabricante do dispositivo para garantir:
    • Os dispositivos de hardware e a configuração confirma os requisitos de e/s do SQL Server
    • Os controladores de dispositivo e outros componentes de software de suporte de todos os dispositivos no caminho de e/s são actualizados
  • Considere utilizar um utilitário como SQLIOSim na mesma unidade como as bases de dados que comunicados os erros de consistência. SQLIOSim é uma ferramenta independente do servidor SQL Engine para testar a integridade de e/s para o sistema de disco. Tenha em atenção que o SQLIOSim fornecido com o SQL Server 2008 e faz não reuiqre uma transferência separada.
  • Verificar a existência de quaisquer outros erros registados pelo SQL Server, por exemplo, violações de acesso. Estes tipos de problemas podem conduzir a corrupção da base de dados, certifique-se resolver estes erros pela primeira vez.
  • Certifique-se de que as bases de dados estiverem a utilizar a opção PAGE_VERIFY soma de verificação. Se estiverem a ser comunicados erros de soma de verificação, estas são indicadores que a consistência ocorreram erros depois de ter escrito o SQL Server páginas no disco para que o sistema de disco deve ser verificado exaustivamente. Aprendera resolver o erro 824 no SQL Server para obter mais informações sobre erros de soma de verificação.
  • Procure erros de Msg 832 no ERRORLOG. Estes são indicadores que páginas Maio estar danificado enquanto estiverem na cache antes de escritas no disco. Para mais informações, consultecomo resolver problemas relacionados com o erro 832 no SQL Server.
  • Tente restaurar uma cópia de segurança da base de dados que conhece ou seja "Limpar" (sem erros de CHECKDB) e a hora quando foi encontrado o erro de calibração de cópias de segurança do registo de transacções que conhece. Se pode "reprodução" este problema se restaurar uma cópia de segurança da base de dados "limpa" e a transacção inicia, em seguida, contacte o suporte técnico da Microsoft para obter assistência.
  • Erros de pureza de dados podem ser um problema com a aplicação a inserir ou actualizar dados inválidos em tabelas do SQL Server. Para mais informações sobre resolução de problemas de pureza de dados, erros consulte o seguinte artigo:resolução de problemas 2570 de erro de DBCC do SQL server 2005
Mais Informação

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

Se os erros encontrados pelo CHECKDB, mensagens adicionais, como as seguintes são reportadas no ERRORLOG para efeitos de relato de erros:

03-2010-31 dbghelp '. 22:07:06.34 spid53 Using dll' versão '4.0.5'
03-2010-31 22:07:06.35 spid53 * * copiar thread - spid = 0, CE = 0x00000000855F5EB0
03-2010-31 22:07:06.35 spid53 * * * pilha de informação a ser enviada para C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\LOG\SQLDump0012.txt
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
03-2010-31 22:07:06.35 spid53 *
03-2010-31 22:07:06.35 spid53 * começar a copiar de pilha:
03-2010-31 22:07:06.35 spid53 * 03/31/10, 22:07:06 spid 53
03-2010-31 22:07:06.35 spid53 *
03-2010-31 22:07:06.35 spid53 * Corrupção da base de dados DBCC
03-2010-31 22:07:06.35 spid53 *
03-2010-31 22:07:06.35 spid53 * bytes de entrada da memória intermédia 84 -
03-2010-31 22:07:06.35 spid53 * dbcc checkdb(mydb)
03-2010-31 22:07:06.35 spid53 *
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
2010-03-31 22:07:06.35 spid53      * -------------------------------------------------------------------------------
03-2010-31 22:07:06.35 spid53 * curtas despejo simplificado da pilha
03-2010-31 22:07:06.38 spid53 assinatura da pilha para a informação de estado é 0x00000000000001E8
processo de informação externas 2010-03-31 22:07:07.42 spid53 devolver 0x20002001 do código.
As informações de erro foi submetidas o relatório de erros do Watson.

Os ficheiros utilizados para relato de erros incluem um ficheiro do SQLDump < nnn >. txt. Este ficheiro pode ser útil para fins históricos, porque contém uma lista dos erros encontrados de CHECKDB num formato XML.

Para saber quando a última vez DBCC CHECKDB foi executada sem erros detectados para uma base de dados (o último conhecido limpo CHECKDB), verifique o ERRORLOG de servidor de SQL para uma mensagem como as seguintes opções para a base de dados ou sistema (esta mensagem destina-se como uma mensagem de nível de informação no registo de eventos de aplicações de Windows com EventID = 17573):

2010-04-01 10:13:59.80 spid7s CHECKDB para a base de dados 'principal' foram concluídos sem erros no 22:11:11.417 03-2010-31 (hora local). Esta é uma mensagem informativa apenas; é necessária nenhuma acção do utilizador

Nota Este é um artigo de “PUBLICAÇÃO RÁPIDA” criado directamente a partir da organização de suporte da Microsoft. As informações contidas neste artigo são fornecidas “tal como estão” em resposta a problemas recentes. Devido à urgência em disponibilizar este artigo, os materiais poderão incluir erros tipográficos e ser revistos em qualquer altura sem aviso prévio. Consulte os Termos de Utilização para outras considerações.

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 2015748 - Última Revisão: 05/07/2014 09:01:00 - Revisão: 1.0

Microsoft SQL Server 2005 Developer Edition, Microsoft SQL 2005 Server Enterprise, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL 2005 Server Workgroup, 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

  • kbmt KB2015748 KbMtpt
Comentários