DBCC CHECKDB (Transact-SQL)

Articolo
12/15/2008

Data aggiornamento: 17 novembre 2008

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

Esecuzione di DBCC CHECKALLOC sul database.
Esecuzione di DBCC CHECKTABLE su ogni tabella e vista del database.
Esecuzione di DBCC CHECKCATALOG sul database.
Convalida del contenuto di ogni vista indicizzata nel database.
Convalida dei dati di Service Broker nel database.

Non è pertanto necessario eseguire i comandi DBCC CHECKALLOC, DBCC CHECKTABLE o DBCC CHECKCATALOG separatamente da DBCC CHECKDB. Per ulteriori informazioni sui controlli eseguiti da questi comandi, vedere la relativa descrizione.

Icona di collegamento a un argomento Convenzioni della sintassi Transact-SQL

Sintassi

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

Argomenti

database_name | database_id | 0
Nome o ID del database per cui eseguire i controlli di integrità. Se è omesso o se si specifica 0, viene utilizzato il database corrente. I nomi dei database devono essere conformi alle regole per gli identificatori.

NOINDEX
Specifica che non è necessario eseguire controlli estesi di indici non cluster per le tabelle utente. Ciò comporta una riduzione dei tempi complessivi di esecuzione. NOINDEX non influisce sulle tabelle di sistema perché i controlli di integrità vengono sempre eseguiti sugli indici delle tabelle di sistema.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Specifica che DBCC CHECKDB corregge gli errori rilevati. 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 segnalati. Le operazioni di correzione possono comportare la perdita di dati.

REPAIR_FAST
Supporta la sintassi per motivi di compatibilità con le versioni precedenti e non viene eseguita alcuna operazione di correzione.

REPAIR_REBUILD
Esegue sia le operazioni di correzione minori e brevi, ad esempio la correzione di chiavi aggiuntive negli indici non cluster, sia le operazioni che richiedono una maggiore quantità di tempo, come la ricostruzione degli indici. Tali correzioni possono essere eseguite senza alcun rischio di perdita dei dati.

Importante:
Utilizzare le opzioni REPAIR solo se strettamente necessario. 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 utilizzare REPAIR, eseguire DBCC CHECKDB senza opzioni di correzione per individuare il livello di correzione da applicare. Se si utilizza il livello REPAIR_ALLOW_DATA_LOSS, è consigliabile eseguire il backup del database prima di utilizzare DBCC CHECKDB con questa opzione.

Utilizzare le opzioni REPAIR solo se strettamente necessario. 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 utilizzare REPAIR, eseguire DBCC CHECKDB senza opzioni di correzione per individuare il livello di correzione da applicare. Se si utilizza il livello REPAIR_ALLOW_DATA_LOSS, è consigliabile eseguire il backup del database prima di utilizzare DBCC CHECKDB con questa opzione.

ALL_ERRORMSGS
Visualizza tutti gli errori segnalati per oggetto. In SQL Server 2005 Service Pack 3 (SP3), vengono visualizzati tutti i messaggi di errore per impostazione predefinita. La specifica o l'omissione di questa opzione non ha alcun effetto. Nelle versioni precedenti di SQL Server vengono visualizzati solo i primi 200 messaggi di errore per ciascun oggetto se ALL_ERRORMSGS non è specificato. I messaggi di errore vengono ordinati in base all'ID di oggetto, ad eccezione dei messaggi generati dal database tempdb.

In SQL Server Management Studio, il numero massimo di messaggi di errore restituiti è 1000. Se si utilizza Management Studio, potrebbe essere necessario eseguire DBCC CHECKDB più volte per ottenere l'elenco completo degli errori quando si specifica ALL_ERRORMSGS. È consigliabile eseguire il comando DBCC utilizzando l'utilità sqlcmd o pianificando un processo di SQL Server Agent per l'esecuzione del comando e l'indirizzamento dell'output a un file. Entrambi i metodi garantiscono la visualizzazione di tutti i messaggi di errore quando si esegue il comando una volta.

NO_INFOMSGS
Disattiva tutti i messaggi informativi.

TABLOCK
Consente a DBCC CHECKDB di ottenere blocchi invece di utilizzare uno snapshot di database interno, incluso un blocco esclusivo (X) sul database di breve durata. TABLOCK consente l'esecuzione più rapida di DBCC CHECKDB in database con carico di lavoro elevato, ma comporta una diminuzione del livello di concorrenza del database durante l'esecuzione dell'istruzione. Per ulteriori informazioni sui blocchi, vedere Modalità blocco.

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

ESTIMATEONLY
Visualizza lo spazio di tempdb stimato necessario per eseguire l'istruzione DBCC CHECKDB con tutte le altre opzioni specificate. Il controllo effettivo sul database non viene eseguito.

PHYSICAL_ONLY
Limita il controllo di integrità alla struttura fisica della pagina, alle intestazioni dei record, alla struttura fisica delle strutture b-tree 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. L'opzione PHYSICAL_ONLY implica sempre l'utilizzo dell'opzione NO_INFOMSGS e non è consentito utilizzarla con le opzioni di correzione.

DATA_PURITY
Consente a DBCC CHECKDB di controllare il database per i valori di colonna che non sono validi o non sono compresi nell'intervallo dei valori consentiti. DBCC CHECKDB rileva ad esempio le colonne con valori di data e ora maggiori o minori dell'intervallo accettabile per il tipo di dati datetime oppure le colonne di tipi di dati numerici approssimati o decimal con valori di precisione o di scala non validi.

Per i database creati in SQL Server 2005, i controlli di integrità dei valori di colonna sono attivati per impostazione predefinita e non richiedono l'opzione DATA_PURITY. Per i database aggiornati da versioni precedenti di SQL Server, i controlli dei valori di colonna non sono attivati per impostazione predefinita fino a quando DBCC CHECKDB WITH DATA_PURITY non è stato eseguito senza errori nel database. A questo punto, DBCC CHECKDB controlla l'integrità dei valori di colonna per impostazione predefinita. Per ulteriori informazioni su come l'aggiornamento del database da versioni precedenti di SQL Server può influire su CHECKDB, vedere la sezione Osservazioni di seguito in questo argomento.

Se si specifica PHYSICAL_ONLY, i controlli di integrità di colonna non vengono eseguiti.

Gli errori di convalida rilevati da questa opzione non possono essere corretti utilizzando le opzioni di correzione DBCC. Per informazioni sulla correzione manuale di questi errori, vedere l'articolo 923247 della Knowledge Base Troubleshooting DBCC error 2570 in SQL Server 2005.

Set di risultati

DBCC CHECKDB restituisce il set di risultati seguente. I valori possono variare, tranne quando vengono 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 set di risultati (messaggio) seguente quando viene specificato NO_INFOMSGS:

The command(s) completed successfully.

DBCC CHECKDB restituisce il set di risultati seguente quando viene 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 set di risultati seguente quando viene 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.

Osservazioni

Nelle versioni precedenti di SQL Server i valori relativi al conteggio delle righe per tabella e per indice e i conteggi pagine possono essere errati. In certe circostanze, uno o più di questi valori può essere addirittura negativo. In SQL Server 2005 questi valori vengono sempre gestiti in modo corretto. I database creati in SQL Server 2005 non contengono pertanto conteggi non corretti. È tuttavia possibile che siano inclusi nei database aggiornati a SQL Server 2005. Non si tratta di un danneggiamento dei dati archiviati nel database. DBCC CHECKDB è stato migliorato in modo da rilevare i casi in cui uno di questi conteggi diventa negativo. Quando vengono rilevati conteggi negativi, l'output di DBCC CHECKDB include un avviso in cui viene consigliata l'esecuzione di DBCC UPDATEUSAGE per risolvere il problema. Sebbene possa sembrare che il problema sia dovuto all'aggiornamento del database a SQL Server 2005, in realtà i conteggi errati erano già presenti prima dell'aggiornamento.

DBCC CHECKDB non esamina gli indici disabilitati. Per ulteriori informazioni sugli indici disabilitati, vedere Disattivazione di indici.

Se un tipo definito dall'utente viene contrassegnato come ordinato per byte, è necessario che sia presente un'unica serializzazione di tale tipo. In assenza di una serializzazione consistente dei tipi definiti dall'utente ordinati per byte, durante l'esecuzione di DBCC CHECKDB viene generato l'errore 2537. Per ulteriori informazioni, vedere User-Defined Type Requirements.

Poiché il database delle risorse è modificabile solo in modalità utente singolo, il comando DBCC CHECKDB non può essere eseguito direttamente su tale database. Tuttavia, quando DBCC CHECKDB viene eseguito sul database master, viene eseguito internamente anche un secondo CHECKDB sul database delle risorse. Di conseguenza, 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.

Nelle versioni di SQL Server 2005 precedenti a SP2, l'esecuzione di DBCC CHECKDB comporta la cancellazione della cache dei piani per l'istanza di SQL Server. 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. In SP2, l'esecuzione di DBCC CHECKDB non comporta la cancellazione della cache dei piani.

Snapshot di database interno

DBCC CHECKDB utilizza uno snapshot interno del database per garantire la consistenza delle transazioni necessaria per l'esecuzione di questi controlli. Ciò consente di evitare problemi di blocco e concorrenza durante l'esecuzione di questi comandi. Per ulteriori informazioni, vedere Informazioni sulle dimensioni dei file sparse negli snapshot del database e la sezione relativa all'utilizzo dello snapshot interno del database per i controlli DBCC in DBCC (Transact-SQL). Se non è possibile creare uno snapshot o se viene specificato TABLOCK, DBCC CHECKDB acquisisce blocchi per ottenere la consistenza necessaria. In questo caso, è necessario un blocco esclusivo a livello di database per eseguire i controlli di allocazione, mentre sono necessari blocchi condivisi a livello di tabella per eseguire i controlli sulle tabelle.

L'esecuzione dell'istruzione DBCC CHECKDB sul database master ha esito negativo se non è possibile creare uno snapshot interno del database.

Quando l'istruzione DBCC CHECKDB viene eseguita su tempdb, non esegue alcuna allocazione o controllo del catalogo e deve acquisire blocchi condivisi a livello di tabella per eseguire i controlli sulle tabelle. Questo funzionamento dipende dal fatto che per motivi di prestazioni gli snapshot di database non sono disponibili in tempdb. Ciò significa che non è possibile ottenere la necessaria consistenza transazionale.

Procedure consigliate

In SQL Server 2005 l'esecuzione di DBCC CHECKDB senza opzioni può richiedere tempi notevolmente più lunghi rispetto alle versioni precedenti, per i motivi seguenti:

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

Di conseguenza, l'opzione PHYSICAL_ONLY è consigliata per l'esecuzione frequente nei sistemi di produzione, poiché consente di ridurre notevolmente i tempi di esecuzione di DBCC CHECKDB su database di grandi dimensioni. È inoltre consigliabile eseguire periodicamente DBCC CHECKDB senza opzioni. La frequenza consigliata di esecuzione varia a seconda delle singole aziende e dei relativi ambienti di produzione.

Controllo parallelo degli oggetti

Per impostazione predefinita, DBCC CHECKDB esegue il controllo parallelo degli oggetti. Il grado di parallelismo viene determinato in modo automatico da Query Processor. Il massimo grado di parallelismo viene configurato in modo analogo alle query parallele. Per limitare il numero massimo di processori disponibili per la verifica DBCC, utilizzare la stored procedure sp_configure. Per ulteriori informazioni, vedere Opzione max degree of parallelism. È possibile disattivare la verifica parallela tramite il flag di traccia 2528. Per ulteriori informazioni, vedere Flag di traccia (Transact-SQL).

Informazioni sui messaggi di errore DBCC

Dopo il completamento del comando DBCC CHECKDB, nel log degli errori di SQL Server viene scritto un messaggio. 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 interrotto 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.

Stato	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..

Segnalazione errori

In SQL Server 2005 Service Pack 1, quando un comando DBCC CHECKDB rileva un errore di danneggiamento, viene creato un file di dump, denominato SQLDUMPnnnn.txt, nella directory LOG di SQL Server. Se le funzionalità di segnalazione degli errori e di raccolta di dati relativi all'utilizzo delle funzionalità sono attivate per l'istanza di SQL Server, il file verrà inoltrato automaticamente a Microsoft. I dati raccolti consentono di migliorare la funzionalità di SQL Server. Per ulteriori informazioni, vedere Impostazioni segnalazione errori e utilizzo funzionalità.

Il file di dump contiene i risultati dell'esecuzione del comando DBCC CHECKDB e l'output di dati diagnostici supplementari. 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 dei dati non ha esito positivo, l'esecuzione del comando DBCC viene completata comunque.

Risoluzione degli errori

Se vengono rilevati errori da DBCC CHECKDB, è consigliabile ripristinare il database dal backup del database invece di eseguire REPAIR con una delle opzioni REPAIR. Se non esistono backup, l'esecuzione di REPAIR corregge gli errori segnalati. L'opzione REPAIR da utilizzare è specificata al termine dell'elenco degli errori segnalati. La correzione di errori con l'opzione REPAIR_ALLOW_DATA_LOSS, tuttavia, potrebbe richiedere l'eliminazione di alcune pagine, con conseguente perdita di dati.

In alcune circostanze, nel database possono essere inseriti dei valori non validi o non compresi nell'intervallo dei valori consentiti in base al tipo di dati della colonna. In SQL Server 2000, DBCC CHECKDB non esegue controlli di intervallo o di integrità su questi valori di colonna. In SQL Server 2005 DBCC CHECKDB è tuttavia in grado di rilevare i valori di colonna non validi per tutti i tipi di dati di colonna. Pertanto, l'esecuzione di DBCC CHECKDB con l'opzione DATA_PURITY per i database aggiornati da versioni precedenti di SQL Server può indicare errori di valori di colonna preesistenti. Poiché SQL Server 2005 non è in grado di riparare automaticamente questi errori, il valore della colonna deve essere aggiornato manualmente. Se CHECKDB rileva tale errore, CHECKDB restituisce un avviso di errore numero 2570, nonché 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 includerà ancora gli errori segnalati e sarà necessario eseguirne il ripristino da un backup. Dopo il completamento delle correzioni, eseguire il backup del database.

Risoluzione degli errori in modalità di emergenza per il database

Quando un database viene impostato in modalità di emergenza utilizzando l'istruzione ALTER DATABASE, DBCC CHECKDB può eseguire alcune correzioni speciali nel database se si specifica l'opzione REPAIR_ALLOW_DATA_LOSS. Grazie a queste correzioni è possibile riportare in linea database altrimenti irrecuperabili in uno stato consistente dal punto di vista fisico. È consigliabile utilizzarle solo se strettamente necessario e solo se non è possibile ripristinare il database da un backup. Se si imposta la modalità di emergenza, il database viene contrassegnato come READ_ONLY, la registrazione è disattivata e l'accesso è consentito ai soli membri del ruolo predefinito del server sysadmin.

[!NOTA] Non è possibile eseguire il comando DBCC CHECKDB in modalità di emergenza all'interno di una transazione utente, né eseguire il rollback della transazione al termine dell'esecuzione.

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

DBCC CHECKDB utilizza le pagine contrassegnate come inaccessibili a causa di errori di I/O o checksum come se tali errori non si fossero verificati. Questa azione consente di aumentare le possibilità di recupero dei dati del database.
DBCC CHECKDB tenta di recuperare il database mediante tecniche di recupero standard basate su log.
Se il recupero del database ha esito negativo a causa di un problema di danneggiamento del log delle transazioni, verrà ricostruito il log delle transazioni. Tale ricostruzione può provocare la perdita di consistenza delle transazioni.

