Datenbankgrößen
Ein großes Problem bei Exchange stellt die Datenbankgröße dar. Microsoft gibt sich da etwas schwammig, was die Empfehlungen betrifft. Meiner Erfahrung nach kann ich sagen, dass Datenbanken bis max. 200 GB noch OK und zu handlen sind.
Wenn wir nun eine Corporate DB haben, auf der sich alle Postfächer eines Unternehmens befinden und eine Öffentliche Ordner DB, am besten noch auf einem Server. Beide bis 50 GB groß, dann brauchen Sie hier nicht weiterzulesen und sollten die Finger von „Verkleinerungsmassnahmen“ lassen.
Wenn wir aber z.B. von einer Enterprise Umgebung mit vier Mailstore Servern reden, auf denen mehrere DBs liegen und diese auch in Bereiche von 200 GB und mehr kommen, kann sich eine Verkleinerung anbieten.
Am empfehlenswertesten ist natürlich, bei einer großen DB alle Postfächer auf eine neue DB zu verschieben, die „alte“ danach löschen und neu anzulegen. Damit ist die DB Datei leer und kann neu gefüllt werden.
Offline Defrag
Es gibt natürlich auch noch die Möglichkeit der Offline Defragmentierung.
Bei Exchange Versionen vor 2003 habe ich auch lieber die Finger davon gelassen, weil das Offline Defrag damals mehr Offline als Defrag war. Es ist häufig vorgekommen, dass DBs nach dieser Maintenance nicht mehr online kamen…
Meine Erfahrungen ab Exchange 2007 sind da eher positiv. Gerade bei Unternehmen, bei denen im Postfachbereich eine relativ hohe Fluktuation herrscht, kann sich diese Vorgehen rechnen.
Wie wird das am besten gemacht?
Nehmen wir mal an, ich habe eine DB Datei, die 150 GB groß ist (von alleine wird sie nie kleiner). Liegt Diese edb Datei auf einer LUN mit 160 GB, sollte der Admin aktiv werden. Die große Frage ist aber, was kann ich eigentlich durch das Offline Defrag erreichen. Im Anwendungseventlog wird bei der nächtlichen Online Defragmentierung ein Eintrag erstellt, der mir den Wert des freien Bereiches einer DB angibt:
Bei dieser DB kann durch ein Offline Defrag also ein Platz von ca. 47 GB eingespart werden. Microsoft gibt an, dass die endgültige Größe der neuen edb Datei sich folgendermaßen errechnet:
Alte DB – Wert aus dem 1221 Event * 110 % = neue DB
Das wäre in unserem Fall 150 GB – 47,020 GB *110 % = 113,278 GB
Allerdings werden Sie feststellen, dass das nur ein ungefährer Wert ist.
Vorgehensweise
Sie sollten natürlich für diesen Vorgang (je nach Rechnerleistung, IO, usw.) einige Stunden einplanen. Genau lässt sich das leider nie voraussagen. Sie sollten aber für die 113 GB ca. 3-6 Stunden rechnen. Also sind wir bei einer nächtlichen Aktion. Des Weiteren benötigen Sie entsprechenden Speicherplatz für die neue DB und am sinnvollsten auch noch für eine offline Kopie der produktiven DB.
Als erstes nehmen sie die DB offline. Es bleibt Ihn frei, dies über die Management Konsole oder die Shell zu machen. Ich arbeite lieber über die Shell. Da werden auch noch mehr Optionen angeboten und für die Defragmentierung brauche ich die Shell ohnehin.
Dismount-Database –identity „Server\Storage Group\Mailstore”
Ist die DB dismounted, erstellen sie sinnvollerweise eine Offline Kopie, bevor Sie der produktiven DB ans Eingemachte gehen.
Danach können Sie mit dem Befehl:
Eseutil /d Databasepath\database.edb
Damit wird eine Offline Defragmentierung durchgeführt und eine neue Defragmentierte DB im aktuellen Verzeichnis angelegt.
Nach einiger Geduld und einigen Stunden Verarbeitung erhalten sie die neue DB, die Sie dann wieder mounten können.
Mount-Database –identity „Server\Storage Group\Mailstore”
Sollte es Ihnen nicht gelingen, die DB zu mounten, haben Sie ja nun immer noch die Offline Sicherungskopie der DB, die sich im Ursprungszustand befindet und auf jeden Fall noch zu mounten sein sollte. Ich kann aber guten Gewissens sagen, dass ich dies bei Exchange 2007 bisher noch nicht erlebt habe.
Ich empfehle Ihnen aber dieses Vorgehen zu erst auf einem entsprechenden Testsystem auszuführen, bevor Sie das auf einem Produktivsystem machen.