Exchange Datenbank defragmentieren

Immer wieder werden Horrorgeschichten über Exchange und die darunter liegende Datenbank erzählt. Das beginnt bei Servern, die alle Woche neu gebootet werden über Datenbanken, die regelmäßig zum defragmentieren beendet werden bis zu Servern die alle Monate neu aufgesetzt werden.

Eine regelmäßige Offline-Defragmentierung von Exchange Datenbanken ist meiner Ansicht nach nicht sinnvoll. Eine Überwachung der Onlinedefragmentation ist empfehlenswert.
Siehe dazu auch
"Is offline defragmentation considered regular Exchange maintenance?"
http://blogs.technet.com/b/exchange/archive/2004/07/08/177574.aspx

In Exchange 2010 ist ein Defrag nicht mehr notwendig. Lesen Sie einfach den folgenden Eintrag:
Database Maintenance in Exchange 2010
http://blogs.technet.com/b/exchange/archive/2011/12/14/database-maintenance-in-exchange-2010.aspx

Das Problem

Immer wenn Daten gespeichert, geändert oder gelöscht werden, entstehen Lücken auf dem Speicherplatz. die Verwaltung von Lücken kostet Rechenzeit und macht damit den Server langsam. Aber die Software arbeitet dagegen an, in dem Sie freie Bereiche wieder verwendet oder durch ausgeklügelte Cachetechniken und Indizierungen die Zugriff optimiert.

Trotzdem hat sich gezeigt, dass Speicherstrukturen bei allzu starke Fragmentierung die Leistung des Systems reduzieren und eine Defragmentierung notwendig ist.

Windows NT 4.0 konnte seine Festplatten nur mit Drittprogrammen defragmentieren. Windows 2000 enthält die kleine Version von Diskkeeper. Genauso war Exchange 5.5 nicht gerade der Meister in der Defragmentierung. Exchange 2000 hat diese Funktion schon besser durchgeführt. Aber eine Defragmentierung des laufenden Systems ist natürlich nicht optimal, da dabei nicht alle Strukturen optimiert werden können.

Defragmentieren im "Lager" - Warum Defragmentierung nicht immer sinnvoll ist:

Es ist nicht immer sinnvoll, alle Datenblöcke „am Stück“ aneinander abzulegen. Eine Datei ändert sich ja immer wieder und eine 100% defragmentierte Datei kann am Ende sogar langsamer sein, als eine, die noch etwas „Luft“ hat.

Angenommen sie haben ein Lager für Waren und schieben alle Waren eng an eng zusammen.. Ok, Sie erfreuen sich daran, dass sie nun komplett leere Regale für neue Waren haben und diese auch sehr schnell einlagern können.

Wenn Sie aber nun im bestehenden Lagerbereich Waren entnehmen, dann ist wieder ein „Loch“ da. Würden Sie nun wieder viele andere Artikel verschieben, um das Loch verschwinden zu lassen?

Oder stellen Sie sich vor, Sie bekommen neue Ware und wollen die natürlich zur zum vorhandenen Warengruppe hinstellen. Das geht aber so erst mal nicht, da dort (noch) kein Platz ist. Sie könnten nun im Regal wieder Platz schaffen, in dem Sie alle Artikel daneben wieder weiterschieben. Das macht aber niemand. Also nehmen alle Artikel der Sorte raus und stellen diese auf einen größeren freien Platz. Schade nur, dass die freien Regale an der anderen Seite der Halle sind. Sie haben wieder eine Lücke auf der einen Seite und einen langen Weg zum neuen Platz.

Defragmentieren macht natürlich Sinn, wenn damit zusammengehörige Artikel auch nebeneinander zu stehen. Aber Sie müssen Kosten und Nutzen abwägen.
Das Beispiel der Lagerhalle kann man nun sicher nicht 1:1 auf die IT übertragen, aber ehe Sie defragmentieren, Sollten Sie schauen, ob sich das „lohnt“ oder vielleicht sogar ins Gegenteil umschlägt.
Es soll ja auch Leute geben, die ihren USB-Stick defragmentieren, was aus meiner Sicht völlig am Ziel vorbei geht. Schneller wird es nicht (da Flashspeicher keine Kopfbewegungen und Latenzzeiten durch Festplattenrotation haben) aber altern schneller, wenn die Speicherstellen öfter geändert werden.

Diese kurze Ausführung soll Sie nicht von dem Einsatz einer Fragmentierung abhalten, aber ich habe den Eindruck, das sehr oft einfach "nur mal so" defragmentiert wird.

Was können wir optimieren ?

