DBCC CHECKTABLE (Transact-SQL)
Si applica a: SQL Server Azure SQL Database
Istanza gestita di SQL di Azure
Controlla l'integrità di tutte le pagine e le strutture che compongono la tabella o la vista indicizzata.
Convenzioni di sintassi Transact-SQL
Sintassi
DBCC CHECKTABLE
(
table_name | view_name
[ , { NOINDEX | index_id }
| , { 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
table_name | view_name
Tabella o vista indicizzata per cui eseguire controlli di integrità. I nomi di tabelle e viste devono essere conformi alle regole per gli identificatori.
NOINDEX
Specifica che i controlli intensivi degli indici non cluster per le tabelle utente non devono essere eseguiti. In questo modo, è possibile ridurre i tempi di esecuzione complessivi. NOINDEX
non influisce sulle tabelle di sistema perché i controlli di integrità vengono sempre eseguiti su tutti gli indici di tabella di sistema.
index_id
Numero di identificazione dell'indice (ID) per cui eseguire controlli di integrità. Se viene specificato index_id, DBCC CHECKTABLE
esegue controlli di integrità solo su tale indice, insieme all'heap o all'indice cluster.
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Specifica che DBCC CHECKTABLE
ripristina gli errori trovati. Per utilizzare un'opzione di correzione, è necessario che il database sia in modalità utente singolo.
REPAIR_ALLOW_DATA_LOSS
Tenta di riparare tutti gli errori rilevati. 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 operazioni di ripristino senza possibilità di perdita dei dati. Sono incluse 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
Utilizzare le opzioni REPAIR solo come ultima risorsa. Per correggere gli errori, è consigliabile eseguire un ripristino da un backup. Le operazioni di ripristino non considerano nessuno dei vincoli che possono esistere tra tabelle o. 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 CHECKTABLE
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 CHECKTABLE
questa opzione.
ALL_ERRORMSGS
Visualizza un numero illimitato di errori. Tutti i messaggi di errore vengono visualizzati per impostazione predefinita. La specifica o l'omissione di questa opzione non ha alcun effetto.
EXTENDED_LOGICAL_CHECKS
Se il livello di compatibilità è 100, introdotto in SQL Server 2008 (10.0.x), esegue controlli di coerenza logica su una visualizzazione indicizzata, indici XML e indici spaziali, in cui presenti.
Per altre informazioni, vedere Esecuzione di controlli di coerenza logica sugli indici nella sezione Osservazioni più avanti in questo articolo.
NO_INFOMSGS
Disattiva tutti i messaggi informativi.
TABLOCK
DBCC CHECKTABLE
Causa l'acquisizione di un blocco di tabella condiviso anziché l'uso di uno snapshot interno del database. TABLOCK
causerà DBCC CHECKTABLE
l'esecuzione più veloce in una tabella con carico elevato, ma riduce la concorrenza disponibile nella tabella durante DBCC CHECKTABLE
l'esecuzione.
ESTIMATEONLY
Visualizza la quantità stimata di tempdb
spazio necessaria per l'esecuzione 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 degli alberi B. 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. Un'esecuzione completa di DBCC CHECKTABLE
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à.
Nota
Nella documentazione di SQL Server viene usato in modo generico il termine albero B in riferimento agli indici. Negli indici rowstore SQL Server implementa un albero B+. Questo non si applica agli indici columnstore o agli archivi dati in memoria. Per altre informazioni, vedere la guida SQL Server e Azure SQL architettura dell'indice e della progettazione.
Pertanto, l'uso dell'opzione PHYSICAL_ONLY
può causare un'esecuzione molto più breve per DBCC CHECKTABLE
le tabelle di grandi dimensioni ed è pertanto consigliato per l'uso frequente nei sistemi di produzione. È comunque consigliabile eseguire periodicamente un'esecuzione completa di DBCC CHECKTABLE
. La frequenza di esecuzione dipende da fattori specifici per i singoli ambienti aziendali e di produzione. PHYSICAL_ONLY
implica sempre NO_INFOMSGS e non è consentito con una delle opzioni di ripristino.
Nota
Specificando PHYSICAL_ONLY
le DBCC CHECKTABLE
cause di ignorare tutti i controlli dei dati FILESTREAM.
DATA_PURITY
DBCC CHECKTABLE
Causa la verifica della tabella per i valori di colonna non validi o non compresi nell'intervallo. Ad esempio, DBCC CHECKTABLE
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, è possibile usare DBCC CHECKTABLE WITH DATA_PURITY
per trovare e correggere gli errori in una tabella specifica. Tuttavia, i controlli dei valori di colonna nella tabella non sono abilitati per impostazione predefinita fino a quando DBCC CHECKDB WITH DATA_PURITY
non è stato eseguito un errore libero nel database. Dopo questa operazione e DBCC CHECKDB
DBCC CHECKTABLE
controllare l'integrità del valore della colonna per impostazione predefinita.
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.
Se PHYSICAL_ONLY
specificato, i controlli di integrità della colonna non vengono eseguiti.
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. MAXDOP può superare il valore configurato con sp_configure
. Se MAXDOP supera il valore configurato con Resource Governor, il motore di database usa il valore MAXDOP di Resource Governor descritto in ALTER WORKLOAD GROUP (Transact-SQL). Quando si utilizza l'hint per la query MAXDOP sono valide tutte le regole semantiche utilizzate con l'opzione di configurazione max degree of parallelism. Per altre informazioni, vedere Configurare l'opzione di configurazione del server max degree of parallelism.
Nota
Se MAXDOP è impostato su zero, il server sceglie il grado massimo di parallelismo.
Commenti
Nota
Per eseguire DBCC CHECKTABLE
in ogni tabella del database, usare DBCC CHECKDB.
Per la tabella specificata, DBCC CHECKTABLE
verifica quanto segue:
- 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.
- Coerenza a livello di collegamenti tra il file system e la tabella quando vengono archiviati i dati varbinary(max) nel file system usando FILESTREAM.
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à è 100 (SQL Server 2008 (10.0.x)) o superiore:
A meno che non
NOINDEX
venga specificato,DBCC CHECKTABLE
esegue controlli di coerenza sia fisici che logici in una singola tabella e in 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 ancheNOINDEX
, 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 molto elevato sulle prestazioni e non è possibile tenere traccia dello stato di avanzamento. È pertanto consigliabile specificare
WITH 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 CHECKTABLE
esegue controlli di coerenza per verificare che le voci di indice soddisfino il predicato di filtro.
A partire da SQL Server 2016 (13.x), i controlli aggiuntivi sulle colonne calcolate persistenti, sulle colonne con tipo definito dall'utente e sugli indici filtrati non verranno eseguiti per impostazione predefinita per evitare le valutazioni di espressioni costose. Questa modifica riduce notevolmente la durata di
CHECKTABLE
rispetto ai database contenenti questi oggetti. Tuttavia, i controlli di coerenza fisici di questi oggetti vengono sempre completati. Solo quandoEXTENDED_LOGICAL_CHECKS
si specifica l'opzione vengono eseguite le valutazioni delle espressioni, oltre a presentare già controlli logici (vista indicizzata, indici XML e indici spaziali) come parte dell'opzioneEXTENDED_LOGICAL_CHECKS
.Se il livello di compatibilità è 90 (SQL Server 2005 (9.x)) o minore, a meno
NOINDEX
che non venga specificato,DBCC CHECKTABLE
esegue controlli di coerenza sia fisici che logici su una singola tabella o vista indicizzata e su tutti gli indici non cluster e XML. Gli indici spaziali non sono supportati.
Per informazioni sul livello di compatibilità di un database
Snapshot interno del database
DBCC CHECKTABLE
usa uno snapshot interno del database per garantire la coerenza transazionale che deve essere necessario eseguire questi controlli. Per altre informazioni, vedere Visualizzare le dimensioni del file sparse di uno snapshot del database (Transact-SQL) e la sezione utilizzo degli snapshot interni del database DBCC in DBCC (Transact-SQL).For more information, see View the Size of the Sparse File of a Database Snapshot (Transact-SQL) and the DBCC internal database snapshot usage section in DBCC (Transact-SQL).
Se non è possibile creare uno snapshot o TABLOCK
viene specificato, DBCC CHECKTABLE
acquisisce un blocco di tabella condiviso per ottenere la coerenza necessaria.
Nota
Se DBCC CHECKTABLE
viene eseguito su tempdb
, deve acquisire un blocco di tabella condiviso. Ciò è dovuto al fatto che, per motivi di prestazioni, gli snapshot del database non sono disponibili in tempdb
. Ciò significa che non è possibile ottenere la consistenza delle transazioni necessaria.
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 CHECKTABLE
in una tabella che archivia BLOB nel file system, DBCC verifica 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 CHECKTABLE
verificherà che sia presente un mapping uno-a-uno tra le directory del file system e file e le righe di tabella, le colonne e i valori di colonna. DBCC CHECKTABLE
può riparare il danneggiamento se si specifica l'opzione REPAIR_ALLOW_DATA_LOSS
. Per ripristinare il danneggiamento di FILESTREAM, DBCC eliminerà tutte le righe di tabella mancanti nei dati del file system e eliminerà tutte le directory e i file che non eseguono il mapping a una riga di tabella, una colonna o un valore di colonna.
Controllare gli oggetti in parallelo
Per impostazione predefinita, DBCC CHECKTABLE
esegue il 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 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
Durante un'operazione DBCC CHECKTABLE
, i byte archiviati in una colonna di tipo definito dall'utente ordinati in byte devono essere uguali alla serializzazione calcolata del valore di tipo definito dall'utente. In caso contrario, la DBCC CHECKTABLE
routine segnala un errore di coerenza.
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 CHECKTABLE
comando, viene scritto un messaggio nel log degli errori SQL Server. Se il comando DBCC viene eseguito correttamente, il messaggio indica il completamento corretto e la durata dell'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 che il comando DBCC è stato terminato a causa di un danneggiamento dei metadati. |
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 che il comando DBCC è stato terminato a causa di un danneggiamento dei metadati. |
4 | È stata rilevata una violazione di accesso o asserzione. |
5 | il comando DBCC è stato terminato da un errore sconosciuto. |
Errore di segnalazione
Un file mini-dump (SQLDUMP<nnnn>.txt
) viene creato nella directory SQL Server LOG
ogni volta che DBCC CHECKTABLE
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 CHECKTABLE
di diagnostica aggiuntivo. 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 dati ha esito negativo, il comando DBCC non riesce.
Risolvere gli errori
Se DBCC CHECKTABLE
vengono segnalati errori, è consigliabile ripristinare il database dal backup del database 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. Tuttavia, la correzione degli errori tramite l'opzione REPAIR_ALLOW_DATA_LOSS
potrebbe richiedere l'eliminazione di alcune pagine e quindi dei dati.
È possibile eseguire l'operazione di correzione tramite una transazione utente che consente il rollback delle modifiche apportate. Se viene eseguito il rollback delle riparazioni, il database conterrà comunque errori e deve essere ripristinato da un backup. Dopo il completamento di tutte le correzioni, eseguire il backup del database.
Set di risultati
DBCC CHECKTABLE
restituisce il set di 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.
DBCC CHECKTABLE
restituisce il set di risultati seguente se viene specificata l'opzione ESTIMATEONLY:
Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
21
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Autorizzazioni
L'utente deve essere il proprietario della tabella oppure un membro del ruolo predefinito del server sysadmin o dei ruoli predefiniti del database db_owner o db_ddladmin.
Esempi
R. Controllare una tabella specifica
Nell'esempio seguente viene verificata l'integrità della pagina dei dati della HumanResources.Employee
tabella nel database AdventureWorks2022.
DBCC CHECKTABLE ('HumanResources.Employee');
GO
B. Eseguire un controllo a basso sovraccarico della tabella
Nell'esempio seguente viene eseguito un controllo a basso sovraccarico della Employee
tabella nel database AdventureWorks2022.
DBCC CHECKTABLE ('HumanResources.Employee') WITH PHYSICAL_ONLY;
GO
C. Controllare un indice specifico
Nell'esempio seguente viene eseguito il controllo di un indice specifico, recuperato tramite l'accesso a sys.indexes
.
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);