DBCC CHECKDB (Transact-SQL)

• 12/14/2017
• 22 minuti per leggere
• • p
  • M
  • m
  • M
  • P
  • +3

Si applica a: SQL Server (tutte le versioni supportate) Azure SQL Database

Controlla l’integrità logica e fisica di tutti gli oggetti nel database specificato eseguendo le seguenti operazioni:

• Esegue DBCC CHECKALLOC sul database.
• Esegue DBCC CHECKTABLE su ogni tabella e vista nel database.
• Esegue DBCC CHECKCATALOG sul database.
• Valida il contenuto di ogni vista indicizzata nel database.
• Valida la coerenza a livello di link tra i metadati delle tabelle e le directory e i file del file system quando si memorizzano dati varbinary(max) nel file system usando FILESTREAM.
• Valida i dati del Service Broker nel database.

Questo significa che i comandi DBCC CHECKALLOC, DBCC CHECKTABLE, o DBCC CHECKCATALOG non devono essere eseguiti separatamente da DBCC CHECKDB. Per informazioni più dettagliate sui controlli che questi comandi eseguono, vedere le descrizioni di questi comandi.

Convenzioni sulla sintassi Transact-SQL

Sintassi

DBCC CHECKDB ) ] } ] ] 

Argomenti

nome_database | database_id | 0
È il nome o l’ID del database per cui eseguire i controlli di integrità. Se non specificato, o se viene specificato 0, viene usato il database corrente. I nomi dei database devono essere conformi alle regole per gli identificatori.

NOINDEX
Specifica che i controlli intensivi degli indici non raggruppati per le tabelle utente non dovrebbero essere eseguiti. Questo diminuisce il tempo complessivo di esecuzione. NOINDEX non ha effetto sulle tabelle di sistema perché i controlli di integrità sono sempre eseguiti sugli indici delle tabelle di sistema.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Specifica che DBCC CHECKDB ripara gli errori trovati. Usa le opzioni REPAIR solo come ultima risorsa. Il database specificato deve essere in modalità utente singolo per usare una delle seguenti opzioni di riparazione.

REPAIR_ALLOW_DATA_LOSS
Tenta di riparare tutti gli errori riportati. Queste riparazioni possono causare alcune perdite di dati.

REPAIR_FAST
Mantiene la sintassi solo per compatibilità all’indietro. Non vengono eseguite azioni di riparazione.

REPAIR_REBUILD
Esegue riparazioni che non hanno possibilità di perdita di dati. Questo può includere riparazioni veloci, come la riparazione di righe mancanti in indici non raggruppati, e riparazioni che richiedono più tempo, come la ricostruzione di un indice.
Questo argomento non ripara errori che coinvolgono dati FILESTREAM.

ALL_ERRORMSGS
Visualizza tutti gli errori riportati per oggetto. Tutti i messaggi di errore sono visualizzati per impostazione predefinita. Specificare o omettere questa opzione non ha alcun effetto. I messaggi di errore sono ordinati per ID dell’oggetto, eccetto per i messaggi generati dal database tempdb.

EXTENDED_LOGICAL_CHECKS
Se il livello di compatibilità è 100 (SQL Server 2008) o superiore, esegue controlli di coerenza logica su una vista indicizzata, indici XML e indici spaziali, se presenti.
Per maggiori informazioni, vedere Esecuzione dei controlli di coerenza logica sugli indici, nella sezione Osservazioni più avanti in questo argomento.

NO_INFOMSGS
Sospende tutti i messaggi informativi.

TABLOCK
Fa sì che DBCC CHECKDB ottenga i lock invece di usare uno snapshot interno del database. Questo include un blocco esclusivo (X) a breve termine sul database. TABLOCK farà sì che DBCC CHECKDB venga eseguito più velocemente su un database sotto forte carico, ma diminuisce la concorrenza disponibile sul database mentre DBCC CHECKDB è in esecuzione.

