Informationen zur Transaktionsprotokollierung

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2007-08-30

In diesem Thema werden die Einzelheiten der Transaktionsprotokollierung in Microsoft Exchange Server 2007 beschreiben. Es enthält außerdem eine kurze Beschreibung der Umlaufprotokollierung.

Die Exchange Server-Transaktionsprotokollierung ist ein robuster Wiederherstellungsmechanismus von ESE (Extensible Storage Engine), der eine Exchange-Datenbank nach einer abrupten Beendigung der Datenbank zuverlässig in einem konsistenten Zustand wiederherstellt. Der Protokollierungsmechanismus wird auch beim Wiederherstellen von Onlinesicherungen verwendet. 

Exchange-Transaktionsprotokollierung

Bevor Änderungen an einer Exchange-Datenbankdatei vorgenommen werden, schreibt Exchange die Änderungen in eine Transaktionsprotokolldatei. Nachdem die Änderungen sicher protokolliert wurden, können sie in die Datenbankdatei geschrieben werden. Im Allgemeinen werden diese Änderungen für Endbenutzer unmittelbar nach dem Sichern im Transaktionsprotokoll, jedoch bevor sie in die Datenbankdatei geschrieben wurden, verfügbar.

Exchange verwendet ein hochentwickeltes internes Speicherverwaltungssystem, das für hohe Leistung optimiert ist und die Zwischenspeicherung von Dutzenden von GB an Datenbankseiten verwalten kann. Aus diesem Grund ist der physikalische Schreibvorgang in die Datenbankdatei während des normalen Betriebs eine Aufgabe mit niedriger Priorität.

Wenn eine Datenbank unerwartet beendet wird, gehen die zwischengespeicherten Änderungen nicht einfach verloren, nur weil der Speichercache zerstört wurde. Wenn die Datenbank neu gestartet wird, durchsucht Exchange die Protokolldateien und rekonstruiert und übernimmt alle Änderungen, die noch nicht in die Datenbankdatei geschrieben wurden. Dieser Vorgang wird als Wiedergabe der Protokolldateien bezeichnet. Die Datenbank ist so strukturiert, dass Exchange bestimmen kann, ob ein beliebiger Vorgang in einer beliebigen Protokolldatei bereits in die Datenbank übernommen wurde, in die Datenbank übernommen werden muss oder nicht zur Datenbank gehört.

Anstatt alle Protokollinformationen in eine einzige große Datei zu schreiben, verwendet Exchange eine Reihe von Protokolldateien, von denen jede genau ein MB (1.024 KB) groß ist. Wenn eine Protokolldatei voll ist, schließt Exchange diese und benennt sie unter Zuweisung einer Sequenzummer um. Das erste Protokoll, das gefüllt wird, endet mit dem Namen Enn00000001.log. Die Angabe nn bezieht sich auf eine zweistellige Zahl, die als Basisname oder Protokollpräfix bezeichnet wird.

Protokolldateien für einzelne Speichergruppen werden durch Dateinamen mit nummerierten Präfixen unterschieden (z. B. E00, E01, E02 oder E03). Die aktuell für eine Speichergruppe geöffnete Datei trägt einfach den Namen Enn.log – sie erhält erst eine Sequenznummer, nachdem sie mit Daten gefüllt und geschlossen wurde.

Die Prüfpunktdatei (Enn.chk) protokolliert, wie weit Exchange mit dem Schreiben der protokollierten Informationen in die Datenbankdateien fortgeschritten ist. Den einzelnen Protokolldatenströmen ist jeweils eine Prüfpunktdatei zugeordnet, und zu jeder Speichergruppe gehört ein separater Protokolldatenstrom. Innerhalb einer Speichergruppe verwenden alle Datenbanken einen Protokolldatenstrom gemeinsam. Aus diesem Grund enthält eine einzige Protokolldatei häufig Vorgänge für mehrere Datenbanken.

Protokolldateien werden hexadezimal nummeriert; die Datei nach der Datei E0000000009.log ist daher E000000000A.log, nicht E0000000010.log. Sie können die Sequenznummern der Protokolldateien in dezimale Werte umwandeln, indem Sie die Anwendung Windows-Rechner (Calc.exe) im Modus Wissenschaftlich verwenden. Führen Sie zu diesem Zweck Calc.exe aus, und klicken Sie dann im Menü Ansicht auf Wissenschaftlich.

