Solucionar problemas de erros de consistência de banco de dados relatados pelo DBCC CHECKDB

  • Artigo

Este artigo explica como solucionar problemas de erros relatados pelo DBCC CHECKDB comando.

Versão original do produto: SQL Server
Número de KB original: 2015748

Sintomas

Quando o DBCC CHECKDB (ou outros comandos semelhantes como DBCC CHECKTABLE) é executado, uma mensagem como a seguinte é gravada no log de erros do SQL Server:

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors and repaired 3 errors.
Elapsed time: 0 hours 0 minutes 0 seconds.
Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001.
This is an informational message only. No user action is required.

Esta mensagem mostra quantos erros de consistência de banco de dados foram encontrados e quantos foram reparados, se uma opção de reparo foi usada. Essa mensagem também é escrita no Log de Eventos do Aplicativo Windows como uma mensagem de nível de informação com EventID=8957. Mesmo que erros sejam relatados, essa mensagem é uma mensagem de nível de informação.

As informações na mensagem começando com "instantâneo de banco de dados interno..." só será exibido se DBCC CHECKDB for executado online, no qual o banco de dados não está no SINGLE_USER modo. Isso ocorre porque para um banco de dados online DBCC CHECKDB, um banco de dados interno instantâneo é usado para apresentar um conjunto consistente de dados para marcar.

Este artigo não discute como solucionar problemas de cada erro específico relatado, DBCC CHECKDB mas sim a abordagem geral se os erros forem relatados. Qualquer referência a CHECKDB neste artigo também se aplica a DBCC CHECKTABLE e DBCC CHECKFILEGROUP , a menos que seja indicado.

Motivo

O DBCC CHECKDB comando verifica a consistência física e lógica de páginas de banco de dados, linhas, páginas de alocação, relações de índice, integridade referencial da tabela do sistema e outras verificações de estrutura. Se alguma dessas verificações falhar (dependendo das opções escolhidas), erros serão relatados.

A causa desses problemas pode variar de corrupção do sistema de arquivos, problemas subjacentes do sistema de hardware, problemas de driver, páginas corrompidas na memória ou cache de armazenamento ou problemas com o SQL Server. Para obter informações sobre como identificar a causa raiz de erros relatados, consulte Investigar a causa raiz.

