2
Microsoft SQL 2008 Standard Server Frage
Ablauf DB und Trans Action Log
Ich habe mal eine kleine Frage.
Bei einem SQL 2008 Server. Wie läuft es mit dem Trans Action Log und DB ab?
Ich habe es eigentlich so gelernt das beschreibe ich folgendermassen:
Ein Programm oder eine App pflegt zum Beispiel mit einem Program oder Webfrontend Daten ein.
Diese werden dann zuerst ins Trans Action Log geschrieben, wenn diese Transaction abgeschlossen ist wird dieser der DB übermittelt. Die DB geantwotet dann Transaction sauber übermittelt und sicher.
So habe ich das zumindestens gelernt.
Was für einen Nachteil hätte es wenn man einen SQL Server ohne Transaction Log betreiben würde?
Bei einem SQL 2008 Server. Wie läuft es mit dem Trans Action Log und DB ab?
Ich habe es eigentlich so gelernt das beschreibe ich folgendermassen:
Ein Programm oder eine App pflegt zum Beispiel mit einem Program oder Webfrontend Daten ein.
Diese werden dann zuerst ins Trans Action Log geschrieben, wenn diese Transaction abgeschlossen ist wird dieser der DB übermittelt. Die DB geantwotet dann Transaction sauber übermittelt und sicher.
So habe ich das zumindestens gelernt.
Was für einen Nachteil hätte es wenn man einen SQL Server ohne Transaction Log betreiben würde?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 141622
Url: https://administrator.de/contentid/141622
Printed on: April 23, 2024 at 13:04 o'clock
2 Comments
Latest comment
Hallo,
jede abgeschlossene Änderung (genauer: Die Änderungen an Blockinhalten, die durch das Statement entstehen) geht erstmal in das Transaction Log. Erst wenn das Transaction Log auf Festplatte geschrieben ist, geht das Ok synchron an die Anwendung zurück.
Auf dem Server läuft jetzt ein zweiter Prozess, der asynchron die Änderungen aus dem Transaktion Log in das eigentliche Datenfile übernimmt. Die übernommenen Änderungen werden entsprechend im Log markiert. Egal wann die Datenbank nach der Bestätigung der Änderung umfallen sollte, nimmt man Datenfile und Transaction Log zusammen, kann ein konsistenter Zustand hergestellt werden (kann man im Log des Servers beim Restart sehen, Transactions rolled back bzw rolled forward).
Was mit den übernommenen Änderungen im Log-File passiert, hängt von den Modus ab, in dem die DB läuft: Bei Simple wird der Platz automatisch wieder freigegeben, bei Full passiert das erst nach einer Transktionlog-Sicherung. Warum sollte man die sichern ? Weil man mit den ununterbrochenen Transaktion-Logs nach einer Vollsicherung ein Transaktionsgenaues Restore machen kann und nicht nur auf die Zeitpunkt einer Vollsicherung zurückkommt.
Warum macht man sich den Aufwand und ändert nicht direkt das Datenfile ? Man muss Transaktionen auch zurücknehmen können (Rollback). Dafür braucht man auch den Zustand vor der Änderung, d.h. mit einer Version des Datenbestandes kommt man nicht hin.
Wenn man auf Transaktionen verzichtet geht es auch ohne, bei alten MySQL mit MyISAM war das z.B. so.
jede abgeschlossene Änderung (genauer: Die Änderungen an Blockinhalten, die durch das Statement entstehen) geht erstmal in das Transaction Log. Erst wenn das Transaction Log auf Festplatte geschrieben ist, geht das Ok synchron an die Anwendung zurück.
Auf dem Server läuft jetzt ein zweiter Prozess, der asynchron die Änderungen aus dem Transaktion Log in das eigentliche Datenfile übernimmt. Die übernommenen Änderungen werden entsprechend im Log markiert. Egal wann die Datenbank nach der Bestätigung der Änderung umfallen sollte, nimmt man Datenfile und Transaction Log zusammen, kann ein konsistenter Zustand hergestellt werden (kann man im Log des Servers beim Restart sehen, Transactions rolled back bzw rolled forward).
Was mit den übernommenen Änderungen im Log-File passiert, hängt von den Modus ab, in dem die DB läuft: Bei Simple wird der Platz automatisch wieder freigegeben, bei Full passiert das erst nach einer Transktionlog-Sicherung. Warum sollte man die sichern ? Weil man mit den ununterbrochenen Transaktion-Logs nach einer Vollsicherung ein Transaktionsgenaues Restore machen kann und nicht nur auf die Zeitpunkt einer Vollsicherung zurückkommt.
Warum macht man sich den Aufwand und ändert nicht direkt das Datenfile ? Man muss Transaktionen auch zurücknehmen können (Rollback). Dafür braucht man auch den Zustand vor der Änderung, d.h. mit einer Version des Datenbestandes kommt man nicht hin.
Wenn man auf Transaktionen verzichtet geht es auch ohne, bei alten MySQL mit MyISAM war das z.B. so.
Ah Danke jetzt ist es mir klarer. Ich muss das ganze mal wirken lassen.
