Glorf IT

Neben dem Problem mit dem Safe wandte sich auch mal ein anderer verzweifelter Kunde an uns.

Ihm waren seine Rechner aus dem Geschäft geklaut worden. Meiner Erinnerung nach hatte er noch seine Sicherungsbänder. Aber weil er den SQL-Server-Dienst während der Datei-Sicherung nicht gestoppt hatte, waren alle Datenbank-Dateien im Zugriff und konnten nicht gesichert werden.
In diesem Fall konnten wir nicht mehr helfen… 🙁

PS: Ich halte nichts von dem erhobenen Zeigefinger: So und so muss Dein Backup aussehen. Das interessiert einen meist ja doch erst, wenn man betroffen ist: "Der Pfarrer predigt nur vor den Frommen!"
Aber vielleicht inspiriert dieser tragische Fall ja doch jemanden die ernste Seite des Themas zu erkennen und sein Sicherungskonzept zu kontrollieren?

Inspiriert durch die Serie zu den Ursachen von Datenbank-Defekten mag ich noch ein paar Fallstricke bei der Datensicherung loswerden. Beispielsweise fand ich persönlich den Fall eines Kunden besonders tragisch, der eigentlich alles richtig gemacht hat.

Ein Kunde machte gewissenhaft tägliche nächtliche Sicherungen nach einem Generationenprinzip und legte sie in den Safe.

Das Problem kam mit dem Hochwasser im letzten Jahr: Dem Schlamm fielen die Rechner zum Opfer. Die Bänder leider auch, denn der Safe stand ebenfalls im Keller.

Wenn ich mich richtig erinnere konnte die beauftragte Rettungsfirma noch vergleichsweise viele Dateifragmente "retten". Aber für eine Datenbank-Rettung reichen üblicherweise Fragmente nicht…

Update: Ich halte nichts von dem erhobenen Zeigefinger: "So und so muss Dein Backup aussehen." Das interessiert einen meist ja doch erst, wenn man betroffen ist: "Der Pfarrer predigt nur vor den Frommen!" 😉
Aber vielleicht inspiriert dieser tragische Fall ja doch jemanden die ernste Seite des Themas zu erkennen und sein Sicherungskonzept zu kontrollieren?

Mit diesem Posting schließe ich die Serie über die Ursachen für Datenbank-Defekte (vorerst?) ab.

Die letzte potentiele Ursache ist unter Umständen schwierig festzustellen. Defektes RAM führt gerne zum Fehlermeldungen im Errorlog des SQL-Servers und zum SQL-Dumps. Wenn es aber nur wenige defekte Speicherzellen sind, dann äußert sich das eher sporadisch und wird auch nicht gleich bemerkt.
Früher oder später werden dann auch im Buffer des SQL-Servers Seiten verbogen. Sind nur wenige Bytes betroffen, dann bemerkt der SQL-Server-2000 das nicht. Und sobald diese Seiten in die Datenbank-Dateien zurückgeschrieben werden, hat auch die Datenbank einen "Treffer". In einem Fall hatten wir mal Probleme, weil in der Systemtabelle in der die Tabelleninformationen gespeichert werden, für eine Tabelle "plötzlich" ein falscher Name drin stand: Anstelle von "u_anl_…" stand dort "u_bnl_…". Das kann eigentlich nur sowas gewesen sein.

Am SQL-Server-2005 werden von den Seiten Checksummen gebildet und kontrolliert. Mir ist aber nicht bekannt, wann die Checksummen berechnet und kontrolliert werden. Als positiver Mensch gehe ich davon aus, dass die Checksumme gleich mit der Änderung der Seite berechnet wird. In diesem Fall könnten auch Probleme im Hauptspeicher bemerkt werden.

Der EDV-Partner eines Kunden hat einmal nach einem Datenbank-Defekt so lange alles geprüft bis er feststellte, dass der Hauptspeicher vom Raid-Controller einen Schlag hatte. Ich habe keine Ahnung, wie er das festgestellt hat, aber es hat mich schwer beeindruckt.