ESTIMATEONLY
Visualizza la quantità stimata di spazio tempdb che è necessaria per eseguire DBCC CHECKDB con tutte le altre opzioni specificate. Il controllo effettivo del database non viene eseguito.

PHYSICAL_ONLY
Limita il controllo all’integrità della struttura fisica delle intestazioni delle pagine e dei record e alla coerenza dell’allocazione del database. Questo controllo è progettato per fornire una piccola verifica della consistenza fisica del database, ma può anche rilevare pagine strappate, errori di checksum, e comuni guasti hardware che possono compromettere i dati di un utente.
Un’esecuzione completa di DBCC CHECKDB può richiedere molto più tempo per essere completata rispetto alle versioni precedenti. Questo comportamento si verifica perché:

• I controlli logici sono più completi.
• Alcune delle strutture sottostanti da controllare sono più complesse.
• Molti nuovi controlli sono stati introdotti per includere le nuove funzionalità.
  Pertanto, usare l’opzione PHYSICAL_ONLY può causare un tempo di esecuzione molto più breve per DBCC CHECKDB su grandi database ed è consigliato per un uso frequente su sistemi di produzione. Si raccomanda comunque di eseguire periodicamente un’esecuzione completa di DBCC CHECKDB. La frequenza di queste esecuzioni dipende da fattori specifici delle singole aziende e degli ambienti di produzione.
  Questo argomento implica sempre NO_INFOMSGS e non è consentito con nessuna delle opzioni di riparazione.

DATA_PURITY
Fa sì che DBCC CHECKDB controlli il database per valori di colonna che non sono validi o fuori range. Per esempio, DBCC CHECKDB rileva le colonne con valori di data e ora che sono più grandi o meno dell’intervallo accettabile per il tipo di dati datetime; o colonne di tipo decimale o approssimativo-numerico con valori di scala o precisione che non sono validi.
I controlli di integrità dei valori di colonna sono abilitati per default e non richiedono l’opzione DATA_PURITY. Per i database aggiornati da versioni precedenti di SQL Server, i controlli sul valore delle colonne non sono abilitati di default finché DBCC CHECKDB WITH DATA_PURITY non è stato eseguito senza errori sul database. Dopo questo, DBCC CHECKDB controlla l’integrità del valore delle colonne per default. Per maggiori informazioni su come CHECKDB potrebbe essere influenzato dall’aggiornamento del database da versioni precedenti di SQL Server, vedi la sezione Osservazioni più avanti in questo argomento.

Gli errori di validazione riportati da questa opzione non possono essere corretti usando le opzioni di riparazione DBCC. Per informazioni sulla correzione manuale di questi errori, vedere l’articolo 923247 della Knowledge Base: Troubleshooting DBCC error 2570 in SQL Server 2005 e versioni successive.

MAXDOP
Applica a: SQL Server ( SQL Server 2014 (12.x) SP2 e successivi).

Sovrascrive l’opzione di configurazione del grado massimo di parallelismo di sp_configure per la dichiarazione. Il MAXDOP può superare il valore configurato con sp_configure. Se MAXDOP supera il valore configurato con Resource Governor, il SQL Server Database Engine usa il valore MAXDOP di Resource Governor, descritto in ALTER WORKLOAD GROUP. Tutte le regole semantiche usate con l’opzione di configurazione del grado massimo di parallelismo sono applicabili quando si usa il suggerimento di query MAXDOP. Per maggiori informazioni, vedi Configurare l’opzione di configurazione del server sul grado massimo di parallelismo.

Remarks

DBCC CHECKDB non esamina gli indici disabilitati. Per maggiori informazioni sugli indici disabilitati, vedi Disabilitare indici e vincoli.

Se un tipo definito dall’utente è contrassegnato come ordinato in byte, ci deve essere solo una serializzazione del tipo definito dall’utente. Non avere una serializzazione coerente dei tipi definiti dall’utente ordinati per byte causa l’errore 2537 quando viene eseguito DBCC CHECKDB. Per maggiori informazioni, vedere Requisiti dei tipi definiti dall’utente.

