Risoluzione degli errori di coerenza del database riportati da DBCC CHECKDB

Questo articolo illustra come risolvere gli errori segnalati dal DBCC CHECKDB comando .

Versione originale del prodotto: SQL Server
Numero KB originale: 2015748

Sintomi

Quando viene eseguito DBCC CHECKDB (o altri comandi simili, ad esempio DBCC CHECKTABLE), viene scritto un messaggio simile al seguente nel log degli errori di 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.

Questo messaggio mostra il numero di errori di coerenza del database rilevati e quanti sono stati riparati, se è stata usata un'opzione di ripristino. Questo messaggio viene scritto anche nel registro eventi dell'applicazione di Windows come messaggio a livello di informazioni con EventID=8957. Anche se vengono segnalati errori, questo messaggio è un messaggio di livello informativo.

Le informazioni nel messaggio che iniziano con "snapshot interno del database..." vengono visualizzate solo se DBCC CHECKDB è stato eseguito online, quando il database non è in modalità SINGLE_USER. Ciò è dovuto al fatto che per un'operazione online DBCC CHECKDB viene usato uno snapshot interno del database per presentare un set coerente di dati da controllare.

Questo articolo non illustra come risolvere ogni errore specifico segnalato da DBCC CHECKDB ma l'approccio generale se vengono segnalati errori. Qualsiasi riferimento a CHECKDB in questo articolo si applica anche a DBCC CHECKTABLE e DBCC CHECKFILEGROUP , a meno che non sia specificato.

Causa

Il DBCC CHECKDB comando controlla la coerenza fisica e logica delle pagine del database, delle righe, delle pagine di allocazione, delle relazioni di indice, dell'integrità referenziale della tabella di sistema ed esegue altri controlli della struttura. Se uno di questi controlli ha esito negativo (a seconda delle opzioni scelte), vengono segnalati errori.

La causa di questi problemi può variare da danneggiamento del file system, problemi di sistema hardware sottostanti, problemi del driver, pagine danneggiate nella memoria o nella cache di archiviazione o problemi con SQL Server. Per informazioni su come identificare la causa radice degli errori segnalati, vedere Analizzare la causa radice.

