Freigeben über

DBCC CHECKDB (Transact-SQL)

  • Artikel

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed Instance

Überprüft die logische und physische Integrität aller Objekte in der angegebenen Datenbank durch Ausführen der folgenden Vorgänge:

  • Die Ausführung von DBCC CHECKALLOC für die Datenbank.

  • Die Ausführung von DBCC CHECKTABLE für jede Tabelle und Sicht in der Datenbank.

  • Die Ausführung von DBCC CHECKCATALOG für die Datenbank.

  • Die Überprüfung des Inhalts jeder indizierten Sicht in der Datenbank.

  • Die Überprüfung der Konsistenz auf Linkebene zwischen den Metadaten der Tabellen und den Dateisystemverzeichnissen und -dateien beim Speichern von varbinary(max) -Daten im Dateisystem mithilfe von FILESTREAM.

  • Die Überprüfung der Service Broker-Daten in der Datenbank.

Das bedeutet, dass die Befehle DBCC CHECKALLOC, DBCC CHECKTABLE und DBCC CHECKCATALOG nicht separat von DBCC CHECKDB ausgeführt werden müssen. Ausführlichere Informationen zu den von diesen Befehlen ausgeführten Überprüfungen finden Sie in den Beschreibungen dieser Befehle.

DBCC CHECKDB wird für Datenbanken unterstützt, die speicheroptimierte Tabellen enthalten. Die Überprüfung wird jedoch nur für Tabellen auf dem Datenträger ausgeführt. Im Rahmen der Datenbanksicherung und -wiederherstellung erfolgt jedoch eine CHECKSUM Überprüfung für Dateien in speicheroptimierten Dateigruppen.

Da DBCC-Reparaturoptionen für speicheroptimierte Tabellen nicht verfügbar sind, müssen Sie Ihre Datenbanken regelmäßig sichern und die Sicherungen testen. Wenn bei einer speicheroptimierten Tabelle Datenintegritätsprobleme auftreten, müssen Sie die Tabelle aus der letzten bekannten fehlerfreien Sicherung wiederherstellen.

Transact-SQL-Syntaxkonventionen

Syntax

