DBCC CHECKDB (Transact-SQL)

Articolo
04/26/2023

Si applica a: SQL Server Azure SQL Database Istanza gestita di SQL di Azure

Verifica l'integrità logica e fisica di tutti gli oggetti del database specificato eseguendo le operazioni seguenti:

Esegue DBCC CHECKALLOC nel database.
Esegue DBCC CHECKTABLE in ogni tabella e vista del database.
Esegue DBCC CHECKCATALOG nel database.
Convalida del contenuto di ogni vista indicizzata nel database.
Convalida la coerenza a livello di collegamenti tra i metadati della tabella e le directory e i file del file system quando vengono archiviati dati varbinary(max) nel file system usando FILESTREAM.
Convalida i dati di Service Broker nel database.

Ciò significa che i DBCC CHECKALLOCcomandi , DBCC CHECKTABLEo DBCC CHECKCATALOG non devono essere eseguiti separatamente da DBCC CHECKDB. Per ulteriori informazioni sui controlli eseguiti da questi comandi, vedere la relativa descrizione.

DBCC CHECKDB è supportato nei database che contengono tabelle ottimizzate per la memoria, ma la convalida si verifica solo nelle tabelle basate su disco. Tuttavia, come parte del backup e del ripristino del database, la convalida mediante CHECKSUM viene eseguita per i file nei filegroup ottimizzati per la memoria.

Poiché le opzioni di ripristino DBCC non sono disponibili per le tabelle ottimizzate per la memoria, è necessario eseguire regolarmente il backup dei database e testare i backup. Se i problemi di integrità dei dati si verificano in una tabella ottimizzata per la memoria, è necessario eseguire il ripristino dall'ultima copia di backup valida nota.

Convenzioni di sintassi Transact-SQL

Sintassi

DBCC CHECKDB
    [ ( database_name | database_id | 0
        [ , NOINDEX
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
    ) ]
    [ WITH
        {
            [ ALL_ERRORMSGS ]
            [ , EXTENDED_LOGICAL_CHECKS ]
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
            [ , MAXDOP = number_of_processors ]
        }
    ]
]

Nota

Per visualizzare la sintassi Transact-SQL per SQL Server 2014 e versioni precedenti, vedere Documentazione delle versioni precedenti.

Argomenti

database_name | database_id | 0

Nome o ID del database per cui eseguire controlli di integrità. Se questo argomento viene omesso oppure se viene specificato il valore 0, viene utilizzato il database corrente. I nomi dei database devono essere conformi alle regole per gli identificatori.

NOINDEX

Specifica che non verranno eseguiti controlli intensivi degli indici non cluster per le tabelle utente. Questa scelta consente di ridurre i tempi di esecuzione complessivi. NOINDEX non influisce sulle tabelle di sistema perché i controlli di integrità vengono sempre eseguiti sugli indici di tabella di sistema.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Specifica che DBCC CHECKDB ripristina gli errori trovati. Utilizzare le opzioni REPAIR solo come ultima risorsa. Il database specificato deve essere in modalità utente singolo per utilizzare una delle opzioni di correzione seguenti.

REPAIR_ALLOW_DATA_LOSS

Tenta di riparare tutti gli errori rilevati. Le operazioni di correzione possono comportare la perdita di dati.

Avviso

L'opzione REPAIR_ALLOW_DATA_LOSS è una funzionalità supportata, ma potrebbe non essere sempre l'opzione migliore per portare un database a uno stato fisicamente coerente. In caso di esito positivo, l'opzione REPAIR_ALLOW_DATA_LOSS potrebbe causare una perdita di dati. Infatti, può comportare una perdita maggiore di dati rispetto al ripristino del database dall'ultimo backup valido.

Microsoft consiglia sempre un ripristino utente dall'ultimo backup valido noto come metodo primario per il ripristino da errori segnalati da DBCC CHECKDB. L'opzione REPAIR_ALLOW_DATA_LOSS non è un'alternativa per il ripristino da un backup valido noto. Si tratta di un'opzione di ultima emergenza consigliata per l'uso solo se il ripristino da un backup non è possibile.

Alcuni errori, che possono essere ripristinati solo usando l'opzione REPAIR_ALLOW_DATA_LOSS , possono comportare la deallocazione di una riga, una pagina o una serie di pagine per cancellare gli errori. Tutti i dati deallocati non saranno più accessibile né potranno essere recuperati e non sarà possibile determinare il contenuto esatto dei dati deallocati. Pertanto, l'integrità referenziale potrebbe non essere accurata dopo la deallocazione di una riga o una pagina poiché i vincoli di chiave esterna non vengono verificati né mantenuti come parte di questa operazione di ripristino. L'utente deve controllare l'integrità referenziale del database (usando DBCC CHECKCONSTRAINTS) dopo aver usato l'opzione REPAIR_ALLOW_DATA_LOSS .

