Wer evtl. zum ersten Mal einen Exchange Server 2003 mittels des Tools
Eseutil verkleinert (defragmentiert) hat, wird nach dem Defrag mit erstaunen
festgestellt haben, dass die Datenbank dummerweise gar nicht wirklich kleiner
geworden ist und man jetzt weiterhin ein Problem hat.
Man muss dazu folgende Dinge beachten:
Im normalen Betrieb wird man ja immer wieder mal E-mails löschen.
Also auch aus dem Papierkorb von Outlook raus.
Diese Mails sind aber nicht wirklich gelöscht, sondern im Exchange nur
als gelöscht markiert. Werden aber in diesem Fall auch erst mal nicht überschrieben von neuen E-Mails!
Erst nach einer gewissen Zeit löscht der Exchange diese Mails wirklich
und unwiderruflich raus. Wann er das tut und wie lange die Aufbewahrungszeit
ist kann man in den Eigenschaften des Postfachspeichers einsehen.
Man muss dazu auf den Reiter “Grenzwerte” klicken (1).
In der unteren Hälfte sieht man bei (2) die Tage, die der Exchange gelöschte
Objekte in seiner Datenbank aufbewahrt bis er sie wirklich endgültig zum Löschen
freigibt.
Unter (3) kann man noch einen Auswahl treffen die selbst erklärend ist.
Es ist aber so, dass wenn hier ein Haken gesetzt ist, aber nie eine Sicherung stattgefunden
hat, werden die Einstellungen unter (2) außer Kraft gesetzt. Sprich, es werden nie Mails
gelöscht!!! Speziell Kunden die z.B. mit Acronis Ihren Server sichern sollten den Haken
hier rausnehmen. Nur Backupprogramme wie MS NTBackup oder Backupexec klinken sich
direkt in den Exchange rein und sichern die DB in einer speziellen Form, so dass der Exchange
dass auch mitbekommt.
Unter dem Reiter “Datenbank” wird das Wartungsintervall festgesetzt wo der Exchange dann
die gelöschten E-Mails bzw. Objekte wirklich rauslöscht und die frei gewordenen Speicherstellen sinnvoll zusammenführt. Dieser Vorgang findet meistens morgens zw. 0 – 5 Uhr statt.
ACHTUNG: sollte hier z.B. eine größere Sicherung laufen oder man hält den Informationsspeicher z.B. in dieser Zeit an weil man mit einem Backuptool die DB offline wegsichern will dann läuft der Wartungsplan natürlich auch nicht und kann keine Objekte aus der DB entfernen.
Man kann hier dann den Wartungsplan von Hand ändern und diesen auf eine anderen Termin
legen. Leider habe ich bis heute keine Möglichkeit gefunden wie man diese Wartung von Hand
anwerfen kann. Gerade im Notfall, wenn man eine DB defragmentieren möchte wäre das sehr
sinnvoll um Zeit zu sparen. Teilweise konnte ich den Wartungsvorgang etwas beschleunigen
indem ich alle Exchange Dienste einmal neu gestartet hatte. Nach ein paar Minuten Wartezeit läuft dann die sog. Onlinedefragmentierung los. Kann man
im Ereignisprotokoll nachvollziehen bzw. auch an den Aktivitäten im MDBDATA Verzeichnis.
Jetzt zu den eigentlichen Fakten:
Problem:
Datenbank defragmentiert und DB wurde aber nicht verkleinert.
Wie oben beschrieben, am besten mal im Exchange Systemmanger die Löscheinstellungen (2)
auf 1 Tag setzen und den Haken unten raus (3).
Dann sämtliche Exchange Dienste neu starten und abwarten bis der Wartungsvorgang anspringt.
Je nach gelöschter Datenmenge kann es etliche Minuten/Stunden dauern bis alle Objekte wirklich
entfernt wurden. Man sieht die Aktivitäten auch sehr gut im MDBDATA Verzeichnis weil hier
jetzt ständig neue Logfiles erzeugt werden.
Danach kann man noch einmal, wie im Teil 1 beschrieben, mittels Eseutil die DB defragmentieren.
Jetzt sollte die Datenbank aber wirklich kleiner geworden sein.
Falls einem das Defragmentieren zu lang dauert , der muss nicht unbedingt
defragmentieren. Wenn die DB sich in einem 100%igen Zustand befindet
werden die jetzt gelöschten Objekte ja wieder so nach und nach durch neue
Mails, Kontakte etc. gefüllt. Die DB Größe auf Dateiebene wird sich kaum
verändern.
Mir ist das ber bis jetzt immer zu risikoreich gewesen und ich habe trotzdem
die Offlinedefragmentierung angewandt.
Ich hatte schon den Fall gehabt, dass die DB auf 16GB angewachsen ist.
Dann eine Onlinedefrag. gemacht, konnte auch gut 5GB loswerden, aber nach
ein paar Tagen ist der Exchange wieder vollgelaufen obwohl nur ein paar MB
hinzugekommen sind.
Ich vermute, dass es an einer defekten DB lag. Also habe ich dann doch via
Eseutil eine Offlinedefrag. durchgeführt. Die DB ist jetzt wirklich um 5GB geschrumpft und ich kann mir sicher sein, dass es eine Weile dauern wird bis
wieder 16GB erreicht sind.
Außerdem kann man auf Dateiebene relativ schnell die Größe bestimmen
was sonst nicht funktioniert.
