Freigeben über

  • Artikel

DBCC CHECKTABLE (Transact-SQL)

Überprüft die Integrität aller Seiten und Strukturen, aus denen die Tabelle oder indizierte Sicht besteht.

Themenlink (Symbol)Transact-SQL-Syntaxkonventionen

Syntax

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 } ] 
        }
    ]

Argumente

  • table_name | view_name
    Die Tabelle oder indizierte Sicht, für die Integritätsüberprüfungen ausgeführt werden sollen. Tabellen- oder Sichtnamen müssen den Regeln für Bezeichner entsprechen.

  • NOINDEX
    Gibt an, dass keine intensiven Überprüfungen von nicht gruppierten Indizes für Benutzertabellen ausgeführt werden sollen. Dadurch wird die Gesamtausführungsdauer verkürzt. NOINDEX hat keine Auswirkungen auf Systemtabellen, da die Integritätsüberprüfungen immer für alle Systemtabellenindizes ausgeführt werden.

  • index_id
    Die Index-ID, für die Integritätsüberprüfungen ausgeführt werden sollen. Wird index_id angegeben, führt DBCC CHECKTABLE Integritätsüberprüfungen nur für den entsprechenden Index zusammen mit dem Heap oder gruppierten Index aus.

  • REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
    Legt fest, dass DBCC CHECKTABLE gefundene Fehler behebt. Zum Verwenden einer Reparaturoption muss sich die Datenbank im Einzelbenutzermodus befinden.

    • REPAIR_ALLOW_DATA_LOSS
      Versucht, alle gemeldeten Fehler zu beheben. Diese Reparaturen können zu Datenverlusten führen.

    • REPAIR_FAST
      Die Syntax wird nur aus Gründen der Abwärtskompatibilität bereitgestellt. Es werden keine Reparaturaktionen ausgeführt.

    • REPAIR_REBUILD
      Führt Reparaturen aus, bei denen kein Datenverlust möglich ist. Dazu können schnelle Reparaturen gehören, wie z. B. das Reparieren fehlender Zeilen in nicht gruppierten Indizes, als auch zeitaufwändigere Reparaturen, wie das Neuerstellen von Indizes.

      REPAIR_REBUILD behebt keine Fehler, die FILESTREAM-Daten betreffen.

    HinweisHinweis

    Verwenden Sie die REPAIR-Optionen nur als letzte Möglichkeit. Zum Reparieren von Fehlern empfiehlt sich das Wiederherstellen mithilfe einer Sicherung. 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, führen Sie DBCC CHECKTABLE ohne Reparaturoption aus, um die zu verwendende Reparaturstufe zu ermitteln. Wenn Sie die REPAIR_ALLOW_DATA_LOSS-Ebene verwenden möchten, empfiehlt es sich, die Datenbank vor dem Ausführen von DBCC CHECKTABLE mit dieser Option zu sichern.

  • ALL_ERRORMSGS
    Zeigt eine unbegrenzte Anzahl von Fehlern an. Alle Fehlermeldungen werden standardmäßig angezeigt. Das Angeben oder Weglassen dieser Option hat keine Auswirkungen.

  • EXTENDED_LOGICAL_CHECKS
    Wenn der Kompatibilitätsgrad 100 (SQL Server 2008) oder höher ist, werden logische Konsistenzprüfungen für eine indizierte Sicht, XML-Indizes und räumliche Indizes (sofern vorhanden) ausgeführt.

    Weitere Informationen finden Sie unter "Ausführen logischer Konsistenzprüfungen an Indizes" im Abschnitt mit den Hinweisen weiter unten in diesem Thema.

  • NO_INFOMSGS
    Alle Informationsmeldungen werden unterdrückt.

  • TABLOCK
    Bewirkt, dass DBCC CHECKTABLE eine freigegebene Tabellensperre erhält, statt eine interne Datenbankmomentaufnahme zu verwenden. Durch TABLOCK wird DBCC CHECKTABLE für eine Tabelle bei starker Belastung schneller ausgeführt, jedoch wird während der Ausführung von DBCC CHECKTABLE die in der Tabelle verfügbare Parallelität verringert.

  • ESTIMATEONLY
    Zeigt den tempdb-Speicherplatz an, der schätzungsweise erforderlich ist, um DBCC CHECKTABLE mit allen 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. Wurde entworfen, um mit geringem Verwaltungsaufwand eine Überprüfung der physischen Konsistenz der Tabelle vorzunehmen. Dabei können auch zerrissene Seiten und häufige Hardwarefehler erkannt werden, die die Daten gefährden können. Die vollständige Ausführung von DBCC CHECKTABLE 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 CHECKTABLE für große Tabellen. Es wird daher für die häufige Verwendung in Produktionssystemen empfohlen. Dennoch ist eine vollständige Ausführung von DBCC CHECKTABLE 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 setzt immer NO_INFOMSGS voraus und kann nicht mit einer Reparaturoption verwendet werden.

    HinweisHinweis

    Bei Angabe von PHYSICAL_ONLY überspringt DBCC CHECKTABLE alle Prüfungen der FILESTREAM-Daten.

  • DATA_PURITY
    Bewirkt, dass DBCC CHECKTABLE die Tabelle auf Spaltenwerte überprüft, die ungültig sind oder außerhalb des zulässigen Bereichs liegen. So können mit DBCC CHECKTABLE beispielsweise Spalten mit Datums- und Uhrzeitwerten erkannt werden, die außerhalb des zulässigen Bereichs für den datetime-Datentyp liegen, oder es werden decimal-Spalten oder Spalten mit einem ungefähren numerischen Datentyp erkannt, die ungültige Dezimal- oder Genauigkeitswerte enthalten.

    Bei Datenbanken, die in SQL Server 2005 und höher erstellt werden, ist die Überprüfung der Spaltenwertintegrität standardmäßig aktiviert; die Option DATA_PURITY ist in diesem Fall nicht erforderlich. Bei Datenbanken, die von früheren Versionen von SQL Server aktualisiert wurden, können Sie mit DBCC CHECKTABLE WITH DATA_PURITY Fehler in einer bestimmten Tabelle suchen und beheben, jedoch ist die Spaltenwertprüfung standardmäßig erst dann aktiviert, wenn DBCC CHECKDB WITH DATA_PURITY fehlerfrei für die Datenbank ausgeführt wurde. Danach wird die Spaltenwertintegrität standardmäßig von DBCC CHECKDB und DBCC CHECKTABLE überprüft.

    Mit dieser Option gemeldete Überprüfungsfehler können nicht mithilfe der DBCC-Reparaturoptionen behoben werden. Informationen zur manuellen Behebung dieser Fehler finden Sie im Knowledge Base-Artikel 923247: Fehlerbehebung für DBCC-Fehler 2570 in SQL Server 2005 (maschinelle Übersetzung).

    Wenn PHYSICAL_ONLY angegeben ist, wird die Spaltenintegrität nicht überprüft.

