Exchange 2000: Massenspam füllt EDB und diese legt die Partition lahm

[Sexsi 10]

• 
• 
• 

Hallo!

 

Der Admin eines Exchange 2000 Server Standard (nix Enterprise) hat seine Exchange-Datenbank auf eine separate 10GB-Partition gelegt. In den vergangenen Tagen ist auf einem Postfach so viel Spam reingedröhnt, dass die Datenbank die Partition randvoll gemacht hat. Sonst liegt angeblich nichts auf der Partition. Er kann auf keinerlei Postfächer mehr zugreifen, der Informationspeicherdienst läuft normal.

 

Das sagte mir der Admin heute Mittag am Telefon, genauer weiß ich es auch noch nicht und ich habe diesen Exchange-Server dort noch nie an den Fingern gehabt.

 

Morgen früh soll ich hinfahren und den Fehler beheben. Auf "meinen" Exchange-Servern würde ich jetzt das von mir vorher angelegte Verzeichnis (mit irgendwelchen Installations-Images, die viele viele MB auf der Partition belegen) löschen, das nur den Zweck erfüllt, in genau diesem Notfall gelöscht zu werden, um Platz zu schaffen. So was hat der aber nicht.

 

eseutil.exe fällt leider aus, für eine Defragmentierung mit DB-Verkleinerung bei einer randvollen Partition nicht möglich ist und bei Auslagerung der temporären DB übers Netz die ganze Prozedur angeblich ewig dauern soll.

 

Ich werde wohl eine weitere SCSI-Platte einbauen, eine neue große Partition anlegen, die Datenbank rüberkopieren, die alte 10GB-Partition löschen und der neuen Partition den Laufwerksbuchstaben der alten geben. Der Rest ist einfach.

 

Mir ist jetzt aber noch eingefallen, dass ich vorübergehend auf der Partition mit der Datenbank die NTFS-Komprimierung aktivieren könnte. Hat damit schon mal jemand Erfahrung gemacht? Ja ja, Datenbank soll man nicht FS-basiert komprimieren, es ist ja auch nur zur Fehlerbehebung gedacht.

 

Andy

[Velius 10]

Hallo Sexsi

 

Files that are managed by extensible storage engine (ESENT or ESE) are not designed to be stored on a compressed drive. The extensible storage engine depends on sector independence for log-based recovery, and compression of files invalidates sector independence. Compression should not be turned on for volumes hosting ESE databases, or any database that uses write-ahead logging.

 

http://support.microsoft.com/default.aspx?scid=kb;en-us;327772

 

Nicht wirklich empfehlenswert!!

 

Schönen Gruss

Velius

[Sexsi 10]

Es war auch nicht nötig. Die Partition war zwar voll, aber man konnte noch dies und das löschen. Es lagen nicht nur die Datenbanken drauf, sondern auch recht viel löschbares Zeugs. Dann wurden die Postfächer von Müll befreit und ich habe noch eine Offline-Komprimierung gemacht. Jetzt ist wieder Platz, sowohl auf der Partition als auch im Store.

 

Ich habe mir den Server mal genauer angeschaut und bin davon überzeugt, dass die Fehler auf die Kompetenz des Admins zurückzuführen sind ...

 

Andy

[Velius 10]

Und glückwunsch, dass du das auch so wieder hinbekommen hast. :)

[phoenixcp 10]

Hauptsache du hast vorgesorgt, das das nicht so schnell wieder passiert. :)

 

Aber den Weg mit der andren Platte muss ich mir merken, der so is simpel und gleichzeitig genial, das ich da noch nicht drauf gekommen bin. Ich kenn auch nur die Chose mit den "sinnlosen Images" die man im Bedarfsfall löschen kann und dann Platz zum aufräumen hat.

[Sexsi 10]

Original geschrieben von phoenixcp

Hauptsache du hast vorgesorgt, das das nicht so schnell wieder passiert. :)

 

Nicht wirklich. Es wurden zwar Quotas festgelegt, aber das eigentliche Problem waren gar nicht die Benutzer, sondern der Admin. Der hat mich mit falschen Hinweisen stundenlang beschäftigt, denn die eigentliche Ursache war ein Fehler seinerseits, den er mit seinen falschen Hinweisen verdecken wollte. Erst alles kaputt machen und dann dumm stellen und so tun als wüsste man von nichts.

 

Aber den Weg mit der andren Platte muss ich mir merken, der so is simpel und gleichzeitig genial, das ich da noch nicht drauf gekommen bin. Ich kenn auch nur die Chose mit den "sinnlosen Images" die man im Bedarfsfall löschen kann und dann Platz zum aufräumen hat.

 

Wichtig ist, dass der Store bei der Standard-Version nie die 16-GB-Marke schaffen darf, sonst hat man ein ernsthaftes Problem mit einem nicht mehr starten wollenden Informationsspeicher.

 

Andy

[phoenixcp 10]

So, und just for Info weil nice to know:

Gibt es von MS irgendeinen Guide, was man überhaupt noch machen kann, falls der Store mal die 16GB erreicht hat?

 

Hab zwar mit Exchange noch nicht viel am Hut, aber was nicht ist kann noch werden und wird es definitv auch, wenn ich mir so anschaue, was man demnächst nach meiner Übernahme alles von mir erwartet.

 

Mfg

Carsten

[Norek 10]

Hi phoenixcp,

 

hier ein Artikel zu deiner Frage.

 

http://www.msexchangefaq.de/notfall/16gb.htm

[phoenixcp 10]

Dangö

 

*In privater Knowldegebase ableg*