Exchange Datenbank - ein Blick dahinter

Wir widmen uns nun etwas dem Blick hinter die Exchange Datenbank. Von anderen Seiten haben wir erfahren, dass die Datenbank transaktionsorientiert ist. Was bedeutet das ?

Wie arbeitet Exchange ?

Exchange ist nun am Arbeiten und bekommt und sendet Mails. Alle Änderungen erfolgen im Datenbankcache und damit erst mal im flüchtigen Hauptspeicher. Sie werden also nicht sofort in die Datenbank geschrieben. Damit im Falle eines Defekts nichts verloren geht, werden eben diese Anweisungen, was zu ändern ist nicht nur im Hauptspeicher geändert, sofort in die Transaktionsdatei geschrieben. Diese Transaktionsdateien enthalten daher immer die Änderungen der Datenbank und werden immer fort geschrieben, d.h. bereits geschriebene Informationen werden nicht mehr verändert. Das Zurückschreiben in die Datenbank erfolgt später. Diese Transaktionsdateien würden daher ihre Festplatte schnell voll schreiben, wenn kein anderer Mechanismus diese löscht.

So schreibt Exchange munter in die Protokolldateien. Immer dann, wenn eine Transaktion in der Protokolldateien steht, ist der Client wieder freigegeben. Ihre "Sanduhr" in Outlook ist also dann wieder weg, wenn Exchange die Befehle in die Transaktionsdatei geschrieben hat. Die hierfür benötigte Zeit ist also auch für die gefühlte Performance ihres Exchange Servers wichtig. Zwischen den tatsächlich in der Datenbank geänderten Bits und dem aktuellen Stand in den Protokolldateien können also einige Megabytes liegen.

Ein zweiter Prozess sorgt nun aber auch dafür, dass die bislang nur in dem Hauptspeicher vorliegenden Änderungen der Datenbankseiten auch in die Datenbank selbst zurück geschrieben werden. Exchange arbeitet quasi die Transaktionsprotokolle nach und schreibt die  Änderungen in die Datenbank. Analog dazu aktualisiert Exchange die EDB.CHK-Datei, in der nur steht, welche Inhalte von Transaktionsdateien von in die Datenbank auf der Festplatte geschrieben wurden. So kann bei einem  Ausfall der Store sehr schnell die bereits in der Datenbank enthaltenen Änderungen überspringen. Es ist daher auch ungefährlich die Datei EDB.CHK zu löschen. Manchmal ist es sogar erforderlich (Restore). Es führt allerdings zu einer längeren Startphase der Datenbank.

Beim Herunterfahren von Exchange muss Exchange aber alle Daten auch in die Datenbank schreiben. Daher kann es manchmal schon länger dauern, bis Exchange "unten" ist. Wird er übrigens unsanft beendet, denn merkt Exchange beim Hochfahren, dass die Datenbank noch nicht den gleichen Stand hat wie die letzte Protokolldatei (dazu gibt es die CHK-Datei) und arbeitet alle Transaktionsdateien ab. Die beim unsanften Beenden eingesparte Zeit muss man als bei Start wieder hinzu rechnen.

So kann bei einem Ausfall auch bei voller Schreibaktivität auf der Datenbank auch bei einem unerwarteten Ausfall (Stromausfall, Hardwaredefekt, Bluescreen etc.) die Datenbank immer wieder in einen konsistenten Status gefahren werden.

Das Prinzip der Protokolldateien kennen aber auch andere Dienste: Auch das Active Directory von Windows 2000 nutzt die Technik. Die Datenbank heißt hier allerdings NTDS.DIT und die Protokolldateien sind 10 Megabyte groß. Auch der Exchange 2000 SRS nutzt die gleiche Technik um für die Exchange 5.5. Server eine alte DIR.EDB zu simulieren. Ein SQL-Server nutzt ähnliche Techniken

Transaktionsdateien

Exchange 2007 nutzt bis zu 2 Milliarden Protokolldateien a 1 Megabyte

Die Transaktionsdateien sind die Dateien, in denen Exchange die Änderungen protokolliert. Sie werden immer weiter geschrieben und erst durch ein erfolgreiches Online Backup gelöscht.

