2
Exchange 2003-Datenbank nach Migration größer - zu groß!
Datenbank bei Exchange 2003 nach Exchange 2003 (NewOrg)-Migration von 70 auf 77 GB angewachsen. Postfachspeicher wurde angehalten.
Hallo zusammen,
wir müssen aufgrund diverser Probleme unsere jetzige AD-Domäne komplett neu aufsetzen (bitte keine Fragen hierzu, gewisse Gründe zwingen uns dazu), damit u.a. in einem SPÄTEREN Schritt der Exchange 2007 unseren Exchange 2003 ablöst. Der EX2007 benötigt ja ein "sauberes" Active Directory und vieles, was mit dem EX2003 noch funktioniert, verweigert der EX2007. So viel zur Vorgeschichte!
Der rationale Weg unserer Planung ist folgender:
1.) EX2003 "Alte Organisation/Domain" nach EX2003 "Neue Organisation/Domain" kopieren
2.) Nach erfolgreicher Umsetzung/Testphase tritt der EX2007 der neuen EX2003-Organisation bei
3.) Migration von EX2003 -> EX2007
Jetzt zu dem Problem: neue Domäne + neue EX2003 steht. Nach der Kopieraktion der Postfächer mittels des Exchange Migration Wizard ist die Datenbank auf dem neuen EX2003 zu groß (77 GB) geworden, obwohl die DB auf dem Quell-Exchange nur 70 GB groß ist. Auch eine Offline-Defragmentierung mittels eseutil.exe brachte keine Vekleinerung.
Wie kann das passieren, dass nach der Migration die DB rund 10% größer ist? Auffällig ist, dass auf dem Quellserver die EX-DB auf priv1.edb (45GB) / priv1.stm (25 GB), beim Zielserver in priv1.edb (77 GB) / priv1.stm (0,2 GB) aufgeteilt ist.
Wie kann ich die Migration durchführen, OHNE die Benutzer zum Löschen aufzufordern und OHNE in einem Schritt auf den EX2007 aufzurüsten?
Danke im Voraus!
Hallo zusammen,
wir müssen aufgrund diverser Probleme unsere jetzige AD-Domäne komplett neu aufsetzen (bitte keine Fragen hierzu, gewisse Gründe zwingen uns dazu), damit u.a. in einem SPÄTEREN Schritt der Exchange 2007 unseren Exchange 2003 ablöst. Der EX2007 benötigt ja ein "sauberes" Active Directory und vieles, was mit dem EX2003 noch funktioniert, verweigert der EX2007. So viel zur Vorgeschichte!
Der rationale Weg unserer Planung ist folgender:
1.) EX2003 "Alte Organisation/Domain" nach EX2003 "Neue Organisation/Domain" kopieren
2.) Nach erfolgreicher Umsetzung/Testphase tritt der EX2007 der neuen EX2003-Organisation bei
3.) Migration von EX2003 -> EX2007
Jetzt zu dem Problem: neue Domäne + neue EX2003 steht. Nach der Kopieraktion der Postfächer mittels des Exchange Migration Wizard ist die Datenbank auf dem neuen EX2003 zu groß (77 GB) geworden, obwohl die DB auf dem Quell-Exchange nur 70 GB groß ist. Auch eine Offline-Defragmentierung mittels eseutil.exe brachte keine Vekleinerung.
Wie kann das passieren, dass nach der Migration die DB rund 10% größer ist? Auffällig ist, dass auf dem Quellserver die EX-DB auf priv1.edb (45GB) / priv1.stm (25 GB), beim Zielserver in priv1.edb (77 GB) / priv1.stm (0,2 GB) aufgeteilt ist.
Wie kann ich die Migration durchführen, OHNE die Benutzer zum Löschen aufzufordern und OHNE in einem Schritt auf den EX2007 aufzurüsten?
Danke im Voraus!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 124379
Url: https://administrator.de/contentid/124379
Ausgedruckt am: 22.11.2024 um 22:11 Uhr
2 Kommentare
Neuester Kommentar
Hallo.
Das ist völlig normal, da bei diesem Vorgang die "Single-instance" Speicherung nicht mehr klappt. "Single-instance" bedeutet, dass jedes Dokument in einem Postfachspeicher nur einmal vorhanden ist, auch wenn es anscheinend in den Postfächern mehrere User vorhanden ist.
Auch das ist normal. In der STM Datei werden native Daten gespeichert (das sind Daten, auf die noch kein MAPI Client zugegriffen hat). Da Exmerge ein MAPI Client ist, werden die Daten der STM Datei in das RTF Format konvertiert und dann in der EDB Datei gespeichert.
Klar, was soll auch defragmentiert werden, wenn nichts fragmentiert ist
LG Günther
Wie kann das passieren, dass nach der Migration die DB rund 10% größer ist?
Das ist völlig normal, da bei diesem Vorgang die "Single-instance" Speicherung nicht mehr klappt. "Single-instance" bedeutet, dass jedes Dokument in einem Postfachspeicher nur einmal vorhanden ist, auch wenn es anscheinend in den Postfächern mehrere User vorhanden ist.
Auffällig ist, dass auf dem Quellserver die EX-DB auf priv1.edb (45GB) / priv1.stm (25 GB), beim Zielserver in priv1.edb (77 GB) / priv1.stm (0,2 GB) aufgeteilt ist.
Auch das ist normal. In der STM Datei werden native Daten gespeichert (das sind Daten, auf die noch kein MAPI Client zugegriffen hat). Da Exmerge ein MAPI Client ist, werden die Daten der STM Datei in das RTF Format konvertiert und dann in der EDB Datei gespeichert.
Auch eine Offline-Defragmentierung mittels eseutil.exe brachte keine Vekleinerung.
Klar, was soll auch defragmentiert werden, wenn nichts fragmentiert ist
LG Günther
Vielen Dank für die Info! Ich konnte das Problem wiefolgt lösen: unsere Datensicherung (Symantec Backup Exec) hat bei der Sicherung die Exchange-DB zum "Leben erweckt", so dass ich zwei große Postfächer löschen konnte. Nach der Online-Defragmentierung ist wieder ausreichend Platz!
