Glorf IT

Im ersten Teil 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.

Die ungeschlagene Nummer eins sind hierbei ungeeignete Festplatten. 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.
Leider findet man damit nur die völlig schrottigen Systeme, deswegen haben wir es dann wieder gelassen…

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

Knapp dahinter stehen Festplatten mit eingeschaltetem Schreibcache, 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.
Das kommt offenbar so oft vor, dass Microsoft sogar einen KB-Artikel dazu geschrieben hat: "INF: SQL Server and Caching Disk Controllers".
Leider 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.

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

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" von der WinHEC) wären dafür die Lösung, aber gestern las ich in der ct15/2006, 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.

Als weiteres gibt es noch eine ganze Reihe von Probleme, die im Umfeld des I/O-Subsystems 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…
Hier noch ein paar weiterführende Hinweise, die Microsoft gut verstreut hat:

• PRB: Additional SQL Server Diagnostics Added to Detect Unreported I/O Problems
• FIX: Additional diagnostics have been added to SQL Server 2000 to detect unreported read operation failures
• PRB: Error message 823 may indicate hardware problems or system problems

Und zuletzt einer der wichtigsten Hinweise: Microsoft bietet zum Test des I/O-Substems ein wunderbares Werkzeug an, dass die Zugriffe des SQL Servers simuliert und dann einen Statusbericht abgibt: SQLIOStress.exe.
Damit kann man ziemlich akurat die meisten aller I/O-Probleme nachweisen.

Demnächst mehr an dieser Stelle…

Es passiert ja zum Glück selten, aber ab und an erleben wir, dass der SQL Server sich bei Kunden aus dem Tritt bringen lässt und sich einfach verabschiedet.
Dann gibt es zwei Dinge zu tun: erstens den SQL-Server-Dienst schnellstens neu starten und zweitens die Ursache finden.

Da ein Admin normalerweise auch bloß 9 von 24 Stunden an 5 von 7 Tagen im Büro ist, der Chef aber auch mal spät abends oder am Wochenende drin ist, sind die Chancen groß, dass es dann passiert wenn der Admin gerade sonstwo ist. Hier hilft ein ganz nettes Feature des Dienstemanagers: Er kann den Dienst sofort wieder starten oder erst nach 1 oder 2 oder 3 … Minuten:

Wenn es wieder passiert, dann kann man sich auch lieber eine Mail schicken lassen oder ein anderes Programm aufrufen. Das finde ich echt nützich.

Vor vier Jahren hat es mir mein Chef schon mal geliehen, aber da war das Thema für mich noch nicht so aktuell. Gelesen habe ich es deswegen erst jetzt:
Fish! Ein ungewöhnliches Motivationsbuch von Lundin, Paul und Christensen. Es ist recht kurz und unterhaltsam. Es erzählt eine Geschichte und versucht dabei ein paar Grundprinzipien der Motivation rüber zu bringen. Man könnte die locker auf zwei Seiten zusammenstellen. Aber dann würde man wahrscheinlich nicht so darüber nachdenken und sich dabei noch amüsieren…

Hier geht es darum, wie man es schaffen kann ein leistungsfähiges Team aufzubauen, deren Mitglieder gut zusammenarbeiten und gute Arbeit leisten. Die wichtigsten Dinge sind dabei die Mitarbeiter dazu zu bringen die Arbeit gut zu finden, dabei viel Spaß zu machen/haben, für andere da zu sein und aufmerksam zu sein.
Interessant finde ich, dass hier ganz allgemeine dinge in den Vordergrund gestellt werden. Und eben nicht die Dinge wie Bezahlung, Freiheit des Einzelnen und Verantwortung. Die gehören für mich schon auch dazu, aber aus eigener Erfahrung trägt tatsächlich die eigene Einstellung maßgeblich dazu bei, ob ich einen guten Tag habe oder nicht. Wenn ich dann auch noch Gelegenheiten schaffe an denen ich lachen oder Quatsch machen kann, dann kann es schon gar nicht mehr so dick kommen…

Außerdem: es ist angenehm zu lesen, dünn und billig.

Bei "flow|state" fand ich kürzlich einen sehr guten, kurzen Artikel (schon vom letzten Jahr) über Oberflächendialoge: "Avoiding unnecessary questions in command UI".

Ich finde er bringt es einfach gut rüber: viele Nachfragen können durch einen anderen Workflow vermieden werden.