DBCC CHECKFILEGROUP (Transact-SQL)
Controlla l'integrità strutturale e di allocazione di tutte le tabelle e le viste indicizzate nel filegroup specificato del database corrente.
Sintassi
DBCC CHECKFILEGROUP
[
[ ( { filegroup_name | filegroup_id | 0 }
[ , NOINDEX ]
) ]
[ WITH
{
[ ALL_ERRORMSGS | NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
[ , PHYSICAL_ONLY ]
}
]
]
Argomenti
filegroup_name
Nome del filegroup nel database corrente di cui si desidera controllare l'integrità strutturale e di allocazione delle tabelle. Se omesso oppure se viene specificato 0, per impostazione predefinita viene utilizzato il filegroup primario. I nomi di filegroup devono essere conformi alle regole per gli identificatori.filegroup_name non può essere un filegroup FILESTREAM.
filegroup_id
Numero di identificazione (ID) del filegroup nel database corrente di cui si desidera controllare l'integrità strutturale e di allocazione delle tabelle.NOINDEX
Specifica che non è necessario eseguire controlli estesi di indici non cluster per le tabelle utente. In questo modo, è possibile ridurre i tempi di esecuzione complessivi. NOINDEX non influisce sulle tabelle di sistema perché DBCC CHECKFILEGROUP controlla sempre tutti gli indici delle tabelle di sistema.ALL_ERRORMSGS
Visualizza un numero illimitato di errori per oggetto. In SQL Server 2008 Service Pack 1 (SP1) 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, ad eccezione di SQL Server 2005 SP3, 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
Consente all'istruzione DBCC CHECKFILEGROUP di ottenere blocchi anziché utilizzare uno snapshot interno del database.ESTIMATEONLY
Visualizza lo spazio di tempdb stimato necessario per eseguire l'istruzione DBCC CHECKFILEGROUP con tutte le 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-tree. Progettato per consentire un controllo con overhead limitato della consistenza fisica del filegroup, questo controllo consente inoltre di rilevare le pagine incomplete e i problemi comuni a livello di hardware che possono compromettere i dati. Un'esecuzione completa di DBCC CHECKFILEGROUP 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 molti nuovi controlli per includere le nuove funzionalità.
Per questo motivo, l'utilizzo dell'opzione PHYSICAL_ONLY può consentire di ottenere tempi molto più brevi per l'esecuzione di DBCC CHECKFILEGROUP su filegroup di grandi dimensioni ed è quindi l'opzione consigliata per l'esecuzione frequente nei sistemi di produzione. È comunque consigliabile prevedere periodicamente un'esecuzione completa di DBCC CHECKFILEGROUP. 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 è consentita con le opzioni di correzione.
[!NOTA]
Se si specifica PHYSICAL_ONLY, DBCC CHECKFILEGROUP ignora tutti i controlli dei dati FILESTREAM.
Osservazioni
DBCC CHECKFILEGROUP e DBCC CHECKDB sono comandi DBCC simili. La differenza principale consiste nel fatto che il comando DBCC CHECKFILEGROUP è limitato al singolo filegroup specificato e alle tabelle obbligatorie.
Tramite DBCC CHECKFILEGROUP vengono eseguiti i comandi seguenti:
DBCC CHECKALLOC per il filegroup.
DBCC CHECKTABLE per ogni tabella e vista indicizzata nel filegroup.
Non è necessario eseguire DBCC CHECKALLOC o DBCC CHECKTABLE separatamente da DBCC CHECKFILEGROUP.
Snapshot interno del database
DBCC CHECKFILEGROUP utilizza uno snapshot interno del database per garantire la consistenza delle transazioni necessaria per eseguire 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 oppure viene specificata l'opzione TABLOCK, DBCC CHECKFILEGROUP acquisisce blocchi per ottenere la consistenza 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. TABLOCK consente l'esecuzione più rapida di DBCC CHECKFILEGROUP in database con carico di lavoro elevato, ma comporta una diminuzione del livello di concorrenza del database durante l'esecuzione dell'istruzione.
[!NOTA]
L'esecuzione di DBCC CHECKFILEGROUP nel database tempdb non comporta l'esecuzione di controlli di allocazione ed è pertanto necessario acquisire blocchi condivisi a livello di tabella per eseguire i controlli delle tabelle. Questo funzionamento dipende dal 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.
Controllo parallelo degli oggetti
Per impostazione predefinita, DBCC CHECKFILEGROUP esegue il controllo parallelo degli oggetti. Il livello 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 il controllo DBCC, utilizzare la stored procedure sp_configure. Per ulteriori informazioni, vedere Opzione max degree of parallelism.
È possibile disabilitare il controllo parallelo tramite il flag di traccia 2528. Per ulteriori informazioni, vedere Flag di traccia (Transact-SQL).
Indici non cluster in filegroup separati
Se un indice non cluster nel filegroup specificato è associato a una tabella in un altro filegroup, l'indice non viene controllato poiché la tabella di base non è disponibile per la convalida. Si tratta di una modifica nel comportamento di SQL Server 2005 rispetto alle versioni precedenti di SQL Server, in cui l'indice non cluster e la tabella di base nell'altro filegroup vengono controllati. Per controllare sia gli indici non cluster che le tabelle di base, eseguire DBCC CHECKDB.
Se una tabella nel filegroup specificato include un indice non cluster in un altro filegroup, tale indice non viene controllato per i motivi seguenti:
La struttura della tabella di base non dipende dalla struttura di un indice non cluster. Non è necessario eseguire una scansione degli indici non cluster per convalidare la tabella di base.
Il comando DBCC CHECKFILEGROUP convalida gli oggetti solo nel filegroup specificato.
Un indice cluster e una tabella non possono trovarsi in filegroup diversi. Le considerazioni precedenti sono pertanto valide solo per gli indici non cluster.
Tabelle partizionate in filegroup separati
Nelle versioni di SQL Server 2005 precedenti a Service Pack 2 (SP2), DBCC CHECKFILEGROUP controlla una tabella partizionata solo se l'intera tabella è inclusa nel filegroup specificato. Se la tabella è distribuita in più filegroup, l'intera tabella viene ignorata. Nella versione SP2 e in quelle successive quando una tabella partizionata è distribuita in più filegroup, DBCC CHECKFILEGROUP controlla i set di righe delle partizioni presenti nel filegroup specificato e ignora quelli negli altri filegroup. Il messaggio informativo 2594 indica le partizioni non controllate. Gli indici non cluster non residenti nel filegroup specificato non vengono controllati.
Informazioni sui messaggi di errore DBCC
Al termine del comando DBCC CHECKFILEGROUP, viene scritto un messaggio nel log degli errori di 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 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, che 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. |
Segnalazione errori
Quando un comando DBCC CHECKFILEGROUP rileva un errore di danneggiamento, viene creato un piccolo 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 abilitate per l'istanza di SQL Server, il file viene inoltrato automaticamente a Microsoft. I dati raccolti consentono di migliorare la funzionalità di SQL Server.
Il file di dump contiene i risultati dell'esecuzione del comando DBCC CHECKFILEGROUP 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 da DBCC CHECKFILEGROUP, è consigliabile ripristinare il database dal backup. Non è possibile specificare le opzioni di correzione nel comando DBCC CHECKFILEGROUP.
Se non è disponibile un backup, per correggere gli errori restituiti è necessario eseguire DBCC CHECKDB e specificare un'opzione di correzione. L'opzione di correzione da utilizzare è specificata in fondo all'elenco degli errori restituiti. La correzione degli errori tramite l'opzione REPAIR_ALLOW_DATA_LOSS potrebbe richiedere l'eliminazione di alcune pagine e pertanto dei dati corrispondenti.
Set di risultati
DBCC CHECKFILEGROUP restituisce il set di risultati seguente (i valori possono variare):
Eccetto quando si specifica ESTIMATEONLY o NO_INFOMSGS.
Per il database corrente, se non si specifica alcun database, indipendentemente dalla specifica delle opzioni (eccetto NOINDEX).
DBCC results for 'master'.
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 2340 rows in 16 pages for object 'spt_values'.
DBCC results for 'MSreplication_options'.
There are 2 rows in 1 pages for object 'MSreplication_options'.
CHECKFILEGROUP found 0 allocation errors and 0 consistency errors in database 'master'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Se si specifica NO_INFOMSGS, DBCC CHECKFILEGROUP restituisce:
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Se si specifica ESTIMATEONLY, DBCC CHECKFILEGROUP restituisce (i valori possono variare):
Estimated TEMPDB space needed for CHECKALLOC (KB)
-------------------------------------------------
15
(1 row(s) affected)
Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
207
(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
A. Controllo del filegroup PRIMARY nel database AdventureWorks
Nell'esempio seguente viene controllato il filegroup primario del database AdventureWorks.
USE AdventureWorks;
GO
DBCC CHECKFILEGROUP;
GO
B. Controllo del filegroup PRIMARY nel database AdventureWorks senza indici non cluster
Nell'esempio seguente viene controllato il filegroup primario del database AdventureWorks senza gli indici non cluster, in base al numero di identificazione del filegroup primario e l'opzione NOINDEX.
USE AdventureWorks;
GO
DBCC CHECKFILEGROUP (1, NOINDEX);
GO
C. Controllo del filegroup PRIMARY con opzioni
Nell'esempio seguente viene controllato il filegroup primario del database master specificando l'opzione ESTIMATEONLY.
USE master;
GO
DBCC CHECKFILEGROUP (1)
WITH ESTIMATEONLY;
Vedere anche
Riferimento
Cronologia modifiche
Aggiornamento del contenuto |
---|
Descrizione di una nuova funzionalità di SQL Server 2008 SP1 nella definizione di ALL_ERRORMSGS. |
Aggiunta della clausola PHYSICAL_ONLY alle sezioni Sintassi e Argomenti. |