Defragmentierungsmodus "Eseutil /D"

Artikel
10/25/2013

Letztes Änderungsdatum des Themas: 2006-08-17

Der Schalter "/D" von "Eseutil" kann zum Offlinedefragmentieren und -komprimieren einer Datenbank verwendet werden. Mit der Defragmentierungsoption wird der verwendete Speicher zusammengeführt, nicht genutzter Speicherplatz wird entfernt und auf diese Weise wird die Datenbank komprimiert und deren Größe reduziert. Anweisungen zur Verwendung der Syntax von "Eseutil /D" finden Sie unter Ausführen von „Eseutil /D“ (Defragmentierung).

Der Schalter "/D" von "Eseutil" kann zum Defragmentieren und Komprimieren einer Datenbank verwendet werden. Bei normalen Operationen werden Datenbankdateien nie auf einen Wert unterhalb der aktuellen Größe verkleinert. Wenn in der Datenbank mit der Löschung von Objekten Speicherplatz freigemacht wird, werden vorhanden Seiten falls möglich weiterverwendet. In der Regel vergrößert sich eine Microsoft® Exchange Server-Datenbank im Verlauf der ersten Monate nach der Inbetriebnahme, aber schließlich stabilisiert sich die Datenbankgröße.

Unter normalen Bedingungen wird mit einer Offlinedefragmentierung der verwendete Festplattenspeicher nicht dauerhaft reduziert. Die Dateigröße wächst in der Regel wieder bis zu vorherigen nicht defragmentierten Größe an. Allerdings gibt es bestimmte Umstände wie das Verschieben zahlreicher Postfächer aus der Datenbank, die es ggf. lohnenswert machen, die Datenbank offline zu defragmentieren. Im Normalbetrieb wird die Datenbank standardmäßig jede Nacht logisch defragmentiert. Hiermit wird nicht die Größe der Datei auf der Festplatte reduziert, sondern die Leistungsfähigkeit der Datenbank erhöht.

Anmerkung:
Sie können das Dienstprogramm "Eseutil" verwenden, um den Informationsspeicher und das Verzeichnis in Microsoft Exchange Server 5.5 und um den Informationsspeicher in Microsoft Exchange 2000 und neueren Versionen zu defragmentieren.

Funktionsweise der Defragmentierungsoption von "Eseutil"

Wenn eine Datenbank mit "Eseutil" defragmentiert wird, indem nicht verwendeter Speicherplatz entfernt und die Datenbank komprimiert wird, erstellt "Eseutil" im Wesentlichen eine neue Datenbank, die alle Informationen der ursprünglichen Datenbank enthält. Nach Abschluss der Defragmentierung wird die ursprüngliche Datenbank gelöscht oder an einer benutzerseitig festgelegten Position gespeichert, und die neue Version wird über die ursprüngliche Version kopiert. Wenn das Dienstprogramm in der Datenbank auf ein Ernst zu nehmendes logisches Problem trifft, wird die Defragmentierung gestoppt. Die Datenbank muss nun erst mit "Eseutil /P" repariert werden, bevor sie defragmentiert werden kann.

Wenn eine Offlinedefragmentierung vorgenommen wird, erstellt Exchange temporäre Kopien der Datenbankdatei (EDB-Datei) und der Streaming-Datenbankdatei (STM-Datei). Tabellen aus der EDB-Datei werden in die temporäre Datenbank kopiert und auf diese Weise gesichert, leere Seiten und Indizes werden hingegen verworfen. Da hiermit die physikalische Anzahl der Seiten in der Datenbank geändert wird, werden Seiten nicht unverändert kopiert; die hierzwischen bestehenden Seitenverknüpfungen werden aktualisiert, und alle in der Datenbank verbleibenden Seiten werden einer Integritätsprüfung unterzogen. Alle Seiten in der STM-Datei, die Daten aufweisen, werden in der temporären STM-Datei gesichert, und die Verweise auf die Seiten werden in der EDB-Datei aktualisiert.

