C. Mohan, Bruce Lindsay and R. Obermarck Transaction Management in the R* Distributed Database Management System C. Mohan, Bruce Lindsay and R. Obermarck 16.05.2009 Seminar Datenbanken SS09 Hendrik Wolf, MNR: 25202540

Seminar Datenbanken SS-09 Inhalt Introduction Guaranteeing Uniformity Synchrone / Asynchrone Logs 2 Phase Locking 2 Phase Commit Hierachical 2P Presumed Abort Presumed Commit Fazit 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 R* Protocol Transaktionsmanagement im R* verteilten Datenbankmanagementsystemen R* ist ein experimentelles Datenbank Protokoll für Transaktion in verteilten Datenbanken Erlaubt multiple Datenänderung auf mehreren Seiten über eine einzelne Transaktion 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 R* Protocol R* beinhaltet Presumed Abort und Presumed Commit Protokoll PA, PC sollen Traffic minimieren und Performance steigern PA ist für read-only Transaktionen optimiert R* verfügt über eigenes Deadlockmanagement Entwickelt in IBM Almaden Research Center 16.05.2009 Seminar Datenbanken SS-09

Guaranteeing Uniformity Transaktionen in einer Datenbank entweder ganz oder gar nicht ausführen. Auch bei Verbindungsfehlern Transaktion müssen test weise durchgeführt werden Widerrufbarkeit durch UNDO/REDO Logs garantieren 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 Log Schreibarten Synchron Log erzwungen Für alle Transaktion Log vor der T. von VM auf Festspeicher sichern -> Force writes Nach Fehlern Transaktion widerrufbar Asynchron Log im VM, bei Bedarf auslagern Transaktionen auch ohne gesicherten Log Nach Fehlern mögl. Kein Log vorhanden 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 2 Phase Locking 2PL ermöglicht Serialisierbarkeit von parallelen Transaktionen. Wachstumsphase: Sperren werden gesetzt, aber nicht freigegeben. Schrumpfungsphase: Sperren werden freigegeben, aber nicht angefordert. Quelle: http://de.wikipedia.org/wiki/Sperrverfahren#Zwei-Phasen-Sperrprotokoll 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 2 Phase Locking R* implementiert 2PL Durch die Nutzung von 2PL entstehen Deadlocks Deadlocks werden von R* nicht verhindert sondern durch „victim Transaction abort“ aufgelöst Victim: Bei globalen Deadlocks wird eine Transaktion auf der Seite des Deadlocks ausgewählt und beendet. 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 2 Phase Commit In vert. Datenbanken teilen sich Transaktionen meist in mehrere Prozesse auf 2P besteht aus einem Koordinator und mehreren Subordinatoren Ko. übergibt Transaktion an die Subs Die Subs führen die Transaktion aus Subs kommunizieren nur mit dem Ko. nicht untereinander Ko Sub1 Sub2 Subn 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 Kriterien eines 2PC Garantierte atomare Transaktionen Transaktionen nach dem ausführen „vergessen“ Minimaler Überhang (Log-writes, message traffic) Optimierte Performance im fehlerfreien Fall Optimierung von read-only Transaktion 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 2P Ablauf Zeit  Koordinator Subordinate PREPARE prepare* / abort* YES / NO VOTE commit* / abort* COMMIT / ABORT ACK end -Prepare State- -Commit State- 16.05.2009 Seminar Datenbanken SS-09

2P im fehlerfreien Ablauf (1/3) Nutzerapplikation übergibt Transaktion an den Koordinator -> 1. Phase Ko. Sendet PREPARE an alle Subordinates Wenn der Sub. bereit ist wird ein prepare Log (force write) und YES VOTE an Ko. gesendet. Wenn alle Subs YES VOTE gesendet haben ist die Transaktion im –PREPARED STATE- und es beginnt die 2te Phase 16.05.2009 Seminar Datenbanken SS-09

2P im fehlerfreien Ablauf (2/3) 2te Phase: Ko. schreibt einen Commit Log (forced) und sendet COMMIT an alle Subs -COMMITING POINT- Wenn alle Subs ein COMMIT erhalten haben schreiben diese ebenfalls einen Commit Log (forced) und senden ACK an denn Ko. Daraufhin führen die Subs die Transaktion aus Ko. Schreibt END in das Log 16.05.2009 Seminar Datenbanken SS-09

