Jump to content

Exchange Postfachspeicher mal wieder ....


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hi,

 

habe ein Problem mit dem Exchange 2003 (SBS) Postfachspeicher.

Habe zu dem Thema einiges hier im Forum gefunden, aber keine

Lösung für mein Problem. Also:

 

Die Priv1.edb ist fast 17 GB groß, sämtliche private Postfächer zusammen aber

nicht einmal 3GB. Also den Postfachspeicher aus der Bereitstellung herraus-

genommen und die Datei mit eseutil defragmentiert.

 

Ergebnis = Nix. Die Priv1.edb ist immer noch fast 17GB groß.

 

Kann ich eine neue DB erstellen lassen, und die Postfächer der alten

danach irgendwie übertragen? Irgendwo in der alten Datei müssen

sich Daten verstecken, die zu keinem Postfach gehören .... :suspect:

Link zu diesem Kommentar

Nutze die Recovery Storage Group (Wiederherstellungsspeichergruppe) fuer die Uebertragung der Postfaecher von der alten in die neue DB.

Das Exchangetool ExMerge kann dafuer auch eingesetzt werden.

 

Weitere Ansatzpunkte mit dem Exchange 2003 SP2:

Die Grenzen fuer den Postfachspeicher und den Speicher fuer die Oeffentlichen Ordner koennen (per Registrykey) auf 75 GB erhoeht werden.

 

Was sagt das Diagnosetool Exchange Best Practices Analyzer (ExBPA) zu Deiner Exchange Organisation?

Link zu diesem Kommentar

Hi.

 

Es muss ja einen Grund geben, warum die Datenbank so groß ist.

 

- wie lange werden den gelöschte Objekte aufbewahrt ?

- wie lange werden gelöschte Postfächer aufbewahrt ?

- wurden irgendwann Postfächer gelöscht ?

- hast du scin einmal den CleanUp Agent gestartet ? (Postfächer -> Rechtsklick -> CleanUp Agent)

 

LG Günther

Link zu diesem Kommentar

Hallo,

 

normalerweise werden Objekte (mails) und Postfächer 14 Tage aufbewahrt,

ich habe diesen Zeitraum aber aufgrund des Problems schon mal 2 Tage lang

auf eine Vorhaltezeit von einem Tag runtergesetzt, was nicht half.

 

Die Option, das Postfächer und Objekte erst nach erfolgter Sicherung des

Postfachspeichers gelöscht werden, ist nicht aktiv.

(Erkennt der Exchange, wenn z.B. Veritas BackupExec den Serverstatus sichert?).

 

Werde mich als nächstes mit ExMerge & ExBPA auseinandersetzen.

 

@ rablu:

Ist der Registry-patch auch für den Exchange des SBS gültig? Der ist ja nicht

grundlos auf 16 GB (temporär 17GB) begrenzt. Erlaubt?

Link zu diesem Kommentar

Erkennt der Exchange, wenn z.B. Veritas BackupExec den Serverstatus sichert?

Ja, er merkt sich den letzten Sicherungsstatus der beiden Exchange DB. Auch bei einer vollstaendigen oder inkrementellen Sicherung durch Fremdprodukte (wie z.B. durch Backup Exec oder ArcServe).

 

Du kannst den Sicherungsstatus mit dem Exchange System Manager (ESM), mit dem ExBPA (der ExBPA warnt bei einer noch nie durchgefuehrten Exchange-Sicherung) und mit Eseutil auslesen.

 

Was sicherst Du mit Veritas Backup Exec beim Exchange genau?

Welche Version von Backup Exec setzt Du ein (klingt nach einer der SMB-Varianten)?

Link zu diesem Kommentar

Was sicherst Du mit Veritas Backup Exec beim Exchange genau?

Welche Version von Backup Exec setzt Du ein (klingt nach einer der SMB-Varianten)?

 

Es handelt sich um Veritas BackupExec 10.0 für Small Business Server 2003

(Version vor Übernahme durch Symantec).

 

Gesichert wird das komplette Systemlaufwerk C:\ mit Ausnahme der TrendMicro-Ordner,

alle Exchange Mailboxen, alle öffentlichen Ordner, alle SQL-Instanzen

(<standard>, BKUPEXEC, SBSMONITORING & SHAREPOINT),

die shadow-copy Komponenten "Systemstatus" & "Dienststatus" und die

