Exchange-Datenbanken offline defragmentieren


    Tags: ,

    Exchange-Datenbank defragmentierenIm Laufe der Zeit frag­mentiert eine Exchange-Daten­bank durch ver­schiedene Opera­tionen. Die Folgen sind ähnlich wie im Datei­system, nämlich eine gerin­gere Leistung durch eine ungün­stige Ver­teilung der Daten auf dem Lauf­werk. Das Bord­mittel eseutil.exe schafft hier Abhilfe, erfor­dert aber eine Downtime des Systems.

    Anmerkung: Das hier beschriebene Verfahren funkioniert zwar einwandfrei, aber Microsoft rät seit einiger Zeit davon ab. Aus diesem Grund kann es zu Einschränkungen beim Support kommen, wenn nach dem Defragmentieren Probleme auftreten. 

    Interaktionen mit der Datenbank können zum Beispiel das Anlegen, Löschen oder Verschieben von Benutzern sein, aber auch das normale tägliche Arbeiten mit Postfächern bis hin zur Archivierung. Leere Bereiche werden dann erneut gefüllt, aber dabei verteilen sich neue Daten oft über mehrere Lücken.

    Ungenutzten Platz zurückgewinnen

    Die Datenbank wird beim Löschen eines Benutzers nicht kleiner, sondern bleibt bei der gleichen Größe stehen. Eine Offline-Defrag­mentierung kann dagegen Speicher­platz auf dem Laufwerk zurück­gewinnen, indem sie diese Lücken schließt. Außerdem wird während dieses Vorgangs nach defekten Bereichen gesucht, um diese zu entfernen.

    Die Defrag­mentierung sollte während einer ausreichend dimen­sionierten Downtime geplant werden, da die jeweilige Datenbank während dieser Wartungs­aufgabe nicht verfügbar ist und die davon betroffenen Benutzer nicht arbeiten können.

    Hinweis: Dieses Verfahren sollte man nicht anwenden, wenn die Datenbank Mitglied in einer Availability Group ist.

    Platz für temporäre Datei

    Zudem sollte man beachten, dass während der Defrag­mentierung zusätzlicher Speicher­platz für temporäre Dateien bereit­gestellt werden muss. Idealer­weise bietet das Volume mindestens gleich viel freien Platz wie die Größe der jeweiligen Daten­bank.

    Ist dies nicht der Fall, dann kann man ein alternatives Laufwerk angeben, das in der Lage ist, die temporäre Datenbank aufzunehmen. Die Temp-Datei wird auf dem Laufwerk angelegt, auf dem die eseutil.exe ausgeführt wird. Außerdem kann man mit dem Parameter /T explizit einen Pfad für die temporäre Datei festlegen.

    Datenbank ermitteln

    Zuerst muss der Name der Datenbank ermittelt werden, welche defrag­mentiert werden soll. Dies geht am besten in PowerShell mittels

    Get-MailboxDatabase -Status | ft name, databasesize

    Name und Größe der Exchange-Datenbank ermitteln

    Neben dem Namen erhält man so die aktuelle Größe des Speicher­platzes, den die Datenbank­datei auf dem Laufwerk belegt.

    Der folgende Befehl gibt zusätzlich Auskunft darüber, wie viel Speicher­platz in der Datenbank übrig ist, also die gesamte Größe der Lücken ("Whitespace"):

    Get-MailboxDatabase -Status | ft name, databasesize, AvailableNewMailboxSpace

    Größe der Exchange-Datenbank und des enthaltenen Whitespace anzeigen

    Das Verhältnis zwischen der Größe der Datenbank und des ungenutzten Platzes entscheidet, ob sich eine Defrag­mentierung lohnt. Enthält zum Beispiel eine 200GB große Datenbank nur 20MB Whitespace, dann wird man von der Optimierung wahrscheinlich absehen.

    Defragmentierung starten

    Nun nimmt man die Datenbank offline, indem man ihre Bereitstellung aufhebt (Achtung ab jetzt können die User nicht mehr arbeiten). Dazu übergibt man Dismount-Database den Namen der DB, welchen man aus der Ausgabe des obigen Befehls entnimmt:

    Dismount-Database -Identity "Mailbox Database 0696279037"

    Exchange-Datenbank aushängen

    Für die eigentliche Defrag­mentierung bringt Exchange das Tool eseutil mit, welches sich auf dem Laufwerk unter \program files\microsoft\exchange server\V15\bin befinden sollte.

    Pfad zu eseutil.exe

    Folgender Aufruf startet den Vorgang und lagert gleichzeitig die temporäre Datenbank auf ein anderes Volume aus:

    eseutil /d "Mailbox Database 0696279037.edb" /T <UNC_path>

    Falls der Festplattenplatz auf dem aktuellen Volume ausreicht, dann kann man auf den Parameter /T verzichten:

    eseutil /d "Mailbox Database 0696279037.edb"

    In meinem Lab bekomme ich bei diesem Aufruf leider einen ERROR 1811 ausgegeben. Vorsichts­halber habe ich deswegen den Dienst Exchange Information Store neu gestartet und mich vergewissert, dass die Datenbank nicht mehr eingehängt ist.

    Die Lösung brachte aber dann der absolute Pfad zur Datenbank:

    eseutil /d "C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database 0696279037\Mailbox Database 0696279037.edb"

    Erfolgreicher Abschluss der Defragmentierung

    In meinem Lab erfolgt die Defrag­mentierung nun recht schnell, da die Datenbank nicht sehr groß ist. In größeren Umgebungen kann sie schon mal ein paar Stunden dauern.

    Datenbank wieder bereitstellen

    Der nächste Schritt ist nun, die Datenbank zu mounten, also sie wieder bereitzustellen:

    Mount-Database -Identity "Mailbox Database 0696279037"

    Zur Kontrolle kann man nun nochmal die Größe der Datenbank mit den Anfangswerten vergleichen.

    Verringerte Größe der Datenbank nach der Defragmentierung

    Wie man sehen kann, habe ich sich sogar in meinem Lab deutlich an Platz hinzugewonnen.

    1 Kommentar

    Bild von Oliver
    Oliver sagt:
    19. Dezember 2018 - 6:53

    Huch, schreiben wir jetzt das Jahr 2003 wieder???
    Zu damaliger Zeit war eseutil eine Geheimwaffe, um Exchange Datenbanken wieder flott zu kriegen.
    Mythen halten sich wohl länger und sind aus den Köpfen nicht herauszubekommen.
    Seit 2011 propagiert MS vergeblich: Don't use eseutil for defrag! Mit eseutil defragmented DBS are not longer supported, und dieses Credo gilt bereits seit 2011....!
    Die einzige Supported Configuration ist durch Mailbox-Move eine neue DB zu befüllen.
    Wenn durch das Löschen von Mailboxen viel Whitespace gewonnen wurde, ist dies eindeutig die prefered Methotik.
    Eseutil ist und bleibt ein Emergency Tool um Datenbanken hardcoremäßig im RAWModus zu reparieren, wenn Exchange die DB nicht mehr mounten kann.

    [Quelle siehe unten:]

    How can I reclaim the whitespace?

    Many assume the answer is to perform an offline defragmentation of the database using ESEUTIL. However, *that's not our recommendation*. When you perform an offline defragmentation you create an entirely brand new database and the operations performed to create this new database are not logged in transaction logs. The new database also has a new database signature, which means that you invalidate the database copies associated with this database.

    In the event that you do encounter a database that has significant whitespace and you don't expect that normal operations will reclaim it, our recommendation is:

    1.) Create a new database and associated database copies.
    2.) Move all mailboxes to the new database.
    3.) Delete the original database and its associated database copies.

    Nehmt bitte diesen Hinweis in obigen Artikel mit auf, Eure Leser korruptieren sonst ihre DBS und bekommen keinen Supoport von MS dafür!

    Mehr Lesetoff dazu von MS:
    https://blogs.technet.microsoft.com/exchange/2015/05/01/new-support-poli...
    https://blogs.technet.microsoft.com/exchange/2011/12/14/database-mainten...