DBCC CHECKTABLE (Transact-SQL)

Data aggiornamento: 17 novembre 2008

Controlla l'integrità di tutte le pagine e strutture che compongono la tabella o la vista indicizzata.

Convenzioni della sintassi Transact-SQL

Sintassi

DBCC CHECKTABLE 
(
        table_name | view_name
    [ , { NOINDEX | index_id }
     |, { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } 
    ] 
)
    [ WITH 
        { ALL_ERRORMSGS ]
          [ , NO_INFOMSGS ]
          [ , TABLOCK ] 
          [ , ESTIMATEONLY ] 
          [ , { PHYSICAL_ONLY | DATA_PURITY } ] 
        }
    ]

Argomenti

• table_name | view_name
  Tabella o vista indicizzata per cui si desidera eseguire i controlli di integrità. I nomi di tabelle e viste devono essere conformi alle regole per gli identificatori.

• NOINDEX
  Specifica che non è richiesta l'esecuzione di controlli estesi degli indici non cluster per le tabelle utente. Ciò consente di ridurre il tempo di esecuzione totale. NOINDEX non influisce sulle tabelle di sistema perché i controlli di integrità vengono sempre eseguiti su tutti gli indici delle tabelle di sistema.

• index_id
  Numero di identificazione (ID) dell'indice per cui eseguire i controlli di integrità. Se si specifica index_id, DBCC CHECKTABLE esegue i controlli di integrità solo su tale indice, insieme all'indice heap o cluster.

• REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
  Specifica che DBCC CHECKTABLE corregge gli errori rilevati. Per utilizzare un'opzione di correzione, è necessario che il database sia in modalità utente singolo.

  • REPAIR_ALLOW_DATA_LOSS
    Esegue un tentativo di correzione di tutti gli errori segnalati. Le operazioni di correzione possono comportare la perdita di dati.
  • REPAIR_FAST
    La sintassi è stata mantenuta solo a scopo di compatibilità con le versioni precedenti. Non vengono eseguite correzioni.
  • 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.

  [!NOTA] 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, in modo da individuare il livello di correzione richiesto. Se si prevede di utilizzare il livello REPAIR_ALLOW_DATA_LOSS, è consigliabile eseguire il backup del database prima di utilizzare DBCC CHECKDB con questa opzione.

• ALL_ERRORMSGS
  Visualizza un numero illimitato di errori. 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.

• NO_INFOMSGS
  Disattiva tutti i messaggi informativi.

• TABLOCK
  Impone l'acquisizione di un blocco condiviso a livello di tabella per l'esecuzione di DBCC CHECKTABLE, anziché utilizzare uno snapshot interno del database. TABLOCK consente l'esecuzione più rapida di DBCC CHECKTABLE in tabelle con carico di lavoro elevato, ma comporta una diminuzione del livello di concorrenza della tabella durante l'esecuzione di DBCC CHECKTABLE.

• ESTIMATEONLY
  Visualizza lo spazio di tempdb stimato necessario per eseguire l'istruzione DBCC CHECKTABLE con tutte le altre opzioni specificate.

• PHYSICAL_ONLY
  Limita il controllo di integrità alla struttura fisica della pagina, alle intestazioni dei record e alla struttura fisica delle strutture b-tree. Progettato per consentire un controllo a basso overhead della consistenza fisica della tabella, questo controllo consente inoltre di rilevare le pagine incomplete e i comuni problemi a livello di hardware che possono compromettere i dati. In SQL Server 2005, un'esecuzione completa di DBCC CHECKTABLE può richiedere tempi notevolmente più lunghi 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 numerosi nuovi controlli per includere le nuove funzionalità di SQL Server 2005.

  Per questo motivo, l'utilizzo dell'opzione PHYSICAL_ONLY può consentire di ottenere tempi molto più brevi per l'esecuzione di DBCC CHECKTABLE su tabelle di grandi dimensioni ed è quindi l'opzione consigliata per l'esecuzione frequente nei sistemi di produzione. È tuttora consigliabile prevedere periodicamente un'esecuzione completa di DBCC CHECKTABLE. La frequenza di esecuzione dipende da fattori specifici per i singoli ambienti aziendali e di produzione. L'opzione PHYSICAL_ONLY implica sempre l'utilizzo dell'opzione NO_INFOMSGS e non è consentito utilizzarla con nessuna delle opzioni di correzione.

• DATA_PURITY
  Consente a DBCC CHECKTABLE di controllare la tabella per individuare valori di colonna non validi o non compresi nell'intervallo dei valori consentiti. Ad esempio, DBCC CHECKTABLE rileva 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, è possibile utilizzare DBCC CHECKTABLE WITH DATA_PURITY per individuare e correggere gli errori in una specifica tabella. I controlli dei valori di colonna nella tabella, tuttavia, non vengono attivati per impostazione predefinita fino a quando DBCC CHECKDB WITH DATA_PURITY non è stato eseguito senza errori nel database. A questo punto, DBCC CHECKDB e DBCC CHECKTABLE controllano l'integrità dei valori di colonna per impostazione predefinita.

  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.

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

Set di risultati

