Condividi tramite

Risoluzione degli errori di coerenza del database riportati da DBCC CHECKB

  • 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, 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 ripristinati, 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 a livello di informazioni.

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à . Ciò è dovuto al fatto che per un database online DBCC CHECKDBviene 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 e di 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 cache di memoria o 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 il ripristino del 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) 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 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. 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. 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 nei dispositivi e nel sistema del percorso I/O.

  5. Se non è possibile eseguire il ripristino da un backup, CHECKDB è disponibile 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 consentire la perdita di dati perché potrebbe lasciare il database in uno stato logicamente incoerente. L'output DBCC CHECKDB consiglia di usare il livello di ripristino minimo. È pratica comune eseguire CHECKDB più REPAIR_ALLOW_DATA_LOSS volte fino a quando non vengono segnalati altri errori. Ciò è dovuto al fatto che quando il ripristino corregge un set di errori, potrebbero essere scoperti altri collegamenti interrotti. 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 un ripristino. 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 ripristino è il livello minimo di ripristino per tentare di risolvere tutti gli errori 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 ripristino più volte. Non tutti gli errori segnalati richiedono la risoluzione dell'uso di questo livello di ripristino. Ciò significa che non tutte le riparazioni con CHECKDB REPAIR_ALLOW_DATA_LOSS conseguente perdita di dati. È necessario eseguire il ripristino per determinare se la risoluzione di un errore causa la perdita di dati. Una tecnica che consente di limitare 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 ripristino per una determinata tabella.

    Avviso

    È necessario eseguire la convalida manuale dei dati dopo CHECKDB il ripristino o l'esportazione o l'importazione dei dati. Per altre informazioni, vedere Argomenti DBCC CHECKDB. I dati potrebbero non essere coerenti logicamente dopo il ripristino. Ad esempio, il ripristino (opzione in particolare 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 dispongono di righe di chiave primaria corrispondenti nella tabella padre.

  6. Provare a creare uno script dello schema del database. Usare lo script per creare un nuovo database e quindi usare uno strumento come BCP o Esportazione/Importazione/Importazione 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.

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 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.
  • Collaborare con il fornitore hardware o il produttore del dispositivo per assicurarsi che:
    • I dispositivi hardware e la configurazione confermano i requisiti di input/output motore di database di Microsoft SQL Server.
    • I driver di dispositivo e altri componenti software di supporto di tutti i dispositivi nel percorso di I/O sono aggiornati.
  • È 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à di I/O per il sistema del disco. SQLIOSim viene fornito con SQL Server e non richiede un download separato. È disponibile 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 se gli elenchi di correzioni dettagliate per SQL Server 2022, 2019, 2017.
  • Verificare la presenza di altri errori segnalati da SQL Server, ad esempio violazioni di accesso o asserzioni. L'attività nei database danneggiati causa 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 nel log degli errori. Questi errori potrebbero indicare che le pagine potrebbero essere danneggiate durante la memorizzazione 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 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 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 durante l'esecuzione di SQL Server. Potrebbe segnalare errori di file temporanei se SQL Server sta scrivendo nei file da controllare. Inoltre, i commutatori come /r o /f possono spostare i byte di file in un percorso diverso su 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 un ripristino, in quanto queste opzioni possono danneggiare i file, se vengono rilevati errori del disco da chkdsk.

Ulteriori informazioni

Per informazioni dettagliate sulla sintassi e DBCC CHECKDB sulle informazioni o sulle opzioni relative all'esecuzione del 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 alla segnalazione errori Watson.

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

Per scoprire l'ultima volta DBCC CHECKDB che è stata eseguita senza errori rilevati per un database (l'ultima operazione pulita CHECKDBnota), 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 for database 'master' finished without errors on Date/Time22:11:11.417 (ora locale). Si tratta solo di un messaggio informativo; non è necessaria alcuna azione da parte dell'utente