Prima di eseguire il ripristino, è necessario creare copie fisiche dei file appartenenti a questo database. Include il file di dati primario (), tutti i file di dati secondari (.mdf), tutti i file di log delle transazioni (.ndf.ldf) e altri contenitori che formano il database, inclusi cataloghi full-text, cartelle di flusso di file, dati ottimizzati per la memoria e così via.

Prima di eseguire il ripristino, è consigliabile modificare lo stato del database in EMERGENCY modalità e cercare di estrarre il maggior numero possibile di informazioni dalle tabelle critiche e salvare tali dati.
REPAIR_FAST

Supporta la sintassi per motivi di compatibilità con le versioni precedenti Non vengono eseguite correzioni.
REPAIR_REBUILD

Esegue operazioni di ripristino senza possibilità di perdita dei dati. Questa opzione può includere operazioni di ripristino rapide, ad esempio ripristino di righe mancanti in indici non cluster, nonché operazioni che richiedono una maggiore quantità di tempo, come la ricompilazione di un indice.

Questo argomento non consente di correggere errori relativi ai dati FILESTREAM.

Importante

Poiché DBCC CHECKDB con una qualsiasi delle opzioni REPAIR sono completamente registrati e recuperabili, Microsoft consiglia sempre l'uso DBCC CHECKDB di un utente con qualsiasi opzione REPAIR all'interno di una transazione (eseguita BEGIN TRANSACTION prima di eseguire il comando) in modo che l'utente possa confermare che vogliono accettare i risultati dell'operazione. L'utente può quindi eseguire COMMIT TRANSACTION per eseguire il commit di tutto il lavoro eseguito dall'operazione di ripristino. Se l'utente non vuole accettare i risultati dell'operazione, può eseguire un ROLLBACK TRANSACTION oggetto per annullare gli effetti delle operazioni di ripristino.

Per correggere gli errori, è consigliabile eseguire un ripristino da un backup. Le operazioni di correzione non tengono conto degli eventuali vincoli esistenti per le tabelle o tra le tabelle. Se la tabella specificata è interessata da uno o più vincoli, è consigliabile eseguire DBCC CHECKCONSTRAINTS dopo l'operazione di correzione. Se è necessario usare REPAIR, eseguire DBCC CHECKDB senza opzioni di correzione per individuare il livello di correzione da applicare. Se si usa il livello, è consigliabile eseguire il backup del REPAIR_ALLOW_DATA_LOSS database prima di eseguire DBCC CHECKDB questa opzione.

ALL_ERRORMSGS

Visualizza tutti gli errori segnalati per oggetto. Tutti i messaggi di errore vengono visualizzati per impostazione predefinita. La specifica o l'omissione di questa opzione non ha alcun effetto. I messaggi di errore vengono ordinati in base all'ID oggetto, ad eccezione dei messaggi generati dal database tempdb.

EXTENDED_LOGICAL_CHECKS

Se il livello di compatibilità è 100, introdotto in SQL Server 2008 (10.0.x), questa opzione esegue controlli di coerenza logica su una visualizzazione indicizzata, gli indici XML e gli indici spaziali, dove presente.

Per altre informazioni, vedere Eseguire controlli di coerenza logica sugli indici più avanti in questo articolo.

NO_INFOMSGS

Disattiva tutti i messaggi informativi.

TABLOCK

DBCC CHECKDB Causa l'acquisizione di blocchi anziché l'uso di uno snapshot interno del database. incluso un blocco esclusivo (X) sul database di breve durata. TABLOCK causerà DBCC CHECKDB l'esecuzione più veloce in un database con carico elevato, ma ridurrà la concorrenza disponibile nel database durante DBCC CHECKDB l'esecuzione.

Importante

TABLOCK limita i controlli eseguiti; DBCC CHECKCATALOG non viene eseguito nel database e i dati di Service Broker non vengono convalidati.

ESTIMATEONLY

Visualizza la quantità stimata di tempdb spazio necessaria per l'esecuzione DBCC CHECKDB con tutte le altre opzioni specificate. Il controllo effettivo del database non viene eseguito.

PHYSICAL_ONLY