Um die dezimale Sequenznummer für eine bestimmte Protokolldatei anzuzeigen, können Sie deren Kopfzeile mithilfe der Datenbankdienstprogramme für Exchange Server (Eseutil.exe) untersuchen. Die erste 4-KB-Seite jeder Protokolldatei enthält Kopfzeileninformationen, die die Protokolldatei und die Datenbanken, zu denen sie gehört, beschreiben und identifizieren. Der Befehl Eseutil /ml [Protokolldateiname] zeigt die Kopfzeileninformationen an. Weitere Informationen zu Eseutil finden Sie unter Eseutil.

Wenn Sie die falsche Option zum Anzeigen einer Kopfzeile verwenden (z. B. /ml mit einer Datenbankkopfzeile anstatt /mh), wird ein Fehler ausgegeben, oder die angezeigten Kopfzeileninformationen sind verstümmelt bzw. falsch.

Sie können die Kopfzeile einer Datenbank nicht anzeigen, während diese bereitgestellt ist. Sie können auch nicht die Kopfzeile der aktuellen Protokolldatei (Enn.log) anzeigen, während eine der Datenbanken in der Speichergruppe bereitgestellt ist. Exchange hält die aktuelle Protokolldatei geöffnet, solange eine Datenbank diese verwendet. Sie können jedoch die Kopfzeile der Prüfpunktdatei anzeigen, während Datenbanken bereitgestellt sind. Exchange aktualisiert die Prüfpunktdatei alle 30 Sekunden, und ihre Kopfzeile kann nur in dem Moment nicht angezeigt werden, in dem eine Aktualisierung auftritt.

Als Exchange-Administrator sollten Sie Exchange-Dateikopfzeilen verstehen. Wenn Sie die Dateikopfzeilen verstehen, können Sie bestimmen, welche Datenbank und Protokolldateien zusammengehören und welche Dateien für eine erfolgreiche Wiederherstellung erforderlich sind.

Beachten Sie im folgenden Beispiel für eine Protokolldatei-Kopfzeile die ersten vier Zeilen.

Base name: e00
Log file: e00.log
lGeneration: 11 (0xB)
Checkpoint: (0xB,7DC,6F)

Diese Zeilen der Protokolldatei-Kopfzeile zeigen, dass diese Protokolldatei die aktuelle Protokolldatei ist, weil der Protokolldateiname keine Sequenznummer aufweist. Die Zeile lGeneration zeigt, dass die Sequenznummer der Protokolldatei B (entsprechend dem dezimalen Wert 11) lauten wird, nachdem die Datei mit Daten gefüllt und geschlossen wurde. Der Basisname ist e00, daher lautet der endgültige Protokolldateiname E000000000B.log.

Der Wert Checkpoint im vorherigen Kopfzeilenbeispiel wird nicht tatsächlich aus der Protokolldatei-Kopfzeile gelesen, jedoch so angezeigt, als wäre dies der Fall. Eseutil.exe liest den Wert Checkpoint direkt aus Enn.chk. Sie müssen daher keinen separaten Befehl eingeben, um zu erfahren, wo sich die Prüfpunktdatei befindet. Wenn die Prüfpunktdatei zerstört wurde, wird für den Wert Checkpoint die Angabe NOT AVAILABLE angezeigt. In diesem Fall befindet sich der Prüfpunkt in der aktuellen Protokolldatei (0xB), und die Angaben 7DC und 6F zeigen an, an welcher Position der Protokolldatei sich der Prüfpunkt befindet. Beachten Sie, dass diese Informationen nur selten von praktischem Nutzen sind.

Wenn die Prüfpunktdatei zerstört wird, kann Exchange Protokolldateien trotzdem ordnungsgemäß wiederherstellen und wiedergeben. Zu diesem Zweck beginnt Exchange jedoch, Protokolldateien zu durchsuchen (beginnend mit der ältesten verfügbaren Datei), anstatt beim Prüfpunktprotokoll zu beginnen. Exchange überspringt Daten, die bereits in die Datenbank übernommen wurden, und arbeitet die Protokolle sequenziell ab, bis Daten gefunden werden, die übernommen werden müssen.

