ESEUTIL /d /p

[m2k2 10]

Hallo,

 

nachdem die Datenbank beim Exchange 2000 Server

mit knapp über 16 GB gegen die Wand gefahren wurde,

habe ich mich für die o.g. Parameter entschieden.

 

Alles lief über Nacht.

 

Am nächsten Tag sah ich im MDBDATA Ordner:

 

TEMPDFRG####.edb usw.

 

Hat die Defrag nicht funktioniert oder was hat es

aufsich mit diesen Temp files ?

[m2k2 10]

Muss mich nochmal nachvorne pushen. Entschuldigung.

[weg5st0 10]

Also ich zitiere mal:

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.

MSXFAQ.DE - Der Einsatz von ESEUTIL, ISINTEG und ESEFILE

 

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.

MSXFAQ.DE - Exchange Datenbank defragmentieren

 

 

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...

[GuentherH 61]

Hi.

 

Schau dir einfach einmal deine Exchange Datenbanken jetzt an, sind sie physisch kleiner geworden ?

 

Wenn nein, dann beschreibe uns doch genau wie du vorgegangen bist.

 

LG Günther

[m2k2 10]

Also,

 

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. (?:eek: )

 

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.

[GuentherH 61]

Hi.

 

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.

 

Gute Erklärung zu dem Thema sind auch in der KB Exchange Server 2003-Postfachspeicher wird nicht bereitgestellt, wenn die Postfachspeicher-Datenbank das 16-GB-Limit erreicht zu finden.

 

LG Günther