Gegevensbanken_2012_Les14_Transacties

Gegevensbanken 2012
Begrippen van
transactieverwerking
Bettina Berendt
http://people.cs.kuleuven.be/~bettina.berendt/
Begrippen van
transactieverwerking:
Motivatie &
Samenvatting
2
Waar zijn we?
Les #
1
2
2
3
4,5
6
7
8
9
10
11
12
13
14-16
17
18
wie
ED
ED
ED
KV
KV
KV
KV
KV
BB
BB
BB
BB
BB
BB
BB
ED
wat
intro, ER
EER, (E)ER naar relationeel schema
relationeel model
Relationele algebra & relationeel calculus
SQL
Programma's verbinden met gegevensbanken
Functionele afhankelijkheden & normalisatie
PHP
Beveiliging van gegevensbanken
Geheugen en bestandsorganisatie
Hashing
Indexstructuren
Queryverwerking
Transactieverwerking en concurrentiecontrole
Data mining en data warehousing
XML, NoSQL
Fysisch model /
vragen
3
En waarom al dit? (1: vorige les)
Les #
1
2
2
3
4,5
6
7
8
9
10
11
12
13
14-16
17
18
wie
ED
ED
ED
KV
KV
KV
KV
KV
BB
BB
BB
BB
BB
BB
BB
ED
wat
intro, ER
EER, (E)ER naar relationeel schema
relationeel model
Relationele algebra & relationeel calculus
SQL
Programma's verbinden met gegevensbanken
Functionele afhankelijkheden & normalisatie
PHP
Beveiliging van gegevensbanken
Geheugen en bestandsorganisatie
Hashing
Indexstructuren
Queryverwerking
Transactieverwerking en concurrentiecontrole
Data mining en data warehousing
XML, NoSQL
4
En waarom al dit?
(2: deze & de volgende lessen)
Les #
1
2
2
3
4,5
6
7
8
9
10
11
12
13
14-16
17
18
wie
ED
ED
ED
KV
KV
KV
KV
KV
BB
BB
BB
BB
BB
BB
BB
ED
wat
intro, ER
EER, (E)ER naar relationeel schema
relationeel model
Relationele algebra & relationeel calculus
SQL
Programma's verbinden met gegevensbanken
Functionele afhankelijkheden & normalisatie
PHP
Beveiliging van gegevensbanken
Geheugen en bestandsorganisatie
Hashing
Indexstructuren
Queryverwerking
Transactieverwerking en concurrentiecontrole
Data mining en data warehousing
XML, NoSQL
5
Dat willen wij niet!
t
reserveer!
reserveer!
6
En hier? ... willen we ook een goede oplossing ...
• Vliegtuig vol
• Geeft plaats vrij op vlucht 1
• Vlucht 1: nog 1 plaats :-)
• Reserveert plaats op vlucht 1
• Wil plaats op vlucht 2 reserveren
• Computer crash!
• Maak die transactie ongedaan!
• ?
7
3 lessen
Nu (#14): wat willen we überhaupt? (transacties, concurrentie,
problemen, eigenschappen, …)
… en kan dat in SQL?
#15: hoe kunnen we gewenste eigenschappen garanderen? ->
concurrentiecontrole
#16: wat moeten we doen na een faling en hoe? -> herstel
8
Agenda
Inleiding tot concurrentie en herstel
Transacties: begrippen
Transactieroosters
Serialiseren van roosters
Transacties in SQL
9
Agenda
Inleiding tot concurrentie en herstel
Transacties: begrippen
Transactieroosters
Serialiseren van roosters
Transacties in SQL
10
Inleiding tot concurrentie en herstel
• transactie
= de uitvoering van een programma dat de gegevensbank
raadpleegt of haar inhoud wijzigt
• gelijktijdige verwerking van transacties is wenselijk, vaak
noodzakelijk
• vnl. voor gegevensbanksystemen met meerdere gebruikers
• twee mogelijkheden voor implementatie:
• interleaved uitvoering:
• 1 processor behandelt afwisselend verschillende transacties
• simultane uitvoering:
• meerdere processoren werken in parallel
• wij veronderstellen "interleaved" model
11
Interleaved en simultaneous verwerking
interleaved - 1 processor
simultaneous - 2 processors
12
Concurrentie
• gelijktijdige verwerking van transacties kan problemen
veroorzaken
• vb: vliegtuigreservatiesysteem
• transactie T1 schrapt reservatie van N plaatsen op vlucht V1 en
reserveert N plaatsen op vlucht V2
• transactie T2 reserveert M plaatsen op vlucht V1
• mogelijke problemen:
• verloren aanpassing
• tijdelijke aanpassing
• foutieve sommering
• vermijden d.m.v.
concurrentiecontrole
13
Verloren aanpassing
http://adbc.kennesaw.edu/index.php?mainmenu=transactions&submenu=concurrency
14
Verloren aanpassing
• Zij X #reservaties op V1, Y #reservaties op V2 voor de
transacties
• Verloren aanpassing:
• wijziging van T1 wordt per ongeluk teniet gedaan door T2
T1
lees(X)
X := X-N
T2
lees(X)
X := X+M
vb:
X = 84
N=5
M=4
schrijf(X)
resultaat:
X = 88 i.p.v. 83
schrijf(X)
lees(Y)
Y := Y+N
schrijf(Y)
15
Tijdelijke aanpassing (dirty read)
T1 afgebroken
T1
lees(X)
X := X-N
schrijf(X)
T2
lees(X)
X := X+M
schrijf(X)
lees(Y)
Y := Y+N
schrijf(Y)
16
Tijdelijke aanpassing (dirty read)
• tijdens de uitvoering wordt T1 door een of andere faling
afgebroken;
• de gewijzigde waarden worden hersteld in oorspronkelijke
toestand, maar T2 heeft intussen zo'n tijdelijk gewijzigde
(ongeldige) waarde gebruikt
T1 afgebroken  aan X wordt
terug de oorspronkelijke
waarde toegekend
T1
lees(X)
X := X-N
schrijf(X)
T2
lees(X)
X := X+M
schrijf(X)
lees(Y)
Y := Y+N
schrijf(Y)
17
Foutieve sommering
T1
T3
som := 0
lees(A)
som := som+A
...
lees(X)
X := X-N
schrijf(X)
lees(X)
som := som+X
lees(Y)
som := som+Y
lees(Y)
Y := Y+N
schrijf(Y)
18
Foutieve sommering
• gebruik van inconsistente waarden door aggregaatfunctie
• bv. sommige van voor een wijziging en andere van erna
T1
T3
som := 0
lees(A)
som := som+A
...
lees(X)
X := X-N
schrijf(X)
T3 berekent het totaal
aantal reservaties op
vluchten terwijl T1 wordt
uitgevoerd
lees(X)
som := som+X
lees(Y)
som := som+Y
lees(Y)
Y := Y+N
schrijf(Y)
19
Niet herhaalbare lezing (nonrepeatable read)
• Gerelateerd aan "foutieve sommering":
• Lees zelfde item 2x kort na elkaar, waarde blijkt intussen gewijzigd
(door een andere transactie)
• bv. reservatie vliegtuigtickets:
• controleer of er vrije plaatsen zijn
• indien ja: reserveer ze
• reservatie mislukt: plaatsen blijken niet meer vrij
20
Herstel
• Waarom herstel nodig is
• Een transactie moet
• ofwel volledig uitgevoerd worden
• ofwel helemaal niet
• Bij een fout (software/hardware) tijdens een transactie:
• ze kan niet helemaal uitgevoerd worden
 oorspronkelijke toestand moet hersteld worden (transactie is dan
helemaal niet uitgevoerd)
21
Mogelijke falingen
die tijdens de uitvoering van een transactie kunnen optreden
1. computer-crash
• inhoud van geheugen kan verloren zijn
2. transactie- of systeemfout
• verkeerde parameter, overflow, deling door 0, logische programmeerfout,..
3. uitzonderingscondities
• bv. bestand kan niet gelezen worden, ...
4. opgelegd door concurrentiecontrole
• bv. transactie afgebroken wegens deadlock
5. schijf-fout
• bv. beschadigd spoor
6. fysieke problemen, catastrofes
• brand, stroomonderbreking, ...
• Bij falingen van de types 1 tot 4 moet de oorspronkelijke toestand
hersteld kunnen worden
22
Agenda
Inleiding tot concurrentie en herstel
Transacties: begrippen
Transactieroosters
Serialiseren van roosters
Transacties in SQL
23
Transacties: begrippen
• transacties:
• "read-only" transactie:
• alleen ophalen (raadplegen) van gegevens
• "update" transactie:
 deze interesseren ons
• met aanpassing van gegevens
• lees- en schrijfbewerkingen van een transactie:
• niveau van beschouwing van transacties:
• gegevenselementen en blokken of schijf
• op dit niveau zijn de bewerkingen van een transactie:
• read_item(X)
• write_item(X)
• kopieer programmavariabele X naar buffer
• schrijf buffer (onmiddellijk of later)
24
Lezen en schrijven
• read_item(X):
• vind adres van blok dat X bevat
• kopieer dat blok in een buffer
• kopieer X in programmavariabele X
• write_item(X):
•
•
•
•
vind adres van blok dat X bevat
kopieer dat blok in een buffer
kopieer de programmavariable X op de juiste plaats in die buffer
bewaar het aangepaste blok terug op schijf (onmiddellijk of later)
25
Status van de transactie
• wordt bijgehouden om zo nodig te kunnen herstellen
• status wordt bepaald door operaties:
• BEGIN_TRANSACTION
• geeft begin van de transactie aan
• READ / WRITE
• alle lees- en schrijfoperaties
• END_TRANSACTION
• geeft einde van een transactie aan
• dan moet worden gecontroleerd of
• de wijzigingen veroorzaakt door de transactie definitief doorgevoerd
kunnen worden op de gegevensbank ( = committed )
• de transactie ongedaan moet worden gemaakt vanwege de
concurrentiecontrole
• COMMIT_TRANSACTION
• succesvol einde van de transactie: alle wijzigingen aangebracht door de
transactie zijn definitief
26
Andere bewerkingen
• ROLLBACK ( of ABORT)
• geen succesvol einde van de transactie; alle wijzigingen
worden ongedaan gemaakt
• UNDO
• één bewerking wordt ongedaan gemaakt
• REDO
• één bewerking wordt opnieuw uitgevoerd
27
Systeemlog
• Systeemlog
• noteert alle transacties die waarden in de gegevensbank
wijzigen
• nodig bij herstelprocedures na falen
• bijgehouden op schijf (met geregelde backup)
• Wat wordt geregistreerd: (T = een transactie-ID)
•
•
•
•
•
[ start_transaction, T ]
[ write_item, T, X, oude waarde, nieuwe waarde ]
[ read_item, T, X ]
[ commit, T ]
[ abort, T ]
29
Herstellen na faling
• twee mogelijkheden
• transactie volledig ongedaan maken:
= effect van write-opdrachten ongedaan maken
• log achterwaarts doorlopen, UNDO alle writes
• transactie goed afwerken:
= effect van write-opdrachten herstellen / herhalen
• log voorwaarts doorlopen, REDO alle writes
• Welk van beide kiezen?
• commit point:
• punt waarop beslist wordt dat transactie goed afgewerkt moet
worden i.p.v. ongedaan gemaakt
30
Commit points (bindpunten)
• een transactie bereikt een commit point wanneer
• alle bewerkingen van de transactie met succes zijn uitgevoerd
en
• al die bewerkingen zijn geregistreerd op de log
• na commit point is resultaat van transactie definitief
•  verplichting om aanpassingen werkelijk op schijf door te
voeren indien nog niet gebeurd
• volgorde van acties tijdens commit
• op log noteren: [ commit, T ]
• log definitief op schijf zetten (vanuit buffer)  "force writing"
• nu is transactie gecommit
31
Bij faling
• voor transacties die gestart zijn maar niet gecommit: rollback
• voor gecommitte transacties: REDO alle writes
• Meer details: zie volgende les
32
Checkpoints (controlepunten)
• op geregelde tijdstippen (gemeten in tijd of in aantal
committed transacties):
• effecten van wijzigingen worden op schijf gezet
• Acties:
1. onderbreek tijdelijk alle transacties
2. schrijf alle aangepaste gegevensbankblokken van buffer naar
schijf
3. schrijf een checkpoint op de log en schrijf de log naar schijf
4. hervat de transactie-uitvoering
• Mogelijke extra informatie in checkpoint-record:
• lijst van actieve transacties op dat moment
• voor elke transactie: adres van 1-ste en meest recente records
in de log
33
Gewenste eigenschappen van transacties
(“ACID properties”)
• Atomicity: ondeelbaarheid
• transactie wordt volledig uitgevoerd, of helemaal niet
• Consistency preservation:
• consistente gegevensbank moet na transactie nog steeds consistent
zijn
• Isolation: geïsoleerdheid
• effect van transactie moet zijn alsof het de enige transactie is die
uitgevoerd werd (geen interferentie met andere transacties)
• er worden meestal 4 isolatieniveaus gedefineerd, naargelang van
de graad van isolatie
• = naargelang welke van de problemen vermeden worden (dirty
reads ezf.)
• Zie isolatieniveaus voor SQL beneden
• Durability: duurzaamheid
• effect van transactie moet persistent zijn, mag niet verloren gaan
34
Agenda
Inleiding tot concurrentie en herstel
Transacties: begrippen
Transactieroosters
Serialiseren van roosters
Transacties in SQL
35
Transactieroosters (schedules)
• Operaties van meerdere transacties in chronologische
volgorde opgeschreven
• zie eerdere voorbeelden met T1 en T2
36
Eigenschappen van transactieroosters
• 2 operaties conflicteren indien
• ze bij verschillende transacties horen
• ze hetzelfde gegevenselement gebruiken
• minstens een ervan een write_item is
• een rooster S voor n transacties Ti is volledig indien
• S alle operaties van de transacties T1,… , Ti, …, Tn bevat (met
inbegrip van een commit of abort operartie als laatste operatie van
elke transactie, en geen andere
• elk paar operaties van één transactie Ti in dezelfde volgorde
voorkomt in S als in Ti
• voor elk paar conflicterende operaties geldt dat de volgorde
eenduidig vastligt
38
Herstelbaarheid van roosters
• Een rooster is herstelbaar a.s.a. een transactie die gecommit is
nooit meer ongedaan gemaakt moet worden
• Voldoende voorwaarde:
• T commit enkel na commit van elke transactie die een waarde
schrijft die T leest
• Herstelbaar impliceert niet "eenvoudig herstelbaar"
• mogelijk "cascading rollback"
• één transactie T terugrollen kan het nodig maken om een
andere (die iets las dat door T geschreven werd) ook terug te
rollen, enz.
• cascading rollback is tijdrovend
39
Voorbeeld
schema a
T1
read (X)
read(X)
write(X)
read(Y)
write(Y)
write(X)
commit
write(Y)
commit
T2
herstelbaar,
maar wel probleem
van verloren
aanpassing
schema c
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
commit
abort
T2
niet herstelbaar,
T2 leest item X
geschreven door T1,
en commit vooraleer
T1 commit,
abort van T1 daarna
maakt die waarde
van X ongeldig
schema d
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
commit
commit
T2
wel herstelbaar:
commit van T2 is
uitgesteld tot na commit
van T1
schema e
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
abort
abort
T2
wel herstelbaar:
indien T1 abort,
moet ook T2 een abort
uitvoeren
40
Voorbeeld
schema a
T1
read (X)
read(X)
write(X)
read(Y)
write(Y)
write(X)
commit
write(Y)
commit
T2
herstelbaar,
maar wel probleem
van verloren
aanpassing
schema b
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
commit
abort
T2
niet herstelbaar,
T2 leest item X
geschreven door T1,
en commit vooraleer
T1 commit,
abort van T1 daarna
maakt die waarde
van X ongeldig
schema d
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
commit
commit
T2
wel herstelbaar:
commit van T2 is
uitgesteld tot na commit
van T1
schema e
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
abort
abort
T2
wel herstelbaar:
indien T1 abort,
moet ook T2 een abort
uitvoeren
41
Voorbeeld
schema a
T1
read (X)
read(X)
write(X)
read(Y)
write(Y)
write(X)
commit
write(Y)
commit
T2
herstelbaar,
maar wel probleem
van verloren
aanpassing
schema b
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
commit
abort
T2
niet herstelbaar,
T2 leest item X
geschreven door T1,
en commit vooraleer
T1 commit,
abort van T1 daarna
maakt die waarde
van X ongeldig
schema c
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
commit
commit
T2
wel herstelbaar:
commit van T2 is
uitgesteld tot na commit
van T1
schema e
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
abort
abort
T2
wel herstelbaar:
indien T1 abort,
moet ook T2 een abort
uitvoeren
42
Voorbeeld
schema a
T1
read (X)
read(X)
write(X)
read(Y)
write(Y)
write(X)
commit
write(Y)
commit
T2
herstelbaar,
maar wel probleem
van verloren
aanpassing
schema b
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
commit
abort
T2
niet herstelbaar,
T2 leest item X
geschreven door T1,
en commit vooraleer
T1 commit,
abort van T1 daarna
maakt die waarde
van X ongeldig
schema c
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
commit
commit
T2
wel herstelbaar:
commit van T2 is
uitgesteld tot na commit
van T1
schema d
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
abort
abort
T2
wel herstelbaar:
indien T1 abort,
moet ook T2 een abort
uitvoeren
43
Voorbeeld
schema a
T1
read (X)
read(X)
write(X)
read(Y)
write(Y)
write(X)
commit
write(Y)
commit
T2
herstelbaar,
maar wel probleem
van verloren
aanpassing
schema b
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
commit
abort
T2
niet herstelbaar,
T2 leest item X
geschreven door T1,
en commit vooraleer
T1 commit,
abort van T1 daarna
maakt die waarde
van X ongeldig
schema c
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
commit
commit
T2
wel herstelbaar:
commit van T2 is
uitgesteld tot na commit
van T1
schema d
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
abort
abort
T2
wel herstelbaar:
indien T1 abort,
moet ook T2 een abort
uitvoeren
44
Cascadeloze roosters
• garanderen dat geen cascading rollbacks nodig zijn
• voldoende voorwaarde:
• elke transactie T leest enkel waarden geschreven door
transacties die al gecommit hebben
• meer restrictief !
• minder verschillende mogelijkheden om transacties gelijktijdig
uit te voeren
45
Strikte roosters
• elke transactie T leest en schrijft enkel items na commit (of
abort) van de laatste transactie die dat item geschreven
heeft
• UNDO write_item:
•
gewoon oorspronkelijke waarde terugzetten
• meest restrictief
•
•
relatief weinig roosters mogelijk
maar eenvoudigst herstelbaar
46
In volgorde van restrictiefheid:
herstelbaar – cascadeloos - strikt
1. herstelbaar rooster
2. casacadeloos rooster ; impliceert 1
3. strikt rooster ; impliceert 2 en 1
47
Maar: Voorbeeld ...
schema a
T1
read (X)
read(X)
write(X)
read(Y)
write(Y)
write(X)
commit
write(Y)
commit
T2
herstelbaar,
maar wel probleem
van verloren
aanpassing
schema c
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
commit
abort
T2
niet herstelbaar,
T2 leest item X
geschreven door T1,
en commit vooraleer
T1 commit,
abort van T1 daarna
maakt die waarde
van X ongeldig
schema d
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
commit
commit
T2
wel herstelbaar:
commit van T2 is
uitgesteld tot na commit
van T1
schema e
T1
read (X)
write(X)
read(X)
read(Y)
write(X)
write(Y)
abort
abort
T2
wel herstelbaar:
indien T1 abort,
moet ook T2 een abort
uitvoeren
48
Agenda
Inleiding tot concurrentie en herstel
Transacties: begrippen
Transactieroosters
Serialiseren van roosters
Transacties in SQL
49
Serialiseren van roosters
• Serieel rooster:
• tussen eerste en laatste opdracht van een transactie T worden
geen opdrachten van eender welke andere transactie uitgevoerd
• m.a.w. transacties worden na elkaar uitgevoerd
• er kan dus geen interferentie zijn
• indien transacties onafhankelijk zijn, is elk serieel rooster
correct
• nadeel van seriële roosters:
• beperking op concurrentie
50
Serialiseerbaarheid
• een rooster S van n transacties is serialiseerbaar
• a.s.a. het equivalent is met een serieel rooster met dezelfde n
transacties
• er zijn meerdere soorten equivalentie definieerbaar
• resultaat-equivalentie
• gegeven beginvoorwaarden, zelfde resultaat
• te zwak: voor andere beginvoorwaarden misschien niet
equivalent
• beter: conflict-equivalentie
51
Conflict-equivalentie
• twee roosters S1 en S2 zijn conflict-equivalent
• a.s.a. volgorde van 2 conflicterende operaties steeds dezelfde is in
beide roosters
• een rooster is conflict-serialiseerbaar
• a.s.a. conflict-equivalent met een serieel rooster
• testen van conflict-serialiseerbaarheid: d.m.v. "precedence
graph"
• graaf die volgorde van transacties aanduidt
• knopen = transacties, gerichte bogen = "komt voor"
52
Testen van conflict-serialiseerbaarheid
1. maak voor elke transactie Ti een
knoop
2. maak een boog van Ti naar Tj a.s.a.
•
•
•
Tj voert een read_item(X) uit na een
write_item(X) van Ti
of Tj voert een write_item(X) uit na
een read_item(X) van Ti
of Tj voert een write_item(X) uit na
een write_item(X) van Ti
i
schrijf(X)
lees(X)
schrijf(X)
j
 lees(X)
 schrijf(X)
 schrijf(X)
1. het rooster is serialiseerbaar a.s.a. de graaf geen cycli bevat
•
Equivalent serieel rooster S' te bekomen door topologisch sorteren
•
als er een boog ( Ti,Tj ) bestaat moet Ti voor Tj komen
53
Voorbeeld (1)
54
Voorbeeld (2)
55
Nog een voorbeeld (1)
X
56
Nog een voorbeeld (2)
57
Nog een
voorbeeld
(3)
(roooster b boven)
(roooster c boven)
58
View-equivalentie
een andere, minder restrictieve definitie van equivalente roosters:
• Roosters S1 en S2 zijn view equivalent als
• voor elke read_item(X) in Ti in S1 geldt:
• de laatste write_item(X) voor die read_item(X) moet in beide
roosters dezelfde write_item van dezelfde transactie Tj zijn
• voor elke X waarvoor een write_item(X) voorkomt:
• de laatste write_item(X) moet dezelfde write_item van
dezelfde transactie Tk zijn in beide roosters
• m.a.w.:
• elke leesopdracht in S1 leest (ziet) dezelfde waarde als
overeenkomstige leesopdracht in S2
• laatst geschreven waarde voor een item is dezelfde in beide
roosters
• een rooster is view serialiseerbaar als het view-equivalent is
met een serieel rooster
59
Verschil tussen view-equivalentie en
conflict-equivalentie?
• zijn allebei hetzelfde indien “constrained write” aanname geldt
• CWA: aan elke write_item(X) gaat een read_item(X) vooraf, en de
geschreven waarde hangt enkel af van de gelezen waarde
• bij “unconstrained write” aanname is view-equivalentie minder
restrictief dan conflict-equivalentie
• maar: testen van view-equivalentie is NP-compleet
T1
read (X)
write(X)
write(X)
T2
write(X)
commit
commit
commit
T3
“blinde” aanpassingen: er gaat geen lezen van X aan vooraf
dit rooster is view-serialiseerbaar,
want view equivalent met serieel rooster
T1
T2
T3
maar het is niet conflict-serialiseerbaar
60
Voorbeeld van view-equivalente maar niet
conflict-equivalente roosters
verplaatsing behoudt
view-equivalentie
(T2 leest waarde van
X geschreven door T3,
laatste geschreven
waarde van X is
geschreven door T2 )
maar niet
conflict-equivalentie
_T1
T2
T3____
X := a
schrijf(X)
X := b
schrijf(X)
lees(X)
X := a
schrijf(X)
X := c
schrijf(X)
61
In volgorde van restrictiefheid:
serieel – conflict-serialiseerbar – view-serialiseerbar
• in volgorde van restrictiefheid:
• serieel
• conflict-serialiseerbaar
• view-serialiseerbaar
meest restrictief
minst restrictief
• minder restrictief betekent:
• flexibeler qua concurrentiemogelijkheden
• moeilijker te testen of rooster serialiseerbaar is
62
Testen of verzekeren van serialiseerbarheid
• Problemen met testen van serialiseerbaarheid:
• interleaving van operaties wordt bepaald door het
besturingssysteem, niet vooraf te voorspellen
• transacties worden continu aangeboden
• begin en einde van roosters moeilijk te voorspellen
• Indien rooster niet serialiseerbaar blijkt:
• herstel nodig  duur
• om deze problemen te vermijden:
• test niet op serialiseerbaarheid
• gebruik bij opstellen van transacties regels (protocols) om
serialiseerbaarheid te verzekeren
 volgende les
63
Agenda
Inleiding tot concurrentie en herstel
Transacties: begrippen
Transactieroosters
Serialiseren van roosters
Transacties in SQL
64
SQL biedt mogelijkheid
om transacties te definiëren
• uitvoering van één query is gegarandeerd atomair
• transacties bestaande uit meerdere SQL-queries:
• gebruiker bepaalt eigenschappen van transactie:
• toegangsmodus:
• read-write of read-only
• diagnoseruimte
• de grootte geeft aan hoeveel foutmeldingen opgeslagen
kunnen worden
• geeft feedback aan de gebruiker over fouten en
uitzonderingen opgetreden tijdens de meest recent
uitgevoerde SQL opdrachten
• Isolatieniveau naar ISO/ANSI SQL-92 (vaak met default waarde,
maar die is afhankelijk van het systeem)
• READ UNCOMMITTED
• READ COMMITTED
• REPEATEABLE READ
• SERIALIZABLE
65
SQL “serializable”
• "serializable"  onze definities van serialiseerbaar
• gebaseerd op vermijden van bepaalde problemen
• dirty read
• gebruik van een "tijdelijke aanpassing”, uitgevoerd door een
nog niet gecommitte transactie
• nonrepeatable read
• opnieuw lezen van een waarde kan een ander resultaat geven
• phantom
• een record wordt zichtbaar bij een tweede maal lezen van een
tabel
• bv. T1 begint een scan van een tabel, T2 voegt intussen
een rij toe
• als T1 herbegint ziet het een “phantom” tupel dat eerst
niet bestond
66
SQL isolatieniveaus
67
Voorbeeld
EXEC SQL WHENEVER SQLERROR GOTO UNDO;
EXEC SQL SET TRANSACTION
READ WRITE
DIAGNOSTICS SIZE 5
ISOLATION LEVEL SERIALIZABLE;
EXEC SQL INSERT INTO EMPLOYEE (Fname, Lname, Ssn,
Dno, Salary)
VALUES('Robert', 'Smith', '991004321', 2, 35000);
EXEC SQL UPDATE EMPLOYEE
SET Salary = Salary * 1.1 WHERE Dno = 2;
EXEC SQL COMMIT;
GOTO THE_END;
UNDO: EXEC SQL ROLLBACK;
THE_END: ...;
Een nieuwe rij wordt toegevoegd in de tabel EMPLOYEE
daarna worden de salarissen van alle werknemers van dept 2 aangepast
Indien ergens een fout optreedt, wordt de hele transactie teruggerold.
68
Vooruitblik
Inleiding tot concurrentie en herstel
Transacties: begrippen
Transactieroosters
Serialiseren van roosters
Transacties in SQL
Transacties II: Concurrentie-controle en herstel
69
Taak voor de volgende les
• Zijn alle ACID
eigenschappen even
belangrijk voor de
volgende types van
toepassingen?
• Wat kann je doen als voor
je toepassing snelheid
heel belangrijk is?
• Online banking
• Een online shop (e.g.
boeken/media)
• Een sociale netwerk site
70
Bronnen
• Deze slides zijn gebaseerd op Henk Olivié‘s slides voor
Gegevensbanken 2009 en op Elmasri & Navathe,
Fundamentals of Database Systems, Addison Wesley /
Pearson, 5e editie 2007.
• Alle kopieën zonder bronspecificatie: Elmasri & Navathe,
Fundamentals of Database Systems, Addison Wesley /
Pearson, 5e editie 2007.
• Verdere figuren: bronnen zie “Powerpoint comments field”
• Bedankt iedereen!
71