Limita il controllo di integrità alla struttura fisica della pagina, alle intestazioni dei record e alla consistenza di allocazione del database. Sebbene sia progettato per consentire un controllo a basso overhead della consistenza fisica del database, questo controllo consente inoltre di rilevare le pagine incomplete, gli errori di checksum e i comuni problemi a livello di hardware che possono compromettere i dati di un utente.

Un'esecuzione completa di DBCC CHECKDB può richiedere molto più tempo rispetto alle versioni precedenti. per i seguenti motivi:

I controlli logici sono più completi.
Alcune delle strutture sottostanti da controllare sono più complesse.
Sono stati introdotti molti nuovi controlli per includere le nuove funzionalità.

Pertanto, l'uso dell'opzione PHYSICAL_ONLY può causare un'esecuzione molto più breve per DBCC CHECKDB i database di grandi dimensioni ed è consigliato per l'uso frequente nei sistemi di produzione. È comunque consigliabile eseguire periodicamente un'esecuzione DBCC CHECKDB completa. La frequenza di esecuzione dipende da fattori specifici per i singoli ambienti aziendali e di produzione.

Questo argomento implica NO_INFOMSGS sempre e non è consentito con una delle opzioni di ripristino.

Avviso

Specificando PHYSICAL_ONLY le DBCC CHECKDB cause di ignorare tutti i controlli dei dati FILESTREAM.

DATA_PURITY

DBCC CHECKDB Causa il controllo del database per i valori di colonna non validi o non compresi nell'intervallo. Ad esempio, DBCC CHECKDB rileva colonne con valori di data e ora maggiori o inferiori all'intervallo accettabile per il tipo di dati datetime o decimale o numerico approssimativo con valori di scala o precisione non validi.

I controlli di integrità dei valori di colonna sono abilitati per impostazione predefinita e non richiedono l'opzione DATA_PURITY . Per i database aggiornati dalle versioni precedenti di SQL Server, i controlli del valore della colonna non sono abilitati per impostazione predefinita fino a quando DBCC CHECKDB WITH DATA_PURITY non è stato eseguito un errore libero nel database. A questo punto, DBCC CHECKDB controlla l'integrità dei valori di colonna per impostazione predefinita. Per altre informazioni su come CHECKDB potrebbe essere interessato dall'aggiornamento del database da versioni precedenti di SQL Server, vedere la sezione Osservazioni più avanti in questo articolo.

Avviso

Se PHYSICAL_ONLY specificato, i controlli di integrità della colonna non vengono eseguiti.

Gli errori di convalida segnalati da questa opzione non possono essere risolti usando le opzioni di ripristino DBCC. Per informazioni sulla correzione manuale di questi errori, vedere l'articolo 923247 della Knowledge Base: Risoluzione dell'errore DBCC 2570 in SQL Server 2005 e versioni successive.

MAXDOP

Si applica a: SQL Server 2014 (12.x) Service Pack 2 e versioni successive

Esegue l'override dell'opzione di configurazione max degree of parallelism di sp_configure per l'istruzione. Il MAXDOP valore può superare il valore configurato con sp_configure. Se MAXDOP supera il valore configurato con Resource Governor, il motore di database SQL Server usa il valore Resource Governor MAXDOP descritto in ALTER WORKLOAD GROUP. Tutte le regole semantiche usate con l'opzione di configurazione max degree of parallelism sono applicabili quando si usa l'hint MAXDOP di query. Per altre informazioni, vedere Configurare l'opzione di configurazione del server max degree of parallelism.

Avviso

Se MAXDOP è impostato su zero, SQL Server sceglie il grado massimo di parallelismo da usare.

Commenti

DBCC CHECKDB non esamina gli indici disabilitati. Per altre informazioni sugli indici disabilitati, vedere Disabilitare indici e vincoli.

Se un tipo definito dall'utente (UDT) viene contrassegnato come ordinato per byte, è necessario che sia presente un'unica serializzazione di tale tipo. Non avere una serializzazione coerente di tipi definiti dall'utente ordinati per byte causa l'errore 2537 quando DBCC CHECKDB viene eseguito. Per altre informazioni, vedere Creazione di tipi definiti dall'utente - requisiti.

Poiché il database di risorse è modificabile solo in modalità utente singolo, il DBCC CHECKDB comando non può essere eseguito direttamente. Tuttavia, quando DBCC CHECKDB viene eseguito nel database master, un secondo CHECKDB viene eseguito internamente nel database di risorse. Ciò significa che DBCC CHECKDB può restituire risultati aggiuntivi. Il comando restituisce ulteriori set di risultati quando non si imposta alcuna opzione o quando si imposta l'opzione PHYSICAL_ONLY o ESTIMATEONLY.

A partire da SQL Server 2005 (9.x) Service Pack 2, l'esecuzione DBCC CHECKDB non cancella più la cache dei piani per l'istanza di SQL Server. Prima di SQL Server 2005 (9.x) Service Pack 2, l'esecuzione DBCC CHECKDB cancella la cache del piano. La cancellazione della cache dei piani comporta la ricompilazione di tutti i piani di esecuzione successivi e può causare un improvviso temporaneo peggioramento delle prestazioni di esecuzione delle query.

Eseguire controlli di coerenza logica sugli indici

I controlli di consistenza logica negli indici variano in base al livello di compatibilità del database, come indicato di seguito:

Se il livello di compatibilità è almeno 100 (introdotto in SQL Server 2008 (10.0.x)):
A meno che NOINDEX non sia specificato, DBCC CHECKDB esegue controlli di coerenza fisica e logica su una singola tabella e su tutti gli indici non cluster. Per impostazione predefinita, tuttavia, negli indici XML, negli indici spaziali e nelle viste indicizzate vengono eseguiti solo controlli di consistenza fisica.
Se viene specificato WITH EXTENDED_LOGICAL_CHECKS, vengono eseguiti controlli logici su viste indicizzate, indici XML e indici spaziali, laddove presenti. Per impostazione predefinita, i controlli di consistenza fisica vengono eseguiti prima di quelli di consistenza logica. Se viene specificato anche NOINDEX, vengono eseguiti solo i controlli logici.

Tramite questi controlli di consistenza logica vengono eseguiti controlli incrociati della tabella degli indici interna dell'oggetto Index con la tabella utente a cui viene fatto riferimento. Per trovare le righe esterne, viene creata una query interna per eseguire un'intersezione completa della tabella interna e della tabella utente. L'esecuzione di questa query può avere un effetto significativo sulle prestazioni e lo stato di avanzamento non può essere monitorato. È pertanto consigliabile specificareWITH EXTENDED_LOGICAL_CHECKS solo se si sospetta la presenza di problemi dell'indice non correlati a danni fisici o se i checksum a livello di pagina sono stati disabilitati e si sospetta la presenza di danni hardware a livello di colonna.

Se l'indice è un indice filtrato, DBCC CHECKDB esegue controlli di coerenza per verificare che le voci di indice soddisfino il predicato di filtro.
Se il livello di compatibilità è 90 o minore, a meno NOINDEX che non sia specificato, DBCC CHECKDB esegue controlli di coerenza fisica e logica su una singola tabella o vista indicizzata e su tutti gli indici non cluster e XML. Gli indici spaziali non sono supportati.
A partire da SQL Server 2016 (13.x), i controlli aggiuntivi sulle colonne calcolate persistenti, le colonne UDT e gli indici filtrati non verranno eseguiti per impostazione predefinita per evitare le valutazioni delle espressioni costose. Questa modifica riduce notevolmente la durata di CHECKDB rispetto ai database contenenti questi oggetti. Tuttavia, la verifica di coerenza fisica di questi oggetti viene sempre completata. Solo quando EXTENDED_LOGICAL_CHECKS viene specificata l'opzione, le valutazioni dell'espressione vengono eseguite, oltre ai controlli logici già presenti come parte dell'opzione EXTENDED_LOGICAL_CHECKS (visualizzazione indicizzata, indici XML e indici spaziali).

Per informazioni sul livello di compatibilità di un database

Visualizzare o modificare il livello di compatibilità di un database

Snapshot interno del database

DBCC CHECKDB usa uno snapshot interno del database per la coerenza transazionale necessaria per eseguire questi controlli. Ciò consente di evitare problemi di blocco e concorrenza durante l'esecuzione di questi comandi. Per altre informazioni, vedere Visualizzare le dimensioni del file sparse di uno snapshot del database (Transact-SQL) e la sezione "Utilizzo dello snapshot interno del database DBCC" in DBCC (Transact-SQL). Se non è possibile creare uno snapshot o TABLOCK viene specificato, DBCC CHECKDB acquisisce i blocchi per ottenere la coerenza necessaria. In questo caso, è necessario un blocco esclusivo a livello di database per eseguire i controlli di allocazione, nonché blocchi condivisi a livello di tabella per eseguire i controlli delle tabelle.

DBCC CHECKDB non riesce quando viene eseguito sul database se non è possibile creare uno snapshot interno del master database.

L'esecuzione DBCC CHECKDB su tempdb non esegue controlli di allocazione o catalogo e deve acquisire blocchi di tabella condivisi per eseguire controlli di tabella. Questo perché, per motivi di prestazioni, gli snapshot del database non sono disponibili in tempdb. Ciò significa che la coerenza transazionale necessaria non può essere ottenuta.

