Risoluzione dei problemi relativi agli errori di coerenza dei database riportati da DBCC CHECKB

In questo articolo viene illustrato come risolvere gli errori segnalati dal comando DBCC CHECKDB.

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

Sintomi

Quando viene eseguito DBCC CHECKDB (o altri comandi simili come CHECKTABLE), nel log degli errori di SQL Server viene scritto un messaggio simile al seguente:

Data/ora spid53 DBCC CHECKDB (MyDB) eseguito da MYDOMAIN\theuser sono stati trovati 15 errori e sono stati corretti errori. Tempo trascorso: 0 ore 0 minuti 0 secondi. Lo snapshot di database interno ha un punto di divisione LSN = 00000026:0000089d: 0001 e primo LSN = 00000026:0000089c: 0001. Solo un messaggio informativo. Non è richiesta alcuna azione da parte dell'utente.

Questo messaggio indica il numero di errori di coerenza dei database trovati e il numero di interventi corretti (se è stata utilizzata un'opzione di ripristino con il comando). Questo messaggio viene anche scritto nel registro eventi applicazioni di Windows come messaggio a livello di informazioni con EventId = 8957 (anche se sono stati segnalati errori questo messaggio è un messaggio di livello informativo).

Le informazioni contenute nel messaggio che inizia 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 DBCC CHECKDB online, viene utilizzato uno snapshot interno del database per presentare un insieme coerente di dati da controllare.

In questo articolo non viene illustrato come risolvere i problemi di ogni errore specifico segnalato da DBCC CHECKDB, ma piuttosto l'approccio generale se vengono segnalati errori. Tutti i riferimenti a CHECKDB in questo articolo si applicano anche a DBCC CHECKTABLE e, CHECKFILEGROUP se non specificato.

Causa

DBCC CHECKDB verifica la coerenza fisica e logica delle pagine del database, le righe, le pagine di allocazione, le relazioni di indice, l'integrità referenziale della tabella di sistema e altri controlli struttura. Se uno qualsiasi di questi controlli ha esito negativo (a seconda delle opzioni scelte), gli errori verranno segnalati come parte del comando.

La causa di tali problemi può variare da un danneggiamento del sistema di file, da problemi relativi al sistema hardware, problemi relativi ai driver, pagine danneggiate in memoria o problemi con il motore di SQL Server. Leggere la sezione risoluzione per ulteriori informazioni su come individuare la causa degli errori segnalati.

Risoluzione

La prima soluzione migliore se DBCC CHECKDB segnala errori di coerenza è il ripristino da un backup valido noto. Tuttavia, se non è possibile eseguire il ripristino da un backup, CHECKDB fornisce una funzionalità per la correzione degli errori. Se si verificano problemi relativi a livello di sistema, ad esempio il file System o l'hardware, è consigliabile correggerli prima prima di eseguire il ripristino o l'esecuzione di un ripristino.

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

CHECKDB ha trovato 0 allocazioni di errori e 15 errori di coerenza nel database ' MyDB '.
REPAIR_ALLOW_DATA_LOSS è il livello minimo di ripristino per gli errori riscontrati da DBCC CHECKDB (MyDB).

La raccomandazione di ripristino è il livello minimo di ripristino per tentare di risolvere tutti gli errori di CHECKDB. Questo non significa che questa opzione di ripristino risolverà tutti gli errori. Inoltre, non tutti gli errori segnalati possono richiedere questo livello di ripristino per risolvere l'errore. Questo significa che non tutti gli errori segnalati da CHECKDB quando repair_allow_data_loss è consigliato provocheranno una perdita di dati. Il ripristino deve essere eseguito per determinare se la risoluzione di un errore provocherà la perdita di dati. Una tecnica che consente di limitare il livello di ripristino per ogni tabella consiste nell'utilizzare DBCC CHECKTABLE per qualsiasi tabella che segnala un errore. In questo modo viene visualizzato il livello minimo di ripristino per una determinata tabella.

Per trovare la causa del perché si sono verificati errori di coerenza dei database, prendere in considerazione i seguenti metodi:

  • Controllare il registro eventi di sistema di Windows per eventuali errori relativi a livello di sistema, driver o disco.
  • Controllare l'integrità del file System con chkdsk.
  • Eseguire qualsiasi diagnostica fornita dai produttori di hardware per il computer e/o il sistema di disco.
  • Collaborare con il fornitore o il produttore del dispositivo hardware per garantire quanto segue:
  • Si consideri l'utilizzo di un'utilità come SQLIOSim sulla stessa unità dei database che hanno riportato gli errori di coerenza. SQLIOSim è uno strumento indipendente dal motore di SQL Server per testare l'integrità delle operazioni di I/O per il sistema disco. SQLIOSim viene fornito con SQL Server 2008 e non richiede un download separato.
  • Controllare eventuali altri errori segnalati da SQL Server, ad esempio le violazioni di accesso o le asserzioni.
  • Verificare che i database utilizzino l' PAGE_VERIFY CHECKSUM opzione. Se sono stati segnalati errori di checksum, si tratta di indicatori che si sono verificati errori di coerenza dopo che SQL Server ha scritto pagine su disco in modo che il sistema disco venga controllato accuratamente, vedere come risolvere i problemi di Msg 824 in SQL Server per ulteriori informazioni sugli errori di checksum.
  • Cercare i messaggi di errore msg 832 nel log degli errori. Si tratta di indicatori che possono essere danneggiati durante la cache prima di essere scritti su disco. Per ulteriori informazioni , vedere Risoluzione dei problemi relativi a Msg 832 in SQL Server .
  • Provare a ripristinare il backup di un database si sa che è "clean" (nessun errore da CHECKDB) e i backup dei registri delle transazioni che si conoscono estendono l'ora in cui si è verificato l'errore. Se è possibile "riprodurre" questo problema ripristinando un backup dei database "puliti" e i registri 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 ulteriori informazioni sulla risoluzione degli errori relativi alla purezza dei dati, vedere Troubleshooting DBCC Error 2570 in SQL server 2005.

Ulteriori informazioni

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

Se gli errori sono stati individuati da CHECKDB, i messaggi aggiuntivi come i seguenti vengono riportati nel log dell'errore ai fini della segnalazione degli errori:

Data/ora spid53 using ' dbghelp.dll' version ' 4.0.5'
Data/ora spid53 * * thread di dump-SPID = 0, EC = 0x00000000855F5EB0
Data/ora spid53 * * _Stack dump inviato toFilePath\FileName
Data/ora spid53 _ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Data/ora spid53 *
Data/ora spid53 * BEGIN STACK DUMP:
Data/ora spid53 * data/Timespid 53
Data/ora spid53 *
Data/ora spid53 * danneggiamento del database DBCC
Data/Timespid53 *
Data/ora spid53 * buffer di input 84 byte-
Data/ora spid53 * DBCC CHECKDB (MyDB)
Data/ora spid53 *
Data/ora spid53 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Data/ora spid53 *-------------------------------------------------------------------------------
Data/ora spid53 * dump dello stack breve
Data/ora la firma dello stack di spid53 per il dump è 0x00000000000001E8
Data/ora spid53 il processo di dump esterno restituisce codice 0x20002001.

Le informazioni sull'errore sono state inviate alla segnalazione degli errori di Watson.

I file utilizzati per la segnalazione degli errori includono un <nnn> file SQLDump. txt. Questo file può essere utile per scopi cronologici poiché contiene un elenco degli errori trovati da CHECKDB in formato XML.

Per sapere quando è stata eseguita l'ultima volta che è stato eseguito DBCC CHECKDB senza errori rilevati per un database (l'ultimo oggetto pulito CHECKDB), controllare il registro di log di SQL Server per un messaggio simile al seguente per il database o il database di sistema (questo messaggio viene scritto come messaggio di livello informativo nel log eventi dell'applicazione di Windows con EventId = 17573):

Data/ora spid7s CHECKDB per il database ' Master ' è stato completato senza errori ondate/Time22:11:11.417 (ora locale). Si tratta di un messaggio informativo solo. non è necessaria alcuna azione dell'utente