T1: A := A * 2 B := B * 2 T2: A := A B := B + 100

Ähnliche Dokumente
Konfliktgraph. Satz und Definition

Übungen zur Vorlesung. Mobile und Verteilte Datenbanken. WS 2008/2009 Blatt 4. Lösung

Grundlagen von Datenbanken. Referentielle Aktionen, Sichten, Serialisierbarkeit und Locking

Übungen zur Vorlesung. Datenbanken I. WS 2002/2003 Blatt 4 MUSTERLÖSUNG

Aufgabe 10.1: Lösung:

Transaktionsmanagement - Einführung. Prof. Dr. T. Kudraß 1

Datenbanken 1. Sommersemester Übung 8

Datenbanken 1. Sommersemester Übung 8

Datenbanken: Ablaufpläne und Serialisierbarkeit

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

3.5 Synchronisation ohne Sperren

Kapitel 12 Integrität der Datenbank

Inhaltsverzeichnis. Inhaltsverzeichnis

Transaction Validation for XML Documents based on XPath

AG Datenbanken und Informationssysteme Wintersemester 2006 / Übungsblatt. Aufgabe 2: Sperrprotokolle in Datenbankystemen

Kommunikation und Datenhaltung

Übungen zu Datenbanksysteme

E. Verteilte Berechnungen/Algorithmen

Datenbanksysteme 2009

Prioritäten/Zeitstempel-Verfahren

Prioritäten/Zeitstempel-Verfahren. WAIT-DIE und WOUND-WAIT-Strategien

Kapitel 3 Synchronisation

Transaktionsverarbeitung und Nebenläufigkeitskontrolle. Jim Gray ( )

Eigenschaften von TAs: ACID-Prinzip

Mehrbenutzersynchronisation

Mehrbenutzersynchronisation

Kapitel 9a Transaktionen - Synchronisation

Universität Augsburg, Institut für Informatik Wintersemester 2008/2009 Prof. Dr. W. Kießling 03. Februar Semesterklausur

Beispielszenarien. 12. Transaktionen. ACID-Eigenschaften. Transaktion

Lösung zum 2. Übungsblatt VBS

Synchronisation in Datenbanksystemen in a nutshell

8. März: Klausurvorbereitung (Durchgehen Klausurähnlicher Aufgaben, Fragestunde)

5. Transaktionsverarbeitung

Datenbank- Verwaltungssysteme

Transaktionsverarbeitung und Nebenläufigkeitskontrolle. Jim Gray ( )

Mehrbenutzer-Synchronisation

6.3 Verteilte Transaktionen

Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS)

Konflikte. Konflikt-Äquivalenz von Read/Write-Plänen, Konflikt-Serialisierbarkeit

Transaktionskonzept Eine Transaktion ist eine Folge von Operationen mit folgenden ACID Eigenschaften: Atomicity: Es werden alle Operationen oder gar k

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.

Concurrency Control. Prof. Dr. T. Kudraß 1. Korrektheitskriterium: Serialisierbarkeit. Zwei Schedules sind konfliktäquivalent wenn gilt:

Übung Datenbanksysteme I Transaktionen, Selektivität, XML

Mehrbenutzersynchronisation

Vorlesung "Verteilte Systeme" Wintersemester 2000/2001. Verteilte Systeme. 14. Transaktionen

Übungen zur Vorlesung. Datenbanken I

DB I S. 1 Referentielle Aktionen [10 P.] Gegeben sei folgende Datendefinition:

Vorlesung "Systemsoftware II" Wintersemester 2002/03

1 Referentielle Aktionen

Verteilte Systeme. Replikation & Konsistenz I. Prof. Dr. Oliver Haase

Kapitel 5 Mehrversionen-CC. MVCC: Annahmen & Eigenschaften

Transaktionen. Michael Löwe 04/15/16. FHDW Hannover, Freundallee 15, Hannover address:

Access-Modell. A4. Im Operandenteil von Anweisungen vorkommende Objekte seien unstrukturiert und stehen in keinerlei Beziehung zueinander.

Software-Engineering und Datenbanken

Mehrbenutzersynchronisation

Replikation und Synchronisation. in mobilen Datenbanksystemen

Darunter versteht man die Anmeldung eines Benutzers beim System unter Angabe einer Benutzererkennung.

Semesterklausur. Hinweise:

Kapitel 2 Transaktionsverwaltung. Skript 2009 Matthias Schubert

Scheduler. vereinfachende Annahmen: alle Transaktionen werden wirksam nur Konflikt-Serialisierbarkeit keine Versionen

6. Serialisierbarkeit

Datenbanken: Transaktionskonzept und Concurrency Control

Serialisierbarkeit von Historien: Minimalanforderung bzgl. "akzeptabler" Synchronisation

... T n T 1 T 2 T 3. Transaktions-Manager. Daten-Manager. Recovery-Manager Puffer-Manager. Datenbank

9. Transaktionsverwaltung 9.3. Fehlerbehandlung Seite 1

Koordination des Mehrbenutzerbetriebs 9. Koordination des Mehrbenutzerbetriebs

mathematik und informatik

Replikation und Caching für mobile Anwendungen

Kapitel 10: Transaktionsverwaltung

Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung

Datenbanksysteme. Transaktionen. Burkhardt Renz. Sommersemester Fachbereich MNI Technische Hochschule Mittelhessen

Datenintegrität und Transaktionskonzept

Mehrbenutzer-Synchronisation

Datenbanken und Informationssysteme

Transaktionsverwaltung

6.1.2 Sequentielle Konsistenz (Lamport 1979)

Kommunikation und Datenhaltung

Grundlagen von Datenbanken SS Synchronisation paralleler Transaktionen

6. Serialisierbarkeit 1

TRANSAKTIONEN UND DATENINTEGRITÄT

TRANSAKTIONEN UND DATENINTEGRITÄT

2.3 View Serialisierbarkeit

Grundlagen: Datenbanken

Mehrbenutzer-Synchronisation

3.6 Transaktionsverwaltung

9.2.4 Phantomproblem. Mächtigkeit von 2PL. Lösung des Phantomproblems. bisherige implizite Annahme

Mächtigkeit von 2PL. Geben Sie einen Schedule S an, der. konfliktserialisierbar, jedoch nicht bei Anwendung von 2PL entstehbar. ist.

Synchronisierung von Transaktionen ohne Sperren. Annahme: Es gibt eine Methode, zu erkennen, wann eine Transaktion die serielle Ordnung verletzt.

Holger Schwarz Universität Stuttgart, IPVS

9.3 Fehlerbehandlung

Transaktionen und Synchronisation konkurrierender Zugriffe

Transkript:

1

T1: A := A * 2 B := B * 2 T2: A := A + 100 B := B + 100 2

1. Transaktionen und ihre Probleme 2. Wie löst man es als Pessimist? 3. Der Optimist sagt 4. Wer hat Recht? 3

Folge von Operationen, die die Datenbank von einem konsistenten in einen konsistenten Zustand überführt, wobei das ACID-Prinzip eingehalten werden muss 4

Initial: A = B = 100 T1: A := A * 2 B := B * 2 T2: A := A + 100 B := B + 100 T 1 T 2 A := A * 2 A := A + 100 B := B + 100 B := B * 2 erwartet: A = B A = 300 B = 400 5

T 1 T 2 A := A * 2 B := B * 2 A := A + 100 B := B + 100 A = 300 B = 300 Serialisierbarer Schedule Schedule, der zu einem beliebigen seriellen Schedule äquivalent ist (serielle Äquivalenz) 6

1. Transaktionen und ihre Probleme 2. Wie löst man es als Pessimist? 3. Der Optimist sagt 4. Wer hat Recht? 7

Es wird auf jeden Fall etwas Schlimmes passieren. Datenbankelemente werden für den (exklusiven) Zugriff gesperrt Ein Element kann nicht von zwei Transaktionen gleichzeitig gesperrt werden 8

alle Sperranforderungen geschehen, vor allen Freigaben T 1 T 2 Lock(A); A := A * 2 Lock(A) Lock(B), B := B * 2 unlock(a); unlock(b) Lock(A); A := A + 100 Lock(B); B := B + 100 unlock(a); unlock(b) 9

Overhead durch Einhaltung des Sperrprotokolls und Deadlock-Identifizierung T 1 T 2 Lock(A); A := A * 2 Lock(B) Lock(B) B := B + 100 Lock(A) Locking ist oft gar nicht notwendig bspw. wenn nur lesende Transaktionen bestehen 10

1. Transaktionen und ihre Probleme 2. Wie löst man es als Pessimist? 3. Der Optimist sagt 4. Wer hat Recht? 11

Etwas Schlimmes wird nicht passieren; oder nur äußerst selten! 12

Prof. H T Kung John T. Robinson 13

Annahme: Datenbank ist in Baumstrukturen organisiert Zugriff erfolgt immer über die Wurzelknoten 14

