Glorf IT

In einem Kommentar zu einem WebLog-Eintrag in dem Peter beschreibt, wie er mit seinem Fahrrad einen schweren Sturz hatte, schreibt Michael St.Pierre etwas ganz Interessantes. Wenn ich recht bedenke, dann predige ich in einem ähnlichen Bereich auch schon seit Jahren und scheitere: "Mache regelmäßig Backups"

Das psychologische Problem dabei ist halt, dass es Menschen (also nicht nur dir) ganz grundsätzlich schwer fällt, aus seltenen Ereignissen Konsequenzen für das eigene Handeln zu ziehen. Man kennt soetwas wie “gefühlte Wahrscheinlichkeit”, und die ist immer deutlich günstiger (also seltener oder häufiger, je nachdem) für denjenigen, der konkrete Änderungen seines Verhaltens vornehmen sollte. Einen Fahrradhelm braucht man wirklich nur 1-maximal 2 mal im ganzen Leben, dann aber entscheidet es sich, ob du aufstehst, den Staub aus den Kleidern schüttelst und deine Schürfwunden versorgst, oder ob du aufgrund einer Hirnblutung mit bleibenden neurologischen Ausfällen leben wirst müssen (oder eben auch nicht mehr lebst) ;-( .

Quelle: Sand in der Kurve…

Die gefühlte Wahrscheinlichkeit ist einfach so gering, dass man es nicht einsieht ein Backup zu machen: Der Rechner ist doch fast ganz neu! Leute, die dauernd mit denen zu tun haben, die kein Backup haben, aber eines gebraucht hätten, denken da eben anders darüber…

Vielleicht nehme ich jetzt doch meinen Helm auch dann, wenn ich zum Bahnhof fahre… 😉

Heute habe ich mich daran gemacht und ein Beispiel für den "SQL Server Everywhere" gestrickt, dass unter Windows XP läuft. Irgendwie habe ich mich damit ziemlich schwer getan, weil ich keine brauchbare Anleitung fand. Die Hilfe scheint sich nur auf den Einsatz auf "Windows Mobile" (oder wie das Windows CE jetzt heisst…) zu beziehen.

Erst mit dem Artikel Getting started with SQL Server Everywhere – C# Database aus "The Code Project" ging es dann voran. Jetzt bin ich ganz begeistert: wenn man weiss wie es geht, dann ist es ganz einfach… 😉

Update: Als ich gerade versuchte das ZIP von dort zu laden, schien es korrupt zu sein. Wenn es bei jemandem klappt, würde ich mich über eine Info freuen…

In den Kommentaren zu dieser Seite fand ich auch den Link zu diesem ganz guten Überblick-Artikel zur Everwhere-Edition. Diese Infos kann ich gut für meine Schulung gebrauchen.

Update^2: OK, man muss angemeldet sein, sonst wird nur die HTML-Seite (mit Endung ZIP) runtergeladen…

Wir haben an "schlechten" Tagen täglich mit Datenbank-Defekten unseren Kunden zu tun, was sicher auch damit zu tun hat, dass wir diese Reparaturen bis vor kurzem meistens kostenfrei durchführten. Für den Microsoft SQL Server 2000 möchte ich ein paar Tipps geben, die ich immer wieder gerne versuche, wenn sich herausstellen sollte, dass die einfachen Mittel (dbcc checkdb) nicht mehr helfen….

Im ersten Teil geht es um Probleme, wenn die Datenbank nicht angehängt werden kann.

Wie kann das passieren?
Der Kunde meldet sich bei der Hotline und beklagt, dass die Datenbank defekt ist. Dann führen die Jungs und Mädels ein paar Standard-Dinge durch. Manchmal kommen sie zu dem Schluss, dass man vor Ort einfach nichts mehr machen kann und holen die Daten in die Firma. Um sie dann im Hause untersuchen zu können, muss man die Datenbank erst mal an einen SQL-Server anhängen. Wenn das mit Bordmitteln nicht mehr geht, dann ist das ein ganz schlechtes Zeichen. Aber meist kann man da noch etwas machen. Das Anhängen geht meistens dann noch über einen Dummy:

1. Ich lege eine neue leere Datenbank irgendwo an. Die Datenbank muss mit so vielen Dateien angelegt werden, wie das anzuhängende Original. Um es einfacher zu haben, liegen bei mir dann immer alle Dateien im gleichen Verzeichnis.
2. Dann stoppe ich den SQL-Server.
3. Löschen der Dateien der neuen leeren Datenbank.
4. Die originalen Dateien der defekten Datenbank dorthin kopieren.
5. SQL Server starten.
   Weil die Datenbank sich nicht einfach öffnen lässt, wird sie beim Starten als suspekt markiert.
6. Jetzt kann man die Datenbank in den Emergency-Mode setzen.
7. Dann muss man den SQL-Server nochmals stoppen ud starten. Dabei wird für die Datenbank kein Recovery versucht.
8. Und schon kann man die eigentliche Analyse bzw. Reparatur beginnen.

So setzt man die Datenbank beim SQL-Server-2000 in den Bypass- bzw. Emergency-Mode:

exec sp_configure 'allow updates', 1
reconfigure with override
GO
update sysdatabases set status = status | 32768 where name = "myDB"
go
exec sp_configure 'allow updates', 0
reconfigure with override

Quelle: Das habe ich aus den Books-Online. Ich finde aber gerade nicht die Stelle. Bitte nach der Reparatur nicht vergessen den Status zurückzusetzen… 😉

Beim SQL-Server-2005 ist das deutlich einfacher:

alter database myDB set emergency

Demnächst geht es weiter…

Anbei die Links zu der Serien mit den 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
• defekter Hauptspeicher im fünften Teil

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?

Im SQL-Team-Weblog hat MLaden einen Performancevergleich von verschiedenen Datenimport-Methoden aus Dateien veröffentlicht:

SSIS – FastParse ON = 7322 ms
SSIS – FastParse OFF = 8387 ms
Bulk Insert = 10534 ms
OpenRowset = 10687 ms
BCP = 14922 ms

Dabei war alles auf einem Testgerät installiert: Datei, SQL-Server und Client. Ich hatte nicht erwartet, dass OpenRowSet mit Bulk-Insert in der gleichen Liga spielt. Das der SSIS noch so viel schneller ist, hatte ich auch nicht erwartet.

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…

Ausgehend von dem Posting letzte Woche möchte eine Lösung für den Median am SQL Server 2005 vorstellen, die wegen der neuen TSQL-Features um einiges performanter ist, als die "alte" Lösung:

Zum Vergleich hier noch mal die "beste" Lösung am SQL Server 2000:

select cast(
(select max(Quantity)
from ( SELECT TOP 50 percent Quantity
FROM #bla
order by Quantity asc) as d)
+(select min(Quantity)
from ( SELECT TOP 50 percent Quantity
FROM #bla
order by Quantity desc) as d)
as numeric(12,2))/2 as "richtiger Median bei ganzen Zahlen"

Diese Lösung am SQL Server 2005 ist etwa um Faktor 4 schneller. Sie basiert auf dem Ansatz von Itzik Ben-Gan, den ich jetzt entdeckt habe: "Calculating the Median Gets Simpler in SQL Server 2005" by Itzik Ben-Gan. (Ein wenig bin ich stolz, dass er für den 2000er die gleiche Lösung vorschlägt wie ich.. 😉 )

In einer Common-Table-Expression wird die komplette Liste durchnumeriert und gezählt. Auf dem Ergebnis werden dann alle bis auf der bzw. die beiden mittleren Datensätze rausgefiltert (WHERE). Dann muss nur noch der Durchschnitt auf dem Rest berechnet werden:

WITH blaRN AS
(
SELECT Quantity,
ROW_NUMBER() OVER(ORDER BY Quantity) AS RowNum,
(select COUNT(*) from #bla) AS Cnt
FROM #bla
)
SELECT avg(Quantity) as Median
FROM blaRN
WHERE RowNum IN((Cnt + 1) / 2, (Cnt + 2) / 2)

Die nächste Lösung für den SQL 2005 basiert auf der Losung von Jörg Neumann, liefert aber in allen Fällen ein korrektes Ergebnis.

Hier passiert im Prinzip das gleiche wie oben. Allerdings wird hier in einer Derived-Table durchgezählt. In der äußeren Query werden dann alle bis auf den bzw. die beiden mittleren Datensätze gefiltert. Dann muss nur noch deren Durchschnittswert berechnet werden:

SELECT avg(Quantity) as Median
FROM
(
SELECT ROW_NUMBER() OVER
(
ORDER BY Quantity DESC
) AS Rank,
Quantity
FROM #bla
) AS sub
WHERE (SELECT COUNT(*) FROM #bla) / 2 in (rank, rank-1)

Der Zugriffplan der unteren Lösung ist leicht komplizierter, aber das macht bei meinen paar Datensätzen keinen Unterschied aus…

Einige sehr interessante Ansätze stehen übrigens auch bei Dan Sullivan.

Anbei noch der Code, um die Beispieltabelle zu füllen:

if object_id(N'tempdb..#bla') is not null drop table #bla
create table #bla (quantity numeric(12,2))
create clustered index i1 on #bla(quantity)

insert into #bla(quantity) values (1)
insert into #bla(quantity) values (2)
insert into #bla(quantity) values (3)
insert into #bla(quantity) values (4)
insert into #bla(quantity) values (5)
insert into #bla(quantity) values (105)

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…