9
Exchange 2003 Datenbank Defragmentierung
Hallo zusammen,
ich habe gerade folgendes Problem:
Win 2003 SBS mit 2 Partitionen
C für System
D war früher Datev, Fileserver, WSUS und Exchange (warum nicht extra Partitionen genutzt wurden... kP)
Datev, Files und WSUS habe ich nun nach und nach auf eigene Server umgezogen. Nun wollte ich die Exchange Datenbank defragmentieren, weil sie doch recht verteil auf dem Dateisystem war.
Leider brachten weder die Defragmentierung der Datenbank selber mit esutil was, noch anschliessende eine Defragmentierung des Dateisystems etwas.
Im Gegenteil: nach esutil wurde es eigentlich noch schlimmer (siehe Bild). Habt ihr eine Idee, wie ich wieder etwas Ordnung auf die Partition bekomme?
Gruß
ich habe gerade folgendes Problem:
Win 2003 SBS mit 2 Partitionen
C für System
D war früher Datev, Fileserver, WSUS und Exchange (warum nicht extra Partitionen genutzt wurden... kP)
Datev, Files und WSUS habe ich nun nach und nach auf eigene Server umgezogen. Nun wollte ich die Exchange Datenbank defragmentieren, weil sie doch recht verteil auf dem Dateisystem war.
Leider brachten weder die Defragmentierung der Datenbank selber mit esutil was, noch anschliessende eine Defragmentierung des Dateisystems etwas.
Im Gegenteil: nach esutil wurde es eigentlich noch schlimmer (siehe Bild). Habt ihr eine Idee, wie ich wieder etwas Ordnung auf die Partition bekomme?
Gruß
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: 148067
Url: https://administrator.de/contentid/148067
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
9 Kommentare
Neuester Kommentar
Moin,
ganz ehrlich "lass" es (Defragmentierung des Dateisystems) - bringt (Außer Stress & Ärger) garnix.
Wenn man es macht, hat man viel Zeit geopfert und die DB im aktuellen Moment optimiert.
Kommt eine einzige Mail dazu, ist die DB schon wieder nicht "optimal", aber das weiß das System und das ist (typischerweise eine Tankstellenadminweisheit), das man die Exchange DB oder das Filesystem eines via Raidplaten genutzen Servers optimieren muß
Wenn der ordentlich gesichert wird - ist das das beste und wichtigste für einen Exchange. Denn dann werden die Logfiles auch gelöscht.
"Vielleicht" macht das mal Sinn, wenn man 100erte Mailboxen gleichzeitig gelöscht hat und neue angelegt hat", aber auch nur dann.
Gruß
ganz ehrlich "lass" es (Defragmentierung des Dateisystems) - bringt (Außer Stress & Ärger) garnix.
Wenn man es macht, hat man viel Zeit geopfert und die DB im aktuellen Moment optimiert.
Kommt eine einzige Mail dazu, ist die DB schon wieder nicht "optimal", aber das weiß das System und das ist (typischerweise eine Tankstellenadminweisheit), das man die Exchange DB oder das Filesystem eines via Raidplaten genutzen Servers optimieren muß
Wenn der ordentlich gesichert wird - ist das das beste und wichtigste für einen Exchange. Denn dann werden die Logfiles auch gelöscht.
"Vielleicht" macht das mal Sinn, wenn man 100erte Mailboxen gleichzeitig gelöscht hat und neue angelegt hat", aber auch nur dann.
Gruß
Hey, danke für die Antwort.
Definiere mal ordentlich gesichert ;) Aktuell wird jede Nacht ein Vollbackup mit NTBackup gemacht (Zeit und Speicher sind da).
Gruß
Definiere mal ordentlich gesichert ;) Aktuell wird jede Nacht ein Vollbackup mit NTBackup gemacht (Zeit und Speicher sind da).
Gruß
Hallo,
ich finde ja diesen Satz sehr prickelnd:
Das ist für eine SBS-Umgebung eher untypisch, dass man für jeden dieser Fälle eigene Server hat.
ich finde ja diesen Satz sehr prickelnd:
Datev, Files und WSUS habe ich nun nach und nach auf eigene Server umgezogen.
Das ist für eine SBS-Umgebung eher untypisch, dass man für jeden dieser Fälle eigene Server hat.
Ordentlich gesichert bedeutet, dass du im Restorefall genau die Daten hast, die du benötigst, um diese Wiederherstellung in einer ansprechenden Zeit durchzuführen.
Hi,
wenn du nicht gerade einen Benchmarktest vor und nach der Defragmentierung laufen lässt, wirst du vermutlich nicht viel spüren. Da beim Exchange noch andere Faktoren mit reinspielen.
Allgmein: wenn die Blöcke wirklich lückenlos geschrieben werden, ist der Gewinn sehr schnell hinfällig. Denn die Datenbestände ändern sich doch von Sekunde zu Sekunde. Wenn die Blöcke zu eng liegen, werden vermutlich neue Daten an anderer Stelle mit ausreichend Platz abgelegt. Das macht die Wege länger.
Ist etwas Abstrakt, ich weiß. Es gibt sogar Defragmentierer, die fortlaufend im Hintergrund die Daten hin und her schieben. Das ist aber eher kontraproduktiv.
Bei einer Exchange DB macht es nur Sinn, um Platz zu gewinnen. Wenn viel gelöscht, verschoben wurde, wird nach dem defragmentieren die DB deutlch kleiner.
Kleiner Nebeneffekt: Da die DB neu geschrieben wird, kann man so auch Fehler aufspüren, die normal wohl unentdeckt bleiben würden.
Also zum Platzsparen und DB-Testen ist defragmentieren mit das Mittel der Wahl! Ansonsten, wie Timo schon schrieb, eher Finger weg.
mfg Crusher
wenn du nicht gerade einen Benchmarktest vor und nach der Defragmentierung laufen lässt, wirst du vermutlich nicht viel spüren. Da beim Exchange noch andere Faktoren mit reinspielen.
Allgmein: wenn die Blöcke wirklich lückenlos geschrieben werden, ist der Gewinn sehr schnell hinfällig. Denn die Datenbestände ändern sich doch von Sekunde zu Sekunde. Wenn die Blöcke zu eng liegen, werden vermutlich neue Daten an anderer Stelle mit ausreichend Platz abgelegt. Das macht die Wege länger.
Ist etwas Abstrakt, ich weiß. Es gibt sogar Defragmentierer, die fortlaufend im Hintergrund die Daten hin und her schieben. Das ist aber eher kontraproduktiv.
Bei einer Exchange DB macht es nur Sinn, um Platz zu gewinnen. Wenn viel gelöscht, verschoben wurde, wird nach dem defragmentieren die DB deutlch kleiner.
Kleiner Nebeneffekt: Da die DB neu geschrieben wird, kann man so auch Fehler aufspüren, die normal wohl unentdeckt bleiben würden.
Also zum Platzsparen und DB-Testen ist defragmentieren mit das Mittel der Wahl! Ansonsten, wie Timo schon schrieb, eher Finger weg.
mfg Crusher
Zitat von @goscho:
Hallo,
ich finde ja diesen Satz sehr prickelnd:
> Datev, Files und WSUS habe ich nun nach und nach auf eigene Server umgezogen.
Das ist für eine SBS-Umgebung eher untypisch, dass man für jeden dieser Fälle eigene Server hat.
Hallo,
ich finde ja diesen Satz sehr prickelnd:
> Datev, Files und WSUS habe ich nun nach und nach auf eigene Server umgezogen.
Das ist für eine SBS-Umgebung eher untypisch, dass man für jeden dieser Fälle eigene Server hat.
Warum untypisch? Der Server war völlig überlastet, da musste ausgleich geschaffen werden. Datev auf einen Server, Files auf einen anderen. Mittlerweile sind ca 50 Clients im Netzwerk, angeschafft wurde der SBS mal für <10.
Zitat von @kopie0123:
Warum untypisch? Der Server war völlig überlastet, da musste ausgleich geschaffen werden. Datev auf einen Server, Files
auf einen anderen. Mittlerweile sind ca 50 Clients im Netzwerk, angeschafft wurde der SBS mal für <10.
Das kann ich dann schon nachvollziehen.Warum untypisch? Der Server war völlig überlastet, da musste ausgleich geschaffen werden. Datev auf einen Server, Files
auf einen anderen. Mittlerweile sind ca 50 Clients im Netzwerk, angeschafft wurde der SBS mal für <10.
Allerdings habe ich nicht wirklich Verständnis für einen eigenen Server für WSUS bei 50 Clients. Der macht bestimtt noch mehr, gell?
Hey,
jep, war ein fehler von mir vorhin. Auf dem WSUS laufen noch andere Dienste mit.
gruß
jep, war ein fehler von mir vorhin. Auf dem WSUS laufen noch andere Dienste mit.
gruß
Ein DB Server schreibt "Log" Files, wenn jemand in die DB schreibt.
(Beim Exchange bedeutet das so ungefähr - ein User macht ne Mail auf, damit wird die vom Status ungelesen in gelesen gesetzt und schwupps ist wieder ein kleiner Schritt mehr für das Transaktionfile nötig)
Diese brauchst du um im Fall der Fälle ein Restore hinzukriegen.
Aber diese Logfiles verstopfen die Platte. Wird die Kiste mit einem für diese DV geeigneten Sicherungswerkzeug gesichert - verschwinden diese Logs.
Aktuell wird jede Nacht ein Vollbackup mit NTBackup gemacht (Zeit und Speicher sind da).
Das ist "ordentlich"Gruß
retour
