Exchange DB Grösse wird trotz löschen nicht kleiner

  • hi @ll,


    ich habe ein grosses problem!


    die exchange 2003 (standard) datenbank, eines kunden, ist mittlerweile über 100gb gross!


    die postfächer waren alle recht gross (es gab keine beschränlung!) und wir haben richtig aufgeräumt.


    wenn ich mir im systemmanager die einzelnen postfachgrössen anschaue, komme ich grade mall auf 14gb. woher kommt diese grosse differenz????


    umlaufprotokollierung war die ganze zeit aus, was wir aber eingeschaltet haben, als die festplatte komplett voll war.


    die datensicherung läufttäglich und die werte, im systemmanager (postfachspeicher) zum löschen etc. haben wir schon auf ein tag gesetzt. das paradoxe ist, das die datenbank von rund 101gb von einem auf den anderen tag um 5gb angewachsen ist und nun eine grösse von 106gb hat. wie kann das sein?


    sicherlich wir könnten nun eine offline defragmentierung starten, die bei der db grösse doch recht lang dauern wird und in der zeit ist unser exchange down. das ist zum einen ein problem, weil der kunde das system braucht und zum anderen anderen wissen wir ja nicht, wie stark sich die defragmentierung auf die grösse auswirkt. kann mann das irgendwie im vorwege heraus finden??



    für ideen und ratschläge wäre ich euch sehr dankbar.


    viele grüsse


    renè

    • Offizieller Beitrag

    Hallo Renè,


    die DB wird NIE kleiner!


    Es wird lediglich Platz innerhalb der DB geschaffen, durch die Online-Defragmentierung,
    die per default nachts zwischen 03:00 und 05:00 läuft.


    Wenn du die DB(s) real verkleinern möchtest, hilft nur eine Offline-Defragmentierung mittels eseutil.


    Aber solange keine Fehler geloggt werden würde ich das nicht machen.


    Lass doch mal einen expba laufen, der gibt dir schon ein paar Hinweise!


    Umlauf-Protokollierung lässt man nur während eines Umzuges laufen...


    ;)

  • hi nobby,


    die online-defragmentierung läuft ja schon jede nacht. nur bringen tut sie nicht wirklich etwas.


    exchange ist immer fleissig am meckern, das die datenbank grösser als die zulässigen 75gb ist.


    expba habe ich laufen lassen. vom grunsatz her war soweit auch alles okay. habe nur ein paar kleine einstellung verändert.


    die umlauf-protokollierung haben wir aus dem grunde eingeschaltet, weil die festplatte randvoll war und nichts mehr ging. die logs waren von anbeginn der installation vorhanden. eigentlich war ich der meinung, das diese nach einem ordentlichen backup auch gelöscht werden. dies war aber nicht der fall.


    gibt es denn eine möglichkeit zu erfahren, wieviel eine offline defragmentierung, an speicherplatz bringen würden?? meine bevor man sie laufen lässt.


    lg
    renè

    • Offizieller Beitrag

    Hi,


    den Event hatte Sascha schon gepostert:
    1221 in dem Anwendungs-Log.


    Mit was wird denn der Exchange gesichert?


    Wenn das ein Standard ist, der Key auf 75GB gesetzt wurde,
    die DB 100GB gross ist, wird der Store nicht bereitgestellt.


    Bleibt nur Offline-Defrag.
    Allerdings auch nur dann, wenn genug Platz in der DB ist....


    Also erst mal nach dem letzten 1221 Event suchen!


    ;)

  • hi backdoor,


    habe deine nachricht gelesen und war grad dabei auf dem kunden server nach zu schauen.


    der kunde hat aus welchen gründen auch immer, die logs heute morgen gelöscht! so kann ich dir leider keine richtige antwort geben.


    lg
    renè

  • hi nobby,


    den informationsspeicher kann man ohne probleme starten. das macht er auch automatisch, nach einem system neu start.


    Meldung aus dem Anwednungslog:


    Exchange-Informationsspeicher "Erste Speichergruppe\Postfachspeicher (FHL-EXCHANGE)": Die aktuelle physikalische Grösse dieser Datenbank (die EDB-Datei und die STM-Datei) beträgt 105 GB. Bei dieser Datenbank wurde die Grössenbeschränkung von 65 GB überschritten. Der logische freie Speicher in dieser Datenbank wurde jedoch noch nicht überprüft. Deshalb ist es möglich, dass diese Datenbank genügend freien Speicher enthält, um ihre logische Grösse auf einen Wert unterhalb der maximalen Grössenbeschränkung zu reduzieren.


    die grössenbeschränkung mit 65gb hatte ich damals bewusst gesetzt, damit der kunde (der hat eigene it-leute) frühzeitig sehen kann, das er an das limit kommt. deshalb der wert.


    der exchange wird mit backup exec 11d gesichert. bei der datensicherung habe ich die komplette e2k3 db ausgewählt (öffentlich und postfach). auch getrennt habe ich es schon versucht. jedoch werden die logs bei beiden varianten nicht gelöscht. damit wir den informationsspeicher wieder starten können, haben wir die umlaufprotokollierung vorläufig aktiviert.


    hoffe das ich euch mit diesen angaben erstmal weiterhelfen konnte.


    lg
    renè

  • hi backdoor,


    es gibt eine speichergruppe, in der der öffentliche und der postfachspeicher enthalten ist.


    ich hatte ja schon die idee, das ich einen weiteren postfachspeicher anlege, die user darauf umlege bzw. aufteile. dies lässt der exchange jedoch nicht zu, weil ich nur eine standard-version habe. auch den weg über eine weitere speichergruppe habe ich schon versucht.


    was wird denn eigentlich noch alles in der edb an informationen gespeichert, das sie so gross ist?? habe gegenüber dem kunden echte erklärungsnöte, warum die edb so gross geworden ist.


    nachdem was ich bisher alles gelesen habe, wird eine offline defragmentierung allgemein nicht empfohlen und sie soll auch nicht unbedingt den gewünschten erfolg, im in hinblick auf den freiwerdenen speicherplatz, mit sich bringen.


    lg
    renè