• Articolo

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.

Icona di collegamento a un argomentoConvenzioni della sintassi Transact-SQL

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. Tutti i messaggi di errore vengono visualizzati per impostazione predefinita. La specifica o l'omissione di questa opzione non ha alcun effetto.

  • 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 caratteristiche.

    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:

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 un 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 coerenza per le transazioni necessaria.

Controllo parallelo degli oggetti

Per impostazione predefinita, DBCC CHECKFILEGROUP esegue il controllo parallelo degli oggetti. Il grado 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 la verifica 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 sia 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 un'analisi 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 registro 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 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.

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

Si è verificato un errore sconosciuto che ha causato l'interruzione del comando DBCC.

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 caratteristiche di segnalazione degli errori e di raccolta di dati relativi all'utilizzo delle caratteristiche sono abilitate per l'istanza di SQL Server, il file viene inoltrato automaticamente a Microsoft. I dati raccolti consentono di migliorare le 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 di un database

Nell'esempio seguente viene controllato il filegroup primario del database AdventureWorks2008R2.

USE AdventureWorks2008R2;
GO
DBCC CHECKFILEGROUP;
GO

B. Controllo del filegroup PRIMARY senza indici non cluster

Nell'esempio seguente viene controllato il filegroup primario del database AdventureWorks2008R2, esclusi gli indici non cluster, in base al numero di identificazione del filegroup primario e specificando l'opzione NOINDEX.

USE AdventureWorks2008R2;
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;