Exchange 5.5 pflegt zwei eigene Sätze von Transaktionsdateien. Die Verzeichnisdatenbank DIR.EDB wird durch eigene Protokolldateien gesichert, während der Store für die PRIV.EDB und PUB.EDB einen zweiten Satz Protokolldateien pflegt. Exchange 2000 hingegen überlässt dem Active Directory die Sicherung des Verzeichnisdienstes (NTDS.DIT und die dazugehörigen Protokolldateien) und gruppiert nun bis zu fünf Datenbank je Speichergruppe und bis zu vier Speichergruppen pro Server. Je Speichergruppe wird ein eigener Satz Protokolldateien gepflegt.

Exchange ist also dann besonders schnell, wenn die Platte mit den Transaktionsdateien sonst nichts macht, damit keine Zeit durch Warten auf den Abschluss anderer Dateioperationen oder Kopfpositionierung verloren geht. Allerdings sollten Sie auf dem Pfad zu diesem Speicherplatz den Schreibcache deaktivieren, damit bei einem Stromausfall auch wirklich alle Schreibbefehle bis dahin ausgeführt wurde. Oder ihr RAID-Controller hat ein "Battery Backup" und Sie wissen , welche Schritte sie beachten müssen, damit diese Informationen beim erneuten Start noch weg geschrieben werden.

Diese Dateien enthalten die Änderungen der Datenbank seit dem letzten Vollbackup. Zwar sind die meisten Änderungen auch schon in der Datenbank enthalten, aber  wenn diese korrupt oder verloren gegangen ist, dann können Sie einfach die Version der Datenbank vom letzten Backup einspielen und wenn ihre Transaktionsprotokolle noch alle vorhanden sind, werden die Änderungen nachgezogen (Roll Forward). Es ist daher auch aus Gründen der Datensicherheit interessant, die Transaktionsdateien auf eine eigene Festplatte zu legen. Beim Restore wird übrigens auch die EDB.CHK-Datei wieder überschrieben, so dass  Exchange wieder am Anfang des Backups startet.

Die "Transaktionsprotokolle" heißen immer EDB*.LOG und sind 5 Megabyte (1Mbyte bei Exchange 2007)  groß sind. Es wird immer in die EDB.LOG geschrieben und wenn diese voll ist, wies sie umbenannt und eine neue Datei angelegt. Damit Exchange eine Chance hat, sich ordentlich zu beenden, gibt es eine res1.log und res2.log, die im Falle von Platznot für das Herunterfahren genutzt werden.

Die Protokolldateien werden durch ein erfolgreichen Online-Backup abgeschnitten.

1.048.575 Protokolldateien

Die Namensgebung der Protokolldateien ist seit Exchange 4.0 bis Exchange 2003 identisch. Der Name hält sich an die 8.3 Konvention und beginnt bei E0000000.LOG und l���uft bis E00FFFEF.LOG. Die letzte Protokolldatei wird nicht mehr umbenannt und bleibt als E00.LOG bestehen.

Das bedeutet aber auch, dass Exchange maximal 1048575 Protokolldateien a 5 Megabyte pro Speichergruppe anlegen kann. Auf Servern mit sehr viel Änderungen  (>5 Terabyte) in den Datenbanken kann es daher tatsächlich passieren, dass die Protokolldateien am Ende ankommen. Mit solch großen Datenmengen hat 1995 natürlich niemand gerechnet, so dass erst mit Exchange 2003 SP1 und Exchange 2000 PostSP3 ein Patch existiert, damit sich die Datenbank wenigstens sauber herunter fährt. Als Admin müssen Sie dann natürlich immer noch die Datenbank auf den "Clean Shutdown" überprüfen (siehe Der Einsatz von ESEUTIL und ESEFILE), die Protokolldateien löschen und die Datenbank starten, so dass Exchange wieder bei E0000000.LOG anfängt.

Für Exchange 2007 ist angekündigt, dass die Protokolldateien nun 8-stellige Bezeichnungen verwenden. Damit können  2147483647 Protokolldateien a 1 Megabyte, also insgesamt 2.500 Terabyte Änderungen pro Speichergruppe möglich sein.

Normalerweise sollte ein durchschnittlicher Server jahrelang ohne Probleme damit arbeiten können und die meisten Server, mit denen ich bislang zu tun hatten, haben kaum eine E004xxxx.LOG überschritten. Aber da das Risiko vorhanden ist, sollten Sie natürlich speziell große Server mit viel Datenumschlag überwachen und bei Connectorserver die Umlaufprotokollierung einschalten.

