pptx - Institut für Informationssysteme

Datenbanken
Prof. Dr. Ralf Möller
Universität zu Lübeck
Institut für Informationssysteme
Marc Stelzner (Übungen)
Torben Matthias Kempfert (Tutor)
Maurice-Raphael Sambale (Tutor)
Transaktionsverwaltung
Architecture of a DBMS / Course Outline
Applications
Anwendungen
SQL
Interface
SQL-Schnittstelle
Figure inspired by Ramakrishnan/ Gehrke: “Dat abase Management Systems”, McGraw-Hill 2003.
Webformulare
Web
Forms
Ausführer
Executor
Parser
Parser
Operator
Evaluator
Operator-Evaluierer
Optimizer
Optimierer
Transaction
Transaktions
Manager
Dateiverwaltungsund Zugriffsmethoden
Files and Access
Methods
Verwalter
Puffer-Verwalter
Buffer
Manager
Lock
SperrVerwalter
Manager
Verwalter
für Manager
externen
Disk
Space
RWiederecovery
herstellungsManager
Verwalter
dieser Teil des
thiscourse
Kurses
SQL-Kommandos
SQLCommands
Speicher
DBMS
Dateien
für Daten
und Indexe...
data
files,
indices,
Fall 2008
Datenbank
Database
Systems Group — Department of Computer Science — ETH Zürich
3
2
Danksagung
• Diese Vorlesung ist inspiriert von den Präsentationen
zu dem Kurs:
„Architecture and Implementation of Database
Systems“
von Jens Teubner an der ETH Zürich
• Graphiken und Code-Bestandteile wurden mit
Zustimmung des Autors (und ggf. kleinen
Änderungen) aus diesem Kurs übernommen
3
Eine einfache Transaktion
The “Hello World” of Transaction Management
• Ab und zu verwende ich meine Kreditkarte, um Geld
I My bank issued me a debit card to access my account .
von meinem Konto abzuheben
I Every once in a while, I’d use it at an ATM to draw some
• Der
Bankautomat führt folgende Transaktion auf der
money from my account, causing the ATM to perform a
Datenbasis der Bank aus
transaction in the bank’s database.
1
2
3
I
bal
r ead bal ( acct no) ;
bal
bal − 100 CHF;
wr i t e bal ( acct no, bal) ;
My account is properly updated to reflect the new balance.
• Wenn alles fehlerfrei abläuft, wird mein Konto richtig
verwaltet
4
Nebenläufiger
Concurrent
Access Zugriff
The problem is: My wife has a card for the account, too.
Mein
Frau verwendet eine Karte für das gleiche Konto...
I We might end up using our cards at different ATMs at the
same time. verwenden wir unsere Karten zur gleichen
• Eventuell
Zeit
me
bal
bal
my wife
DBstate
r ead ( acct) ;
bal
r ead ( acct) ;
bal
bal − 200 ;
bal − 100 ;
wr i t e ( acct, bal) ;
wr i t e ( acct, bal) ;
I
1200
1200
1200
1200
1100
1000
The first update was lost during this execution. Lucky me!
• Die erste Aktualisierung des Kontos
ist verlorengegangen: Mich freut‘s! Allerdings...
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
201
5
... kann es auch nach hinten losgehen
Another
Example
• Diesmal
wird Geld von einem Konto auf ein anderes
I
This time, I want to transfer money over to another account .
transferiert
1
2
3
4
5
6
/ / Subtract money from source (checking) account
chk bal
r ead bal ( chk acct no) ;
chk bal
chk bal − 500 CHF;
wr i t e bal ( chk acct no, chk bal) ;
/ / Credit money to the target (saving) account
sav bal
r ead bal ( sav acct no) ;
sav bal
sav bal + 500 CHF;
wr i t e bal ( sav acct no, sav bal) ;
• I Bevor
die
Transaktion
zum
Schritt is6 kommt, wird die
Before the
transaction
gets to step
6, its execution
interrupted/ cancelled
(power outage, disk failure, software
Ausführung
abgebrochen
bug, ...). My money is lost / .
(Stromversorgungsproblem, Plattenproblem,
Softwarefehler, ...).
• Mein Geld ist verschwunden 
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
202
6
ACID-Eigenschaften und Transaktionen
Um diese und viele andere Effekte zu vermeiden,
stellen DMBS folgende Eigenschaften sicher
• Atomicity: Entweder werden alle oder keine
Werteänderungen einer Transaktion in den
Datenbankzustand übernommen
• Consistency: Eine Transaktion überführt einen
konsistenten Zustand (FDs, Integritätsbedingungen) in
einen anderen
• Isolation: Eine Transaktion berücksichtigt bei der
Berechnung keine Effekte andere parallel laufender
Transaktionen
• Durability: Effekte einer erfolgreichen Transaktion werden
persistent gemacht
7
Anomalien: Lost Update
• Wir haben schon „Lost Update“ im Beispiel
betrachtet
• Effekte einer Transaktion gehen verloren, weil eine
andere Transaktion geänderte Werte unkontrolliert
überschreibt
8
Anomalien:
Inconsistent
Anomalies:
Inconsistent
ReadRead
Consider the money transfer example (slide 202), expressed in
Betrachten
SQLsyntax: wir die Überweisung in SQL
Transaction 1
Transaction 2
UPDATE Account s
SET bal ance = bal ance - 500
WHERE cust omer = 4711
AND account _t ype = ’ C’ ;
SELECT SUM( bal ance)
FROM Account s
WHERE cust omer = 4711;
UPDATE Account s
SET bal ance = bal ance + 500
WHERE cust omer = 4711
AND account _t ype = ’ S’ ;
 ITransaktion
2 sieht
einen inkonsistenten
Transaction 2 sees
an inconsistent
database state. Zustand
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
206
9
Anomalien: Dirty Read
Anomalies: Dirty Read
An
anderen
Tag
heben
und ich zur
At a einem
different day,
my wife and
me again
end upmeine
in front ofFrau
an
ATM at roughly
the same
time:
gleichen
Zeit
Geld
vom Automaten ab
me
my wife
DBstate
bal
r ead ( acct) ;
bal
bal − 100 ;
wr i t e ( acct, bal) ;
bal
bal
r ead ( acct) ;
bal − 200 ;
abor t ;
wr i t e ( acct, bal) ;
1200
1200
1100
1100
1100
1200
900
My wife’s
transaction has
already read
the modified
account einen
 IDie
Transaktion
meiner
Frau
hat schon
balance before my transaction was rolled back.
geänderten
Zustand gelesen bevor meine
Transaktion zurückgerollt wird
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
207
10
Nebenläufige Ausführung
Concurrent Execution
• Ein Steuerprogramm (Scheduler) entscheidet über
die Ausführungsreihenfolge der nebenläufigen
I The scheduler decides the execution order of concurrent
Datenbankzugriffe
database
accesses.
Client 1
Client 2
3
2
1
2
1
Client 3
3
2
1
Scheduler
2
1
1
Access and Storage Layer
11
Datenbankobjekte und Zugriffe daraus
• Wir nehmen ein vereinfachtes Datenmodell an
– Eine Datenbank besteht aus einer Menge von
benannten Objekten. In jedem Zustand hat ein Objekt
einen Wert.
– Transaktionen greifen auf ein Objekt o mit den
Operationen read und write zu
• In einer relationalen DB haben wir:
Objekt ≙ Komponente eines Tupels
12
Transaktion: Definition
Transactions
A database transaction T is a (strictly ordered) sequence of steps.
• Eine Datenbanktransaktion ist eine (strikt geordnete)
Each step is a pair of an accessoperation applied to an object.
Folge von Schritten, wobei ein Schritt eine
I Transaction T = hs1, . . . , sn i
Zugriffsoperation auf ein Objekt ist
I Step si = (ai , ei )
– Transaktion T = <s1, ..., sn>
I Access
operation
– Schritt
si = (ai, eai)i 2 { r (ead), w(r i t e)}
The length
of a transaction
its number
– Zugriffsoperation
ai ∈T{isr(ead),
w(rite)of} steps |T| = n.
• Die Länge einer Transaktion ist definiert als die
We could write the money transfer transaction as
Anzahl der Schritte |T| = n
3
• Beispiel:
T =ead,
<(read,
Checking),
(write,
Checking),
T = h(r
Checking),
(wr i t e,
Checking),
2
Saving),
(r ead, Saving), (wr(read,
i t e, Saving)
i (write,
Saving)>
or, more concisely,
• Kurzform: T = <r(C), w(C), r(S), w(S)>
T = hr(C), w(C), r(S), w(S)i .
1
13
Ausführungspläne
edules
Ein (Ausführungs-)Plan (Schedule) S für eine gegebene
schedule
Sforvon
a given
set of transactions
T =, ...,
{ T1,T. . }. ,ist
Tn }eine
is anFolge
Menge
Transaktionen
T = {T
1
n
rbitrary
of execution steps
vonsequence
Ausführungsschritten
2
1
S(k) = (Tj , aS(k)
k j=, a1.i, .e. im
) , k = 1...m
i , ei ) = (T
1
so dass
uch that
1. Sallgenau
aller Transaktionen
und
1. Scontains
steps die
of allSchritte
transactions
an nothing elseenthält
and
2. the orderdie
among steps in each transaction Tj is preserved:
(ap2.
, epOrdnung
) < (aq , eqder
) in Schritte
Tj ) (Tj ,jeder
ap , ep )Transaktion
< (Tj , aq , eq )beibehalten
in S .
wird
We sometimes
(awrite
p , ep) < (aq , eq) in Tj, dann (Tj , ep , ep) < (Tj , aq , eq)
in SS= hr1(B), r2(B), w 1(B), w 2(B)i
o mean
Wir schreiben S = <r1(B), r2(B), w1(B), w2(B)> für
S(1) = (T1, r ead, B) S(3) = (T1, wr i t e, B)
S(1)
=2(T
, read,
B)
S(2)
= (T
, r 1ead,
B) S
(4) = (T2, wr i t e,S(3)
B) = (T1, write,
14
Serielle Ausführung
Serial
Execution
Ein
spezieller
Plan ist die serielle Ausführung
• EinOne
Plan
heißtschedule
seriell isgenau
dann, wenn für jede
particular
serial execution.
Transaktion
Tj Sis
alleserial
ihreiff,Schritte
direkt t ransaction Tj , all
I A schedule
for each contained
its steps follow each
otherSchritte
(no interleaving
of t ransactions).
aufeinanderfolgen
(ohne
anderer
Transaktion dazwischen)
2
Consider again the ATM example from slide 201.
2
Betrachten
das
Geldautomatenbeispiel:
I S= wir
hr 1(B),
r2(B),
w 1(B), w 2(B)i
1
1
schedule is not serial.
• S = I <rThis
1(B), r2(B), w1(B), w2(B)>
• Dieser
Plan ist nicht seriell
If my wife had gone t o the bank one hour later, “our” schedule
been serial.
Wennprobably
meinewould
Frauhave
später
zum Automaten geht, ergibt
2
1
sich I S= hr1(B), w 1(B), r2(B), w 2(B)i
2
1
• S = <r1(B), w1(B), r2(B), w2(B)>
• Dieser Plan ist seriell
Fall 2008
Syst ems Group — Depart ment of Comput er Science — ETH Zürich
212
15
Korrektheit der seriellen Ausführung
• Anomalien können nur auftreten, wenn die Schritte
mehrerer Transaktionen verschränkt ausgeführt
werden (Multi-User-Modus)
• Falls alle Transaktionen bis zum Ende ausgeführt
werden (keine Nebenläufigkeit), treten
keine Anomalien auf
• Jede serielle Ausführung ist korrekt
• Verzicht auf nebenläufige Ausführung nicht
praktikabel, da zu langsam (Wartezeit auf Platten)
• Jede verschränkte Ausführung, die einen gleichen
Zustand wie eine serielle erzeugt, ist korrekt
16
Konflikte
• Was bedeutet es, dass ein Plan S äquivalent zu
einem anderen S‘ ist?
• Manchmal kann man einfach Teilschritte aus
verschiedenen Transaktionen in einem Plan
umordnen
– Nicht jedoch die Teilschritte innerhalb einer einzelnen
Transaktion (sonst eventuell anderes Ergebnis)
• Zwei Operationen (a, e) und (a‘, e‘) stehen in
Konflikt zueinander (a, e) ⇎ (a‘, e‘), wenn ihre
Ausführungs-reihenfolge bedeutsam ist
– Umordnung in einem Plan dann nicht möglich
• Jeder Plan S‘, der durch legale Umordnung von S
generiert werden kann, heißt konfliktäquivalent zu S
17
Konflikte
Ausführbare Definition
eines Konflikts:
Conflicts
Conflicts
• Based
Zweion
Operationen
und
a‘,
e‘) asind
income
Konflikt
our r ead/ wBased
r i t e(T
model,
we
can come
with
more
on
oure)
r ead/
wr(T
i tj,eup
model,
we
can
up with a m
i, a,
zueinander indefinition
S,
wenn
machine-friendly
of a conflictdefinition
.
machine-friendly
of a conflict .
–I
–
–
0
0
0 0
Twozu
operations
(TIi , a,Two
e) and
(T
are
ine)
conflict
inj , Sif
j , a , e )(T
operations
and (T
a(T
,e
are
sie
zwei verschiedenen
Transaktionen
gehören
i , a,
i ≠) T
j) in conflict i
theygleiche
belong Objekte
to two1.different
transactions(T
=und
Tj ), transactions(Ti 6
they
belong
to (e
two
= T
sie1.das
referenzieren
= different
e‘)i 6
0
2. they access the samethey
database
object,
i.e., e database
= e , and object, i.e., e = e0
access
same
mindestens eine der 2.
Operationen
athe
oder
a‘ eine
3. at least one of them
wr i t e
operation.
3. is
ataleast
one
of them is a wr i t e operation.
Schreiboperation
ist
I This inspires the following conflict matrix:
I This inspires the following conflict matrix:
• Hierdurch ist eine sog. Konfliktmatrix
definiert
r ead wr i t e
r ead wr i t e
r ead
⇥
r ead
⇥
wr i t e
⇥
⇥
wr i t e
⇥
⇥
I
Conflict
relation
≺
:
Konfliktrelation S
I Conflict relation
0 0 ≺ S:
• Konfliktrelation (T
i , a, e) ≺ S (Tj , a , e )
(Ti , a, e) ≺ S (Tj , a0, e0)
:=
:= Ti 6
(a, e) = (a0, e0) ^ (Ti , a, e) occurs
before
= Tj
kommt
vor (Tj , a0, e0) in S^
(a, e) = (a0, e0) ^ (Ti , a, e) occurs before (Tj , a0, e0) in 18
S^ T
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
215
Konflikt-Serialisierbarkeit
• Ein Plan S heißt Konflikt-serialisierbar, gdw. er
Konflikt-äquivalent ist zu einem seriellen Plan S‘
• Die Ausführung eines Konflikt-serialisierbaren Plans S
ist korrekt (S braucht nicht seriell zu sein)
• Korrektheit eines Plans kann anhand des
Konfliktgraphen GS gezeigt werden (auch
Serialisierungsgraph genannt)
– Knoten von GS sind die Transaktionen Ti aus S
– Kanten Ti ⟶ Tj werden hinzugefügt, gdw. S
Operationen
(Ti, a, e) und (Tj, a‘, e‘) enthält, so dass (Ti, a, e) ≺S (Tj,
a‘, e‘)
• S ist Konflikt-serialisierbar, wenn GS zyklenfrei ist
19
Serialisierungsgraph
Serialization Graph
Beispiel:
ATM-Transaktion
Example:
ATM
transactions (% slide 201)
I
I
S= hr1(A), r2(A), w 1(A), w 2(A)i
Konfliktrelation:
Conflict
relation:
(T1, r , A) ≺ S (T2, w, A)
(T2, r , A) ≺ S (T1, w, A)
(T1, w, A) ≺ S (T2, w, A)
T2
T1
! not serializable
nicht
serialisierbar
Beispiel:
Example:
TwoZwei
moneyGeldtransfers
transfers (% slide 202)
I
S= hr1(C), w 1(C), r2(C), w 2(C), r1(S), w 1(S), r2(S), w 2(S)i
I
Konfliktrelation:
Conflict
relation:
(T1, r , C) ≺ S (T2, w, C)
(T1, w, C) ≺ S (T2, r , C)
(T1, w, C) ≺ S (T2, w, C)
..
.
Fall 2008
T2
T1
!serialisierba
serializable
r
Systems Group — Department of Computer Science — ETH Zürich
217
20
Sperren im Anfrageplan
Query Scheduling
Können
einen
Scheduler
bauen, der
immer einen
Canwir
we build
a scheduler
that alwaysemits
a serializable
Query Scheduling
schedule?
serialisierbaren
Plan generiert?
Can weIdea:
build a scheduler that alwaysemits a serializable
Idee:
schedule?
I Require each transaction to
Client 1 Client 2 Client 3
• Idea:
Lasse jede
eine
obtainTransaktion
a lock before it accesses
2
3
3
2
2
I Require each
Client
1 Client 2 Client 3
1
transaction
Sperre
auf
aakquirieren,
data
object o:to bevor
1
1
obtain a lock before it accesses
2
3
3
eina data
Datum
zugegriffen
wird
Scheduler
2
2
1
object o:
2
l ock o ;
2 ...access o ...;
l ock o ;
3 unl ock o ;
...access
o ...;
3
unl ock o ;
1
1
1
2
1
1
Scheduler
2
1
1
Access and Storage Layer
This prevents concurrent
Access and Storage Layer
access
to o.
This prevents
concurrent
I
I
1
access to o.wird ein nebenläufiger
• Dadurch
Zugriff auf o verhindert
Fall 2008
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
Systems Group — Department of Computer Science — ETH Zürich
218
218
21
Sperr-Verwaltung
• Falls eine Sperre nicht zugeteilt wird (z.B. weil eine
andere Transaktion T‘ die Sperre schon hält), wird
die anfragende Transaktion T blockiert
• Der Verwalter setzt die Ausführung von Aktionen
einer blockierten Transaktion T aus
• Sobald T‘ die Sperre freigibt, kann sie an T
vergeben werden (oder an eine andere Transaktion,
die darauf wartet)
• Eine Transaktion, die eine Sperre erhält, wird
fortgesetzt
• Sperren regeln die relative Ordnung der
Einzeloperationen verschiedener Transaktionen
22
Aufgabe:
• Reicht die Idee der Sperrverwaltung aus, um
Serialisierbarkeit
zu garantieren?
ATM Transaction
with Locking
Transaction 1
Transaction 2
l ock ( acct) ;
r ead ( acct) ;
unl ock ( acct) ;
DBstate
1200
l ock ( acct) ;
r ead ( acct) ;
unl ock ( acct) ;
l ock ( acct) ;
wr i t e ( acct) ;
unl ock ( acct) ;
1100
l ock ( acct) ;
wr i t e ( acct) ;
unl ock ( acct) ;
1000
23
ATM-Transaktion mit Sperren
ATM Transaction with Locking
Transaction 1
Transaction 2
l ock ( acct) ;
r ead ( acct) ;
unl ock ( acct) ;
DBstate
1200
l ock ( acct) ;
r ead ( acct) ;
unl ock ( acct) ;
l ock ( acct) ;
wr i t e ( acct) ;
unl ock ( acct) ;
1100
l ock ( acct) ;
wr i t e ( acct) ;
unl ock ( acct) ;
Fall 2008
1000
Systems Group — Department of Computer Science — ETH Zürich
221
24
Zwei-Phasen-Sperrverwaltung
o-Phase
(2PL)
• DasLocking
Zwei-Phasen-Sperrprotokoll
(Two-Phase
Locking,
2PL)
führt eine
Einschränkung
The two-phase
locking
protocol
posesweitere
an additional
restriction: ein
I
• Sobald
eine Transaktion
eine
Sperre
Once
a transaction
has released any
lock,
it must freigegeben
not acquire
anyhat,
new darf
lock. sie keine weiteren Sperren anfordern
# gehaltene
# of locks
Sperren
held
Zeit
time
lock
phase
Sperrphase
I
release
phase
Freigabe-Phase
• Zwei-Phasen-Sperrprotokoll wird in jedem
Two-phase
locking is the concurrency
Datenbanksystem
verwendetcontrol protocol used
in database systems today.
25
Aufgabe:
o-Phase
Locking
(2PL) nicht auf einmal angefordert
• Warum
werden Sperren
bzw. zurückgegeben?
The two-phase locking protocol poses an additional restriction:
I
Once a transaction has released any lock, it must not acquire
any new lock.
# gehaltene
# of locks
Sperren
held
Zeit
time
lock
phase
Sperrphase
I
release
phase
Freigabe-Phase
Two-phase locking is the concurrency control protocol used
in database systems today.
26
Noch einmal: ATM-Transaktion
Again: ATM Transaction
Transaction 1
Transaction 2
DBstate
l ock ( acct) ;
r ead ( acct) ;
unl ock ( acct) ;
✓
l ock ( acct) ;
wr i t e ( acct) ;
unl ock ( acct) ;
1200
l ock ( acct) ;
r ead ( acct) ;
unl ock ( acct) ;
1100
✓
l ock ( acct) ;
wr i t e ( acct) ;
unl ock ( acct) ;
Fall 2008
1000
Systems Group — Department of Computer Science — ETH Zürich
223
27
Eine 2PL-konforme Transaktion
I
To comply with the two-phase locking protocol, the ATM
must not
acquire
any new locks
after a first lock
• transaction
Zweiphasigkeit
muss
eingehalten
werden
has been released.
1
2
3
4
5
Fall 2008
l ock ( acct) ;
bal
r ead bal ( acct) ;
bal
bal − 100 CHF;
wr i t e bal ( acct, bal) ;
unl ock ( acct) ;
lock phase
unlock phase
Systems Group — Department of Computer Science — ETH Zürich
224
28
Entstehender
Resulting
ScheduleAbarbeitungsplan
Transaction 1
Transaction 2
l ock ( acct) ;
r ead ( acct) ;
wr i t e ( acct) ;
unl ock ( acct) ;
DBstate
1200
l ock ( acct) ;
Transaction
blocked
r ead ( acct) ;
wr i t e ( acct) ;
unl ock ( acct) ;
1100
900
• The
Verwendung
von Sperren führt zu einem korrekten
use of locking lead to a correct (and serializable)
(und serialisierbaren) Plan
schedule.
I
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
225
29
Sperrarten
(Sperrmodi)
Lock Modes
Wegesehen,
saw earlierdass
that two
read
operations do not nicht
conflict w
• Wir haben
zwei
Leseoperationen
each other.
in Konflikt zueinander stehen
I Systems typically use different types of locks (“lock mode
• Systeme verwenden verschiedene Arten von Sperren
I
to allow read operations to run concurrently.
– Lesesperren
(read
locks,
shared
locks):
S
I
read
locksor
shared
locks:
modeModus
S
– Schreibsperren
(write locks,
exclusive
locks):XModus X
I
write locksor
exclusive
locks: mode
• Lock stehen
in Konflikt
zueinander,
wenn
eines
I Locksnur
are only
in conflict
if at least one
of them
is an Xlo
davon eine X-Sperre ist:
shared (S)
exclusive (X)
shared (S)
exclusive (X)
⇥
⇥
⇥
• Es ist Ieine
Operation
beim 2PL,
während
der a
It issichere
a safe operation
in two-phase
locking
to convert
Sperrphase
eine
in einelock
X-Sperre
zu lock phase.
shared
lockS-Sperre
into an exclusive
during the
konvertieren
30
Verklemmungen (Deadlocks)
• WieDeadlocks
bei vielen Sperrprotokollen, kann es beim ZweiLike many lock-based protocols,
two-phase
locking has the
Phasen-Sperrprotokoll
zu
Verklemmungen
kommen:
risk of deadlock situations:
I
Transaction 1
l ock ( A) ;
..
.
do something
..
.
l ock ( B)
[ wait for T2 to release lock ]
I
Transaction 2
l ock ( B)
..
.
do something
..
.
l ock ( A)
[ wait for T1 to release lock ]
Both transactions would wait for each other indefinitely.
• Durch Sperren ist der Ressourcenzugriff exklusiv
• Beide Transaktionen warten wechselseitig aufeinander
• Ressource werden nicht einzeln entzogen (no
preemption)
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
227
31
Behandlung von Verklemmungen
Erkennung von Verklemmungen:
• System verwaltet einen Wartet-auf-Graphen, in dem
einen Kante T1 ⟶ T2 bedeutet, dass T1 blockiert ist
durch eine Sperre, die von T2 gehalten wird
• Periodisch wird nach Zyklen in diesem Graph
gesucht
• Wenn Zyklus entdeckt, wird die Verklemmung durch
Abbruch (abort) einer der Transaktionen aufgelöst
• Wahl des Opfers durchaus schwierig:
– Abbruch junger Transaktionen führt zu
Mehrfachausführung
– Abbruch alter Transaktionen führt zu Verlust von
vielen ausgeführten Operationen
32
Deadlock prevention: e.g., by treating handling lock requests
in an asymmetric way:
I
wait-die: A transaction is never blocked by an older
transaction.
I
wound-wait: A transaction
is never blocked by a
Zeitüberschreitung
(Timeout):
younger transaction.
I
Behandlung von Verklemmungen
•I Timeout:
Warte nur
auf Sperre bis Zeitüberschreitung eintritt, sonst
Only wait for a lock until a timeout expires.
nehme Verklemmung
an und
brecheand
ababort.
Otherwise
assume that a deadlock
has occurred
I
E.g., IBM DB2 UDB:
db2 => GET DATABASE CONFI GURATI ON;
..
.
I nt er val f or checki ng deadl ock ( ms)
Lock t i meout ( sec)
( DLCHKTI ME) = 10000
( LOCKTI MEOUT) = - 1
229
Bankier-Algorithmus (leider Ressourcen nicht a priori
bekannt)
Wikipedia
Systems Group — Department of Computer Science — ETH Zürich
Vermeidung
von Verklemmungen:
• Wait-Die
• Wound-Wait
Fall 2008
33
Wait-Die
• Fordert eine Transaktion eine Sperre an, die von
einer jüngeren gehalten wird, so wartet die ältere bis
die Sperre von der jüngeren freigegeben wird.
• Fordert eine Transaktion eine Sperre an, die von
einer älteren gehalten wird, so bricht sie sich selber
ab
(genauer: sie startet neu, allerdings behält sie ihren
alten Zeitstempel bei, um so „älter“ zu wirken und
ihre Chancen zu erhöhen, diesmal komplett
durchlaufen zu können)
[Wikipedia]
34
Wound-Wait
• Fordert eine Transaktion eine Sperre an, die von
einer jüngeren gehalten wird, so wird die jüngere
abgebrochen (genauer: neu gestartet) und die ältere
bekommt die Sperre zugewiesen.
• Fordert eine Transaktion eine Sperre an, die von
einer älteren gehalten wird, so wartet sie, bis die
Sperre von der älteren wieder freigegeben wird.
[Wikipedia]
35
Varianten des Zwei-Phasen-Sperrprotokolls
Variants of Two-Phase Locking
• Es gibt Freiheitsgrade bzgl. der Akquise- und
I The two-phase locking protocol does not prescribe exactly
Rückgabezeit
von
when locks have
to Sperren
acquired and released.
• Mögliche
I PossibleVarianten
variants:
# gehaltene
locks
Sperren
held
# gehaltene
locks
Sperren
held
Zeit
time
“lock
phase”
Sperrphase
release
phase
Freigabe-Phase
preclaiming
2PL
2PL mit
Voranforderung
I
Zeit
time
lock phase “release
phase”
Sperrphase
Freigabe-Phase
strict 2PL
striktes 2PL
What could motivate either variant?
• Wodurch könnten die Varianten motiviert sein?
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
230
36
Aufgabe:
o-Phase
Locking
(2PL)
• Waskann
passieren,
wenn Sperren nicht in einem Schritt
zurückgegeben werden?
The two-phase locking protocol poses an additional restriction:
I
Once a transaction has released any lock, it must not acquire
any new lock.
# gehaltene
# of locks
Sperren
held
Zeit
time
lock
phase
Sperrphase
I
release
phase
Freigabe-Phase
Two-phase locking is the concurrency control protocol used
in database systems today.
37
Kaskadierendes Rücksetzen
Cascading Rollbacks
Betrachten
wir drei Transaktionen
Consider
three transactions:
T1
T2
T3
abor t ;
✓
w(x)
r(x)
r(x)
time
t1 t2
• Wenn Transaktion T1 abgebrochen und zurückgerollt wird,
I When transaction T1 aborts, transactions T2 and T3 have
haben
Transaktionen T und T schon Daten gelesen, die
already read data written by T21 (% dirty3 read, slide 207)
von TT erzeugt
wurden
(Dirty
Read)
I T2 and 2
need
to
be
rolled
back,
too.
3
•I T
undT3Tcannot
ebenfalls
zurückgerollt
3 müssen
T22and
commit
until the fate
of T1 is known.werden
•I T
können
nichttwo-phase
abgeschlossen
two-phase
vs. strict
locking werden bis T1
2 und T3locking
fertig ist
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
246
• Zwei-Phasen-Sperrung vs. strikte Zwei-Phasen-Sperrung 38
Phantom-Problem
Phantom Problem
Transaction 1
Transaction 2
Effect
insert new row into R;
commi t ;
T1 locks all rows
T2 locks new row
T2’s lock released
reads new row, too!
scan relation R;
scan relation R;
Although
both transactions
followed the 2PLfolgen,
• IObwohl
beide
Relationenproperly
dem 2PL-Protokoll
protocol,
T1 observed
effect
sieht
T1 einen
Effektanvon
T2caused by T2.
I Cause of the problem: T1 can only lock existing rows.
• Ursache des Problems:
I Possible solutions:
T1 kann nur existierende Tupel sperren
I
I
Key range locking, typically in B-trees
Predicate locking
39
Implementierung eines Sperrverwalters
Ein Sperrverwalter muss drei Aufgaben effektiv
erledigen:
1. Prüfen, welche Sperren für eine Ressource gehalten
werden (um eine Sperranforderung zu behandeln)
2. Bei Sperr-Rückgabe müssen die Transaktionen, die die
Sperre haben wollen, schnell identifizierbar sein
3. Wenn eine Transaktion beendet wird, müssen alle von
der Transaktion angeforderten und gehaltenen Sperren
zurückgegeben werden
Wie muss eine Datenstruktur aussehen, mit der diese
Anforderungen erfüllt werden können?
40
Datenstruktur zur Buchführung
Bookkeeping
Transaction ID
Update Flag
TX Status
# of Locks
hash table,
indexed by resource ID
..
.
..
.
Resource Control Block (RCB)
Resource ID
Hash Chain
First In Queue
...
Transaction
Control Block
(TCB)
..
.
LCB Chain
..
.
Transaction ID
Resource ID
Lock Mode
Lock Status
Next in Queue
LCB Chain
Transaction ID
Resource ID
Lock Mode
Lock Status
Next in Queue
LCB Chain
...
Lock Control Blocks (LCBs)
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
232
41
Implementierung von Aufgaben
1. Sperren für eine Ressource können über
Hashzugriff gefunden werden
– Verkettete Liste der Lock Control Blocks über ‚First In
Queue/Next in Queue‘ (alle Anfragen enthalten,
stattgegeben oder nicht)
– Transaktion(en) am Kopf der Liste hält/halten Sperre
für die Ressource
2. Wenn eine Sperre zurückgegeben wird (LCB aus
der Liste entfernt), können die nächsten
Transaktionen berücksichtigt werden
3. Sperren einer beendeten Transaktion können über
‚LCB Chain‘ identifiziert und zurückgegeben
werden
42
Granularität des Sperrens
Granularity of Locking
Die
Granularität
des Sperrens
The granularity
of locking
is a trade-off:unterliegt Abwägung
database level
low concurrency
low overhead
high concurrency
high overhead
tablespace level
table level
page level
row-level
 ISperren mit multipler Granularität
Idea: multi-granularity locking
43
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
234
Sperren mit multipler Granularität
• Entscheide die Granularität von Sperren für jede
Transaktion (abhängig von ihrer Charakteristik)
– Tupel-Sperre z.B. für
SELECT *
FROM CUSTOMERS
WHERE C_CUSTKEY = 42
Q1
– und eine Tabellen-Sperre für
SELECT * FROM CUSTOMERS
Q2
• Wie können die Sperren für die Transaktionen
koordiniert werden?
– Für Q2 sollen nicht für alle Tupel umständlich
Sperrkonflikte analysiert werden
44
Vorhabens-Sperren
Intention Locks
Datenbanken
setzten Vorhabens-Sperren (intention
locks) für verschiedenen Sperrgranularitäten ein
Databases use an additional type of locks: intention locks.
• Sperrmodus
Intention Share: IS
I Lock mode intention share: I S
• Sperrmodus
Intention
Exclusive:
IX
I Lock mode intention
exclusive:
IX
I Conflict matrix:
• Konfliktmatrix:
S
X
IS IX
S
X ⇥
IS
IX ⇥
⇥
⇥
⇥
⇥
⇥
⇥
⇥
A lock I on a coarser level means that there’s some lock
a lower level.
EineonSperre
I☐ auf einer gröberen Ebene bedeutet,
I
•
dass es eine Sperre ☐ auf einer niederen Ebene
gibt
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
236
45
Vorhabens-Sperren
Protokoll für Sperren auf mehreren Ebenen:
1. Eine Transaktion kann jede Ebene g in Modus ☐ ∈ {S, X}
2. Bevor Ebene g in Modus ☐ gesperrt werden kann, muss
eine Sperre I☐ für alle gröberen Ebenen gewonnen werden
Anfrage Q1 würde
• eine IS-Sperre für Tabelle CUSTOMERS anfordern
(auch für Tablespace und die Datenbank) und dann
• eine S-Sperre auf dem Tupel mit C_CUSTKEY=42
akquirieren
Anfrage Q2 wurde eine
• S-Sperre für die Tabelle CUSTOMERS anfordern (und eine
IS-Sperre auf dem Tablespace und der Datenbank)
46
Entdeckung von Konflikten
Nehmen wir an, folgende Anfrage ist zu bearbeiten
UPDATE CUSTOMERS
SET NAME = ‘John Doe‘
WHERE C_CUSTKEY = 17
Hierfür wird
• eine IX-Sperre auf Tabelle CUSTOMERS (und ...) sowie
• eine X-Sperre auf dem Tupel mit Kunde 17
Diese Anfrage ist
• kompatibel mit Q1 (kein Konflikt zw. IX und IS auf der
Tabellenebene)
• aber inkompatibel mit Q2 (die S-Sperre von Q2 steht in
Konflikt mit der IX-Sperre bzgl. Q3)
47
Konsistenzgarantien in SQL-92
In einigen Fall kann man mit einigen kleinen Fehlern
im Anfrageergebnis leben
• „Fehler“ bezüglich einzelner Tupel machen in
Aggregat-funktionen evtl. kaum bemerkbar
– Lesen inkonsistenter Werte (inconsistent read
anomaly)
• In SQL-92 kann man Isolations-Modi spezifizieren:
SET ISOLATION SERIALIZABLE;
• Es gibt weniger strikte Modi, unter denen die
Performanz höher ist (weniger Verwaltungsaufwand
z.B. für Sperren)
48
SQL-92 Isolations-Modi
• Read uncommitted (auch: ‘dirty read‘ oder ‘browse‘)
– Nur Schreibsperren akquiriert (nach 2PL)
• Read committed (auch ‘cursor stability‘)
– Lesesperren werden nur gehalten, sofern der
Zeiger auf das betreffende Tupel zeigt,
Schreibsperren nach 2PL
• Repeatable read (auch ‘read stability‘)
– Lese- und Schreibsperren nach 2PL akquiriert
• Serializable
– Zusätzliche Sperranforderungen, um
Phantomproblem zu begegnen
49
Resultierende
Konsistenzgarantien
Resulting Consistency Guarantees
isolation level
read uncommitted
read committed
repeatable read
serializable
•
dirty read
non-repeat. rd
phantom rd
possible
not possible
not possible
not possible
possible
possible
not possible
not possible
possible
possible
possible
not possible
Some implementations support more, less, or different
Einige
unterstützen mehr,
levelsImplementierungen
of isolation.
I
weniger
oder andere
(isolation levels)
I Few applications
really Isolationmodi
need serializability.
• Nur wenige Anwendung benötigen
(volle) Serialisierbarkeit
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
244
50
node 8
8500
node 7
6423
5012
6423
8280
node 3
node 1
5012
6330
4123
4222
4450
4528
58
node 2
node 4
node 9
node 5
node 6
9016
9200
mputer Science — ETH Zürich
8700
8808
8887
new node 9
8500
8570
8604
node 4
8700
9016
node 0
8280
8404
new separator
new entry
6423
8050
8105
node 6
9016
9200
8700
8808
8887
8500
8570
8604
node 2
6423
8050
8105
node 7
node 8
–
!
–
Must split node 4.
Knoten 4 aufgespalten
New separator goes into node 1
Neuer
Separator
Knoten
(including
pointer to in
new
page). 1
new entry
6423
8050
8105
!
6423
separator 6330
key 6330.eines Eintrags mit new
• Insert
Einfügung
Schlüssel
5012
6330
1
e).
• Betrachten wir eine Transaktion Tw, die etwas in
Insert: Examples (Insert with Leaf Split)
einen B-Baum einführt, was zu einer Splitoperation
führt
5012
6330
de 5
Nebenläufigkeit beim Indexzugriff
8700
9016
node 0
node 4
new node 9
51
Nebenläufigkeit beim Indexzugriff
• Nehme an, die Aufspaltung ist gerade erfolgt, aber
der neue Separator 6423 ist noch nicht etabliert
• Nehme weiterhin an, ein nebenläufiges Lesen in
Transaktion Tr sucht nach 8085
– Die Verzeigerung weist auf Knoten node1
– Knoten node1 enthält aber 8050 nicht mehr, also wird
der entsprechende Datensatz nicht gefunden
• Auch in B-Bäumen muss beim Umbau mit Sperren
gearbeitet werden!
52
Sperren und B-Baum-Indexe
Betrachten wir B-Baum-Operationen
• Für die Suche erfolgt ein Top-Down-Zugriff
• Für Aktualisierungen ...
– erfolgt erst eine Suche,
– dann werden Daten ggf. in ein Blatt eingetragen und
– ggf. werden Aufspaltungen von Knoten nach oben
propagiert
• Nach dem Zwei-Phasen-Sperrprotokoll ...
– müssen S/X-Sperren auf dem Weg nach unten
akquiriert werden (Konversion provoziert ggf.
Verklemmungen)
– müssen alle Sperren bis zum Ende gehalten werden
53
Sperren und B-Baum-Indexe
• Diese Strategie reduziert die Nebenläufigkeit
drastisch
• Alle Transaktionen müssen warten, um die Sperre
für die Wurzel des Index zu erhalten
• Wurzel wird dadurch zum Flaschenhals und
serialisiert alle (Schreib-)Transaktionen
• Zwei-Phasen-Sperrprotokoll nicht angemessen für
B-Baum-Indexstrukturen
54
Sperrkopplung
Betrachten wir den Schreibe-Fall (alle Sperren mit
Konflikt)
• Das Protokoll Write-Only-Tree-Locking (WTL)
garantiert Serialisierbarkeit
– Für alle Baumknoten n außer der Wurzel kann eine
Sperre nur akquiriert werden, wenn die Sperre für den
Elternknoten akquiriert wurde
– Sobald ein Knoten entsperrt wurde, kann für ihn nicht
erneut eine Sperre angefordert werden (2PL)
Und damit gilt:
• Alle Transaktionen folgen Top-Down-Zugriffsmuster
• Keine Transaktion kann dabei andere überholen
• WTL-Protokoll ist verklemmungsfrei
55
Aufspaltungssicherheit
• Wir müssen auf dem Weg nach unten in den B-Baum
Schreibsperren wegen möglicher Aufspaltungen halten
• Allerdings kann man leicht prüfen, ob ein Spaltung von
Knoten n die Vorgänger überhaupt erreichen kann
– Wenn n weniger als 2d Einträge enthält kommt es nicht zu einer
Weiterreichung der Aufspaltung nach oben
• Ein Knoten, der diese Bedingung erfüllt, heißt
aufspaltungssicher (split safe)
• Ausnutzung zur frühen Sperrrückgabe
– Wenn ein Knoten auf dem Weg nach unten als
aufspaltungssicher gilt, können alle Sperren der Vorgänger
zurückgegeben werden
– Sperren werden weniger lang gehalten
56
Sperrkopplungsprotokoll (Variante 1)
Lock Coupling Protocol (Variant 1)
1
2
3
4
5
6
1
2
3
4
5
6
7
Fall 2008
place Slock on root ;
root ;
current
while current is not a leaf node do
place Slock on appropriate son of current ;
release Slock on current ;
son of current ;
current
readers
writers
place Xlock on root ;
root ;
current
while current is not a leaf node do
place Xlock on appropriate son of current ;
son of current ;
current
if current is safe then
release all locks held on ancestors of current ;
Systems Group — Department of Computer Science — ETH Zürich
252
57
Erhöhung der Nebenläufigkeit
• Auch mit Sperrkopplung werden eine beträchtliche
Anzahl von Sperren für innere Knoten benötigt (wodurch
die Nebenläufigkeit gemindert wird)
• Innere Knoten selten durch Aktualisierungen betroffen
– Wenn d=50, dann Aufspaltung bei jeder 50. Einfügung
(2% relative Auftretenshäufigkeit)
• Eine Einfügetransaktion könnte optimistisch annehmen,
dass keine Aufspaltung nötig ist
– Bei inneren Knoten werden währende der Baumtraversierung
nur Lesesperren akquiriert (inkl. einer Schreibsperre für das
betreffende Blatt)
– Wenn die Annahme falsch ist, traversiere Indexbaum erneut
unter Verwendung korrekter Schreibsperren
58
Sperrkopplungsprotokoll (Variante 2)
Lock Coupling Protocol (Variant 2)
6
Modifikationen
für 1Schreibvorgänge
Modified
protocol fornur
writers:
1
2
3
4
5
6
7
8
9
10
place Slock on root ;
current
root ;
while current is not a leaf node do
son
appropriate son of current ;
if son is a leaf then
place Xlock on son ;
else
place Slock on son ;
release lock on current ;
current
son ;
if current is unsafe then
12
release all locks and repeat with protocol Variant 1;
11
16
Reader protocol remains unchanged.
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
59
254
Zusammenfassung
• Wenn eine Aufspaltung nötig ist, wird der Vorgang
abgebrochen und erneut aufgesetzt
• Die resultierende Verarbeitung ist korrekt, obwohl es
nach einem erneuten Sperren aussieht (was für
WTL nicht erlaubt ist)
• Der Nachteile von Variante 2 ist, das im Falle einer
Blattaufspaltung Arbeit verloren ist
• Es gibt viele Varianten dieser Sperrprotokolle
60
B+-Bäume ohne Lesesperren
B•+-trees
Readohne
Locks
Es gibtWithout
Vorschläge,
Lesesperren auf B-BaumKnoten
zu operieren
I Lehman and Yao (TODSvol. 6(4), 1981) proposed a protocol
• Anforderung:
ein any
Next-Zeiger
auf rechten
that does not need
read locks onzeigt
B-tree nodes.
I Requirement: a next pointer, pointing to the right sibling.
Geschwisterknoten
...
...
...
...
• Vorher
schon betrachtet: Verkettete Liste auf
I Chapter II: Linked list along the leaf level.
Blattebene
I Pointers provide a second path to find each node.
• Zeiger
stellen
zweiten
Pfad aufsplits)
Knoten
bereit
I This way,
mis-guided
(by concurrent
read operations
still find the nodeZugriffen
that they need.
• Beican
nebenläufigen
und Aufspaltung von
Knoten bleibt Zugriff
auf Gesamtinformation möglich
Lehman and Yao (TODS vol. 6(4), 1981
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
256
61
4
5
6
7
8
9
10
11
A
B
8700
9016
3
8105
8280
2
lock & read page B ;
create new page D and lock it ;
populate page D ;
set next pointer D ! C;
write D ;
set next pointer B ! D ;
adjust content of B ;
write B ;
lock & read A ;
adjust content of A ;
write A ;
5012
6423
8105
8280
1
8500
Einfügung mit Aufspaltung eines inneren
Insertion
KnotensWith Inner Node Split
D
C
All index
entries remained
at all
times.
• IAlle
Indexeinträge
sindreachable
zu jedem
Zeitpunkt
erreichbar
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
257
62
B-Baum-Zugriff beim Lesen
• Die Next-Zeiger ermöglichen Leseoperationen, Einträge
sogar inmitten einer Aufspaltung zu finden, auch wenn
einige Einträge schon auf eine neue Seite verschoben
wurden
• Während tree_search() können Lesetransaktionen auf die
Geschwister eine Knotens n zugreifen sofern
– in n kein entsprechender Eintrag gefunden wird und
– next kein Nullzeiger ist
• Es wird nur auf Geschwister mit gleichem Elternteil
verwiesen
• Schreibsperren halten Lesetransaktionen nicht vom
Zugriff auf eine Seite ab (Leser fordern keine Sperren
an)
63
• Dieses Protokoll wird von PostgreSQL verwendet
Sperren (Locks) und Indexsperren (Latches)
• Welches Annahmen müssen wir machen für Sperrfreien Lesezugriff?
• Sperren wollte wir ja nicht verwenden
• Leichtgewichtige Sperren für kurzfristige atomare
Ops
• Indexsperren induzieren wenige
Verwaltungsaufwand
(meist als Spinlocks implementiert)
• Sie sind nicht unter der Kontrolle des
Sperrverwalters (es gibt keine
Verklemmungsüberwachung oder automatisches
Zurückgeben der Sperren bei Transaktionsabbruch)
64
Optimistische Organisation der
Nebenläufigkeit
• Bisher waren wir pessimistisch
– Wir haben uns immer den schlimmste Fall vorgestellt
und durch Sperrverwaltung vermieden
• In der Praxis kommt der schlimmste Fall gar nicht
sehr oft vor (siehe auch die Isolationsmodi)
• Wir können auch das beste hoffen und nur im Fall
eines Konflikts besondere Maßnahmen ergreifen
• Führt auf die Idee der Optimistischen Kontrolle der
Nebenläufigkeit
65
Optimistische Organisation der
Nebenläufigkeit
Behandle Transaktionen in drei Phasen
• Lesephase: Führe Transaktion aus, aber schreibe
Daten nicht sofort auf die Platte, halte Kopien in
einem privaten Arbeitsbereich
• Validierungsphase: Wenn eines Transaktion
erfolgreich angeschlossen wird (commit), teste ob
Annahmen gerechtfertigt waren. Falls nicht, führe
doch noch einen Abbruch durch
• Schreibphase: Transferiere Daten vom privaten
Arbeitsbereich in die Datenbasis
66
Validierung von Transaktionen
Validierung wird üblicherweise implementiert durch
Betrachtung der
• Gelesenen Attribute (read set RS(Ti))
• Geschriebene Attribute (write set WS(Ti))
67
Validierung von Transaktionen
• Rückwärtsorientierte optimistische
Nebenläufigkeitsverwaltung
– Vergleich T bezüglich aller erfolgreich beendeter
(committed) Transaktionen
– Test ist erfolgreich, wenn Tc beendet wurde bevor T
gestartet wurde oder RS(T) ⋂ WS(Tc) = 
• Vorwärtsorientierte optimistische
Nebenläufigkeitsverwaltung
– Vergleiche T bezüglich aller laufenden Transaktionen
Tr
– Test ist erfolgreich, wenn WS(T) ⋂ RS(Tr) = 
68
Multiversions-Nebenläufigkeitsorganisation
Betrachten wir den folgenden Abarbeitungsplan
t
r1(x), w1(x), r2(x), w2(y), r1(y), w1(z)
Ist dieser Plan serialisierbar?
• Angenommen, wenn T1 y lesen möchte, sei der
„alte“ Wert vom Zeitpunkt t noch verfügbar
• Dann könnten wir eine Historie wie folgt erzeugen
r1(x), w1(x), r2(x), r1(y), w2(y), w1(z)
die serialisierbar ist
69
Multiversions-Nebenläufigkeitsorganisation
• Mit verfügbaren alten Objektversionen müssen
Leseschritte nicht länger blockiert werden
• Es sind „abgelaufene“, aber konsistente Werte
verfügbar
• Problem: Versionierung benötigt Raum und erzeugt
Verwaltungsaufwand (Garbage Collection)
• Einige Systeme unterstützen Schnappschussisolation
– Oracle, SQL Server, PostgreSQL
70
Wiederherstellung (Recovery)
Architecture of a DBMS / Course Outline
Applications
Anwendungen
SQL
Interface
SQL-Schnittstelle
Figure inspired by Ramakrishnan/ Gehrke: “Dat abase Management Systems”, McGraw-Hill 2003.
Webformulare
Web
Forms
Ausführer
Executor
Parser
Parser
Operator
Evaluator
Operator-Evaluierer
Optimizer
Optimierer
Transaction
Transaktions
Manager
Dateiverwaltungsund Zugriffsmethoden
Files and Access
Methods
Verwalter
Puffer-Verwalter
Buffer
Manager
Lock
SperrVerwalter
Manager
Verwalter
für Manager
externen
Disk
Space
RWiederecovery
herstellungsManager
Verwalter
dieser Teil des
thiscourse
Kurses
SQL-Kommandos
SQLCommands
Speicher
DBMS
Dateien
für Daten
und Indexe...
data
files,
indices,
Fall 2008
Datenbank
Database
Systems Group — Department of Computer Science — ETH Zürich
3
71
Wiederherstellung nach Fehlern
Drei Typen von Fehlern
• Transaktionsfehler (Prozessfehler)
– Eine Transaktion wird abgebrochen (abort)
– Alle Änderungen müssen ungeschehen gemacht
werden
• Systemfehler
– Datenbank- oder Betriebssystem-Crash,
Stromausfall, o.ä.
– Änderungen im Hauptspeicher sind verloren
– Sicherstellen, dass keine Änderungen mit Commit
verloren gehen (oder ihre Effekte wieder herstellen)
und alle anderen Transaktionen ungeschehen
gemacht werden
72
Wiederherstellung nach Fehlern
Drei Typen von Fehlern
• Transaktionsfehler (Prozessfehler)
• Systemfehler
• Medienfehler (Gerätefehler)
– Crash von Festplatten, Feuer, Wassereinbruch
– Wiederherstellung von externen Speichermedien
Trotz Fehler müssen Atomarität und Durabilität
garantiert werden (ACID-Bedingungen)
73
Beispiel:System
Systemausfall
Example:
Crash (or (oder
Media Medienfehler)
Failure)
T1
T2
T3
T4
T5
time
crash
• Transaktionen T1, T2 und T3 wurden vor dem Ausfall
I Transactions
T1, T2, and
the crash.
5 were committed before
erfolgreich
beendet
 TDauerhaftigkeit:
Es muss
sicher! Durability:
Ensuredie
thatEffekte
updatesbeibehalten
are preserved (or
redone).
gestellt
werden, dass
werden
oder
I Transactions T3 and
T4 werekönnen
not (yet)(redo)
committed.
wiederhergestellt
werden
! Atomicity:TAllund
of their
effects need
to be
undone.
• Transaktionen
T4 wurden
noch
nicht
beendet 
3
Atomarität: Systems
Alle Group
Effekte
müssen rückgängig gemacht 267
Fall 2008
— Department of Computer Science — ETH Zürich
werden
74
Arten von Speichern
Wir nehmen an, es gibt drei Arten von Speichern
• Flüchtige Speicher
– Wird vom Pufferverwalter verwendet (auch für Cache
und Write-Ahead-Log, s.u.)
• Nicht-flüchtiger Speicher
– Festplatten
• Stabiler Speicher
– Nicht-flüchtiger Speicher, der alle drei Arten von
Fehlern überlebt. Stabilität kann durch Replikation auf
mehrere Platten erhöht werden (auch: Bänder)
Vergleiche Arten von Fehler und Arten von Speichern
75
Schatten-Seiten-Verwaltung
• Fehler können zu jeder Zeit auftreten, also muss das
System jederzeit in einen konsistenten Zustand
zurückgeführt werden können
• Dies kann durch Redundanz erreicht werden
• Schatten-Seiten (eingeführt durch IBMs „System R“)
– Von jeder Seite werden zwei Versionen geführt
– Aktuelle Version (Arbeitskopie, copy-on-write)
– Schatten-Seite (konsistente Version auf
nicht-flüchtigem Speicher zur Wiederherstellung)
• Operation SAVE, um aktuellen Zustand als
Schatten-Version zu sichern (für Commit)
• Operation RESTORE, um Wiederherstellung einzuleiten
(für Abort)
76
Shadow Pages
Schatten-Seiten-Verwaltung
1. Initially: shadow ⌘ current .
• Am Anfang:
shadowT=now
current
2. A transaction
changes the
current version.
• Ein Transaktion
T ändert nun die
I
Updates are not done in-place.
aktuelle Version
Create
new
pages and alter
– Aktualisierung
nicht
in situ
current page table.
– Neue Seiten anfordern, kopieren, ändern
3a.Seitentabelle
If T aborts, overwrite
und
anpassencurrent
version with shadow version.
I
directory
R R⇤
current
• Wenn T abgebrochen wird, überschreibe
3b. If T commits, change information in
aktuelle
Version mit Schatten-Version
directory to make current version
• Wenn T persistent
beendet .wird, aktualisiere Info
in Verzeichnis,
Version
4. Reclaim um
disk aktuelle
pages using
garbage
shadow
persistent
zu machen
collection.
• Gewinne ggf. Seiten durch Garbage Collection wieder
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
270
77
Schatten-Seiten: Diskussion
• Wiederherstellung schnell für ganze Relationen/Dateien
• Um Persistenz (Durabilität) sicherzustellen, müssen
modifizierte Seiten bei einem Commit in nicht-flüchtigen
Speicher (z.B. Festplatte) geschrieben werden (force to
disk)
• Nachteile:
– Hohe I/O-Kosten, keine Verwendung von Cache möglich
– Langsame Antwortzeiten
• Besser: No-Force-Strategie, Verzögerung des
Schreibens
• Transaktion muss neu abgespielt werden können
(Redo), auch für Änderungen, die nicht gespeichert
wurden
Gray et al.. The Recovery Manager of the System R
Database
Manager. ACM Comp. Surv., vol. 13(2), June 1981.
78
Schatten-Seiten: Diskussion
• Schatten-Seiten ermöglichen das Stehlen der
Rahmen im Pufferverwalter (frame stealing): Seiten
werden möglicherweise sofort auf die Platte
geschrieben (sogar bevor Transaktion erfolgreich
beendet wird)
– Stehlen erfolgt durch andere Transaktionen
– Stehlen kann nur erfolgen, wenn Seite nicht gepinnt
– Geänderte Seiten (dirty pages) werden auf die Platte
geschrieben
• Diese Änderungen müssen ungeschehen gemacht
werden während der Wiederherstellung
– Leicht möglich durch Schatten-Seiten
79
Effekte
für die Wiederherstellung
Effects
on Recovery
• I Entscheidungen
zurforce
Strategie
The decisions force/no
and steal/haben
no stealAuswirkungen
have
implications
on bei
whatder
we have
to do during recovery:
auf
das, was
Wiederherstellung
erfolgen
muss
no steal
steal
I
•
force
no force
no redo
no undo
must redo
no undo
no redo
must undo
must redo
must undo
If we want to use steal and no force (to increase concurrency
andsteal
performance),
have towird
implement
redo and undo
Bei
und noweforce
zur Erhöhung
der
routines.
Nebenläufigkeit
und der Performanz ein redo
und ein undo implementiert
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
273
80
Write-Ahead-Log (WAL)
• Die ARIES1-Wiederherstellungsmethode verwendet ein
Write-Ahead-Log zur Implementierung der notwendigen
redundanten Datenhaltung
• Datenseiten werden in situ modifiziert
• Für ein Undo müssen Undo-Informationen in eine
Logdatei auf nicht-flüchtigem Speicher geschrieben
werden bevor eine geänderte Seite auf die Platte
geschrieben wird
• Zur Persistenzsicherung muss zur Commit-Zeit RedoInformation sicher gespeichert werden (No-ForceStrategie: Daten auf der Platte enthalten alte
Information)
1
Algorithm for Recovery and Isolation Exploiting Semantics
Mohan et al. ARIES: A Transaction Recovery Method Supporting
Fine-Granularity Locking and Partial Rollbacks UsingWriteAhead
Logging. ACM TODS, vol. 17(1), March 1992.
81
Inhalte of
des
Content
theWrite-Ahead-Logs
Write-Ahead Log
LSN Type TX Prev Page UNxt Redo Undo
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
LSN
(Log Sequence
Sequence Number)
LSN
(Log
Number)
Monotonically increasing number to identify each log
• Monoton
steigende Zahl, um Einträge zu identifizieren
record.
Trick:
Verwende
Byte-Position
of Log-Eintrag
Trick:
Use byte position
of log record
Why?
TypType
(Log
Type)
(LogRecord
Record Type)
Indicates whether
this
is an
update record (UPD),
end ofEnd-of• Repräsentiert,
ob es
ein
Update-Eintrag
(UPD),
transaction record (EOT), compensation log record (CLR), ...
Transaction-Eintrag (EOT), Compensation-Log-Record
TX (Transaction ID)
(CLR)
Transaction identifier (if applicable).
TX (Transaktions-ID)
• Fall
Transaktionsbezeichner
(falls
anwendbar)
2008
Systems Group — Department
of Computer
Science — ETH Zürich
275
82
Inhalte des Write-Ahead-Logs (Forts.)
Prev (Previous Log Sequence Number)
• LSN des vorigen Eintrags von der gleichen Transaktion
(falls anwendbar, am Anfang steht ‘-‘)
Page (Page Identifier)
• Seite, die aktualisiert wurde (nur für UPD und CLR)
UNxt (LSN Next to be Undone)
• Nur für CLR: Nächster Eintrag der Transaktion, der
während des Zurückrollens bearbeitet werden muss
Redo
• Information zum erneuten Erzeugen einer Operation
Undo
• Information zum Ungeschehenmachen einer Operation
83
Beispiel
Example
Redo
Transaction 1 Transaction 2 LSN Type TX Prev Page UNxt
a
a
Undo
r ead( A) ;
c
r ead( C) ;
c
c + 10 ;
a − 50 ;
1
2
UPD T1
UPD T2
–
–
···
···
A := A − 50 A := A + 50
C := C+ 10 C := C− 10
3
4
UPD T1
EOT T1
1
3
···
···
B := B + 50 B := B − 50
r ead( A) ;
a
a − 10 ;
a
5
wr i t e( a, A) ;
6
commi t ;
UPD T2
EOT T2
2
5
···
···
A := A − 10 A := A + 10
wr i t e( a, A) ;
wr i t e( c, C) ;
r ead( B) ;
b
b + 50 ;
b
wr i t e( b, B) ;
commi t ;
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
277
84
Redo/Undo-Information
ARIES nimmt seitenorientiertes Redo an
• Keine anderen Seiten müssen angesehen werden,
um eine Operation erneut zu erzeugen
• Z.B.: Physikalisches Logging
– Speicher von Byte-Abbildern von (Teilen von) Seiteninhalten
– Vorher-Abbild (Abbild vor der Operation)
– Nachher-Abbild (Abbild nach der Operation)
• Wiederherstellung unabhängig von Objekten
– Struktur braucht nicht bekannt zu sein, nur Seitenstruktur
relevant
• Gegensatz: Logisches Redo (‚Setze Tupelwert auf v‘)
– Redo muss vollständig durchgeführt werden, auch Indexeinträge
werden neu generiert, inkl. Aufspaltung usw.
85
Redo/Undo-Information
• ARIES unterstützt logisches Undo
• Seitenorientiertes Undo kann kaskadierende RückrollSituationen heraufbeschwören
– Selbst wenn eine Transaktion T1 nicht direkt Tupel betrachtet
hat, die von anderer Transaktion T2 beschrieben wurden, ist
doch das physikalische Seitenlayout, dass T1 sieht, von T2
beeinflusst
– T1 kann nicht von T2 erfolgreich beendet werden
• Logisches Undo erhöht also die Nebenläufigkeit
• Durch Operator-Logging können Transaktion voll nebenläufig
arbeiten, wenn ihre Operationen semantisch kompatibel sind
– Z.B.: Dekrement- und Inkrementoperationen
– Dieses ist für Index und Metadaten relevant
86
Schreiben von Log-Einträgen
• Aus Performanzgründen werden Log-Einträge
zunächst in flüchtigen Speicher geschrieben
• Zu bestimmten Zeiten werden die Einträge bis zu
einer bestimmten LSN in stabilen Speicher
geschrieben
– Alle Einträge bis zum EOT einer Transaktion T
werden auf die Platte geschrieben wenn T erfolgreich
beendet (um ein Redo von Ts Effekten vorzubereiten)
– Wenn eine Datenseite p auf die Platte geschrieben
wird, werden vorher die letzten Modifikationen von p
im WAL auf die Platte geschrieben (zur Vorbereitung
eines Undo)
• Die Größe des Logs nimmt immer zu
(s. aber Schnappschüsse weiter unten)
87
Normaler Verarbeitungsmodus
Während des normalen Transaktionsverarbeitung, werden
zwei Dinge im Transaktionskontrollblock gespeichert
• LastLSN (Last Log Sequence Number)
– LSN des letzten geschriebenen Log-Eintrags für die Transaktion
• UNxt (LSN Next to be Undone)
– LSN des nächsten Eintrags, der beim Rückrollen betrachtet
werden muss
Wenn eine Aktualisierung einer Seite p durchgeführt wird
– wird ein Eintrag r ins WAL geschrieben und
– die LSN von r im Seitenkopf von p gespeichert
88
Datenstruktur zur Buchführung
Bookkeeping
Transaction ID
Update Flag
TX Status
# of Locks
hash table,
indexed by resource ID
..
.
..
.
Resource Control Block (RCB)
Resource ID
Hash Chain
First In Queue
...
Transaction
Control Block
(TCB)
..
.
LCB Chain
..
.
Transaction ID
Resource ID
Lock Mode
Lock Status
Next in Queue
LCB Chain
Transaction ID
Resource ID
Lock Mode
Lock Status
Next in Queue
LCB Chain
...
Lock Control Blocks (LCBs)
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
232
89
Rückrollen einer Transaktion
Schritte zum Rückrollen einer Transaktion T:
• Abarbeiten des WAL in Rückwärtsrichtung
• Beginn bei Eintrag, auf den UNxt im
Transaktionskontrollblock von T zeigt
• Finden der übrigen Einträge von T durch Verfolgen
der Prev- und UNxt-Einträge im Log
Undo-Operationen modifizieren ebenfalls Seiten
• Logging der Undo-Operationen im WAL
• Verwendung von Compensation-Log-Record (CLRs)
für diesen Zweck
90
Rückrollen einer Transaktion
Transaction Rollback
1
Function: r ol l back ( SaveLSN, T)
2
UndoNxt
T.UNxt ;
while SaveLSN < UndoNxt do
LogRec read log entry with LSN UndoNxt ;
switch LogRec.Type do
case UPD
perform undo operation LogRec.Undo on page LogRec.Page ;
LSN write log entry
hCLR, T, T.LastLSN, LogRec.Page, LogRec.Prev, · · · , ? i ;
set LSN = LSN in page header of LogRec.Page ;
T.LastLSN
LSN ;
3
4
5
6
7
8
9
10
case CLR
UndoNxt
11
12
13
T.UNxt
LogRec.UNxt ;
UndoNxt ;
91
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
283
I
Transaction can be rolled back partially (back to SaveLSN).
Rückrollen einer Transaktion
Why isthisuseful?
• Transaktionen können auch partiell zurückgerollt
werden (zur SaveLSN)
– Wozu könnte das nützlich sein?
• Das UNxt-Feld in einem CLR zeigt auf den
I The UNxt field
in a CLRpoints toder
the ungeschehen
log entry before the one
Logeintrag
vor demjenigen,
that haswurde
been undone.
gemacht
UPD
UPD
sav1
Fall 2008
UPD
sav2
UPD
CLR
CLR
r ol l back ( sav2)
UPD
CLR
CLR
Log
r ol l back ( sav1)
Systems Group — Department of Computer Science — ETH Zürich
284
92
Wiederherstellung nach Ausfall
Neustart nach einem Systemabsturz in drei Phasen
1. Analyse-Phase:
–
–
Lese Log in Vorwärtsrichtung
Bestimmt Transaktionen, die aktiv waren als der
Absturz passierte (solche Transaktionen nennen wir
Pechvögel)
2. Redo-Phase:
–
Spiele Operation im Log erneut ab (in
Vorwärtsrichtung), um das System in den Zustand vor
dem Fehler zu bringen
3. Undo-Phase:
–
Rolle Pechvögel-Transaktionen zurück, in dem das
Log in Rückwärtsrichtung abgearbeitet wird (wie beim 93
Analyse-Phase
Analysis Phase
1
Function: anal yze ( )
2
3
foreach log entry record LogRec do
switch LocRec.Type do
create transaction control block for LogRec.TX if necessary ;
case UPDor CLR
LogRec.TX.LastLSN
LogRec.LSN ;
if LocRec.Type = UPDthen
LogRec.TX.UNxt
LogRec.LSN ;
4
5
6
7
8
else
LogRec.TX.UNxt
9
10
11
12
LogRec.UNxt ;
case EOT
delete transaction control block for LogRec.TX ;
94
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
286
Redo-Phase
Redo Phase
1
Function: r edo ( )
2
3
4
foreach log entry record LogRec do
switch LocRec.Type do
case UPDor CLR
v
pi n ( LogRec.Page) ;
if v.LSN < LogRec.LSN then
perform redo operation LogRec.Redo on v ;
v.LSN
LogRec.LSN ;
5
6
7
8
unpi n ( v, · · · ) ;
9
•
can occur during recovery!
AuchSystem
beimcrashes
Wiederherstellen
können Abstürze eintreten
I
Undo and redo of a transaction T must be idempotent:
I
• undo(undo(T))
= undo(T)
Check
LSN before performing
the redo operation (line 6).
– Undo und Redo einer Transaktion müssen idempotent
undo(undo(T)) = undo(T)
sein
redo(redo(T)) = redo(T)
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
• redo(redo(T))
= redo(T)
– Prüfe LSN vor der Redo-Operation
287
95
Redo-Phase
• Beachte, dass alle Operationen (auch solche von
Pechvögeln) in chronologischer Ordnung erneut
durchgeführt werden
• Nach der Redo-Phase ist das System im gleichen
Zustand, wie zum Fehlerzeitpunkt
– Einige Log-Einträge sind noch nicht auf der Platte, obwohl
erfolgreich beendete Transaktionen ihre Änderung
geschrieben hätten. Alle anderen müssten ungeschehen
gemacht werden
• Wir müssen hinterher alle Effekte von Pechvögeln
ungeschehen machen
• Als Optimierung kann man den Puffermanager
instruieren, geänderte Seiten vorab zu holen
(Prefetch)
96
Undo-Phase
• Die Undo-Phase ist ähnlich zum Rückrollen im
normalen Betrieg
• Es werden mehrere auf einmal Transaktionen
zurückgerollt (all Pechvögel)
• Alle Pechvögel werden vollständig zurückgerollt
(nicht nur bis zu einem Sicherungspunkt)
97
Undo-Phase
1
Function: undo ( )
2
while transactions (i.e., TCBs) left to roll back do
T TCB of loser transaction with greatest UNxt ;
LogRec read log entry with LSN T.UNxt ;
switch LogRec.Type do
case UPD
perform undo operation LogRec.Undo on page LogRec.Page ;
LSN write log entry
hCLR, T, T.LastLSN, LogRec.Page, LogRec.Prev, · · · , ? i ;
set LSN = LSN in page header of LogRec.Page ;
T.LastLSN
LSN ;
3
4
5
6
7
8
9
10
case CLR
UndoNxt
11
12
13
14
15
16
LogRec.UNxt ;
T.UNxt
UndoNxt ;
if T.UNxt = ‘–’ then
write EOT log entry for T ;
delete TCB for T ;
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
290
98
Checkpointing
• WAL ist eine immer-wachsendes Log-Datei, die bei
der Wiederherstellung gelesen wird
• In der Praxis sollte die Datei nicht zu groß werden
(Wiederherstellung dauert zu lange)
• Daher wird ab und zu ein sog. Checkpoint erstellt
– Schwergewichtiger Checkpoint:
Speicherung aller geänderter Seiten auf der Platte,
dann Verwaltungsinformation für Checkpoint schreiben
(Redo kann dann ab Checkpoint erfolgen)
– Leichtgewichtiger Checkpoint:
Speichere Information bzgl. geänderter Seiten in Log,
aber keine Seiten (Redo ab Zeitpunkt kurz vor
Checkpoint)
99
Medien-Wiederherstellung
• Um Medienfehler zu kompensieren, muss
peridiodisch eine Sicherungskopie erstellt werden
(nicht-flüchtiger Speicher)
• Kann während des Betriebs erfolgen, wenn WAL
auch gesichert wird
• Wenn Pufferverwalter verwendet wird, reicht es, das
Log vom Zeitpunkt des Backups zu archivieren
– Pufferverwalter hat aktuelle Seiten
– Sonst muss bis zum ältesten Write der aktualisierten
Seiten zurückgegangen werden
• Anderer Ansatz:
Spiegeldatenbank auf anderem Rechner
100
Leichtgewichtiger Checkpoint
Schreibe periodisch Checkpoint in drei Phasen
1. Schreibe Begin-Checkpoint-Logeintrag BCK
2. Sammle Information
–
über geänderte Seiten im Pufferverwalter und dem
LSN ihrer letzten Modifikationsoperation und
– über alle aktiven Transaktionen (und ihrer LastLSN
und UNxt TCB-Einträge)
Schreibe diese Information in End-Checkpoint Eintrag
ECK
3. Setze Master-Record auf bekannte Position auf der
Platte und zeige auf LSN und BCK Logeinträge
101
Wiederherstellung mit leichtgew. Checkpoint
Während
der
Wiederherstellung
Recovery
with
Fuzzy Checkpointing
• Starte
beim BCK-Eintrag im Master-Record
DuringAnalyse
crash recovery
I start analyze
(anstelle
vom Anfang
Logs)
passat thedes
BCKentry
recorded in the master
record (instead of from the beginning of the log).
• Wenn
der ECK-Eintrag gelesen wird
I
–
When reading the ECKlog entry,
Bestimme
kleinste
LSN
die die
Redo-Verarbeitung
I
Determine
smallest
LSNfür
for redo
processing
and
und I Create TCBs for all transactions in the checkpoint .
– Erzeuge TCBs checkpoint
für alle Transaktionen im Checkpoint
Log
✓
analyze pass
redo pass
undo pass
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
293
102
Zusammenfassung
• ACID und Serialisierbarkeit
– Vermeiden von Anomalien durch Nebenläufigkeit
– Serialisierbarkeit reicht für Isolation
• Zwei-Phasen-Sperrprotokoll
– 2PL ist eine praktikable Technik, um Serialisierbarkeit
zu garantieren (meist wird strikte 2PL verwendet)
– In SQL-92 können sog. Isolationsgrade eingestellt
werden
(Abschwächung der ACID-Bedingungen)
• Nebenläufigkeit in B-Bäumen
– Spezialisierte Protokolle (WTL) zur
Flaschenhalsvermeidung
• Wiederherstellung (ARIES)
103
Das Gesamtbild der Architektur
Architecture of a DBMS / Course Outline
Applications
Anwendungen
SQL
Interface
SQL-Schnittstelle
Figure inspired by Ramakrishnan/ Gehrke: “Dat abase Management Systems”, McGraw-Hill 2003.
Webformulare
Web
Forms
Ausführer
Executor
Parser
Parser
Operator
Evaluator
Operator-Evaluierer
Optimizer
Optimierer
Transaction
Transaktions
Manager
Dateiverwaltungsund Zugriffsmethoden
Files and Access
Methods
Verwalter
Puffer-Verwalter
Buffer
Manager
Lock
SperrVerwalter
Manager
Verwalter
für Manager
externen
Disk
Space
RWiederecovery
herstellungsManager
Verwalter
dieser Teil des
thiscourse
Kurses
SQL-Kommandos
SQLCommands
Speicher
DBMS
Dateien
für Daten
und Indexe...
data
files,
indices,
Fall 2008
Datenbank
Database
Systems Group — Department of Computer Science — ETH Zürich
3
104