Zuletzt noch ein Hinweis von Microsoft, den ich in der Praxis selber noch nicht erlebt habe:
You may notice unpredictable behavior on a multiprocessor computer that is running SQL Server 2000 and has the Physical Addressing Extensions (PAE) specification enabled.

Hast Du weitere Ursachen ausmachen können? Dann hinterlasse bitte einen Kommentar.

Vorherige Postings zu Ursachen von Datenbank-Defekten:

• skurrile Gründe im ersten Teil
• Probleme mit Festplatten im zweiten Teil
• Datenverluste durch eine defekte Datensicherung im dritten Teil
• systemnahe Programme, die den I/O umbiegen, im viertel Teil

In diesem Teil der Serie über die Ursachen von Datenbank-Defekten geht es um Anwendungen, die sich zwischen den SQL-Server und den Festplatten einklinken. Systemnahen Programmen ist es möglich alle Dateizugriffe abzufangen und eigene Routinen dazwischen zu hängen. Von diesen Programmen geht im Zusammenhang mit Datenbanksystemen eine reale, aber sehr schwer nachzuweisende Gefahr aus.

Ein gutes Beispiel dafür sind eingeschaltete On-Access-Virenscanner. Sie überprüfen die Dateien während des Zugriffs auf Schädlingscode. Datenbank-Dateien des SQL-Servers auf Viren zu prüfen ist aber hochgradig unsinnig. Selbst wenn man einen Virus als BLOB (vom Typ Image) in die Datenbank schreiben würde, hätten die Virenscanner so gut wie keine Chance den Inhalt der Datenbank zu prüfen, da der SQL-Server die Inhalte seitenweise in 8KB-Blöcke zerstückelt und dann getrennt voneinander speichert. Sie könnten allenfalls erkennen, wenn die Datei an sich "befallen" wäre. In diesem Fall würde aber der SQL-Server die Datenbank nicht öffnen können und als suspekt markieren.

Daher rate ich dringend die Datenbak-Dateien (Endungen: MDF, LDF und NDF) von der OnAccess-Virenprüfung auszuschließen. Das kostet nicht nur etwas Performance, sondern kann auch zu Datenbank-Defekten führen. In dem bereits neulich erwähnten Artikel von Microsoft "SQL Server 2000 I/O Basics" wird das deutlich beschrieben.

Many implementations of backup software, antivirus programs, and other applications are deployed as I/O system filter drivers. This allows interception of the I/O request and appropriate processing. Inappropriate processing by a filter driver may cause stale reads or lost writes.

Often these types of problems require reproductions and kernel-level debugging efforts to determine the root cause of the problem, which might be something like a stuck IRP. This can be time-consuming and invasive.

Auf die angesprochenen Probleme "stale reads" und "lost writes" wird in dem Artikel sehr genau eingegangen. Sie sind auch verantwortlich für potentielle Probleme mit anderer Software:

Software zur Verschlüsselung von Dateien bzw. Verzeichnissen oder eine komplete Festplattenvollverschlüsselung können potentiell zu Datenbank-Defekten führen. Mit dem windows-eigenen EFS sind mir noch keine Probleme zu Ohren gekommen. Bei anderer Verschlüsselungssoftware konnte ein Kollege von mir mit dem Werkzeug SQLIOStress sehr gut potentielle Probleme nachweisen. Um Ärger zu vermeiden, möchte ich hier keine Namen nennen. (Generell sollte man sowieso nicht alles glauben, was im Internet steht.) Wenn Ihr solche Software einsetzt, dann überprüft einfach selber mit SQLIOStress, ob es unproblematisch ist… 😉

Im Prinzip kommen alle möglichen weiteren Programme als Störenfriede in Frage, die sich in das I/O-System einhängen. Mir fällt bloß gerade kein weiteres Beispiel ein. 😉

Vorherige Postings zu Ursachen von Datenbank-Defekten:

• skurrilen Gründe im ersten Teil
• Probleme mit Festplatten im zweiten Teil
• Datenverluste durch eine defekte Datensicherung im dritten Teil

Demnächst mehr an der gleichen Stelle…

Nach den eher skurrilen Gründen im ersten Teil der Serie über Ursachen für Datenbank-Defekte und den Festplatten im zweiten Teil, geht es heute um Datenverluste durch eine defekte Datensicherung.

Natürlich führt die Datensicherung selber nur sehr selten zu Problemen, aber es kam durchaus schon bei unseren Kunden vor. Als wir noch den Sybase SQL Server einsetzten kam es mehrfach vor, dass wir sehr seltsame Effekte bei Kunden feststellten, die vermutlich auf die Datensicherung zurückzuführen waren. Die meisten davon traten allerdings unter Novell NetWare (Friede seiner Asche) auf.
Unter Windows 2000 hatten wir einmal einen Fall bei dem im Errorlog des "Sybase SQL Anywhere" jede Menge Informationen aus dem Sicherungsprotokoll der Sicherungssoftware standen. Das hat mich damals sehr gewundert, weil der SQL-Anyhwere-Dienst die ganze Zeit lief und die Errorlog-Datei exklusiv geöffnet hatte. Ich hatte bis dahin gedacht, dass sich ein Prozess nicht so einfach Zugang zu anderen Dateien verschaffen kann. Den Trick mit den Hooks habe ich erst später gelernt.
In einem anderen Fall wurden die Datenbanken vor dem nächtlichen Backup geprüft (keine Fehler), dann wurde der Dienst gestoppt, die Dateien gesichert und der Dienst wieder gestartet. Am nächsten Morgen konnte man mit einer der Datenbanken nicht mehr arbeiten. Hier war es so, dass man mit dem Hex-Editor erkennen konnte, dass einfach Schrott in der Datenbank stand. Für mich sahen es wie Fragmente eines Word-Dokumentes aus. Als ob da jemand etwas durcheinander gebracht hätte… Aber wir konnten nie beweisen, dass es die Sicherungssoftware war. Deswegen nenne ich auch keine Namen.

Aber viel öfter machte die Rücksicherung bei Kunden Ärger. Deswegen würde ich empfehlen die Rücksicherung nie in das originale Verzeichnis zu machen oder wenn schon, dann das Original wenigstens vorher umzubenennen. Am besten man macht vor der Rücksicherung eine Datensicherung. 😉

Hintergrund ist, dass wir schon so oft den Fall hatten, dass die zurückgesicherten Dateien fehlerhaft waren.

• Häufig genug hatten die Kunden beim Backup kein "Verify" eingestellt ("Das dauert dann so lange!").
• Der SQL-Server-Dienst wurde nicht gestoppt, die Datenbank-Dateien waren im Zugriff und wurden nicht gesichert. Das Protokoll nicht kontrolliert.
• Es wurden immer die gleichen (kaputten) Bänder genommen.
• Beim Sichern waren die Daten noch OK, während der (sachgemäßen?) Lagerung ruderten die DVDs rüber.

Und warum machen die überhaupt eine Rücksicherung? Na, z.B. weil ein Mitarbeiter versehentlich etwas zu viel gelöscht hat…

Naja, und wenn man dann die kaputte Dateien über die Originale geschrieben werden, dann ist das Jammern groß. Komischweise sind das dann auch die Kunden, die keine weitere Sicherung haben… Vielleicht mache ich mal eine Serie zum Thema Datensicherung. Aber das Lesen ja doch bloß die, die schon eine Sicherung machen: der Pfarrer predigt immer nur vor den Frommen!

Demnächst geht es weiter …

