Problembehandlung bei Datenbank-Konsistenzfehler zurückgegeben von DBCC CHECKB

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 2015748 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Problembeschreibung

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

2010-03-31-22:07:06.34-spid53 DBCC CHECKDB (Mydb) ausgeführt, indem MYDOMAIN\theuser 15 gefunden und repariert Fehler 0. Verstrichene Zeit: 0 Stunden 0 Minuten 0 Sekunden. Interne Datenbanksnapshot wurde Punkt LSN geteilt = d 00000026:0000089: 0001 und erste LSN = 00000026:0000089 c: 0001. Dies ist nur eine Informationsmeldung. Es ist keine Handlung des Benutzers erforderlich.

Diese Meldung zeigt, wie viele Datenbank-Konsistenzfehler gefunden wurden und wie viele repariert wurden (wenn eine Reparatur mit dem Befehl verwendet wurde). Diese Meldung wird auch in das Windows-Anwendungsereignisprotokoll geschrieben, als Informationsebene Nachricht mit Ereignis-ID = 8957 (selbst wenn Fehler gemeldet werden, diese Meldung ist eine Informationsmeldung Ebene).

Die Informationen in der Nachricht, beginnend mit "internal Database snapshot..." wird nur angezeigt, wenn DBCC CHECKDB online und was ist ausgeführt wurde, wenn die Datenbank nicht im SINGLE_USER-Modus ist. Dies ist, da für eine online DBCC CHECKDB ein internen Datenbanksnapshot verwendet wird, an einen konsistenten Satz von Daten zu überprüfen.

In diesem Artikel besprechen nicht Behandlung von jeder Fehler von DBCC CHECKDB jedoch eher die allgemeine Vorgehensweise gemeldet werden, wenn Fehler gemeldet werden. Jede Bezugnahme auf CHECKDB in diesem Artikel gilt auch für DBCC CHECKTABLE und CHECKFILEGROUP, sofern nicht ausdrücklich angegeben.

Ursache

DBCC CHECKDB überprüft die physische und logische Konsistenz der Datenbankseiten, Zeilen, Reservierungsseiten, Index Beziehungen, Dateisystem Tabelle referenzielle Integrität und anderen Struktur überprüft. Wenn eine dieser Überprüfungen fehlschlägt (abhängig von den Optionen, die Sie ausgewählt haben), werden als Teil des Befehls Fehler gemeldet.

Die Ursache dieser Probleme kann variieren von Beschädigung des Dateisystems, zugrunde liegende Systemprobleme Hardware, Treiber gibt, beschädigte Seiten im Arbeitsspeicher oder Probleme mit der SQL Server Engine. Lesen Sie den Abschnitt "Lösung" für Weitere Informationen, wie Sie die Ursache der Fehler finden, die gemeldet werden.

Lösung

Die erste, beste Lösung DBCC CHECKDB meldet Konsistenzfehler ist von einer einwandfreien Sicherungskopie wiederherstellen. Wenn Sie aus einer Sicherung wiederherstellen können, bietet jedoch dann CHECKDB eine Funktion zum Reparieren von Fehlern. Wenn Probleme wie z. B. das Dateisystem oder die Hardware diese Probleme verursachen könnte, wird empfohlen, diese zunächst vor der Wiederherstellung oder Reparatur auszuführen zu korrigieren.

Wenn Sie DBCC CHECKDB eine Empfehlung ausführen werden bereitgestellt, um die Reparaturoption anzugeben, die erforderlich ist, um alle Fehler zu reparieren ist. Diese Meldungen können wie folgt aussehen:

CHECKDB hat 0 Reservierungsfehler und 15 Konsistenzfehler in 'Mydb'-Datenbank gefunden.
REPAIR_ALLOW_DATA_LOSS ist die minimale Reparaturstufe für die DBCC CHECKDB (Mydb gefundenen Fehler

Mindestanforderungen für die Reparatur versucht, alle Fehler von CHECKDB auflösen wird empfohlen reparieren. Dies bedeutet nicht, dass diese Reparaturoption tatsächlich alle Fehler beheben. Nicht alle gemeldeten Fehler können darüber hinaus diese Art der Reparatur zum Beheben des Fehlers benötigen. Dies bedeutet, dass nicht alle Fehler von CHECKDB ausgegeben werden Repair_allow_data_loss empfohlen wird zu Datenverlust führt. Reparatur muss ausgeführt werden, um festzustellen, ob die Behebung eines Fehlers zu Datenverlust führt. Eine Technik, um zur Eingrenzung für jede Tabelle die Repair-Stufe werden ist, verwenden Sie DBCC CHECKTABLE für jede Tabelle eine Fehlermeldung. Welche Mindestanforderungen für die Reparatur für eine gegebene Tabelle zeigt.

Finden Sie die Ursache, warum Konsistenz Datenbankfehler aufgetreten sind, sollten Sie diese Methoden:

  • Überprüfen Sie das Ereignisprotokoll des Windows-Systems für Systemebene, Treiber oder Datenträger Fehlern
  • Überprüfen Sie die Integrität des Dateisystems mit dem Befehl Chkdsk.
  • Diagnose für den Computer bzw. Datenträgersystem von Ihrem Hardware-Hersteller bereitgestellt.
  • Arbeiten Sie mit Ihrem Hardwarehersteller oder Gerätehersteller sicherstellen:
    • Die Hardwaregeräte und die Konfiguration bestätigt den i/o-Anforderungen von SQL Server
    • Die Gerätetreiber und andere unterstützende Software-Komponenten aller Geräte im e/a-Pfad werden aktualisiert.
  • Verwenden Sie ein Dienstprogramm wie SQLIOSim auf demselben Laufwerk wie die Datenbanken, die die Konsistenzfehler gemeldet haben. SQLIOSim ist ein Tool, das unabhängig von der SQL Server Engine So testen Sie die Integrität der i/o für Disk-System. Beachten Sie, dass SQLIOSim nicht Reuiqre separaten Download ist im Lieferumfang von SQL Server 2008.
  • Überprüfen Sie auf Weitere Fehler vom SQL Server z. B. Zugriffsverletzungen gemeldet. Diese Art von Problemen führen möglicherweise zu Datenbankbeschädigungen unbedingt zuerst diese Fehler zu beheben.
  • Stellen Sie sicher, dass Ihre Datenbanken die PAGE_VERIFY CHECKSUM-Option verwenden. Wenn Checksum-Fehler gemeldet werden, sind Indikatoren, die die Konsistenz Fehler aufgetreten sind, nachdem SQL Server geschrieben wurde auf Datenträger Seiten, damit Ihre Festplattensystem gründlich geprüft werden sollen. Finden Sie unter Problembehandlung bei Msg 824 in SQL Server für Weitere Informationen zu Prüfsummenfehlern.
  • Suchen Sie nach Msg 832 Fehler im Fehlerprotokoll. Dies sind die Indikatoren, die Mai-Seiten beschädigt werden, zwar im Cache, bevor Sie auf den Datenträger geschrieben. Weitere Informationen finden Sie unter wie beheben Msg 832 in SQL Server .
  • Versuchen Sie, eine Datenbanksicherung wiederherzustellen, die Sie kennen, "sauber" (keine Fehler von CHECKDB) und Transaktionsprotokollsicherungen, die Sie kennen umfassen die Zeit, wann der Fehler aufgetreten ist. Wenn Sie dieses Problem, indem replay-können"Wiederherstellen einer Datenbanksicherung"sauberen"und einer Transaktion protokolliert, dann wenden Sie sich an Microsoft Product Support Services, um Unterstützung zu erhalten.
  • Datenfehler Reinheit kann ein Problem mit der Anwendung einfügen oder ungültige Daten in SQL Server-Tabellen aktualisieren. Weitere Informationen zur Problembehandlung bei Daten Reinheit Fehler finden Sie im folgenden Artikel: Problembehandlung bei DBCC Fehler 2570 in SQL Server 2005

Weitere Informationen

Informationen zur Syntax der DBCC CHECKDB und Informationsmöglichkeiten dazu, wie Sie den Befehl ausführen finden Sie in des SQL Server-Onlinedokumentation im Themas zum Befehl DBCC CHECKDB.

CHECKDB Fehler gefunden wurden, werden weitere Meldungen wie die folgenden im Fehlerprotokoll für die Zwecke der Fehlerberichterstattung gemeldet:

2010-03-31 22:07:06.34 spid53 mit "dbghelp.dll' Version '4.0.5'
2010-03-31 22:07:06.35 spid53 ** Dump Thread - Spid = 0, EG = 0x00000000855F5EB0
2010-03-31 22:07:06.35 spid53 *** Stack Dump an C:\Program Files\Microsoft SQL Server\MSSQL10 gesendet werden.SQL2008\MSSQL\LOG\SQLDump0012.txt
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
2010-03-31-22:07:06.35-spid53 *
2010-03-31-22:07:06.35-spid53 * STAPELABBILD beginnen:
2010-03-31-22:07:06.35-spid53 * 03/31/10 22:07:06 Spid 53
2010-03-31-22:07:06.35-spid53 *
2010-03-31-22:07:06.35-spid53 * DBCC Datenbankbeschädigung
2010-03-31-22:07:06.35-spid53 *
2010-03-31-22:07:06.35-spid53 * Input Buffer 84-Byte -
2010-03-31-22:07:06.35-spid53 * Dbcc checkdb(mydb)
2010-03-31-22:07:06.35-spid53 *
2010-03-31 22:07:06.35 spid53      * *******************************************************************************
2010-03-31 22:07:06.35 spid53      * -------------------------------------------------------------------------------
2010-03-31-22:07:06.35-spid53 * kurze Stack Dump
2010-03-31-22:07:06.38 spid53 Stapelsignatur für das Speicherabbild ist 0x00000000000001E8
2010-03-31 22:07:07.42 spid53 externe Dump Prozess Code 0x20002001 zurück.
Die Fehlerinformationen an die Watson-Fehlerberichterstattung übermittelt.

Die Dateien für Fehlerberichterstattung enthalten SQLDump < Nnn > .txt-Dateien. Diese Datei kann aus historischen Gründen hilfreich sein, da sie eine Liste der im XML-Format von CHECKDB gefundene Fehler enthält.

Um herauszufinden, wann das letzte Mal DBCC CHECKDB ohne Fehler für eine Datenbank (die letzten bekannten sauber CHECKDB) ausgeführt wurde, überprüfen Sie im SQL Server-Fehlerprotokoll eine Fehlermeldung wie die folgende für Ihre Datenbank oder die Systemdatenbank (bezieht sich diese Meldung als Informationsebene Nachricht in das Windows-Anwendungsereignisprotokoll mit Ereignis-ID = 17573):

2010-04-01-10:13:59.80 wurde spid7s CHECKDB für die Datenbank 'Master' ohne Fehler auf 2010-03-31-22:11:11.417 (lokale Zeit). Dies ist nur eine Informationsmeldung. Es ist keine Handlung des Benutzers erforderlich

Hinweis Dies ist ein Artikel, der im Schnellverfahren direkt von der Microsoft-Supportorganisation erstellt wurde. Die hierin enthaltenen Informationen werden als Reaktion auf neue Probleme wie besehen bereitgestellt. Da dieser Artikel im Schnellverfahren erstellt wurde, kann er Tippfehler enthalten und zu einem späteren Zeitpunkt ohne vorherige Ankündigung überarbeitet werden. Weitere zu berücksichtigende Informationen finden Sie in den Nutzungsbedingungen.

Eigenschaften

Artikel-ID: 2015748 - Geändert am: Mittwoch, 7. Mai 2014 - Version: 1.0
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 R2 Enterprise
  • Microsoft SQL Server 2008 R2 Standard
  • Microsoft SQL Server 2008 R2 Web
  • Microsoft SQL Server 2008 R2 Workgroup
  • Microsoft SQL Server 2012 Developer
  • Microsoft SQL Server 2012 Enterprise
  • Microsoft SQL Server 2012 Express
  • Microsoft SQL Server 2012 Standard
  • Microsoft SQL Server 2012 Web
  • Microsoft SQL Server 2014 Developer
  • Microsoft SQL Server 2014 Enterprise
  • Microsoft SQL Server 2014 Express
  • Microsoft SQL Server 2014 Standard
  • Microsoft SQL Server 2014 Web
Keywords: 
kbmt KB2015748 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell übersetzt und wird dann möglicherweise mithilfe des Community Translation Framework (CTF) von Mitgliedern unserer Microsoft Community nachbearbeitet. Weitere Informationen zu CTF finden Sie unter http://support.microsoft.com/gp/machine-translation-corrections/de.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 2015748
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com