Come DBCC CHECKDB crea un database snapshot interno a partire da SQL Server 2014

DBCC CHECKDB crea un database snapshot interno.
Il database snapshot interno viene creato usando file fisici. Ad esempio, per un database con database_id = 10 tre file E:\Data\my_DB.mdf, E:\Data\my_DB.ndfe E:\Data\my_DB.ldf, verrà creato il database snapshot interno usando E:\Data\my_DB.mdf_MSSQL_DBCC11 e E:\Data\my_DB.ndf_MSSQL_DBCC11 file. L'oggetto database_id dello snapshot è database_id + 1. Si noti anche che i nuovi file vengono creati nella stessa cartella usando la convenzione <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>di denominazione . Non viene creato alcun file sparse per il log delle transazioni.
I nuovi file sono contrassegnati come file sparse a livello di file system. Le dimensioni sul disco usate dai nuovi file aumentano in base alla quantità di dati aggiornati nel database di origine durante il DBCC CHECKDB comando. Le dimensioni dei nuovi file saranno lo stesso file del .mdf file o.ndf.
I nuovi file vengono eliminati alla fine dell'elaborazione DBCC CHECKDB . Questi file sparse creati da DBCC CHECKDB hanno gli attributi "Delete on Close" impostati.

Avviso

Se il sistema operativo rileva un arresto imprevisto mentre il DBCC CHECKDB comando è in corso, questi file non verranno puliti. Gli spazi saranno necessari e possono potenzialmente causare errori nelle esecuzioni future DBCC CHECKDB . In questo caso, è possibile eliminare questi nuovi file dopo aver confermato che non DBCC CHECKDB è attualmente stato eseguito alcun comando.

I nuovi file sono visibili usando le normali utilità per i file, ad esempio Esplora risorse.

Nota

Prima di SQL Server 2014 (12.x), i flussi di file denominati sono stati usati invece per creare i file snapshot interni. I flussi di file denominati utilizzano il formato <filename.extension>:MSSQL_DBCC database_id_of_snapshot<>. I flussi di file denominati non sono visibili usando le normali utilità per i file, ad esempio Esplora risorse. Pertanto, in SQL Server 2012 (11.x) e versioni precedenti, potrebbero verificarsi messaggi di errore 7926 e 5030 quando si esegue il DBCC CHECKDB comando per i file di database che si trovano in un volume formattato reFS. Questo è dovuto al fatto che i flussi di file non possono essere creati in Resilient File System (RefS).

Controllare e ripristinare i dati FILESTREAM

Quando FILESTREAM è abilitato per un database e una tabella, è possibile, facoltativamente, archiviare oggetti binari di grandi dimensioni (BLOB) varbinary(max) nel file system. Quando si usa DBCC CHECKDB in un database che archivia i BLOB nel file system, DBCC controlla la coerenza a livello di collegamento tra il file system e il database.

Ad esempio, se una tabella contiene una colonna varbinary(max) che usa l'attributo FILESTREAM, DBCC CHECKDB verificherà che sia presente un mapping uno-a-uno tra directory del file system e file e righe di tabella, colonne e valori di colonna. DBCC CHECKDB può ripristinare il danneggiamento se si specifica l'opzione REPAIR_ALLOW_DATA_LOSS . Per ripristinare il danneggiamento di FILESTREAM, DBCC consentirà di eliminare qualsiasi riga della tabella in cui mancano i dati del file system.

Procedure consigliate

È consigliabile usare l'opzione PHYSICAL_ONLY per l'uso frequente nei sistemi di produzione, L'uso PHYSICAL_ONLY può ridurre notevolmente il runtime per DBCC CHECKDB i database di grandi dimensioni. È anche consigliabile eseguire DBCC CHECKDB periodicamente senza opzioni. La frequenza consigliata di esecuzione varia a seconda delle singole aziende e dei relativi ambienti di produzione.

Controllare gli oggetti in parallelo

Per impostazione predefinita, DBCC CHECKDB esegue il controllo parallelo degli oggetti. Il grado di parallelismo viene determinato in modo automatico da Query Processor. Il livello massimo di parallelismo viene configurato allo stesso modo delle query parallele. Per limitare il numero massimo di processori disponibili per la verifica DBCC, usare sp_configure. Per altre informazioni, vedere Configurare l'opzione di configurazione del server max degree of parallelism. Il controllo parallelo può essere disabilitato usando il flag di traccia 2528. Per altre informazioni, vedere Flag di traccia (Transact-SQL).

