Exchange Datenbank läuft voll

1. offizieller Beitrag

    Hoi Leutz,


    bin neu hier und komm gleich mit nem Problem.
    Bitte nicht zerpflücken gleich. :)


    Also folgendes System habe ich vorliegen:


    Windows 2003 SP1 mit Exchange Server Enterprise 2003 SP1


    Da nun Richtlinien für den Mailgebrauch nicht gewünscht waren bei uns ist unsere Datenbank mittlerweile so angewachsen das ich nun am Wochenende eine volle Platte hatte.


    Ich in meinem blauäugigen Leichtsinn dachte noch: Ok müssen die Leutz halt mal aufräumen. Aber so einfach wars dann ja nich da die Datenbank ja nix hergeben will.


    Egal gesagt getan es muss nun mittlerweile wieder einiges frei in der Datenbank sein und ich bereite mich seelisch auf eine Offline Defragmentierung vor.


    Nun hab ich ja schon Horror Geschichten über die beiden Tools ESEUTIL und ISINTEG gelesen und bin da ziemlich verunsichert.


    Meine Fragen an euch sind folgende:


    Ich habe vor per Backup Exec die Erste Speichergruppe komplett zu sichern und ausserdem Offline die gesamte Datenbank auf eine USB Platte nochmals zu sichern.


    Langt das oder muss ich unbedingt noch etwas sichern? Ich meine etwas gelesen zu haben von Dateien die nach einem fehlerhaften ESEUTIL nicht mit der alten Sicherung klar kommen.


    Ist ein Run von ISINTEG komplett ungefährlich? Wenn nein, was muss ich beachten? Ich hab schon viel gelesen von "einfach machen" bis "könnte alles zerstören"


    Ich habe vor die Datenbank auf eine USB Festplatte auszulagern durch ESEUTIL. Ist dies gefährlich? Habe dafür extra eine mit externer Stromversorgung gekauft!


    Achja, die Online Defragmentierung sagt, das 1 GB frei in der Datenbank ist, was ich mir nicht vorstellen kann, da meine User etwa 5-10 GB an Mails gelöscht haben. Wird dieser Bereich auch wieder freigestellt?


    Echt sorry das ich mit sowas hier meinen Einstand übe, bin aber wirklich bischel am verzweifeln.

    • Offizieller Beitrag

    Hallo,


    also, wenn Du Exchange 2003 SP2 installierst, hast Du die Möglichkeit die max. DAtenbankgrösse auf 75 GB zu erhöhen
    Das bringt jedoch nur etwas wenn Du genügend freien Speicherplatz auf der Festplatte hast.


    http://www.nobbysweb.de/community/newbb/howto/075.pdf


    wenn der Event 1221 sagt, dass Du 1 GB freien Speicher innerhalb der Datenbank hast, dann würde deine Datenbank nach einen Offline defragmentation also mit eseutil /d um genau das eine GB kleiner werden.


    Wenn deine User allerdings heute 5-10 GB gelöscht haben, dann würde ich bis morgen früh warten, bis die online Maintenance durchgelaufen ist. Dann such nochmals nach dem Event 1221 und überprüfe, wieviel freien Speicherplatz sich dann innerhalb der Datenbank befindet.


    Wegen einem GB eine Offline Defragmentierung durchzuführen, rechtfertigt nicht den Impact wie downtime des Servers etc.


    Aber wenn Du eseutil /d durchführst, dann kannst Du wie schon gesagt, eine Online Sicherung durchführen, und dann den Informationsspeicherdienst beenden.


    Überprüfe dann mit eseutil /mh <Pfad zu den DBs>\Datenbankname ob diese dann im Status Clean Shutdown sind.


    Dann kannst Du diese wegkopieren udn dann defragmentieren.


    Isinteg kannst du auch laufen lassen. Ist halb so wild wie manche schreiben.


    Aber nach einer Offline Defragmentierung bekommt deine DAtenbank einen neue Signatur. Die passt dann nicht mehr mit den Transaktionsprotokollen zusammen. Somit müssen die gelöscht werden.


    Frührer Backups sind dann auch nur bedingt einsetzbar. Daher mein dringender Rat, mach nachdem die Datenbanken wieder online sind, sofort eine Online Sicherung.

    Moin Jürgen,


    jo das mit SP2 hab ich auch schon gelesen. Die Datenbankgrösse zu erhöhen fällt aber ja schon aus zwei Gründen flach:


    1. Die Festplatte ist ja voll. :-/
    2. Der Enterprise Exchange hat ja nicht die 16 GB Beschränkung wie der Standard.


    Also meine User haben gestern ziemlich gelöscht und es blieb leider bei dem 1 GB.


    Ich war am vermuten, das die Online Defragmentierung vielleicht nur die gelöschten Mailboxen zusammenfasst und den Speicherplatz in den vorhanden Mailboxen übersieht.


    Jedenfalls ist das grad meine Wage Hoffnung.


    Achja was ich vergesse hatte zu erwähnen:


    Ich habe mehrere neue Mailboxen angelegt gehabt am Freitag und danach ist die Datenbank vollgelaufen. Habe dann mal überprüft woran das liegen könnte, doch die Mailboxen der neuen Mitarbeiter sind komplett leer noch.


    Holt sich die Datenbank für neue Mailboxen einen bestimmten grossen Bereich und erweitert den dann wenn nötig? Weil bis Freitag hatte ich noch gut und gerne 2-3 GByte auf der Platte frei. Hab auch am Freitag nochmal 1 GByte freischaufeln können, doch auch der ist mittlerweile weg. sehr seltsames Verhalten wie ich finde.

    • Offizieller Beitrag

    ja ok, dann fällt das flach.


    Werden denn bei Dir viele Transaktionsprotokolle geschrieben?


    Du könntest ja auch mal mit dem Tool Exmon überprüfen, ob es da den einen oder anderen User gibt der sehr viel sendet/empfängt.


    http://www.microsoft.com/downl…49c22e-e0c7-4b7c-acef-729
    d48af7bc9&displaylang=en


    Desweiteren kannst Du mal im Anwendungsprotokoll überprüfen, ob die ONline Defragmentierung auch beendet wird.


    Das sind meines Wissens nach die Events 700 und 701

    • Offizieller Beitrag

    Hi,


    Du hast Recht, dass der Enterprise nicht der 16GB grenze unterliegt! Das hat Jürgen sicher überlesen. :)


    Das der Plattenplatz so schnell zuläuft könnte daran liegen, das die Transaktionsprotokolle der Speicherguppe auf dem gleichen Laufwerk liegen. Wenn dem so ist solltest Du diese mit dem ESM auf ein anderes Laufwerk verschieben.


    Eine offline Defragmentierung wrird sicher nicht so viel bringen, da Du mit Sicherheit die Aufbewahrungsfrist gesetzt hast. Daher solltest Du dies auf den Postfachspeicher auf 0 Tage stellen und den Wartungsintervall laufen lassen.


    Nun kannst du mit eseutil die edb offline defragmentieren. Über den Parameter /T kannst Du auch den Pfad für die Tempdatei verschieben, da mindestens 107% der EDB-Grösse als freien Platz benötigst.


    http://www.nobbysweb.de/community/newbb/howto/010.pdf


    Gruss
    Heinz

    Moin Jürgen und Heinz,


    natürlich ich Hammel, die Aufbewarungsfrist.
    Ich hab die sogar letztens mir noch länger angesehen.


    Die Transaktionsprotokolle der Speicherguppe liegen auf einem anderen Laufwerk. Danke aber für den Tipp.


    Die ollen Protokolle haben mich auch schonmal zum Wahnsinn getrieben aber so wenigstens mir aufgezeigt das die Sicherung nicht korrekt lief. ;)


    Also ich hab am Donnerstag Abend eine Downtime beantragt und die ist durch. Da die in den Karfreitag reinläuft sollte dies keine Probleme darstellen, naja ausser für mich da ich diesen Tag dann wohl in der Firma verbringe.


    Das mit Exmon werd ich auch noch ausprobieren. Gute Idee. Danke.


    Die Aufbewahrungsfrist. Manchmal liegt alles so nah das man es nicht sieht. *sploing* ^^


    Danke euch zweien schon mal.


    Aber nochmals die Frage:


    Langt es wenn ich die erste Speichergruppe komplett sichere und die Sicherung 100% durchläuft?
    Ich werd morgen und übermorgen versuchen die Sicherung auf einen Testrechner zu spielen nur um zu testen ob das Backup auch vollständig klappt.

    • Offizieller Beitrag

    Dazu gibt es noch den Event 1206 in den Anwendungsprotokollen. Dort stehen wohl wieviel als gelöscht marktiertn Daten noch nicht komplett gelöscht wurden, da die Deleted Item Retention noch nicht abgelaufen ist.


    Und wie Heinz schon sagte, nur die RSG erstellen und DB mappen, dann kannst Du die gemappte DB restoren um zu testen ob das Backup auch ok ist.

    Also Jungs, absolut klasse die Hinweise.
    Ich werd heut nacht den Exchange nochmals genauer unter die Lupe nehmen.


    Die Events schau ich mir gleich nochmal an.


    Vielen Dank schon mal. Ich halt euch auf dem laufenden.


    Eine Frage hab ich aber noch:


    Ich hab noch nich ganz raus wie die Exchange Datenbank so richtig arbeitet. Die Situation grad ist die, das auf der Datenbank Platte kaum bis garkein Platz ist. Mails laufen aber weiterhin rein und raus. Nun versucht die Datenbank manchmal sich Speicher zu nehmen und gelangt dabei ans Ende des Platzes. Zack fahren die Exchange Dienste runter.


    Ich starte den Server neu, die Platte weisst wieder ein paar MB Platz auf und Exchange geht wieder.


    Meine Vermutung: Die Datenbank nutzt eine Zeitlang die leeren Bereiche die sie hat, doch irgendwo ist ein Mechanismus der Ihr sagt: Jetzt reserviere dir selbst mal etwas mehr Speicherplatz.


    Meine Hoffnung: Durch die nächste Online Defragmentierung wird viel Platz innerhalb der Datenbank frei und sie wird erstmal die Platte in Ruhe lassen.


    Lieg ich da richtig, komplett falsch oder bin ich auf dem Holzweg?


    Hmm, wenn ich das hier alles so lese, ich glaub ich brauch ma wieder nen Lehrgang. ^^

    • Offizieller Beitrag

    Also in deinem Fall ist das Problem nicht der Exchange Server sondern der freie Platz auf den HDDs.


    Die Exchange Datenbanken sind ganz unten in 4 K grosse Seiten aufgeteilt.


    Wenn jetzt mails reinkommen, dann werden diese Seiten belegt und somit als nicht gelöscht markiert.


    Gehst Du jetzt her, und löscht Mails/Postfächer dann werden diese Seiten als gelöscht markiert und haben allerdings wie bei Dir noch die Deleted Item Retention von X TAgen ...


    Erst nach X Tagen werden die Inhalten der betreffenden Seiten als gelöscht markiert.


    Jede Nacht bei der Online defragmentierung werden nun die als gelöscht markierten Seiten deren Inhalt schon gelöscht ist gezählt und mit 4 k multipliziert. Das ergibt dann den freien Speicher innerhalb der DAtenbank.


    Führst Du nun eine offline Defragmentierung mit eseutil /d durch, dann wird Standardmässig in dem Verzeichnis indem Eseutil ausgeführt wird eine temproäre DAtenbank erstellt und von der original Datenbank alle Seiten die als Nicht gelöscht markiert sind rüberkopiert. Wenn das alles durch ist, dann wird die Temp. DB umbenannt in den Namen der ursprünglichen DAtenbank udn dann die ursprüngliche überschrieben, somit wirde die Datenbank dann kleiner.


    Wird keine offline Defrag durchgeführt, wird bei den nächsten Schreiboperationen innerhalb der DB der freies Speicher zuerst beschrieben und die Datenbank dann nicht grösser.