Risolvere gli errori di coerenza del database segnalati da DBCC CHECKDB

  • Articolo

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 come DBCC CHECKTABLE), viene scritto un messaggio simile al seguente nel log degli errori 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 quanti errori di coerenza del database sono stati trovati e quanti sono stati ripristinati, se è stata usata un'opzione di ripristino. Questo messaggio viene scritto anche nel registro eventi dell'applicazione Windows come messaggio a livello di informazioni con EventID=8957. Anche se vengono segnalati errori, questo messaggio è un messaggio a livello di informazioni.

Le informazioni nel messaggio che iniziano con "snapshot interno del database..." viene visualizzato solo se DBCC CHECKDB è stato eseguito online, in cui il database non è in SINGLE_USER modalità . Questo avviene perché per un oggetto online DBCC CHECKDBviene usato uno snapshot del database interno per presentare un set coerente di dati da controllare.

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

Causa

Il DBCC CHECKDB comando controlla la coerenza fisica e logica di pagine di database, righe, pagine di allocazione, relazioni di indice, integrità referenziale della tabella di sistema e 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 dal danneggiamento del file system, dai problemi del sistema hardware sottostante, dai problemi del driver, dalle pagine danneggiate nella memoria o nella cache di archiviazione o dai problemi con il SQL Server. Per informazioni su come identificare la causa radice degli errori segnalati, vedere Analizzare la causa radice.

Risoluzione

  1. Risolvere eventuali problemi correlati all'hardware sottostante nel sistema prima di procedere con il ripristino di un backup o il ripristino del database in altro modo. Applicare tutti gli aggiornamenti del driver di dispositivo, del firmware, del BIOS e 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) 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 altre informazioni sul controllo della 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 ripristino.

  3. Applicare la versione più recente SQL Server Aggiornamento cumulativo o Service Pack per assicurarsi di non riscontrare problemi noti. Controllare la documentazione dell'aggiornamento cumulativo o del 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 se gli elenchi di correzioni dettagliate 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 gestori del percorso di I/O per isolare e risolvere eventuali problemi. Gli 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 nei dispositivi e nel sistema del percorso di I/O.

  5. Se non è possibile eseguire il ripristino da un backup, CHECKDB ha 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 ripristinare con consenti la perdita di dati perché potrebbe lasciare il database in uno stato logicamente incoerente. L'output DBCC CHECKDB consiglia il livello minimo di riparazione da usare. È prassi comune eseguire CHECKDB più volte con REPAIR_ALLOW_DATA_LOSS fino a quando non vengono segnalati altri errori. Ciò è dovuto al fatto che quando il ripristino corregge un set di errori, potrebbero essere individuati altri collegamenti interrotti. Tuttavia, è possibile che vengano visualizzati nuovi errori se la causa sottostante non è stata risolta. Pertanto, se i problemi a livello di sistema, ad esempio hardware o file system, causano il danneggiamento dei dati, questi problemi devono essere risolti prima del ripristino di un backup o di un ripristino. I tecnici del supporto tecnico Microsoft non possono supportare il ripristino fisico dei dati danneggiati se il ripristino 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 correzione minimo per gli errori rilevati da DBCC CHECKDB (mydb).

    La raccomandazione di ripristino è il livello minimo di ripristino per tentare di risolvere tutti gli errori da CHECKDB. Il livello di riparazione minimo non significa che questa opzione di ripristino corregge tutti gli errori. Alcuni errori semplicemente non possono essere corretti. Potrebbe anche essere necessario eseguire il processo di ripristino più di una volta. Non tutti gli errori segnalati richiedono la risoluzione dell'uso di questo livello di riparazione. Ciò significa che non tutte le operazioni di CHECKDBREPAIR_ALLOW_DATA_LOSS ripristino provocano la perdita di dati. È necessario eseguire il ripristino per determinare se la risoluzione di un errore comporta la perdita di dati. Una tecnica che consente di limitare il livello di correzione 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 CHECKDB termine del ripristino o dell'esportazione o dell'importazione dei dati. Per altre informazioni, vedere Argomenti DBCC CHECKDB. I dati potrebbero non essere coerenti logicamente dopo il ripristino. Ad esempio, il ripristino (in particolare REPAIR_ALLOW_DATA_LOSS l'opzione) potrebbe rimuovere intere pagine di dati che contengono dati incoerenti. In questi casi, una tabella con una relazione di chiave esterna con un'altra tabella può avere righe che non hanno righe di chiave primaria corrispondenti nella tabella padre.

  6. Provare a creare uno script per lo schema del database. Usare lo script per creare un nuovo database e quindi usare uno strumento come Esportazione/Importazione guidata BCP o SSIS per esportare la maggior parte dei dati possibile 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 al successivo 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). Ecco alcuni esempi:

Analizzare la causa radice degli errori di coerenza del database

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

  • Controllare nel registro eventi di sistema di Windows 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 di hardware per il computer e/o il sistema disco.
  • Collaborare con il fornitore dell'hardware o il produttore del dispositivo per assicurarsi che:
  • È consigliabile usare un'utilità come SQLIOSim nell'unità in cui si trovano i database che hanno segnalato gli errori di coerenza. SQLIOSim è uno strumento indipendente dal motore di SQL Server per testare l'integrità dell'I/O per il sistema disco. SQLIOSim viene fornito con SQL Server e non richiede un download separato. È disponibile nella cartella \MSSQL\Binn .
  • Controllare la documentazione dell'aggiornamento cumulativo o del 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 se gli elenchi di correzioni dettagliate per SQL Server 2022, 2019, 2017.
  • Verificare la presenza di eventuali altri errori segnalati da SQL Server, ad esempio violazioni di accesso o asserzioni. L'attività su database danneggiati genera spesso eccezioni di violazione di accesso o errori di asserzione.
  • Assicurarsi che i database utilizzino 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. Pertanto, 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 del messaggio 832 in ERRORLOG. Questi errori potrebbero indicare che le pagine potrebbero essere danneggiate mentre sono nella cache prima di essere scritte nel 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 noto che è "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 purezza dei dati possono essere un problema con l'applicazione che inserisce o aggiorna dati non validi nelle tabelle 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 .

Ulteriori informazioni

Per informazioni dettagliate sulla sintassi di e sulle informazioni o sulle opzioni su come eseguire il comando, vedere DBCC CHECKDB (Transact-SQL).For details on the syntax of DBCC CHECKDB and information or options about how to run the command, see DBCC CHECKDB (Transact-SQL).

Se vengono rilevati errori usando CHECKDB, altri messaggi simili al messaggio seguente vengono segnalati in ERRORLOG 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 alla segnalazione degli errori di Watson.

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

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

Data/ora spid7s CHECKDB per il database 'master' completato senza errori in Data/Ora22:11:11.417 (ora locale). Si tratta solo di un messaggio informativo; non è necessaria alcuna azione utente