Transaktionsprotokolle per ESEUTIL in die Datenbank schreiben

[Stonehedge 12]

Hallo Zusammen,

 

ich habe eine kurze Frage:

 

Ist es möglich die Transaktionsprotokolle per Eseutil, OHNE die Bereitstellung aufzuheben, in die Datenbank zu schreiben, um diese im Anschluss zu löschen?

 

Ich weiß, dass das kein guter Weg ist und diese eh beim nächsten Backup gelöscht werden, aber ich habe gerade eine kleine Diskussion, finde nur leider per google nichts genaueres. Will das nur klären.

 

Viele Grüße,

Stonehedge

[Dukel 436]

Wieso führst du kein Backup durch?

 

Ich wüsste nicht, dass Eseutil überhaupt die Protokolle in die DB Files schreibt.

[Stonehedge 12]

Hi,

 

keine Sorge ich will das Backup durchführen. Es geht mir nur generell um die Möglichkeit. Das Backup wird von einem Externen aufgrund von noch laufenden Verträgen durchgeführt und er kommt erst morgen dazu, das Backup einzurichten. Dieser meinte mir dann vorwerfen zu müssen, ich hätte keine Ahnung vom Betrieb eines Exchange-Servers, weil ich ja mit ESEUTIL und entsprechenden Parametern die Transaktionsprotokolle jederzeit entfernen könne.

 

How to remove Exchange Server transaction log files

 

Dort steht auch als erster Punkt "Bereitstellung aufheben" und dass das während der Geschäftszeiten nicht praktikabel ist, liegt ja auf der Hand.

[RobertWi 81]

Moin,

 

ESEUTIL ist ein Offline-Tool, nichts für den Online-Betrieb. Eine offizielle Lösung, die Log-Dateien online einzuarbeiten, ist nicht dokumentiert (darum sichern Backup-Programme ja auch noch die letzten Log-Dateien mit, sonst müssten sie das nicht).

 

Die simpelste Methode, die Log-Dateien einzuarbeiten, ist einfach die Bereitstellung der DB aufzuheben. Dabei werden die Log-Dateien eingearbeitet. ESEUTIL ist dann gar nicht mehr notwendig.

[NilsK 2.785]

Moin,

 

wozu würde man denn die "Transaktionsprotokolle einarbeiten" wollen? Und was sollte das überhaupt sein? Und warum sollte man die Transaktionsprotokolle entfernen wollen?

 

Ich denke, jemand, der sowas verlangt, hat das Prinzip der Transaktionsprotokollierung nicht verstanden. Du kannst dir ja mal sagen lassen, von welchen Parametern er denn da so redet.

 

Gruß, Nils

[Stonehedge 12]

Haha Super! Ich danke euch für die Antworten. Habe schon an mir gezweifelt. Allerdings glaube ich, dass ich mir nach Nils' Beitrag auch nochmal das Prinzip der Transaktionsprotokolle betrachten sollte. Eigtl bin ich davon ausgegangen, dass dort alle Änderungen seit dem letzten Vollbackup eingetragen sind und diese noch nicht zwingend alle in die Datenbank geschrieben wurden. Liege ich da falsch? Liege ich auch falsch, wenn ich annehme, dass die Performance leiden kann, wenn es sehr sehr viele Transaktionsprotokolle gibt?

[Dukel 436]

Transaktionen werden erstmal in die Protokolle geschrieben und dann nach und nach in die DB Files geschrieben. Das heisst nicht, dass alle Daten seit dem letzte Vollbackup nur in den Protokollen liegen. Diese Files liegen nur da und werden nur nach einem Vollbackup gelöscht, dass man diese als Sicherheit hat und einen Point-In-Time Restore durchführen kann.

[RobertWi 81]

Haha Super! Ich danke euch für die Antworten. Habe schon an mir gezweifelt. Allerdings glaube ich, dass ich mir nach Nils' Beitrag auch nochmal das Prinzip der Transaktionsprotokolle betrachten sollte. Eigtl bin ich davon ausgegangen, dass dort alle Änderungen seit dem letzten Vollbackup eingetragen sind und diese noch nicht zwingend alle in die Datenbank geschrieben wurden. Liege ich da falsch?

 

Jein.

 

Der Ablauf sieht wie folgt aus:

- Änderung passiert

- Seite aus der Datenbank in den Arbeitsspeicher laden

- Änderung als SQL-Befehle in die Log-Dateien eintragen

- Änderungen im Arbeitsspeicher machen

- JETZT: Anwender sieht die Änderung (darum ist es auch für die Performance wichtig, dass Log-Dateien schnell geschrieben werden können)

- (bei DAG nach dem Seeding: Änderung als SQL-Befehle an die passiven Knoten schicken)

- wenn Zeit ist oder die Datenbankbereitstellung aufgehoben wird oder nach einem Crash bei Neustart oder ESEUTIL: Log-Dateien in die Datenbank übernehmen

- bei einem Backup werden alle Log-Dateien, die bereits in der DB sind und (dessen Informationen bei DAG auf die passiven repliziert worden sind), abgeschnitten

 

Seit 2010 wird auch abgewartet, bis eine gewisse Änderungsmenge vorhanden ist, bevor überhaupt die Datenbank angefasst wird. Bei einer "idle" DB kann es daher sein, dass diverse Log-Dateien entstehen, die nie eingearbeitet werden und bei einem Backup keine Log-Dateien abgeschnitten werden.

 

Liege ich auch falsch, wenn ich annehme, dass die Performance leiden kann, wenn es sehr sehr viele Transaktionsprotokolle gibt?

 

Ja, zu 99%. Die Anzahl der Log-Dateien hat im Normalbetrieb überhaupt keine Auswirkungen auf die Performance, da die nur geschrieben, alle Änderungen aber im Arbeitsspeicher gemacht werden und von dort in die DB gehen.

 

Log-Dateien, die bereits eingearbeitet sind, liegen nur noch aus Redundanzgründen auf der Platte.

 

Die anderen, nicht eingearbeiteten, sind erst dann wichtig, wenn z.B. nach einem Crash der Arbeitsspeicher verloren gegangen ist oder die Bereitstellung aufgehoben wird. Dann dauert das etwas länger. Zu dem Zeitpunkt sind aber eh bereits alle Benutzer getrennt.

 

Problematisch ist also nicht die Zahl der Log-Dateien, sondern die Zahl der *nicht eingearbeiteten* Log-Dateien.

 

Da man die im laufenden Betrieb aber nicht einfach feststellen kann, ist die Diskussion darüber höchsten Philosophisch und sobald es ernsthafte Probleme gibt, wird sich Exchange schon beschweren.

 

@Dukel: Kleine Begriffskorrektur. Bei einer Point-in-Time-Recovery werden keine Log-Dateien benutzt, da die Datenbank auf den Stand der Sicherung zurückgesetzt wird. Du meinst die Roll-Forward Recovery, dafür braucht man die Log-Dateien.

[Stonehedge 12]

Ich danke dir vielmals für deine ausführliche Erklärung! Dennoch werde ich mich dann auf die Suche machen müssen, den Grund der Performance-Probleme zu finden. Dort hatte ich eben die Transaktionsprotokolle in Verdacht.

 

Danke an euch alle. Dieses Board ist immer wieder herrlich :)

[Dukel 436]

Wieso fragst du nicht gleich, wie man Performance überprüfen kann und in den Griff bekommen kann?

[Stonehedge 12]

Weil das erstmal nicht meine Frage war. Ich wollte die Frage oben klären.

[NilsK 2.785]

Moin,

 

- (bei DAG nach dem Seeding: Änderung als SQL-Befehle an die passiven Knoten schicken)

 

als SQL-Befehle? :confused:

Ist das nicht eigentlich Log Shipping, d.h. der passive Knoten holt sich Kopien der Logfiles und sorgt selbst für das Nachführen der Transaktionen in seiner Kopie?

 

Gruß, Nils

[RobertWi 81]

Hallo Nils,

 

das dachte ich bis zum Summit auch, es wurde allerdings bei 2010 ein wenig angepasst.

 

Beim Seeding werden Log-Dateien kopiert (sog. File Mode), aber sobald die Datenbanken synchron sind, werden die Transaktionen über den Ese Buffer kopiert (sog. Block Mode) und die Log auf dem passiven Knoten aus diesem neu erstellt - von mir etwas kurz als "SQL-Befehle" beschrieben.

 

Hier ist eine öffentliche Version der Folien: Native Data Protection in Exchange 2010 SP1 :: 2010 :: Europe :: Microsoft Tech·Ed (Folie 10 in Powerpoint durchklicken).

[NilsK 2.785]

Moin,

 

cool, danke für die Info!

 

Gruß, Nils