Die Serie in der ich berichten welche Ursachen erfahrungsgemäß hinter Datenbank-Defekten stecken, hat mich darauf gebracht vielleicht auch ein paar Werkzeuge oder Vorgehensweisen zu beschrieben. Immerhin ist es manchmal nicht ganz einfach den SQL Server 2000 überhaupt dazu zu bringen eine korrupte Datenbank zu akzeptieren.

Wenn uns Kunden eine defekte Datenbank schicken, dann können wir relativ häufig doch noch eine ganze Menge an Daten aus den Dateien rausholen, selbst wenn der SQL Server sich weigert die Dateien auch nur als Datenbank-Dateien zu erkennen.
Leider bietet MS dazu keine Unterstützung, eine echte Lücke in die eine estländische Firma gesprungen ist.
Mit dem Werkzeug Recovery for SQL Server haben wir schon aus so mancher Kunden-Datenbank wieder etwas rausholen können. Natürlich fehlen dann die Daten aus den defekten Seiten und die Daten sind nicht mehr in sich konsistent. Sprich: Es erfordert noch eine gründliche Portion Nacharbeit, um die Daten wieder in einen halbwegs sauberen Stand zu bringen.

Nun könnte man sich auf den Standpunkt stellen: "Keine Datensicherung – selbst schuld." Wenn man bedenkt, dass die meisten unserer Kunden bei einem Totalverlust der Daten vor dem wirtschaftlichen Ruin stehen, dann versteht man warum wir das tun…. 🙂

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…

Wenn ich im Kopf so die Liste der Dinge durchgehe, die wir schon als Ursachen für Datenbank-Defekte ausmachen konnten, dann gibt es so viele potentielle Ursachen, dass ich wohl eine Reihe daraus machen muss. Irgendwie drängt es mich mit den Hauptursachen anzufangen, aber die kennt Ihr ja bestimmt schon. Deswegen fange ich mit den verrückten Sachen an.

Wetter
Das Wetter habe ich ja schon genannt… 😉

Zipper
Als ich 1993 in meiner Firma anfing, hatten wir gerade eine Serie von Datenbank-Problemen. Wie sich zeigte arbeitete der von uns damals (noch unter OS/2 eingesetzte) PKZIP nicht korrekt. Es betraf komischerweise fast ausschließich Datenbank-Devices. Der Test war zum Glück einfach: Datei zippen, entzippen und binär mit dem Original vergleichen. Die Trefferquote war so hoch, das wir sogar eine neue Version bekamen.
Ich meine mich zu erinnern, dass wir vor gar nicht allzulanger Zeit ähnliche Probleme mit dem Entpacken von ZIPs hatten, die größer als eine bestimmte Grenze waren (war es 2 GBytes oder 4 GBytes?). Das betraf die letzte FreeWare-Version des PowerArchivers. Dann musste die kostenpflichtige angescaft werden. Allerdings traf uns das im Zusammenhang mit VMWare-Images.

Mails
Kollegen kommen immer wieder auf die Idee mir Datenbank-Dateien per Mail zu schicken. Ende der 90er kam es da häufiger vor, dass die Datenbank defekt in meinem Outlook ankam, obwohl die Datei beim Absender OK war. Komischerweise machen das einige Kollegen immer noch, aber dabei ist schon länger keine DB mehr rübergerudert.

CD/DVD-Brennprogramme
Immer wieder senden Kunden Ihre Daten zu uns ein, damit die Kollegen in den Fachabteilungen bestimmte Probleme oder Effekte nachvollziehen können. Dabei kommen unregelmäßig nur schrottige Datenbanken bei uns an. Neben den ganz normalen CRC-Fehlern (hat Kunde nicht bemerkt, weil beim Brennen kein Verify durchgeführt wurde) kommen auch ganz leere Dateien bei uns an. Sie haben die richtige Größe, bestehen von vorne bis hinten aber aus Hex00.
Immer wieder schaffen es Kunden die Datenbank-Dateien zu brennen ohne den SQL-Server-Dienst zu beenden. Bei bisher ungeklärten Umständen stehen dann "leere" Dateien auf der DVD/CD. Fast alle Betroffenen hatten Nero im Einsatz, aber ich konnte es noch nicht reproduzieren.
Daher schaue ich mir die Datenbank-Dateien immer als erstes mal im Hex-Editor an. Das geht mit dem Programm XVI32 ganz prima. Es arbeitet auch mit sehr großen Dateien noch gut.