Perché il database Resource è modificabile solo in modalità utente singolo, il comando DBCC CHECKDB non può essere eseguito direttamente su di esso. Tuttavia, quando DBCC CHECKDB viene eseguito contro il database principale, un secondo CHECKDB viene anche eseguito internamente sul database Resource. Questo significa che DBCC CHECKDB può restituire risultati extra. Il comando restituisce set di risultati extra quando non sono impostate opzioni o quando è impostata l’opzione PHYSICAL_ONLY o ESTIMATEONLY.

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

Eseguire i controlli di coerenza logica sugli indici

Il controllo di coerenza logica sugli indici varia a seconda del livello di compatibilità del database, come segue:

• Se il livello di compatibilità è 100 (SQL Server 2008) o superiore:
• A meno che non sia specificato NOINDEX, DBCC CHECKDB esegue entrambi i controlli di coerenza fisica e logica su una singola tabella e su tutti i suoi indici non raggruppati. Tuttavia, sugli indici XML, sugli indici spaziali e sulle viste indicizzate solo i controlli di coerenza fisica vengono eseguiti per default.
• Se WITH EXTENDED_LOGICAL_CHECKSè specificato, i controlli logici vengono eseguiti su una vista indicizzata, sugli indici XML e sugli indici spaziali, se presenti. Per impostazione predefinita, i controlli di coerenza fisica vengono eseguiti prima dei controlli di coerenza logica. Se viene specificato anche NOINDEX, vengono eseguiti solo i controlli logici.

Questi controlli logici di coerenza incrociano la tabella indice interna dell’oggetto indice con la tabella utente a cui fa riferimento. Per trovare le righe in eccesso, viene costruita una query interna per eseguire un’intersezione completa delle tabelle interna e utente. L’esecuzione di questa query può avere un effetto molto alto sulle prestazioni e il suo progresso non può essere monitorato. Pertanto, si consiglia di specificare WITH EXTENDED_LOGICAL_CHECKS solo se si sospettano problemi all’indice che non sono correlati alla corruzione fisica, o se i checksum a livello di pagina sono stati disattivati e si sospetta una corruzione hardware a livello di colonna.

• Se l’indice è un indice filtrato, DBCC CHECKDB esegue controlli di coerenza per verificare che le voci dell’indice soddisfino il predicato del filtro.
• Se il livello di compatibilità è 90 o meno, a meno che non sia specificato NOINDEX, DBCC CHECKDB esegue controlli di coerenza sia fisici che logici su una singola tabella o vista indicizzata e su tutti i suoi indici XML e non raggruppati. Gli indici spaziali non sono supportati.
• A partire da SQL Server 2016, i controlli aggiuntivi sulle colonne calcolate persistenti, sulle colonne UDT e sugli indici filtrati non verranno eseguiti per default per evitare le costose valutazioni delle espressioni. Questo cambiamento riduce notevolmente la durata di CHECKDB contro i database contenenti questi oggetti. Tuttavia, i controlli di coerenza fisica di questi oggetti sono sempre completati. Solo quando l’opzione EXTENDED_LOGICAL_CHECKS è specificata, le valutazioni delle espressioni saranno eseguite in aggiunta ai controlli logici già presenti (vista indicizzata, indici XML e indici spaziali) come parte dell’opzione EXTENDED_LOGICAL_CHECKS.

Per conoscere il livello di compatibilità di un database

• Visualizza o cambia il livello di compatibilità di un database

Internal Database Snapshot

