{"id":54,"date":"2006-07-18T17:57:27","date_gmt":"2006-07-18T15:57:27","guid":{"rendered":"http:\/\/www.glorf.it\/blog\/2006\/07\/18\/sql-talk\/db-defekte\/ursachen-fur-datenbank-defekte-teil-4\/"},"modified":"2006-07-18T21:26:48","modified_gmt":"2006-07-18T19:26:48","slug":"ursachen-fur-datenbank-defekte-teil-4","status":"publish","type":"post","link":"http:\/\/www.glorf.it\/blog\/2006\/07\/18\/sql-talk\/db-defekte\/ursachen-fur-datenbank-defekte-teil-4","title":{"rendered":"Ursachen für Datenbank-Defekte (Teil 4)"},"content":{"rendered":"

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.<\/p>\n

Ein gutes Beispiel dafür sind eingeschaltete On-Access-Virenscanner<\/strong>. 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.<\/p>\n

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<\/a>" wird das deutlich beschrieben.<\/p>\n

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.<\/p>\n

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.<\/p><\/blockquote>\n

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:<\/p>\n

Software zur Verschlüsselung<\/strong> von Dateien bzw. Verzeichnissen oder eine komplete Festplattenvollverschlüsselung können potentiell zu Datenbank-Defekten führen. Mit dem windows-eigenen EFS<\/abbr> sind mir noch keine Probleme zu Ohren gekommen. Bei anderer Verschlüsselungssoftware konnte ein Kollege von mir mit dem Werkzeug SQLIOStress<\/a> 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<\/a>, ob es unproblematisch ist… \ud83d\ude09<\/p>\n

Update:<\/strong> Gerade fiel mir ein, dass bei Einsatz von EFS nur die MDF und NDFs verschlüsselt werden dürfen. Microsoft empfiehlt die LDF nicht zu verschlüsseln. Ich glaube vor allem aus Performancegründen. Ich kann die Quelle aber gerade nicht finden, lediglich hier<\/a> steht ein winziger Satz dazu. <\/div>\n

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. \ud83d\ude09<\/p>\n

Vorherige Postings zu Ursachen von Datenbank-Defekten:<\/p>\n