Exchange 2016 DB Defragmentierung fehlgeschlagen
Hallo Zusammen
Mir ist wohl ein blöder Fehler unterlaufen.
Ich wollte die Datenbanken zweck Speicherplatzfreigabe defragementieren. Dabei habe ich nicht bedacht, dass er das TEMPDFRG.EDB File auf dem Laufwerk C:\ erstellt. Ich dachte er macht es im Verzeichnis wo die Datenbank liegt.
Jetzt ist der Speicher vollgelaufen. Das Problem konnte ich relativ schnell beheben. Auch die Datenbank konnte wieder eingebunden werden. Der Server läuft aktuell.
Meine Frage:
Kann ich das temporäre DEFRAG File unter C:\Program Files\Microsoft\Exchange Server\V15\Bin löschen? An der ursprünglichen Datenbank wurde so wie ich das sehe nichts gemacht, da der Defragmentierungstask noch im Gange war und dann abgebrochen hat mit Error 1808 DiskFull.
Danke für Eure Hilfe.
Grüsse
Plexi
Mir ist wohl ein blöder Fehler unterlaufen.
Ich wollte die Datenbanken zweck Speicherplatzfreigabe defragementieren. Dabei habe ich nicht bedacht, dass er das TEMPDFRG.EDB File auf dem Laufwerk C:\ erstellt. Ich dachte er macht es im Verzeichnis wo die Datenbank liegt.
Jetzt ist der Speicher vollgelaufen. Das Problem konnte ich relativ schnell beheben. Auch die Datenbank konnte wieder eingebunden werden. Der Server läuft aktuell.
Meine Frage:
Kann ich das temporäre DEFRAG File unter C:\Program Files\Microsoft\Exchange Server\V15\Bin löschen? An der ursprünglichen Datenbank wurde so wie ich das sehe nichts gemacht, da der Defragmentierungstask noch im Gange war und dann abgebrochen hat mit Error 1808 DiskFull.
Danke für Eure Hilfe.
Grüsse
Plexi
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1494557501
Url: https://administrator.de/forum/exchange-2016-db-defragmentierung-fehlgeschlagen-1494557501.html
Ausgedruckt am: 26.12.2024 um 13:12 Uhr
9 Kommentare
Neuester Kommentar
Zitat von @Plexi87:
Wie kann man denn eine solche Defragmentierung machen und das temporäre File auslagern? Kann man den Befehl entsprechend anpassen?
Parameter /t "<Pfad>\temp.edb"Wie kann man denn eine solche Defragmentierung machen und das temporäre File auslagern? Kann man den Befehl entsprechend anpassen?
Ein
eseutil /?
sagts dir auch.Gruß Strods
Zitat von @Plexi87:
Hallo Zusammen
Vielen Dank. Ich weiss, dass der Exchange da gewisse Wartungstask selbst macht. Aber ich habe gesehen, dass ich 30 GB White Space freigeben kann. Der wird auch durch die Archivierung nicht freigegeben oder?
Grüsse Plexi
Hallo Zusammen
Vielen Dank. Ich weiss, dass der Exchange da gewisse Wartungstask selbst macht. Aber ich habe gesehen, dass ich 30 GB White Space freigeben kann. Der wird auch durch die Archivierung nicht freigegeben oder?
Grüsse Plexi
Nein. Exchange ist faul, wenn die DB einmal aufgebläht wurde macht er das nicht vollständig rückgängig da das anpassen der Indizes Rechenzeit kostet und das ESE Datenbankformat ist nicht gerade effizient.
Es gibt zwar eine Onlinedefragmentierung aber vollständig wirst du damit den Whitespace nicht los, denn das Erweitern oder Verkleinern kostet auch immer wieder Zeit und Rechenleistung die den Usern Wartezeit bescheren würde.
Wenn Exchange die DB dauernd in der Größe vorhalten wollte die die Daten tatsächlich haben könntest du Exchange nicht mehr effizient benutzen weil es ständig damit beschäftigt wäre die DB größer oder kleiner zu machen.
So hält sie sich halt einen Puffer an Speicher auf Vorrat und die eingehenden Daten können ohne Verzögerung in der DB hinterlegt werden.
Dauernde Offline Defragmentierung ist nicht die Lösung wenn dein Speicher knapp ist, besorg dir mehr Speicher und archiviere mehr Daten in separate DBs oder Archive.
Auch das Benutzen der Postfächer als Dateiablage sollte man verhindern und die Größe von Attachments konsequent runterschrauben. Die sind nämlich die Hauptursache für extrem schwankende DB Größen.
genauso ist es, nach einem händischen defrag wird die DB nicht schneller und ehe du dich versiehst ist hat die db wieder die gleiche größe wie vorher. Anschließend leidet die performance an den Outlook Clients bis die wieder aufgebläht ist wie davor. So gesehen eine sinnlose ABM.
Sinn machen würde:
1. Alle Mailboxen per pst massenexport sichern.
2. Die PST bei jedem ins Homelaufwerk/Backup legen (optional)
3. Per Richtlinie Alle Emails die Älter als X sind löschen.
4. DB defragmentieren/shrinken
5. Wenn jemand was altes braucht soll er sich das aus der pst holen.
Es soll aber Leute geben die mit einer Mailbox unter 50GB unzufrieden sind weil die verlustängste überwiegen;)
Sinn machen würde:
1. Alle Mailboxen per pst massenexport sichern.
2. Die PST bei jedem ins Homelaufwerk/Backup legen (optional)
3. Per Richtlinie Alle Emails die Älter als X sind löschen.
4. DB defragmentieren/shrinken
5. Wenn jemand was altes braucht soll er sich das aus der pst holen.
Es soll aber Leute geben die mit einer Mailbox unter 50GB unzufrieden sind weil die verlustängste überwiegen;)