Behandeln von Datenbankkonsistenzfehlern, die von DBCC CHECKDB gemeldet werden

  • Artikel

In diesem Artikel wird erläutert, wie Fehler behoben werden, die DBCC CHECKDB vom Befehl gemeldet werden.

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

Symptome

Wenn 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 als Meldung auf Informationsebene mit EventID=8957 in das Windows-Anwendungsereignisprotokoll geschrieben. Auch wenn Fehler gemeldet werden, handelt es sich bei dieser Meldung um eine Meldung auf Informationsebene.

Die Informationen in der Meldung, die mit "interne Datenbank Momentaufnahme..." beginnen. wird nur angezeigt, wenn DBCC CHECKDB online ausgeführt wurde, wobei sich die Datenbank nicht im SINGLE_USER Modus befindet. Dies liegt daran, dass für eine Onlinedatenbank DBCC CHECKDBeine interne Datenbank Momentaufnahme verwendet wird, um einen konsistenten Satz von Zu überprüfenden Daten zu präsentieren.

In diesem Artikel wird nicht erläutert, wie die einzelnen von gemeldeten spezifischen Fehler behandelt DBCC CHECKDB werden, sondern der allgemeine Ansatz, wenn Fehler gemeldet werden. Alle Verweise auf CHECKDB in diesem Artikel gelten auch für DBCC CHECKTABLE und DBCC CHECKFILEGROUP , sofern nicht anders angegeben.

Ursache

Der DBCC CHECKDB Befehl überprüft die physische und logische Konsistenz von Datenbankseiten, Zeilen, Zuordnungsseiten, Indexbeziehungen, referenzieller Integrität der Systemtabelle und anderen Strukturprüfungen. Wenn eine dieser Überprüfungen fehlschlägt (abhängig von den von Ihnen ausgewählten Optionen), werden Fehler gemeldet.

Die Ursache dieser Probleme kann von Dateisystembeschädigungen, zugrunde liegenden Hardwaresystemproblemen, Treiberproblemen, beschädigten Seiten im Arbeitsspeicher oder Speichercache oder Problemen mit der SQL Server reichen. Informationen zum Identifizieren der Grundursache gemeldeter Fehler finden Sie unter Untersuchen der Grundursache.