Wie lange dauert die Defragmentierung einer Datenbank?

Die Dauer bis zum Abschluss einer Defragmentierung ist davon abhängig, wie viel Leerraum eine Datenbank aufweist, und nicht von der Größe der Datenbankdatei. Beispielsweise dauert das Defragmentieren einer Datenbank mit 100 GB, die 10 GB Daten umfasst, ebenso lange wie das Defragmentieren einer Datenbank mit 11 GB, die 10 GB Daten umfasst.

Standardmäßig wird nach Abschluss der Defragmentierung die temporäre Datenbank automatisch zur neuen Produktionsdatenbank, und die ursprüngliche Produktionsdatenbank wird gelöscht. Die Dauer der Defragmentierung kann erheblich verringert werden, wenn sich auf dem logischen Laufwerk der Datenbank freier Speicher in der Größe der ursprünglichen Datenbankdateien befindet. In diesem Fall kann die temporäre Datenbank auf dem gleichen logischen Laufwerk gespeichert werden, und die abschließende Kopie ist im Handumdrehen erstellt.

Microsoft empfiehlt, kein Netzlaufwerk für die temporäre Datenbank zu verwenden. Bei Verwendung eines Netzlaufwerks für die temporäre Datenbank verlängert sich die Zeit für die Defragmentierung, und das Verfahren wird bei jedem zwischenzeitlichen oder dauerhaften Netzwerkfehler beendet. Da das Defragmentierungsverfahren nicht wieder aufgenommen werden kann, müssten Sie in diesem Fall von vorne anfangen.

Anmerkung:
Sie benötigen lediglich den Speicherplatz auf dem logischen Laufwerk, der der abschließenden Größe der Dateien nach der Defragmentierung entspricht. Obwohl es unmöglich ist, exakt vorherzusagen, wie viel Festplattenspeicher benötigt werden wird, empfiehlt es sich, ca. 110 % an freiem Festplattenspeicher vorzuhalten. Weitere Informationen zum Bestimmen der Größe des Festplattenspeichers für die Defragmentierung finden Sie im Microsoft Knowledge Base-Artikel 195914 "Bestimmen des freien Speicherplatzes einer Datenbank mit Exchange 5.5 Service Pack 1 und höheren Versionen von Exchange" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=195914).

Sie benötigen lediglich den Speicherplatz auf dem logischen Laufwerk, der der abschließenden Größe der Dateien nach der Defragmentierung entspricht. Obwohl es unmöglich ist, exakt vorherzusagen, wie viel Festplattenspeicher benötigt werden wird, empfiehlt es sich, ca. 110 % an freiem Festplattenspeicher vorzuhalten. Weitere Informationen zum Bestimmen der Größe des Festplattenspeichers für die Defragmentierung finden Sie im Microsoft Knowledge Base-Artikel 195914 "Bestimmen des freien Speicherplatzes einer Datenbank mit Exchange 5.5 Service Pack 1 und höheren Versionen von Exchange" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=195914).

Wann sollte "Eseutil /D" ausgeführt werden?

Es gibt mehrere Situationen, in denen "Eseutil /D" zum Defragmentieren einer Exchange-Datenbank ausgeführt werden sollte. Im Folgenden finden Sie eine Liste dieser Situationen:

Es gibt eine große Menge Leerraum in der Datenbank, der wiederverwertet werden kann. Als Beispiel hierfür gilt, wenn die Anzahl der Postfächer in der Datenbank erheblich verringert wurde.
Im Anwendungsprotokoll wird mehrfach ein Ereignis aufgezeichnet, das darauf hinweist, dass die Datenbank offline defragmentiert werden sollte. Dies tritt in seltenen Fällen auf, wenn die normale Onlinedefragmentierung nicht mehr in der Lage ist, die Datenbank in effizienter Weise zu defragmentieren.
Wenn die Datenbankgrößenbeschränkung von 16 GB unter der Standardversion von Exchange erreicht wurde und Leerraum wiederverwendet werden muss, damit die Datenbank bereitgestellt werden kann. Wenn Sie Exchange Server 2003 ausführen, sollte Service Pack 2 (SP2) installiert werden, um das Limit auf 75 GB zu erhöhen. Weitere Informationen über das Erhöhen des Limits für die Datenbankgröße finden Sie im Microsoft Knowledge Base-Artikel 828070, "Exchange Server 2003-Postfachspeicher wird nicht bereitgestellt, wenn die Postfachspeicher-Datenbank das 16-GB-Limit erreicht" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=828070).

Anmerkung:
Nach der Defragmentierung der Datenbank mit "Eseutil" empfiehlt es sich, eine vollständige Sicherung der Datenbank zu erstellen. Eine vollständige Sicherung wird benötigt, da mit der Datenbankdefragmentierung neue Datenbankdateien erstellt werden, die neue Datenbanksignaturen aufweisen. Das erneute Einspielen der Protokolldatei nach einer Wiederherstellung ist davon abhängig, dass die Datenbanksignaturen den erwarteten Werten entsprechen, die in den Transaktionsprotokolldateien aufgezeichnet sind. Alle Datenbanksicherungen, die vor der Defragmentierung erstellt wurden, enthalten Datenbankdateien mit Signaturen, die sich von denen der neuen, defragmentierten Datenbank unterscheiden. Wird eine ältere Datenbank wiederhergestellt, werden neue Transaktionsprotokolle, die an die neuen, defragmentierten Datenbankdateien gebunden sind, nicht wieder eingespielt.

Nach der Defragmentierung der Datenbank mit "Eseutil" empfiehlt es sich, eine vollständige Sicherung der Datenbank zu erstellen. Eine vollständige Sicherung wird benötigt, da mit der Datenbankdefragmentierung neue Datenbankdateien erstellt werden, die neue Datenbanksignaturen aufweisen. Das erneute Einspielen der Protokolldatei nach einer Wiederherstellung ist davon abhängig, dass die Datenbanksignaturen den erwarteten Werten entsprechen, die in den Transaktionsprotokolldateien aufgezeichnet sind. Alle Datenbanksicherungen, die vor der Defragmentierung erstellt wurden, enthalten Datenbankdateien mit Signaturen, die sich von denen der neuen, defragmentierten Datenbank unterscheiden. Wird eine ältere Datenbank wiederhergestellt, werden neue Transaktionsprotokolle, die an die neuen, defragmentierten Datenbankdateien gebunden sind, nicht wieder eingespielt.

Wann sollte "Eseutil /D" nicht ausgeführt werden?

Es gibt Fälle, in denen "Eseutil /D" zum Defragmentieren einer Exchange-Datenbank nicht ausgeführt werden sollte. Im Folgenden finden Sie eine Liste dieser Situationen:

Die Defragmentierungsoption von "Eseutil" sollte nicht als eine Art Standardwartungsmaßnahme ausgeführt werden. Zu diesem Zweck führt Exchange jede Nacht eine automatische Onlinedefragmentierung durch. Es gibt keinen Grund, regelmäßig eine Offlinedefragmentierung durchzuführen, es sei denn, dass bestimmte Umstände danach verlangen.
Die Defragmentierungsoption von "Eseutil" kann nicht ausgeführt werden, wenn die Datenbank nicht konsistent ist.

Anmerkung:
Sofern Sie nicht davon ausgehen, dass mehr als 20 % des verfügbaren Speichers eingespart werden können, bewirkt die Defragmentierung in der Regel keine wesentliche Größenreduzierung der Datenbankdateien.

Weitere Informationen

Weitere Informationen finden Sie unter den folgenden Themen im Handbuch zum Exchange Server-Datenbankdienstprogramm: