DBCC CHECKDB (Transact-.SQL)

• 14.12.2017
• 22 Minuten zu lesen
• • p
  • M
  • m
  • M
  • P
  • +3

Gilt für: SQL Server (alle unterstützten Versionen) Azure SQL Database

Überprüft die logische und physische Integrität aller Objekte in der angegebenen Datenbank, indem die folgenden Vorgänge ausgeführt werden:

• Führt DBCC CHECKALLOC in der Datenbank aus.
• Führt DBCC CHECKTABLE für jede Tabelle und Ansicht in der Datenbank aus.
• Führt DBCC CHECKCATALOG für die Datenbank aus.
• Überprüft den Inhalt jeder indizierten Ansicht in der Datenbank.
• Überprüft die Konsistenz auf Verknüpfungsebene zwischen Tabellenmetadaten und Dateisystemverzeichnissen und -dateien, wenn varbinary(max)-Daten mit FILESTREAM im Dateisystem gespeichert werden.
• Überprüft die Service Broker-Daten in der Datenbank.

Das bedeutet, dass die Befehle DBCC CHECKALLOC, DBCC CHECKTABLE oder DBCC CHECKCATALOG nicht separat von DBCC CHECKDB ausgeführt werden müssen. Ausführlichere Informationen zu den Prüfungen, die diese Befehle durchführen, finden Sie in den Beschreibungen dieser Befehle.

Transact-SQL-Syntaxkonventionen

Syntax

DBCC CHECKDB ) ] } ] ] 

Argumente

Datenbankname | Datenbank_id | 0
Ist der Name oder die ID der Datenbank, für die Integritätsprüfungen durchgeführt werden sollen. Wenn nicht angegeben oder wenn 0 angegeben ist, wird die aktuelle Datenbank verwendet. Datenbanknamen müssen den Regeln für Bezeichner entsprechen.

NOINDEX
Legt fest, dass intensive Prüfungen von nicht geclusterten Indizes für Benutzertabellen nicht durchgeführt werden sollen. Dadurch verringert sich die Gesamtausführungszeit. NOINDEX wirkt sich nicht auf Systemtabellen aus, da Integritätsprüfungen immer auf Indizes von Systemtabellen durchgeführt werden.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Legt fest, dass DBCC CHECKDB die gefundenen Fehler repariert. Verwenden Sie die REPAIR-Optionen nur als letzten Ausweg. Die angegebene Datenbank muss sich im Einzelbenutzermodus befinden, um eine der folgenden Reparaturoptionen zu verwenden.

REPAIR_ALLOW_DATA_LOSS
Versucht, alle gemeldeten Fehler zu reparieren. Diese Reparaturen können einen gewissen Datenverlust verursachen.

REPAIR_FAST
Behält die Syntax nur aus Gründen der Abwärtskompatibilität bei. Es werden keine Reparaturvorgänge durchgeführt.

REPAIR_REBUILD
Führt Reparaturen durch, bei denen kein Datenverlust droht. Dies kann schnelle Reparaturen, wie das Reparieren von fehlenden Zeilen in nicht geclusterten Indizes, und zeitaufwändigere Reparaturen, wie das Wiederherstellen eines Index, umfassen.
Dieses Argument repariert keine Fehler, die FILESTREAM-Daten betreffen.

ALL_ERRORMSGS
Zeigt alle gemeldeten Fehler pro Objekt an. Standardmäßig werden alle Fehlermeldungen angezeigt. Das Angeben oder Weglassen dieser Option hat keine Auswirkung. Die Fehlermeldungen werden nach Objekt-ID sortiert, mit Ausnahme der Meldungen, die aus der tempdb-Datenbank generiert werden.

EXTENDED_LOGICAL_CHECKS
Wenn die Kompatibilitätsebene 100 ( SQL Server 2008) oder höher ist, führt logische Konsistenzprüfungen für eine indizierte Ansicht, XML-Indizes und räumliche Indizes durch, sofern vorhanden.
Weitere Informationen finden Sie unter Durchführen von logischen Konsistenzprüfungen für Indizes im Abschnitt Bemerkungen weiter unten in diesem Thema.

NO_INFOMSGS
Unterdrückt alle Informationsmeldungen.

TABLOCK
Veranlasst DBCC CHECKDB, Sperren zu erhalten, anstatt einen internen Datenbank-Snapshot zu verwenden. Dies schließt eine kurzfristige exklusive (X) Sperre für die Datenbank ein. TABLOCK führt dazu, dass DBCC CHECKDB auf einer stark belasteten Datenbank schneller läuft, verringert aber die auf der Datenbank verfügbare Gleichzeitigkeit, während DBCC CHECKDB läuft.

ESTIMATEONLY
Zeigt die geschätzte Menge an tempdb-Speicherplatz an, die für die Ausführung von DBCC CHECKDB mit allen anderen angegebenen Optionen erforderlich ist. Die eigentliche Datenbankprüfung wird nicht durchgeführt.

PHYSICAL_ONLY
Beschränkt die Prüfung auf die Integrität der physischen Struktur der Seiten- und Datensatzköpfe und die Zuordnungskonsistenz der Datenbank. Diese Prüfung wurde entwickelt, um eine kleine Overhead-Prüfung der physischen Konsistenz der Datenbank zu bieten, aber sie kann auch zerrissene Seiten, Prüfsummenfehler und allgemeine Hardwarefehler erkennen, die die Daten eines Benutzers gefährden können.
Ein vollständiger Lauf von DBCC CHECKDB kann erheblich länger dauern als frühere Versionen. Dieses Verhalten tritt auf, weil:

• Die logischen Prüfungen umfassender sind.
• Einige der zu prüfenden zugrunde liegenden Strukturen sind komplexer.
• Viele neue Prüfungen wurden eingeführt, um die neuen Funktionen einzubeziehen.
  Daher kann die Verwendung der Option PHYSICAL_ONLY eine wesentlich kürzere Laufzeit für DBCC CHECKDB auf großen Datenbanken bewirken und wird für den häufigen Einsatz auf Produktionssystemen empfohlen. Wir empfehlen dennoch, in regelmäßigen Abständen einen vollständigen Lauf von DBCC CHECKDB durchzuführen. Die Häufigkeit dieser Läufe hängt von Faktoren ab, die für einzelne Unternehmen und Produktionsumgebungen spezifisch sind.
  Dieses Argment impliziert immer NO_INFOMSGS und ist mit keiner der Reparaturoptionen erlaubt.

DATA_PURITY
Veranlasst DBCC CHECKDB, die Datenbank auf Spaltenwerte zu prüfen, die nicht gültig sind oder außerhalb des Bereichs liegen. DBCC CHECKDB erkennt zum Beispiel Spalten mit Datums- und Zeitwerten, die größer oder kleiner als der akzeptable Bereich für den Datentyp datetime sind, oder Spalten mit dezimalen oder approximativ-numerischen Daten, deren Skalen- oder Präzisionswerte nicht gültig sind.
Die Integritätsprüfungen für Spaltenwerte sind standardmäßig aktiviert und erfordern nicht die Option DATA_PURITY. Bei Datenbanken, die von früheren Versionen von SQL Server aktualisiert wurden, sind Spaltenwertprüfungen erst dann standardmäßig aktiviert, wenn DBCC CHECKDB WITH DATA_PURITY für die Datenbank fehlerfrei ausgeführt wurde. Danach prüft DBCC CHECKDB standardmäßig die Integrität von Spaltenwerten. Weitere Informationen darüber, wie CHECKDB durch ein Upgrade der Datenbank von früheren Versionen von SQL Server beeinflusst werden kann, finden Sie im Abschnitt Bemerkungen weiter unten in diesem Thema.

Validierungsfehler, die von dieser Option gemeldet werden, können nicht mit DBCC-Reparaturoptionen behoben werden. Informationen zum manuellen Korrigieren dieser Fehler finden Sie im Knowledge Base-Artikel 923247: Troubleshooting DBCC error 2570 in SQL Server 2005 und späteren Versionen.

MAXDOP
Gilt für: SQL Server ( SQL Server 2014 (12.x) SP2 und höher).