DBCC CHECKTABLE restituisce il set dei risultati seguente. Viene restituito lo stesso set di risultati se si specifica solo il nome della tabella o qualsiasi opzione.

DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Se si specifica l'opzione ESTIMATEONLY, DBCC CHECKTABLE restituisce il set dei risultati seguente:

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

Osservazioni

DBCC CHECKTABLE esegue controlli di consistenza su una singola tabella o vista indicizzata e su tutti gli indici XML e non cluster corrispondenti, a meno che non venga specificata l'opzione NOINDEX. Per eseguire DBCC CHECKTABLE su ogni tabella del database, utilizzare DBCC CHECKDB.

DBCC CHECKTABLE esegue i controlli seguenti per la tabella specificata:

• Collegamenti corretti per le pagine di dati di indice, all'interno di righe, LOB e di overflow della riga.
• Ordinamento corretto degli indici.
• Consistenza dei puntatori.
• Presenza di dati accettabili in ogni pagina, incluse le colonne calcolate.
• Presenza di offset di pagina accettabili.
• A ogni riga nella tabella di base corrisponde una riga in ogni indice non cluster e viceversa.
• Ogni riga in una tabella o un indice partizionato è inclusa nella partizione corretta.

Snapshot di database interno

DBCC CHECKTABLE utilizza uno snapshot interno del database per garantire la consistenza transazionale necessaria per l'esecuzione di questi controlli. 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 si specifica TABLOCK, DBCC CHECKTABLE acquisisce un blocco condiviso a livello di tabella per ottenere la necessaria consistenza.

[!NOTA] Se si esegue DBCC CHECKTABLE sul database tempdb è richiesta l'acquisizione di un blocco condiviso a livello di tabella. 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.

Controllo parallelo degli oggetti

Per impostazione predefinita, DBCC CHECKTABLE esegue un controllo parallelo degli oggetti. Il grado di parallelismo viene determinato in modo automatico da Query Processor. Il grado di parallelismo massimo viene configurato esattamente come per le query parallele. Per limitare il numero massimo di processori disponibili per i controlli DBCC, utilizzare 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).

[!NOTA] Durante un'operazione DBCC CHECKTABLE i byte archiviati in una colonna con tipo definito dall'utente ordinato per byte devono essere uguali alla serializzazione calcolata del valore con tipo definito dall'utente. Se questa condizione non si verifica, la routine DBCC CHECKTABLE restituirà un errore di consistenza.

Informazioni sui messaggi di errore DBCC

Dopo il completamento del comando DBCC CHECKTABLE, 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.

Segnalazione errori

In SQL Server 2005 Service Pack 1 (SP1), quando DBCC CHECKTABLE rileva un errore di danneggiamento dei dati, viene creato un piccolo file di dump (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 CHECKTABLE e l'output di dati diagnostici supplementari. Il file dispone di elenchi di controllo di accesso discrezionale (DACL) limitati. 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 segnalati errori dopo l'esecuzione di DBCC CHECKTABLE, è consigliabile eseguire il ripristino del database dal backup, anziché eseguire REPAIR con una delle opzioni REPAIR. Se non è disponibile un backup, l'esecuzione di REPAIR può consentire la correzione degli errori segnalati. L'opzione REPAIR da utilizzare viene indicata alla fine dell'elenco degli errori segnalati. Si noti, tuttavia, che la correzione di errori con l'opzione REPAIR_ALLOW_DATA_LOSS potrebbe richiedere l'eliminazione di alcune pagine, con conseguente perdita di dati.

È 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 di tutte le correzioni, eseguire il backup del database.

Autorizzazioni

L'utente deve essere il proprietario della tabella o membro del ruolo predefinito del server sysadmin, del ruolo predefinito del database db_owner o del ruolo predefinito del database db_ddladmin.

Esempi

A. Controllo di una tabella specifica

Nell'esempio seguente viene controllata l'integrità delle pagine di dati nella tabella HumanResources.Employee nel database AdventureWorks .

USE AdventureWorks;
GO
DBCC CHECKTABLE ("HumanResources.Employee");
GO

B. Esecuzione di un controllo della tabella a basso overhead

Nell'esempio seguente viene eseguito un controllo a basso overhead della tabella Employee nel database AdventureWorks.

USE AdventureWorks;
GO
DBCC CHECKTABLE ("HumanResources.Employee") WITH PHYSICAL_ONLY;
GO

C. Controllo di un indice specifico

Nell'esempio seguente viene eseguito il controllo di un indice specifico, recuperato tramite l'accesso a sys.indexes.

USE AdventureWorks;
GO
DECLARE @indid int;
SET @indid = (SELECT index_id 
              FROM sys.indexes
              WHERE object_id = OBJECT_ID('Production.Product')
                    AND name = 'AK_Product_Name');
DBCC CHECKTABLE ("Production.Product", @indid);

Vedere anche

Riferimento

DBCC (Transact-SQL)

Altre risorse

Architettura di tabelle e indici
Risoluzione degli errori DBCC nelle viste indicizzate

Guida in linea e informazioni

Assistenza su SQL Server 2005

Cronologia modifiche