Normalerweise dauert es nur ein oder zwei Sekunden, bis Exchange eine Protokolldatei durchsucht hat, die bereits in die Datenbank übernommen wurde. Wenn eine Protokolldatei Vorgänge enthält, die in die Datenbank geschrieben werden müssen, kann deren Übernahme zwischen 10 Sekunden und mehreren Minuten dauern. Die Inhalte einer Protokolldatei werden durchschnittlich in maximal 30 Sekunden in die Datenbank geschrieben.

Wenn eine Exchange-Datenbank normal heruntergefahren wird, werden alle ausstehenden Daten in die Datenbankdateien geschrieben. Nach dem normalen Herunterfahren wird der Datenbankdateisatz als konsistent betrachtet, und Exchange trennt die Datenbank von ihrem Protokolldatenstrom. Dies bedeutet, dass die Datenbankdateien nun abgeschlossen sind – sie sind vollkommen aktuell. Die Transaktionsprotokolle sind zum Starten der Datenbankdateien nicht erforderlich.

Sie können feststellen, ob eine Datenbank ordnungsgemäß heruntergefahren wurde, indem Sie den Befehl Eseutil /mh ausführen und die Dateikopfzeilen untersuchen.

Wenn alle Datenbanken in einer Speichergruppe getrennt wurden und sich im Zustand Clean Shutdown befinden, können alle Protokolldateien sicher gelöscht werden, ohne dass negative Auswirkungen auf die Datenbanken eintreten können. Wenn Sie nun alle Protokolldateien löschen, generiert Exchange beginnend mit Enn00000001.log eine neue Sequenz von Protokollen. Sie könnten die Datenbankdateien sogar auf einen anderen Server oder in eine andere Speichergruppe mit vorhandenen Protokolldateien verschieben, und die Datenbanken würden sich an einen anderen Protokolldatenstrom anfügen.

Wenn sich eine Datenbank im Status Dirty Shutdown befindet, müssen alle vorhandenen Transaktionsprotokolle ab dem Prüfpunkt verfügbar sein, bevor Sie die Datenbank erneut bereitstellen können. Wenn diese Protokolle nicht verfügbar sind, müssen Sie die Datenbank reparieren, indem Sie den Befehl Eseutil /p ausführen, um einen konsistenten Zustand der Datenbank zu erzielen und ihre Startbereitschaft sicherzustellen.

Achtung:

Wenn Sie eine Datenbank reparieren müssen, gehen in der Regel einige Daten verloren. Die Datenverluste sind häufig nur sehr gering; sie können jedoch auch schwerwiegend sein. Nachdem Sie Eseutil /p für eine Datenbank ausgeführt haben, sollten Sie die Datenbank durch die folgenden beiden Maßnahmen vollständig reparieren: Führen Sie zuerst Eseutil/d aus, um die Datenbank zu defragmentieren. Durch diesen Vorgang werden alle Datenbankindizes und Speicherstrukturen gelöscht und anschließend neu erstellt. Führen Sie dann das Tool Isinteg.exe (Integritätsüberprüfung für den Informationsspeicher) im Modus –fix aus. Dieses Tool durchsucht die Datenbank nach logischen Inkonsistenzen, die durch das Löschen ausstehender Transaktionsprotokolle entstehen. Es können beispielsweise Verweise in der Datenbank vorhanden sein, die nicht aktuell sind. Isinteg.exe versucht, solche Probleme bei geringstmöglichem Datenverlust zu korrigieren.

Die Transaktionsprotokollierung ermöglicht nicht nur die zuverlässige Wiederherstellung von Exchange nach einer unerwarteten Datenbankunterbrechung, sondern ist auch für die Anfertigung und Wiederherstellung von Onlinesicherungen wesentlich. Weitere Informationen zum Anfertigen und Wiederherstellen von Onlinesicherungen finden Sie unter Sichern und Wiederherstellen von Datenbanken.

Umlaufprotokollierung

Diese Vorgehensweise wird zwar nicht als bewährte Methode empfohlen, Sie können jedoch Exchange zum Einsparen von Speicherplatz konfigurieren, indem Sie die Umlaufprotokollierung aktivieren. Anhand der Umlaufprotokollierung kann Exchange Transaktionsprotokolldateien überschreiben, nachdem die in den Protokolldateien enthaltenen Daten an die Datenbank übergeben wurden. Bei Aktivierung der Umlaufprotokollierung können Daten jedoch nur bis zur letzten vollständigen Sicherung wiederhergestellt werden.

Bei der Standardtransaktionsprotokollierung, die von Exchange 2007 verwendet wird, wird jede Datenbanktransaktion in einer Speichergruppe in eine Protokolldatei und dann in die Datenbank geschrieben. Wenn eine Protokolldatei eine Größe von einem MB erreicht, wird sie umbenannt, und eine neue Protokolldatei wird erstellt. Im Lauf der Zeit führt diese Vorgehensweise zu einer Sammlung von Protokolldateien. Wenn Exchange unerwartet beendet wird, können Sie die Transaktionen wiederherstellen, indem Sie die Daten aus diesen Protokolldateien in die Datenbank wiedergeben. Bei der Umlaufprotokollierung wird die erste Protokolldatei überschrieben und wiederverwendet, wenn die darin enthaltenen Dateien in die Datenbank geschrieben wurden.

In Exchange 2007 ist die Umlaufprotokollierung standardmäßig deaktiviert. Durch Aktivieren der Umlaufprotokollierung senken Sie die Anforderungen an den Speicherplatz auf den Laufwerken. Ohne einen vollständigen Satz von Transaktionsprotokolldateien können jedoch Daten, die über die letzte vollständige Sicherung hinausgehen, nicht wiederhergestellt werden. Daher ist die Umlaufprotokollierung in einer normalen Produktionsumgebung nicht empfehlenswert.

Weitere Informationen zum Aktivieren bzw. Deaktivieren der Umlaufprotokollierung in Exchange 2007 finden Sie unter Aktivieren oder Deaktivieren der Umlaufprotokollierung für eine Speichergruppe.

Fortlaufende Replikation und Umlaufprotokollierung

Sie können die Umlaufprotokollierung mit der fortlaufenden Replikation kombinieren. In dieser Konfiguration gibt es einen neuen Typ der Umlaufprotokollierung mit der Bezeichnung CRCL (Continuous Replication Circular Logging, Umlaufprotokollierung bei fortlaufender Replikation), die sich von der ESE-Umlaufprotokollierung wie an früherer Stelle in diesem Thema erörtert unterscheidet. Im Gegensatz zur ESE-Umlaufprotokollierung, die vom Microsoft Exchange-Informationsspeicherdienst ausgeführt und verwaltet wird, wird CRCL vom Microsoft Exchange-Replikationsdienst ausgeführt und verwaltet.

Wenn aktiviert, generiert die ESE-Umlaufprotokollierung keine zusätzlichen Protokolldateien und überschreibt stattdessen im Bedarfsfall die aktuelle Protokolldatei. Allerdings werden in einer Umgebung mit fortlaufender Replikation Protokolldateien für den Protokollversand und die Protokollwiedergabe benötigt. Dementsprechend wird, wenn Sie CRCL aktivieren, die aktuelle Protokolldatei nicht überschrieben, und es werden geschlossene Protokolldateien für den Protokollversand- und -wiedergabeprozess generiert. Insbesondere der Microsoft Exchange-Replikationsdienst verwaltet CRCL so, dass die Protokollkontinuität beibehalten wird, und Protokolle werden von der Protokolllöschfunktion nicht gelöscht, wenn sie noch für die Replikation benötigt werden. Daher sollte die Aktivierung von CRCL keine negativen Auswirkungen auf die Replikation haben.