Übersteuert die Konfigurationsoption für den maximalen Grad der Parallelität von sp_configure für die Anweisung. Der 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 Resource Governor MAXDOP-Wert, der in ALTER WORKLOAD GROUP beschrieben wird. Alle semantischen Regeln, die mit der Konfigurationsoption für den maximalen Parallelitätsgrad verwendet werden, sind anwendbar, wenn Sie den Abfragehinweis MAXDOP verwenden. Weitere Informationen finden Sie unter Konfigurieren der Serverkonfigurationsoption für den maximalen Parallelitätsgrad.

Bemerkungen

DBCC CHECKDB untersucht keine deaktivierten Indizes. Weitere Informationen über deaktivierte Indizes finden Sie unter Deaktivierte Indizes und Einschränkungen.

Wenn ein benutzerdefinierter Typ als bytegeordnet gekennzeichnet ist, darf es nur eine Serialisierung des benutzerdefinierten Typs geben. Eine nicht konsistente Serialisierung von benutzerdefinierten Typen mit Byte-Order verursacht den Fehler 2537, wenn DBCC CHECKDB ausgeführt wird. Weitere Informationen finden Sie unter Anforderungen an benutzerdefinierte Typen.

Da die Ressourcendatenbank nur im Einzelbenutzermodus geändert werden kann, kann der DBCC CHECKDB-Befehl nicht direkt auf ihr ausgeführt werden. Wenn jedoch DBCC CHECKDB gegen die Master-Datenbank ausgeführt wird, wird intern auch ein zweites CHECKDB auf die Ressourcendatenbank ausgeführt. Dies bedeutet, dass DBCC CHECKDB zusätzliche Ergebnisse liefern kann. Der Befehl gibt zusätzliche Ergebnissätze zurück, wenn keine Optionen gesetzt sind oder wenn entweder die Option PHYSICAL_ONLY oder ESTIMATEONLY gesetzt ist.

Beginnend mit SQL Server 2005 (9.x) SP2 löscht die Ausführung von DBCC CHECKDB nicht mehr den Plan-Cache für die Instanz von SQL Server. Vor SQL Server 2005 (9.x) SP2 löscht die Ausführung von DBCC CHECKDB den Plan-Cache. Das Löschen des Plan-Caches führt zu einer Neukompilierung aller späteren Ausführungspläne und kann zu einer plötzlichen, vorübergehenden Abnahme der Abfrageleistung führen.

Durchführen von logischen Konsistenzprüfungen auf Indizes

Die logische Konsistenzprüfung auf Indizes variiert je nach Kompatibilitätsebene der Datenbank wie folgt:

• Wenn die Kompatibilitätsebene 100 (SQL Server 2008) oder höher ist:
• Wenn nicht NOINDEX angegeben ist, führt DBCC CHECKDB sowohl physische als auch logische Konsistenzprüfungen auf einer einzelnen Tabelle und auf allen ihren nicht geclusterten Indizes durch. Bei XML-Indizes, räumlichen Indizes und indizierten Ansichten werden jedoch standardmäßig nur physische Konsistenzprüfungen durchgeführt.
• Wenn WITH EXTENDED_LOGICAL_CHECKS angegeben ist, werden logische Prüfungen für eine indizierte Ansicht, XML-Indizes und räumliche Indizes, sofern vorhanden, durchgeführt. Standardmäßig werden die physischen Konsistenzprüfungen vor den logischen Konsistenzprüfungen durchgeführt. Wenn NOINDEX ebenfalls angegeben ist, werden nur die logischen Prüfungen durchgeführt.

Diese logischen Konsistenzprüfungen vergleichen die interne Indextabelle des Indexobjekts mit der Benutzertabelle, auf die es verweist. Um abweichende Zeilen zu finden, wird eine interne Abfrage erstellt, um eine vollständige Überschneidung der internen und der Benutzertabelle durchzuführen. Die Ausführung dieser Abfrage kann sich sehr stark auf die Leistung auswirken, und ihr Fortschritt kann nicht verfolgt werden. Daher empfehlen wir, WITH EXTENDED_LOGICAL_CHECKS nur anzugeben, wenn Sie Indexprobleme vermuten, die nicht mit physischer Korruption zusammenhängen, oder wenn Prüfsummen auf Seitenebene deaktiviert wurden und Sie Hardwarekorruption auf Spaltenebene vermuten.

