{"id":45,"date":"2006-07-13T21:49:44","date_gmt":"2006-07-13T19:49:44","guid":{"rendered":"http:\/\/www.glorf.it\/blog\/2006\/07\/13\/sql-talk\/db-defekte\/ursachen-fur-datenbank-defekte-teil-2\/"},"modified":"2006-07-18T18:05:08","modified_gmt":"2006-07-18T16:05:08","slug":"ursachen-fur-datenbank-defekte-teil-2","status":"publish","type":"post","link":"http:\/\/www.glorf.it\/blog\/2006\/07\/13\/sql-talk\/db-defekte\/ursachen-fur-datenbank-defekte-teil-2","title":{"rendered":"Ursachen für Datenbank-Defekte (Teil 2)"},"content":{"rendered":"

Im ersten Teil<\/a> der Serie über Ursachen für Datenbank-Defekte habe ich über ein paar sehr skurrile Ursachen von defekten Datenbanken berichtet. Heute geht es um ein sehr ernstes Thema: die Festplatten oder genauer das gesammte I\/O-Subsystem.<\/p>\n

Die ungeschlagene Nummer eins sind hierbei ungeeignete Festplatten<\/strong>. Es gibt immer wieder EDV-Händler, die unseren Kunden Server mit billigen EIDE-Festplatten verkaufen. (Unser Klientel hat den Ruf besonders kostenbewusst zu sein, vermutlich ist da etwas dran.) Dabei sind RAID-Systeme mit EIDE-Festplatten offenbar auch nicht viel besser. Weil die Kunden in der Regel zunächst nicht glauben, dass die Probleme durch deren Hardware verursacht werden, haben wir sogar eine Zeitlang mit unserer Software einen Batch installiert, der eine sehr große Datei erzeugte und die dann immer hin und her kopierte. Nach jedem Kopiervorgang wurden die Dateien binär verglichen. Wenn dabei Unterschiede auftreten, dann überzeugt das auch den EDV-Laien.
\nLeider findet man damit nur die völlig schrottigen Systeme, deswegen haben wir es dann wieder gelassen…<\/p>\n

Warum IDE-Festplatten für Serversysteme nicht geeignet sind, beschreibt der TecChannel-Artikel "Gefahr: IDE-Festplatten im Dauereinsatz<\/a>". Aus meiner Sicht gilt das gleiche für Einzelplatzsysteme auf denen der Kunde seine Daten gespeichert hat.<\/p>\n

Knapp dahinter stehen Festplatten mit eingeschaltetem Schreibcache<\/strong>, das gilt auch für Raid-Systeme. Wenn der Schreibcache nicht abgesichert ist (z.B. mit einer Batterie gepuffert oder mit einer USV abgesichert), dann hat bei einem Stromausfall oder beim versehentlichen Drücken des Reset-Schalters (wie um alles in aller Welt kann das passieren?) mit sehr hoher Wahrscheinlichkeit das Transaktionslog einen irreparablen Treffer. Häufig ist auch die MDF betroffen.
\nDas kommt offenbar so oft vor, dass Microsoft sogar einen KB-Artikel dazu geschrieben hat: "INF: SQL Server and Caching Disk Controllers<\/a>".
\nLeider bringt ein eingeschalteter Schreibcache aber auch wirklich spürbare Performance. Deswegen lohnt es sich an dieser Stelle etwas mehr Geld auszugeben und ein Raid-System mit SCSI-Platten (siehe oben) und abgesichertem Schrei-Cache anzuschaffen.<\/p>\n

Diesen Punkt beschreibt Microsoft unter anderem in dem Dokument: "SQL Server 2000 I\/O Basics<\/a>". Ein wirkluich sehr erhellendes Dokument, dass auch noch viele andere Dinge erklärt auf die ich ein ander mal zu sprechen komme.<\/p>\n

Zuerst dachte ich Hybrid-Festplatten, genauer "Hybrid Hard Drives with Non-Volatile Flash" (siehe auch den Vortrag "Hybrid Hard Drives with Non-Volatile Flash and Longhorn<\/a>" von der WinHEC) wären dafür die Lösung, aber gestern las ich in der ct15\/2006<\/a>, dass eine NAND-Speicherzelle nur rund 200.000 Lösch- oder Schreibaktionen aushält. Bei der Menge an Schreiboperationen, die der SQL Server verursacht, könnte das zu einem Problem werden.<\/p>\n

Als weiteres gibt es noch eine ganze Reihe von Probleme, die im Umfeld des I\/O-Subsystems<\/strong> stecken können. Neben einem Fall von defektem Hauptspeicher im RAID-Controller konnten wir früher mehrfach Treiber-Probleme als Ursachen ausmachen. Der Kollege, der damals unsere internen Systeme betreute, erzählte mir dass für die RAID-Controller, die unsere Firma für den interen Einsatz anschafft, bei den Tests immer wieder Bugs in deren internem Microcode festgestellt wurden (keine Ahnung, wie die das testen). Auch hier sollte man deswegen immer die neueste Software vom Hersteller einsetzen…
\nHier noch ein paar weiterführende Hinweise, die Microsoft gut verstreut hat:<\/p>\n