Wenn Sie für Testzwecke diesen Fall einmal forcieren wollen, dann können Sie mit ADSIEDIT auf den Eigenschaften der Speichergruppe die Größe der Logfiles im Feld "msExchESEParamLogFileSize" auf kleinere Werte setzen (Default ist 5120 = 5 MB), damit Exchange entsprechend kleinere Logfiles anlegt.

Eine Überwachung ist dennoch ratsam. Der Exchange Server Analyser prüft z.B. den Inhalt des Feld "msExchESEParamLogFilePath" für jede Speichergruppe und generiert ab 950000 (E7EF0) Protokolldateien eine Warnung und ab 1,020,000 (F9060) einen Fehler. Sie haben dann immer noch 28575 Protokolldateien (oder ca. 139 Gigabyte Änderungen) Zeit für Gegenmaßnahmen.

Umlaufprotokollierung

Exchange bietet die Möglichkeit, die so genannte Datenbankumlaufprotokollierung (Circular Logging) zu aktivieren. Bei Exchange 5.5. ist diese per Default aktiv, während Exchange 2000 diese per Default nicht aktiv hat. Damit hat sich Microsoft zugunsten der Betriebssicherheit und der Möglichkeiten eines "Rollforward" entschieden und gegen "Plug and Play". Ich erwarte schon die ersten Hilferufe in der Newsgroup, wenn ein Server mangels Platz nicht mehr funktioniert. Die Antwort ist ganz einfach: "Nutzen Sie ein ordentliches Onlinebackup".

Die Umlaufprotokollierung hat nur das Ziel, das Vollaufen einer Festplatte und den Platzbedarf durch Transaktionsprotokolle zu verhindern. Exchange legt dann nur fünf Protokolldateien an. Demnach kann er im Cache auch nie mehr als die 5x5 Megabyte Änderungen halten. Wenn demnach sehr viele Änderungen an der Datenbank erforderlich sind und damit die Transaktionsprotokolle voll sind, dann wird Exchange die Verarbeitung neuer Änderungen drosseln und ist gezwungen, die Datenbank zu aktualisieren. Die Performance ist dann natürlich reduziert. Ansonsten kann Exchange viel mehr Transaktionen "ausstehen" haben, die nur in den Transaktionsdateien und im Datenbankcache (RAM) stehen. So oder so bleibt Exchange bei seiner "transaktionsorientierten" Datenbankverwaltung, die die Konsistenz der Datenbank in jedem Falle sichert.

Insofern hilft die Umlaufprotokollierung dabei, den Speicherplatz auf der Festplatte zu beschränken. Der Preis dafür ist aber, dass bei einem Ausfall der Datenbank kein Roll Forward möglich ist, d.h. Sie nur noch das letzte Backup restaurieren aber nicht mehr fortschreiben können. Praktisch bedeutet dies: Wenn Sie um 22:00 Uhr sichern und am tag drauf fällt ihr Server mit 26 MByte Änderungen gegen 16:00 Uhr aus, dann sind alle Änderungen des Tages hinfällig.

Eine Besonderheit ist Exchange 2000. Hier sind die Transaktionsprotokolle pro Speichergruppe, so dass mehrere Datenbanken (Bis zu fünf) gemeinsame Protokolldateien nutzen, wird aber nur eine Datenbank dismounted, dann wird die Umlaufprotokollierung außer Betrieb gesetzt, wenn sonst würden ja offene Transaktionen für diese Datenbank überschrieben. Das sollten Sie aber wissen, da sonst ihr Server schnell wieder voll ist. Es bietet sich an, die freie Festplattenkapazität mit in die Überwachung des Servers mit aufzunehmen.

Die Datenbanken

Die Datenbank von Exchange 5.5 besteht eigentlich aus drei Dateien. 

Zusätzlich gibt es  jede Menge anderer Dateien, die Exchange nutzt. Der MTA nutzt ebenso wie der IMC das Dateisystem teilweise zur Ablage von temporären Daten.

Mit Exchange 2000 ändert sich diese Datenbank, um den gestiegenen Anforderungen gerecht zu werden.

Mit Exchange 2007 ändert sich diese Datenbank erneut:

16 GB / 75 GB Limit