Lösung

  1. Beheben Sie alle zugrunde liegenden hardwarebezogenen Probleme auf dem System, bevor Sie mit der Wiederherstellung einer Sicherung oder anderweitigen Reparatur der Datenbank fortfahren. 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) zusammen, um Probleme zu isolieren und zu beheben. Beispiele hierfür sind das Aktualisieren von Gerätetreibern und das Überprüfen der Konfiguration des gesamten E/A-Pfads. Weitere Informationen zum Überprüfen der Grundursache finden Sie unter Untersuchen der Grundursache.

  2. Wenn DBCC CHECKDB permanente Konsistenzfehler gemeldet werden, besteht die beste Lösung in der Wiederherstellung von Daten aus einer bekannten fehlerfreien Sicherung. Weitere Informationen finden Sie unter Wiederherstellen und Wiederherstellen.

  3. Wenden Sie die neuesten SQL Server kumulatives Update oder Service Pack an, um sicherzustellen, dass keine bekannten Probleme auftreten. Überprüfen Sie die Dokumentation zum kumulativen Update oder Service Pack auf bekannte Probleme im Zusammenhang mit Datenbankbeschädigungen (Konsistenzfehler), und wenden Sie alle relevanten Korrekturen an. Ein zentraler Ort, an dem Sie nach allen Korrekturen für eine bestimmte Version suchen können, wenn die Detaillierten Korrekturen für SQL Server 2022, 2019, 2017 aufgeführt sind.

  4. Wenn die DBCC CHECKDB Fehler zeitweilig auftreten, d. h. wenn sie bei einer Ausführung angezeigt werden und bei der nächsten ausführung nicht mehr angezeigt werden, treten möglicherweise Probleme mit dem Datenträgercache auf (gerätetreiber oder ein anderes 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, das Überprüfen der Konfiguration des gesamten E/A-Pfads sowie das Aktualisieren von Firmware und BIOS auf den E/A-Pfadgeräten und dem System.

  5. Wenn es nicht möglich ist, aus einer Sicherung wiederherzustellen, CHECKDB verfügt über eine Funktion zum Beheben von Fehlern, die Sie verwenden können. Es gibt zwei Reparaturebenen:

    • REPAIR_REBUILD – führt Reparaturen durch, die keine Möglichkeit eines Datenverlusts haben.
    • REPAIR_ALLOW_DATA_LOSS – führt Reparaturen durch, die die Möglichkeit eines Datenverlusts haben.

    Weitere Informationen finden Sie in der DBCC CHECKDB-Dokumentation.

    Sie müssen vorsichtshalber vorgehen, wenn Sie sich für die Reparatur mit Datenverlust zulassen entscheiden, da die Datenbank möglicherweise einen logisch inkonsistenten Zustand aufweist. Die DBCC CHECKDB Ausgabe gibt eine Empfehlung für die zu verwendende Mindestreparaturstufe aus. Es ist üblich, mehrmals mit REPAIR_ALLOW_DATA_LOSS auszuführenCHECKDB, bis keine weiteren Fehler gemeldet werden. Dies liegt daran, dass, wenn die Reparatur eine Reihe von Fehlern behebt, andere fehlerhafte Verknüpfungen möglicherweise aufgedeckt werden. Es können jedoch neue Fehler angezeigt werden, wenn die zugrunde liegende Ursache nicht behoben wurde. Wenn Daher Probleme auf Systemebene, z. B. Hardware oder Dateisystem, Datenbeschädigungen verursachen, müssen diese Probleme zuerst vor der Wiederherstellung einer Sicherung oder Reparatur behoben werden. Microsoft-Supporttechniker können bei der physischen Wiederherstellung beschädigter Daten nicht helfen, wenn die Reparatur die Konsistenzfehler nicht behebt oder wenn die Datenbanksicherung beschädigt ist.

    Wenn Sie ausführen DBCC CHECKDB, wird eine Empfehlung bereitgestellt, um die mindestens erforderliche Reparaturoption anzugeben, um alle Fehler zu beheben. Diese Meldungen ä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 mindeste Reparaturstufe, um zu versuchen, alle Fehler von CHECKDBzu beheben. Die minimale Reparaturstufe bedeutet nicht, dass diese Reparaturoption alle Fehler behebt. Einige Fehler können einfach nicht behoben werden. Außerdem müssen Sie den Reparaturvorgang möglicherweise mehrmals ausführen. Nicht alle gemeldeten Fehler erfordern die Verwendung dieser Reparaturstufe, um behoben zu werden. Dies bedeutet, dass nicht alle Reparaturen von CHECKDB mit REPAIR_ALLOW_DATA_LOSS Datenverlust führen. Eine Reparatur muss ausgeführt werden, um zu ermitteln, ob die Lösung eines Fehlers zu Datenverlusten führt. Eine Technik, um die Reparaturstufe für jede Tabelle einzugrenzen, besteht darin, für jede Tabelle zu verwenden DBCC CHECKTABLE , die einen Fehler meldet. Dies zeigt die minimale Reparaturstufe für eine bestimmte Tabelle an.

    Warnung

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

  6. Versuchen Sie, ein Skript für das Datenbankschema zu erstellen. Verwenden Sie das Skript, um eine neue Datenbank zu erstellen, und verwenden Sie dann ein Tool wie BCP oder den SSIS-Export/Import-Assistenten , um so viele Daten wie möglich aus der beschädigten Datenbank in die neue Datenbank zu exportieren. Beim Exportieren von Daten aus einer beschädigten Tabelle tritt wahrscheinlich ein Fehler auf. Überspringen Sie in solchen Fällen diese Tabelle, wechseln Sie zur nächsten, und speichern Sie, was Möglich ist.

  7. Lesen Sie die folgenden Artikel auf bestimmte Fehler, die von generiert werden DBCC CHECKDB , und führen Sie die angegebenen Schritte aus (falls vorhanden). Hier sind einige Beispiele:

Untersuchen der Grundursache für Datenbankkonsistenzfehler

Um die Grundursache von Datenbankkonsistenzfehlern zu ermitteln, sollten Sie die folgenden Methoden in Betracht ziehen:

  • Überprüfen Sie das Windows-Systemereignisprotokoll auf Systemebenen-, Treiber- oder Datenträgerfehler, und arbeiten Sie mit Ihrem Hardwarehersteller zusammen, um sie zu beheben.
  • Führen Sie alle Diagnose aus, die von Ihren Hardwareherstellern für den Computer und/oder das Datenträgersystem bereitgestellt werden.
  • Wenden Sie sich an Ihren Hardwareanbieter oder Gerätehersteller, um Folgendes sicherzustellen:
  • Erwägen Sie die Verwendung eines Hilfsprogramms wie SQLIOSim auf dem Laufwerk, auf dem sich die Datenbanken befinden, die die Konsistenzfehler gemeldet haben. SQLIOSim ist ein von der SQL Server Engine unabhängiges Tool zum Testen der Integrität von E/A für das Datenträgersystem. SQLIOSim wird mit SQL Server ausgeliefert und erfordert keinen separaten Download. Sie finden sie im Ordner \MSSQL\Binn .
  • Überprüfen Sie die Dokumentation zum kumulativen Update oder Service Pack auf bekannte Probleme im Zusammenhang mit Datenbankbeschädigungen (Konsistenzfehler), und wenden Sie alle relevanten Korrekturen an. Ein zentraler Ort, an dem Sie nach allen Korrekturen für eine bestimmte Version suchen können, wenn die Detaillierten Korrekturen für SQL Server 2022, 2019, 2017 aufgeführt sind.
  • Überprüfen Sie, ob andere Fehler von SQL Server gemeldet werden, z. B. Zugriffsverletzungen oder Assertionen. Aktivitäten für beschädigte Datenbanken führen häufig zu Zugriffsverstößen 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 die 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 Meldung 832-Fehlern. Diese Fehler können darauf hindeuten, dass Seiten möglicherweise beschädigt sind, während sie sich im Cache befinden, bevor sie auf den Datenträger geschrieben werden. Weitere Informationen finden Sie unter Problembehandlung für Msg 832 in SQL Server.
  • Versuchen Sie auf einem anderen System, eine Datenbanksicherung wiederherzustellen, von der Sie wissen, dass es sich um "sauber" handelt (keine Fehler von CHECKDB), gefolgt von Transaktionsprotokollsicherungen, die sich über den Zeitraum erstrecken, zu dem der Fehler generiert wurde. Wenn Sie dieses Problem "neu erstellen" können, indem Sie eine "sauber" Datenbanksicherung und Transaktionsprotokollsicherung wiederherstellen, wenden Sie sich an den technischen Support von Microsoft, um Unterstützung zu erhalten.
  • Datenreinheitsfehler können ein Problem sein, wenn die Anwendung ungültige Daten in SQL Server Tabellen einfügt oder aktualisiert. Weitere Informationen zur Problembehandlung von Datenreinheitsfehlern finden Sie unter Troubleshooting DBCC Error 2570 in SQL Server 2005.
  • Überprüfen Sie die Integrität des Dateisystems mithilfe des Befehls chkdsk .

Weitere Informationen

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

Wenn Fehler mithilfe CHECKDBvon gefunden werden, werden andere Meldungen ähnlich der folgenden Meldung im ERRORLOG für die 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.

Die dateien, die für die Fehlerberichterstattung verwendet werden, enthalten eine SQLDump<nnn>.txt-Datei . Diese Datei kann für verlaufsbezogene Zwecke nützlich sein, da sie eine Liste der Fehler enthält, die in CHECKDB einem XML-Format gefunden wurden.

Wenn Sie herausfinden möchten, wann das letzte Mal DBCC CHECKDB ohne Fehler ausgeführt wurde, die für eine Datenbank erkannt wurden (die letzte bekannte sauber CHECKDB), überprüfen Sie die SQL Server ERRORLOG für eine Meldung wie die folgende in einer Benutzer- oder Systemdatenbank (diese Nachricht wird als Meldung der Informationsebene im Windows-Anwendungsereignisprotokoll mit EventID = 17573 geschrieben):

Date/Time spid7s CHECKDB for database 'master' finished on Date/Time22:11:11.417 (local time). Dies ist nur eine Informationsmeldung; Es ist keine Benutzeraktion erforderlich.