"Erste Speichergruppe" im Microsoft Information Store.

 

Sicherungen laufen immer durch, Fehler gibt es bei einigen Windows Systemdatenbanken

unter C:\Windows\security\ ... die *.log, *.edb & *.sdb-Dateien werden Übersprungen.

Link zu diesem Kommentar

Hi.

 

Sicherungen laufen immer durch, Fehler gibt es bei einigen Windows Systemdatenbanken

unter C:\Windows\security\ ... die *.log, *.edb & *.sdb-Dateien werden Übersprungen.

 

Schau dir dazu bitte einmal diesen Beitrag an - http://www.mcseboard.de/showthread.php?t=93510

 

Und ansonsten - hast du eigentlich schon einmal alle Punkte durchgearbeitet, die ab Beitrag #3 beschrieben wurden.

 

LG Günther

Link zu diesem Kommentar

Also .....

 

habe den Exchange- und den Security-Ordner aus der Filesicherung herausgenommen.

Dienst-, Systemstatus und Exchange des Servers werden gesichert.

 

Die genannten Ansatzpunkte habe ich alle durch, bis auf:

 

Postfächer mit der Wiederherstellungsspeichergruppe in neue Datenbank umziehen. -> Geht erst am WE.

 

 

Gelöschte Objekte werden wie gesagt sonst 14 Tage gespeichert, aber ich hatte diesen Wert

probeweise für 2 Tage runtergesetzt, so daß sie nur noch einen Tag gespeichert werden.

Kein Ergebnis.

 

Die Option, daß Objekte erst nach einer erfolgreichen Sicherung gelöscht werden, ist nicht aktiv.

Auch wenn dies aktiv sein sollte, die Sicherung des Exchange läuft jede Nacht 1A durch.

(Fullbackup)

 

Der Exchange Best Practice Analyzer sagt, das die Exchange-DB zu groß ist. :jau:

Warum (oder besser, welches Element daran schuld ist), ist mir dort nicht ersichtlich.

 

 

Der Registry-patch für das SP2 für Exchange verschafft erstmal jede Menge Luft

und die Mitarbeiter können wieder problemlos mit Outlook "rumspielen",

allerdings bleibt ja das grundlegende Phänomen, daß die DB viel zu groß ist.

 

Am WE geh ich das Anlegen einer neuen DB an, evtl wird dann ja der "Balast"

in der alten DB zurückgelassen....

 

Schonmal Danke für eure Tips :)

Link zu diesem Kommentar
  • 2 Wochen später...

Update:

 

Die erste Defragmentierung mit eseutil (besser die ersten 3 mal) hatte ich noch

ohne SP2 für den Exchangeserver durchgeführt, was ja wie gesagt nichts gebracht

hat. Hier habe ich aus anderer Quelle die Empfehlung bekommen, es jetzt nochmal

nach dem SP2 zu probiern, bevor ich eine neue DB anlege ... und es hat geklappt.

 

Zum einen hat die Defragmentierung nur noch knappe 30 Minuten gedauert (vorher über 2 Stunden),

und zum anderen ist die DB jetzt von 16.9 auf 3.8 GB geschrumpft.

Link zu diesem Kommentar

Hi,

 

Zur Info:

bei Ex 2003 SP2 wird für die Berechnung der Datenbankgröße jetzt nicht mehr die Größe auf dem Datenträger herangezogen, sondern die logische Größe (also abzgl. aller nicht mehr genutzten Datensätze).

 

- Size check done against the database now uses logical database size. Empty space in the database will not count against the configured database size limit, therefore no offline defrag will be required for recovery after running out of licensed database size.

 

Hier der Link zum kompletten Artikel.

 

Christoph

Link zu diesem Kommentar

Schau mals in Ereignisprotokoll ob die online defragmentierung und das clean up funktioniert.

 

Zum Beispiel: event 700 "Information Store (552) First Storage Group: Online defragmentation is beginning a full pass on database 'C:\Program Files\Exchsrvr\mdbdata\pub1.edb'. "

 

Cleanup of deleted mailboxes that are past the retention date is finished on database "First Storage Group\Mailbox Store (servername)".

0 deleted mailboxes (0 KB) have been removed.

0 deleted mailboxes (0 KB) have been retained.

 

 

Gruss

 

Rakli

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...