Datenbank zu gross genau wie die Verzweiflung

    So hab ein ähnlich es Problem Postfächer sind etwa 35 GB gross
    bekomm die nachrichten:


    Ereignistyp: Informationen
    Ereignisquelle: MSExchangeIS Mailbox Store
    Ereigniskategorie: Allgemein
    Ereigniskennung: 1216
    Datum: 16.06.2008
    Zeit: 08:26:16
    Benutzer: Nicht zutreffend
    Computer: EP-SBS
    Beschreibung:
    Die Grösse des Exchange-Informationsspeichers "Erste Speichergruppe\Postfachspeicher (*)" wurde auf 50 GB beschränkt. Die aktuelle physikalische Grösse dieser Datenbank (die EDB-Datei und die STM-Datei) beträgt 49 GB. Wenn die physikalische Grösse dieser Datenbank abzüglich dem logischen freien Speicher die Beschränkung von 50 überschreitet, wird die Bereitstellung der Datenbank regelmässig aufgehoben.


    Ereignistyp: Informationen
    Ereignisquelle: MSExchangeIS Public Store
    Ereigniskategorie: Allgemein
    Ereigniskennung: 1216
    Datum: 16.06.2008
    Zeit: 08:26:16
    Benutzer: Nicht zutreffend
    Computer: EP-SBS
    Beschreibung:
    Die Grösse des Exchange-Informationsspeichers "Erste Speichergruppe\Informationsspeicher für Öffentliche Ordner (EP-SBS)" wurde auf 18 GB beschränkt. Die aktuelle physikalische Grösse dieser Datenbank (die EDB-Datei und die STM-Datei) beträgt <1 GB. Wenn die physikalische Grösse dieser Datenbank abzüglich dem logischen freien Speicher die Beschränkung von 18 überschreitet, wird die Bereitstellung der Datenbank regelmässig aufgehoben.


    Habe aber am 12 erst ca. 8 GB durch Archivierungen frei gemacht und auch das Delete über das Wochenende auf 0 gestz gehabt:
    Ereignistyp: Informationen
    Ereignisquelle: MSExchangeIS Mailbox Store
    Ereigniskategorie: Allgemein
    Ereigniskennung: 1221
    Datum: 12.06.2008
    Zeit: 02:57:01
    Benutzer: Nicht zutreffend
    Computer: EP-SBS
    Beschreibung:
    Die Datenbank "Erste Speichergruppe\Postfachspeicher (EP-SBS)" besitzt 8193 MB freien Speicherplatz, nachdem die Onlinedefragmentierung abgeschlossen wurde.


    das STM file is 17,1 GB die edb is 32,5 GB.


    was hilft mir ?


    offline defrag ???



    Hab jetzt schon ein 70GB Limit per Registry eingeführt, sollt doch auch was nützen :)

    • Offizieller Beitrag

    danuselli:
    der Key hilft pro DB, muss also für die ÖO extra gesetzt werden.
    http://www.nobbysweb.de/community/newbb/howto/075.pdf


    Und zieht erst mit einem Neustart des Dienstes!!


    Amerz
    Der Notfall-Key hilft hier nicht, da der Server SP2 hat und somit bis 75GB kann, wenn der Reg-Key korrekt gesetzt wurde.


    ;)

    Weis das keiner eine Antwort zu meinem vorhereigen Post?


    (((
    1. Ist bekannt warum das kopieren der priv1.edb so lang dauert?
    Normal sollte so eine Kopie relativ fix gehen auch wenn sie so gross ist. (Intel Xeon 4Kerne mit 1,6Ghz und 2Gig RAM) Liegt es vielleicht daran das die Datei auf der Festplatte stark fragmentiert ist?


    2. Worauf muss ich bei Folgendem achten:
    eseutil /d /p [XXXXX]exchsrvr\mdbdata\priv1.edb /t"[YYYYYY]\priv1.edb"
    danach
    eseutil /d /p [XXXXX]exchsrvr\mdbdata\pub1.edb /t"[YYYYYY]\pub1.edb"
    Spiele mit den Gedanken den neuen Speicherort für den öffentlichen Ordner und die Postfächer vorerst auf das [YYYYYYY] Verzeichnis zu legen.
    Worauf muss ich achten und/oder was muss ich noch kopieren so, dass ich nur noch die Pfade im ESM ändern muss?
    )))

    • Offizieller Beitrag

    Hallo,


    dauert das kopieren lokal so lange?


    Die Datei kann in der Regel nicht oder wenig fragmentiert sein.


    Hardware-Probleme kannst du ausschliessen?


    Habe sowas vermehrt bie Servern mit S-ATA Platten gesehen.


    Treiber für den I/O bzw. LAN in Ordnung?


    Wenn du den Speicherort ändern willst, macht das verschieben den Datei der Exchange selber!


    Nur im ESM auf die Eigenschaften der DB gehen und dort den neuen Speicherort angeben.


    Lediglich der Pfad selber muss existieren.


    NICHT in das Root eines Laufwerkes legen!!


    Für die Dauer der Verschiebung wird der Store Offline genommen.


    Wenn du den Befehl wie aufgeführt ausführst, wird lediglich die temporäre DB in das andere Verzeichnis/LW gelegt.


    ;)

    Hallo,


    jepp richtig das Kopieren lokal dauert so lang. Hardwarefehler kann ich glaube ich ausschliessen (Keine komischen Geräusche; Nichts im GeräteManager; und in den Log's)
    Soweit ich das sehen kann haben wir zwei SCSI Platten drin.
    Bei den Treibern kann ich keine offenkundigen Fehler erkennen. Suche gleich noch mal im Netz nach aktuelleren.


    (Zu 2.)

    Zitat

    Wenn du den Befehl wie aufgeführt ausführst, wird lediglich die temporäre DB in das andere Verzeichnis/LW gelegt.


    Soweit war es noch klar. Hatte vorgehabt dann die Temporäre online zubringen um die Off-Time zu verkürzen.
    Weil:
    Ablegen der DB im selben Ordner/Partition = zu wenig Platz
    Löschen der alten DB nach dem Befehl (s.o.) und Kopieren der Temp danach = dauert zu lang.
    Darauf bezog sich die Frage worauf ich achten muss.


    (Neuer Pkt. 3)
    Ich hatte vor einiger Zeit den Fehler gemacht das ich die Grösse der Postfächer als Liste ausgedruckt habe.
    Seit dem werde ich ständig damit konfrontiert das wir ca. 35GB an Postfachspeicher belegen...
    Leider ist aufgefallen das 35GB nicht so viel ist wie die Speichergrenze von 75GB.
    Ist das so normal und woran liegt das eigentlich? Komme dort in starke Argumentationsnöte.
    (Bevor die Frage kommt: Letztes Onlinedefrag besagt das umumbei 200MB frei sind bei den Postfächern)

    • Offizieller Beitrag

    Hi,


    du kannst die Temporäre DB NICHT mounten!!!!


    Diese Datei existiert nur so lange, wie das eseutil braucht für die Offline-Defragmentierung!!


    Wären dieser Zeit ist der Store zwingend down!


    Wenn lokales kopieren dermassen lange dauert, würde ich mich mit dem Hersteller in Verbindung setzten.


    :oops:

    Zitat


    (1)du kannst die Temporäre DB NICHT mounten!!!!


    (2)Diese Datei existiert nur so lange, wie das eseutil braucht für die Offline-Defragmentierung!!


    Soo... sicher?


    erst zu (2):
    Der Befehl eseutil /d /p [XXXXX]exchsrvr\mdbdata\priv1.edb /t"[YYYYYY]\priv1.edb" macht folgendes.


    eseutil /d
    ist klar!


    [XXXXX]exchsrvr\mdbdata\priv1.edb
    Welche nicht komprimierte DB soll benutzt werden?


    /t"[YYYYYY]\priv1.edb"
    Wo soll die temporäre Datenbank erstellt werden?


    /p
    Und das ist der springende Punkt! Sagt Microsoft: Bewahrt die temporäre Datenbank (in anderen Worten: Erstellt nicht) Hinweis: Wenn das Erstellen deaktiviert ist (wenn Sie beispielsweise die Option /p verwenden), wird die ursprüngliche Datenbank nicht komprimiert beibehalten, und die defragmentierte Version der Datenbank ist in der temporären Datenbank enthalten.


    Das heisst also das man die unkompremierte hat und die neue kompremierte an einem anderen Speicherort!


    Dann zu (1):
    Nach dem Oben angegebenen Prozess folgendes:
    1. SMTP stoppen
    2. Speichergruppe offline nehmen
    3. alte unkompremierte .stm und .edb Dateien umbenennen (zur sicherheit)
    4. Speichergruppe online schalten
    5. Er legt selbsttändig eine Leere an
    6. Diese über den System Manager verschieben
    7. Speichergruppe offline nehmen
    8. die verschobenen leeren DB's löschen
    9. die kompremierten .stm und .edb Dateien wieder in priv1.stm und priv1.edb um benennen (halt so wie die leeren DB's nach dem Verschieben hiessen)
    10. Online nehmen
    11. SMTP starten


    So hatte ich es vorgehabt und das ist nach der Beschreibung der Parameter von Microsoft auch möglich.
    http://support.microsoft.com/kb/192185/de


    Was sagste dazu? :hammer:



    Ich hab es aber raus bekommen woran es lag. Es war bei uns eine in irgend einer Form defekte Datenbank.


    Vollständig gelöst habe ich mein Problem so:


    1. SMTP stoppen
    2. Informationsspeicherdienst Stoppen
    3. Kopieren der .edb und .stm
    4. umbenennen der orig. priv1.edb und priv1.stm Dateien (zur sicherheit)
    5. Hacken setzen unterm Postfachspeicher bei "diesen Informationsspeicher beim Start nicht bereitstellen"
    6. Wiederherstellungsspeicher erstellen mit der Kopie der Dateien
    7. Dienst wieder starten Wiederherstellungsspeicher bereitstellen
    8. Aus dem Wiederherstellungsspeicher die Postfächer wiederherstellen
    9. evtl. drauf achten ob oder welches Postfach unverhältnismässig gross ist
    10. Hacken wieder raus nehmen(siehe oben)
    11. Dann SMTP starten


    Dabei hab ich fest gestellt das wohl irgendwelche toten Daten im Speicher lagen und die damit weg waren.


    Jetzt haben wir wieder 35 Gig.


    PS: Es war wohl deshalb alles so langsam da alle Speicher bewegungen auf einem RAID 5 waren.