• Wenn der Index ein gefilterter Index ist, führt DBCC CHECKDB Konsistenzprüfungen durch, um zu überprüfen, ob die Indexeinträge das Filterprädikat erfüllen.
• Wenn der Kompatibilitätslevel 90 oder weniger ist, sofern nicht NOINDEX angegeben ist, führt DBCC CHECKDB sowohl physische als auch logische Konsistenzprüfungen für eine einzelne Tabelle oder indizierte Ansicht und für alle ihre nicht geclusterten und XML-Indizes durch. Räumliche Indizes werden nicht unterstützt.
• Beginnend mit SQL Server 2016 werden zusätzliche Prüfungen auf persistierte berechnete Spalten, UDT-Spalten und gefilterte Indizes standardmäßig nicht ausgeführt, um die teuren Ausdrucksauswertungen zu vermeiden. Diese Änderung reduziert die Dauer von CHECKDB für Datenbanken, die diese Objekte enthalten, erheblich. Die physischen Konsistenzprüfungen für diese Objekte werden jedoch immer abgeschlossen. Nur wenn die Option EXTENDED_LOGICAL_CHECKS angegeben ist, werden die Ausdrucksauswertungen zusätzlich zu den bereits vorhandenen logischen Prüfungen (indizierte Ansicht, XML-Indizes und räumliche Indizes) als Teil der Option EXTENDED_LOGICAL_CHECKS durchgeführt.

Um die Kompatibilitätsebene einer Datenbank zu erfahren

• Anzeigen oder Ändern der Kompatibilitätsebene einer Datenbank

Interner Datenbank-Snapshot

DBCC CHECKDB verwendet einen internen Datenbank-Snapshot für die transaktionale Konsistenz, die zur Durchführung dieser Prüfungen erforderlich ist. Dadurch werden Blockierungen und Gleichzeitigkeitsprobleme bei der Ausführung dieser Befehle vermieden. Weitere Informationen finden Sie unter Anzeigen der Größe der Sparse-Datei eines Datenbank-Snapshots (Transact-SQL) und im Abschnitt DBCC Interne Datenbank-Snapshot-Verwendung in DBCC (Transact-SQL). Wenn ein Snapshot nicht erstellt werden kann oder TABLOCK angegeben ist, erwirbt DBCC CHECKDB Sperren, um die erforderliche Konsistenz zu erreichen. In diesem Fall ist eine exklusive Datenbanksperre erforderlich, um die Zuordnungsprüfungen durchzuführen, und gemeinsame Tabellensperren sind erforderlich, um die Tabellenprüfungen durchzuführen.DBCC CHECKDB schlägt fehl, wenn es gegen den Master ausgeführt wird, wenn ein interner Datenbank-Snapshot nicht erstellt werden kann.Wenn DBCC CHECKDB gegen tempdb ausgeführt wird, werden keine Zuordnungs- oder Katalogprüfungen durchgeführt und es müssen gemeinsame Tabellensperren erworben werden, um Tabellenprüfungen durchzuführen. Dies liegt daran, dass aus Leistungsgründen keine Datenbank-Snapshots auf tempdb verfügbar sind. In Microsoft SQL Server 2012 oder einer früheren Version von SQL Server können Fehlermeldungen auftreten, wenn Sie den Befehl DBCC CHECKDB für eine Datenbank ausführen, deren Dateien sich auf einem ReFS-formatierten Volume befinden. Weitere Informationen finden Sie im Knowledge Base-Artikel 2974455: DBCC CHECKDB-Verhalten, wenn sich die SQL Server-Datenbank auf einem ReFS-Volume befindet.

Prüfen und Reparieren von FILESTREAM-Daten

Wenn FILESTREAM für eine Datenbank und Tabelle aktiviert ist, können Sie optional varbinary(max) binary large objects (BLOBs) im Dateisystem speichern. Wenn Sie DBCC CHECKDB für eine Datenbank verwenden, die BLOBs im Dateisystem speichert, prüft DBCC die Konsistenz auf Link-Ebene zwischen dem Dateisystem und der Datenbank. Wenn eine Tabelle beispielsweise eine varbinary(max)-Spalte enthält, die das FILESTREAM-Attribut verwendet, prüft DBCC CHECKDB, ob es eine Eins-zu-Eins-Zuordnung zwischen Dateisystemverzeichnissen und -dateien und Tabellenzeilen, -spalten und -spaltenwerten gibt. DBCC CHECKDB kann eine Beschädigung reparieren, wenn Sie die Option REPAIR_ALLOW_DATA_LOSS angeben. Um eine FILESTREAM-Korruption zu reparieren, löscht DBCC alle Tabellenzeilen, in denen Dateisystemdaten fehlen.

