DBCC CHECKFILEGROUP (Transact-SQL)
Überprüft die Zuordnung und strukturelle Integrität aller Tabellen und indizierten Sichten in der angegebenen Dateigruppe der aktuellen Datenbank.
Syntax
DBCC CHECKFILEGROUP
[
[ ( { filegroup_name | filegroup_id | 0 }
[ , NOINDEX ]
) ]
[ WITH
{
[ ALL_ERRORMSGS | NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
[ , PHYSICAL_ONLY ]
}
]
]
Argumente
filegroup_name
Der Name der Dateigruppe in der aktuellen Datenbank, für die die Tabellenzuordnung und strukturelle Integrität überprüft werden sollen. Wenn dieses Argument fehlt oder mit 0 angegeben ist, wird standardmäßig die primäre Dateigruppe verwendet. Dateigruppennamen müssen den Regeln für Bezeichner entsprechen.filegroup_name kann keine FILESTREAM-Dateigruppe sein.
filegroup_id
Die Dateigruppen-ID in der aktuellen Datenbank, für die die Tabellenzuordnung und strukturelle Integrität überprüft werden sollen.NOINDEX
Legt fest, dass nicht gruppierte Indizes für Benutzertabellen nicht intensiv überprüft werden. Dadurch wird die Ausführungsdauer insgesamt verkürzt. NOINDEX wirkt sich nicht auf Systemtabellen aus, da DBCC CHECKFILEGROUP immer alle Systemtabellenindizes überprüft.ALL_ERRORMSGS
Zeigt pro Objekt eine unbegrenzte Fehlerzahl an. Alle Fehlermeldungen werden standardmäßig angezeigt. Das Angeben oder Weglassen dieser Option hat keine Auswirkungen.NO_INFOMSGS
Unterdrückt alle Informationsmeldungen.TABLOCK
Bewirkt, dass DBCC CHECKFILEGROUP freigegebene Tabellensperren erhält anstatt auf eine interne Datenbankmomentaufnahme zurückzugreifen.ESTIMATEONLY
Zeigt den tempdb-Speicherplatz an, der schätzungsweise erforderlich ist, um DBCC CHECKFILEGROUP mit den anderen angegebenen Optionen auszuführen.PHYSICAL_ONLY
Beschränkt die Überprüfung auf die Integrität der physischen Struktur der Seite, der Datensatzheader und der physischen Struktur von B-Strukturen. Dieses Argument wurde entworfen, um mit geringem Verwaltungsaufwand eine Überprüfung der physischen Konsistenz der Dateigruppe vorzunehmen. Dabei werden auch zerrissene Seiten und häufige Hardwarefehler erkannt, die die Daten gefährden können. Die vollständige Ausführung von DBCC CHECKFILEGROUP kann erheblich mehr Zeit in Anspruch nehmen als in früheren Versionen. Dieses Verhalten tritt aus den folgenden Gründen auf:Die logischen Überprüfungen sind umfassender.
Einige der zu überprüfenden zugrunde liegenden Strukturen sind komplexer.
Es wurden viele neue Überprüfungen eingeführt, um die neuen Funktionen einzuschließen.
Daher bewirkt das Verwenden der PHYSICAL_ONLY-Option möglicherweise eine viel kürzere Ausführungszeit von DBCC CHECKFILEGROUP für große Dateigruppen. Es wird daher für die häufige Verwendung in Produktionssystemen empfohlen. Dennoch ist eine vollständige Ausführung von DBCC CHECKFILEGROUP in regelmäßigen Abständen empfehlenswert. Die Häufigkeit dieser Ausführungsvorgänge hängt von Faktoren ab, die für einzelne Unternehmen und Produktionsumgebungen spezifisch sind. PHYSICAL_ONLY impliziert stets NO_INFOMSGS und kann nicht mit einer der Reparaturoptionen verwendet werden.
Hinweis Bei Angabe von PHYSICAL_ONLY überspringt DBCC CHECKFILEGROUP alle Überprüfungen der FILESTREAM-Daten.
Hinweise
DBCC CHECKFILEGROUP und DBCC CHECKDB sind ähnliche DBCC-Befehle. Der Hauptunterschied besteht darin, dass DBCC CHECKFILEGROUP auf die einzelne angegebene Dateigruppe und die erforderlichen Tabellen beschränkt ist.
Von DBCC CHECKFILEGROUP werden die folgenden Befehle ausgeführt:
DBCC CHECKALLOC für die Dateigruppe.
DBCC CHECKTABLE für jede Tabelle und indizierte Sicht in der Dateigruppe.
Eine von DBCC CHECKFILEGROUP getrennte Ausführung von DBCC CHECKALLOC oder DBCC CHECKTABLE ist nicht erforderlich.
Interne Datenbankmomentaufnahme
Zur Bereitstellung der Transaktionskonsistenz, die für diese Prüfungen vorliegen muss, verwendet DBCC CHECKFILEGROUP eine interne Datenbankmomentaufnahme. Weitere Informationen finden Sie unter Grundlegendes zur Größe von Dateien mit geringer Dichte in Datenbankmomentaufnahmen und im Abschnitt zum Verwenden der internen DBCC-Datenbankmomentaufnahme in DBCC (Transact-SQL).
Falls keine Momentaufnahme erstellt werden kann oder die TABLOCK-Option angegeben ist, wendet DBCC CHECKFILEGROUP Sperren an, um die erforderliche Konsistenz zu erlangen. In diesem Fall ist für die Durchführung der Zuordnungsprüfungen eine exklusive Datenbanksperre erforderlich, und für die Durchführung der Tabellenprüfungen sind freigegebene Tabellensperren erforderlich. Durch TABLOCK wird DBCC CHECKFILEGROUP für eine Datenbank bei starker Belastung schneller ausgeführt, jedoch wird während der Ausführung von DBCC CHECKFILEGROUP die in der Datenbank verfügbare Parallelität verringert.
Hinweis |
---|
Durch das Ausführen von DBCC CHECKFILEGROUP für tempdb werden keine Zuordnungsprüfungen veranlasst, und zur Durchführung von Tabellenprüfungen müssen freigegebene Tabellensperren aktiviert werden. Dies liegt daran, dass aus Leistungsgründen keine Datenbank-Momentaufnahmen für tempdb verfügbar sind. Dies bedeutet, dass sich die erforderliche Transaktionskonsistenz nicht herstellen lässt. |
Paralleles Überprüfen von Objekten
Standardmäßig führt DBCC CHECKFILEGROUP eine parallele Überprüfung von Objekten durch. Der Grad der Parallelität wird automatisch durch den Abfrageprozessor bestimmt. Der Höchstgrad für die Parallelität wird genauso konfiguriert wie parallele Abfragen. Verwenden Sie sp_configure, um die maximale Anzahl von Prozessoren zu beschränken, die für DBCC-Überprüfungen verfügbar sind. Weitere Informationen finden Sie unter max degree of parallelism (Option).
Die parallele Überprüfung kann mithilfe des Ablaufverfolgungsflags 2528 deaktiviert werden. Weitere Informationen finden Sie unter Ablaufverfolgungsflags (Transact-SQL).
Nicht gruppierte Indizes für separate Dateigruppen
Wenn einem nicht gruppierten Index in der angegebenen Dateigruppe eine Tabelle in einer anderen Dateigruppe zugeordnet wird, wird der Index nicht überprüft, da die Basistabelle nicht für die Überprüfung verfügbar ist. Dies ist eine Verhaltensänderung in SQL Server 2005. In früheren Versionen von SQL Server werden der nicht gruppierte Index und die Basistabelle in der anderen Dateigruppe überprüft. Führen Sie DBCC CHECKDB aus, um die nicht gruppierten Indizes und die Basistabellen zu überprüfen.
Wenn eine Tabelle der angegebenen Dateigruppe einen nicht gruppierten Index in einer anderen Dateigruppe besitzt, wird der nicht gruppierte Index aus folgenden Gründen nicht überprüft:
Die Basistabellenstruktur ist unabhängig von der Struktur eines nicht gruppierten Indexes. Nicht gruppierte Indizes müssen zur Überprüfung der Gültigkeit der Basistabelle nicht durchsucht werden.
Mit dem Befehl DBCC CHECKFILEGROUP werden nur Objekte in der angegebenen Dateigruppe überprüft.
Ein gruppierter Index und eine Tabelle dürfen sich nicht in unterschiedlichen Dateigruppen befinden. Die vorausgegangenen Ausführungen gelten daher nur für nicht gruppierte Indizes.
Partitionierte Tabellen für separate Dateigruppen
In früheren Versionen von SQL Server 2005 als Service Pack 2 (SP2) überprüft DBCC CHECKFILEGROUP eine partitionierte Tabelle nur, wenn sich die gesamte Tabelle auf die angegebene Dateigruppe bezieht. Wenn die Tabelle über mehrere Dateigruppen verteilt ist, wird die gesamte Tabelle ignoriert. Wenn ab SP2 eine partitionierte Tabelle für mehrere Dateigruppen vorhanden ist, überprüft DBCC CHECKFILEGROUP die Partitionsrowsets, die für die angegebene Dateigruppe vorhanden sind, und ignoriert die Rowsets in den anderen Dateigruppen. In der Informationsmeldung 2594 werden die nicht überprüften Partitionen angegeben. Nicht gruppierte Indizes, die nicht in der angegebenen Dateigruppe vorhanden sind, werden nicht überprüft.
Grundlegendes zu DBCC-Fehlermeldungen
Nach Ausführung des DBCC CHECKFILEGROUP-Befehls wird eine Meldung im SQL Server-Fehlerprotokoll verzeichnet. Wurde der DBCC-Befehl erfolgreich ausgeführt, zeigt die Meldung den erfolgreichen Abschluss und die Ausführungsdauer des Befehls an. Wurde der DBCC-Befehl aufgrund eines Fehlers vor Abschluss der Überprüfung beendet, zeigt die Meldung an, dass der Befehl beendet wurde. Außerdem wird ein Statuswert und die Ausführungsdauer des Befehls angegeben. In der folgenden Tabelle sind die Statuswerte aufgeführt und beschrieben, die in der Meldung enthalten sein können.
Status |
Beschreibung |
---|---|
0 |
Fehlernummer 8930 wurde ausgelöst. Dies weist auf beschädigte Metadaten hin, die die Beendigung des DBCC-Befehls verursacht haben. |
1 |
Fehlernummer 8967 wurde ausgelöst. Ein interner DBCC-Fehler ist aufgetreten. |
2 |
Beim Reparieren einer Datenbank im Notfallmodus ist ein Fehler aufgetreten. |
3 |
Dies weist auf beschädigte Metadaten hin, die die Beendigung des DBCC-Befehls verursacht haben. |
4 |
Eine Assertations- oder Zugriffsverletzung wurde entdeckt. |
5 |
Ein unbekannter Fehler ist aufgetreten, der den DBCC-Befehl beendet hat. |
Fehlerberichterstellung
Eine Minidumpdatei (SQLDUMPnnnn.txt) wird jedes Mal im SQL Server-Verzeichnis "LOG" erstellt, wenn DBCC CHECKFILEGROUP einen Fehler durch eine Beschädigung erkennt. Falls die Funktionen zur Verwendung der Datensammlung und zur Fehlerberichterstellung für die SQL Server-Instanz aktiviert sind, wird die Datei automatisch an Microsoft weitergeleitet. Die gesammelten Daten werden zur Verbesserung der Funktionalität von SQL Server verwendet.
Die Sicherungsdatei enthält die Ergebnisse des DBCC CHECKFILEGROUP-Befehls sowie eine zusätzliche Diagnoseausgabe. Die Datei verfügt über eingeschränkte, besitzverwaltete Zugriffssteuerungslisten (Discretionary Access Control List, DACL). Der Zugriff ist auf das SQL Server-Dienstkonto und Mitglieder der sysadmin-Rolle beschränkt. Die sysadmin-Rolle enthält standardmäßig alle Mitglieder der Windows-Gruppe VORDEFINIERT\Administratoren und der Gruppe lokaler Administratoren. Ein Fehler bei der Datensammlung verursacht keinen Fehler des DBCC-Befehls.
Auflösen von Fehlern
Sollten Fehler von DBCC CHECKFILEGROUP gemeldet werden, wird die Wiederherstellung der Datenbank aus der Datenbanksicherung empfohlen. Beachten Sie, dass für DBCC CHECKFILEGROUP keine Reparaturoptionen angegeben werden können.
Falls keine Sicherung vorhanden ist, lassen sich die gemeldeten Fehler durch Ausführung von DBCC CHECKDB mit einer Reparaturoption beheben. Welche Reparaturoption dabei zu verwenden ist, wird am Ende der Liste mit den gemeldeten Fehlern angegeben. Soll die Fehlerkorrektur mithilfe der Option REPAIR_ALLOW_DATA_LOSS erfolgen, müssen möglicherweise einige Seiten, und damit auch Daten, gelöscht werden.
Resultsets
DBCC CHECKFILEGROUP gibt folgendes Resultset zurück (die tatsächlichen Werte können davon abweichen):
Es sei denn, ESTIMATEONLY oder NO_INFOMSGS wurde angegeben.
Für die aktuelle Datenbank (falls keine Datenbank angegeben wurde), ob Optionen (außer NOINDEX) angegeben wurden oder nicht.
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.
Wurde NO_INFOMSGS angegeben, gibt DBCC CHECKFILEGROUP Folgendes zurück:
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Wurde ESTIMATEONLY angegeben, gibt DBCC CHECKFILEGROUP Folgendes zurück (die tatsächlichen Werte können davon abweichen):
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.
Berechtigungen
Erfordert die Mitgliedschaft in der festen Serverrolle sysadmin oder der festen Datenbankrolle db_owner.
Beispiele
A. Überprüfen der Dateigruppe PRIMARY einer Datenbank
Das folgende Beispiel überprüft die primäre Dateigruppe der AdventureWorks2008R2-Datenbank.
USE AdventureWorks2008R2;
GO
DBCC CHECKFILEGROUP;
GO
B. Überprüfen der PRIMARY-Dateigruppe ohne nicht gruppierte Indizes
Das folgende Beispiel überprüft die primäre Dateigruppe der AdventureWorks2008R2-Datenbank (unter Ausschluss nicht gruppierter Indizes). Zu diesem Zweck werden die ID der primären Dateigruppe und NOINDEX angegeben.
USE AdventureWorks2008R2;
GO
DBCC CHECKFILEGROUP (1, NOINDEX);
GO
C. Überprüfen der PRIMARY-Dateigruppe mit Optionen
Im folgenden Beispiel wird die primäre Dateigruppe der master-Datenbank überprüft. Dabei wird die Option ESTIMATEONLY angegeben.
USE master;
GO
DBCC CHECKFILEGROUP (1)
WITH ESTIMATEONLY;