Glorf IT

Bei uns in der Firma kann man Zeitschriften "abonnieren". Die werden von der Firma gekauft und bekommen
eine Liste angehängt wer das Heft alles lesen will. Die Leute bekommen sie der Reihe nach von oben nach unten.
Jeder kann sich dann 2 bis 3 Tage Zeit lassen und gibt es das weiter. Dass nennen wir "Umlauf" und ist eine wirklich tolle Sache.
Privat habe ich nur die ct abonniert, in der Firma bin ich bei etwa 8 Zeitschriften auf dem Umlaufzettel.

Das klappt leider nicht immer, weil ein paar Spezialisten reichen, um das System zu torpedieren…

Die Aussitzer
Einige Kollegen lieben es sich hinter Stapeln von Zeitschriften zu verschanzen. In ihren Augen zeugt es von Wichtigkeit, wenn man einerseits viele Zeitschriften "abonniert", aber zu beschäftigt ist, um sie zu lesen.
Als bei uns die "Clean-Desk-Policy" eingeführt wurde, schien es besser zu werden. Jetzt da die Schreibtische voll sind, entwickeln Einige sehr kreative Möglichkeiten den großen Stapel für andere noch sichtbar zu machen, z.B. die Schranktür offen stehen zu lassen. 😉

Die Infosammler
Andere wiederum möchten die Artikel wirklich lesen, aber kommen nicht dazu. Es bereitet ihnen körperliche Qualen eine Zeitschrift
ungelesen weiterzugeben. Wenn die Zeitschriften dann 3 oder 4 Monate bei ihnen rumlagen, dann kommt der nächste Urlaub. Dann kann der Infosammler einfach "Wiedervorlage am x.x." draufschreiben und die Zeitschrift weitergeben. Denn er bekommt sie ja relativ bald nach dem Urlaub wieder.
Das auch schon vorher zu machen geht nicht, denn es könnte ja gerade in der Zeit sein, dass er ganz unvorhergesehen dazu kommt doch all die Zeitschriften zu lesen.

Die Fledderer
Einige wenige Kollegen lesen die Zeitschriften wirklich intensiv. Sie erleichtern sich und anderen das Lesen indem sie Kernaussagen
durch Unterstreichungen (die auch manchmal verrutschen und dann wie Durchstreichen aussehen) oder Textmarker (die praktischerweise auch auf der Rückseite sichtbar sind) hervorheben.
Manche sind sogar so freundlich, dass sie ihrer Ansicht nach unscharfe oder falsche Aussagen unlesbar machen.

… und dann gibt es da noch Leute wie mich, die sich freuen wenn sie eine Zeitschrift mal als einer der ersten bekommen, ein paar Artikel lesen und sie nach ein paar Tagen einfach weitergeben. Da gerade Urlaubszeit ist bekam ich in den letzten Wochen etliche ganz aktuelle Zeitschriften. Hurra!

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…