☰

MSSQL-Fehler: Konsistenzbasierter E/A-Fehler – kann er durch ein MSSQL- oder Betriebssystemproblem verursacht werden?

tag-icon • tag-icon sql-server sql-server-2005
MSSQL-Fehler: Konsistenzbasierter E/A-Fehler – kann er durch ein MSSQL- oder Betriebssystemproblem verursacht werden?

Folgendes habe ich im Windows-Fehlerprotokoll gesehen:

SQL Server hat einen logischen konsistenzbasierten E/A-Fehler erkannt: falsche Prüfsumme (erwartet: 0x19fedd20; tatsächlich: 0x19fed5e3). Er trat beim Lesen der Seite (1:1764) in Datenbank-ID 6 bei Offset 0x00000000dc8000 in Datei „D:\mssql\local_repository_pbdiffimport.mdf“ auf. Weitere Nachrichten im SQL Server-Fehlerprotokoll oder Systemereignisprotokoll können weitere Einzelheiten liefern. Dies ist ein schwerwiegender Fehlerzustand, der die Datenbankintegrität gefährdet und sofort behoben werden muss. Führen Sie eine vollständige Datenbankkonsistenzprüfung durch (DBCC CHECKDB). Dieser Fehler kann viele Ursachen haben. Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation.

Ich rannte

dbcc checkdb

was mir sagte, ich sollte mit der Option REPAIR_ALLOW_DATA_LOSS wiederherstellen, also habe ich schließlich ausgeführt

DBCC CHECKDB (my_db_name, REPAIR_ALLOW_DATA_LOSS) MIT NO_INFOMSGS

Das führte jedoch dazu, dass etwa 2.000 Zeilen verloren gingen. Ich habe ein Backup wiederhergestellt, aber jetzt befürchte ich, dass dies erneut passieren wird, da wir vor etwa 2 Wochen bereits ein Konsistenzproblem in derselben Datenbank hatten, das dann jedoch in einem Index auftrat (neu erstellte Indizes lösten das Problem).

Wir haben die Festplatten untersucht – RAID5 sieht gut aus, keine Fehler und auch keines der Festplattenprüfprogramme hat irgendwelche Hardwareprobleme ergeben.

Kann dies am Betriebssystem (Windows Server 2003) oder an MSSQL (MSSQL Server 2005) liegen?

Antwort1

Die Konsistenz kann durch einen der folgenden Faktoren verursacht werden: Hardware oder Software. Sehen Sie sich die SQL-Protokolle an, um herauszufinden, was das Problem möglicherweise verursacht hat.

Meine Vorschläge:

  • Stellen Sie sicher, dass die Datenbankoption Page_Verify auf CHECKSUM eingestellt ist. Dies überprüft alle Schreibvorgänge, bevor sie erfolgen. Dies ist die Standardeinstellung in SQL Server 2005.
  • Backup täglich oder mehrmals täglich (je nach Bedarf)
  • Richten Sie Wartungspläne ein, um Ihre Datenbank täglich auf Konsistenz zu prüfen.
  • Halten Sie Ihren Windows Server und SQL Server mit Patches und auch mit Drittanbietersoftware auf dem neuesten Stand.
  • Lesen "Top-Tipps für eine effektive Datenbankwartung", da dort die meisten meiner Vorschläge ausführlicher erläutert werden.

Ich kann diesen Artikel wärmstens empfehlen, da er Systemadministratoren helfen soll, die nicht wissen, wie man einen Datenbankserver verwaltet.

Antwort2

In Ihrem Systemereignisprotokoll werden wahrscheinlich Hardwareereignisse gemeldet. Sie sollten diese untersuchen.

Führen Sie SQLIOSIM aus, um die Festplatte für mehr als 24 Stunden zu belasten. Wenn SQLIOSIM einen Fehler meldet, müssen Sie sich zur Untersuchung an Ihren Hardwareanbieter wenden. Es könnte an der Festplatte, am RAID-Array oder an den Treibern liegen. Das Betriebssystem und SQL sind die unwahrscheinlichsten Übeltäter.

SehenSo verwenden Sie das Dienstprogramm SQLIOSim zum Simulieren der SQL Server-Aktivität auf einem Datenträgersubsystem.

Antwort3

Definitiv kein SQL Server-Problem (also, sehr, sehr, sehr unwahrscheinlich). AUCH ist es wahrscheinlich kein Betriebssystemproblem – einfach, weil fehlerhafte Schreibvorgänge viel zu offensichtlich sind, um lange als Fehler bestehen zu bleiben.

Dies deutet ernsthaft darauf hin, dass es an der Hardware liegt. RAM (Sie verwenden ECC?) ist ein möglicher Übeltäter, ebenso wie alle anderen damit verbundenen Probleme (RAID-Controller? Festplatten?)

verwandte Informationen