DBCC CHECKTABLE (Transact-SQL)

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.

  Hinweis

  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.

  Hinweis
  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

Hinweis
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

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.

Hinweis
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

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

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 UDT-Werts (User-Defined Type, benutzerdefinierter Typ) sein. Falls dies nicht zutrifft, meldet die DBCC CHECKTABLE-Routine einen Konsistenzfehler.

Grundlegendes zu DBCC-Fehlermeldungen

Fehlerberichterstellung

Beheben von Fehlern

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

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

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

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

C. Überprüfen eines bestimmten Indexes

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

Siehe auch

Verweis

Konzepte

Andere Ressourcen