plexi87
Goto Top

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

Content-ID: 1494557501

Url: https://administrator.de/contentid/1494557501

Ausgedruckt am: 22.11.2024 um 09:11 Uhr

user217
Lösung user217 30.07.2024 um 09:26:10 Uhr
Goto Top
ja, es ist wirklich nur temporär und nur vorhanden während eseutil läuft.
Die Frage könntest du dir aber selbst beantworten indem du z.B. sysinternals process explorer anwerfen würdest..
Plexi87
Plexi87 30.07.2024 um 09:45:04 Uhr
Goto Top
Super, vielen Dank für die schnelle Antwort.
Ich wusste einfach nicht, ob noch irgendwo auf dieses File referenziert wird. Da frage ich lieber einmal zu viel als zu wenig face-smile

Wie kann man denn eine solche Defragmentierung machen und das temporäre File auslagern? Kann man den Befehl entsprechend anpassen?

Grüsse Plexi
user217
user217 30.07.2024 um 09:49:00 Uhr
Goto Top
Keine Ursache!
Meinem Restwissen nach kannst du dir das komplett sparen weil der Exchange das seit 2016 selber automatisch macht, außer du brauchst wirklich jedes MB aber dann wäres ggf. aber sinnvoller die user Mailboxen zu archivieren.
13910172396
13910172396 30.07.2024 aktualisiert um 09:55:33 Uhr
Goto Top
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"

Ein eseutil /? sagts dir auch.

Gruß Strods
Plexi87
Plexi87 30.07.2024 um 10:00:38 Uhr
Goto Top
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
13910172396
13910172396 30.07.2024 aktualisiert um 10:53:00 Uhr
Goto Top
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

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.
user217
user217 30.07.2024 um 10:57:08 Uhr
Goto Top
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;)
Plexi87
Plexi87 30.07.2024 um 11:17:57 Uhr
Goto Top
Super.
Vielen Dank für die Ausführungen. Werde dies für die nächste grössere Wartung mal im Hinterkopf behalten.
Eine schöne Restwoche allerseits face-smile

Plexi
Flash600
Flash600 02.08.2024 um 10:22:56 Uhr
Goto Top
evtl. könntest du dann auch (falls genug Platz vorhanden) eine neue DB(s) erstellen, mailboxen dorthin migrieren und die alte DB löschen.