Nota

Questa funzionalità non è disponibile in ogni edizione di SQL Server. Per altre informazioni, vedere Verifica della coerenza parallela nella sezione Gestibilità RDBMS delle edizioni e delle funzionalità supportate di SQL Server 2022.

Informazioni sui messaggi di errore DBCC

Al termine del DBCC CHECKDB comando, viene scritto un messaggio nel log degli errori SQL Server. Se l'esecuzione del comando DBCC ha esito positivo, il messaggio segnala che il completamento è avvenuto correttamente e indica la durata di esecuzione del comando. Se il comando DBCC viene arrestato prima del completamento del controllo a causa di un errore, il messaggio indica che il comando è stato terminato e specifica un valore di stato e la durata dell'esecuzione del comando. Nella tabella seguente sono elencati e descritti i valori di stato che possono essere inclusi nel messaggio.

State	Descrizione
0	È stato generato l'errore numero 8930. Indica un danneggiamento dei metadati che ha causato l'interruzione del comando DBCC.
1	È stato generato l'errore numero 8967. Si è verificato un errore DBCC interno.
2	Si è verificato un errore durante un ripristino di database in modalità di emergenza.
3	Indica un danneggiamento dei metadati che ha causato l'interruzione del comando DBCC.
4	È stata rilevata una violazione di accesso o asserzione.
5	il comando DBCC è stato terminato da un errore sconosciuto.

Nota

SQL Server registra la data e l'ora in cui è stata eseguita una verifica di coerenza per un database senza errori (o la verifica di coerenza di pulizia). Questo concetto è noto come last known clean check. Quando un database viene avviato per la prima volta, questa data viene scritta nel Log eventi (EventID-17573) e nel log degli errori nel formato seguente:

CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

Errore di segnalazione

Un file di dump (SQLDUMP<nnnn>.txt) viene creato nella directory SQL Server LOG ogni volta che DBCC CHECKDB rileva un errore di danneggiamento. Se le funzionalità di segnalazione degli errori e di raccolta di dati relativi all'utilizzo delle funzionalità sono abilitate per l'istanza di SQL Server, il file verrà inoltrato automaticamente a Microsoft. I dati raccolti vengono usati per migliorare le funzionalità di SQL Server. Il file dump contiene i risultati del comando e l'output DBCC CHECKDB di diagnostica aggiuntivo. L'accesso è limitato all'account del servizio SQL Server e ai membri del ruolo sysadmin. Per impostazione predefinita il ruolo sysadmin contiene tutti i membri del gruppo BUILTIN\Administrators di Windows e del gruppo dell'amministratore locale. Se il processo di raccolta dati ha esito negativo, il comando DBCC non riesce.

Risolvere gli errori

Se vengono segnalati errori da DBCC CHECKDB, è consigliabile ripristinare il database dal backup del database anziché eseguire REPAIR con una delle opzioni REPAIR. Se non esistono backup, l'esecuzione di REPAIR corregge gli errori rilevati. L'opzione REPAIR da utilizzare è specificata al termine dell'elenco degli errori rilevati. Tuttavia, la correzione degli errori tramite l'opzione REPAIR_ALLOW_DATA_LOSS potrebbe richiedere l'eliminazione di alcune pagine e quindi alcuni dati.

In alcune circostanze, i valori potrebbero essere immessi nel database che non sono validi o non compresi nell'intervallo in base al tipo di dati della colonna. DBCC CHECKDB è in grado di rilevare i valori di colonna non validi per tutti i tipi di dati della colonna. Pertanto, l'esecuzione DBCC CHECKDB con l'opzione DATA_PURITY nei database aggiornati da versioni precedenti di SQL Server potrebbe rivelare errori preesistenti di valori di colonna. Poiché SQL Server non è in grado di correggere automaticamente questi errori, il valore della colonna deve essere aggiornato manualmente. Se CHECKDB rileva un errore di questo tipo, CHECKDB restituisce un avviso, il numero di errore 2570 e le informazioni per identificare la riga interessata e correggere manualmente l'errore.

È possibile eseguire l'operazione di correzione tramite una transazione utente che consente il rollback delle modifiche apportate. Se si esegue il rollback delle correzioni, il database include ancora errori e deve essere ripristinato da un backup. Dopo il completamento delle correzioni, eseguire il backup del database.

Risolvere gli errori in modalità di emergenza del database