DBCC CHECKDB usa uno snapshot del database interno per la consistenza transazionale necessaria per eseguire questi controlli. Questo previene problemi di blocco e di concorrenza quando questi comandi vengono eseguiti. Per maggiori informazioni, vedere Visualizzare la dimensione del file sparso di un’istantanea del database (Transact-SQL) e la sezione Utilizzo dell’istantanea interna del database DBCC in DBCC (Transact-SQL). Se un’istantanea non può essere creata, o viene specificato TABLOCK, DBCC CHECKDB acquisisce i lock per ottenere la coerenza richiesta. In questo caso, un blocco esclusivo del database è richiesto per eseguire i controlli di allocazione, e i blocchi condivisi delle tabelle sono richiesti per eseguire i controlli delle tabelle.DBCC CHECKDB fallisce quando viene eseguito contro il master se un’istantanea del database interno non può essere creata.L’esecuzione di DBCC CHECKDB contro tempdb non esegue alcun controllo di allocazione o catalogo e deve acquisire i blocchi condivisi delle tabelle per eseguire i controlli delle tabelle. Questo perché, per ragioni di prestazioni, gli snapshot del database non sono disponibili su tempdb. Questo significa che la consistenza transazionale richiesta non può essere ottenuta.In Microsoft SQL Server 2012 o in una versione precedente di SQL Server, è possibile incontrare messaggi di errore quando si esegue il comando DBCC CHECKDB per un database i cui file si trovano su un volume formattato ReFS. Per ulteriori informazioni, vedere l’articolo della Knowledge Base 2974455: Comportamento di DBCC CHECKDB quando il database di SQL Server si trova su un volume ReFS.

Controllo e riparazione dei dati FILESTREAM

Quando FILESTREAM è abilitato per un database e una tabella, è possibile memorizzare opzionalmente varbinary(max) binary large objects (BLOBs) nel file system. Quando si usa DBCC CHECKDB su un database che memorizza BLOB nel file system, DBCC controlla la coerenza a livello di collegamento tra il file system e il database, per esempio, se una tabella contiene una colonna varbinary(max) che usa l’attributo FILESTREAM, DBCC CHECKDB controlla che ci sia una mappatura uno-a-uno tra le directory e i file del file system e le righe della tabella, le colonne e i valori delle colonne. DBCC CHECKDB può riparare la corruzione se si specifica l’opzione REPAIR_ALLOW_DATA_LOSS. Per riparare la corruzione FILESTREAM, DBCC cancellerà tutte le righe di tabella che mancano di dati del file system.

Best Practices

Si raccomanda di usare l’opzione PHYSICAL_ONLY per un uso frequente sui sistemi di produzione. L’uso di PHYSICAL_ONLY può ridurre notevolmente il tempo di esecuzione di DBCC CHECKDB su grandi database. Si raccomanda inoltre di eseguire periodicamente DBCC CHECKDB senza opzioni. La frequenza con cui dovresti eseguire queste esecuzioni dipende dalle singole aziende e dai loro ambienti di produzione.

Controllo degli oggetti in parallelo

Di default, DBCC CHECKDB esegue il controllo in parallelo degli oggetti. Il grado di parallelismo è determinato automaticamente dal processore di query. Il grado massimo di parallelismo è configurato proprio come le query parallele. Per limitare il numero massimo di processori disponibili per il controllo DBCC, usare sp_configure. Per maggiori informazioni, vedere Configurare il grado massimo di parallelismo Opzione di configurazione del server. Il controllo parallelo può essere disabilitato usando il flag di tracciamento 2528. Per maggiori informazioni, vedi Trace Flags (Transact-SQL).

Comprensione dei messaggi di errore DBCC

Dopo che il comando DBCC CHECKDB finisce, viene scritto un messaggio nel log degli errori di SQL Server. Se il comando DBCC viene eseguito con successo, il messaggio indica il successo e il tempo di esecuzione del comando. Se il comando DBCC si ferma prima di completare il controllo a causa di un errore, il messaggio indica che il comando è stato terminato, un valore di stato e il tempo di esecuzione del comando. La seguente tabella elenca e descrive i valori di stato che possono essere inclusi nel messaggio.

State	Description
0	Errore numero 8930 è stato sollevato. Questo indica una corruzione nei metadati che ha terminato il comando DBCC.
1	Errore numero 8967 è stato sollevato. Si è verificato un errore interno del DBCC.
2	Si è verificato un errore durante la riparazione del database in modalità di emergenza.
3	Questo indica una corruzione nei metadati che ha terminato il comando DBCC.
4	È stato rilevato un asserto o una violazione di accesso.
5	Si è verificato un errore sconosciuto che ha terminato il comando DBCC.