Se il comando DBCC CHECKDB viene eseguito correttamente, il database è in uno stato consistente dal punto di vista fisico e lo stato del database viene impostato su ONLINE. È tuttavia possibile che il database contenga una o più inconsistenze delle transazioni. È consigliabile eseguire DBCC CHECKCONSTRAINTS per identificare eventuali difetti della regola business ed eseguire immediatamente il backup del database.

Se il comando DBCC CHECKDB non riesce, non è possibile correggere il database.

Esecuzione di DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS nei database replicati

L'esecuzione del comando DBCC CHECKDB con l'opzione REPAIR_ALLOW_DATA_LOSS può influire sui database utente (database di pubblicazione e di sottoscrizione) e sul database di distribuzione utilizzato 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 processo CHECKDB per correggere 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 il processo CHECKDB inserisce, aggiorna o elimina righe, i trigger non vengono attivati e, di conseguenza, le modifiche non vengono replicate.
- 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. Nonostante siano registrate, alcune correzioni DBCC non possono essere replicate dall'agente di lettura log. Se ad esempio una pagina di dati viene deallocata dal processo CHECKDB, l'agente di lettura log non associa questa condizione a un'istruzione DELETE. Di conseguenza, la modifica non viene replicata.
Tabelle di metadati della replica. Le azioni eseguite dal processo CHECKDB per correggere le tabelle di metadati della replica danneggiate richiedono l'eliminazione e la riconfigurazione della replica.

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

Mettere in stato di inattività il sistema: interrompere l'attività sul database e su qualsiasi altro database incluso nella topologia di replica, quindi provare a sincronizzare tutti i nodi. Per ulteriori informazioni, vedere How to: Quiesce a Replication Topology (Replication Transact-SQL Programming).
Eseguire DBCC CHECKDB.
Se il report di DBCC CHECKDB include correzioni relative a tabelle presenti nel database di distribuzione o a tabelle di metadati della replica di un database utente, eliminare e riconfigurare la replica. Per ulteriori informazioni, vedere Rimozione della replica.
Se il report di DBCC CHECKDB include correzioni relative a tabelle replicate, eseguire la convalida dei dati per determinare la presenza di eventuali differenze tra i dati dei database di pubblicazione e di sottoscrizione. Per ulteriori informazioni, vedere I dati del server di pubblicazione e quelli del Sottoscrittore non corrispondono.

Autorizzazioni

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

Esempi

A. Controllo del database corrente e del database AdventureWorks

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

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

B. Controllo del database corrente, con la disattivazione dei messaggi informativi

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

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Vedere anche

Cronologia modifiche

Versione	Cronologia
17 novembre 2008	Nuovo contenuto: Nella definizione di ALL_ERRORMSGS viene descritta una nuova funzionalità di SP3.
12 dicembre 2006	Nuovo contenuto: Aggiunta di informazioni nella sezione Osservazioni in merito alla cancellazione della cache dei piani in seguito all'esecuzione di DBCC CHECKDB.
17 luglio 2006	Nuovo contenuto: Aggiunta di informazioni relative alla restituzione di tutti i messaggi di errori nella definizione di ALL_ERRORMSGS.
14 aprile 2006	Nuovo contenuto: Aggiunta della sezione "Segnalazione degli errori", in cui vengono illustrate le nuove funzionalità di SP1. Aggiunta della sezione "Risoluzione degli errori in modalità di emergenza per il database".
5 dicembre 2005	Nuovo contenuto: Aggiunta delle informazioni sul messaggio di errore 2537 per i tipi definiti dall'utente ordinati per byte. Aggiunta della sezione "Esecuzione di DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS nei database replicati". Aggiunta della sezione "Informazioni sui messaggi di errore DBCC". Contenuto modificato: Correzione della sintassi. Correzione della definizione di REPAIR_FAST. L'opzione non esegue azioni di correzione. Correzione della definizione di TABLOCK tramite l'aggiunta delle operazioni non eseguite al momento della specifica dell'opzione.