Quando un database è stato impostato sulla modalità di emergenza tramite l'istruzione ALTER DATABASE , DBCC CHECKDB può eseguire alcune riparazioni speciali nel database se l'opzione REPAIR_ALLOW_DATA_LOSS è specificata. Grazie a queste correzioni è possibile riportare online database altrimenti irrecuperabili in uno stato consistente dal punto di vista fisico. Queste riparazioni devono essere usate come ultima risorsa e solo quando non è possibile ripristinare il database da un backup. Se si imposta la modalità di emergenza, il database viene contrassegnato come READ_ONLY, la registrazione è disabilitata e l'accesso è consentito ai soli membri del ruolo predefinito del server sysadmin.

Nota

Non è possibile eseguire il DBCC CHECKDB comando in modalità di emergenza all'interno di una transazione utente ed eseguire il rollback della transazione dopo l'esecuzione.

Quando il database è in modalità di emergenza e DBCC CHECKDB con la REPAIR_ALLOW_DATA_LOSS clausola viene eseguita, vengono eseguite le azioni seguenti:

DBCC CHECKDB utilizza le pagine contrassegnate come inaccessibili a causa di errori di I/O o checksum, come se gli errori non si siano verificati. Questa azione consente di aumentare le possibilità di recupero dei dati del database.
DBCC CHECKDB tenta di ripristinare il database usando le normali tecniche di recupero basate su log.
Se il ripristino del database non riesce a causa del danneggiamento del log delle transazioni, il log delle transazioni viene ricompilato. Tale ricompilazione può provocare la perdita di consistenza delle transazioni.

Avviso

L'opzione REPAIR_ALLOW_DATA_LOSS è una funzionalità supportata di SQL Server. Tuttavia, non sempre può rappresentare l'opzione migliore per portare un database in uno stato coerente dal punto di vista fisico. In caso di esito positivo, l'opzione REPAIR_ALLOW_DATA_LOSS può comportare una perdita di dati. Infatti, può comportare una perdita maggiore di dati rispetto al ripristino del database dall'ultimo backup valido. Microsoft consiglia sempre un ripristino dell'utente dall'ultimo backup valido noto come metodo primario per il ripristino da errori segnalati da DBCC CHECKDB. L'opzione REPAIR_ALLOW_DATA_LOSSnon è un'alternativa per il ripristino da un backup valido noto. Si tratta di un'opzione di ultima risorsa di emergenza consigliata per l'uso solo se il ripristino da un backup non è possibile.

Dopo la ricompilazione del log non ci sarà alcuna garanzia ACID completa.

Dopo la ricompilazione del log, DBCC CHECKDB verranno eseguiti automaticamente e verranno segnalare e correggere i problemi di coerenza fisica.

I vincoli applicati alla coerenza dei dati logici e alla logica di business devono essere convalidati manualmente.

Le dimensioni del log delle transazioni rimarranno quelle predefinite e dovranno essere modificate manualmente impostando le dimensioni recenti.

Se il DBCC CHECKDB comando ha esito positivo, il database si trova in uno stato fisicamente coerente e lo stato del database è impostato su ONLINE. È tuttavia possibile che il database contenga una o più inconsistenze delle transazioni. È consigliabile eseguire DBCC CHECKCONSTRAINTS per identificare eventuali difetti della logica di business ed eseguire immediatamente il backup del database. Se il DBCC CHECKDB comando non riesce, il database non può essere ripristinato.

Eseguire DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS nei database replicati

L'esecuzione del DBCC CHECKDB comando con l'opzione REPAIR_ALLOW_DATA_LOSS può influire sui database utente (database di pubblicazione e sottoscrizione) e sul database di distribuzione usato dalla replica. Nei database di pubblicazione e di sottoscrizione sono incluse le tabelle pubblicate e le tabelle di metadati della replica. Per questi database è necessario tenere in considerazione i possibili problemi seguenti:

Tabelle pubblicate. Le azioni eseguite dal CHECKDB processo per ripristinare i dati utente danneggiati potrebbero non essere replicate:
La replica di tipo merge utilizza i trigger per tenere traccia delle modifiche apportate alle tabelle pubblicate. Se le righe vengono inserite, aggiornate o eliminate dal CHECKDB processo, i trigger non vengono attivati, pertanto la modifica non viene replicata.
La replica transazionale utilizza il log delle transazioni per tenere traccia delle modifiche apportate alle tabelle pubblicate. L'agente di lettura log sposta quindi tali modifiche nel database di distribuzione. Alcune riparazioni DBCC, anche se registrate, non possono essere replicate dall'agente di lettura log. Ad esempio, se una pagina dati viene deallocata dal CHECKDB processo, l'agente di lettura log non converte questa deallocazione in un'istruzione DELETE, pertanto la modifica non viene replicata.
Tabelle di metadati della replica. Le azioni eseguite dal CHECKDB processo per ripristinare le tabelle dei metadati di replica danneggiate richiedono la rimozione e la riconfigurazione della replica.

