Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Transaction Management in the R* Distributed Database Management System C. Mohan, Bruce Lindsay and R. Obermarck 16.05.2009Seminar Datenbanken SS09 Hendrik."—  Präsentation transkript:

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

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

3 Seminar Datenbanken SS-093 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

4 Seminar Datenbanken SS-094 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

5 Seminar Datenbanken SS-095 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

6 Seminar Datenbanken SS-096 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

7 Seminar Datenbanken SS Phase Locking 2PL ermöglicht Serialisierbarkeit von parallelen Transaktionen. Wachstumsphase: Sperren werden gesetzt, aber nicht freigegeben. Schrumpfungsphase: Sperren werden freigegeben, aber nicht angefordert. Quelle:

8 Seminar Datenbanken SS 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.

9 Seminar Datenbanken SS 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 Sub1Sub2Subn

10 Seminar Datenbanken SS-0910 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

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

12 Seminar Datenbanken SS P 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

13 Seminar Datenbanken SS P 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

14 Seminar Datenbanken SS P 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)

15 Seminar Datenbanken SS-0915 Zusammenfassung 2P KoordinatorSubordinator Nachrichten PREPARE COMMIT/ABORT YES/NO VOTE ACK Logs commit* (forced) end prepare* commit* beide forced

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

17 Seminar Datenbanken SS P 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

18 Seminar Datenbanken SS P 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

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

20 Seminar Datenbanken SS-0920 Hierachical 2P Bisherige Beschreibung von 2P reicht nicht aus wenn eine Transaktion aus mehren Ebenen / Prozessen besteht. Lösung: Hierachical 2P Ko Sub1Sub2Subn

21 Seminar Datenbanken SS-0921 Hierachical 2P Root Non-Leaf Non-Root Leaf 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

22 Seminar Datenbanken SS-0922 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

23 Seminar Datenbanken SS-0923 PA Protocol - Ablauf ROOT Non-Root,Non-LeafLeaf PREPARE VOTE READ prepare* VOTE YES commit* COMMIT commit* ACK end

24 Seminar Datenbanken SS-0924 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

25 Seminar Datenbanken SS-0925 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

26 Seminar Datenbanken SS-0926 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.

27 Seminar Datenbanken SS-0927 PC Protocol - Ablauf ROOT Non-Root,Non-LeafLeaf collecting* PREPARE collecting* PREPARE VOTE READ prepare* VOTE YES commit* COMMIT commit

28 Seminar Datenbanken SS-0928 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

29 Seminar Datenbanken SS-0929 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

30 Seminar Datenbanken SS-0930 Quellen Joseph M. Hellerstein and Michael Stonebraker (Eds.): Readings in Database Systems, 4th Edition Paper Phasen-Sperrprotokoll


Herunterladen ppt "Transaction Management in the R* Distributed Database Management System C. Mohan, Bruce Lindsay and R. Obermarck 16.05.2009Seminar Datenbanken SS09 Hendrik."

Ähnliche Präsentationen


Google-Anzeigen