Best Practices

Wir empfehlen, dass Sie die Option PHYSICAL_ONLY für den häufigen Einsatz auf Produktionssystemen verwenden. Die Verwendung von PHYSICAL_ONLY kann die Laufzeit von DBCC CHECKDB auf großen Datenbanken erheblich verkürzen. Wir empfehlen Ihnen außerdem, DBCC CHECKDB regelmäßig ohne Optionen auszuführen. Wie häufig Sie diese Läufe durchführen sollten, hängt von den einzelnen Unternehmen und ihren Produktionsumgebungen ab.

Parallele Überprüfung von Objekten

Standardmäßig führt DBCC CHECKDB 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 wie bei parallelen Abfragen konfiguriert. Um die maximale Anzahl der für die DBCC-Prüfung verfügbaren Prozessoren zu begrenzen, verwenden Sie sp_configure. Weitere Informationen finden Sie unter Konfigurieren der Serverkonfigurationsoption für den maximalen Parallelitätsgrad. Die parallele Prüfung kann mit dem Trace-Flag 2528 deaktiviert werden. Weitere Informationen finden Sie unter Trace-Flags (Transact-SQL).

Verstehen von DBCC-Fehlermeldungen

Nach Beendigung des DBCC CHECKDB-Befehls wird eine Meldung in das SQL Server-Fehlerprotokoll geschrieben. Wenn der DBCC-Befehl erfolgreich ausgeführt wurde, gibt die Meldung den Erfolg und die Zeit an, in der der Befehl ausgeführt wurde. Wenn der DBCC-Befehl aufgrund eines Fehlers vor Abschluss der Prüfung abbricht, gibt die Meldung an, dass der Befehl abgebrochen wurde, einen Statuswert und die Dauer der Ausführung des Befehls. In der folgenden Tabelle sind die Statuswerte aufgeführt und beschrieben, die in der Meldung enthalten sein können.

Status	Beschreibung
0	Fehler Nummer 8930 wurde ausgelöst. Dies weist auf eine Beschädigung der Metadaten hin, die den DBCC-Befehl beendete.
1	Fehler Nummer 8967 wurde ausgelöst. Es gab einen internen DBCC-Fehler.
2	Ein Fehler trat während der Datenbankreparatur im Notfallmodus auf.
3	Dies weist auf eine Beschädigung der Metadaten hin, die den DBCC-Befehl beendete.
4	Eine Assert- oder Zugriffsverletzung wurde festgestellt.
5	Ein unbekannter Fehler ist aufgetreten, der den DBCC-Befehl beendet hat.

Fehlerberichterstattung

Eine Dump-Datei (SQLDUMP*nnnn*.txt) wird im SQL Server LOG-Verzeichnis erstellt, wenn DBCC CHECKDB einen Korruptionsfehler entdeckt. Wenn die Features Feature Usage Data Collection und Error Reporting für die Instanz von SQL Server aktiviert sind, wird die Datei automatisch an Microsoft weitergeleitet. Die gesammelten Daten werden zur Verbesserung der SQL Server-Funktionalität verwendet und enthalten die Ergebnisse des DBCC CHECKDB-Befehls sowie zusätzliche Diagnoseausgaben. Der Zugriff ist auf das SQL Server-Dienstkonto und Mitglieder der sysadmin-Rolle beschränkt. Standardmäßig enthält die sysadmin-Rolle alle Mitglieder der Gruppe Windows BUILTIN\Administrators und der Gruppe des lokalen Administrators. Der DBCC-Befehl schlägt nicht fehl, wenn der Datensammlungsprozess fehlschlägt.

Fehler beheben