In der RTM-Version (Release to Manufacturing) von Exchange 2007 wird die Kombination der Umlaufprotokollierung mit der fortlaufender Clusterreplikation (CCR) oder der fortlaufenden lokalen Replikation (LCR) unterstützt. Dies ist jedoch nicht zu empfehlen, da in diesem Fall keine Wiedergabewiederherstellung möglich ist, nachdem eine Datensicherung wiederhergestellt wurde. In Exchange 2007 Service Pack 1 (SP1) kann auch für Speichergruppen in einer CCR-, LCR- oder SCR-Umgebung (Standby Continuous Replication, fortlaufende Standbyreplikation) die Umlaufprotokollierung aktiviert sein. Diese Vorgehensweise wird jedoch ebenfalls aus den vorstehend genannten Gründen nicht empfohlen. Bei Aktivierung in jeder dieser Umgebungen wird mit CRCL- und nicht mit ESE-Umlaufprotokollierung gearbeitet (auch als JET-Umlaufprotokollierung (Joint Engine Technology) bezeichnet). In einer CCR-, LCR- oder SCR-Umgebung sollten Sie immer gemäß dem nachstehenden Verfahren vorgehen, um die Umlaufprotokollierung zu aktivieren oder zu deaktivieren:

1. Halten Sie die fortlaufende Replikation mithilfe des Cmdlets Suspend-StorageGroupCopy an.

2. Aktivieren oder deaktivieren Sie die Umlaufprotokollierung. Ausführliche Anweisungen zum Aktivieren oder Deaktivieren der Umlaufprotokollierung finden Sie unter Aktivieren oder Deaktivieren der Umlaufprotokollierung für eine Speichergruppe.

3. Heben Sie die Bereitstellung der Datenbank in der Speichergruppe auf, die für die Umlaufprotokollierung aktiviert oder deaktiviert ist, und stellen Sie die Datenbank dann wieder bereit.

4. Setzen Sie die fortlaufende Replikation mithilfe des Cmdlets Resume-StorageGroupCopy fort.

Für Speichergruppen in einer LCR-Umgebung müssen Sie vor dem Ausführen des Cmdlets Enable-StorageGroupCopy zum Aktivieren von LCR für eine Speichergruppe sicherstellen, dass die aktuelle Einstellung für die Umlaufprotokollierung vom Microsoft Exchange-Informationsspeicherdienst erkannt und genutzt wird, indem Bereitstellung der Datenbank in der Speichergruppe aufgehoben und die Datenbank dann wieder bereitgestellt wird. Während der Microsoft Exchange-Informationsspeicherdienst voraussetzt, dass Sie die Bereitstellung der Datenbank aufheben und diese dann wieder bereitstellen, damit die Konfigurationsänderung erkannt und angewendet wird, ist der Microsoft Exchange-Replikationsdienst in der Lage, die Konfigurationsänderung dynamisch zu erkennen und ohne Neustart anzuwenden. Daher kann sich, wenn das vorstehende Verfahren nicht ausgeführt wird, für die Datenbank eine Situation ergeben, in der der Microsoft Exchange-Replikationsdienst davon ausgeht, dass die Umlaufprotokollierung deaktiviert (oder aktiviert) ist, während der Microsoft Exchange-Informationsspeicherdienst davon ausgeht, dass für die Umlaufprotokollierung genau der gegenteilige Status zutrifft. Dies kann dazu führen, dass Protokolldateien vorzeitig abgeschnitten werden.

Um die Anzahl der erstellten Transaktionsprotokolle unter Kontrolle zu halten, aktivieren Administratoren beim Verschieben großer Postfächer manchmal die Umlaufprotokollierung. Da es sich beim Verschieben von Postfächern um einen Vorgang handelt, der zwei unterschiedliche Datenbanken einbezieht, können Sie die Umlaufprotokollierung während des Verschiebens der Postfächer für beide Datenbanken aktivieren.

Sie können CRCL in CCR-, LCR- und SCR-Umgebungen beim Verschieben von Postfächern oder in anderen Szenarien aktivieren, in denen eine große Menge an Protokolldateien erstellt wird. Allerdings können Sie für die Zeit, in der CRCL aktiviert ist, keine Datensicherungen erstellen. Aus diesem Grund muss Folgendes sichergestellt sein:

• Das Verschieben von Postfächern wirkt sich nicht störend auf Datensicherungsvorgänge aus, denn wenn CRCL aktiviert ist, können Sie keine Datensicherungen durchführen.

• CRCL wird deaktiviert, nachdem das Verschieben der Postfächer abgeschlossen ist, sodass die Datensicherungen fortgesetzt werden können.