Risoluzione

  1. Risolvere eventuali problemi relativi all'hardware sottostanti nel sistema prima di procedere con il ripristino di un backup o altrimenti riparare il database. Applicare qualsiasi driver di dispositivo, firmware, BIOS e aggiornamenti del sistema operativo rilevanti per il percorso di I/O. Collaborare con l'amministratore del percorso di I/O completo (computer locale, driver di dispositivo, schede di interfaccia di rete di archiviazione, SAN, archiviazione back-end e cache) e memoria (RAM) per isolare e risolvere eventuali problemi. Gli esempi includono l'aggiornamento dei driver di dispositivo e il controllo della configurazione dell'intero percorso di I/O. Per informazioni dettagliate su come analizzare la causa radice, vedere Analizzare la causa radice.

  2. Se DBCC CHECKDB segnala errori di coerenza permanenti, la soluzione migliore consiste nel ripristinare i dati da un backup valido noto. Per altre informazioni, vedere Ripristino e recupero.

  3. Applicare l'aggiornamento cumulativo di SQL Server o il Service Pack più recente per assicurarsi di non riscontrare problemi noti. Controllare la documentazione relativa all'aggiornamento cumulativo o al Service Pack per eventuali problemi noti risolti relativi al danneggiamento del database (errori di coerenza) e applicare eventuali correzioni pertinenti. Un'unica posizione centrale in cui è possibile cercare tutte le correzioni per una determinata versione negli elenchi dettagliati delle correzioni per SQL Server 2022, 2019, 2017.

  4. Se gli DBCC CHECKDB errori sono intermittenti, ovvero se vengono visualizzati in un'esecuzione e scompaiono nel successivo, potrebbero verificarsi problemi di cache del disco (driver di dispositivo o altro problema di percorso di I/O). Collaborare con i responsabili del percorso di I/O per isolare e risolvere eventuali problemi. Alcuni esempi includono l'aggiornamento dei driver di dispositivo, il controllo della configurazione dell'intero percorso di I/O e l'aggiornamento del firmware e del BIOS sui dispositivi del percorso di I/O e sul sistema.

  5. Se non è possibile eseguire il ripristino da un backup, CHECKDB dispone di una funzionalità per correggere gli errori che è possibile usare. Esistono due livelli di riparazione:

    • REPAIR_REBUILD - esegue riparazioni che non hanno alcuna possibilità di perdita di dati.
    • REPAIR_ALLOW_DATA_LOSS - esegue riparazioni che hanno la possibilità di perdita di dati.

    Per altre informazioni, vedere la documentazione di DBCC CHECKDB.

    È necessario prestare attenzione quando si fa la scelta di riparare con Consenti perdita di dati perché potrebbe lasciare il database in uno stato logicamente incoerente. L'output DBCC CHECKDB fornisce una raccomandazione sul livello minimo di riparazione da usare. È pratica comune eseguire CHECKDB con REPAIR_ALLOW_DATA_LOSS più volte fino a quando non vengono più segnalati errori. Ciò è dovuto al fatto che quando la riparazione corregge un set di errori, potrebbero emergere altre dipendenze danneggiate. Tuttavia, nuovi errori possono essere visualizzati se la causa sottostante non è stata risolta. Pertanto, se i problemi a livello di sistema, ad esempio hardware o file system, causano un danneggiamento dei dati, questi problemi devono essere risolti prima del ripristino di un backup o di una riparazione. I tecnici del supporto Tecnico Microsoft non possono assistere con il ripristino fisico dei dati danneggiati se la riparazione non corregge gli errori di coerenza o se il backup del database è danneggiato.

    Quando si esegue DBCC CHECKDB, viene fornita una raccomandazione per indicare l'opzione di ripristino minima necessaria per correggere tutti gli errori. Questi messaggi sono simili all'output seguente:

    CHECKDB ha rilevato 0 errori di allocazione e 15 errori di coerenza nel database 'mydb'.
    REPAIR_ALLOW_DATA_LOSS è il livello di ripristino minimo per gli errori rilevati da DBCC CHECKDB (mydb).

    La raccomandazione di riparazione è il livello minimo di ripristino per tentare di risolvere tutti gli errori provenienti da CHECKDB. Il livello minimo di ripristino non significa che questa opzione di ripristino corregge tutti gli errori. Alcuni errori non possono essere corretti. Potrebbe anche essere necessario eseguire il processo di riparazione più volte. Non tutti gli errori segnalati richiedono l'uso di questo livello di ripristino per essere risolti. Ciò significa che non tutte le riparazioni effettuate da CHECKDB con REPAIR_ALLOW_DATA_LOSS comportano una perdita di dati. È necessario eseguire la riparazione per determinare se la risoluzione di un errore causa la perdita di dati. Una tecnica che aiuta a determinare il livello di ripristino per ogni tabella consiste nell'usare DBCC CHECKTABLE per qualsiasi tabella che segnala un errore. Viene visualizzato il livello minimo di riparazione per una determinata tabella.

    Avviso

    È necessario eseguire la convalida manuale dei dati al completamento della CHECKDB riparazione o dell'esportazione o dell'importazione dei dati. Per altre informazioni, vedere argomenti di DBCC CHECKDB. I dati potrebbero non essere coerenti logicamente dopo il ripristino. Ad esempio, la riparazione (in particolare l'opzione REPAIR_ALLOW_DATA_LOSS) potrebbe rimuovere intere pagine di dati contenenti dati incoerenti. In questi casi, una tabella con una relazione di chiave esterna con un'altra tabella può terminare con righe che non hanno righe corrispondenti con chiave primaria nella tabella padre.

  6. Provare a generare uno script dello schema del database. Usare lo script per creare un nuovo database e quindi usare uno strumento come BCP o Importazione/Esportazione guidata SSIS per esportare il maggior numero possibile di dati dal database danneggiato al nuovo database. È probabile che l'esportazione di dati da una tabella danneggiata abbia esito negativo. In questi casi, ignorare questa tabella, passare alla successiva e salvare ciò che è possibile.

  7. Esaminare gli articoli seguenti per individuare errori specifici generati da DBCC CHECKDB e seguire i passaggi forniti (se presenti). Di seguito sono riportati alcuni esempi.

Indagare la causa principale degli errori di coerenza del database

Per identificare la causa radice degli errori di coerenza del database, considerare questi metodi:

  • Controllare il registro eventi di sistema di Windows per individuare eventuali errori relativi a livello di sistema, driver o disco e collaborare con il produttore dell'hardware per risolverli.
  • Eseguire qualsiasi diagnostica fornita dai produttori hardware per il computer e/o il sistema del disco. La maggior parte dei sistemi fornisce la diagnostica predefinita BIOS/UEFI per l'archiviazione (dischi rigidi), la memoria, le CPU, le schede di sistema, le matrici RAID e più altri componenti.
  • Collaborare con il fornitore hardware o il produttore del dispositivo per assicurarsi che:
  • È consigliabile usare un'utilità come SQLIOSim nell'unità in cui si trovano i database in cui sono stati segnalati errori di coerenza. SQLIOSim è uno strumento indipendente dal motore di SQL Server per testare l'integrità di I/O per il sistema del disco. SQLIOSim viene fornito con SQL Server e non richiede un download separato. Si trova nella cartella \MSSQL\Binn.
  • Controllare la documentazione relativa all'aggiornamento cumulativo o al Service Pack per eventuali problemi noti risolti relativi al danneggiamento del database (errori di coerenza) e applicare eventuali correzioni pertinenti. Una posizione centrale in cui è possibile cercare tutte le correzioni per una determinata versione negli elenchi dettagliati delle correzioni per SQL Server 2022, 2019, 2017.
  • Verificare la presenza di altri errori segnalati da SQL Server, ad esempio violazioni di accesso o asserzioni. Le operazioni sui database danneggiati causano spesso eccezioni di violazione di accesso o errori di asserzione.
  • Assicurarsi che i database usino l'opzione PAGE_VERIFY CHECKSUM . Se vengono segnalati errori di checksum, si tratta di un'indicazione che si sono verificati errori di coerenza dopo che SQL Server ha scritto pagine su disco. Di conseguenza, il sottosistema di I/O deve essere controllato accuratamente. Per altre informazioni sugli errori di checksum, vedere Come risolvere i problemi relativi a Msg 824 in SQL Server.
  • Cercare gli errori 832 in ERRORLOG. Questi errori potrebbero indicare che le pagine potrebbero essere danneggiate mentre sono nella cache prima della scrittura sul disco. Per altre informazioni, vedere Come risolvere i problemi relativi a Msg 832 in SQL Server.
  • In un altro sistema, provare a ripristinare un backup del database che sai essere "pulito" (nessun errore da CHECKDB) seguito da backup del log delle transazioni che si estendono nel tempo in cui è stato generato l'errore. Se è possibile "ricreare" questo problema ripristinando un backup del database "pulito" e un backup del log delle transazioni, contattare il supporto tecnico Microsoft per assistenza.
  • Gli errori di Data Purity possono essere un problema con l'applicazione che inserisce o aggiorna dati non validi nelle tabelle di SQL Server. Per altre informazioni sulla risoluzione degli errori di purezza dei dati, vedere Risoluzione degli errori DBCC 2570 in SQL Server 2005.
  • Controllare l'integrità del file system usando il comando chkdsk. Non eseguire chkdsk mentre SQL Server è in esecuzione. Potrebbe segnalare errori transitori dei file se SQL Server sta scrivendo nei file da controllare. Inoltre, opzioni come /r o /f possono spostare i byte di file in una posizione diversa sul disco e tale spostamento potrebbe causare danneggiamento se SQL Server sta anche scrivendo o leggendo da questi file. Assicurarsi quindi di arrestare SQL Server prima di eseguire il chkdsk comando . Inoltre, prestare attenzione con le opzioni di riparazione come /r e /f. Assicurarsi di disporre di un backup dei database prima di eseguire una riparazione, in quanto queste opzioni possono danneggiare i file, se vengono rilevati errori del disco da chkdsk.

Ulteriori informazioni

Per informazioni dettagliate sulla sintassi di DBCC CHECKDB e per informazioni o opzioni su come eseguire il comando, vedere DBCC CHECKDB (Transact-SQL).

Se vengono rilevati errori tramite CHECKDB, altri messaggi simili al seguente vengono segnalati nel log degli errori ai fini della segnalazione degli errori:

**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.

Le informazioni sull'errore sono state inviate al sistema di segnalazione errori Watson.

I file usati per la segnalazione errori includono un file SQLDump<nnn>.txt. Questo file può essere utile per scopi storici perché contiene un elenco degli errori rilevati da CHECKDB in un formato XML.

Per scoprire l'ultima volta DBCC CHECKDB che è stata eseguita senza errori rilevati per un database (l'ultima CHECKDB pulita nota), controllare SQL Server ERRORLOG. Cercare un messaggio simile al seguente per un utente o un database di sistema. Questo messaggio viene scritto come messaggio a livello di informazioni nel registro eventi dell'applicazione di Windows con EventID = 17573:

Date/Time spid7s CHECKDB per il database 'master' è terminato senza errori il Date/Time22:11:11.417 (ora locale). Si tratta solo di un messaggio informativo; non è necessaria alcuna azione da parte dell'utente

  • Ultimo aggiornamento: