Transaktions-Synchronisation

Grundlagen von Datenbanken
SS 2010
9. Synchronisation paralleler Transaktionen
Prof. Dr. Stefan Böttcher
Universität Paderborn
Agenda:
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 1
Wesentliche Eigenschaften von Transaktionen
Transaktionen ( = mehrere Datenbank-Aktionen
zusammengefasst zu einer Einheit )
sind :
Eigenschaft
Bedeutung
Beispiel
A
atomar
ganz oder garnicht
Überweisung
C
consistent
korrekt
Dateneingabe
I
isoliert
ungestört von parallelen
Transaktionen
Flugbuchung
D
dauerhaft
Daten gesichert
Auszahlung
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 2
Transaktionsprozeduren
Transaktionsprozeduren =
Prozeduren / Funktionen / Quellcodefragmente ,
die als atomare Einheit (ganz oder garnicht) auf der
Datenbank ausgeführt werden sollen.
Syntax zur Kennzeichnung der Einheit,
z.B. Anfang und Ende der Transaktionsprozedur wird
bestimmt durch einen der beiden Befehle
Commit oder Rollback
oder
am Anfang steht der Befehl tBegin( )
am Ende steht tCommit( ) oder tAbort( )
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 3
Transaktionen einer Transaktionsprozedur
Transaktion (= Ausführung einer Transaktionsprozedur auf der
Datenbank)
eine Folge aus Lese- und oder Schreiboperationen
auf der Datenbank , denen ein Begin vorangestellt ist ,
und an deren Ende entweder Commit oder Abort
ausgeführt wird.
Commit schreibt Änderungen auf der Datenbank fest,
Abort macht die Änderungen dieser Transaktion auf der
Datenbank rückgängig.
i.d.R. gibt es mehrere Transaktionen pro Transaktionsprozedur.
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 4
Transaktionsprozedur – Beispiel 1 (SQL)
void umbuchung ( int kto1, int kto2, int wieviel )
{
stmt.executeUpdate( ‘rollback‘ ) ;
stmt.executeUpdate( ‘update K.stand = K.stand + ‘ +
wieviel + ‘ where K.kto = ‘ + kto1 ) ;
stmt.executeUpdate( ‘update K.stand = K.stand - ‘ +
wieviel + ‘ where K.kto = ‘ + kto2 ) ;
stmt.executeUpdate( ‘commit‘ ) ;
}
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 5
Mögliche Transaktionen zu Beispiel 1
Eine Beispieltransaktion (T1)
< T1: Start >
< T1: Konto1 = Konto1 + 100 >
< T1: Konto2 = Konto2 - 100 >
< T1: Commit >
Eine andere Beispieltransaktion (T2)
< T2: Start >
< T2: Konto77 = Konto77 + 44 >
< T2: Konto88 = Konto88 - 44 >
< T2: Commit >
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 6
Transaktionsprozedur – Beispiel 2 (Poet OODB)
int bestelle ( int kto , Bestellung b )
{ tBegin( ) ;
aktuellerPreis = DB.Bestellungen.insert(b) ;
DB.Konten( kto ) . stand -= aktuellerPreis ;
if ( DB.Konten( kto ) . ueberziehungsLimitErschoepft ( ) ;
{ tAbort( ) ; // Datenbankoperationen dieser T zurücksetzen
return 255 ;
}
else {
tCommit( ) ; // Datenbankoperationen dieser T festschreiben
return 1;
}
}
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 7
Mögliche Transaktionen zu Beispiel 2
Eine Beispieltransaktion (T3)
< T3: Start >
< T3: Bestellungen.insert( 33, ‘Meier‘ , ‘Teil66 ) >
< T3: Konto22 = Konto22 - 1000 >
< T3: read( Konto22 ) >
// noch genug auf dem Konto
< T3: Commit >
Eine andere Beispieltransaktion (T4)
< T4: Start >
< T4: Bestellungen.insert( 33, ‘Meier‘ , ‘Teil66 ) >
< T4: Konto22 = Konto22 - 1000 >
< T4: read( Konto22 ) >
// nicht genug auf dem Konto
< T4: Abort >
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 8
Parallele Transaktionen
mehrere Transaktionen arbeiten gleichzeitig auf der Datenbank
z.B. verschiedene Bestellungen und Umbuchungen
und Kontostandsabfragen gleichzeitig
Ziele:
• hoher Parallelitätsgrad erwünscht  kritischer Abschnitt geht nicht,
• fehlerhafte parallele Abläufe sollen vermieden werden
4 typische Fehlerklassen:
Lesen schmutziger Daten (= dirty read)
nicht wiederholbares Lesen (= non-repeatable read)
verlorene Änderung (= lost update)
Phantomproblem (= phantom problem)
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 9
Fehlerklasse Lesen schmutziger Daten (= Dirty Read)
// Summe aller Konten ist 0
< T1: Start >
< T1: Konto1 = Konto1 - 100 >
< T2: Start >
< T2: read(Konto1) >
< T2: read(Konto2) >
< T2: Commit >
// Summe ist -100 ??
< T1: Konto2 = Konto2 + 100 >
< T1: Commit >
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 10
Nicht-wiederholbares Lesen (= non-repeatable read)
< T1: Start >
< T2: Start >
< T2: read(Konto1) >
< T1: Konto1 = Konto1 - 100 >
< T2: read(Konto1) >
// ?? 2 verschiedene Werte
< T2: Commit >
< T1: Commit >
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 11
Fehlerklasse Verlorene Änderung (= lost update)
< T1: Start >
< T1: temp1 = Konto1 + 100 >
< T2: Start >
< T2: temp2 = Konto1 + 200 >
< T2: Konto1 = temp2 >
< T2: Commit >
< T1: Konto1 = temp1 >
< T1: Commit >
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 12
Hintergrund der Fehlerklassen (1) - Konflikt
Operationen aus T1 und T2 stehen zu einander in Konflikt
2 Operationen (read oder write) auf demselben Objekt
(z.B. demselben Datenwert) stehen zueinander in Konflikt,
wenn mindestens eine der beiden Operationen
eine Schreiboperation (write) ist.
Idee: ( Konflikt = Nichtvertauschbarkeit )
2 Operationen stehen zueinander in Konflikt,
wenn sie nicht vertauschbar sind
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 13
Hintergrund der Fehlerklassen (2) - Abhängigkeit
Operationen jeder Ti gehören ‘unteilbar‘ zusammen
Wenn o1 aus T1 zu o2 aus T2 in Konflikt steht,
kommt es auf die Reihenfolge von o1 und o2 an:
Durch o1 vor o2 entsteht eine Abhängigkeit T1 vor T2
durch o2 vor o1 entsteht eine Abhängigkeit T2 vor T1
T1 vor T2 wäre korrekt oder T2 vor T1 wäre korrekt,
aber T1 vor T2 und T2 vor T1 (zyklische Abhängigkeit)
ist nicht korrekt.
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 14
Gemeinsamkeiten der Fehlerklassen
Operationen aus T1 und T2 stehen so zu einander in Konflikt,
dass zyklische Abhängigkeiten
T1 vor T2 und T2 vor T1
entstehen
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 15
Fehlerklasse Lesen schmutziger Daten (= Dirty Read)
// Summe aller Konten ist 0
< T1: Start >
< T1: Konto1 = Konto1 - 100 >
< T2: Start >
< T2: read(Konto1) >
< T2: read(Konto2) >
< T2: Commit >
// Summe ist -100 ??
< T1: Konto2 = Konto2 + 100 >
< T1: Commit >
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 16
Nicht-wiederholbares Lesen (= non-repeatable read)
< T1: Start >
< T2: Start >
< T2: read(Konto1) >
< T1: Konto1 = Konto1 - 100 >
< T2: read(Konto1) >
// ?? 2 verschiedene Werte
< T2: Commit >
< T1: Commit >
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 17
Fehlerklasse Verlorene Änderung (= lost update)
< T1: Start >
< T1: temp1 = Konto1 + 100 >
< T2: Start >
< T2: temp2 = Konto1 + 200 >
< T2: Konto1 = temp2 >
< T2: Commit >
< T1: Konto1 = temp1 >
< T1: Commit >
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 18
Formale Definition von Serialisierbarkeit (1)
Eine Transaktion(Ti , i ) ist eine partielle Ordnung einer Menge
von Operationen,
Ti  Liesi x , Schreibei x  | x ist Dateneleme nt Abbruchi , Endei ,
mit einer zugehörigen partiellen Ordnungsrelation
folgenden Eigenschaften:
 i mit
 Abbruchi Ti  EndeTi .
 Abbruchi bzw. Endei ist die letzte Operation in Ti , d.h. für
alle an anderen Operationen oi  Ti gilt, oi i Abbruchi
bzw. oi i Endei .
- Für jedes Paar
entweder oi1
Motivation / Fehlerklassen
oi1 , oi2 Ti , die in Konflikt stehen, ist
i oi2
oder oi2 i oi1 .
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 19
Formale Definition von Serialisierbarkeit (2)
Eine vollständige Historie einer Menge von n Transaktionen Ti mit
i 1  i n 
Ordnungsrelationen
mit Ordnungsrelation
H ,
ist eine partielle Ordnung
H ,  
H
wobei
n
 H  i 1 Ti
n
  H  i 1 i

und
alle Paare von Operationen
o1, o2  H ,
die zueinander in Konflikt stehen, werden durch die
vollständige Historie
o2  H o1.
Motivation / Fehlerklassen
H
Serialisierbarkeit
o  H o2 oder
geordnet, d. h. 1
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 20
Formale Definition von Serialisierbarkeit (3)
Eine Historie H1  H ' ,  H '  ist ein Präfix einer vollständigen
Historie H 2  H '  H , also eine partielle Ordnung mit
folgenden Eigenschaften:
 H' H
 Für alle o1 , o2  H ' gilt : o1  H ' o2  o1  H o2 .
 Für alle o1 , o2  H gilt : o1  H o2  o2  H '   o1  H '.
Historien können also Transaktionen enthalten, die noch
nicht vollständig ausgeführt sind.
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 21
Formale Definition von Serialisierbarkeit (4)
Zwei Historien von Transaktionen heißen „aquivalent“,
wenn sie über derselben Menge von Transaktionen
definiert sind, dieselben Operationen enthalten und
zueinander in Konflikt stehende Operationen nicht
abgebrochener Transaktionen in derselben Weise ordnen.
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 22
Formale Definition von Serialisierbarkeit (5)
Eine vollständige Historie von Transaktionen heißt „seriell“,
wenn für jedes Paar
T , T  von Transaktionen entweder
alle Operationen von
Tj
von T j
von
i
j
Ti
vor allen Operationen
auftreten, oder umgekehrt alle Operationen
vor allen Operationen von
Motivation / Fehlerklassen
Serialisierbarkeit
Ti
2-Phasen-Sperren
auftreten.
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 23
Formale Definition von Serialisierbarkeit (6)
Eine vollständige Historie von Transaktionen heißt
„serialisierbar“,
wenn sie äquivalent zu einer seriellen Historie ist
Eine Historie heißt serialisierbar,
wenn der Präfix ihrer mit Ende (=Commit) abschlossenen
Transaktionen serialisierbar ist.
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 24
Serialisierbarkeitstheorem (7)
Der Abhängigkeitsgraph einer Historie von Transaktionen
enthält einen Knoten pro Transaktion und für jede
Abhängigkeit T1 vor T2 eine Kante von T1 nach T2.
Eine Historie von Transaktionen ist genau dann
„serialisierbar“, wenn ihr Abhängigkeitsgraph projiziert auf
die mit Commit abgeschlossenen Transaktionen zyklenfrei
ist.
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 25
2-Phasen-Sperren – Lese- und Schreibsperren
Wird eine angeforderte Sperre nicht gewährt, muss T warten
bis die Sperre gewährt wird
Operationen auf Sperren:
rlock( T, A ) = Transaktion T fordert Lesesperre auf A an
wlock( T, A ) = Transaktion T fordert Schreibsperre auf A an
unlock( T, A ) = Transaktion T gibt Sperre auf A wieder frei
auch benutzte Kurzschreibweise:
lock( T, A ) = Transaktion T fordert Lese- oder Schreibsperre
auf A an
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 26
2-Phasen-Sperren - Legalität
T hält beim Schreiben eines Objektes A eine Schreibsperre
und beim Lesen eines Objektes eine Schreib- oder Lesesperre
Legalität:
Für alle Operationen write(T, A)  T gilt:
es gibt wlock(T,A)  T und unlock(T,A)  T mit
wlock( T , A ) <H write( T, A ) <H unlock( T, A )
Für alle Operationen read(T, A)  T gilt:
es gibt lock(T,A)  T und unlock(T,A)  T mit
lock( T , A ) <H read( T, A ) <H unlock( T, A )
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 27
2-Phasen-Sperren – Sperr-Regel
Schreibsperren (wlock) auf A verbieten
rlock wlock
gleichzeitige andere Sperren auf A,
rlock
ok
wait
und Lesesperren (rlock) auf A verbieten
gleichzeitige andere Schreibsperren auf A wlock wait wait
Sperr-Regel:
Für alle wlock(Ti,A), unlock(Ti,A), wlock(Tk,A), unlock(Tk,A) mit i≠k gilt:
unlock(Ti,A) <H wlock(Tk,A) v unlock(Tk,A) <H wlock(Ti,A)
Für alle rlock(Ti,A), unlock(Ti,A), wlock(Tk,A), unlock(Tk,A) mit i≠k gilt:
unlock(Ti,A) <H wlock(Tk,A) v unlock(Tk,A) <H rlock(Ti,A)
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 28
Warum 2-Phasigkeit notwendig ist
// Summe aller Konten ist 0 ( z.B. A+B = 0 )
// T1 bucht 100€ von A nach B um , T2 liest A und B
wlock( T1, A)
< T1: A = A - 100 > // write(T,A)
unlock(T1,A)
rlock(T2,A) ; rlock(T2,B)
< T2: read(A) >
< T2: read(B) >
unlock(T2,A) ; unlock(T2,B)
wlock(T1,B)
// Summe A+B ist -100 ??
< T1: B = B + 100 >
unlock(T1,B)
// dirty read trotz Legalität und eingehaltener Sperr-Regel
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 29
2-phasige Transaktionen
Jede Transaktion T muss mit der Freigabe ihrer Sperren
warten, bis sie alle Sperren erhalten hat.
Sie macht ihre erste Sperrfreigabe erst nach allen
Sperranforderungen
2-Phasigkeit einer Transaktion T:
Für alle rlock(T,A) , wlock(T,B) , unlock(T,C) gilt:
rlock(T,A)
<H unlock(T,C)
und
wlock(T,B) <H unlock(T,C)
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 30
Serialisierbarkeit durch 2-Phasen-Sperren
2-Phasen-Sperren garantiert serialisierbare Historien
Serialisierbarkeitssatz für 2-Phasen-Sperren:
Jede Historie, die nur aus legalen 2-phasigen Transaktionen
besteht und die Sperr-Regel einhält ist serialisierbar.
Beweis: Widerspruchsbeweis über die Ordnung <H.
Angenommen, die Historie H ist nicht serialisierbar, dann gibt
es einen Zyklus im Serialisierbarkeitsgraph  …  …
mindestens 1 der am Zyklus beteiligten Transaktionen ist nicht
legal oder nicht 2-phasig oder H verletzt die Sperr-Regel
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 31
Parallele Validierung (nach Kung & Robinson) (1)
Transaktionen T haben 2 oder 3 Phasen
Zeit
T
lies aus der Datenbank
und schreibe auf lokale Kopien
Lesephase
validiere (=prüfe), ob Abhängigkeiten azyklisch sind,
d.h., dass T nicht von neuerer Transaktion abhängt
Validierungsphase
nur wenn Validierung erfolgreich war,
schreibe lokale Kopien in die Datenbank
optionale
Schreibphase
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 32
Parallele Validierung (nach Kung & Robinson) (2)
Transaktionen T bekommen am Ende der Lesephase ihren Zeitstempel
Zeit Neuere Transaktionen validieren gegen ältere
T
Lesephase
lies aus der Datenbank
und schreibe auf lokale Kopien
hier bekommt die Transaktion T ihren Zeitstempel
validiere (=prüfe), ob Abhängigkeiten azyklisch sind,
d.h., dass T nicht von neuerer Transaktion abhängt
Validierungsphase
wenn Validierung erfolgreich war,
schreibe lokale Kopien in die Datenbank
optionale
Schreibphase
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 33
Parallele Validierung (nach Kung & Robinson) (3)
Grundideen:
1. Transaktionen werden nicht gesperrt, müssen nicht warten
2. Lasse neuere Transaktionen „vordrängeln“, aber auf eigenes Risiko,
d.h., wenn sie zu früh gestartet wurden, müssen sie abbrechen und
wiederholt gestartet werden.
3. Neuere Transaktionen sind die, die einen späteren Zeitstempel
bekommen, d.h. später mit der Lesephase fertig wurden.
4. Um die Datenbank nicht zu beschädigen,
schreiben Transaktionen in der Lesephase nur auf lokale Kopien,
und nur nach erfolgreicher Validierung schreiben sie (in der
Schreibphase) in die Datenbank
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 34
Parallele Validierung (nach Kung & Robinson) (4)
Wenn es eine Abhängigkeit Tneu  Talt geben könnte, breche Tneu ab,
d.h. Tneu schreibt nicht in die Datenbank (Tneu hat keine Schreibphase)
Abhängigkeiten
Talt  Tneu sind o.K.
Talt
Zeit
Tneu
L
Lesephase
V
[& S]
Validierung
[ & Schreibphase ]
Validierung von Tneu verhindert diese Abhängigkeit
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 35
Validierung unterscheidet 3 Gruppen älterer Transaktionen
Zeit
Talt1  o.K.
r
Tneu wird bei jeder Abhängigkeit Tneu  Talt
abgebrochen (zyklische Abhängigkeit wäre möglich)
 writeSet(Talt2) ∩ readSet(Tneu) = 
Talt2
v
[& w]
r
Talt3
v
[& w]
Motivation / Fehlerklassen
Serialisierbarkeit
 writeSet(Talt3) ∩ readSet(Tneu) = 
und writeSet(Talt3) ∩ writeSet(Tneu) = 
Tneu
r
Lesephase
v
[& w]
Validierung
[& Schreibphase]
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 36
Implementierung der Validierungsphase von Tneu
Tneu unterteilt alle älteren Transaktionen in 3 Gruppen:
1. Talt1: Transaktionen, die beendet werden,
bevor Tneu in der Lesephase ist
2. Talt2: Transaktionen, die beendet werden,
während Tneu in der Lesephase ist
3. Talt3: Transaktionen, die beendet werden,
nachdem Tneu in der Lesephase war
Validierung liefert genau dann false,
wenn es eine T  Talt2 gibt mit writeSet(Talt2) ∩ readSet(Tneu) ≠  oder
wenn es eine T  Talt3 gibt mit
writeSet(Talt3) ∩ ( readSet(Tneu)  writeSet(Tneu) ) ≠ 
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 37
Korrektheit der parallelen Validierung
time
Told1  o.K.
r
Told2
v
[& w]
r
Tneu  Talt kann es nicht geben für
Talt1 , denn : ende von Talt1 vor start von Tneu
Talt2, Talt3, weil Validierung das ausschließt
Tneu validiert erfolgreich
 writeSet(Talt2) ∩ readSet(Tneu) = 
Told3  writeSet(Talt3) ∩ readSet(Tneu) = 
 writeSet(Talt3) ∩ writeSet(Tneu) = 
v
[& w]
Motivation / Fehlerklassen
Serialisierbarkeit
Tnew
r
Lesephase
v
[& w]
Validierung
[& Schreibphase]
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 38
Transaktionsprozedur zum Phantomproblem
TP1:
EXEC SQL insert into Konten values( KontoNr3, 3000 ) ;
TP2:
EXEC SQL select Count(KontoNr) into :Kontenanzahl
from Konten
if ( Kontenanzahl ≠ 0 ) // zeige Durchschnittsbetrag
{ EXEC SQL select SUM(KontoStand) into :Summe
from Konten
println(''Durchschnittsbetrag ist :'',
Summe / Kontenanzahl ) ;
}
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 39
Transaktionen zum Phantomproblem
T2 stellt fest, dass KontoNr3 nicht existiert
< T2: Start >
< T2: read(KontoNr1) >
< T2: read(KontoNr2) >
< T2: not exists(KontoNr3) >
< T1: Start >
< T1: insert (KontoNr3 , 3000 ) >
< T1: Commit >
< T2: read(KontoStand1) >
< T2: read(KontoStand2) >
< T2: read(KontoStand3) >
< T2: Commit >
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 40
Konflikt mit Phantom-Tupeln
T2 stellt fest, dass KontoNr3 nicht existiert
< T2: not exists(KontoNr3) >
< T1: insert (KontoNr3 , 3000 ) >
Vertauschung der Operationen ändert das Ergebnis  Konflikt
T2 stellt fest, dass KontoNr3 existiert
< T1: insert (KontoNr3 , 3000 ) >
< T2: read(KontoNr3) >
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 41
Prädikatives Sperren
Problem des physischen Sperrens:
Es sperrt die gelesenen Tupel der Relation, d.h. nur die
gelesenen und als wahr interpretierten Tupel des Schemas
Idee zur Verhinderung des Phantomproblems:
Sperre alle gelesenen Tupel des Schemas, auch die
als falsch interpretierten Tupel des Schemas
Realisierung:
Benutze Sperren mit Formeln (z.B. des Tupelkalküls) für
Mengen von gesperrten Tupeln des Schemas
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 42
Prädikatives Sperren - Beispiel
Betrag
rlock( T1 , { tKonto | t.Betrag > 5000 } )
5000
wlock( T2 , { tKonto | t.Name >= ‘Q‘ } )
Schema( Konto )
Name
Q
{ tKonto | t.Betrag > 5000 } ∩ { tKonto | t.Name >= ‘Q‘ } ≠  
t.Betrag > 5000  t.Name >= ‘Q‘ ist erfüllbar  T2 Sperre nicht gewähren
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 43
Prädikatives Sperren - Kritik
Hauptkritikpunkt:
Test für die Sperrvergabe braucht einen Beweis  dauert zu lange
Aber unvollständige Beweiser genügen O(Vergleichsanzahl³)
Im Zweifelsfall: Sperre nicht gewähren, d.h. Transaktion warten lassen
{ tKonto | t.Betrag > 5000 } ∩ { tKonto | t.Name >= ‘Q‘ } ≠  
t.Betrag > 5000  t.Name >= ‘Q‘ ist erfüllbar  T2 Sperre nicht gewähren
Alternativvorschläge:
1. Indexsperren (konzeptuell: eingeschränkte prädikative Sperren)
2. Sperren der EOF-Marke (Hauptkritikpunkt: blockiert alle Einfüger)
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 44
Prädikative Validierung
Idee zur Verhinderung des Phantomproblems:
Benutze zur Validierung Anfrage statt Beweis
T validiert von ihr geschriebene alte und neue Werte
von Tupeln der Relation gegen Formeln (z.B. des Tupelkalküls)
der Lese- und Schreibmengen älterer Transaktionen,
d.h. Formeln beschreiben von älteren Transaktionen
gelesene bzw. geschriebene Tupel des Schemas
+ möglich durch Anfrage  effizient durchführbar
 in jedem DBMS implementierbar
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 45
Prädikative Validierung - Beispiel
Betrag
read-set( Talt , { tKonto | t.Betrag > 5000 } )
write-set( Tneu ,
6000
5000
4000
+
Konto + { ( Name=‘Reich‘, Betrag=6000 ) }
-
Konto - { ( Name=‘Reich‘, Betrag=4000 ) }
)
Schema( Konto )
Name
Q Reich
{ t { ( Name=‘Reich‘, Betrag=6000 ) , ( Name=‘Reich‘, Betrag=4000 ) } | t.Betrag > 5000 } ≠ 
 Validierung von Tneu scheitert  Tneu abbrechen und neu starten
Motivation / Fehlerklassen
Serialisierbarkeit
2-Phasen-Sperren
Validierung
Prädikative Synchronisation
Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher – Folie 9 - 46