Resolução

  1. Resolva quaisquer problemas relacionados ao hardware subjacentes no sistema antes de continuar restaurando um backup ou reparando o banco de dados. Aplique qualquer driver de dispositivo, firmware, BIOS e atualizações do sistema operacional relevantes para o caminho de E/S. Trabalhe com o administrador do caminho completo de E/S (computador local, drivers de dispositivo, NICs de armazenamento, SAN, armazenamento de back-end e cache) para isolar e resolve quaisquer problemas. Exemplos incluem atualizar drivers de dispositivo e verificar a configuração de todo o caminho de E/S. Para obter mais informações sobre como verificar a causa raiz, consulte Investigar a causa raiz.

  2. Se DBCC CHECKDB relatar erros de consistência permanente, a melhor solução será restaurar dados de um bom backup conhecido. Para obter mais informações, consulte Restauração e Recuperação.

  3. Aplique as últimas SQL Server Atualização Cumulativa ou Service Pack para garantir que você não esteja executando problemas conhecidos. Verifique a documentação da Atualização Cumulativa ou do Service Pack para ver quaisquer problemas conhecidos corrigidos relacionados à corrupção do banco de dados (erros de consistência) e aplique quaisquer correções relevantes. Um local central em que você pode pesquisar todas as correções para uma determinada versão se a correção detalhada listar SQL Server 2022, 2019, 2017.

  4. Se os DBCC CHECKDB erros forem intermitentes, ou seja, se eles aparecerem em uma execução e desaparecerem na próxima, você poderá estar enfrentando problemas de cache de disco (driver de dispositivo ou outro problema de caminho de E/S). Trabalhe com os mantenedores do caminho de E/S para isolar e resolve problemas. Exemplos incluem atualizar drivers de dispositivo, verificar a configuração de todo o caminho de E/S e atualizar firmware e BIOS nos dispositivos e no sistema de caminho de E/S.

  5. Se não for possível restaurar de um backup, CHECKDB terá um recurso para reparar erros que você pode usar. Há dois níveis de reparo:

    • REPAIR_REBUILD – executa reparos que não têm nenhuma possibilidade de perda de dados.
    • REPAIR_ALLOW_DATA_LOSS – executa reparos que têm a possibilidade de perda de dados.

    Para obter mais informações, consulte Documentação do DBCC CHECKDB.

    Você deve ter cuidado ao fazer a opção de reparar com permitir a perda de dados, pois ele pode deixar seu banco de dados em um estado logicamente inconsistente. A DBCC CHECKDB saída faz uma recomendação no nível mínimo de reparo a ser usado. É uma prática comum executar CHECKDB com REPAIR_ALLOW_DATA_LOSS várias vezes até que não sejam relatados mais erros. Isso ocorre porque quando o reparo corrige um conjunto de erros, outras vinculações quebradas podem ser descobertas. No entanto, novos erros podem aparecer se a causa subjacente não tiver sido resolvida. Portanto, se problemas de nível do sistema, como hardware ou sistema de arquivos estão causando corrupção de dados, esses problemas devem ser resolvidos primeiro, antes da restauração de um backup ou reparo. Os engenheiros de suporte da Microsoft não poderão ajudar na recuperação física de dados corrompidos se o reparo não corrigir os erros de consistência ou se o backup do banco de dados estiver corrompido.

    Quando você executa DBCC CHECKDB, uma recomendação é fornecida para indicar a opção de reparo mínima necessária para reparar todos os erros. Essas mensagens se assemelham à seguinte saída:

    O CHECKDB encontrou 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 por DBCC CHECKDB (mydb).

    A recomendação de reparo é o nível mínimo de reparo para tentar resolve todos os erros de CHECKDB. O nível mínimo de reparo não significa que essa opção de reparo corrija todos os erros. Alguns erros simplesmente não podem ser corrigidos. Além disso, talvez seja necessário executar o processo de reparo mais de uma vez. Nem todos os erros relatados exigem que o uso desse nível de reparo seja resolvido. Isso significa que nem todos os reparos resultam CHECKDBREPAIR_ALLOW_DATA_LOSS em perda de dados. O reparo deve ser executado para determinar se a resolução de um erro resulta em perda de dados. Uma técnica para ajudar a reduzir o nível de reparo para cada tabela é usar DBCC CHECKTABLE para qualquer tabela que relata um erro. Isso mostra o nível mínimo de reparo de uma determinada tabela.

    Aviso

    Você deve executar a validação manual de dados após CHECKDB a conclusão do reparo ou da exportação ou importação de dados. Para obter mais informações, confira Argumentos DBCC CHECKDB. Os dados podem não ser logicamente consistentes após o reparo. Por exemplo, o reparo (particularmente REPAIR_ALLOW_DATA_LOSS a opção) pode remover páginas de dados inteiras que contêm dados inconsistentes. Nesses casos, uma tabela com uma relação de chave estrangeira com outra tabela pode acabar com linhas que não têm linhas de chave primária correspondentes na tabela pai.

  6. Tente escrever o script do esquema de banco de dados. Use o script para criar um novo banco de dados e, em seguida, use uma ferramenta como BCP ou Assistente de Exportação/Importação do SSIS para exportar o máximo possível de dados do banco de dados corrompido para o novo banco de dados. A exportação de dados de uma tabela corrupta provavelmente falhará. Nesses casos, ignore esta tabela, vá para a próxima e salve o que puder.

  7. Examine os artigos a seguir para obter erros específicos gerados e DBCC CHECKDB siga as etapas fornecidas (se houver). Aqui estão alguns exemplos:

Investigar a causa raiz de erros de consistência de banco de dados

Para identificar a causa raiz dos erros de consistência do banco de dados, considere esses métodos:

  • Verifique o Log de Eventos do Sistema Windows em busca de erros relacionados ao sistema, driver ou disco e trabalhe com o fabricante de hardware para resolve-los.
  • Execute qualquer diagnóstico fornecida pelos fabricantes de hardware para o computador e/ou sistema de disco.
  • Trabalhe com seu fornecedor de hardware ou fabricante de dispositivos para garantir que:
  • Considere usar um utilitário como SQLIOSim na unidade em que residem os bancos de dados que relataram os erros de consistência. O SQLIOSim é uma ferramenta independente do mecanismo SQL Server para testar a integridade de E/S para o sistema de disco. O SQLIOSim é fornecido com SQL Server e não requer um download separado. Ele pode ser encontrado na pasta \MSSQL\Binn .
  • Verifique a documentação da Atualização Cumulativa ou do Service Pack para ver quaisquer problemas conhecidos corrigidos relacionados à corrupção do banco de dados (erros de consistência) e aplique quaisquer correções relevantes. Um local central em que você pode pesquisar todas as correções para uma determinada versão se a correção detalhada listar SQL Server 2022, 2019, 2017.
  • Verifique se há outros erros relatados por SQL Server como violações de acesso ou declarações. A atividade contra bancos de dados corrompidos frequentemente resulta em exceções de violação de acesso ou erros de declaração.
  • Verifique se seus bancos de dados estão usando a opção PAGE_VERIFY CHECKSUM . Se erros de soma de verificação estiverem sendo relatados, isso é uma indicação de que os erros de consistência ocorreram após SQL Server tiver escrito páginas em disco. Assim, seu subsistema de E/S deve ser verificado minuciosamente. Para obter mais informações sobre erros de soma de verificação, consulte Como solucionar problemas do Msg 824 em SQL Server.
  • Procure erros da mensagem 832 no ERRORLOG. Esses erros podem indicar que as páginas podem ser danificadas enquanto estão em cache antes de serem gravadas no disco. Para obter mais informações, consulte Como solucionar problemas do Msg 832 no SQL Server.
  • Em outro sistema, tente restaurar um backup de banco de dados que você sabe que é "limpo" (sem erros de ) seguido por backups de log de CHECKDBtransações que abrangem o tempo em que o erro foi gerado. Se você puder "recriar" esse problema restaurando um backup de banco de dados "limpo" e um backup de log de transações, 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 inserindo ou atualizando dados inválidos em tabelas de SQL Server. Para obter mais informações sobre como solucionar problemas de erros de Puridade de Dados, confira Solução de problemas do Erro DBCC 2570 no SQL Server 2005.
  • Verifique a integridade do sistema de arquivos usando o comando chkdsk .

Mais informações

Para obter detalhes sobre a sintaxe de DBCC CHECKDB e informações ou opções sobre como executar o comando, consulte DBCC CHECKDB (Transact-SQL).

Se algum erro for encontrado usando CHECKDB, outras mensagens semelhantes à seguinte mensagem serão relatadas no ERRORLOG para fins de relatório de erro:

**Dump thread - spid = 0, EC = 0x00000000855F5EB0
***Stack Dump being sent toFilePath\FileName
* ******************************************************************************
*
* BEGIN STACK DUMP:
*  Date/Timespid 53
*
* DBCC database corruption
*
* Input Buffer 84 bytes -
*             dbcc checkdb(mydb)
*
* *******************************************************************************
*   -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000001E8
External dump process return code 0x20002001.

As informações de erro foram enviadas ao relatório de erros do Watson.

Os arquivos usados para relatórios de erros incluem um arquivo sqlDump<nnn>.txt . Esse arquivo pode ser útil para fins históricos, pois contém uma lista dos erros encontrados CHECKDB em um formato XML.

Para descobrir quando a última vez DBCC CHECKDB foi executada sem erros detectados para um banco de dados (o último limpo CHECKDBconhecido ), marcar o SQL Server ERRORLOG para uma mensagem como a seguinte em um usuário ou banco de dados do sistema (esta mensagem é escrita como uma mensagem de nível de informação no Log de Eventos do Aplicativo Windows com EventID = 17573 também):

Data/Hora spid7s CHECKDB para banco de dados 'master' concluído sem erros em Data/Hora22:11:11.417 (hora local). Esta é apenas uma mensagem informativa; nenhuma ação do usuário é necessária