Skript Datenbanken I - Praktische Informatik Universität Kassel
Skript Datenbanken I - Praktische Informatik Universität Kassel
Skript Datenbanken I - Praktische Informatik Universität Kassel
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Kapitel 6 – Realisierungen des Transaktionsprinzips 131<br />
des log. Neue Sätze für das log werden dabei zuerst in flüchtige Puffer<br />
geschrieben und dann von Zeit zu Zeit, z.B. bei einem Commit, mittels<br />
der force-Operation in stabilen Speicher geschrieben. Man nennt dies<br />
„forcing the log up to a certain LSN“ (Durchschreiben des log bis zu einer<br />
LSN).<br />
Drei Arten von Sätzen werden unterschieden<br />
• undo-redo-log-records<br />
• undo-only-log-records<br />
• redo-only-log-records.<br />
Undo-redo-Information kann dabei physisch als before- und after-image<br />
oder operational in der Art „addiere 5 to Feld 4 von Satz 15“ gespeichert<br />
werden. Operation logging erlaubt potentiell mehr Parallelität durch Ausnutzung<br />
semantischer Information als striktes Sperren mit X-Sperren die<br />
während des ganzen Commits gehalten werden.<br />
ARIES verwendet ferner das weithin anerkannte WAL (write ahead<br />
logging) Protokoll, bei dem „update-in-place“, also schreiben an den alten<br />
Speicherplatz“ erfolgt, was voraussetzt, daß zumindestens die undo-Information<br />
für dieses Update auf das log in stabilem Speicher herausgeschrieben<br />
wurde. Um die Einhaltung des Protokolls zu überwachen, steht in<br />
jeder Seite die LSN des log-Satzes, der die letzte Änderung auf dieser<br />
Seite verursacht hat.<br />
Der Transaktionsstatus wird auch im log aufgezeichnet und keine<br />
Transaktion ist abgeschlossen, bevor nicht ihr Commit-Status und alle sie<br />
betreffenden log-Daten auf stabilem Speicher gesichert sind, wozu das log<br />
bis zur LSN des Commit-Satzes auf stabilen Speicher durchgeschrieben<br />
sein muß.<br />
6.3 Mehrbenutzerzugriff<br />
Mehrbenutzerbetrieb verlangt die Isolierung der einzelnen Transaktion<br />
vor Auswirkungen des quasi-parallelen Betriebs (vgl. ACID-Eigenschaften<br />
oben). Dies wird erreicht durch „Kontrolle der Nebenläufigkeit“ (concurrency<br />
control).