Nur mal als Randnotiz: Wir hatten auch mal einen Kunden, der eine Datenbank gebrannt hat, dabei den SQL Server nicht stoppte und dessen Datenbank danach so richtig im Eimer war. Er behauptet sie sei vorher völlig in Ordnung gewesen. Das konnte mein Kollege natürlich nicht kontrollieren, wir wissen nur, dass sie hinterher so kaputt war, dass sie sich nicht mehr reparieren ließ.

WordPad
Ein Kunde hatte mal Netz-Probleme und konte sich mit der Anwendung nicht zum Datenbank-Server verbinden. Weil er nicht auf den Kopf gefallen war, hat er erst mal in der Datenbank nachgeschaut und die Sybase-SQL-Anywhere-Datebank mit dem Notepad aufgemacht. Natürlich sah er nur Nonsense und komische Zeichen. Daraufhin rief er an und beschwerte sich. Es stellte sich heraus, dass die Datenbank wirklich defekt war. Aber nur, weil die Datei für den Notepad zu groß war und deswegen im WordPad geöffnet wurde. Als er das Programm schloss wurde er gefragt, ob er speichern will. Er schaute sich den Dialog nicht groß an, sondern drückte nur auf die Leertaste. Beim Speichern wurde die Datei um ein paar WordPad-Stuerzeichen ergänzt, z.B. ein schöner langer Datei-Header, ein paar Hex00 wurden entfernt und Sonderzeichen ersetzt.
Im Ergebnis war die Datenbank nur noch Schrott.
Habe ich schon erwähnt, dass der Anwendersupport die Kunden nur zu uns durchgestellt, wenn es keine Datensicherung gibt und wir die letzte Hoffnung sind? Das war eine bittere Pille für den Mann…

Bald kommt noch mehr zum gleichen Thema.

Wir haben festgestellt, dass das Wetter eindeutig Einfluss auf die Häufigkeit von Datenbank-Defekten hat. Bei jeder der "Hitzewellen" der letzten Wochen bekamen wir von Kunden täglich eine oder manchmal zwei defekte Datenbanken eingeschickt. In den gemäßigten Phasen mit normalen Temperaturen bekommen wir pro Woche eine oder mal auch gar keine. Am Montag bekamen wir zum Beispiel vier (wenn man das auf Sa/So/Mo rechnet sind es 4/3tel DBs pro Tag).

An den heißen Tagen ist in der Regel klar ein Versagen der Festplatten die Ursache, an den anderen ist die Ursache normalerweise schwer festzustellen. Wir haben punktuell schon ein paar Ursachen rausgefunden, die ich irgendwann ja mal posten kann. Aber die Ursachenanalyse aus der Ferne ist immer schwierig und auch ein wenig Glücksache.

Ich habe den Verdacht, dass bei etliche Kunden der Server in einem kleinen nicht-klimatisierten und deswegen überhitzen Raum steht. Am besten noch unter dem Dach, so wie bei meinem ersten Arbeitgeber. Da war es im Serverraum schier nicht auszuhalten. Und wenn dann auch noch von draußen Hitze kommt, dann rudern Festplatten eben schneller rüber. Ich meine in einer der CTs vom Anfang des Jahres hätte auch ein Artikel potentielle Ursachen für Festplatten-Defekte thematisiert und dort stand auch etwas über überhitzen. Leider finde ich den Artikel nicht mehr. 🙁