DBCC CHECKALLOC (Transact-SQL)
Aktualisiert: 17. November 2008
Überprüft die Konsistenz von Strukturen der Speicherplatzzuordnung für eine bestimmte Datenbank.
Transact-SQL-Syntaxkonventionen
Syntax
DBCC CHECKALLOC
[
( database_name | database_id | 0
[ , NOINDEX
| , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
)
[ WITH
{
[ ALL_ERRORMSGS ]
[ , NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
}
]
]
Argumente
database_name | database_id | 0
Name oder ID der Datenbank, für die die Zuordnung und Seitenverwendung überprüft werden soll. Wird kein Wert oder der Wert 0 angegeben, wird die aktuelle Datenbank verwendet.Datenbanknamen müssen den Regeln für Bezeichner entsprechen.
NOINDEX
Gibt an, dass nicht gruppierte Indizes für Benutzertabellen nicht überprüft werden sollen.Hinweis: NOINDEX wird nur aus Gründen der Abwärtskompatibilität beibehalten und hat keine Auswirkungen auf DBCC CHECKALLOC.
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Gibt an, dass DBCC CHECKALLOC gefundene Fehler behebt. database_name muss sich im Einzelbenutzermodus befinden.- REPAIR_ALLOW_DATA_LOSS
Versucht, die gefundenen Fehler zu beheben. Diese Reparaturen können zu Datenverlusten führen. REPAIR_ALLOW_DATA_LOSS ist die einzige Option, die die Reparatur von Zuordnungsfehlern ermöglicht.
- REPAIR_FAST
Die Syntax wird nur aus Gründen der Abwärtskompatibilität beibehalten. Es werden keine Reparaturaktionen ausgeführt.
- REPAIR_REBUILD
Nicht anwendbar.
Wichtig: Verwenden Sie die REPAIR-Optionen nur als letzte Möglichkeit. Zur Behebung von Fehlern ist es empfehlenswert, eine Sicherung wiederherzustellen. Bei Reparaturvorgängen werden keine Einschränkungen berücksichtigt, die möglicherweise in oder zwischen Tabellen vorhanden sind. Wenn die angegebene Tabelle an einer oder mehreren Einschränkungen beteiligt ist, ist es empfehlenswert, nach einem Reparaturvorgang DBCC CHECKCONSTRAINTS auszuführen. Wenn Sie REPAIR verwenden müssen, sollten Sie DBCC CHECKDB ohne Reparaturoption ausführen, um die zu verwendende Reparaturstufe zu ermitteln. Wenn Sie die REPAIR_ALLOW_DATA_LOSS-Ebene verwenden, empfiehlt es sich, die Datenbank vor dem Ausführen von DBCC CHECKDB zu sichern. - REPAIR_ALLOW_DATA_LOSS
- WITH
Aktiviert die Angabe von Optionen.
- ALL_ERRORMSGS
Zeigt alle Fehlermeldungen an. In SQL Server 2005 Service Pack 3 (SP3) werden alle Fehlermeldungen standardmäßig angezeigt. Das Angeben oder Weglassen dieser Option hat keine Auswirkungen. In vorherigen Versionen von SQL Server werden nur die ersten 200 Fehlermeldungen für jedes Objekt angezeigt, wenn ALL_ERRORMSGS nicht angegeben wird.
- NO_INFOMSGS
Unterdrückt alle Informationsmeldungen und die Anzeige des verwendeten Speicherplatzes.
- TABLOCK
Bewirkt, dass der DBCC-Befehl eine exklusive Datenbanksperre erhält.
- ESTIMATEONLY
Zeigt den geschätzten tempdb-Speicherplatz an, der zum Ausführen von DBCC CHECKALLOC mit allen anderen angegebenen Optionen erforderlich ist.
Resultsets
In den folgenden Tabellen werden die von DBCC CHECKALLOC zurückgegebenen Informationen beschrieben.
Element | Beschreibung |
---|---|
FirstIAM |
Nur zur internen Verwendung. |
Root |
Nur zur internen Verwendung. |
Dpages |
Anzahl von Datenseiten. |
Pages used |
Zugeordnete Seiten. |
Dedicated extents |
Dem Objekt zugeordnete Blöcke. Wenn Seiten mit gemischter Zuordnung verwendet werden, kann es Seiten geben, die ohne Blöcke zugeordnet sind. |
DBCC CHECKALLOC meldet außerdem eine Zuordnungszusammenfassung für jeden Index und jede Partition in jeder Datei. In dieser Zusammenfassung wird die Verteilung der Daten beschrieben.
Element | Beschreibung |
---|---|
Reserved pages |
Seiten, die für den Index zugeordnet wurden, und nicht verwendete Seiten in zugeordneten Blöcken. |
Used pages |
Zugeordnete Seiten, die vom Index verwendet werden. |
Partition ID |
Nur zur internen Verwendung. |
Alloc unit ID |
Nur zur internen Verwendung. |
In-row data |
Seiten enthalten Index- oder Heapdaten. |
LOB data |
Seiten enthalten Daten vom Typ varchar(max), nvarchar(max), varbinary(max), text, ntext, xml und image. |
Row-overflow data |
Seiten enthalten Daten einer Spalte mit variabler Länge, die durch Ausführen eines Pushs außerhalb von Zeilen verschoben wurden. |
DBCC CHECKALLOC gibt das folgende Resultset zurück (die tatsächlichen Werte können davon abweichen), außer wenn ESTIMATEONLY oder NO_INFOMSGS angegeben wird.
DBCC results for 'master'.
************************************************************* Table sysobjects Object ID 1. Index ID 1 FirstIAM (1:11) Root (1:12) Dpages 22. Index ID 1. 24 pages used in 5 dedicated extents. Index ID 2 FirstIAM (1:1368) Root (1:1362) Dpages 10. Index ID 2. 12 pages used in 2 dedicated extents. Index ID 3 FirstIAM (1:1392) Root (1:1408) Dpages 4. Index ID 3. 6 pages used in 0 dedicated extents. Total number of extents is 7. ************************************************************* '...' ************************************************************* Table spt_server_info Object ID 1938105945. Index ID 1 FirstIAM (1:520) Root (1:508) Dpages 1. Index ID 1. 3 pages used in 0 dedicated extents. Total number of extents is 0. ************************************************************* Processed 52 entries in sysindexes for database ID 1. File 1. Number of extents = 210, used pages = 1126, reserved pages = 1280. File 1 (number of mixed extents = 73, mixed pages = 184). Object ID 1, Index ID 0, data extents 5, pages 24, mixed extent pages 9. '...' Object ID 1938105945, Index ID 0, data extents 0, pages 3, mixed extent pages 3. Total number of extents = 210, used pages = 1126, reserved pages = 1280 in this database. (number of mixed extents = 73, mixed pages = 184) in this database. CHECKALLOC found 0 allocation errors and 0 consistency errors in database 'master'. DBCC results for 'master'. ************************************************************* Table sys.sysrowsetcolumns Object ID 4. Index ID 1, partition ID 262144, alloc unit ID 262144 (type In-row data). FirstIAM (1:98). Root (1:94). Dpages 7. Index ID 1, partition ID 262144, alloc unit ID 262144 (type In-row data). 9 pages used in 1 dedicated extents. Index ID 1, partition ID 262144, alloc unit ID 262398 (type Row-overflow data). FirstIAM (0:0). Root (0:0). Dpages 0. Index ID 1, partition ID 262144, alloc unit ID 262398 (type Row-overflow data). 0 pages used in 0 dedicated extents. Total number of extents is 1. ... ************************************************************* Processed 201 entries in system catalog for database ID 1. File 1. Number of extents = 44, used pages = 300, reserved pages = 345. File 1 (number of mixed extents = 29, mixed pages = 225). Object ID 4, index ID 1, partition ID 262144, alloc unit ID 262144 (type In-row data), data extents 1, pages 9, mixed extent pages 8. Object ID 5, index ID 1, partition ID 327680, alloc unit ID 327680 (type In-row data), data extents 0, pages 2, mixed extent pages 2. Object ID 7, index ID 1, partition ID 458752, alloc unit ID 458752 (type In-row data), data extents 0, pages 5, mixed extent pages 5. Object ID 8, index ID 0, partition ID 524288, alloc unit ID 524288 (type In-row data), data extents 0, pages 2, mixed extent pages 2. Object ID 13, index ID 1, partition ID 851968, alloc unit ID 851968 (type In-row data), data extents 1, pages 9, mixed extent pages 8. Object ID 15, index ID 1, partition ID 983040, alloc unit ID 983040 (type In-row data), data extents 0, pages 2, mixed extent pages 2. Object ID 26, index ID 1, partition ID 281474978414592, alloc unit ID 1703937 (type In-row data), data extents 0, pages 3, mixed extent pages 3. Object ID 27, index ID 1, partition ID 281474978480128, alloc unit ID 1769473 (type In-row data), data extents 0, pages 3, mixed extent pages 3. Object ID 27, index ID 2, partition ID 562949955190784, alloc unit ID 1769474 (type In-row data), index extents 0, pages 3, mixed extent pages 3. ... Object ID 1179151246, index ID 1, partition ID 72057594038845440, alloc unit ID 13435136 (type In-row data), data extents 2, pages 18, mixed extent pages 8. Object ID 1179151246, index ID 2, partition ID 72057594038910976, alloc unit ID 13566208 (type In-row data), index extents 1, pages 16, mixed extent pages 8. Object ID 1911677858, index ID 0, partition ID 72057594039631872, alloc unit ID 15073536 (type In-row data), data extents 0, pages 2, mixed extent pages 2. Total number of extents = 41, used pages = 289, reserved pages = 323 in this database. (number of mixed extents = 27, mixed pages = 211) in this database. CHECKALLOC found 0 allocation errors and 0 consistency errors in database 'master'. DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Wenn ESTIMATEONLY angegeben wird, gibt DBCC CHECKALLOC das folgende Resultset zurück.
Estimated TEMPDB space needed for CHECKALLOC (KB)
-------------------------------------------------
34
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Hinweise
DBCC CHECKALLOC überprüft die Zuordnung aller Seiten in der Datenbank, unabhängig vom Typ der Seite oder des Objekts, zu dem sie gehören. Außerdem überprüft der Befehl die verschiedenen internen Strukturen, mit deren Hilfe diese Seiten und die Beziehungen zwischen ihnen nachverfolgt werden.
Wird NO_INFOMSGS nicht angegeben, erfasst DBCC CHECKALLOC Informationen zur Speicherplatznutzung für alle Objekte in der Datenbank. Diese Informationen werden anschließend zusammen mit den gefundenen Fehlern gedruckt.
Hinweis: |
---|
Die Funktionalität von DBCC CHECKALLOC ist in DBCC CHECKDB und DBCC CHECKFILEGROUP enthalten. Dies bedeutet, dass Sie DBCC CHECKALLOC nicht gesondert von diesen Anweisungen ausführen müssen. |
Interner Datenbanksnapshot
DBCC CHECKALLOC verwendet einen internen Datenbanksnapshot, um die für die Durchführung dieser Überprüfungen erforderliche Transaktionskonsistenz bereitzustellen. Wenn ein Snapshot nicht erstellt werden kann oder TABLOCK angegeben ist, versucht DBCC CHECKALLOC, eine exklusive Sperre (X) für die Datenbank abzurufen, um die erforderliche Konsistenz zu erhalten. Weitere Informationen zu Sperren finden Sie unter Sperrmodi.
Hinweis: |
---|
In SQL Server 2005 werden beim Ausführen von DBCC CHECKALLOC für tempdb keine Überprüfungen ausgeführt. Der Grund hierfür liegt darin, dass aus Leistungsgründen für tempdb keine Datenbanksnapshots verfügbar sind. Dies bedeutet, dass die erforderliche Transaktionskonsistenz nicht erhalten werden kann. Beenden Sie den MSSQLSERVER-Dienst, und starten Sie ihn neu, um Zuordnungsprobleme mit tempdb zu beheben. Durch diese Aktion wird die tempdb-Datenbank gelöscht und neu erstellt. |
Grundlegendes zu DBCC-Fehlermeldungen
Nach Abschluss des Befehls DBCC CHECKALLOC 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, wird in einer Meldung angezeigt, dass der Befehl beendet wurde. Außerdem werden 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 als Ursache für das Beenden des DBCC-Befehls hin. |
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 als Ursache für das Beenden des DBCC-Befehls hin. |
4 |
Eine Assertations- oder Zugriffsverletzung wurde entdeckt. |
5 |
Ein unbekannter Fehler ist aufgetreten, durch den der DBCC-Befehl beendet wurde. |
Fehlerberichterstellung
In SQL Server 2005 Service Pack 1 (SP1) wird jedes Mal eine Minidumpdatei (SQLDUMPnnnn.txt) im SQL Server-Verzeichnis LOG erstellt, wenn DBCC CHECKALLOC einen Fehler durch eine Beschädigung erkennt. Wenn die Features zur Erfassung von Featureverwendungsdaten 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. Weitere Informationen finden Sie unter Einstellungen für Fehler- und Verwendungsberichte.
Die Sicherungsdatei enthält die Ergebnisse des DBCC CHECKALLOC-Befehls sowie eine zusätzliche Diagnoseausgabe. Die Datei hat eingeschränkte freigegebene 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
Wenn DBCC CHECKALLOC Fehler meldet, sollten Sie die Datenbank aus der Datenbanksicherung wiederherstellen, statt eine Reparatur auszuführen. Wenn keine Sicherung vorhanden ist, können die gemeldeten Fehler durch das Ausführen einer Reparatur behoben werden. Beim Beheben der Fehler kann es jedoch erforderlich sein, einige Seiten (und somit Daten) zu löschen.
Eine Reparatur kann in einer Benutzertransaktion ausgeführt werden. Dies ermöglicht ein Rollback der Änderungen. Wenn für Änderungen ein Rollback ausgeführt wird, enthält die Datenbank immer noch Fehler und muss von einer Datensicherung wiederhergestellt werden. Nach Abschluss der Reparaturen sollten Sie eine Sicherung der Datenbank ausführen.
Berechtigungen
Erfordert die Mitgliedschaft in der festen Serverrolle sysadmin oder in der festen Datenbankrolle db_owner.
Beispiele
Im folgenden Beispiel wird DBCC CHECKALLOC
für die aktuelle Datenbank und für die AdventureWorks
-Datenbank ausgeführt.
-- Check the current database.
DBCC CHECKALLOC;
GO
-- Check the AdventureWorks database.
DBCC CHECKALLOC (AdventureWorks);
GO
Siehe auch
Verweis
Andere Ressourcen
Organisationsstruktur von Tabellen und Indizes
Verwalten des von Objekten verwendeten Speicherplatzes
Hilfe und Informationen
Informationsquellen für SQL Server 2005
Änderungsverlauf
Version | Verlauf |
---|---|
17. November 2008 |
|
14. April 2006 |
|
05. Dezember 2005 |
|