Beim Einsatz einer Datenbank auf einem Dateisystem gibt es natürlich auch zwei Bereiche, die optimiert werden können:

  • Das Dateisystem
    Die Exchange Datenbanken sind faktisch nur einfache Dateien auf dem Dateisystem. Ist das Dateisystem sehr stark fragmentiert, dann sind auch die Exchange Datenbanken nicht mehr an einem Stück, was sich in langsameren Zugriffen zeigt.
  • Die Datenbank
    Auch innerhalb der Datenbank gibt es eine Struktur mit belegten Datenbankseiten und freien Bereichen. Auch hier ist eine Defragmentierung nützlich, um freie Bereiche zusammen zu fassen.

Genau genommen  muss man daher beide Bereich defragmentieren, wobei einige Defragmentierungstools genau dann nur unvollständig arbeiten, wenn es eine so große Datei wie die EDB-Dateien von Exchange gibt.

Muss ich Exchange defragmentieren ?

Nun ja auch hier gibt es geteilte Meinungen. Natürlich wird ein Server durch die Defragmentierung auf dem Papier schneller, aber wer keinen Benchmark nach der Installation gemacht hat, hat keine Vergleichswerte um diesen Vorteil ermessen zu können. Tatsache ist aber , dass Caching und ausgefeilte Indices in Exchange den Performancegewinn nicht sehr groß ausfallen lassen. Insofern dürfen Sie von der Defragmentierung keine Wunder erwarten.

Interessant ist eine Defragmentierung aus einem anderen Grund:

  • Datenbanktest
    Durch die Offline Defragmentierung wird die komplette Datenbank gelesen und neu geschrieben. Damit werden bisher unerkannte Fehler in der Struktur entdeckt. Dies kann aber auch mit ESEUTIL im Checkmode schneller erreicht werden.
  • Datenbankverkleinerung
    Durch das Neuschreiben werden die Dateien kleiner, da freie Bereiche zusammengefasst und entfernt werden. Nur das lohnt sich nur, wenn genug freie Bereiche vorhanden sind. Aber Exchange bekommt immer weiter Nachrichte, so dass die Datenbank natürlich schnell wieder wächst. Dieses "vergrößern" ist sogar ein sehr aufwändiger Prozess, der Zeit dauert.

Insofern ist eine Defragmentierung der Datenbank aus Platzgründen nur sinnvoll, wenn sehr viele freie Bereiche vorhanden sind, die in naher Zukunft nicht wieder benutzt werden, z.B.: wenn Sie im Rahmen einer Migration viele Postfächer verschoben oder gelöscht haben.

Interessant ist eine Defragmentierung auf dem Dateisystem, auf dem viele temporäre Daten geschrieben werden. Dies ist z.B. das MTADATA Verzeichnis aber auch die MAILROOT-Verzeichnisse des virtuellen SMTP-Servers. Eine schnelle Festplatte und ausreichend Platz sind hier gut für die Performance. Aber auch hier gelten die Werte um so stärker, je voller das Laufwerk ist. Erst wenn die Partition recht voll ist, macht sich der zusätzliche Aufwand bemerkbar.

Am besten ist es daher den Grund für die Defragmentierung zu minimieren. Dazu eignen sich am besten getrennte Partitionen für die entsprechenden Daten. Ein Einmal installierter Server schreibt nur sehr wenig in die Systempartition. Werden nun Pagefile, Exchange Datenbank, Protokolldateien und temporäre Daten auf eigene Festplatten verlagert, dann reduziert sich die Fragmentierung.

Aber wenn Sie dennoch defragmentieren wollen, dann sollten Sie die unterschiede können

Online Defragmentierung

Exchange 5.5. Und Exchange 2000 defragmentieren automatisch ihre Datenbank online, d.h. ohne die Funktionalität des Servers zu stoppen. Natürlich geht etwas Leistung verloren und eine Datensicherung sollte nicht gerade in das gleiche Zeitfenster fallen.

Exchange fasst dabei nebeneinander liegende freie Bereiche zu größeren Blöcken zusammen. Damit werden Sie leichter wieder verwendbar. Den Erfolg oder Misserfolg können Sie im Eventlog ablesen. Die Meldung sieht etwa wie folgt aus:

Lassen Sie sich nicht irritieren über den Text "abgebrochen". Dies ist ein Übersetzungsfehler. Die gleiche Eventlog Meldung auf einem englischen Server lautet auf "abgeschlossen".

In dieser Meldung, welche für jede Datenbank getrennt vorhanden ist, erkennen Sie auch, wie viel Platz in der Datenbank letztlich frei ist. Dieser wird durch neue Nachrichten wieder verwendet. Ist kein Platz mehr frei, dann vergrößert Exchange die Datenbank. Der komplette Lauf hat folgende Event IDs:

Quelle EventID Beschreibung
ESE 700 Information Store (7812) Erste Speichergruppe: Onlinedefragmentierung hat einen vollständigen Durchlauf der Datenbank 'D:\Exchsrvr\mdbdata\pub1.edb' begonnen
ESE 702 Information Store (7812) Erste Speichergruppe: Onlinedefragmentierung setzt den vollständigen Durchlauf der Datenbank 'D:\exchsrvr\mdbdata\priv1.edb' fort.
ESE 703 Information Store (7812) Erste Speichergruppe: Onlinedefragmentierung hat den wieder aufgenommenen Durchlauf der Datenbank 'D:\exchsrvr\mdbdata\priv1.edb' abgeschlossen.
ESE 701 Information Store (7812) Erste Speichergruppe: Onlinedefragmentierung hat einen vollständigen Durchlauf der Datenbank 'D:\Exchsrvr\mdbdata\pub1.edb' abgeschlossen.
MSExchangeIS 1221 Die Datenbank "Erste Speichergruppe\Postfachspeicher (SERVERNAME)" besitzt 8 MB freien Speicherplatz, nachdem die Onlinedefragmentierung abgeschlossen wurde.

Durch die ONLINE Defragmentierung wird die Datenbank aber nicht kleiner !. Es wird nur freier Platz in der Datenbank zusammengefasst, d.h. mehrere zusammenhängende Speicherseiten werden in der Liste der freien Seiten zusammengefasst. Es werden auch keine Daten "verschoben".

Offline Defragmentierung

Wenn Sie wirklich eine Verkleinerung der Datenbank wünschen, dann müssen Sie die Datenbank OFFLINE defragmentieren.

Zur Offline Defragmentierung ist es notwendig, die Exchange Dienste zu stoppen und ausreichend freien Speicherplatz für die temporäre Datenbank zu haben. Dabei wird die Originaldatei geöffnet und eine neue Datendatei geschrieben. Dabei werden alle leeren Seiten entfernt, so dass die Datendatei kleiner wird. Dies lohnt sich eigentlich nur, wenn viele Benutzer und Postfächer gelöscht worden sind. Frühere Versionen von Exchange benötigten dazu zudem sehr viel Festplattenplatz. Exchange 2000 ist sparsamer, aber trotzdem kann dieser Prozess sehr lange dauern und ist nicht ohne Risiko. Eine Datensicherung vorher und nachher ist anzuraten, vor allem weil die DB dabei eine neue Signatur etc. erhält und damit ältere Sicherungen von Protokolldateien (Inkrementelle und differenzielle Sicherungen) nicht mehr brauchbar sind.

  • Q192185 XADM: How to Defragment with the Eseutil utility (Eseutil.exe)

Der Aufruf ist im normalen Betrieb nicht notwendig. Die Datenbank wächst sowieso immer wieder an, solange Nachrichten übertragen werden und Ziel von Exchange ist eine hohe Verfügbarkeit. Dazu zählt auch die Reduzierung von Zeiten durch überflüssige Pflege. Sie können jede Nacht bei der Onlinedefragmentierung im Eventlog nachsehen, wie viel Prozent Festplattenplatz frei ist.

Diskdefragmentierung

Was die meisten bei all den ESEUTIL-Spielereien gerne vergessen, ist das Dateisystem. Die Datenbank kann "intern" noch so schön "am Stück" sein aber das sagt nichts über die Fragmentierung auf der Festplatte aus. Auch hier kann man geteilter Meinung sein, und eine Defragmentierung als überflüssig abtun oder als sinnvoll einstufen. Die Anbieter kommerzieller Lösungen wir Diskkeeper, PerfectDisk etc. sind natürlich für eine Defragmentierung. Wenn Sie aber ihren Exchange Server "sauber" planen und die Datenbanken z.B.: auf dedizierten Partitionen ablegen, dann findet eine Fragmentierung eigentlich nicht statt.

Aus meiner Erfahrung macht eine Fragmentierung aber nur dann Probleme, wenn der Bereich der "freien Blöcke" gering ist (also die Partition sehr voll wird) oder es exzessiv viele Fragmente sind. Auf Desktops und Notebooks kann mit dem Outlook Cached Mode natürlich die OST-Datei nach einiger Zeit ganz schön fragmentiert sein. Hier kann eine Defragmentierung wirklich helfen.

Zusammenfassung

Ein gut dimensionierter Server benötigt in der Regel keine Offline Defragmentierung. Die Defragmentierung bringt aus meiner Erfahrung kaum messbare und noch weniger fühlbare Geschwindigkeitsvorteile. Allerdings sind die Dienste einige Zeit nicht verfügbar, Sie benötigen freien Speicherplatz  und nach dem Start wird die Datenbank aufwändig wieder erweitert.

Zu Zeiten von Exchange 5.0 war eine regelmäßige Defragmentierung noch angeraten, aber mit Exchange 5.5 und Exchange 2000 rate ich guten Gewissens davon ab. Die Geschwindigkeit eines Exchange Servers ist in den meisten Installation nur sehr gering von der Fragmentierung abhängig sondern viel mehr von der Dimensionierung und Anbindung der Speichersubsysteme. (Siehe Exchange Sizing)

Weitere Links