ESEUTIL arbeitet auf einer recht tiefen Ebene (seitenorientiert) der Datenbank und ist ein letztes Mittel, wenn alle andere versagen.
Ich verzichte hier auf eine Beschreibung und verweise explizit auf die Dokumentation von Exchange und rate niemanden dieses Programm ohne triftigen Grund aufzurufen. Lassen sie die Finger von ESEUTIL, wenn ihr Exchange funktioniert. Dann bleibt es auch am Leben. Bei einigen Aktionen braucht ESEUTIL nicht nur viel Hauptspeicher, sondern auch sehr viel Platz auf der Festplatte. Die CPU-Last ist ebenso sehr hoch, d.h. auf Servern die nicht "nur" Exchange machen, kann es sinnvoll sein, den Aufruf in die Abendstunden zu verlegen. Die Laufzeiten können je nach Größe der Datenbank mehrere Stunden betragen.
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.
Hast du wenigstens die Ausgabe des eseutil protokolliert oder mal ins eventlog geschaut.
Eseutil lagert in diese tempdb aus.
Dazu muss natürlich genug Platz sein...
die Datenbanken: priv1.edb (ca. 15 GB) und priv1.stm Streaming (ca. 1,5 GB)
Exchange konnte den Postfachspeicher nicht mehr bereitstellen. Platz wurde 110 % geschafft und der RegKey zur Temporärenvergrößerung wurde nicht eingetragen.
Informationsspeicherdienst beendet und MDBDATA Ordner weggesichert auf USB LW. Im gleichen Ordner ESEUTIL /d /p gestartet.
Das Ganze ist dann in die Nacht rein gelaufen. Am nächsten Tag konnte der Postfachspeicher ca. 2 Min. angehängt werden und wurde dann wieder autom. abgehängt. In diesem Zeitfenster habe ich E-Mail löschen können und der Postfachspeicher hat gehalten. (? )
Nach einem Blick in den MDBDATA Ordner sah ich diese Temp-Files (tempdfrg2276.edb, tempdfrg2276.stm (glaub ich, kanns nicht mehr so rekapitulieren). Diese waren ca. 700 MB und irgendwas mit 200.
Das hat mich stutzig gemacht ! Da ich dachte diese Temps werden angelegt und wieder drübergeschoben ?
Der Postfachspeicher hat den ganzen Tag gehalten. Ich habe ca. 2,5 GB E-Mails gelöscht, die POP3 (Grabbing) E-Mail-Zufuhr gesperrt bis Anfang nächster Woche und hoffe nun auf die Onlinedefrag im Wartungszeitfenster.
Eine Offline Defragmentierung bringt erst dann Sinn, wenn in der Datenbank zuerst Platz frei wird, erst dann kann die Offline Defragmentierung die Datenbank wirklich physisch kleiner machen.
Da es dabei immer wieder zu Missverständnisses kommt, und dabei unnötige Fehler begangen werden, möchte ich die Vorgehensweise kurz beschreiben:
- zuerst freien Plattenplatz überprüfen (es muss zumindest die gleiche der höhere freie Plattenkapazität vorhanden sein, wie die priv1.edb und priv1.stm groß ist)
- Aufbewahrungsrichtlinie für gelöschte Objekte auf 0 Tage setzen
- Onlinedefragmentierung durchführen. Diese wird per default zwischen 1:00 und 5:00 durchgeführt. Sie kann aber durch Anpassung des Zeitschemas zur sofortigen Ausführung erzwungen werden
- abwarten, bis die Onlinedefragmentierung erfolgt ist, und freien Platz in der Datenbank überprüfen (Ereignis-ID 700)
- erst wenn obiger Punkt erfolgreich durchgeführt wurde, und Platz in der Datenbank freigegeben wurde, macht die Offlinedefragmentierung Sinn und die Datenbanken werden tatsächlich physisch kleiner
Wenn sich die DB nicht mehr bereitstellen lassen (16 GB Grenze), sind natürlich vorher die notwendigen Schritte zu unternehmen.
Kleiner Tipp dazu: bevor man die Datenbank wieder bereitstellt, auf jeden Fall vorher die Warteschlangen überprüfen und gegebenenfalls anhalten. Es macht wenig Sinn die Datenbanken bereit zustellen, wenn in den Warteschlangen einige GB auf die Zustellung warten.
)
