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.