Wenn von DBCC CHECKDB Fehler gemeldet werden, empfehlen wir, die Datenbank aus der Datenbanksicherung wiederherzustellen, anstatt REPAIR mit einer der REPAIR-Optionen auszuführen. Wenn keine Sicherung vorhanden ist, werden die gemeldeten Fehler durch die Ausführung von repair korrigiert. Die zu verwendende Reparaturoption wird am Ende der Liste der gemeldeten Fehler angegeben. Die Korrektur der Fehler mit der Option REPAIR_ALLOW_DATA_LOSS kann jedoch das Löschen einiger Seiten und damit einiger Daten erfordern.

Unter bestimmten Umständen können Werte in die Datenbank eingegeben werden, die nicht gültig sind oder außerhalb des Bereichs liegen, der durch den Datentyp der Spalte vorgegeben ist. DBCC CHECKDB kann Spaltenwerte erkennen, die nicht für alle Spaltendatentypen gültig sind. Daher kann die Ausführung von DBCC CHECKDB mit der Option DATA_PURITY auf Datenbanken, die von früheren Versionen von SQL Server aktualisiert wurden, bereits vorhandene Spaltenwertfehler aufdecken. Da SQL Server diese Fehler nicht automatisch reparieren kann, muss der Spaltenwert manuell aktualisiert werden. Wenn CHECKDB einen solchen Fehler feststellt, gibt CHECKDB eine Warnung, die Fehlernummer 2570 und Informationen zur Identifizierung der betroffenen Zeile und zur manuellen Korrektur des Fehlers zurück.

Die Reparatur kann im Rahmen einer Benutzertransaktion durchgeführt werden, damit der Benutzer die vorgenommenen Änderungen zurücknehmen kann. Wenn die Reparatur rückgängig gemacht wird, enthält die Datenbank immer noch Fehler und muss aus einer Sicherung wiederhergestellt werden. Nachdem die Reparaturen abgeschlossen sind, sichern Sie die Datenbank.

Fehlerbehebung im Datenbank-Notfallmodus

Wenn eine Datenbank mit der ALTER DATABASE-Anweisung in den Notfallmodus versetzt wurde, kann DBCC CHECKDB einige spezielle Reparaturen an der Datenbank durchführen, wenn die Option REPAIR_ALLOW_DATA_LOSS angegeben ist. Diese Reparaturen können es ermöglichen, normalerweise nicht wiederherstellbare Datenbanken in einem physisch konsistenten Zustand wieder online zu bringen. Diese Reparaturen sollten nur als letzter Ausweg und nur dann verwendet werden, wenn Sie die Datenbank nicht aus einer Sicherung wiederherstellen können. Wenn die Datenbank in den Notfallmodus versetzt wird, wird die Datenbank als READ_ONLY markiert, die Protokollierung ist deaktiviert und der Zugriff ist auf Mitglieder der festen Serverrolle sysadmin beschränkt.

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

• DBCC CHECKDB verwendet Seiten, die aufgrund von E/A- oder Prüfsummenfehlern als unzugänglich markiert wurden, als ob die Fehler nicht aufgetreten wären. Dadurch erhöhen sich die Chancen für eine Datenwiederherstellung aus der Datenbank.
• DBCC CHECKDB versucht, die Datenbank mit regulären protokollbasierten Wiederherstellungstechniken wiederherzustellen.
• Wenn die Datenbankwiederherstellung aufgrund einer Beschädigung des Transaktionsprotokolls nicht erfolgreich ist, wird das Transaktionsprotokoll neu erstellt. Die Wiederherstellung des Transaktionsprotokolls kann zum Verlust der Transaktionskonsistenz führen.

Wenn der Befehl DBCC CHECKDB erfolgreich ist, befindet sich die Datenbank in einem physisch konsistenten Zustand und der Datenbankstatus wird auf ONLINE gesetzt. Die Datenbank kann jedoch eine oder mehrere transaktionale Inkonsistenzen enthalten. Es wird empfohlen, DBCC CHECKCONSTRAINTS auszuführen, um Fehler in der Geschäftslogik zu identifizieren und die Datenbank sofort zu sichern.

Wenn der DBCC CHECKDB-Befehl fehlschlägt, kann die Datenbank nicht repariert werden.

Das Ausführen des DBCC CHECKDB-Befehls mit der Option REPAIR_ALLOW_DATA_LOSS in replizierten Datenbanken

