DBCC CHECKDB (Transact-SQL)

Aktualisiert: 17. November 2008

Überprüft die logische und physikalische 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 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 von diesen Befehlen ausgeführten Überprüfungen finden Sie in den Beschreibungen dieser Befehle.

Transact-SQL-Syntaxkonventionen

Syntax

DBCC CHECKDB 
[
    [ ( database_name | database_id | 0
        [ , NOINDEX 
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
        ) ]
    [ WITH 
        {
            [ ALL_ERRORMSGS ]
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
        }
    ]
]

Argumente

• database_name | database_id | 0
  Der Name oder die ID der Datenbank, für die Integritätsprüfungen ausgeführt werden. Wird das Argument nicht angegeben oder wird 0 angegeben, wird die aktuelle Datenbank verwendet. Datenbanknamen müssen den Regeln für Bezeichner entsprechen.

• NOINDEX
  Gibt an, dass keine intensive Überprüfung nicht gruppierter Indizes für Benutzertabellen ausgeführt werden soll. Auf diese Weise wird die Gesamtausführungszeit reduziert. 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 festgestellte Fehler behebt. 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.
  • REPAIR_FAST
    Wird nur aus Gründen der Abwärtskompatibilität der Syntax beibehalten. Es werden keine Reparaturaktionen ausgeführt.
  • REPAIR_REBUILD
    Führt sowohl kleinere, schnelle Reparaturen, wie z. B. das Reparieren zusätzlicher Schlüssel in nicht gruppierten Indizes und zeitaufwändige Reparaturen, wie das Neuerstellen von Indizes, aus. Diese Reparaturen können ohne das Risiko von Datenverlusten ausgeführt werden.

  Wichtig:

  Verwenden Sie die REPAIR-Optionen nur als letzte Möglichkeit. Zum Reparieren von Fehlern empfiehlt sich das Wiederherstellen mithilfe einer Sicherung. Bei Reparaturvorgängen werden keine Einschränkungen berücksichtigt, die möglicherweise in oder zwischen Tabellen 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, empfiehlt es sich, die Datenbank vor dem Ausführen von DBCC CHECKDB zu sichern.

• ALL_ERRORMSGS
  Zeigt alle gemeldeten Fehler für jedes Objekt 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. Die Fehlermeldungen werden nach der Objekt-ID sortiert. Davon ausgenommen sind Meldungen, die für die tempdb-Datenbank generiert wurden.

  In SQL Server Management Studio werden maximal 1.000 Fehlermeldungen zurückgegeben. Mit Management Studio müssen Sie DBCC CHECKDB möglicherweise mehrmals ausführen, um eine vollständige Fehlerliste abzurufen, wenn ALL_ERRORMSGS angegeben ist. Es wird empfohlen, den DBCC-Befehl auszuführen, indem Sie sqlcmd utility verwenden oder einen SQL Server-Agentauftrag planen, um den Befehl auszuführen und die Ausgabe an eine Datei weiterzuleiten. Mit jeder dieser Methoden kann sichergestellt werden, dass beim einmaligen Ausführen des Befehls alle Fehlermeldungen gemeldet werden.

• NO_INFOMSGS
  Alle Informationsmeldungen werden unterdrückt.

• TABLOCK
  Bewirkt, dass DBCC CHECKDB Sperren abruft, statt einen internen Datenbanksnapshot zu verwenden. Dies schließt eine kurzfristige exklusive Sperre (X) für die Datenbank ein. Durch TABLOCK wird DBCC CHECKDB schneller auf einer Datenbank bei starker Auslastung ausgeführt, jedoch wird während der Ausführung von DBCC CHECKDB die in der Datenbank verfügbare Parallelität verringert. Weitere Informationen zu Sperren finden Sie unter Sperrmodi.

  TABLOCK beschränkt die ausgeführten Überprüfungen. DBCC CHECKCATALOG wird nicht für die Datenbank ausgeführt, und Service Broker-Daten 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 physikalischen Struktur der Seiten- und Datensatzheader, der physikalischen Struktur von B-Strukturen und der Zuordnungskonsistenz der Datenbank. Mithilfe der Überprüfung kann mit geringem Verwaltungsaufwand eine Überprüfung der physikalischen Konsistenz der Datenbank vorgenommen werden. Dabei können auch zerrissene Seiten, Prüfsummenfehler und häufige Hardwarefehler festgestellt werden, die Benutzerdaten gefährden können. PHYSICAL_ONLY setzt immer NO_INFOMSGS voraus und kann nicht mit einer der Reparaturoptionen verwendet werden.

• 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 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, ist die Spaltenwertprüfung nicht standardmäßig aktiviert. Die Aktivierung erfolgt erst, wenn DBCC CHECKDB WITH DATA_PURITY fehlerfrei für die Datenbank ausgeführt wurde. Danach wird die Spaltenwertintegrität standardmäßig von DBCC CHECKDB überprüft. Weitere Informationen zu den möglichen Auswirkungen der Aktualisierung einer Datenbank von einer früheren Version von SQL Server finden Sie im Abschnitt mit den Hinweisen weiter unten in diesem Thema.

  Wenn PHYSICAL_ONLY angegeben ist, wird die Spaltenintegrität nicht ü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.

Resultsets

DBCC CHECKDB gibt das folgende Resultset zurück. Die Werte können variieren, es sei denn, die Optionen ESTIMATEONLY, PHYSICAL_ONLY oder NO_INFOMSGS werden angegeben:

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.

Hinweise

In früheren Versionen von SQL Server nehmen die tabellen- und indexbasierten Zeilen- und Seitenzähler möglicherweise falsche Werte an. Unter bestimmten Bedingungen können sie sogar negative Werte annehmen. In SQL Server 2005 werden diese Werte immer richtig verwaltet. Daher sollten in SQL Server 2005 erstellten Datenbanken nie fehlerhafte Zählungen enthalten sein. Bei Datenbanken, die auf SQL Server 2005 aktualisiert wurden, ist dies jedoch möglich. Hierbei handelt es sich nicht um eine Beschädigung der Daten, die in der Datenbank gespeichert sind. DBCC CHECKDB wurde verbessert, sodass nun erkannt wird, wenn diese Anzahl negativ wird. Wenn negative Zählwerte erkannt werden, enthält die Ausgabe von DBCC CHECKDB eine Warnung und die Empfehlung, DBCC UPDATEUSAGE auszuführen, um das Problem zu beheben. Obwohl es den Anschein hat, als wäre dieses Problem durch die Aktualisierung der Datenbank auf SQL Server 2005 verursacht worden, waren die falschen Zählwerte tatsächlich schon vor dem Aktualisierungsvorgang vorhanden.

Deaktivierte Indizes werden von DBCC CHECKDB nicht überprüft. Weitere Informationen zu deaktivierten Indizes finden Sie unter Deaktivieren von Indizes.

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 beim Ausführen von DBCC CHECKDB der Fehler 2537 ausgegeben. Weitere Informationen finden Sie unter User-Defined Type Requirements.

Da der Zugriff auf die Ressourcendatenbank nur im Einzelbenutzermodus möglich ist, kann der DBCC CHECKDB-Befehl für diese Datenbank nicht direkt ausgeführt werden. Wird DBCC CHECKDB jedoch für die master-Datenbank ausgeführt, 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 Resultsets zurück, wenn keine Optionen festgelegt wurden oder wenn entweder die Option PHYSICAL_ONLY oder die Option ESTIMATEONLY festgelegt wurde.

In Versionen von SQL Server 2005 vor SP2 wurde beim Ausführen von DBCC CHECKDB der Plancache für die Instanz von SQL Server gelöscht. Durch das Löschen des Plancaches wird eine Neukompilierung aller späteren Ausführungspläne verursacht, und möglicherweise entsteht eine plötzliche temporäre Verringerung der Abfrageleistung. In SP2 wird beim Ausführen von DBCC CHECKDB der Plancache nicht gelöscht.

Interner Datenbanksnapshot

DBCC CHECKDB verwendet einen internen Datenbanksnapshot 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 Grundlegendes zur Größe von Dateien mit geringer Dichte in Datenbanksnapshots und im Abschnitt zur Verwendung von internen Datenbanksnapshots in DBCC unter DBCC (Transact-SQL). Wenn kein Snapshot erstellt werden kann oder TABLOCK angegeben wird, ruft DBCC CHECKDB Sperren ab, um die erforderliche Konsistenz bereitzustellen. In diesem Fall ist eine exklusive Datenbanksperre erforderlich, um die Zuordnungsprüfungen auszuführen; weiterhin sind gemeinsame Tabellensperren erforderlich, um die Tabellenprüfungen auszuführen.

Die Ausführung von DBCC CHECKDB für master meldet einen Fehler, wenn kein interner Datenbanksnapshot erstellt werden kann.

Das Ausführen von DBCC CHECKDB für tempdb bewirkt keine Zuordnungs- oder Katalogüberprüfungen; weiterhin sind gemeinsame Tabellensperren erforderlich, um Tabellenüberprüfungen auszuführen. Dies liegt daran, dass aus Leistungsgründen keine Datenbanksnapshots auf tempdb verfügbar sind. Das bedeutet, dass die erforderliche Transaktionskonsistenz nicht bereitgestellt werden kann.

Bewährte Methoden

In SQL Server 2005 kann das Ausführen von DBCC CHECKDB ohne Optionen gegenüber früheren Versionen erheblich mehr Zeit in Anspruch nehmen. Dieses Verhalten hat folgende Ursachen:

• Die eingeführten logischen Überprüfungen sind umfassender.
• Einige der zugrunde liegenden Strukturen, die überprüft werden, sind komplexer.
• Es wurden zahlreiche neue Überprüfungen eingeführt, um neue Features in SQL Server 2005 hinzuzufügen.

Daher sollte die Option PHYSICAL_ONLY für die häufige Verwendung in Produktionssystemen verwendet werden. 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 ist von den jeweiligen Unternehmen und Produktionsumgebungen abhängig.

Paralleles Überprüfen von Objekten

Standardmäßig führt DBCC CHECKDB eine parallele Überprüfung von Objekten aus. Der Grad an Parallelität wird automatisch durch den Abfrageprozessor festgelegt. 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 max degree of parallelism (Option). Parallele Überprüfung kann durch das Ablaufverfolgungsflag 2528 deaktiviert werden. Weitere Informationen finden Sie unter Ablaufverfolgungsflags (Transact-SQL).

Grundlegendes zu DBCC-Fehlermeldungen

Nach der Fertigstellung des Befehls DBCC CHECKDB wird eine Meldung in das SQL Server-Fehlerprotokoll geschrieben. Wenn der DBCC-Befehl erfolgreich ausgeführt wird, gibt die Meldung den Erfolg und die Dauer der Ausführung an. Wenn der DBCC-Befehl vor Abschluss der Überprüfung aufgrund eines Fehlers beendet wird, gibt die Meldung das Beenden des Befehls, einen Statuswert sowie die Dauer der Befehlsausführung an. In der folgenden Tabelle sind die Statuswerte aufgeführt und beschrieben, die in der Meldung enthalten sein können.

Fehlerberichterstellung

In SQL Server 2005 Service Pack 1 wird jedes Mal eine Sicherungsdatei (SQLDUMPnnnn.txt) im SQL Server-Verzeichnis LOG erstellt, wenn DBCC CHECKDB einen Fehler durch eine Beschädigung erkennt. 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 CHECKDB-Befehls sowie eine zusätzliche Diagnoseausgabe. 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 CHECKDB Fehler meldet, empfiehlt es sich, die Datenbank mithilfe einer Datenbanksicherung wiederherzustellen, statt REPAIR 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 Werte in die Datenbank eingegeben, die basierend auf dem Datentyp der Spalte ungültig sind oder außerhalb des gültigen Bereichs liegen. In SQL Server 2000 führt DBCC CHECKDB keine Bereichs- oder Integritätsprüfungen für diese Spaltenwerte aus. In SQL Server 2005 kann DBCC CHECKDB jedoch ungültige Spaltenwerte für alle Spaltendatentypen erkennen. Wenn DBCC CHECKDB mit der Option DATA_PURITY für Datenbanken ausgeführt wird, die von früheren Versionen von SQL Server aktualisiert wurden, ist es daher möglich, dass bereits vorhandene Spaltenwertfehler aufgedeckt werden. Da SQL Server 2005 diese Fehler nicht automatisch reparieren kann, muss der Spaltenwert manuell aktualisiert werden. Wenn CHECKDB einen derartigen Fehler erkennt, werden eine Warnung, die Fehlernummer 2570 sowie Informationen zurückgegeben, anhand derer die betroffene Zeile identifiziert 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 für Reparaturen ein Rollback ausgeführt wird, enthält die Datenbank immer noch Fehler und muss von 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 mit der ALTER DATABASE-Anweisung in den Notfallmodus versetzt wurde, können mit DBCC CHECKDB einige spezielle Reparaturen an der Datenbank ausgeführt werden, wenn die Option REPAIR_ALLOW_DATA_LOSS angegeben wurde. Durch diese Reparaturen können normalerweise nicht wiederherstellbare Datenbanken in einem physikalisch konsistenten Zustand wieder online geschaltet werden. Die Reparaturen sollten als letzte Möglichkeit und nur dann verwendet werden, wenn die Datenbank nicht von einer Sicherung wiederhergestellt werden kann. Wenn sich die Datenbank im Notfallmodus befindet, wird sie als READ_ONLY markiert, die Protokollierung deaktiviert und der Zugriff auf Mitglieder der festen Serverrolle sysadmin beschränkt.

Hinweis:
Sie können den DBCC CHECKDB-Befehl nicht im Notfallmodus innerhalb einer Benutzertransaktion ausführen und nach der Ausführung für die Transaktion ein Rollback ausführen.

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- oder Prüfsummenfehlern mit Kein Zugriff markiert 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 Wiederherstellungstechniken wiederherzustellen.
• Wenn die Datenbank aufgrund einer Beschädigung des Transaktionsprotokolls nicht wiederhergestellt werden kann, wird das Transaktionsprotokoll neu erstellt. Beim Neuerstellen des Transaktionsprotokolls kann die Transaktionskonsistenz möglicherweise verloren gehen.

Wenn der DBCC CHECKDB-Befehl erfolgreich ausgeführt wurde, befindet sich die Datenbank in einem physikalisch konsistenten Zustand, und der Datenbankstatus wird auf ONLINE festgelegt. Die Datenbank kann jedoch 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.

Wenn der DBCC CHECKDB-Befehl einen Fehler generiert, kann die Datenbank nicht repariert 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 (Publikations- und Abonnementdatenbanken) und die von der Replikation verwendete Verteilungsdatenbank haben. Publikations- und Abonnementdatenbanken schließen veröffentlichte Tabellen und Tabellen mit Replikationsmetadaten ein. Beachten Sie folgende mögliche 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. Werden Zeilen vom CHECKDB-Prozess eingefügt, aktualisiert oder gelöscht, 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.

Führen Sie Folgendes aus, 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ät in der Datenbank und allen anderen Datenbanken in der Replikationstopologie, und versuchen Sie anschließend, alle Knoten zu synchronisieren. Weitere Informationen finden Sie unter How to: Quiesce a Replication Topology (Replication Transact-SQL Programming).
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 einschließt, entfernen Sie die Replikation, und konfigurieren Sie sie neu. Weitere Informationen finden Sie unter Entfernen der Replikation.
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 Publikations- und Abonnementdatenbanken bestehen. Weitere Informationen finden Sie unter Fehlende Übereinstimmung der Daten auf dem Verleger und auf dem Abonnenten.

Berechtigungen

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

Beispiele

A. Überprüfen der aktuellen Datenbank und der AdventureWorks-Datenbank

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

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

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

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

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Siehe auch

Verweis

DBCC (Transact-SQL)
sp_helpdb (Transact-SQL)
Systemtabellen (Transact-SQL)

Andere Ressourcen

Physische Datenbankarchitektur
Grundlegendes zur Größe von Dateien mit geringer Dichte in Datenbanksnapshots
Problembehandlung von DBCC-Fehlern in indizierten Sichten
Optimieren der DBCC CHECKDB-Leistung

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf