Freigeben über

DBCC CHECKTABLE (Transact-SQL)

  • Artikel

Aktualisiert: 17. November 2008

Ü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 ]
          [ , 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. Wenn index_id angegeben wird, 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 festgestellte 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 geringfügige, nicht zeitaufwändige Reparaturaktionen aus, wie z. B. das Reparieren zusätzlicher Schlüssel in nicht gruppierten Indizes, und zeitaufwändige Reparaturen, z. B. das Neuerstellen von Indizes. Diese Reparaturen können ohne das Risiko von Datenverlusten ausgeführt werden.
    ms174338.note(de-de,SQL.90).gifHinweis:
    Verwenden Sie die REPAIR-Optionen nur als letzte Möglichkeit. Zum Reparieren von Fehlern wird das Wiederherstellen mithilfe einer Sicherung empfohlen. Bei Reparaturvorgängen werden keine Einschränkungen berücksichtigt, die möglicherweise in oder zwischen Tabellen vorhanden sind. Wenn die angegebene Tabelle an mindestens einer Einschränkung beteiligt ist, wird empfohlen, 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 möchten, wird empfohlen, die Datenbank vor dem Ausführen von DBCC CHECKDB mit dieser Option zu sichern.
  • ALL_ERRORMSGS
    Zeigt eine unbegrenzte Anzahl von Fehlern 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 früheren Versionen von SQL Server werden nur die ersten 200 Fehlermeldungen für jedes Objekt angezeigt, wenn ALL_ERRORMSGS nicht angegeben wird.
  • NO_INFOMSGS
    Alle Informationsmeldungen werden unterdrückt.
  • TABLOCK
    Bewirkt, dass DBCC CHECKTABLE eine gemeinsame Tabellensperre erhält, statt einen internen Datenbanksnapshot zu verwenden. Durch TABLOCK wird DBCC CHECKTABLE für eine Tabelle bei starker Auslastung 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 physikalischen Struktur der Seite, der Datensatzheader und der physikalischen Struktur von B-Strukturen. Wurde entworfen, um mit geringem Verwaltungsaufwand eine Überprüfung der physikalischen Konsistenz der Tabelle vorzunehmen. Dabei können auch zerrissene Seiten und häufige Hardwarefehler festgestellt werden, die die Daten gefährden können. In SQL Server 2005 kann eine vollständige Ausführung von DBCC CHECKTABLE 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 zahlreiche neue Überprüfungen eingeführt, um die neuen Features in SQL Server 2005 hinzuzufügen.

    Daher bewirkt das Verwenden der PHYSICAL_ONLY-Option möglicherweise eine wesentlich 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 wird eine vollständige Ausführung von DBCC CHECKTABLE in regelmäßigen Abständen empfohlen. Die Häufigkeit dieser Ausführungsvorgänge ist von spezifischen Faktoren der einzelnen Unternehmen und Produktionsumgebungen abhängig. PHYSICAL_ONLY setzt immer NO_INFOMSGS voraus und kann nicht mit einer Reparaturoption verwendet werden.

  • DATA_PURITY
    Bewirkt, dass DBCC CHECKTABLE die Tabelle auf Spaltenwerte überprüft, die ungültig sind oder außerhalb des zulässigen Bereichs liegen. Es können mit DBCC CHECKTABLE beispielsweise Spalten mit Datums- und Uhrzeitwerten festgestellt 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 festgestellt, die ungültige Dezimal- oder Genauigkeitswerte enthalten.

    Bei Datenbanken, die in SQL Server 2005 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: Troubleshooting DBCC error 2570 in SQL Server 2005.

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

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.

Hinweise

DBCC CHECKTABLE führt Konsistenzüberprüfungen für eine einzelne Tabelle oder indizierte Sicht und alle nicht gruppierten Indizes und XML-Indizes aus, sofern nicht die Option NOINDEX angegeben wird. 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.

Interner Datenbanksnapshot

DBCC CHECKTABLE verwendet einen internen Datenbanksnapshot, 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 Datenbanksnapshots und im Abschnitt über die Verwendung von internen Datenbanksnapshots in DBCC unter DBCC (Transact-SQL).

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

ms174338.note(de-de,SQL.90).gifHinweis:
Wenn DBCC CHECKTABLE für tempdb ausgeführt wird, muss eine gemeinsame Tabellensperre erworben werden. 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.

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 festgelegt. Der maximale Grad der Parallelität wird auf dieselbe Weise konfiguriert wie der maximale Grad bei parallelen Abfragen. Zum Einschränken der maximalen Anzahl der für die DBCC-Überprüfung verfügbaren Prozessoren verwenden Sie sp_configure. Weitere Informationen finden Sie unter max degree of parallelism (Option).

Parallele Überprüfung kann durch das Ablaufverfolgungsflag 2528 deaktiviert werden. Weitere Informationen finden Sie unter Ablaufverfolgungsflags (Transact-SQL).

ms174338.note(de-de,SQL.90).gifHinweis:
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. Wenn 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. Wenn der DBCC-Befehl aufgrund eines Fehlers vor Abschluss der Überprüfung beendet wurde, 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

Fehler Nr. 8930 wurde ausgelöst. Dies weist auf beschädigte Metadaten als Ursache der Beendigung des DBCC-Befehls hin.

1

Fehler Nr. 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 der Beendigung des DBCC-Befehls hin.

4

Eine Assertations- oder Zugriffsverletzung wurde festgestellt.

5

Ein unbekannter Fehler ist aufgetreten, der den DBCC-Befehl beendet hat.

Fehlerberichterstellung

In SQL Server 2005 Service Pack 1 (SP1) wird jedes Mal eine kleine Dumpdatei (SQLDUMPnnnn.txt) im SQL Server-Verzeichnis LOG erstellt, wenn DBCC CHECKTABLE einen Fehler aufgrund einer Beschädigung feststellt. 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. Mit den gesammelten Daten werden die Funktionen von SQL Server verbessert. Weitere Informationen finden Sie unter Einstellungen für Fehler- und Verwendungsberichte.

Die Sicherungsdatei enthält die Ergebnisse des DBCC CHECKTABLE-Befehls sowie eine zusätzliche Diagnoseausgabe. Die Datei enthält eingeschränkte freigegebene Zugriffssteuerungslisten (Discretionary Access Control Lists – DACLs). 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, wird empfohlen, die Datenbank aus der Datenbanksicherung wiederherzustellen, statt REPAIR mit einer der REPAIR-Optionen auszuführen. Wenn keine Sicherung vorhanden ist, 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. Wenn für Reparaturen ein Rollback ausgeführt wird, sind in der Datenbank immer noch Fehler enthalten. Sie muss daher aus einer Datensicherung wiederhergestellt werden. Sichern Sie nach dem Abschluss aller Reparaturen die Datenbank.

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 AdventureWorks -Datenbank überprüft.

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

USE AdventureWorks;
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 abgerufen wird.

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

Siehe auch

Verweis

DBCC (Transact-SQL)

Andere Ressourcen

Tabellen- und Indexarchitektur
Problembehandlung von DBCC-Fehlern in indizierten Sichten

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf

Version Verlauf

17. November 2008
Neue Inhalte:
  • In der Definition von ALL_ERRORMSGS werden die neuen Funktionen von SP3 beschrieben.

12. Dezember 2006
Neue Inhalte:
  • Den Abschnitten zur Syntax und zu den Argumenten wurde die Option DATA_PURITY hinzugefügt.

14. April 2006
Neuer Inhalt:
  • Im Abschnitt mit den Hinweisen wurde ein Unterabschnitt zur Fehlerberichterstellung hinzugefügt. In diesem Abschnitt werden neue Funktionen von SP1 beschrieben.

05. Dezember 2005
Neuer Inhalt:
  • Es wurde eine benutzerdefinierte Typnotiz hinzugefügt.
Geänderter Inhalt:
  • Die REPAIR_FAST-Definition wurde korrigiert. Die Option führt keine Reparaturvorgänge aus.
  • Die Syntax wurde korrigiert.
  • Beispiel C wurde korrigiert.