Das Ausführen des DBCC CHECKDB-Befehls mit der Option REPAIR_ALLOW_DATA_LOSS kann sich auf Benutzerdatenbanken (Veröffentlichungs- und Abonnementdatenbanken) und die von der Replikation verwendete Verteilungsdatenbank auswirken. Publikations- und Abonnementdatenbanken enthalten veröffentlichte Tabellen und Replikationsmetadatentabellen. Achten Sie auf die folgenden potenziellen Probleme in diesen Datenbanken:

• Veröffentlichte Tabellen. Aktionen, die vom CHECKDB-Prozess durchgeführt werden, um beschädigte Benutzerdaten zu reparieren, werden möglicherweise nicht repliziert:
• Die Merge-Replikation verwendet Trigger, um Änderungen an veröffentlichten Tabellen zu verfolgen. Wenn Zeilen durch den CHECKDB-Prozess eingefügt, aktualisiert oder gelöscht werden, werden die Trigger nicht ausgelöst; daher wird die Änderung nicht repliziert.
• Die transaktionale Replikation verwendet das Transaktionsprotokoll, um Änderungen an veröffentlichten Tabellen zu verfolgen. Der Log Reader Agent verschiebt diese Änderungen dann in die Verteilungsdatenbank. Einige DBCC-Reparaturen werden zwar protokolliert, können aber nicht vom Log Reader Agent repliziert werden. Wenn zum Beispiel eine Datenseite durch den CHECKDB-Prozess freigegeben wird, übersetzt der Log Reader Agent dies nicht in eine DELETE-Anweisung; daher wird die Änderung nicht repliziert.
• Replikationsmetadaten-Tabellen. Aktionen, die vom CHECKDB-Prozess durchgeführt werden, um beschädigte Replikationsmetadatentabellen zu reparieren, erfordern das Entfernen und Neukonfigurieren der Replikation.

Wenn Sie den DBCC CHECKDB-Befehl mit der Option REPAIR_ALLOW_DATA_LOSS auf einer Benutzerdatenbank oder Verteilungsdatenbank ausführen müssen:

1. Setzen Sie das System still: Stoppen Sie die Aktivität auf der Datenbank und auf allen anderen Datenbanken in der Replikationstopologie und versuchen Sie dann, alle Knoten zu synchronisieren. Weitere Informationen finden Sie unter Quiesce einer Replikationstopologie (Replikations-Transact-SQL-Programmierung).
2. Führen Sie DBCC CHECKDB aus.
3. Wenn der DBCC CHECKDB-Bericht Reparaturen für Tabellen in der Verteilungsdatenbank oder für Replikationsmetadatentabellen 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 DBCC CHECKDB-Bericht Reparaturen für replizierte Tabellen enthält, führen Sie eine Datenvalidierung durch, um festzustellen, ob es Unterschiede zwischen den Daten in den Veröffentlichungs- und Abonnementdatenbanken gibt.

Ergebnismengen

DBCC CHECKDB gibt die folgende Ergebnismenge zurück. Die Werte können variieren, außer wenn die Optionen ESTIMATEONLY, PHYSICAL_ONLY oder NO_INFOMSGS angegeben sind:

 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 die folgende Ergebnismenge (Nachricht) zurück, wenn NO_INFOMSGS angegeben ist:

 The command(s) completed successfully.

DBCC CHECKDB gibt die folgende Ergebnismenge zurück, wenn PHYSICAL_ONLY angegeben ist:

 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 die folgende Ergebnismenge zurück, wenn ESTIMATEONLY angegeben ist.

 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 in der festen Serverrolle sysadmin oder in der festen Datenbankrolle db_owner.

Beispiele

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

Das folgende Beispiel führt DBCC CHECKDB für die aktuelle Datenbank und für die AdventureWorks2012-Datenbank aus.

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

B. Prüfen der aktuellen Datenbank, Unterdrücken von Informationsmeldungen

Das folgende Beispiel prüft die aktuelle Datenbank und unterdrückt alle Informationsmeldungen.

DBCC CHECKDB WITH NO_INFOMSGS; GO 

Siehe auch

DBCC (Transact-SQL)
Anzeigen der Größe der Sparse-Datei eines Datenbank-Snapshots (Transact-SQL)
sp_helpdb (Transact-SQL)
Systemtabellen (Transact-SQL)