Se è necessario eseguire il DBCC CHECKDB comando con l'opzione REPAIR_ALLOW_DATA_LOSS in un database utente o in un database di distribuzione:

Mettere in stato di inattività il sistema: arrestare l'attività sul database e su qualsiasi altro database incluso nella topologia di replica, quindi provare a sincronizzare tutti i nodi. Per altre informazioni, vedere Come mettere una topologia di replica in stato di inattività (programmazione Transact-SQL della replica).
Eseguire DBCC CHECKDB.
Se il DBCC CHECKDB report include riparazioni per eventuali tabelle nel database di distribuzione o in qualsiasi tabella dei metadati di replica in un database utente, rimuovere e riconfigurare la replica. Per altre informazioni, vedere Disabilitare la pubblicazione e la distribuzione.
Se il DBCC CHECKDB report include riparazioni per le tabelle replicate, eseguire la convalida dei dati per determinare se esistono differenze tra i dati nei database di pubblicazione e di sottoscrizione.

Set di risultati

DBCC CHECKDB restituisce il set di risultati seguente. I valori possono variare tranne quando vengono specificate le ESTIMATEONLYopzioni , PHYSICAL_ONLYo NO_INFOMSGS:

 DBCC results for 'model'.
    
 Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.
    
 Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.
    
 Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.
    
 Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.
    
 Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.
    
 Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.
    
 Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.
    
 DBCC results for 'sys.sysrowsetcolumns'.
    
 There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.
    
 DBCC results for 'sys.sysrowsets'.
    
 There are 97 rows in 1 pages for object 'sys.sysrowsets'.
    
 DBCC results for 'sysallocunits'.
    
 There are 195 rows in 3 pages for object 'sysallocunits'.
    
 There are 0 rows in 0 pages for object "sys.sysasymkeys".
    
 DBCC results for 'sys.syssqlguides'.
    
 There are 0 rows in 0 pages for object "sys.syssqlguides".
    
 DBCC results for 'sys.queue_messages_1977058079'.
    
 There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".
    
 DBCC results for 'sys.queue_messages_2009058193'.
    
 There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".
    
 DBCC results for 'sys.queue_messages_2041058307'.
    
 There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".
    
 CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.
    
 DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB restituisce il set di risultati seguente (messaggio) quando NO_INFOMSGS viene specificato:

 The command(s) completed successfully.

DBCC CHECKDB restituisce il set di risultati seguente quando PHYSICAL_ONLY viene specificato:

 DBCC results for 'model'.
    
 CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.
    
 DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB restituisce il set di risultati seguente quando ESTIMATEONLY viene specificato.

 Estimated TEMPDB space needed for CHECKALLOC (KB)
    
 -------------------------------------------------
    
 13
    
 (1 row(s) affected)
    
 Estimated TEMPDB space needed for CHECKTABLES (KB)
    
 --------------------------------------------------
    
 57
    
 (1 row(s) affected)
    
 DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Autorizzazioni

È richiesta l'appartenenza al ruolo predefinito del server sysadmin o al ruolo predefinito del database db_owner.

Esempi

R. Controllare sia l'attuale che un altro database

Nell'esempio seguente viene eseguito DBCC CHECKDB per il database corrente e per il database AdventureWorks2022.

-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks2022 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2022, NOINDEX);
GO

B. Controllare il database corrente, eliminando i messaggi informativi

Nell'esempio seguente viene verificato il database corrente e vengono soppressi tutti i messaggi informativi.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

DBCC CHECKDB (Transact-SQL)

Sintassi

Argomenti

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Commenti

Eseguire controlli di coerenza logica sugli indici

Per informazioni sul livello di compatibilità di un database

Snapshot interno del database

Come DBCC CHECKDB crea un database snapshot interno a partire da SQL Server 2014

Controllare e ripristinare i dati FILESTREAM

Procedure consigliate

Controllare gli oggetti in parallelo

Informazioni sui messaggi di errore DBCC

Errore di segnalazione

Risolvere gli errori

Risolvere gli errori in modalità di emergenza del database

Eseguire DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS nei database replicati

Set di risultati

Autorizzazioni

Esempi

R. Controllare sia l'attuale che un altro database

B. Controllare il database corrente, eliminando i messaggi informativi

Vedi anche

Commenti e suggerimenti

Commenti e suggerimenti

Risorse aggiuntive