Freigeben über

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

  • Artikel

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

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

Problembeschreibung

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..." wird nur angezeigt, wenn DBCC CHECKDB sie online ausgeführt wurde, in der sich die Datenbank nicht im SINGLE_USER Modus befindet. Dies liegt daran, dass für eine Onlinedatenbank DBCC CHECKDBeine 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 ihnen gemeldet wird, sondern 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, referenzielle Systemtabellenintegrität und andere Strukturprüfungen. Wenn eine dieser Prüfungen fehlschlägt (je nach ausgewählten Optionen), werden Fehler gemeldet.

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

Lö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) zusammen, um 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. Weitere Informationen zum Überprüfen der Ursache finden Sie unter "Untersuchen der Stammursache".

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

  3. Wenden Sie das neueste kumulative SQL Server-Update oder Service Pack an, um sicherzustellen, dass bekannte Probleme auftreten. Überprüfen Sie die Dokumentation zu kumulativen Updates oder Service Pack auf bekannte Probleme, die im Zusammenhang mit Datenbankbeschädigungen (Konsistenzfehlern) 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, wenn die Detaillierten Fixlisten für SQL Server 2022, 2019, 2017.

  4. Wenn die DBCC CHECKDB Fehler zeitweise auftreten, liegt dies daran, dass sie bei einer Ausführung angezeigt und beim nächsten ausgeblendet werden, möglicherweise probleme mit dem Datenträgercache (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 -systemen.

  5. Wenn es nicht möglich ist, eine Sicherung wiederherzustellen, CHECKDB gibt es ein Feature zum Reparieren von Fehlern, die Sie verwenden können. Es gibt zwei Reparaturebenen:

    • REPAIR_REBUILD - führt Reparaturen durch, die keine Möglichkeit zum Datenverlust haben.
    • REPAIR_ALLOW_DATA_LOSS - führt Reparaturen durch, die die Möglichkeit haben, Datenverluste zu haben.

    Weitere Informationen finden Sie in der DBCC CHECKDB-Dokumentation.

    Sie müssen vorsichtig vorgehen, wenn Sie die Möglichkeit haben, datenverlusten zuzustimmen, da ihre Datenbank möglicherweise in einem logisch inkonsistenten Zustand belassen wird. Die DBCC CHECKDB Ausgabe empfiehlt die Mindestreparaturstufe. Es ist üblich, dass sie mehrmals ausgeführt CHECKDB REPAIR_ALLOW_DATA_LOSS wird, 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 angezeigt werden, 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 eine Sicherung oder Reparatur wiederhergestellt 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 ausgeführt werden DBCC CHECKDB, wird eine Empfehlung bereitgestellt, um die mindestreparaturoption anzugeben, 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 (mydb) gefundenen DBCC CHECKDB Fehler.

    Die Reparaturempfehlung ist die Mindeststufe der Reparatur, um zu versuchen, alle Fehler zu beheben.CHECKDB 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 Behebung dieser Reparaturstufe. Dies bedeutet, dass nicht alle Reparaturen CHECKDB zu REPAIR_ALLOW_DATA_LOSS Datenverlust führen. Die Reparatur muss ausgeführt werden, um festzustellen, ob die Auflösung eines Fehlers zu Datenverlust führt. Eine Technik, die hilft, die Reparaturstufe für jede Tabelle einzugrenzen, besteht darin, für jede Tabelle zu verwenden DBCC CHECKTABLE , 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 CHECKDB die Reparatur oder der Datenexport oder der Import 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 eine Tabelle mit einer Fremdschlüsselbeziehung zu einer anderen Tabelle mit Zeilen enden, die keine entsprechenden Primärschlüsselzeilen in der übergeordneten Tabelle enthalten.

  6. Versuchen Sie, das Datenbankschema zu skripten. 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 zum nächsten, und speichern Sie, was Sie können.

  7. Lesen Sie die folgenden Artikel, um bestimmte Fehler zu erhalten, die von DBCC CHECKDB ihnen generiert wurden, und führen Sie die angegebenen Schritte aus (falls vorhanden). Im Folgenden finden Sie einige Beispiele hierfür:

Untersuchen der Ursache für Datenbankkonsistenzfehler

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

  • Überprüfen Sie das Windows System-Ereignisprotokoll auf alle Systemebenen-, Treiber- oder Datenträgerfehler, und arbeiten Sie mit Ihrem Hardwarehersteller zusammen, um sie zu beheben.
  • Führen Sie alle Diagnosen aus, die von Ihren Hardwareherstellern für den Computer und/oder das Datenträgersystem bereitgestellt werden.
  • Arbeiten Sie mit Ihrem Hardwareanbieter oder Gerätehersteller zusammen, um folgendes sicherzustellen:
    • Die Hardwaregeräte und die Konfiguration bestätigen die Anforderungen an Microsoft SQL Server Datenbank-Engine Eingabe/Ausgabe.
    • Die Gerätetreiber und andere unterstützende Softwarekomponenten aller Geräte im E/A-Pfad sind auf dem neuesten Stand.
  • 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 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. Sie befindet sich im Ordner \MSSQL\Binn .
  • Überprüfen Sie die Dokumentation zu kumulativen Updates oder Service Pack auf bekannte Probleme, die im Zusammenhang mit Datenbankbeschädigungen (Konsistenzfehlern) 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, wenn 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. Aktivitäten gegen beschädigte Datenbanken führen häufig zu Zugriffsverletzungs ausnahmen oder Bestätigen von 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 nach Meldung 832-Fehlern im ERRORLOG. 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 wurden. Weitere Informationen finden Sie unter Problembehandlung für Msg 832 in SQL Server.
  • Versuchen Sie auf einem anderen System, eine Datenbanksicherung wiederherzustellen, die Sie wissen, dass dies "sauber" ist (keine Fehler von ) gefolgt von CHECKDBTransaktionsprotokollsicherungen, die den Zeitpunkt der Erstellung des Fehlers umfassen. Wenn Sie dieses Problem "neu erstellen" 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 dem Einfügen oder Aktualisieren ungültiger Daten in SQL Server-Tabellen sein. 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 Sie die Ausführung nicht chkdsk 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 können 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 Datenträgerfehler gefunden chkdskwerden.

Weitere Informationen

Ausführliche Informationen zur Syntax und Informationen oder Optionen zum Ausführen des Befehls finden Sie unter DBCC CHECKDB (Transact-SQL).For details on the syntax of DBCC CHECKDB and information or options about how to run the command, see DBCC CHECKDB (Transact-SQL)

Wenn Fehler mithilfe CHECKDBvon Fehlern 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 Fehler enthält, die in einem XML-Format gefunden wurden CHECKDB .

Um herauszufinden, wie lange die letzte Ausführung DBCC CHECKDB ohne Fehler für eine Datenbank (die letzte bekannte Bereinigung CHECKDB) ausgeführt wurde, ü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 als Informationsebene-Nachricht im Windows-Anwendungsereignisprotokoll mit EventID = 17573 geschrieben:

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