Hinweise

HinweisHinweis

Verwenden Sie DBCC CHECKDB, um DBCC CHECKTABLE für jede Tabelle der Datenbank auszuführen.

DBCC CHECKTABLE überprüft für die angegebene Tabelle Folgendes:

  • Überprüft, ob die Index-, LOB- und Zeilenüberlauf-Datenseiten sowie die Datenseiten in Zeilen richtig verknüpft sind.

  • Überprüft, ob sich die Indizes in der richtigen Sortierreihenfolge befinden.

  • Überprüft, ob die Zeiger konsistent sind.

  • Überprüft, ob die Daten auf jeder Seite sinnvoll sind, einschließlich berechneter Spalten.

  • Überprüft, ob die Seitenoffsets sinnvoll sind.

  • Überprüft, ob es für jede Zeile in der Basistabelle eine entsprechende Zeile in jedem nicht gruppierten Index gibt und umgekehrt.

  • Überprüft, ob sich jede Zeile in einer partitionierten Tabelle oder einem partitionierten Index in der richtigen Partition befindet.

  • Überprüft die Konsistenz auf Linkebene zwischen dem Dateisystem und der Tabelle, wenn die varbinary(max)-Daten mit FILESTREAM im Dateisystem gespeichert werden.

Ausführen logischer Konsistenzprüfungen an Indizes