Error Reporting

Un file dump (SQLDUMP*nnnn*.txt) viene creato nella directory SQL Server LOG ogni volta che DBCC CHECKDB rileva un errore di corruzione. Quando le funzioni di raccolta dati Feature Usage e Error Reporting sono abilitate per l’istanza di SQL Server, il file viene automaticamente inoltrato a Microsoft. I dati raccolti vengono utilizzati per migliorare la funzionalità di SQL Server. Il file di dump contiene i risultati del comando DBCC CHECKDB e ulteriori output diagnostici. L’accesso è limitato all’account di servizio di SQL Server e ai membri del ruolo sysadmin. Per impostazione predefinita, il ruolo sysadmin contiene tutti i membri del gruppo Windows BUILTIN\Administrators e il gruppo dell’amministratore locale. Il comando DBCC non fallisce se il processo di raccolta dati fallisce.

Risolvere gli errori

Se vengono riportati errori da DBCC CHECKDB, si consiglia di ripristinare il database dal backup del database invece di eseguire REPAIR con una delle opzioni REPAIR. Se non esiste un backup, l’esecuzione di REPAIR corregge gli errori riportati. L’opzione di riparazione da utilizzare è specificata alla fine della lista degli errori segnalati. Tuttavia, correggere gli errori usando l’opzione REPAIR_ALLOW_DATA_LOSS potrebbe richiedere la cancellazione di alcune pagine, e quindi di alcuni dati.

In alcune circostanze, potrebbero essere inseriti nel database valori non validi o fuori range in base al tipo di dati della colonna. DBCC CHECKDB può rilevare valori di colonna che non sono validi per tutti i tipi di dati della colonna. Pertanto, l’esecuzione di DBCC CHECKDB con l’opzione DATA_PURITY sui database che sono stati aggiornati da versioni precedenti di SQL Server potrebbe rivelare errori preesistenti nei valori delle colonne. Poiché SQL Server non può riparare automaticamente questi errori, il valore della colonna deve essere aggiornato manualmente. Se CHECKDB rileva un tale errore, CHECKDB restituisce un avvertimento, il numero di errore 2570 e le informazioni per identificare la riga interessata e correggere manualmente l’errore.

La riparazione può essere eseguita sotto una transazione utente per permettere all’utente di annullare le modifiche effettuate. Se le riparazioni vengono annullate, il database conterrà ancora errori e deve essere ripristinato da un backup. Dopo che le riparazioni sono state completate, eseguire il backup del database.

Risolvere gli errori in modalità di emergenza del database

Quando un database è stato impostato in modalità di emergenza usando l’istruzione ALTER DATABASE, DBCC CHECKDB può eseguire alcune riparazioni speciali sul database se l’opzione REPAIR_ALLOW_DATA_LOSS è specificata. Queste riparazioni possono permettere ai database normalmente irrecuperabili di essere riportati online in uno stato fisicamente coerente. Queste riparazioni dovrebbero essere usate come ultima risorsa e solo quando non è possibile ripristinare il database da un backup. Quando il database è impostato in modalità di emergenza, il database è marcato READ_ONLY, la registrazione è disabilitata e l’accesso è limitato ai membri del ruolo fisso di sysadmin.

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

• DBCC CHECKDB usa le pagine che sono state marcate come inaccessibili a causa di errori di I/O o di checksum, come se gli errori non si fossero verificati. Questo aumenta le possibilità di recupero dei dati dal database.
• DBCC CHECKDB tenta di recuperare il database usando le normali tecniche di recupero basate sul log.
• Se, a causa della corruzione del log delle transazioni, il recupero del database non ha successo, il log delle transazioni viene ricostruito. La ricostruzione del log delle transazioni può comportare la perdita della coerenza transazionale.