Transaktionen bestehen aus 3 Phasen read validate write - Abarbeitung der Transaktion - geschrieben wird auf lokalen Kopien der Originale - jede Transaktion hat je ein privates read- und writeset - Prüfe, ob lokale Änderungen global bekanntgemacht werden können - Prüfe, ob gelesene Werte nicht verfälscht sind - wenn Validierung erfolgreich war, werden die Änderungen global übernommen 15

Einschränkung der Serialisierbarkeit Jede Transaktion T i erhält während ihrer Ausführung eine Transaktionsnummer t(i) Zuweisung vor der Validierung (Ende read-phase) Ein Schedule ist dann serialisierbar, wenn es einen seriellen äquivalenten Schedule gibt, in dem T i vor T j kommt, wenn t(i) < t(j) ist 16

Serialisierbarkeit ist gegeben wenn für alle T i,t j mit t(i) < t(j) eine der folgenden drei Bedingungen erfüllt ist: 1. T i und T j sind seriell 17

2. writeset(t i ) readset(t j ) = und die write-phase von T j beginnt erst nach dem Ende der write- Phase von T i 3. writeset(t i ) (readset(t j ) writeset(t j )) = und T i beendet seine read-phase vor der read-phase von T j 18

Serielle Validierung Prüft nur Bedingungen 1 und 2 Write-Phase sind somit seriell Parallele Validierung Bedingung 3 wird hinzugenommen Parallele write-phasen werden ermöglicht 20

Ansatz: Führe die Validierung und die write-phase seriell in einer kritischen Sektion durch Beginn der Transaktion: 1. Merke aktuell größte Transaktionsnummer (s_tn) 2. Erstelle leeres write-set 3. Erstelle leeres read-set 21

Ende der Transaktion: 1. Betrete kritische Sektion 2. Hole aktuell größte Transaktionnummer (f_tn) 3. Für jede Transaktion T i von s_tn + 1 bis f_tn Prüfe ob Überschneidung zwischen writeset(t i ) und eigenem readset besteht 4. Wenn Überschneidung: starte neu 5. Sonst: Write-Phase, tnc++, tn = tnc 6. Verlasse kritische Sektion 22

T 1 : w(a) T 2 : r(b), w(c) T 3 : r(a), w(b) s_tn = 0 f_tn = 0 tn = 1 tnc++ s_tn = 0 f_tn = 1 s_tn = 0 Prüfe readset auf Überschneidung mit writeset(t 1 ) {B} {A} = tn = 2 tnc++ f_tn = 2 krit. Sektion: tnc = 12 0 23

T 1 : w(a) T 2 : r(b), w(c) T 3 : r(a), w(b) Prüfe readset auf Überschneidung mit writeset(t 1 ) {A} {A} = {A} s_tn = 0 Prüfung mit T2 f_tn = 2 {A} {C} = NEUSTART krit. Sektion: tnc = 2 24

Nebenläufigkeit soll durch Hinzunahme der dritten Bedingung erhöht werden Neu: Menge active von Transaktionen, die ihre readaber noch nicht ihre write-phase abgeschlossen haben Für T active müssen read- und writeset betrachtet werden 25

enter_crit_sec() f_tn = tnc finish_active = copy(active), active := active own_id leave_crit_sec() prüfe für writesets aller Transaktion in finish_active ob eine Überschneidung zum eigen read- oder writeset besteht prüfe für die writesets aller Transaktionen von T s_tn+1 bis T f_tn ob eine Überschneidung zum eigenen readset besteht wenn nicht, write_phase(), enter_crit_sec() tnc = tnc + 1, tn = tnc active = active own_id, leave_crit_sec() sonst enter_crit_sec() active = active own_id, starte_neu leave_crit_sec() 26

perfekter Anwendungsfall: Anfragesystem 99 % lesende Transaktionen Überschneidung der read-sets sind irrelevant Nebenläufiges Einfügen in große B-Bäume 27

1. Transaktionen und ihre Probleme 2. Wie löst man es als Pessimist? 3. Der Optimist sagt 4. Wer hat Recht? 28

Locking: Hohe Nebenläufigkeit, bei garantierter Serialisierbarkeit unabhängig von der Datenorganisation allgemein anwendbar nicht deadlockfrei großer Overhead 29

Optimistische Methode: deadlockfrei weniger Overhead sehr gut, bei Systemen mit überwiegend lesenden Transaktionen viele (unnötige) Neustarts von Transaktionen kleinste Einheit zur Überprüfung sind Speicherseiten 30

Optimismus ist gut, in einigen Fällen sogar besser, doch im Allgemeinen ist Pessimismus sicherer! 31