Die logische Konsistenzprüfung an Indizes variiert wie folgt je nach dem Kompatibilitätsgrad der Datenbank:

  • Wenn der Kompatibilitätsgrad 100 (SQL Server 2008) oder höher ist:

    • DBCC CHECKTABLE führt sowohl physische als auch logische Konsistenzprüfungen für eine einzelne Tabelle und alle nicht gruppierten Indizes aus, sofern nicht NOINDEX angegeben wird. Allerdings werden an XML-Indizes, räumlichen Indizes und indizierten Sichten standardmäßig nur physische Konsistenzprüfungen ausgeführt.

    • Bei Angabe von WITH EXTENDED_LOGICAL_CHECKS werden logische Konsistenzprüfungen an indizierten Sichten, XML-Indizes und räumlichen Indizes (sofern vorhanden) ausgeführt. Standardmäßig werden physische Konsistenzprüfungen vor den logischen Konsistenzprüfungen ausgeführt. Wenn NOINDEX ebenfalls angegeben wird, werden nur die logischen Prüfungen ausgeführt.

      Diese logischen Konsistenzprüfungen überprüfen die interne Indextabelle des Indexobjekts anhand der Benutzertabelle, auf die verwiesen wird. Zum Auffinden externer Zeilen wird eine interne Abfrage konstruiert, um eine vollständige Schnittmenge der internen Tabellen und der Benutzertabellen zu bilden. Die Ausführung dieser Abfrage kann sich sehr stark auf die Leistung auswirken, und ihr Status kann nicht verfolgt werden. Daher empfiehlt es sich, WITH EXTENDED_LOGICAL_CHECKS nur dann anzugeben, wenn Sie Indexprobleme vermuten, die nicht mit einer physischen Beschädigung in Zusammenhang stehen, oder wenn die Prüfsummen auf Seitenebene deaktiviert wurden und Sie eine Beschädigung der Hardware auf Spaltenebene vermuten.

    • Bei einem gefilterten Index prüft DBCC CHECKDB anhand von Konsistenzprüfungen, ob die Indexeinträge dem Filterprädikat entsprechen.

  • Wenn der Kompatibilitätsgrad 90 oder weniger beträgt, führt DBCC CHECKTABLE sowohl physische als auch logische Konsistenzprüfungen für eine einzelne Tabelle oder indizierte Sicht und für alle nicht gruppierten Indizes und XML-Indizes aus, sofern nicht NOINDEX angegeben wird. Räumliche Indizes werden nicht unterstützt.

So erfahren Sie den Kompatibilitätsgrad einer Datenbank

Interne Datenbankmomentaufnahme

DBCC CHECKTABLE verwendet eine interne Datenbankmomentaufnahme, um die für die Ausführung dieser Überprüfungen erforderliche Transaktionskonsistenz bereitzustellen. Weitere Informationen finden Sie unter Grundlegendes zur Größe von Dateien mit geringer Dichte in Datenbankmomentaufnahmen und im Abschnitt über die Verwendung von internen Datenbankmomentaufnahmen in DBCC unter DBCC (Transact-SQL).

Wenn eine Momentaufnahme nicht erstellt werden kann oder TABLOCK angegeben ist, erwirbt DBCC CHECKTABLE eine freigegebene Tabellensperre, um die erforderliche Konsistenz zu erhalten.

HinweisHinweis

Wird DBCC CHECKTABLE für tempdb ausgeführt, muss eine freigegebene Tabellensperre erworben 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.

Überprüfen und Reparieren von FILESTREAM-Daten

Wenn FILESTREAM für eine Datenbank und eine Tabelle aktiviert ist, können Sie varbinary(max)-BLOBs (Binary Large Objects) optional im Dateisystem speichern. Wenn Sie DBCC CHECKTABLE für eine Tabelle verwenden, die BLOBs im Dateisystem speichert, überprüft DBCC die Konsistenz auf Linkebene zwischen dem Dateisystem und der Datenbank.

Wenn eine Tabelle beispielsweise eine varbinary(max)-Spalte mit dem FILESTREAM-Attribut enthält, überprüft DBCC CHECKTABLE, ob zwischen den Dateisystemverzeichnissen und -dateien und den Tabellenzeilen, Spalten und Spaltenwerten eine 1:1-Zuordnung besteht. DBCC CHECKTABLE kann Beschädigungen reparieren, wenn Sie die REPAIR_ALLOW_DATA_LOSS-Option angeben. Zum Reparieren einer FILESTREAM-Beschädigung löscht DBCC alle Tabellenzeilen, für die Dateisystemdaten fehlen, sowie alle Verzeichnisse und Dateien, die keiner Tabellenzeile, keiner Spalte oder keinem Spaltenwert zugeordnet sind.

Paralleles Überprüfen von Objekten

Standardmäßig führt DBCC CHECKTABLE eine parallele Überprüfung von Objekten durch. Der Grad der Parallelität wird automatisch durch den Abfrageprozessor bestimmt. Der maximale Grad der Parallelität wird auf dieselbe Weise konfiguriert wie der maximale Grad bei parallelen 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).

HinweisHinweis

Während eines DBCC CHECKTABLE-Vorgangs müssen die Bytes, die in einer Spalte eines benutzerdefinierten Typs gespeichert sind, dessen Sortierreihenfolge eine Bytereihenfolge ist, gleich der berechneten Serialisierung des UDT-Werts (User-Defined Type, benutzerdefinierter Typ) sein. Falls dies nicht zutrifft, meldet die DBCC CHECKTABLE-Routine einen Konsistenzfehler.

Grundlegendes zu DBCC-Fehlermeldungen

Nach Beendigung des Befehls DBCC CHECKTABLE wird eine Meldung in das SQL Server-Fehlerprotokoll geschrieben. Wenn der DBCC-Befehl erfolgreich ausgeführt wird, gibt die Meldung einen erfolgreichen Abschluss und die Dauer der Befehlsausführung 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, durch den der DBCC-Befehl beendet wurde.

Fehlerberichterstellung

Eine Minidumpdatei (SQLDUMPnnnn.txt) wird jedes Mal im SQL Server-Verzeichnis LOG erstellt, wenn DBCC CHECKTABLE einen Fehler durch eine Beschädigung erkennt. Falls die Funktionen zur Erfassung von Funktionsverwendungsdaten 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 CHECKTABLE-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.

Beheben von Fehlern

Wenn DBCC CHECKTABLE Fehler meldet, ist es empfehlenswert, die Datenbank aus der Datenbanksicherung wiederherzustellen, statt REPAIR mit einer der REPAIR-Optionen auszuführen. Ist keine Sicherung vorhanden, können durch das Ausführen von REPAIR die gemeldeten Fehler behoben werden. Die zu verwendende REPAIR-Option wird am Ende der Liste der gemeldeten Fehler angegeben. Beim Beheben der Fehler mithilfe der REPAIR_ALLOW_DATA_LOSS-Option ist es jedoch möglicherweise erforderlich, einige Seiten (und somit Daten) zu löschen.

Die Reparatur kann im Rahmen einer Benutzertransaktion ausgeführt werden, damit der Benutzer für die vorgenommenen Änderungen ggf. ein Rollback ausführen kann. Falls für Reparaturen ein Rollback ausgeführt wird, enthält die Datenbank immer noch Fehler und muss aus einer Datensicherung wiederhergestellt werden. Sichern Sie die Datenbank nach dem Abschluss aller Reparaturen.

Resultsets

DBCC CHECKTABLE gibt das folgende Resultset zurück. Das gleiche Resultset wird zurückgegeben, wenn Sie nur den Tabellennamen oder eine der Optionen angeben.

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 gibt das folgende Resultset zurück, wenn die ESTIMATEONLY-Option angegeben wurde:

Estimated TEMPDB space needed for CHECKTABLES (KB) 
-------------------------------------------------- 
21
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Berechtigungen

Der Benutzer muss Besitzer der Tabelle oder Mitglied der festen Serverrolle sysadmin, der festen Datenbankrolle db_owner oder der festen Datenbankrolle db_ddladmin sein.

Beispiele

A. Überprüfen einer bestimmten Tabelle

Im folgenden Beispiel wird die Datenseitenintegrität der HumanResources.Employee -Tabelle in der AdventureWorks2008R2-Datenbank überprüft.

USE AdventureWorks2008R2;
GO
DBCC CHECKTABLE ("HumanResources.Employee");
GO

B. Ausführen einer Überprüfung der Tabelle mit geringem Verwaltungsaufwand

Im folgenden Beispiel wird eine Überprüfung der Employee -Tabelle in der AdventureWorks2008R2-Datenbank mit geringem Verwaltungsaufwand ausgeführt.

USE AdventureWorks2008R2;
GO
DBCC CHECKTABLE ("HumanResources.Employee") WITH PHYSICAL_ONLY;
GO

C. Überprüfen eines bestimmten Indexes

Im folgenden Beispiel wird ein bestimmter Index überprüft, der durch Zugreifen auf sys.indexes ermittelt wird.

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