Leider hat Microsoft die Datenbanken in der Größe beschränkt. Die Standard Version von Exchange hat bis Exchange 2003 SP1 inklusive ein Limit von 16 Gigabyte. Die Enterprise Version ist bei 8000 Gigabyte (8TB) pro Datenbank beschränkt, wie folgende Eventlogmeldung auch aussagt:

Update: Exchange 2003 SP2 erlaubt auch in der Standardversion die Erweiterung auf bis zu 75 GByte. Allerdings werden Sie dazu einen Registrierungsschlüssel ("Database Size Limit in GB") setzen müssen.

 Nur sind die Aussagen nicht immer identisch, worauf sich das Limit in Wirklichkeit bezieht. Folgende Tabelle gibt meinen Kenntnisstand wieder,  wobei ich nicht alle Kombinationen getestet habe:

Server Postfachspeicher Public Folder Speicher
Exchange 5.5 Standard 1x 16 GB 1x 16 GB !
Exchange 5.5 Enterprise 1x 8 TB 1x 8 TB
Exchange 2000 Standard 1x 16 GB (erweiterbar auf 17 GB mit Registrykey) (16 Gb) 1x 16 GB  !
Exchange 2000 Enterprise 4 Speichergruppen a max. 5 Datenbanken (8 TB) 1x 8 TB
Exchange 2003 Standard 1x 16 GB (erweiterbar auf 17 GB mit Registrykey) (16 Gb) 1x 16 GB  !
Exchange 2003 Standard SP2 1x 18 GB (erweiterbar auf 75 GB mit Registrykey (16 Gb) 1x 18 GB
Erweiterbar auf 75GB
Exchange 2003 Enterprise 4 Speichergruppen a max. 5 Datenbanken (16 TB) 1x 8 TB
Exchange 2003 Enterprise SP2 4 Speichergruppen a max. 5 Datenbanken (16 TB)
Per Registrierung auch beschränkbar !!
1x 8 TB

Achtung:
Einige Quellen nennen 16 TB als Obergrenze für eine Postfachdatenbank. Das kann ich nicht bestätigen. Ein Exchange 2003 SP2 Enterprise Server meldet ohne Beschränkung 8000GB als maximale Größe:

Allerdings sind natürlich auch dies im Jahr 2006 noch theoretische Grenzen, da eine Datenbank dieser Größe nicht betrieben werden sollte. Die Sicherungszeit und vor allem Wiederherstellungszeit ist jenseits von allen wünschenswerten Grenzen.

Selbst die Aussagen von Microsoft sind hier nicht eindeutig, wie verschiedene TechNet Artikel belegen.

EventLog: ESE, 445
Information Store (4664) Die Datenbank E:\Exchsrvr\mdbdata\pub1.edb hat die maximale Datenbankgröße von 16383 MB erreicht. Wenn die Datenbank nicht neu gestartet werden kann, muss möglicherweise eine Offlinedefragmentierung durchgeführt werden, um ihre Größe zu verringern.

Sie können aber davon ausgehen, dass eine Exchange Standard Version immer ein Limit des Postfachspeichers auf 16 GB hat. Ob die öffentlichen Ordner auch beschränkt sind, habe ich selbst nicht verifiziert. Nur die Enterprise Version ist daher nach heutigen Maßstäben unbeschränkt, da das nächste Limit bei 8 Terabyte liegt. Dies finden Sie beim Enterprise Server auch im Eventlog

Unabhängig von der notwendigen Hardware dürfte die zeitgemäße Sicherung und Wiederherstellung solcher Daten noch einige Zeit benötigen. Hier sind dann mehrere Server besser einzusetzen.

Die einzelnen Dateien

Aber auch bei mittleren Servern sollten Sie die Anforderungen der Datenbank an das Festplattensystem kennen, um im Hinblick auf Geschwindigkeit eine Optimierung zu erreichen.

Datenbankdatei Name Funktion
Datenbanken *.EDB In dieser Datenbank stehen alle Objekte in 4kByte Seiten. Die Datei ist nur dann konsistent, wenn alle Transaktionen aus den Protokolldateien verarbeitet wurden. (Also nur wenn Exchange sauber beendet wurde.)
Streaming Speicher *.STM Diese Dateien gibt es erst seit Exchange Server 2000 und enthalten den unveränderten MIME Inhalt der Nachrichten von Internet Clients.

Die Struktur besteht aus 4k Seiten in 64kByte Blöcken, die typischerweise mit vielen 64k Zugriffen verwendet werden. Das ist z.B. wichtig für die Festlegung der Größe des Stripe eines Raidcontrollers.

Dateien für die Protokolle der  Transaktionen E0n.LOG
E0nxxxxx*.LOG
Jeweils 5 Megabyte Dateien, in denen die Transaktionen protokolliert werden, d.h. alle Veränderungen währen der Laufzeit.

Diese Dateien sind für alle Fälle einer Wiederherstellung notwendig.

Patchdatei *.PAT Werden während der Datensicherung erstellt und enthalten die Seiten der Datenbank, die während der Sicherung verändert wurden.

Sie sind zum Restore unbedingt notwendig. Siehe auch Backup

Checkpoint Datei *.CHK Die Checkpoint Datei enthält die Information, wie weit die Transaktionsprotokolle schon in die Datenbank übernommen wurden. Ohne diese Datei durchläuft Exchange beim Start alle LOG-Dateien bis es an die Stelle kommt.

Um dem gewachsenen Bedarf nach Speicherplatz nachkommen zu können, sind mit dem Exchange 2000 Enterpriseserver mehrere Datenbanken je Server möglich. Damit kann eine Datenbank kleiner sein und auch einzeln gesichert, restauriert und überprüft werden. Nur so kann eine entsprechend kurz gefasste Wiederherstellungszeit eingehalten werden.

Alle Dateien sind mit Prüfsummern, Versionsnummern und anderen Dingen "gestempelt", so dass der Store immer feststellen kann, ob die Dateien korrekt und die richtige Version sind. Siehe auch -1018 Fehler Ursache und Lösung.

Datenzugriffe

Wenn Sie die Zugriffe auf die verschiedenen Datenbankdateien kennen, dann haben Sie auch die besten Voraussetzungen für eine effektive Planung und Partitionierung ihres Servers

Datenbankteil Design-Empfehlungen
Transaktionsprotokolle der Speichergruppe Sequentieller Zugriff (sequential IP)

Dedizierte RAID1 oder RAID 0-1 Arrays je Speichergruppe

Objektspeicher (*.EDB) kleiner wahlfreier Zugriff (Random I/O (4KB))

Dedizierte RAID1, 0+1, oder 5 Arrays je Speichergruppe. Je nach Last kann dieser Bereich mit dem Streaming Speicher kombiniert werden bzw. Sollte eine Speichergruppe mehrere EDB-Dateien enthalten, die auf getrennten Subsystemen liegen (bis zu 5 je Speichergruppe möglich)

Streaming Store (*.STM) Große wahlfreie Zugriffe (Random I/O (64KB))

Dedizierte RAID1, 0+1, oder 5 Arrays je Speichergruppe. Je nach Last kann dieser Bereich mit den Objektspeicher (*.EDB) kombiniert werden bzw.

Sie finden unter Sizing eines Exchange Server einige konkrete Werte und Gedanken, wie Sie einen Server planen und aufbauen könnten.

Backup und Restore

Aufgrund dieser Funktionsweise bedeutet dies auch eine besondere Behandlung für die Datensicherung und Rücksicherung. Die Dateien sind permanent offen und nur über entsprechende API's kann der Exchange Server gesichert werden. Dies ist auch notwendig, da nur ein Signal an den Exchange Server ihn veranlaßt, die Transaktionsdateien zu löschen. Dies ist aber notwendig, um wieder Festplattenplatz zu gewinnen.

Weitergehende Informationen zur Sicherung und Wiederherstellung der Datenbank finden Sie beim Thema  Backup und Restore.

Single Instance Store

Die Exchange Datenbank pflegt einen so genannten "Single Instance Store", d.h. eine Mail an mehrere Anwender wird nur einmal physikalisch in der Datenbank abgelegt. Dies spart gehörig Platz.

Mit Exchange 2000 ist dieser Store immer noch vorhanden, allerdings nur innerhalb einer Datenbank. Eine Nachricht an Empfänger in verschiedenen Speichergruppen wird daher in jeder Datenbank einmal angelegt. Insofern ist bei der Aufteilung der Personen auf Datenbanken auch dieser Aspekt zu beachten.

Exchange 2007 nutzt einen Single Instance Store nur noch für die Anlagen aber nicht mehr für den Message Body

Exchange 2010 nutzt gar keinen Single Instance Store mehr

Übrigens gibt es noch andere Dienste, die eine solche Zusammenfassung redundanter Daten vornehmen, siehe Q299726 The Single Instance Storage Filter and Groveler Service.

Checkpoint Depth

Nun kann man den Exchange Server hat mit vielen Daten (z.B. Migration von Benutzern, viele neue Mails etc.) dazu bringen, sehr viele Daten in kurzer Zeit "einzubuchen". Natürlich wird Exchange zuerst die Änderungen der Datenbank in die LOG-Dateien und in den Hauptspeicher schreiben. Nach einiger Zeit wird Exchange aber die Zugriffe ausbremsen, um die "Dirty Pages" der Datenbank auch in die EDB-Datei zu übertragen. Dies passiert per Default nach 20 Megabyte.

Der Exchange Server schreibt die Änderungen in der EDB-Seite des Hauptspeichers nach maximal 4 (Exchange 20007/2003) oder 20 (Exchange 2007) Logdateien. Das ist eine gute Mischung zwischen "Entzerrung" und Aktualität. Wenn wenn die EDB-Datei zu weit nachhängt, dann verlängert das z.B.: die Neustartzeit bei einem Ausfall oder das Herunterfahren bzw. ein Failover bei einem Cluster.

Defragmentierung und Checks

Exchange 2000 erweitert die Datenbank immer in 1 Megabyte schritten. Damit kann der Administrator sehr einfach die tatsächliche Größe der Datenbank (Dateigröße) erkennen. Problem dabei ist aber, dass die Datenbankdatei dann sehr fragmentiert wird. Daher wurde dieses Verhalten beim SP1 derart geändert, dass Exchange 2000 nun 16 Megabyte Schritte belegt. (siehe Q283691 XADM: Store Backup Runs More Slowly as Database Becomes Fragment)

Es gibt eigentlich keine regelmäßigen Checks oder Arbeiten, die man einer Exchange Datenbank zukommen lassen muss, wenn man mal davon absieht, dass die Hardware ohne Zweifel sein sollte und ein Online-Backup die Datenbank sichern kann. Exchange hat jede Datenbank mit Prüfsummen gesichert, so dass Korruptionen sehr schnell erkannt werden. Wenn sich jedoch ein Fehler eingeschlichen hat, dann gibt es Kommandozeilenprogramme wie ESEUTIL und ESEFILE, die weiter helfen.

Plötzliches Wachstum

Sehr oft bemerken Administratoren, dass die Datenbank sehr schnell anwächst und fragen, wie dies geschehen kann. Dies kann mehrere Gründe haben.

Wenn die Datenbank so groß ist, dann heißt die nächste Frage: "Wie groß ist die Datenbank wirklich und wie bekomme ich sie wieder klein" ?. Ehe Sie an eine Verkleinerung gehen sollten Sie wissen, was eine Offline-Verkleinerung bringen kann. Eine Exchange Datenbank kann nämlich nur durch eine komplette Reorganisation verkleinert werde. Diese bedeutet aber, dass ihre Exchange Funktion für einige Stunden nicht verfügbar ist.

Der beste Weg dies heraus zu finden ist ein Blick in das Eventlog des Servers. Normalerweise wird jede Nacht eine "Online Defragmentierung" durchgeführt, bei der freie Blöcke zusammengefasst werden. Das Ergebnis dieser Aktion ist im Eventlog zu sehen:

Eine Offline Defragmentierung würde die Datenbank also um maximal 489 Megabyte schrumpfen. Das hört sich viel an, aber selbst einer eine Datenbankgröße von 8 GByte sind das etwas mehr als 5%. Es ist fraglich,  ob für diesen Gewinn der Exchange Server für einige Stunden "Offline" sein soll. Zumal Exchange die Datenbank dann doch wieder bei den nächsten Mails relativ "aufwändig" vergrößern muss.

Aber vielleicht können Sie ja noch mehr gewinnen, wenn die unerwünschten Daten noch in der Datenbank sind und von Exchange noch nicht freigegeben werden:

Wichtigstes Kriterium ist wirklich der innerhalb der Exchange Datenbank freie Platz und eine Abwägung, ob eine Offline Defragmentierung wirklich sinnvoll ist.

Weitere Links

HKLM\SYSTEM\CurrentControlSet\Services\ESE\Performance\Show Advanced Counters: DWORD = 1

Tags:Datenbank Basics Transaktionsprotokolle CircularLogging