Beheben von Problemen mit der Datenbankkonsistenz, die von DBCC CHECKDB gemeldet wurden

In diesem Artikel wird erläutert, wie vom DBCC CHECKDB Befehl gemeldete Fehler untersucht oder behoben werden.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 2015748

Symptome

Wenn die DBCC CHECKDB (oder andere ähnliche Befehle wie DBCC CHECKTABLE) ausgeführt wird, wird eine Meldung wie die folgende in das SQL Server-Fehlerprotokoll geschrieben:

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors and repaired 3 errors.
Elapsed time: 0 hours 0 minutes 0 seconds.
Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001.
This is an informational message only. No user action is required.

Diese Meldung zeigt, wie viele Datenbankkonsistenzfehler gefunden wurden und wie viele repariert wurden, wenn eine Reparaturoption verwendet wurde. Diese Nachricht wird auch in das Windows-Anwendungsereignisprotokoll als Meldung auf Informationsebene mit EventID=8957 geschrieben. Auch wenn Fehler gemeldet werden, handelt es sich bei dieser Meldung um eine Meldung auf Informationsebene.

Die Informationen in der Nachricht beginnend mit "interne Datenbankmomentaufnahme..." werden nur angezeigt, wenn DBCC CHECKDB online ausgeführt wurde, wobei sich die Datenbank nicht im Modus SINGLE_USER befindet. Dies liegt daran, dass für ein online DBCC CHECKDB, eine interne Datenbankmomentaufnahme verwendet wird, um eine konsistente Datenmenge darzustellen, die überprüft werden soll.

In diesem Artikel wird nicht erläutert, wie Sie jeden spezifischen Fehler behandeln, der von DBCC CHECKDB gemeldet wird, sondern vielmehr den allgemeinen Ansatz, wenn Fehler gemeldet werden. Alle Verweise auf CHECKDB diesen Artikel gelten auch für DBCC CHECKTABLE und DBCC CHECKFILEGROUP , sofern nicht angegeben.

Ursache

Der DBCC CHECKDB Befehl überprüft die physische und logische Konsistenz von Datenbankseiten, Zeilen, Zuordnungsseiten, Indexbeziehungen, referenzieller Integrität der Systemtabellen und andere Strukturprüfungen. Wenn eine dieser Prüfungen fehlschlägt (je nach ausgewählten Optionen), werden Fehler gemeldet.

Die Ursachen dieser Probleme können von Dateisystembeschädigungen, zugrunde liegenden Hardwaresystemproblemen, Treiberproblemen, beschädigten Seiten im Speicher- oder Speichercache bis zu Problemen mit dem SQL Server reichen. Informationen zum Identifizieren der Grundursache gemeldeter Fehler finden Sie unter Grundursache untersuchen.

Auflösung

  1. Beheben Sie alle zugrunde liegenden hardwarebezogenen Probleme auf dem System, bevor Sie mit der Wiederherstellung einer Sicherung fortfahren oder die Datenbank anderweitig reparieren. Wenden Sie alle Gerätetreiber, Firmware-, BIOS- und Betriebssystemupdates an, die für den E/A-Pfad relevant sind. Arbeiten Sie mit dem Administrator des vollständigen E/A-Pfads (lokaler Computer, Gerätetreiber, Speicher-NICs, SAN, Back-End-Speicher und Cache) und Arbeitsspeicher (RAM) zusammen, um etwaige Probleme zu isolieren und zu beheben. Beispiele hierfür sind das Aktualisieren von Gerätetreibern und die Überprüfung der Konfiguration des gesamten E/A-Pfads. Ausführliche Informationen zum Untersuchen der Ursache finden Sie unter Untersuchen der Grundursache.

  2. Wenn DBCC CHECKDB dauerhafte Konsistenzfehler meldet, besteht die beste Lösung im Wiederherstellen von Daten aus einer bekannten guten Sicherung. Weitere Informationen finden Sie unter Wiederherstellung und Recovery.

  3. Wenden Sie das neueste kumulative SQL Server-Update oder Service Pack an, um sicherzustellen, dass Sie nicht auf bekannte Probleme stoßen. Überprüfen Sie die Dokumentation zu kumulativen Updates oder Service Packs auf bekannte, im Zusammenhang mit Datenbankbeschädigungen (Konsistenzfehlern) stehende Probleme, die behoben wurden, und wenden Sie relevante Korrekturen an. Ein zentraler Ort, an dem Sie nach allen Fixes für eine bestimmte Version suchen können, die in den Detaillierten Fixlisten für SQL Server 2022, 2019, 2017 aufgeführt sind.

  4. Wenn die DBCC CHECKDB Fehler zeitweise auftreten, d. h., sie erscheinen bei einer Ausführung und verschwinden bei der nächsten, haben Sie möglicherweise mit Problemen mit dem Datenträgercache zu tun (entweder mit dem Gerätetreiber oder einem anderen E/A-Pfadproblem). Arbeiten Sie mit den Betreuern des E/A-Pfads zusammen, um Probleme zu isolieren und zu beheben. Beispiele hierfür sind das Aktualisieren von Gerätetreibern, die Überprüfung der Konfiguration des gesamten E/A-Pfads sowie das Aktualisieren von Firmware und BIOS auf den I/O-Pfadgeräten und dem System.

  5. Wenn es nicht möglich ist, eine Sicherung wiederherzustellen, verfügt CHECKDB über eine Funktion zur Fehlerbehebung, die Sie verwenden können. Es gibt zwei Reparaturebenen:

    • REPAIR_REBUILD - führt Reparaturen durch, bei denen kein Datenverlust möglich ist.
    • REPAIR_ALLOW_DATA_LOSS - führt Reparaturen durch, bei denen Datenverlust möglich ist.

    Weitere Informationen finden Sie in der DBCC CHECKDB-Dokumentation.

    Sie müssen vorsichtig vorgehen, wenn Sie die Reparatur mit „Datenverlust zulassen“ auswählen, da Ihre Datenbank möglicherweise in einem logisch inkonsistenten Zustand belassen wird. Die DBCC CHECKDB Ausgabe empfiehlt die zu verwendende Mindestreparaturstufe. Es ist üblich, CHECKDB mit REPAIR_ALLOW_DATA_LOSS mehrfach auszuführen, bis keine weiteren Fehler gemeldet werden. Dies liegt daran, dass beim Beheben einer Reihe von Fehlern möglicherweise andere fehlerhafte Verknüpfungen aufgedeckt werden. Neue Fehler können jedoch auftreten, wenn die zugrunde liegende Ursache nicht behoben wurde. Wenn daher Probleme auf Systemebene wie Hardware oder Dateisystem zu Datenbeschädigungen führen, müssen diese Probleme zuerst behoben werden, bevor ein Backup wiederhergestellt oder eine Reparatur durchgeführt wird. Microsoft-Supporttechniker können nicht bei der physischen Wiederherstellung beschädigter Daten unterstützen, wenn die Reparatur die Konsistenzfehler nicht behebt oder wenn die Datenbanksicherung beschädigt ist.

    Wenn Sie DBCC CHECKDB ausführen, wird eine Empfehlung angezeigt, die die Mindestreparaturoption angibt, die zum Reparieren aller Fehler erforderlich ist. Diese Nachrichten ähneln der folgenden Ausgabe:

    CHECKDB hat 0 Zuordnungsfehler und 15 Konsistenzfehler in der Datenbank "mydb" gefunden.
    REPAIR_ALLOW_DATA_LOSS ist die minimale Reparaturstufe für die von DBCC CHECKDB (mydb) gefundenen Fehler.

    Die Reparaturempfehlung ist die Mindeststufe der Reparatur, um zu versuchen, alle Fehler von CHECKDB zu beheben. Die minimale Reparaturstufe bedeutet nicht, dass diese Reparaturoption alle Fehler behebt. Einige Fehler können einfach nicht behoben werden. Möglicherweise müssen Sie auch den Reparaturvorgang mehrmals ausführen. Nicht alle gemeldeten Fehler erfordern die Verwendung dieser Reparaturstufe, um behoben zu werden. Dies bedeutet, dass nicht alle von CHECKDB mit REPAIR_ALLOW_DATA_LOSS durchgeführten Reparaturen zu Datenverlust führen. Die Reparatur muss ausgeführt werden, um festzustellen, ob die Behebung eines Fehlers zu Datenverlust führt. Eine Technik, die hilft, die Reparaturstufe für jede Tabelle einzugrenzen, besteht darin, DBCC CHECKTABLE für jede Tabelle zu verwenden, die einen Fehler meldet. Dies zeigt die Mindestreparaturstufe für eine bestimmte Tabelle an.

    Warnung

    Sie müssen eine manuelle Datenüberprüfung durchführen, nachdem die Reparatur oder der Datenexport oder der Import CHECKDB abgeschlossen ist. Weitere Informationen finden Sie unter DBCC CHECKDB-Argumente. Die Daten sind nach der Reparatur möglicherweise nicht logisch konsistent. Beispielsweise kann die Reparatur (insbesondere REPAIR_ALLOW_DATA_LOSS Option) ganze Datenseiten entfernen, die inkonsistente Daten enthalten. In solchen Fällen kann es dazu führen, dass eine Tabelle mit einer Fremdschlüsselbeziehung zu einer anderen Tabelle Zeilen enthält, für die es in der übergeordneten Tabelle keine entsprechenden Primärschlüsselzeilen gibt.

  6. Versuchen Sie, das Datenbankschema als Skript zu erstellen. Verwenden Sie das Skript, um eine neue Datenbank zu erstellen und dann ein Tool wie BCP oder SSIS Export/Import-Assistent zu verwenden, um so viele Daten wie möglich aus der beschädigten Datenbank in die neue Datenbank zu exportieren. Das Exportieren von Daten aus einer beschädigten Tabelle schlägt wahrscheinlich fehl. Überspringen Sie in solchen Fällen diese Tabelle, wechseln Sie zur nächsten Tabelle, und speichern Sie, was Sie können.

  7. Überprüfen Sie die folgenden Artikel auf bestimmte Fehler, die von DBCC CHECKDB generiert wurden, und führen Sie die angegebenen Schritte aus (falls vorhanden). Im Folgenden finden Sie einige Beispiele:

Ursache für Datenbankkonsistenzfehler untersuchen

Um die Ursache von Datenbankkonsistenzfehlern zu identifizieren, sollten Sie die folgenden Methoden in Betracht ziehen:

  • Überprüfen Sie das Windows System-Ereignisprotokoll auf Fehler auf Systemebene, Treiber- oder Datenträgerfehler und arbeiten Sie mit Ihrem Hardwarehersteller zusammen, um sie zu beheben.
  • Führen Sie alle Diagnosetools aus, die von Ihren Hardwareherstellern für den Computer und/oder das Datenträgersystem bereitgestellt werden. Die meisten Systeme bieten integrierte BIOS-/UEFI-Diagnosen für Massenspeicher (Festplatten), Speicher, CPUs, Systemboards, RAID-Arrays und mehrere andere Komponenten.
  • Arbeiten Sie mit Ihrem Hardwareanbieter oder Gerätehersteller zusammen, um folgendes sicherzustellen:
  • Erwägen Sie die Verwendung eines Hilfsprogramms wie SQLIOSim auf dem Laufwerk, auf dem sich die Datenbanken befinden, für die Konsistenzfehler gemeldet wurden. SQLIOSim ist ein Tool, das vom SQL Server-Modul unabhängig ist, um die Integrität von E/A für das Datenträgersystem zu testen. SQLIOSim wird mit SQL Server ausgeliefert und erfordert keinen separaten Download. Es befindet sich im Ordner \MSSQL\Binn.
  • Überprüfen Sie die Dokumentation zu kumulativen Updates oder Service Pack auf bekannte Probleme im Zusammenhang mit Datenbankbeschädigungen (Konsistenzfehlern) und wenden Sie relevante Korrekturen an. Ein zentraler Ort, an dem Sie nach allen Fixes für eine bestimmte Version suchen können, siehe die detaillierten Fixlisten für SQL Server 2022, 2019, 2017.
  • Überprüfen Sie auf andere Fehler, die von SQL Server gemeldet werden, z. B. Zugriffsverletzungen oder Assertionen. Vorgänge mit beschädigten Datenbanken führen häufig zu Zugriffsverletzungsausnahmen oder Assert-Fehlern.
  • Stellen Sie sicher, dass Ihre Datenbanken die PAGE_VERIFY CHECKSUM Option verwenden. Wenn Prüfsummenfehler gemeldet werden, ist dies ein Hinweis darauf, dass Konsistenzfehler aufgetreten sind, nachdem SQL Server Seiten auf den Datenträger geschrieben hat. Daher sollte Ihr E/A-Subsystem gründlich überprüft werden. Weitere Informationen zu Prüfsummenfehlern finden Sie unter Problembehandlung für Msg 824 in SQL Server.
  • Suchen Sie im ERRORLOG nach Fehlern mit Meldung 832. Diese Fehler deuten möglicherweise darauf hin, dass Seiten beschädigt werden, während sie sich im Cache befinden, bevor sie auf den Datenträger geschrieben werden. Weitere Informationen finden Sie unter Fehlerbehebung bei Msg 832 in SQL Server.
  • Versuchen Sie auf einem anderen System, eine Datenbanksicherung wiederherzustellen, von der Sie wissen, dass sie "sauber" ist (keine Fehler von CHECKDB), gefolgt von Transaktionsprotokollsicherungen, die den Zeitraum abdecken, in dem der Fehler erzeugt wurde. Wenn Sie dieses Problem reproduzieren können, indem Sie eine „saubere“ Datenbanksicherung und Transaktionsprotokollsicherung wiederherstellen, wenden Sie sich an den technischen Support von Microsoft, um Unterstützung zu erhalten.
  • Datenreinheitsfehler können ein Problem mit der Anwendung sein, die ungültige Daten in SQL Server-Tabellen einfügt oder aktualisiert. Weitere Informationen zur Problembehandlung von Datenreinheitsfehlern finden Sie unter Problembehandlung bei DBCC-Fehler 2570 in SQL Server 2005.
  • Überprüfen Sie die Integrität des Dateisystems mithilfe des Befehls chkdsk. Führen Siechkdsk nicht aus, während SQL Server ausgeführt wird. Es kann vorübergehende Dateifehler melden, wenn SQL Server in die zu überprüfenden Dateien schreibt. Darüber hinaus können Optionen wie /r oder /f Dateibytes an einen anderen Speicherort auf dem Datenträger verschieben, und eine solche Bewegung kann zu Beschädigungen führen, wenn SQL Server auch in diese Dateien schreibt oder liest. Achten Sie daher darauf, SQL Server zu beenden, bevor Sie den chkdsk Befehl ausführen. Üben Sie außerdem Vorsicht mit Reparaturoptionen wie /r und /f. Stellen Sie sicher, dass Sie eine Sicherung Ihrer Datenbanken haben, bevor Sie eine Reparatur ausführen, da diese Optionen die Dateien beschädigen können, wenn von chkdsk Datenträgerfehler gefunden werden.

Weitere Informationen

Ausführliche Informationen zur Syntax von DBCC CHECKDB sowie Informationen oder Optionen zum Ausführen des Befehls finden Sie unter DBCC CHECKDB (Transact-SQL).

Wenn bei Verwendung von CHECKDB Fehler gefunden werden, werden andere Nachrichten, die der folgenden Meldung ähneln, im ERRORLOG für die Zwecke der Fehlerberichterstattung gemeldet:

**Dump thread - spid = 0, EC = 0x00000000855F5EB0
***Stack Dump being sent toFilePath\FileName
* ******************************************************************************
*
* BEGIN STACK DUMP:
*  Date/Timespid 53
*
* DBCC database corruption
*
* Input Buffer 84 bytes -
*             dbcc checkdb(mydb)
*
* *******************************************************************************
*   -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000001E8
External dump process return code 0x20002001.

Die Fehlerinformationen wurden an die Watson-Fehlerberichterstattung übermittelt.

Zu den Dateien, die für die Fehlerberichterstattung verwendet werden, gehören eine SQLDump<nnn>.txt Datei. Diese Datei kann für historische Zwecke nützlich sein, da sie eine Liste der von CHECKDB gefundenen Fehler im XML-Format enthält.

Um herauszufinden, wann DBCC CHECKDB zuletzt ohne erkannte Fehler für eine Datenbank ausgeführt wurde (das letzte bekannte fehlerfreie CHECKDB), überprüfen Sie den SQL Server ERRORLOG. Suchen Sie nach einer Nachricht wie der folgenden für einen Benutzer oder eine Systemdatenbank. Diese Nachricht wird ebenfalls) als Informationsebene-Nachricht im Windows-Anwendungsereignisprotokoll mit EventID = 17573 geschrieben:

Date/Time spid7s CHECKDB für die Datenbank 'master' wurde am Date/Time22:11:11.417 (Ortszeit) ohne Fehler abgeschlossen. Dies ist nur eine Informationsnachricht; Es ist keine Benutzeraktion erforderlich.

  • Last updated on