Freigeben über

DBCC CHECKTABLE (Transact-SQL)

  • Artikel

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance

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

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 } ]
          [ , MAXDOP = number_of_processors ]
        }
    ]

Argumente

table_name | view_name

Dies ist 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

Hiermit wird festgelegt, dass nicht gruppierte Indizes für Benutzertabellen nicht intensiv überprüft werden sollen. Dadurch wird die Ausführungsdauer insgesamt verkürzt. NOINDEX hat keine Auswirkungen auf Systemtabellen, da die Integritätsüberprüfungen immer für alle Systemtabellenindizes ausgeführt werden.

index_id

Dies ist 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

Hiermit wird angegeben, dass DBCC CHECKTABLE die gefundenen Fehler behebt. Zum Verwenden einer Reparaturoption muss sich die Datenbank im Einzelbenutzermodus befinden.

  • REPAIR_ALLOW_DATA_LOSS

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

  • REPAIR_FAST

    Die Syntax wird nur aus Gründen der Abwärtskompatibilität beibehalten. 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.

    Dieses Argument behebt keine Fehler, die FILESTREAM-Daten betreffen.

Wichtig

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 bestehen. 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 CHECKTABLE ohne Reparaturoption ausführen, um die zu verwendende Reparaturstufe zu ermitteln. Wenn Sie die Ebene REPAIR_ALLOW_DATA_LOSS 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 Kompatiblitätsgrad 100 (in SQL Server 2008 10.0.x eingeführt) beträgt, führt diese Option logische Konsistenzprüfungen für eine indizierte Sicht, XML-Indizes und räumliche Indizes (sofern vorhanden) aus.

Weitere Informationen finden Sie unter Ausführen logischer Konsistenzprüfungen für Indizes im Abschnitt Hinweise weiter unten in diesem Artikel.

NO_INFOMSGS

Alle Informationsmeldungen werden unterdrückt.

TABLOCK

Dies bewirkt, dass DBCC CHECKTABLE eine freigegebene Tabellensperre erhält, anstatt eine interne Datenbankmomentaufnahme zu verwenden. Durch TABLOCK wird DBCC CHECKTABLE schneller in einer stark ausgelasteten Tabelle ausgeführt, allerdings verringert sich während der Ausführung von DBCC CHECKTABLE die in der Tabelle verfügbare Parallelität.

ESTIMATEONLY

Hiermit wird der tempdb-Speicherplatz angezeigt, 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 erfolgt normalerweise aus einem der folgenden Gründe:

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

Hinweis

In der Dokumentation wird der Begriff „B-Struktur“ im Allgemeinen in Bezug auf Indizes verwendet. In Zeilenspeicherindizes implementiert die Datenbank-Engine eine B+-Struktur. Dies gilt nicht für Columnstore-Indizes oder In-Memory-Datenspeicher. Weitere Informationen finden Sie im Leitfaden zur Architektur und zum Entwerfen von SQL Server- und Azure SQL-Indizes.

Daher führt das Verwenden der Option PHYSICAL_ONLY möglicherweise zu einer viel kürzeren Ausführungszeit von DBCC CHECKTABLE für große Tabellen. Sie 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 impliziert stets NO_INFOMSGS und kann nicht mit den Reparaturoptionen verwendet werden.

Hinweis

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

DATA_PURITY

Dies 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 Zeitwerten erkannt werden, die außerhalb des zulässigen Bereichs für den datetime-Datentyp liegen, oder es werden decimal-Spalten oder Spalten mit einem angenäherten numerischen Datentyp erkannt, die ungültige Dezimal- oder Genauigkeitswerte enthalten.

Die Überprüfung der Spaltenwertintegrität ist standardmäßig aktiviert. Die Option DATA_PURITY ist nicht erforderlich. Bei Datenbanken, für die ein Upgrade aus früheren Versionen von SQL Server ausgeführt wurde, können Sie DBCC CHECKTABLE WITH DATA_PURITY verwenden, um Fehler in einer bestimmten Tabelle zu suchen und zu beheben. Spaltenwertüberprüfungen sind für die Tabelle jedoch nicht standardmäßig aktiviert. Die Aktivierung erfolgt erst, wenn DBCC CHECKDB WITH DATA_PURITY für die Datenbank fehlerfrei ausgeführt wurde. Danach überprüfen DBCC CHECKDB und DBCC CHECKTABLE standardmäßig die Spaltenwertintegrität.

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: Problembehandlung bei DBCC-Fehler 2570 in SQL Server 2005 und höher.

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

MAXDOP

Gilt für: SQL Server 2014 (12.x) Service Pack 2 und höhere Versionen

Überschreibt die Konfigurationsoption Max. Grad an Parallelität von sp_configure für die Anweisung. MAXDOP kann den mit sp_configure konfigurierten Wert überschreiten. Wenn MAXDOP den mit Resource Governor konfigurierten Wert überschreitet, verwendet die Datenbank-Engine den in „ALTER WORKLOAD GROUP (Transact-SQL)“ beschriebenen MAXDOP-Wert von Resource Governor. Alle mit der Konfigurationsoption Max. Grad an Parallelität verwendeten semantischen Regeln gelten auch für die Verwendung des MAXDOP-Abfragehinweises. Weitere Informationen finden Sie unter Konfigurieren der Serverkonfigurationsoption Max. Grad an Parallelität.

Hinweis

Wenn MAXDOP auf 0 (Null) festgelegt wird, wählt der Server den maximalen Grad an Parallelität aus.

Bemerkungen

Hinweis

Verwenden Sie DBCC CHECKDB, um DBCC CHECKTABLE für jede Tabelle in 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.

Durchführen logischer Konsistenzprüfungen für 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 10.0.x) oder höher lautet:

    • Sofern NOINDEX nicht angegeben ist, führt DBCC CHECKTABLE sowohl physische als auch logische Konsistenzprüfungen für eine einzelne Tabelle und alle zugehörigen, nicht gruppierten Indizes aus. 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 Prüfungen für eine indizierte Sicht, 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 ist, 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 erheblich auf die Leistung auswirken, und ihr Status kann nicht nachverfolgt 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 CHECKTABLE anhand von Konsistenzprüfungen, ob die Indexeinträge dem Filterprädikat entsprechen.

  • Ab SQL Server 2016 (13.x) werden zusätzliche Überprüfungen von persistierten berechneten Spalten, UDT-Spalten und gefilterten Indizes nicht standardmäßig ausgeführt, um die teuren Auswertungen von Ausdrücken zu vermeiden. Durch diese Änderung wird die Dauer der Ausführung von CHECKTABLE für Datenbanken stark reduziert, die diese Objekte enthalten. Die physischen Konsistenzprüfungen dieser Objekte werden jedoch immer abgeschlossen. Nur wenn die Option EXTENDED_LOGICAL_CHECKS angegeben ist, werden die Ausdrucksauswertungen zusätzlich zu logischen Prüfungen ausgeführt, die bereits als Teil der Option EXTENDED_LOGICAL_CHECKS vorhanden sind (indizierte Sicht, XML-Indizes und räumliche Indizes).

  • Wenn der Kompatibilitätsgrad 90 (SQL Server 2005 (9.x)) 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 ermitteln 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 Anzeigen der Größe der Sparsedatei einer Datenbankmomentaufnahme (Transact-SQL) und im Abschnitt Verwenden einer internen Datenbank-Momentaufnahme mit DBCC unter DBCC (Transact-SQL).

Wenn keine Momentaufnahme erstellt werden kann oder TABLOCK angegeben wird, wendet DBCC CHECKTABLE eine freigegebene Tabellensperre an, um die erforderliche Konsistenz zu erzielen.

Hinweis

Wenn DBCC CHECKTABLE für tempdb ausgeführt wird, muss eine freigegebene Tabellensperre angewendet werden. Dies liegt daran, dass aus Leistungsgründen keine Datenbankmomentaufnahmen für tempdb verfügbar sind. Dies bedeutet, dass die erforderliche Transaktionskonsistenz nicht erhalten werden kann.

Ü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 Option REPAIR_ALLOW_DATA_LOSS 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 Objektüberprüfung aus. 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 Konfigurieren der Serverkonfigurationsoption Max. Grad an Parallelität.

Die parallele Überprüfung kann mithilfe des Ablaufverfolgungsflags 2528 deaktiviert werden. Weitere Informationen finden Sie unter Ablaufverfolgungsflags (Transact-SQL).

Hinweis

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 Werts des benutzerdefinierten Typs sein. Falls dies nicht zutrifft, meldet die DBCC CHECKTABLE-Routine einen Konsistenzfehler.

Hinweis

Diese Funktion ist nicht in jeder Edition von SQL Serververfügbar. Weitere Informationen finden Sie unter „Parallele Konsistenzprüfung“ im Abschnitt zur RDBMS-Verwaltbarkeit des Artikels Editionen und unterstützte Features von SQL Server 2022.

Grundlegendes zu DBCC-Fehlermeldungen

Nachdem der Befehl DBCC CHECKTABLE ausgeführt wurde, wird eine Meldung in das SQL Server-Fehlerprotokoll geschrieben. 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.

State 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.

Fehlerberichterstattung

Eine kleine Sicherungsdatei (SQLDUMP<nnnn>.txt) wird jedes Mal im LOG-Verzeichnis von SQL Server erstellt, wenn DBCC CHECKTABLE einen Fehler durch eine Beschädigung erkennt. Falls die Features zur Datensammlung zur Verwendung von Features 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 Systemadministratorrolle enthält standardmäßig alle Mitglieder der Windows-Gruppe VORDEFINIERT\Administratoren und der Gruppe lokaler Administratoren. Ein Fehler bei der Datensammlung verursacht keinen Misserfolg des DBCC-Befehls.

Beheben von Fehlern

Wenn DBCC CHECKTABLE Fehler meldet, empfiehlt es sich, die Datenbank mithilfe einer 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. Wenn die Fehlerkorrektur mithilfe der Option REPAIR_ALLOW_DATA_LOSS erfolgen soll, müssen möglicherweise jedoch einige Seiten, und damit auch Daten, gelöscht werden.

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 über eine Sicherung 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

Sie müssen der Besitzer der Tabelle sein oder ein Mitglied der festen Serverrolle sysadmin bzw. der festen Datenbankrollen db_owner oder db_ddladmin.

Beispiele

A. Überprüfen einer bestimmten Tabelle

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

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 AdventureWorks2022-Datenbank mit geringem Verwaltungsaufwand ausgeführt.

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.

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);

Weitere Informationen