2P im fehlerfreien Ablauf (3/3) Sollte einer der Subs NO VOTE senden wird die Transaktion abgebrochen Transaktion geht in den -ABORT STATE- Ko. sendet ABORT an all die Subs die YES VOTE gesendet haben und schreibt einen ABORT LOG (forced) 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 Zusammenfassung 2P Koordinator Subordinator Nachrichten PREPARE COMMIT/ABORT YES/NO VOTE ACK Logs commit* (forced) end prepare* commit* beide forced 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 2P Ablauf mit Fehlern Jede Seite verfügt über einen Recovery Prozess RP bezieht Information aus den gesicherten Logs 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 2P Ablauf mit Fehlern Absturz im PREPARED STATE RP spricht Ko. an um zu erfahren wie die T. beendet wird Wenn Ko. mit COMMIT/ABORT antworten verhält sich RP wie ein Sub und führt die T. durch 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 2P Ablauf mit Fehlern Absturz im COMMIT STATE der Transaktion RP sendet solange COMMIT / ABORT an die Subs bis ein ACK zurückgesendet wird. Wenn ACK erhalten wird END in das Log geschreiben 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 2P Ablauf mit Fehlern Absturz bei der Ausführung der Transaktion RP widerruft die Transaktion mit Hilfe des UNDO/REDO Logs 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 Hierachical 2P Bisherige Beschreibung von 2P reicht nicht aus wenn eine Transaktion aus mehren Ebenen / Prozessen besteht. Lösung: Hierachical 2P Ko Sub1 Sub2 Subn 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 Hierachical 2P Root Prozesse werden Baumförmig angeordnet mit Parent / Child Abhängigkeit Root: Prozess arbeitet als Ko Non-Root,Non-Leaf: arbeitet als Ko für Leaf und als Sub für Root Leaf: Pozess arbeitet als Sub Non-Leaf Non-Root Leaf Leaf Leaf 16.05.2009 Seminar Datenbanken SS-09

Presumed Abort Protocol Transaktion ist komplett oder teilweise read-only Komplett read-only: keine updates Teilweise read-only: Ein Teil der T. bewirkt updates Art der T. muss nicht vorher bekannt sein. Für read-only gilt: Root sendet kein COMMIT / ABORT Kein UNDO/REDO Log Keine 2te Phase für das Protokoll 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 PA Protocol - Ablauf ROOT Non-Root,Non-Leaf Leaf PREPARE VOTE READ prepare* VOTE YES commit* COMMIT ACK end 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 PA Protocol - Ablauf Vollständig read-only Kein Prozess schreibt Logs Root sendet PREPARE an dessen Leaf-Prozesse Leaf-Prozesse senden READ-VOTE an den Root Teilweise read-only Root sendet PREPARE und COMMIT / ABORT an die Leaf-Prozesse die ein update durchführen Und PREPARE an alle read-only Leafs Ist der Root ein Non-root,Non-Leaf Prozess sendet dieser YES-VOTE und ACK an dessen parent-root 16.05.2009 Seminar Datenbanken SS-09

Presumed Commit Protocol Mehrheit der T. werden mit COMMIT beendet und nicht mit ABORT  Logs forced-write nur für abort  Performance Problem: Root stürzt ab während einige Leafs im PREPARED STATE sind also YES VOTE gesendet haben Nach Recovery vergisst Root die T. ohne die Leafs darüber zu informieren, da kein commit Log Die Leafs die YES-VOTE gesendet haben fragen beim Root nach, dieser antwortet mit COMMIT  Inkonsistenz 16.05.2009 Seminar Datenbanken SS-09

Presumed Commit Protocol Lösung: Root forced einen collect Log In dem der Status der Leafs festgehalten wird  PC Wenn Recovery Prozess nach Fehlern einen collect log findet werden damit alle beteiligten Leafs ABORTED Wenn kein Log vorhanden ist wird auf Anfragen der Leaf-Prozesse immer mit COMMIT geantwortet. 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 PC Protocol - Ablauf ROOT Non-Root,Non-Leaf Leaf collecting* PREPARE VOTE READ prepare* VOTE YES commit* COMMIT commit 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 PC Protocol - Ablauf Vollständig read-only Root schreibt zwei Logs: collecting (forced) und commit Und sendet PREPARE an die Leaf-Prozesse Leaf-Prozesse senden READ-VOTE und schreiben keine Logs Teilweise read-only Root schreibt zwei Logs: collecting und commit beide forced sendet PREPARE und COMMIT an update-Leaf und PREPARE an read-only-Leaf Leaf schreibt drei Logs: collecting, prepare beide forced und commit nicht forced 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 Fazit PA ist effizienter als 2P durch die read-only Optimierung von PA 2P behandelt alles als update Transaktion PC bietet Performancevorteil gegenüber 2P Durch die Einsparung von zwei Logs und ACK 16.05.2009 Seminar Datenbanken SS-09

Seminar Datenbanken SS-09 Quellen Joseph M. Hellerstein and Michael Stonebraker (Eds.): Readings in Database Systems, 4th Edition Paper http://de.wikipedia.org/wiki/Sperrverfahren#Zwei-Phasen-Sperrprotokoll 16.05.2009 Seminar Datenbanken SS-09