Compartilhar via

Como solucionar problemas de consistência de banco de dados reportados por DBCC CHECKB

  • Artigo

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

Versão original do produto: SQL Server
Número original da base de conhecimento: 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 é gravada 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 que começa com "instantâneo do banco de dados interno..." só aparece se DBCC CHECKDB tiver sido executado online, no qual o banco de dados não está no SINGLE_USER modo. Isso ocorre porque, para um on-line DBCC CHECKDB, um instantâneo de banco de dados interno é usado para apresentar um conjunto consistente de dados a serem verificados.

Este artigo não discute como solucionar cada erro específico relatado por 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 indicado.

Causa

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), os 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 no cache de armazenamento ou problemas com o SQL Server. Para obter informações sobre como identificar a causa raiz dos erros relatados, consulte Investigar a causa raiz.

Resolução

  1. Resolva quaisquer problemas subjacentes relacionados ao hardware no sistema antes de prosseguir com a restauração de um backup ou reparar o banco de dados. Aplique todas as atualizações de driver de dispositivo, firmware, BIOS e sistema operacional relevantes para o caminho de E/S. Trabalhe com o administrador do caminho de E/S completo (computador local, drivers de dispositivo, NICs de armazenamento, SAN, armazenamento de back-end e cache) para isolar e resolver quaisquer problemas. Os exemplos incluem a atualização de drivers de dispositivo e a verificação da 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 o relatar erros de consistência permanentes, a melhor solução seria restaurar os dados de um backup em boas condições. Para obter mais informações, consulte Restauração e recuperação.

  3. Aplique a atualização cumulativa ou o Service Pack mais recente do SQL Server para garantir que você não esteja enfrentando problemas conhecidos. Verifique a documentação da Atualização Cumulativa ou do Service Pack para ver se há problemas conhecidos corrigidos relacionados à corrupção do banco de dados (erros de consistência) e aplique as correções relevantes. Um local central onde você pode pesquisar todas as correções para uma versão específica se as listas de correções detalhadas para 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ê pode 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 resolver quaisquer problemas. Os exemplos incluem a atualização de drivers de dispositivo, a verificação da configuração de todo o caminho de E/S e a atualização do firmware e do BIOS nos dispositivos e no sistema do caminho de E/S.

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

    • REPAIR_REBUILD - Realiza reparos que não têm possibilidade de perda de dados.
    • REPAIR_ALLOW_DATA_LOSS - Realiza reparos que têm a possibilidade de perda de dados.

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

    Você deve ter cuidado ao optar por reparar com permitir perda de dados, pois isso pode deixar seu banco de dados em um estado logicamente inconsistente. A DBCC CHECKDB saída faz uma recomendação sobre o nível mínimo de reparo a ser usado. É uma prática comum executar CHECKDB várias REPAIR_ALLOW_DATA_LOSS vezes até que não sejam relatados mais erros. Isso ocorre porque, quando o reparo corrige um conjunto de erros, outras ligações quebradas podem ser descobertas. No entanto, novos erros podem aparecer se a causa subjacente não tiver sido resolvida. Portanto, se problemas no nível do sistema, como hardware ou sistema de arquivos, estiverem 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 podem 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 CHECKDBo , é fornecida uma recomendação para indicar a opção de reparo mínima necessária para reparar todos os erros. Essas mensagens são semelhantes à 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 resolver todos os erros do 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, pode ser necessário executar o processo de reparo mais de uma vez. Nem todos os erros relatados exigem o uso desse nível de reparo para serem resolvidos. Isso significa que nem todos os reparos resultam CHECKDB REPAIR_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 restringir qual é o nível de reparo para cada tabela é usar DBCC CHECKTABLE para qualquer tabela que relate um erro. Isso mostra o nível mínimo de reparo para 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, consulte Argumentos DBCC CHECKDB. Os dados podem não ser logicamente consistentes após o reparo. Por exemplo, reparar (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 criar um script para o esquema do banco de dados. Use o script para criar um novo banco de dados e, em seguida, use uma ferramenta como o Assistente de Exportação/Importação BCP ou 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 corrompida provavelmente falhará. Nesses casos, pule esta tabela, vá para a próxima e salve o que puder.

  7. Revise os artigos a seguir para ver se há erros específicos gerados por DBCC CHECKDB e siga as etapas fornecidas (se houver). Eis alguns exemplos:

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

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

  • Verifique o Log de Eventos do Sistema do Windows para ver se há erros relacionados ao nível do sistema, driver ou disco e trabalhe com o fabricante do hardware para resolvê-los.
  • Execute todos os diagnósticos fornecidos pelos fabricantes de hardware para o computador e/ou sistema de disco.
  • Trabalhe com o fornecedor de hardware ou fabricante do dispositivo para garantir que:
    • Os dispositivos de hardware e a configuração confirmam os requisitos de entrada/saída do mecanismo de banco de dados do Microsoft SQL Server.
    • Os drivers de dispositivo e outros componentes de software de suporte de todos os dispositivos no caminho de E/S estejam atualizados.
  • Considere usar um utilitário como o SQLIOSim na unidade em que residem os bancos de dados que relataram os erros de consistência. O SQLIOSim é uma ferramenta independente do SQL Server Engine para testar a integridade da E/S para o sistema de disco. O SQLIOSim é fornecido com o 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 se há problemas conhecidos corrigidos relacionados à corrupção do banco de dados (erros de consistência) e aplique as correções relevantes. Um local central onde você pode pesquisar todas as correções para uma versão específica se as listas de correções detalhadas para SQL Server 2022, 2019, 2017.
  • Verifique se há outros erros relatados pelo SQL Server, como violações de acesso ou asserções. A atividade em bancos de dados corrompidos frequentemente resulta em exceções de violação de acesso ou erros de declaração.
  • Verifique se os bancos de dados estão usando a PAGE_VERIFY CHECKSUM opção. Se erros de soma de verificação estiverem sendo relatados, isso é uma indicação de que os erros de consistência ocorreram depois que o SQL Server gravou páginas no 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 de Msg 824 no SQL Server.
  • Procure erros da mensagem 832 no ERRORLOG. Esses erros podem indicar que as páginas podem ser danificadas enquanto estão no cache antes de serem gravadas no disco. Para obter mais informações, consulte Como solucionar problemas de Msg 832 no SQL Server.
  • Em outro sistema, tente restaurar um backup de banco de dados que você sabe que está "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.
  • Os erros de Pureza de Dados podem ser um problema com o aplicativo inserindo ou atualizando dados inválidos em tabelas do SQL Server. Para obter mais informações sobre como solucionar erros de Pureza de Dados, consulte Solucionando problemas do erro DBCC 2570 no SQL Server 2005.
  • Verifique a integridade do sistema de arquivos usando o comando chkdsk . Não execute chkdsk enquanto o SQL Server estiver em execução. Ele pode relatar erros de arquivo transitórios se o SQL Server estiver gravando nos arquivos que estão sendo verificados. Além disso, opções como /r ou /f podem mover bytes de arquivo para um local diferente no disco, e esse movimento pode levar à corrupção se o SQL Server também estiver gravando ou lendo esses arquivos. Portanto, certifique-se de interromper o SQL Server antes de executar o chkdsk comando. Além disso, tenha cuidado com opções de reparo como /r e /f. Certifique-se de ter um backup de seus bancos de dados antes de executar um reparo, pois essas opções podem corromper os arquivos, se erros de disco forem encontrados pelo chkdsk.

Mais informações

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

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

**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 para o relatório de erros do Watson.

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

Para descobrir a última vez DBCC CHECKDB que foi executado sem erros detectados para um banco de dados (o último limpo CHECKDBconhecido), verifique o SQL Server ERRORLOG. Procure uma mensagem como a seguinte para um banco de dados de usuário ou sistema. Essa mensagem também é gravada como uma mensagem de Nível de Informação no Log de Eventos do Aplicativo Windows com EventID = 17573):

Data/Hora spid7s CHECKDB para banco de dados 'mestre' 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