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 ?

Diese Seite geht aktuell noch nicht auf Änderungen mit Exchange 2007 und neuer ein. Insbesondere die Größe einer Datenbank ist nun bei 1 TB und kann per Regedit beim Enterprise Server weiter angehoben werden. Siehe ExchangeDB 1TB Limit

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 können 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.

  • XADM: Cannot Mount Database Because of Corrupted Transaction Log (Q301438)
  • 812592 How and when to manipulate Exchange transaction logs in disaster recovery
  • 296788 Offline backup and restore procedures für Exchange
  • 296787 XADM: Offline backup and restore procedures für Exchange Server 4.0, 5.0, and 5.5
  • 301438 You cannot mount a database because there is a corrupted transaction log in Exchange 2000
  • 271987 Overview of Exchange database architecture and engine
  • Exchange Server 2007 SP1 ESE Changes - Part 1
    http://blogs.technet.com/b/exchange/archive/2007/11/30/447640.aspx

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 MB Ä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. 

  • PRIV.EDB
    enthält sämtliche Nachrichten aller Postfächer. 
  • PUB.EDB
     enthält alle öffentlicher Ordner, von denen ein Replikation auf diesem Server liegt.
  • DIR.EDB
    Enthält das Verzeichnis von Exchange 5.5. Hierin stehen die gesamten Konfigurationsdaten von Exchange, die Benutzer und alle Parameter, die Exchange so verwaltet.

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.

  • Keine DIR.EDB,
    da die Funktion nun durch das Active Directory übernommen wird. Die Datei dir.edb ist komplett entfallen. Alle Informationen werden nun im Active Directory abgelegt.
  • EDB und zusätzlich STM-Dateien
    Aus den Datenbanken werden nun je zwei Dateien. Zur EDB-Datei gesellt sich eine STM-Datei hinzu, welche Streaming Daten direkt speichert und nicht mehr in 8-bit MAPI umwandelt, was doch sehr rechenintensiv war. So können nun auch streaming Daten direkt aus dem Store am Client abgespielt werden, z.B. Sprachnachrichten etc.
    Der Informationsspeicher besteht aber immer aus beiden Daten. Die EDB und STM Datei gehören untrennbar zusammen und können weder getrennt genutzt noch von unterschiedlichen Versionsständen gestartet werden.
  • Mehrere Datenbanken EDB/STM
    Exchange 2000 Enterprise erlaubt zusätzlich auch die Anlage mehrerer Speichergruppen und Datenbanken um die Last der Datenzugriffe auf mehrere Festplatten zu verteilen, verschiedene Service Level Agreements (SLA) zu erlauben etc.

Mit Exchange 2007 ändert sich diese Datenbank erneut:

  • Wegfall der STM-Datei
  • Protokolldateien mit 1 Megabyte aber dafür bis zu 2 Milliarden
  • Datenbank Pagesize 8k (statt 4k)

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.

  • Aussage einer telefonischen Auskunft bei Microsoft (Anfang 2005)
    Exchange 2000: 16GB-Grenze gilt nur für Postfächer.
    Exchange 2000: öffentliche Ordner sind nicht beschränkt
    Dem widerspricht aber folgende Eventlog Meldung, die sehr wohl ein Limit von 16 GB aufzeigt:
EventLog: ESE, 445
Information Store (4664) Die Datenbank E:\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 können, 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 können, 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.

  • Viele Nachrichten wurden übertragen
    Das ist an sich nicht schlecht und eher ein Zeichen, dass ihr Exchange Server genutzt wird. Es kann aber auch eine Fehlbedienung durch Anwender vorliegen, die sehr große Anlagen ohne Überlegung versenden. Nutzen Sie das Nachrichtentracking, um solchen Nachrichten auf die Schliche zu kommen. Ebenso können Sie die Größe der Postfächer z.B.: mit EXMERGE oder dem Exchange System Manager anzeigen lassen. Das hilft natürlich nur, wenn Sie auch die Größen der vergangenen Wochen sich mal notiert haben, um eine Veränderung zu sehen.
  • Wurm und Virus
    Oft ist es gar nicht der Anwender, der bewusst solche Mails versendet. Prüfen Sie ihr Netzwerk, Clients und Server auf Viren. Sie sollten nie einen Exchange Server ohne Virenschutz betreiben. EICAR ist ein Testvirus, um die prinzipielle Funktion zu prüfen.
  • Offenes Relay
    Alle Nachrichten, die durch den MTA oder die Routing Engine gehen, gehen auch durch das Exchange Postfach und belegen zumindest temporär Platz. Auch wenn der Platz schon wieder freigegeben ist, so wird die Datenbank nicht mehr kleiner. Kontrollieren Sie anhand der Protokolldateien des SMTP-Servers und des Nachrichtentracking eventuellen Missbrauch.
  • Backup/Antivirus Software hat die Datenbank beschädigt
    Selten aber auch manchmal das Problem, dass eine Antivirus Software oder eine Datensicherung die Datenbank aufbläht. Besonders sind z.B. Sicherungen beliebt, die einzelne Elemente sichern (BrickLevel, Single Item Backup etc.). Das ist natürlich keine Sicherung aber erlaubt die Wiederherstellung von einzelnen oder vielen Nachrichten. Leider geht dabei der "Single Instance Store" verloren, so dass eine so restaurierte Datenbank viel größer ist, als das Original. Ein "Verkleinern" ist in diesem Fall aber nicht möglich.
  • Postfächer wurden migriert, öffentlichen Ordner repliziert
    Gerade bei der Migration von Postfächern von einem Server oder einem fremden Mailsystem auf den fraglichen Server wächst natürlich die Datenbank sehr schnell. Dieses Wachstum können sie leicht vorhersehen. Aber durch diese Aktion werden auch die Transaktionsprotokolle auf dem Server ebenso stark wachsen. Diese werden in der Regel erst beim nächsten Backup wieder abgeschnitten. Hier hilft dann z.B. ein Zwischenbackup, um wieder Platz frei zu geben.

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:

  • Gute Daten brauchen Platz
    Wenn ihre Datenbank gewachsen ist, weil sinnvolle und erwünschte Daten darin gespeichert wurden, dann brauchen Sie nicht weiter zu lesen. Dann können Sie die Datenbank selbstverständlich nicht kleiner machen, es sei denn Sie Löschen oder Archivieren Daten auf ein anderes Medium.
  • Temporäre Daten
    Wenn das Wachstum aufgrund temporärer Daten erfolgt ist, die schon wieder gelöscht wurden, dann sind die Datenbankseiten schon wieder freigegeben
  • Unerwünschte Nachrichten gelöscht
    Wenn das Wachstum aufgrund eines Virus, einer Mailschleife (Loop) oder durch Anwender verursacht wurden, dann müssen Sie diese Mails erst löschen. Das einfache Löschen hält die Nachrichten bei Exchange aber noch im Papierkorb bzw. im Superpapierkorb. Exchange gibt die Daten erst frei, wenn die Verfallszeit abgelaufen ist.

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