16 GB Limit

  • Hallo alle zusammen,


    leider ist das eingetreten, was ich eigentlich vermeiden wollte. Das 16 GB-Limit wurde überschritten und ich musste
    auf die temporären 17 GB ausweichen.


    Die Frage ist jetzt: wie lange halten die 17 GB? Bei Exchange 2003 hält es ja nur bis zum nächsten Neustart, wenn ich
    mich nicht irre? Ist das bei 2000 genauso oder bleiben die 17 GB auch nach einem Neustart erhalten?


    Das einfache Veschieben von Postfächern verändert die Grösse der DB ja scheinbar nicht wirklich. Werden denn zunächst die jetzt (nach der Online-Defragmentierung) als frei markierten knapp 6 GB durch weitere Emails gefüllt oder werden die freien Stellen der EDB ignoriert und die Datei einfach weiter vergrössert? Bis jetzt kann ich durch den anfallenden Email keine Veränderung der EDB-Grösse feststellen, so dass man tippen könnte, dass zunächst die freien Seiten der EDB gefüllt werden?!


    2. Frage: Gibt es eine andere Möglichkeit, die Grösse der DB wieder auf unter 16 GB zu schrauben, ohne das eseutil
    einzusetzen? Aufgrund der Warnungen in einschlägigen Webseiten, ist mir da doch ziemlich bange vor ...
    Was für Sicherungen muss ich davor ggf. noch durchführen?


    Ich muss unbedingt sicher gehen, dass wir entweder noch einige Monate mit den 17 GB weiterarbeiten können oder dass wir die DB auf eine
    kleine Grösse runterschrauben können, ohne sie unnötigen Risiken auszusetzen.


    Selten war ich für Hilfe so dankbar wie im Moment! Vielen, vielen Dank schon mal im voraus!!!


    Viele Grüsse, Maze

    • Offizieller Beitrag

    Hallo,


    ist zwar schon einige Zeit her, aber soweit ich weiss musst Du nach jedem Restart den Registry Key neu setzen.


    Aber nun zu guten Nachricht. Exchange verwendet den freien Speicher innerhalb der Datenbank zuerst bevor die Datenbankdatei weiter anwächst.


    Ich empfehle Dir jedoch trotzdem mit eseutil /d die Datenbank offline zu defragmentieren, da Du sonst sehr schwer eine Kontrolle hast wieviel freien Speicher noch innerhalb der DB ist bevor diese anwächst. Und wenn diese das dann macht, kann es zu spät sein.
    Dann steht der Server auf alle Fälle.

  • Vielen Dank an Euch beide,


    das waren genau die Antworten, die ich hören wollte. :)


    MAJO: genauso werde ich es machen


    Jürgen: okay, habe kein Problem damit, den Reg-Key nach dem Neustart nochmal neu zu setzen - hauptsache ist, es funktioniert.


    Ja, ich werde die Offline-Defragmentierung auf jeden Fall zeitnah machen, aber wenn er erstmal auf den freien Speicher zugreift, so habe ich zumindest zunächst keinen ganz so argen Zeitdruck, da 6 GB doch schon ein ganz guter Puffer sind für ein UN unserer Grösse. ;)


    Klasse Forum, danke für die raschen Antworten!

  • Hi Nobby,


    danke für den Hinweis! Da reicht aber ein xcopy auf alle Dateien im MDBDATA-Verzeichnis im Offline-Modus, oder muss ich über ein backup-tool ne online-sicherung fahren lassen?


    Viele Grüsse, Maze

    • Offizieller Beitrag

    Hallo,


    vor dem eseutil /d (offline Defrag) die .edb und .stm wegkopieren oder über z.b. NTBackup sichern (Offline Backup.


    Nachdem alles erfolgreich durchgelaufen ist, dann noch eine OnlineSicherung durchführen.


    Denn wie Nobby schon schrieb, die Datenbank erhält eine neue Datenbanksignatur. Und diese ist in den alten Transaktionsprtokollen nicht identisch.


    Daher das Backup.

  • Hi Jürgen,


    danke für Deine Antwort.


    Okay, ich verstehe, dass ihr damit meint, dass dann bei hochgefahrenen Diensten der Exchange automatisch die logs erneuert (mit der richtigen ID/Signatur) und bei einer Online-Sicherung diese dann gesichert werden, richtig?


    Viele Grüsse, Maze.


    PS: Werde mich wohl erst am WE trauen. ;)


    PPS: Online-Sicherung geht auch mit ntbackup, oder? Wenn ich die richtige Speichergruppe auswähle, sichert er auch die logs und alle anderen notwendig Dateien mit?