Se il comando DBCC CHECKDB ha successo, il database è in uno stato fisicamente coerente e lo stato del database è impostato su ONLINE. Tuttavia, il database potrebbe contenere una o più inconsistenze transazionali. Si consiglia di eseguire DBCC CHECKCONSTRAINTS per identificare qualsiasi difetto della logica di business ed eseguire immediatamente il backup del database.Se il comando DBCC CHECKDB fallisce, il database non può essere riparato.

Eseguire DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS nei database replicati

Eseguire il comando DBCC CHECKDB con l’opzione REPAIR_ALLOW_DATA_LOSS può influenzare i database utente (database di pubblicazione e sottoscrizione) e il database di distribuzione utilizzato dalla replica. I database di pubblicazione e sottoscrizione includono tabelle pubblicate e tabelle di metadati di replica. Sii consapevole dei seguenti potenziali problemi in questi database:

• Tabelle pubblicate. Le azioni eseguite dal processo CHECKDB per riparare i dati utente corrotti potrebbero non essere replicate:
• La replica di fusione usa i trigger per tracciare le modifiche alle tabelle pubblicate. Se le righe vengono inserite, aggiornate o cancellate dal processo CHECKDB, i trigger non scattano; pertanto, il cambiamento non viene replicato.
• La replica transazionale usa il log delle transazioni per tracciare i cambiamenti alle tabelle pubblicate. Il Log Reader Agent sposta quindi queste modifiche al database di distribuzione. Alcune riparazioni DBCC, sebbene registrate, non possono essere replicate dal Log Reader Agent. Per esempio, se una pagina di dati viene deallocata dal processo CHECKDB, il Log Reader Agent non la traduce in un’istruzione DELETE; pertanto, la modifica non viene replicata.
• Tabelle di metadati di replica. Le azioni eseguite dal processo CHECKDB per riparare le tabelle dei metadati di replica corrotte richiedono la rimozione e la riconfigurazione della replica.

Se dovete eseguire il comando DBCC CHECKDB con l’opzione REPAIR_ALLOW_DATA_LOSS su un database utente o di distribuzione:

1. Quiesce il sistema: Fermare l’attività sul database e su tutti gli altri database nella topologia di replica, e poi provare a sincronizzare tutti i nodi. Per ulteriori informazioni, vedere Quiescenza di una topologia di replica (Programmazione Transact-SQL di replica).
2. Eseguire DBCC CHECKDB.
3. Se il rapporto DBCC CHECKDB include riparazioni per qualsiasi tabella nel database di distribuzione o qualsiasi tabella di metadati di replica in un database utente, rimuovere e riconfigurare la replica. Per maggiori informazioni, vedere Disabilitare la pubblicazione e la distribuzione.
4. Se il rapporto DBCC CHECKDB include riparazioni per qualsiasi tabella replicata, eseguire la convalida dei dati per determinare se ci sono differenze tra i dati nei database di pubblicazione e di abbonamento.

Set di risultati

DBCC CHECKDB restituisce il seguente set di risultati. I valori possono variare tranne quando sono specificate le opzioni ESTIMATEONLY, PHYSICAL_ONLY, o 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 seguente set di risultati (messaggio) quando è specificato NO_INFOMSGS:

 The command(s) completed successfully.

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

 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 seguente set di risultati quando è specificato ESTIMATEONLY.

 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.

Permissions

Richiede l’appartenenza al ruolo fisso di sysadmin del server o al ruolo fisso db_owner del database.

Esempi

A. Controllo sia del database corrente che di un altro

L’esempio seguente esegue DBCC CHECKDB per il database corrente e per il database AdventureWorks2012.

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

B. Controllo del database corrente, soppressione dei messaggi informativi

L’esempio seguente controlla il database corrente e sopprime tutti i messaggi informativi.

DBCC CHECKDB WITH NO_INFOMSGS; GO 

Vedi anche

DBCC (Transact-SQL)
Vedi la dimensione del file sparse di un’istantanea del database (Transact-SQL)
sp_helpdb (Transact-SQL)
Tabelle di sistema (Transact-SQL)