Hallo zusammen,
wenn ich das hier so lese möchte ich manchmal in die Tischkante beissen - da treffen ja etliches an Halbwissen und "Tipps" aufeinander, da mag ich denn mal auch meine 50 Cents dazugeben.
<B>Domino und Compact:</B>
Auf den Compact zu verzichten ist keine gute Idee, nicht mal ansatzweise. Der tut schließlich einiges mehr als nur die Dateien kleiner zu machen - und sogar das läßt sich per Switch steuern. Aber dazu später.
<B>Windows und Fragmentierung:</B>
Alle Filesysteme unterliegen diesem "Problem", nur sind die Auswirkungen unterschiedlich stark zu merken.
Wo liegt das Performance-Problem hierbei? Nun, eigentlich ganz simpel in der Tatsache, daß der Schreib/Lesekopf der Platte immer erst neu positioniert werden muß, bevor der nächste Block gelesen werden kann. Stehen die Blöcke "hintereinander" fällt diese Verzögerung weg. Womit wir aber schon die nächste Frage hätten - stehen nach dem Defragmentieren die Blöcke wirklich hintereinander?
<B>Anatomie der Datenspeicherung:</B>
Der Schreib/Lesekopf der Platte (ich nenne ihn jetzt mal kurz nur "Kopf") liest einen Block von der Platte und schreibt ihn in einen Puffer. Da die Daten auf der Platte schneller kommen als der Puffer verarbeiten kann muß die Platte jetzt warten, bis der Puffer wieder zur Verfügung steht. Im Idealfall dauert das z.B. genau eine Plattenumdrehung und der Kopf wäre, bei sequentieller Speicherung, genau an der richtigen Stelle für den nächsten Block. Und der Vorgang wiederholt sich.
Dieser "Idealfall" existiert allerdings heutzutage aus folgenden Gründen nicht mehr wirklich:
- Die Blockgröße der Festplatte und des Betriebssystems müssen dafür identisch sein.
- Die Festplatte liegt heutzutage bei Servern in einem RAID, meist 5 oder 6. Ein RAID hat ebenfalls eine Block-Größe (meist als Stripe bezeichnet).
- das RAID beherbergt oft Daten verschiedener Systeme oder Programme. Die Vorstellung, zum Zeitpunkt X fragt nur genau eines dieser Programme die Daten sequentiell ab ist weltfremd.
- Ein SAN beherbergt u.U. mehrere redundante RAID-Systeme und wird von vielen Servern und Applikationen zeitgleich genutzt. Der Hauptvorteil einer Defragmentierung wird dadurch zunichte gemacht, daß die Köpfe sowieso aufgrund der verschiedenen parallelen Anfragen ständig in Bewegung sind.
- Alle RAID-Versionen (außer 0) schreiben die Daten doppelt, von wo sie später gelesen werden kann man nicht direkt beeinflussen, selbst wenn sie an einer Stelle sequentiell stehen würden werden die Kopien auf andere Platten redundant verteilt.
<B>Erkenntnisse aus obigen Bemerkungen:</B>
In einem modernen Serversystem mit RAID und/oder sogar SAN kann man den physikalischen Speicherort nicht beeinflussen. Vielmehr hat man bereits in Planungsphase auf bestimmte Dinge zu achten, die die Performance später maßgeblich beeinflussen:
- Nicht alle Daten gehören ins SAN (Stichwort OS und Translogs)
- RAID 5 und 6 sind nicht für alle Daten sinnvoll (Stichwort Translogs)
- Trenne OS und Daten
- beachte die verwendeten Blockgrößen und stimme sie ab
- kenne deine Applikation und die benötigten Blockgrößen
- kenne dein OS und dessen Vor- und Nachteile
- Nutze Cache-Mechanismen sinnvoll
- vermeide unnötige Vorgänge durch rechtzeitige DB-Wartung (Stichwort Compact und Updall)
usw ...
Um zum Thema Compact zurückzukommen, das ja vom Verfasser des Ur-Postings gemeinsam mit dem Datenbankspeicher sinngemäß als "Quelle allen Übels" bezeichnet wurde:
Wenn du wirklich davon überzeugt, daß die Fragmentierung dein Problem verursacht, wieso läßt du die Datenbanken dann überhaupt verkleinern? Dann lasse sie doch in der Größe unangetastet und benutze statt dessen den Compact-Schalter -b (kleines(!) b) dieser läßt die Größe unangetastet aber führt trotzdem die Wartung durch, indem z.B. der White-Space zusammengefaßt wird und doppelte Unread- und Ordner-Aktionen reduziert werden. In keinem Fall sollte man das komplett abschalten. Wenn man es täglich (nachts) laufen läßt geht das auch ohne große Performance-Verluste durch.
Wenn du vom "schlechten Windows" sprich NTFS überzeugt bist - nimm DB2 als Backend, ich verspreche dir keine Performance-Verbesserung - aber dein Argument der Fragmentierung würde dann nicht mehr ziehen (wenn die Datenbank auf einem anderen System liegt) Aber ich behaupte, es wird keine signifikante Änderung erkennbar werden.
<B>Tipp:</B>
Um euer Performance-Problem auszuloten sollte man sich auf den beteiligten Systemen mal mit ein paar Hilfsmitteln die I/O etwas genauer anschauen. Ein Windows-Defrag mag ja auf einem Laptop oder PC was bringen, ich vermute euer Problem allerdings eher woanders, selbst wenn ein Defrag nach dem Streichholz-Zieh-Prinzip bei euch temporär Besserung bringt so denke ich nicht, daß es die eigentliche Ursache darstellt.
<i>Früher ... da gab es mal Computersysteme mit einer einzigen rotierenden Magnetscheibe.</i>