theoretisches zur Exchange Checkpoint Datei

[firefox80 10]

Hallo Leute!

 

Die Exchange Checkpoint Datei speichert ja, bis zu welchem Punkt genau die Transaktionsprotokolle schon in die Datenbank geschrieben wurden.

 

Wenn man die chk Datei löscht, kann man ja veranlassen, dass sämtliche Inhalte der Transaktionsprotokolle in die Datenbank geschrieben werden.

 

Jetzt meine Frage:

Was passiert mit dem Teil der Daten, der sich VOR dem Punkt der chk Datei befindet?

Sprich werden dann Daten doppelt in die Datenbank geschrieben?

Merkt das Exchange, dass die Daten schon abgearbeitet wurden? (Wenn es das könnte, bräuchte man ja keine chk Datei ... also eine dumme Frage)

 

Wäre toll wenn ihr mir bei dem Punkt etwas auf die Sprünge helfen könntet!

 

LG

FireFoX

[LukasB 10]

Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003

 

Wenn ich mir das so durchlese, scheint deine Theorie nicht ganz zu stimmen. Wenn es keine Checkpoint-Datei gibt, greift Exchange auf eine Recovery.env zurück - wenn es die auch nicht gibt, dann passiert garnix.

 

Wenn man jetzt aber falsche Werte in die Recovery.env schreiben würde, dann würde er höchstwahrscheinlich die Daten doppelt schreiben.

[firefox80 10]

In deinem Link lese ich:

If no checkpoint file exists, replay begins with the oldest log file available in the transaction log folder for the storage group.

 

Die Recovery.env wird doch nur nach einem Online Restore erzeugt?

 

Angenommen ich habe ein Offlinebackup der Datenbanken und alle nachfolgenden Log Files. Somit kann ich ja ein roll forward recovery vornehmen. Wenn ich Thomas Joos in seinem Kompendium richtig verstanden habe, muss dazu die chk Datei gelöscht werden. (Seite 583 ganz unten)

 

Also hab ich dann doppelte Mails in meinem Postfach?

 

LG

 

edit:

noch ein dazu passender Absatz aus deinem Link:

You cannot replay log files if the checkpoint file points to the wrong log. Exchange treats a checkpoint log as if it were the first log available and ignores all older log files. If you restore an older file copy of the database, the checkpoint will be too far ahead, and Exchange tries to start log file replay from a log file that is too new. You can solve this problem by removing the checkpoint file; thus forcing Exchange to scan all available logs. (If you restore an online backup, hard recovery ignores the checkpoint file.)

[erbachgeist 10]

ja genau so funktioniert es. Das Offline-backup zurückspielen und dann die Checkpoint-Datei löschen. Exchange geht dann alle Transaktionsprotokolle durch und schreibt diese in die Datenbank. Doppelte Mails werden dabei nicht erzeugt.

Die Datei restore.env wird durch die Datensicherung, bzw. -Wiederherstellung durch ein Backupprogramm erzeugt, wenn die Option "Letzter Sicherungssatz" gesetzt wurde.

rein theoretisch reicht auch eine leere neu angelegte Datenbank, zumindest dann wenn alle Transaktionsprotokolle noch da sind. Du brauchst halt die Protokolle exakt ab dem Moment auf den die Offline-Sicherung aufbaut. Doppelte mails kann es nicht geben, weil die Transaktionsprotokolle ja die neuen Mails und Änderungen integrieren, die noch nicht in der DB enthalten sind

 

Gruss

 

Thomas Joos

[firefox80 10]

Hallo Thomas!

 

Es ist eine Ehre, wenn man vom Autor selbst Unterstützung bekommt!

Dein Exchange Kompendium ist gut gelungen! (Dein MCSE Trainer hat mich aber nicht so begeistert, aber das ist ein anderes Thema)

 

Zurück zum Exchange:

Irgendwie geht mir der Knoten nicht auf...

 

Im Normalfall wird man ja einen Stand haben, bei dem die Log Files weiter zurückreichen als es dem Stand der Offline gesicherten Datenbank entspricht. Mir geht es genau um den Teil der Protokolle, vom 1. Log file bis zum Stand der Datenbank.

 

In meinen Google Recherchen habe ich 2 Ansätze gefunden (Leider die Links nicht notiert)

A: Exchange merkt beim Lesen der Logs, wieviel davon schon in der Datenbank ist. Erst Aktionen die sich zeitlich nach dem DB Stand befinden werden geschrieben. Die chk Datei ist rein aus Performance Gründen da, damit Exchange nicht immer alles durchsuchen muss.

 

B: In den Logs sind die Aufzeichnungen nicht nach Nachrichten organisiert, sondern nach binären Datenblöcken. (So ungefähr: schreibe die bytes 2745 ins Offset 72554) Demnach hätte man keinen Schaden, wenn ALLE Transaktionen nochmal abgespielt werden würden, da es ja zum gleichen Endstand führt.

 

Könntest du mir eine Theorie bestätigen bzw. korrigieren?

 

Besten Dank!

FireFoX

[erbachgeist 10]

Hallo firefox,

 

es freut mich, wenn mein Exchange-Kompendium für gelungen ist, es hat auch neben meiner Projekttätigkeit einiges an Anstrengung gekostet.

Ich finde auch den MCSE-Trainer gut, da es kein anderes Buch gibt in dem fast 1.100 Prüfungsrelevante Fragen mit Theorie und dem Aufbau einer Testumgebung erklärt wird. Ich würde auch gerne die Theorie noch erweitern, aber das ist erst für die Version Windows Server 2008 vom Verlag geplant.

 

Zu Deiner Frage:

Exchange arbeitet die Transaktionsprotokolle (ich nenne die jetzt einfach mal tp) nach und nach ab. tjp die abgearbeitet sind, werden in der CHK-Datei vermerkt, das findet parallel statt. Wird die CHK-Datei gelöscht, arbeitet Exchange die Transaktionsprotokolle noch mal von Anfang an ab, schreibt aber nichts in die DB was schon drin ist. Grundsätzlich unterscheiden sich Deine Theorien A und B nicht stark voneinander, beide haben richtige Teile, da bei beiden nicht doppelt geschrieben wird. Wichtig ist nur, dass man alle Transaktionsprotokolle lückenlos hat, nachdem die DB entweder online gesichert, oder heruntergefahren wurde, dann wird der Rest in die DB integriert.

 

Ein sehr interessanter Artikel zu dem Thema ist:

 

Offline Backup and Restoration Procedures for Exchange

 

Generell sollte man eine Exchange-DB täglich online sichern, dann hat man eigentlich keine Probleme. Wenn auffällt, dass die DB defekt ist, hat ja sowieso keiner mehr die TP. Eine defekte DB repariere ich eigentlich immer mit eseutil /d dann wird die DB repariert, leere Bereiche gelöscht und alles gleich defragmentiert.

 

Ich hoffe das schafft Klarheit. Hilfreich ist auch die Seite von Kollege Frank Carius, die erklärt das auch recht gut:

 

MSXFAQ.DE - Exchange Datenbank - ein Blick dahinter