DBCC CHECKDB
    [ [ ( database_name | database_id | 0
        [ , NOINDEX
        | , { 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

database_name | database_id | 0

Der Name oder die ID der Datenbank, für die Integritätsprüfungen ausgeführt werden. 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 intensive Überprüfungen nicht gruppierter Indizes für Benutzertabellen nicht ausgeführt werden. Dadurch wird die Ausführungsdauer insgesamt verkürzt. NOINDEX wirkt sich nicht auf Systemtabellen aus, da Integritätsprüfungen für Systemtabellenindizes immer ausgeführt werden.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Gibt an, dass DBCC CHECKDB die gefundenen Fehler repariert. Verwenden Sie die REPAIR_* Optionen nur als letzte Möglichkeit. Die angegebene Datenbank muss sich im Einzelbenutzermodus befinden, damit eine der folgenden Reparaturoptionen verwendet werden kann.

  • REPAIR_ALLOW_DATA_LOSS

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

    Warnung

    Die Option REPAIR_ALLOW_DATA_LOSS kann zu mehr Datenverlust führen, als wenn Sie aus einer letzten bekannten guten Sicherung wiederherstellen. Siehe Warnung zum Datenverlust mit REPAIR_ALLOW_DATA_LOSS

    Microsoft empfiehlt immer eine Wiederherstellung durch den oder die Benutzer*in aus der letzten als funktionierend bekannten Sicherung als primäre Methode zur Wiederherstellung nach Fehlern, die von DBCC CHECKDB gemeldet wurden. Die Option REPAIR_ALLOW_DATA_LOSS ist keine Alternative zur Wiederherstellung aus einer als funktionierend bekannten Sicherung. Es handelt sich um einen Notfall letzte Möglichkeit, Option nur zur Verwendung empfohlen wird, wenn die Wiederherstellung aus einer Sicherung nicht möglich ist.

    Bestimmte Fehler, die nur mithilfe der Option REPAIR_ALLOW_DATA_LOSS repariert werden können, können die Zuordnung einer Zeile, einer Seite oder einer Reihe von Seiten umfassen, um die Fehler zu löschen. Alle deallocated-Daten sind für den Benutzer nicht mehr zugänglich oder wiederherstellbar, und der genaue Inhalt der deallocated-Daten kann nicht bestimmt werden. Daher ist die referenzielle Integrität nach der Zuordnung von Zeilen oder Seiten möglicherweise nicht korrekt, da Fremdschlüsseleinschränkungen nicht im Rahmen dieses Reparaturvorgangs überprüft oder verwaltet werden. Der oder die Benutzer*in muss die referentielle Integrität der Datenbank (mit DBCC CHECKCONSTRAINTS) überprüfen, nachdem er oder sie die Option REPAIR_ALLOW_DATA_LOSS verwendet hat.

    Sie müssen vor der Reparatur physische Kopien der Dateien erstellen, die zu dieser Datenbank gehören. Dies schließt die primäre Datendatei (.mdf), alle sekundären Datendateien (.ndf), alle Transaktionsprotokolldateien (.ldf) und andere Container ein, aus denen die Datenbank besteht, einschließlich Volltextkataloge, Datenstromordner, arbeitsspeicheroptimierte Daten und so weiter.

    Erwägen Sie vor der Reparatur, den Status der Datenbank in den Modus EMERGENCY zu ändern und zu versuchen, so viele Informationen wie möglich aus den kritischen Tabellen zu extrahieren und die Daten zu speichern.

  • REPAIR_FAST

    Wird nur aus Gründen der Abwärtskompatibilität der Syntax beibehalten. Es werden keine Reparaturaktionen ausgeführt.

  • REPAIR_REBUILD

    Führt Reparaturen aus, bei denen kein Datenverlust möglich ist. Diese Option kann schnelle Reparaturen umfassen, z. B. das Reparieren fehlender Zeilen in nicht gruppierten Indizes und mehr zeitaufwendige Reparaturen, z. B. das Neuerstellen eines Indexes.

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

Wichtig

Da DBCC CHECKDB mit einer der REPAIR_* Optionen vollständig protokolliert und wiederherstellbar sind, empfiehlt Microsoft immer, dass ein Benutzer DBCC CHECKDB mit allen REPAIR_* Optionen in einer Transaktion verwendet (BEGIN TRANSACTION vor dem Ausführen des Befehls ausführen), damit der Benutzer bestätigen kann, dass er die Ergebnisse des Vorgangs akzeptieren möchte. Benutzer*innen können dann COMMIT TRANSACTION ausführen, um alle vom Reparaturvorgang vorgenommenen Arbeiten zu committen. Wenn der Benutzer die Ergebnisse des Vorgangs nicht akzeptiert, kann er eine ROLLBACK TRANSACTION ausführen, um die Auswirkungen der Reparaturvorgänge rückgängig zu machen.

Zum Reparieren von Fehlern empfiehlt sich das Wiederherstellen mithilfe einer Sicherung. Reparaturvorgänge berücksichtigen keine der Einschränkungen, die für oder zwischen Tabellen vorhanden sein können. 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 CHECKDB ohne Reparaturoption aus, um die zu verwendende Reparaturstufe zu finden. Wenn Sie die Ebene REPAIR_ALLOW_DATA_LOSS verwenden möchten, empfiehlt es sich, die Datenbank vor dem Ausführen von DBCC CHECKDB mit dieser Option zu sichern.

ALL_ERRORMSGS

Zeigt alle gemeldeten Fehler für jedes Objekt an. Alle Fehlermeldungen werden standardmäßig angezeigt. Das Angeben oder Weglassen dieser Option hat keine Auswirkungen. Die Fehlermeldungen werden nach der Objekt-ID sortiert. Davon ausgenommen sind Meldungen, die für die tempdb-Datenbank generiert wurden.

EXTENDED_LOGICAL_CHECKS

Wenn der Kompatibilitä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 weiter unten in diesem Artikel unter Durchführen logischer Konsistenzprüfungen für Indizes.

NO_INFOMSGS

Alle Informationsmeldungen werden unterdrückt.

TABLOCK

Bewirkt, dass DBCC CHECKDB Sperren anwendet, statt eine interne Datenbankmomentaufnahme zu verwenden. Dies schließt eine kurzfristige exklusive Sperre (X) für die Datenbank ein. TABLOCK bewirkt, dass DBCC CHECKDB bei einer Datenbank mit hoher Auslastung schneller ausgeführt werden, verringert jedoch die parallele Verfügbarkeit der Datenbank, während DBCC CHECKDB ausgeführt wird.

Wichtig

TABLOCK beschränkt die durchgeführten Prüfungen; DBCC CHECKCATALOG nicht für die Datenbank ausgeführt wird, und die Dienstbrokerdaten werden nicht überprüft.

ESTIMATEONLY

Zeigt den tempdb-Speicherplatz an, der schätzungsweise erforderlich ist, um DBCC CHECKDB mit allen anderen angegebenen Optionen auszuführen. Die eigentliche Datenbankprüfung wird nicht ausgeführt.

PHYSICAL_ONLY

Begrenzt die Überprüfung der Integrität der physischen Struktur der Seiten- und Datensatzheader und der Zuordnungskonsistenz der Datenbank. Die Überprüfung soll dazu dienen, mit geringem Verwaltungsaufwand eine Überprüfung der physischen Konsistenz der Datenbank vorzunehmen. Dabei können auch zerrissene Seiten, Prüfsummenfehler und häufige Hardwarefehler erkannt werden, die Benutzerdaten gefährden können.

Eine vollständige Ausführung von DBCC CHECKDB kann erheblich länger dauern als frühere 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 kann die Verwendung der Option PHYSICAL_ONLY zu einer viel kürzeren Laufzeit für DBCC CHECKDB für große Datenbanken führen und für die häufige Verwendung in Produktionssystemen empfohlen werden. Dennoch ist eine vollständige Ausführung von DBCC CHECKDB 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.

Dieses Argument impliziert stets NO_INFOMSGS und kann nicht mit den Reparaturoptionen verwendet werden.

Warnung

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

DATA_PURITY

Bewirkt, dass DBCC CHECKDB die Datenbank auf Spaltenwerte überprüft, die ungültig sind oder außerhalb des zulässigen Bereichs liegen. So können mit DBCC CHECKDB z. B. 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, ist die Spaltenwertüberprüfung nicht standardmäßig aktiviert. Die Aktivierung erfolgt erst, wenn DBCC CHECKDB WITH DATA_PURITY für die Datenbank fehlerfrei ausgeführt wurde. Danach wird die Spaltenwertintegrität standardmäßig von DBCC CHECKDB überprüft. Weitere Informationen zu den möglichen Auswirkungen des Upgrades einer Datenbank von einer früheren Version von SQL Server auf CHECKDB finden Sie im Abschnitt „Bemerkungen“ weiter unten in diesem Artikel.

Warnung

Wenn PHYSICAL_ONLY angegeben ist, werden spaltenintegritätsprüfungen nicht ausgeführt.

Mit dieser Option gemeldete Überprüfungsfehler können nicht mithilfe der DBCC-Reparaturoptionen behoben werden. Informationen zum manuellen Korrigieren dieser Fehler finden Sie unter MSSQLSERVER_2570.

MAXDOP

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

Überschreibt die max degree of parallelism Konfigurationsoption 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 SQL Server-Datenbank-Engine den in MAXDOP beschriebenen -Wert von Resource Governor. Alle semantischen Regeln, die mit der max degree of parallelism-Konfigurationsoption verwendet werden, sind anwendbar, wenn Sie den MAXDOP Abfragehinweis verwenden. Weitere Informationen finden Sie unter Serverkonfiguration: max. Grad der Parallelität.

Warnung

Wenn MAXDOP auf Null festgelegt ist, wählt SQL Server die zu verwendende max degree of parallelism aus.

Bemerkungen

DBCC CHECKDB untersucht keine deaktivierten Indizes. Weitere Informationen zu deaktivierten Indizes finden Sie unter Deaktivieren von Indizes und Einschränkungen.

Wenn ein benutzerdefinierter Typ als Typ markiert ist, dessen Sortierreihenfolge eine Bytereihenfolge ist, darf es nur eine Serialisierung des benutzerdefinierten Typs geben. Wenn keine konsistente Serialisierung benutzerdefinierter Typen vorhanden ist, deren Sortierreihenfolge eine Bytereihenfolge ist, wird bei der Ausführung von DBCC CHECKDB der Fehler 2537 ausgegeben. Weitere Informationen finden Sie unter Erstellen von User-Defined Typen – Anforderungen.

Da der Zugriff auf die Ressourcendatenbank nur im Einzelbenutzermodus möglich ist, kann der Befehl DBCC CHECKDB für diese Datenbank nicht direkt ausgeführt werden. Wenn DBCC CHECKDB jedoch für die Masterdatenbank ausgeführt wird, wird intern ein zweiter CHECKDB-Befehl für die Ressourcendatenbank ausgeführt. Das bedeutet, dass DBCC CHECKDB möglicherweise zusätzliche Ergebnisse zurückgibt. Der Befehl gibt zusätzliche Ergebnisse zurück, wenn keine Optionen festgelegt wurden oder wenn entweder die Option PHYSICAL_ONLY oder ESTIMATEONLY festgelegt wurde.

In SQL Server 2005 (9.x) Service Pack 2 und höheren Versionen löscht die Ausführung DBCC CHECKDB den Plancache für die Sql Server-Instanz nicht mehr. In Versionen vor SQL Server 2005 (9.x) Service Pack 2 wird beim Ausführen von DBCC CHECKDB der Plancache gelöscht. Das Löschen des Plancaches führt zu einer Neukompilierung aller späteren Ausführungspläne und kann zu einem plötzlichen, temporären Rückgang der Abfrageleistung führen.

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 mindestens 100 beträgt (eingeführt in SQL Server 2008 (10.0.x)):

  • Sofern NOINDEX nicht angegeben ist, führt DBCC CHECKDB 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 Konsistenzüberprüfungen überprüfen die interne Indextabelle des Indexobjekts mit 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 CHECKDB anhand von Konsistenzprüfungen, ob die Indexeinträge dem Filterprädikat entsprechen.

  • Wenn der Kompatibilitätsgrad 90 oder weniger beträgt, führt NOINDEX 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 DBCC CHECKDB angegeben wird. Räumliche Indizes werden nicht unterstützt.

  • In SQL Server 2016 (13.x) und höheren Versionen werden zusätzliche Überprüfungen auf gespeicherte berechnete Spalten, UDT-Spalten und gefilterte Indizes nicht standardmäßig ausgeführt, um die kostspieligen Ausdrucksauswertungen zu vermeiden. Durch diese Änderung wird die Dauer der Ausführung von CHECKDB 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).

Informationen zur Kompatibilitätsstufe einer Datenbank

Interne Datenbankmomentaufnahme

DBCC CHECKDB verwendet eine interne Datenbankmomentaufnahme für die Transaktionskonsistenz, die für diese Überprüfungen erforderlich ist. Auf diese Weise werden beim Ausführen dieser Befehle Blockierungs- und Parallelitätsprobleme verhindert. Weitere Informationen finden Sie unter Anzeigen der Größe der geringen Datei einer Datenbankmomentaufnahme- und der internen Datenbankmomentaufnahmeverwendung Abschnitt in DBCC-. Wenn keine Momentaufnahme erstellt werden kann oder TABLOCK angegeben wird, wendet DBCC CHECKDB Sperren an, um die erforderliche Konsistenz zu erzielen. In diesem Fall ist für die Durchführung der Zuordnungsprüfungen eine exklusive Datenbanksperre erforderlich, und für die Durchführung der Tabellenprüfungen sind freigegebene Tabellensperren erforderlich.

Die Ausführung von DBCC CHECKDB für die Datenbank master ist nicht erfolgreich, wenn keine interne Datenbankmomentaufnahme erstellt werden kann.

Die Ausführung von DBCC CHECKDB für tempdb bewirkt keine Zuordnungs- oder Katalogüberprüfungen. Zum Ausführen von Tabellenüberprüfungen sind weiterhin freigegebene Tabellensperren erforderlich. Das liegt daran, dass aus Leistungsgründen keine Datenbankmomentaufnahmen für tempdb verfügbar sind. Das bedeutet, dass die erforderliche Transaktionskonsistenz nicht erhalten werden kann.

Erstellen einer internen Momentaufnahmedatenbank ab SQL Server 2014 durch DBCC CHECKDB

  1. DBCC CHECKDB erstellt eine interne Momentaufnahmedatenbank.

  2. Die interne Momentaufnahmedatenbank wird mithilfe physischer Dateien erstellt. For a database with database_id = 10 that has three files E:\Data\my_DB.mdf, E:\Data\my_DB.ndf, and E:\Data\my_DB.ldf, the internal snapshot database is created using E:\Data\my_DB.mdf_MSSQL_DBCC11 and E:\Data\my_DB.ndf_MSSQL_DBCC11 files. Die database_id der Momentaufnahme ist database_id + 1. Beachten Sie auch, dass die neuen Dateien unter Verwendung der Namenskonvention <filename.extension>_MSSQL_DBCC<database_id_of_snapshot> erstellt werden. Für das Transaktionsprotokoll wird keine Sparsedatei erstellt.

  3. Die neuen Dateien werden auf Dateisystemebene als Sparsedateien markiert. Die Größe auf dem Datenträger, die von den neuen Dateien verwendet wird, erhöht sich basierend darauf, wie viele Daten in der Quelldatenbank während des befehls DBCC CHECKDB aktualisiert werden. Die Größe der neuen Dateien ist dieselbe Datei wie die .mdf oder .ndf Datei.

  4. Die neuen Dateien werden am Ende der DBCC CHECKDB-Verarbeitung gelöscht. Für diese Sparsedateien, die von DBCC CHECKDB erstellt werden, ist das Attribut „Beim Schließen löschen“ festgelegt.

Warnung

Wenn beim Auftreten des Betriebssystems ein unerwartetes Herunterfahren auftritt, während der Befehl DBCC CHECKDB ausgeführt wird, werden diese Dateien nicht bereinigt. Sie belegen Platz und können möglicherweise Fehler bei zukünftigen DBCC CHECKDB Ausführungen verursachen. In diesem Fall können Sie diese neuen Dateien löschen, nachdem Sie bestätigt haben, dass derzeit kein DBCC CHECKDB Befehl ausgeführt wird.

Die neuen Dateien werden mit normalen Dateihilfsprogrammen wie Windows Explorer angezeigt.

Hinweis

Vor SQL Server 2014 (12.x) wurden stattdessen benannte Dateistreams verwendet, um die internen Momentaufnahmedateien zu erstellen. Die benannten Dateistreams verwendeten das Format <Dateiname.Erweiterung>:MSSQL_DBCC<Datenbank_ID_der_Momentaufnahme>. Benannte Dateidatenströme werden nicht mithilfe gewöhnlicher Dateihilfsprogramme wie Windows-Explorer angezeigt. Daher können in SQL Server 2012 (11.x) und früheren Versionen Fehlermeldungen 7926 und 5030 auftreten, wenn Sie den Befehl DBCC CHECKDB für Datenbankdateien ausführen, die sich auf einem ReFS-formatiertem Volume befinden. Dies liegt daran, dass Dateidatenströme nicht auf Resilient File System (RefS)erstellt werden können.

Ü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 CHECKDB für eine Datenbank verwenden, die BLOBs im Dateisystem speichert, überprüft DBCC die Konsistenz auf Linkebene zwischen dem Dateisystem und der Datenbank.

Wenn eine Tabelle z. B. eine varbinary(max) Spalte enthält, die das FILESTREAM-Attribut verwendet, DBCC CHECKDB überprüft, ob eine 1:1-Zuordnung zwischen Dateisystemverzeichnissen und Dateien und Tabellenzeilen, Spalten und Spaltenwerten vorhanden ist. DBCC CHECKDB kann Beschädigungen reparieren, wenn Sie die Option REPAIR_ALLOW_DATA_LOSS angeben. Um FILESTREAM-Beschädigungen zu reparieren, löscht DBCC alle Tabellenzeilen, die Dateisystemdaten fehlen.

Bewährte Methoden

Es empfiehlt sich, die Option PHYSICAL_ONLY für den häufigen Einsatz in Produktionssystemen zu verwenden. Das Verwenden von PHYSICAL_ONLY kann die Ausführungszeit von DBCC CHECKDB für große Datenbanken erheblich verkürzen. Darüber hinaus sollte in regelmäßigen Abständen DBCC CHECKDB ohne Optionen ausgeführt werden. Die Häufigkeit der Ausführung hängt von den jeweiligen Unternehmen und Produktionsumgebungen ab.

In Azure SQL verwaltete Instanz muss der verfügbare Speicherplatz die gesamte interne Datenbankmomentaufnahmedatei aufnehmen, die von DBCC CHECKDBdaten tatsächlich verwendet wird. Dies kann zu einer Situation führen, in der die Ausführung DBCC CHECKDB in einer sehr großen, aber sparsamen Datenbank (die Größe der Daten ist viel kleiner als die Datenbankdateigröße) aufgrund des fehlenden Speicherplatzes in Ihrer verwalteten SQL-Instanz fehlschlägt. Wenn DBCC CHECKDB der gesamte verfügbare Speicherplatz während der Ausführung verbraucht wird, erhalten Sie die folgende Fehlermeldung:

Msg 1133, Level 16, State 3, Line 1
The managed instance has reached its storage limit. To storage usage for the managed instance cannot exceed (...) MBs.
You might need to temporarily scale up your SQL managed instance storage capacity before running `DBCC CHECKDB` again.

Paralleles Überprüfen von Objekten

Standardmäßig führt DBCC CHECKDB eine parallele Objektüberprüfung aus. Der Grad der Parallelität wird automatisch durch den Abfrageprozessor bestimmt. Der Höchstgrad für die Parallelität wird genauso konfiguriert wie parallele 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 Serverkonfiguration: max. Grad der Parallelität. Die parallele Überprüfung kann mithilfe des Ablaufverfolgungsflags 2528 deaktiviert werden. Weitere Informationen finden Sie unter Ablaufverfolgungskennzeichnungen.

Hinweis

Dieses Feature ist in jeder Edition von SQL Server nicht verfü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 CHECKDB ausgeführt wurde, wird eine Meldung in das SQL Server-Fehlerprotokoll geschrieben. Falls der DBCC-Befehl erfolgreich ausgeführt wird, gibt die Meldung den Erfolg und die Dauer der Ausführung an. Falls der DBCC-Befehl vor Abschluss der Überprüfung aufgrund eines Fehlers beendet wird, gibt die Meldung die Beendigung des Befehls, einen Statuswert sowie die Dauer der Ausführung an. 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 eine Beschädigung der Metadaten hin, die zur Beendigung des DBCC-Befehls geführt hat.
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 eine Beschädigung der Metadaten hin, die zur Beendigung des DBCC-Befehls geführt hat.
4 Eine Assertations- oder Zugriffsverletzung wurde entdeckt.
5 Ein unbekannter Fehler ist aufgetreten, der den DBCC-Befehl beendet hat.

SQL Server zeichnet das Datum und die Uhrzeit der Ausführung einer Konsistenzprüfung für eine fehlerfreie Datenbank (oder eine „saubere“ Konsistenzprüfung) auf. Dies wird als last known clean check bezeichnet. Wenn eine Datenbank erstmalig gestartet wird, wird dieses Datum im folgenden Format in das Ereignisprotokoll (EventID-17573) und in das Fehlerprotokoll geschrieben:

CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

Fehlerberichterstattung

Ein Stapelabbild (SQLDump<nnnn>.txt, SQLDump<nnnn>.log, SQLDump<nnnn>.mdmp) wird im SQL Server LOG Verzeichnis erstellt, wenn DBCC CHECKDB einen Beschädigungsfehler 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 CHECKDB-Befehls sowie eine zusätzliche Diagnoseausgabe. Der Zugriff ist auf das SQL Server-Dienstkonto und Mitglieder der Systemadministratorrolle beschränkt. Die Systemadministratorrolle enthält standardmäßig alle Mitglieder der Windows-Gruppe BUILTIN\Administrators und der lokalen Administratorgruppe. Ein Fehler bei der Datensammlung verursacht keinen Misserfolg des DBCC-Befehls.

Beheben von Fehlern

Wenn fehler von DBCC CHECKDBgemeldet werden, empfehlen wir, die Datenbank aus der Datenbanksicherung wiederherzustellen, anstatt DBCC CHECKDB mit einer der REPAIR_* Optionen auszuführen. Wenn keine Sicherung vorhanden ist, können Sie die gemeldeten Fehler durch Ausführen von REPAIR beheben. Die zu verwendende Reparaturoption wird am Ende der Liste gemeldeter 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.

Unter bestimmten Bedingungen werden möglicherweise Werte in die Datenbank eingegeben, die je nach Datentyp der Spalte ungültig sind oder außerhalb des gültigen Bereichs liegen. DBCC CHECKDB kann Spaltenwerte erkennen, die nicht für alle Spaltendatentypen gültig sind. Wird DBCC CHECKDB mit der Option DATA_PURITY für Datenbanken ausgeführt, die von früheren Versionen von SQL Server upgegradet wurden, ist es daher möglich, dass bereits vorhandene Spaltenwertfehler aufgedeckt werden. Da SQL Server diese Fehler nicht automatisch reparieren kann, muss der Spaltenwert manuell aktualisiert werden. Wenn CHECKDB einen derartigen Fehler erkennt, gibt CHECKDB eine Warnung, die Fehlernummer 2570 sowie Informationen zurück, anhand derer die betroffene Zeile ermittelt und der Fehler manuell behoben werden kann.

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 Reparaturen zurückgesetzt werden, enthält die Datenbank weiterhin Fehler und muss aus einer Sicherung wiederhergestellt werden. Nach Abschluss der Reparaturen sollten Sie eine Sicherung der Datenbank durchführen.

Beheben von Fehlern im Datenbank-Notfallmodus

Wenn eine Datenbank mithilfe der ALTER DATABASE-Anweisung in den Notfallmodus versetzt wurde, können mit DBCC CHECKDB bestimmte Reparaturen an der Datenbank vorgenommen werden, sofern die Option REPAIR_ALLOW_DATA_LOSSangegeben wurde. Diese Reparaturen ermöglichen möglicherweise, dass nicht wiederherstellbare Datenbanken in einem physisch konsistenten Zustand wieder online gebracht werden können. Die Reparaturen sollten als letzte Möglichkeit und nur dann verwendet werden, wenn die Datenbank nicht aus einer Sicherung wiederhergestellt werden kann. Wenn die Datenbank im Notfallmodus festgelegt ist, wird die Datenbank READ_ONLY markiert, die Protokollierung ist deaktiviert, und der Zugriff ist auf Mitglieder des sysadmin festen Serverrolle beschränkt.

Hinweis

Sie können den befehl DBCC CHECKDB nicht im Notfallmodus innerhalb einer Benutzertransaktion ausführen und die Transaktion nach der Ausführung zurücksetzen.

Wenn sich die Datenbank im Notfallmodus befindet und DBCC CHECKDB mit der REPAIR_ALLOW_DATA_LOSS-Klausel ausgeführt wird, werden die folgenden Aktionen ausgeführt:

  • DBCC CHECKDB verwendet Seiten, die aufgrund von E/A-Fehlern oder Prüfsummenfehlern als nicht zugänglich gekennzeichnet wurden, als wären keine Fehler aufgetreten. Dadurch erhöhen sich die Chancen für eine Datenwiederherstellung aus der Datenbank.

  • DBCC CHECKDB versucht, die Datenbank mithilfe regulärer, protokollbasierter Wiederherstellungsverfahren wiederherzustellen.

  • Falls die Datenbank aufgrund einer Beschädigung des Transaktionsprotokolls nicht wiederhergestellt werden kann, wird das Transaktionsprotokoll neu erstellt. Die Neuerstellung des Transaktionsprotokolls kann zu einem Verlust der Transaktionskonsistenz führen.

Warnung

Die Option REPAIR_ALLOW_DATA_LOSS kann zu mehr Datenverlust führen, als wenn Sie aus einer letzten bekannten guten Sicherung wiederherstellen. Siehe Warnung zum Datenverlust mit REPAIR_ALLOW_DATA_LOSS

Ist der DBCC CHECKDB-Befehl erfolgreich, befindet sich die Datenbank in einem physisch konsistenten Zustand, und der Datenbankstatus wird auf ONLINE festgelegt. Die Datenbank kann jedoch eine oder mehrere Transaktionsinkonsistenzen enthalten. Es wird empfohlen, DBCC CHECKCONSTRAINTS auszuführen, um mögliche Fehler in der Geschäftslogik zu identifizieren und die Datenbank dann sofort zu sichern.

Falls der DBCC CHECKDB-Befehl einen Fehler generiert, kann die Datenbank nicht repariert werden.

Warnung zum Datenverlust mit REPAIR_ALLOW_DATA_LOSS

Die Option REPAIR_ALLOW_DATA_LOSS ist ein unterstütztes Feature von SQL Server. Es ist jedoch möglicherweise nicht immer die beste Option, um eine Datenbank in einen physisch konsistenten Zustand zu bringen. Bei erfolgreicher Ausführung kann die Option REPAIR_ALLOW_DATA_LOSS zu Datenverlust führen.

Tatsächlich kann dies dazu führen, dass mehr Daten verloren gehen, als wenn ein Benutzer die Datenbank aus der letzten bekannten guten Sicherung wiederherstellen wollte. Microsoft empfiehlt immer eine Wiederherstellung durch den oder die Benutzer*in aus der letzten als funktionierend bekannten Sicherung als primäre Methode zur Wiederherstellung nach Fehlern, die von DBCC CHECKDB gemeldet wurden.

Die Option REPAIR_ALLOW_DATA_LOSS ist keine Alternative zur Wiederherstellung aus einer als funktionierend bekannten Sicherung. Es handelt sich um einen Notfall letzte Möglichkeit Option, die nur dann zur Verwendung empfohlen wird, wenn die Wiederherstellung aus einer Sicherung nicht möglich ist.

Nachdem das Protokoll neu erstellt wurde, gibt es keine vollständige ACID-Garantie.

Nachdem das Protokoll neu erstellt wurde, wird DBCC CHECKDB automatisch ausgeführt und sowohl Berichte als auch physische Konsistenzprobleme behoben.

Durch logische Datenkonsistenz und Geschäftslogik erzwungene Dateneinschränkungen müssen manuell überprüft werden.

Die Größe des Transaktionsprotokolls bleibt der Standardgröße überlassen und muss manuell auf die zuletzt verwendete Größe angepasst werden.

Ausführen von DBCC CHECKDB mit REPAIR_ALLOW_DATA_LOSS in replizierten Datenbanken

Das Ausführen des Befehls DBCC CHECKDB mit der Option REPAIR_ALLOW_DATA_LOSS kann Auswirkungen auf Benutzerdatenbanken (Veröffentlichungs- und Abonnementdatenbanken) und die von der Replikation verwendete Verteilungsdatenbank haben. Veröffentlichungs- und Abonnementdatenbanken schließen veröffentlichte Tabellen und Tabellen mit Replikationsmetadaten ein. Beachten Sie die folgenden potenziellen Probleme in diesen Datenbanken:

  • Veröffentlichte Tabellen. Aktionen, die vom CHECKDB-Prozess zur Reparatur beschädigter Benutzerdaten ausgeführt werden, werden möglicherweise nicht repliziert:

  • Die Mergereplikation verwendet Trigger, um Änderungen an veröffentlichten Tabellen nachzuverfolgen. Wenn Zeilen vom CHECKDB-Prozess eingefügt, aktualisiert oder gelöscht werden, werden die Trigger nicht ausgelöst. Daher wird die Änderung nicht repliziert.

  • Die Transaktionsreplikation verwendet das Transaktionsprotokoll, um Änderungen an veröffentlichten Tabellen nachzuverfolgen. Anschließend verschiebt der Protokolllese-Agent diese Änderungen in die Verteilungsdatenbank. Einige DBCC-Reparaturen werden zwar protokolliert, können vom Protokolllese-Agent jedoch nicht repliziert werden. Wenn z. B. die Zuordnung einer Datenseite durch den CHECKDB-Prozess aufgehoben wird, übersetzt der Protokolllese-Agent dies nicht in eine DELETE-Anweisung. Daher wird die Änderung nicht repliziert.

  • Tabellen mit Replikationsmetadaten. Für Aktionen, die vom CHECKDB-Prozess zur Reparatur beschädigter Tabellen mit Replikationsmetadaten ausgeführt werden, ist das Entfernen und Neukonfigurieren der Replikation erforderlich.

Gehen Sie folgendermaßen vor, wenn Sie den Befehl DBCC CHECKDB mit der Option REPAIR_ALLOW_DATA_LOSS für eine Benutzerdatenbank oder Verteilungsdatenbank ausführen müssen:

  1. Versetzen Sie das System in einen inaktiven Status: Beenden Sie die Aktivitäten in der Datenbank und allen anderen Datenbanken in der Replikationstopologie, und versuchen Sie anschließend, alle Knoten zu synchronisieren. Weitere Informationen finden Sie unter Versetzen einer Replikationstopologie in einen inaktiven Status (Replikationsprogrammierung mit Transact-SQL).

  2. Führen Sie DBCC CHECKDB aus.

  3. Wenn der Bericht von DBCC CHECKDB Reparaturen für Tabellen in der Verteilungsdatenbank oder für Tabellen mit Replikationsmetadaten in einer Benutzerdatenbank enthält, entfernen Sie die Replikation, und konfigurieren Sie sie neu. Weitere Informationen finden Sie unter Deaktivieren der Veröffentlichung und Verteilung.

  4. Wenn der Bericht von DBCC CHECKDB Reparaturen für replizierte Tabellen enthält, führen Sie eine Datenüberprüfung aus, um zu bestimmen, ob Unterschiede zwischen den Daten in den Veröffentlichungs- und Abonnementdatenbanken bestehen.

Resultset

DBCC CHECKDB gibt das folgende Resultset zurück: Die Werte können variieren, außer wenn die Optionen ESTIMATEONLY, PHYSICAL_ONLYoder NO_INFOMSGS angegeben werden:

DBCC results for 'model'.
Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.
Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.
Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.
Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.

DBCC results for 'sys.sysrowsetcolumns'.
There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.

DBCC results for 'sys.sysrowsets'.
There are 97 rows in 1 pages for object 'sys.sysrowsets'.

DBCC results for 'sysallocunits'.
There are 195 rows in 3 pages for object 'sysallocunits'.
There are 0 rows in 0 pages for object "sys.sysasymkeys".

DBCC results for 'sys.syssqlguides'.
There are 0 rows in 0 pages for object "sys.syssqlguides".

DBCC results for 'sys.queue_messages_1977058079'.
There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".

DBCC results for 'sys.queue_messages_2009058193'.
There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".

DBCC results for 'sys.queue_messages_2041058307'.
There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".

CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB gibt das folgende Resultset (die folgende Meldung) zurück, wenn NO_INFOMSGS angegeben wird:

The command(s) completed successfully.

DBCC CHECKDB gibt das folgende Resultset zurück, wenn PHYSICAL_ONLY angegeben wird:

DBCC results for 'model'.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB gibt das folgende Resultset zurück, wenn ESTIMATEONLY angegeben wird:

Estimated TEMPDB space needed for CHECKALLOC (KB)
-------------------------------------------------
13

(1 row(s) affected)

Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
57

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Berechtigungen

Erfordert die Mitgliedschaft im sysadmin festen Serverrolle oder der db_owner festen Datenbankrolle.

Beispiele

A. Überprüfen der aktuellen und einer anderen Datenbank

Im folgenden Beispiel wird DBCC CHECKDB für die aktuelle Datenbank und für die AdventureWorks2022-Datenbank ausgeführt.

-- Check the current database.
DBCC CHECKDB;
GO

-- Check the AdventureWorks2022 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2022, NOINDEX);
GO

B. Überprüfen der aktuellen Datenbank mit Unterdrückung von Informationsmeldungen

Im folgenden Beispiel wird die aktuelle Datenbank überprüft; alle Informationsmeldungen werden unterdrückt.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Verwandte Inhalte