gegevensbanken 2010 les16
TRANSCRIPT
![Page 1: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/1.jpg)
Gegevensbanken 2010
Begrippen van transactieverwerking II:technieken voor concurrentiecontrole en herstel
Bettina Berendtwww.cs.kuleuven.be/~berendt
![Page 2: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/2.jpg)
2
Concurrentiecontrole en herstel:
Motivatie & Samenvatting
![Page 3: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/3.jpg)
3
transactionsquery processing
indexing II and higher-dimensional structures
Waar zijn we?LesNr. wie wat
1 ED intro, ER2 ED EER3 ED relational model4 ED mapping EER2relational5 KV relational algebra, relational calculus6 KV SQL7 KV vervolg SQL8 KV demo Access, QBE, JDBC
9 KV functional dependencies and normalisation
10 KV functional dependencies and normalisation11 BB file structures and hashing12 BB indexing I
13 BB14 BB15 BB16 BB transactions II: concurrentie & herstel17 BB Data mining (and a bit on d. warehousing)18 ED XML, oodb, multimedia db
Fysisch model / vragen
![Page 4: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/4.jpg)
4
Concurrentiecontrole
t
reserveer!
![Page 5: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/5.jpg)
5
Herhaling: Gewenste eigenschappen van transacties
– 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:• niveau 0: geen overschrijven van een ‘dirty read’ van een
transactie op hoger niveau• niveau 1: geen verloren aanpassingen• niveau 2: geen verloren aanpassingen en geen ‘dirty reads’• niveau 3: niveau 2 + ‘repeatable reads’
– Durability: duurzaamheid• effect van transactie moet persistent zijn, mag niet verloren gaan
concurrentie-controle
![Page 6: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/6.jpg)
6
Herhaling: Testen of garanderen 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
![Page 7: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/7.jpg)
7
Herstel
t
(plan: commit)
reserveer!rollback
![Page 8: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/8.jpg)
8
Herhaling: Gewenste eigenschappen van transacties
– 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:• niveau 0: geen overschrijven van een ‘dirty read’ van een
transactie op hoger niveau• niveau 1: geen verloren aanpassingen• niveau 2: geen verloren aanpassingen en geen ‘dirty reads’• niveau 3: niveau 2 + ‘repeatable reads’
– Durability: duurzaamheid• effect van transactie moet persistent zijn, mag niet verloren gaan
herstel
![Page 9: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/9.jpg)
9
Herhaling: Mogelijke falingen
– 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
REDOs + UNDOs
Backup + REDOs
![Page 10: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/10.jpg)
10
Agenda I
Vergrendeling (locking)
Tijdstempels
Multiversietechnieken
Optimistische concurrentiecontrole
Granulariteit van items
![Page 11: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/11.jpg)
11
Agenda I
Vergrendeling (locking)
Tijdstempels
Multiversietechnieken
Optimistische concurrentiecontrole
Granulariteit van items
![Page 12: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/12.jpg)
12
Vergrendeling
• grendel (slot, lock) • variabele horend bij een gegevenselement in de gegevensbank
• beschrijft de status van dat element t.o.v. mogelijke bewerkingen die erop kunnen worden uitgevoerd
– soorten grendels:• binaire grendels:
– twee mogelijke toestanden
• gedeelde / exclusieve grendels (of read / write locks)
– drie mogelijke toestanden
![Page 13: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/13.jpg)
13
Binaire grendels
• twee mogelijke toestanden: lock(X) = 1 of 0– 1: X is niet toegankelijk– 0: X is toegankelijk
• twee bewerkingen– lock_item(X): een transactie vraagt toegang tot X– unlock_item(X): een transactie geeft X weer vrij
(deze bewerkingen zijn steeds atomair)
![Page 14: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/14.jpg)
14
lock_item(X):B: als LOCK(X) = 0 dan LOCK(X) := 1
anderswacht tot LOCK(X) = 0;spring naar B
lock_item(X):B: als LOCK(X) = 0 dan LOCK(X) := 1
anderswacht tot LOCK(X) = 0;spring naar B
unlock_item(X):LOCK(X) := 0;als er transacties aan het wachten zijn op X:dan maak één van die transacties wakker
unlock_item(X):LOCK(X) := 0;als er transacties aan het wachten zijn op X:dan maak één van die transacties wakker
Binaire grendels: lock en unlock
• lock manager van DBMS houdt – status van grendels, – wachtende transacties etc. bij
![Page 15: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/15.jpg)
15
Regels voor vergrendeling:Elke transactie T moet volgende regels volgen
1. T moet lock_item(X) uitvoeren
voor read_item(X) of write_item(X)
2. T moet unlock_item(X) uitvoeren
nadat alle read_item(X) en write_item(X) van T zijn uitgevoerd
3. T mag geen lock_item(X) uitvoeren
als het al een grendel op T heeft
4. T mag geen unlock_item(X) uitvoeren
als het geen grendel op T heeft
![Page 16: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/16.jpg)
16
Lees- / schrijf-vergrendeling
– twee soorten grendels: lees-grendels en schrijf-grendels• ook gedeelde / exclusieve grendels genoemd
– drie toestanden voor gegevenselement:• niet vergrendeld (geen grendel)
• lees-grendel
• schrijf-grendel
– drie bewerkingen:• read_lock(X)
• write_lock(X)
• unlock_item(X)
![Page 17: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/17.jpg)
17
read_lock(X):B: als LOCK(X)="unlocked"
dan LOCK(X):="read-locked";aantal_reads(X) := 1
anders als LOCK(X) = "read-locked"dan aantal_reads(X) := aantal_reads(X)+1anders
wacht tot LOCK(X)="unlocked";spring naar B
read_lock(X):B: als LOCK(X)="unlocked"
dan LOCK(X):="read-locked";aantal_reads(X) := 1
anders als LOCK(X) = "read-locked"dan aantal_reads(X) := aantal_reads(X)+1anders
wacht tot LOCK(X)="unlocked";spring naar B
write_lock(X):B: als LOCK(X)="unlocked"
dan LOCK(X) := "write-locked"anders
wacht tot LOCK(X)="unlocked";
spring naar B
write_lock(X):B: als LOCK(X)="unlocked"
dan LOCK(X) := "write-locked"anders
wacht tot LOCK(X)="unlocked";
spring naar B
![Page 18: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/18.jpg)
18
unlock_item(X):B: als LOCK(X)="write-locked"
dan LOCK(X):="unlocked";als er transacties zijn die wachten op X:dan maak 1 ervan wakker
anders als LOCK(X) = "read-locked"dan aantal_reads(X) := aantal_reads(X)-1;
als aantal_reads(X) = 0 dan LOCK(X) := "unlocked"
als er transacties wachten op X:dan maak 1 ervan wakker
unlock_item(X):B: als LOCK(X)="write-locked"
dan LOCK(X):="unlocked";als er transacties zijn die wachten op X:dan maak 1 ervan wakker
anders als LOCK(X) = "read-locked"dan aantal_reads(X) := aantal_reads(X)-1;
als aantal_reads(X) = 0 dan LOCK(X) := "unlocked"
als er transacties wachten op X:dan maak 1 ervan wakker
![Page 19: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/19.jpg)
19
Regels voor vergrendeling (bij lees / schrijf-vergrendeling):
Elke transactie T moet volgende regels volgen:
1. T moet read_lock(X) of write_lock(X) uitvoeren
vóór eender welke read_item(X)
2. T moet write_lock(X) uitvoeren
vóór write_item(X)
3. T moet unlock(X) uitvoeren
nadat alle read_item(X) en write_item(X) uitgevoerd zijn
4. T mag geen read_lock(X) uitvoeren
als het al een (lees- of schrijf-) grendel heeft op X (*)
5. T mag geen write_lock(X) uitvoeren
als het al een (lees- of schrijf-) grendel heeft op X (*)
6. T mag geen unlock(X) uitvoeren
als het geen grendel heeft op X
![Page 20: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/20.jpg)
20
Afzwakken van regels
– (*) regels kunnen afgezwakt worden:• upgrade:
– als T al een leesgrendel op X heeft, en het is de enige transactie met een leesgrendel op X, dan kan dit met write_lock(X) in een schrijfgrendel veranderd worden
• downgrade:
– als T een schrijfgrendel op X heeft, kan dat met read_lock(X) verlaagd worden tot een leesgrendel
= conversie van grendels
![Page 21: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/21.jpg)
21
Lees-/schrijf-vergrendeling serialiseerbarheid?
– Gebruik van bovenstaande regels vermijdt bepaalde problemen
maar garandeert geen serialiseerbaarheid– vb: fig. 18.3 (volgende pagina)
• twee mogelijke seriële uitvoeringen:
– 1. tel X bij Y op, tel dan Y bij X op
– 2. tel Y bij X op, tel dan X bij Y op
– in een serieel schema zal één van de transacties de originele X/Y gebruiken en de andere de aangepaste
– in 18.3c gebruiken beide transacties de originele X/Y
• probleem: Y is te vroeg vrijgegeven
– daarom: strengere set regels (= een protocol) volgen
![Page 22: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/22.jpg)
22
Voorbeeld
![Page 23: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/23.jpg)
23
Twee-fasen-vergrendeling
– protocol van vergrendeling om bepaalde problemen te vermijden:
• alle vergrendelingen van een transactie gebeuren vóór de eerste ontgrendelbewerking
– binnen een transactie gebeurt vergrendeling steeds in twee fasen:
• "expanding phase": plaatsen van grendels
• "shrinking phase": vrijgeven van grendels
– de fasen zijn strikt gescheiden• eens een grendel vrijgegeven is, kunnen er geen nieuwe meer
geplaatst worden
– twee-fasen-vergrendeling garandeert serialiseerbaarheid• maar vermijdt geen deadlock / starvation
![Page 24: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/24.jpg)
24
T1 T2
read_lock(Y); read_lock(X);read_item(Y); read_item(X);write_lock(X); write_lock(Y);unlock(Y); unlock(X);read_item(X); read_item(Y);X:=X+Y; Y := X+Y;write_item(X); write_item(Y);unlock(X); unlock(Y);
T1:write_lock(x) verschoventot voor unlock(Y)
T2:write_lock(Y) verschoven tot voor unlock(X)
Voorbeeld: verschovene operaties
![Page 25: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/25.jpg)
25
Voorbeeld: de twee fasen
![Page 26: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/26.jpg)
26
Deadlock
• 2 processen wachten op elkaar– hebben elk een grendel die de ander wil– geven die grendel niet vrij voor ze de andere grendel krijgen
![Page 27: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/27.jpg)
27
Varianten van twee-fasen-vergrendeling
– basisversie: • zoals gezien
– conservatieve 2FV:• alle grendels plaatsen voor transactie begint
• vermijdt deadlocks
• probleem:
– niet altijd bekend op voorhand welke grendels nodig zullen zijn
– strikte, resp. rigoureuze 2FV:• geen enkel schrijfgrendel, resp. grendel vrijgeven voor commit of
abort
• garandeert een strikt rooster
• is niet deadlock-vrij
![Page 28: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/28.jpg)
28
• besluit: – twee-fasen-vergrendeling
• garandeert serialiseerbaarheid van rooster
• maar vermijdt geen deadlocks of starvation
• om dit op te lossen nog andere technieken nodig
– twee benaderingen van deadlock:• vermijden (deadlock prevention)
• opsporen (deadlock detection)
![Page 29: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/29.jpg)
29
Deadlock-vermijdende protocollen
• alles vooraf vergrendelen (cf. conservatieve 2FV)– grote beperking op concurrentie
• items steeds in welbepaalde volgorde vergrendelen– programmeur moet deze volgorde kennen: in de praktijk niet
wenselijk
• gebruik van tijdstempels (timestamps)
![Page 30: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/30.jpg)
30
Agenda I
Vergrendeling (locking)
Tijdstempels
Multiversietechnieken
Optimistische concurrentiecontrole
Granulariteit van items
![Page 31: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/31.jpg)
31
Deadlock-preventie met tijdstempels
– elke transactie T krijgt tijdstempel TS(T) toegekend• als T1 start voor T2: TS(T1) < TS(T2)
– mogelijke schema’s:• stel:
– Ti wil X vergrendelen maar kan niet omdat Tj er een grendel op heeft
• wait-die schema :
– als TS(Ti) < TS(Tj) (Ti is ouder dan Tj )
• dan mag Ti wachten tot grendel vrijkomt
• anders wordt Ti afgebroken (= de jongere transactie) en later herstart met dezelfde timestamp
• wound-wait schema :
– als TS(Ti) < TS(Tj) (Ti is ouder dan Tj )
• dan wordt Tj (de jongere transactie) afgebroken
• anders mag Ti (de jongere transactie) wachten tot grendel vrijkomt
![Page 32: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/32.jpg)
32
Vordelen en nadelen
– in beide gevallen wordt jongste transactie afgebroken en later herstart
• gemiddeld gaat minder werk verloren
– voordeel: deadlock-vrij• oudere transactie wacht steeds op jongere (wait-die) of omgekeerd
(wound-wait)
• dus nooit lussen in wachtpatroon
– nadeel:• sommige transacties worden afgebroken zelfs al zouden ze geen
deadlock veroorzaken
• wait-die : Ti mogelijk vaak afgebroken en herstart
![Page 33: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/33.jpg)
33
Deadlock-preventie zonder tijdstempels
• verschillende schema’s– niet wachten: "no waiting" schema
• als een transactie een grendel niet kan krijgen, wordt ze direct afgebroken en na een zekere tijd herstart
– voorzichtig wachten: "cautious waiting" schema• transactie mag alleen wachten op een grendel als de transactie die die
grendel heeft niet zelf aan het wachten is
– Stel: Ti wil X vergrendelen, Tj heeft grendel op X
– als Tj niet zelf wacht op een grendel
• dan laat Ti wachten
• anders breek Ti af
• is deadlock vrij!
– gebruik van timeouts:• als een transactie langer wacht dan een welbepaalde tijd, wordt ze
automatisch afgebroken en herstart• detecteert niet echt deadlocks
![Page 34: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/34.jpg)
34
Deadlock-detectie• periodieke controle of systeem in deadlock is
• enkel interessant wanneer er weinig interferentie tussen transacties is
– (korte transacties die slechts weinig items vergrendelen, of weinig transacties)
– detectie: op basis van "wacht op"-graaf• lus in graaf = deadlock
– indien deadlock: • kies slachtoffer om af te breken
– "victim selection":
• voorkeur voor jonge transacties die weinig aanpassingen gemaakt hebben
• of transacties die in meerdere cycles in de graaf betrokken zijn
![Page 35: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/35.jpg)
35
Starvation (“verhongeren”)
– definitie:• een transactie moet steeds maar blijven wachten, terwijl andere
transacties vooruitgaan
1. doordat andere wachtende transacties steeds de vrijkomende grendels krijgen, of
2. doordat de "victim selection" steeds deze transactie kiest
– oplossingen:• 1: te vermijden door eerlijke toekenning van grendels
– bv. first come, first serve
– verschillende prioriteiten + proces dat lang wacht krijgt steeds hogere prioriteit
• 2: te vermijden door eerlijke slachtofferselectie
– selecteer transactie met laagste prioriteit
– bij heropstarten van die transactie krijgt ze automatisch een hogere prioriteit
– opmerking: • wait-die en wound-wait voorkomen starvation
![Page 36: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/36.jpg)
36
Concurrentiecontrole d.m.v. tijdstempels
– serialiseerbaarheid garanderen d.m.v. tijdstempels i.p.v. grendels en deadlock-preventie/detectie
• geen grendels nodig geen deadlocks mogelijk
– er is één tijdstempel per transactie• tijdstempels zijn uniek
• en in chronologische volgorde
– T1 voor T2 aangeboden TS(T1) < TS(T2)
– tijdstempels ordenen de transacties– het transactierooster met tijdstempelordening is equivalent met
het serieel rooster met precies die volgorde van transacties
![Page 37: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/37.jpg)
37
– met elk item X worden twee tijdstempelwaarden geassocieerd:• read_TS(X)
– grootste tiidstempel van alle transacties die met succes X gelezen hebben ( jongste transactie)
• write_TS(X)
– grootste tijdstempel van alle transacties die met succes X geschreven hebben ( jongste transactie)
– voor een transactie T die read_item(X) of write_item(X) wil uitvoeren:
• vergelijk tijdstempels
• beslis of T die actie mag uitvoeren
– vb: T mag X niet lezen als X door een transactie met latere tijdstempel geschreven is
![Page 38: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/38.jpg)
38
– wat als tijdstempels niet kloppen?• transactie afbreken, ongedaan maken, en opnieuw aanbieden (nu
met latere TS)
• bij ongedaan maken (rollback):
– transacties die iets gelezen hebben dat door deze transactie geschreven werd ook ongedaan maken
– cascading rollback
– ordening op basis van tijdstempels• garandeert serialiseerbaarheid
– maar niet elk serialiseerbaar rooster wordt aanvaard
• vermijdt deadlock (maar geen starvation)
![Page 39: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/39.jpg)
39
Transactie T voert write_item(X) uit:als read_TS(X) > TS(T) of write_TS(X) > TS(T):
(write_item komt te laat, jongere transacties hebben intussen al een oudere waarde van X gelezen of een jongere geschreven)
breek T af en maak T ongedaananders
write_item(X); write_TS(X) := TS(T)
Transactie T voert read_item(X) uit:als write_TS(X) > TS(T):
(te lezen waarde is intussen al overschreven door jongere transactie)breek T af en maak T ongedaan
anders read_item(X); read_TS(X) := max(TS(T), read_TS(X))
Transactie T voert write_item(X) uit:als read_TS(X) > TS(T) of write_TS(X) > TS(T):
(write_item komt te laat, jongere transacties hebben intussen al een oudere waarde van X gelezen of een jongere geschreven)
breek T af en maak T ongedaananders
write_item(X); write_TS(X) := TS(T)
Transactie T voert read_item(X) uit:als write_TS(X) > TS(T):
(te lezen waarde is intussen al overschreven door jongere transactie)breek T af en maak T ongedaan
anders read_item(X); read_TS(X) := max(TS(T), read_TS(X))
Basis tijdstempelordeningsalgoritme
![Page 40: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/40.jpg)
40
– problemen met het basis tijdstempelordeningsalgoritme:• cascading rollbacks
• niet herstelbaar
– reeds gecommitte transacties moeten soms ook ongedaan gemaakt worden
– strikte tijdstempelordening:• = een variante van het basis algoritme
• een transactie T
– die read_item(X) of write_item(X) doet met TS(T) > write_TS(X)
– wacht met deze operatie tot de transactie met timestamp write_item(X) gecommit of afgebroken is
• garandeert strikt rooster
![Page 41: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/41.jpg)
41
Transactie T voert write_item(X) uit:als read_TS(X) > TS(T): (write_item komt te laat)
breek T af en maak T ongedaananders als write_TS(X)>TS(T): (write_item is niet meer relevant)
voer de write_item niet uit maar ga gewoon door(evt. problemen hierdoor veroorzaakt worden ontdekt door andere regels)
anders write_item(X); write_TS(X) := TS(T)
Transactie T voert write_item(X) uit:als read_TS(X) > TS(T): (write_item komt te laat)
breek T af en maak T ongedaananders als write_TS(X)>TS(T): (write_item is niet meer relevant)
voer de write_item niet uit maar ga gewoon door(evt. problemen hierdoor veroorzaakt worden ontdekt door andere regels)
anders write_item(X); write_TS(X) := TS(T)
– Thomas’ schrijfregel:licht gewijzigde versie t.o.v. basis tijdstempelordeningsalgoritme
• legt geen conflict-serialiseerbaarheid op
• verwerpt minder write_items
• wijziging aan write_item procedure:
![Page 42: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/42.jpg)
42
Agenda I
Vergrendeling (locking)
Tijdstempels
Multiversietechnieken
Optimistische concurrentiecontrole
Granulariteit van items
![Page 43: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/43.jpg)
43
Multiversie-concurrentiecontrole
– er worden meerdere waarden (versies) van een item X door het systeem bewaard:
• X1, X2, ..., Xk
– voor elke versie zijn er twee tijdstempels: • read_TS( Xi ):
– grootste TS van alle T die Xi met succes gelezen hebben
• write_TS( Xi ):
– TS van de T die Xi geschreven heeft
– als T een write_item(X) mag uitvoeren:• creatie van nieuwe versie Xk+1
• met
– read_TS(Xk+1), write_TS(Xk+1) := TS(T)
– Als T de waarde van versie Xi mag lezen:
• wordt
– read_TS(Xi) := max(read_TS(Xi), TS(T))
![Page 44: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/44.jpg)
44
Transactie T wil een write_item(X) uitvoeren:zij Xi de versie van X met de grootste write_TS(Xi) <= TS(T)als TS(T) < read_TS(Xi) (d.w.z. versie Xi zou dan moeten gelezen
zijn nadat T geschreven heeft)dan breek T af en maak T ongedaan anders
creëer nieuwe versie Xj van Xread_TS(Xj) := TS(T)write_TS(Xj) := TS(T)
Transactie T wil een read_item(X) uitvoeren:zoek de versie i van X met hoogste write_TS(Xi) <= TS(T)geef de waarde van Xi terug aan T
Transactie T wil een write_item(X) uitvoeren:zij Xi de versie van X met de grootste write_TS(Xi) <= TS(T)als TS(T) < read_TS(Xi) (d.w.z. versie Xi zou dan moeten gelezen
zijn nadat T geschreven heeft)dan breek T af en maak T ongedaan anders
creëer nieuwe versie Xj van Xread_TS(Xj) := TS(T)write_TS(Xj) := TS(T)
Transactie T wil een read_item(X) uitvoeren:zoek de versie i van X met hoogste write_TS(Xi) <= TS(T)geef de waarde van Xi terug aan T
![Page 45: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/45.jpg)
45
– Er bestaan nog andere multiversie-technieken• bv. met grendels i.p.v. tijdstempels
• ...
![Page 46: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/46.jpg)
46
Agenda I
Vergrendeling (locking)
Tijdstempels
Multiversietechnieken
Optimistische concurrentiecontrole
Granulariteit van items
![Page 47: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/47.jpg)
47
Optimistische concurrentiecontrole– methode:
• er gebeurt geen controle terwijl transactie wordt uitgevoerd
• alle aanpassingen gebeuren in lokale kopies van gegevens
• op het einde van de transactie: valideringsfase
– indien serialiseerbaarheid voldaan:
• pas gegevensbank aan, commit transactie
– indien niet:
• herstart transactie later
– drie fasen:• leesfase:
– T kan waarden van gegevensbank lezen
– aanpasingen gebeuren in lokale kopies
• valideringsfase
– controle op serialiseerbaarheid
• schrijffase:
– als controle positief blijkt, worden aanpassingen in de gegevensbank geschreven
![Page 48: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/48.jpg)
48
– voordeel:• alle controles voor een transactie in één keer ( weinig last voor
en tijdens transactie zelf)
– bij kleine interferentie tussen transacties:• meeste transacties worden succesvol gevalideerd
– bij grote interferentie:• veel volledig uitgevoerde transacties moeten herstart worden
![Page 49: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/49.jpg)
49
Implementering van optimistische concurrentiecontrole met tijdstempels
• voor elke transactie:– write_set: verzameling van alle geschreven items– read_set: verzameling van alle gelezen items– start- en eindtijd voor de 3 fasen wordt bijgehouden met
tijdstempels• valideringsfase controleert of Ti niet interfereert met een committed
transactie of met een transactie in valideringsfase:– Voor elke Tj die gecommit of in valideringsfase is, moet één
van volgende eigenschappen gelden:
1. Tj beëindigt zijn schrijffase voor Ti zijn leesfase begint
2. Ti start zijn schrijffase nadat Tj zijn schrijffase beëindigt, en read_set(Ti) write_set(Tj) =
3. Tj beëindigt leesfase voor Ti leesfase beëindigt, en
read_set(Ti) write_set(Tj) = en write_set(Ti) write_set(Tj) =
– Indien OK: • succes; • zoniet: Ti faalt ( later herstarten )
![Page 50: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/50.jpg)
50
Agenda I
Vergrendeling (locking)
Tijdstempels
Multiversietechnieken
Optimistische concurrentiecontrole
Granulariteit van items
![Page 51: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/51.jpg)
51
Granulariteit van gegevensitems
• keuze van een item– read_item, write_item: wat is een "item"?
• gegevensbank (grove granulariteit)
• bestand
• blok op schijf
• record
• veld in record (fijne granulariteit)
– hoe groter het item, • hoe minder concurrentie mogelijk
– hoe kleiner het item, • hoe meer items
• meer grendels, lock/unlock bewerkingen, tijdstempels, ...
• extra ruimte en verwerkingstijd nodig
![Page 52: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/52.jpg)
52
– ideale granulariteit hangt af van soort transactie• bv. toegang tot veel records in een bestand:
– niveau "bestand" beter
• toegang tot slechts enkele records
– niveau "record" beter
– evt. mogelijk om vergrendeling op verschillende niveaus van granulariteit uit te voeren
• keuze tussen bv. heel bestand vergrendelen, één record in bestand vergrendelen, ...
![Page 53: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/53.jpg)
53
vergrendeling met meervoudige granulariteitsniveaus
• een gegevensbanksysteem kan meerdere niveaus van granulariteit ondersteunen– voorbeeld:
• gegevensbanksysteem met twee bestanden, • elk bestand met verscheidene pagina’s, • elke pagina met verscheidene records.• met grendels die op elk niveau kunnen worden geplaatst
![Page 54: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/54.jpg)
54
Intention locks (I)
– extra type van grendels nodig: intention locks• IS: intention shared locks:
– gedeelde grendel(s) zal (zullen) gevraagd worden op lagere niveaus
• IX: intention exclusive locks:
– een exclusieve grendel zal gevraagd worden op een lager niveau
• SIX: shared-intention-exclusive locks:
– het actuele knooppunt is in gedeelde mode vergrendeld, maar een exclusieve grendel zal op een lager niveau gevraagd worden
![Page 55: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/55.jpg)
55
Intention locks (II)
compatibiliteitsmatrix:
Geeft aan of een transactie T een knooppunt kan locken indien daar al een lock op staat
S shared lockX exclusive lock
![Page 56: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/56.jpg)
56
Meervoudige granulariteitsvergrendelingsprotocol
1. de vergrendeling moet rekening houden met de compatibiliteit
2. de wortel van de boom moet eerst vergrendeld worden
3. een knooppunt N kan slechts vergrendeld worden door een transactie T in S of IS modus indien het ouder knooppunt van N reeds vergrendeld is in IS of IX modus
4. een knoopunt N kan slechts vergrendeld worden door een transactie T in X, IX of SIX modus indien het ouder knooppunt van N reeds vergrendeld is in IX of SIX modus
5. een transactie T kan een knooppunt slechts vergrendelen indien het geen knooppunt ontgrendeld heeft (om aan 2-fase protocol te voldoen)
6. een transactie T kan een knooppunt N enkel ontgrendelen indien geen van de kinderen van N op dat ogenblik vergrendeld zijn door T
compatibiliteitsmatrix:
S shared lockX exclusive lock IS intention shared lockIX intention exclusive lockSIX shared-intention- exclusive lock
![Page 57: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/57.jpg)
57
• voorbeeld:1. T1 wil record r111 en record
r211 aanpassen
2. T2 wil alle records op pagina p12 aanpassen
3. T3 wil record r11j en het volledige bestand f2 lezen
– een serializeerbaar rooster is hiernaast gegeven
aanp. r111
aanp. r211
aanp. p12
lees f2
lees r11j
aanp. r111
2
![Page 58: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/58.jpg)
58
Concurrentiecontrole in indexen
• index als boom-structuur (b.v. B+ ):– elke opdracht begint bij wortel
• wortel vergrendelen
• concurrentie in hele bestand wordt beperkt
– bij lees-grendel: enkel andere lees-opdrachten mogelijk
– bij schrijf-grendel: geen andere opdrachten mogelijk
– verschillende bewerkingen:• enkel lezen:
– index zal niet wijzigen
• aanpassing van velden in records:
– index zal niet wijzigen
• toevoeging of weglating van records:
– wijziging van index begint op laagste niveau, en kan zich tot in de wortel naar boven voortplanten
![Page 59: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/59.jpg)
59
Mogelijke oplossingen (I)
1. wanneer geen toevoegingen of weglatingen gebeuren:• vergrendeling van actuele niveau is voldoende:
• daarom:
– vergrendeling van ouder opgeven zodra naar kind wordt overgegaan
![Page 60: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/60.jpg)
60
Mogelijke oplossingen (II)
2. wanneer wel toevoegingen of weglatingen gebeuren:• eventueel een beperkt aantal niveaus vergrendelen:
– ouder ( en siblings ) van actuele knoop
– bv. vergrendeling van grootouder opgeven zodra naar kleinkind wordt overgegaan
– dit volstaat dikwijls bij aanpassingen
• indien niet voldoende niveaus vergrendeld (als aanpassing op hogere dan vergrendelde niveaus effect heeft):
– bewerking ongedaan maken en opnieuw aanbieden, ditmaal met vergrendeling op volledige pad
• zuivere “top-down” algoritmen gebruiken,
– die knooppunten die bijna vol zijn reeds splitsen tijdens afdaling
– knooppunten die erg leeg zijn reeds samenvoegen tijdens afdaling
![Page 61: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/61.jpg)
61
Einde: Agenda I
Vergrendeling (locking)
Tijdstempels
Multiversietechnieken
Optimistische concurrentiecontrole
Granulariteit van items
![Page 62: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/62.jpg)
62
Agenda II
Herstel: begrippen
Technieken voor uitgestelde aanpassing
Technieken voor onmiddellijke aanpassing
Schaduwpaginering
![Page 63: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/63.jpg)
63
Agenda II
Herstel: begrippen
Technieken voor uitgestelde aanpassing
Technieken voor onmiddellijke aanpassing
Schaduwpaginering
![Page 64: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/64.jpg)
64
Herstel: begrippen
• Definitie: – herstellen na een faling
• = correcte toestand, geldig op een tijdstip vóór de faling, reconstrueren
• dit vereist:• bijhouden van informatie over wijzigingen van gegevensitems,
buiten gegevensbank zelf:
• systeemlog
• strategie:– bij grote schade (catastrofe):
• herstel gearchiveerde versie en herdoe de committed transacties
– bij kleinere schade: • maak een aantal wijzigingen ongedaan ("undo"),
• herdoe enkele bewerkingen
![Page 65: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/65.jpg)
65
Twee soorten hersteltechnieken (bij niet-catastrofale falingen)
• uitgestelde aanpassing ("deferred update")– wijzigingen in GB pas echt aanbrengen NA het bereiken van
een commit point• intussen in lokale transactiewerkruimte bewaard
– commit • plaatst aanpassingen in log • en voert ze uit in GB
– algoritme: NO-UNDO / REDO
• onmiddellijke aanpassing ("immediate update")– wijzigingen kunnen aangebracht worden vóór bereiken van
commit point– zijn dan ook geregistreerd op log– bij faling vóór commit:
• wijzigingen ongedaan maken: roll-back
– algoritmes: UNDO / REDO of UNDO / NO-REDO
![Page 66: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/66.jpg)
66
Cache: DBMS systemen gebruiken cache
• DBMS cache:– een aantal buffers voor GB (en indexen en log) in het centrale
geheugen
– een index (directory) houdt bij welke GB items in de cache staan
• voor elke bewerking op een item:– indien item in cache: voer bewerking uit
– indien item niet in cache: haal eerst juiste pagina in cache, voer dan bewerking uit
• soms pagina's uit cache verwijderen (bv. langst niet gebruikte) om plaats te maken voor andere– indien intussen gewijzigd: schrijf naar schijf
• naar zelfde locatie ("in-place update") effectieve wijziging, log aanpassen (pagina moet evt. hersteld kunnen worden)
• of naar andere locatie ("shadowing") meerdere versies van pagina blijven beschikbaar
![Page 67: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/67.jpg)
67
– Per pagina in de cache:• dirty bit:
– geeft aan of pagina gewijzigd is
• pin / unpin bit:
– geeft aan of pagina teruggeschreven mag worden naar disk
– bv. zolang een transactie nog werk heeft in die pagina: "vastgepind" moet in cache blijven
![Page 68: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/68.jpg)
68
Log
– Log inschrijvingen:• voor REDO: nieuwe waarde (AFIM: after image)
• voor UNDO: oude waarde (BFIM)
– Write-ahead logging: • eerst log naar schijf schrijven, dan pas aanpassing doorvoeren
• is nodig bij onmiddellijke aanpassing
![Page 69: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/69.jpg)
69
Terminologie betreffende schrijven van cache blokken naar schijf
• ”steal" : – pagina uit cache naar schijf schrijven, zelfs als ze vastgepind is
• een transactie is nog niet gecommit
• wordt gebruikt wanneer cache manager het buffer frame nodig heeft voor een andere transactie
• ”force": – alle gewijzigde pagina's direct naar schijf geschreven na
commit
• vaak "Steal - no force" benadering– voordeel steal: minder intern geheugen nodig – voordeel no-force: kan heel wat I/O besparen, wanneer veel
transacties aanpassingen in dezelfde pagina aanbrengen
![Page 70: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/70.jpg)
70
Checkpoints en systeemlog
– checkpoint in systeemlog schrijven:• pauzeer transacties• schrijf alle gewijzigde buffers naar schijf• schrijf [ checkpoint ] op log• hervat transacties
– voor transacties met [ commit,T ] voor [ checkpoint ] moet geen enkele write herdaan worden
– frequentie van checkpoints schrijven: • met intervallen gemeten in tijd of aantal gecommitte transacties
– "fuzzy checkpoint":• geforceerd schrijven van alle gewijzigde buffers naar schijf kan tijd
vragen, daarom “fuzzy checkpointing”:• hervat transacties zodra [ checkpoint ] geschreven is op log, maar
voor alles naar schijf geschreven is – (vorige checkpoint blijft dan nog een tijd geldig)
![Page 71: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/71.jpg)
71
Transactie-rollback
• Transactie faalt – het effect van de transactie moet ongedaan worden gemaak
(terugrollen)– soms cascade van rollbacks veroorzaakt
• door terugrollen van een transactie moeten andere ook teruggerold worden;
– zie bv. fig. 19.1• kan tijdrovend zijn! vermijden
– cascading rollback is nooit nodig bij cascadeloze (of strikte) roosters
• de in de praktijk gebruikte technieken garanderen cascadeloze roosters
• daardoor ook geen read_item inschrijvingen nodig in log (deze zijn enkel nodig i.v.m. cascades)
![Page 72: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/72.jpg)
72
COMMIT?
COMMIT?
Voorbeeld
![Page 73: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/73.jpg)
73
Agenda II
Herstel: begrippen
Technieken voor uitgestelde aanpassing
Technieken voor onmiddellijke aanpassing
Schaduwpaginering
![Page 74: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/74.jpg)
74
Hersteltechnieken gebaseerd op uitgestelde aanpassing
– kenmerken van uitgestelde aanpassing:• een transactie kan de gegevensbank niet wijzigen vóór het
bereiken van haar commit point
• een transactie bereikt haar commit point niet vooraleer alle aanpassingsopdrachten geregistreerd zijn in de log (en de log geschreven is naar schijf)
– dus nooit undo nodig• nog-niet-definitieve wijzigingen immers nooit op schijf doorgevoerd
(enkel in cache)
– NO-UNDO / REDO herstel-algoritme
![Page 75: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/75.jpg)
75
procedure RDU_S: /* Recovery using Deferred Update - Single user */ REDO alle write_items van gecommitte transacties in de volgorde zoals ze in de log staan herstart alle actieve transacties
procedure REDO (write_opdracht): lees bijhorende log-inschrijving [write_item, T, X, nieuwe_waarde] en zet item X in de gegevensbank gelijk aan nieuwe_waarde
Single-user omgevingprocedure RDU_S
• gebruikt REDO: – opnieuw uitvoeren van een schrijfopdracht
• houdt 2 lijsten bij: – gecommitte transacties sinds vorig checkpoint
– actieve transacties (slechts één voor single user)
• opmerking: REDO moet idempotent zijn– d.w.z. meerdere keren zelfde REDO heeft zelfde effect als één keer
die REDO
![Page 76: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/76.jpg)
76
Systeemlog (voorbeeld)
![Page 77: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/77.jpg)
77
procedure RDU_M: REDO alle write_items van gecommitte transacties in de volgorde zoals ze in de log staan herstart alle actieve transacties
Multi-user omgeving
• procedure RDU_M– gebruikt weer REDO– houdt 2 lijsten bij:
• gecommitte transacties sinds vorig checkpoint
• actieve transacties
• RDU_M gaat uit van strikte 2-fasen-vergrendeling:
– grendels blijven behouden tot commit
![Page 78: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/78.jpg)
78
write opdrachten van T2 en T3 worden herdaanT4 en T5 worden herstart
Multi-user omgeving: voorbeeld
![Page 79: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/79.jpg)
79
Efficiëntere versie van NO-UNDO / REDO
– efficiëntere versie van NO-UNDO / REDO:• steeds enkel laatste write van een item doorvoeren
– log achterstevoren doorlopen– REDO write_item(X) enkel indien eerder (i.e. verder op de log)
nog geen write_item(X) tegengekomen
– indien afgebroken (b.v, bij deadlock detectie):• herstarten is eenvoudig, er is immers niets gewijzigd
![Page 80: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/80.jpg)
80
RDU_M: vordelen en nadelen
• nadeel: – slechts beperkte concurrentie van transacties mogelijk:
• alle items blijven vergrendeld tot aan commit point
– mogelijk veel bufferruimte nodig: • om alle items bij te houden tot de wijzigingen kunnen worden
vastgelegd in gegevensbank
• voordeel: – het is nooit nodig om een transactie terug te rollen
• wijzigingen worden nooit vastgelegd voor commit bereikt is• er worden nooit tijdelijke waarden (geschreven door niet-
gecommitte transacties) gelezen ( geen cascades)
![Page 81: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/81.jpg)
81
systeemlog
Voorbeeld
![Page 82: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/82.jpg)
82
Andere transactie-bewerkingen
– sommige transactie-bewerkingen hebben geen invloed op gegevensbank zelf
• bv. rapport genereren• gebruiker krijgt liever geen rapport van transactie die
achteraf faalde
dit soort bewerkingen wordt pas na commit werkelijk uitgevoerd
• "batch-jobs"
![Page 83: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/83.jpg)
83
Agenda II
Herstel: begrippen
Technieken voor uitgestelde aanpassing
Technieken voor onmiddellijke aanpassing
Schaduwpaginering
![Page 84: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/84.jpg)
84
Herstel gebaseerd op onmiddellijke aanpassing
– aanpassingen gebeuren in gegevensbank zelf, zonder commit af te wachten
– wel steeds log-inschrijving vóór aanpassing• write-ahead log protocol
– effect van aanpassing moet soms ongedaan gemaakt worden
![Page 85: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/85.jpg)
85
procedure RIU_S: UNDO alle write_items van de actieve transactie in omgekeerde volgorde van voorkomen in de log REDO alle write_items van gecommitte transacties in de volgorde zoals ze in de log voorkomen
procedure UNDO(write_opdracht): bekijk bijhorende log-inschrijving [write_item, T, X, BFIM, AFIM] stel de waarde van X in de gegevensbank gelijk aan BFIM
Single-user omgeving:procedure RIU_S
• maakt weer gebruik van REDO• houdt twee lijsten bij:
– transacties die gecommit zijn na laatste checkpoint
– actieve transacties
• gebruikt UNDO (schrijfoperatie)
![Page 86: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/86.jpg)
86
procedure RIU_M: UNDO alle write_items van de actieve transacties in omgekeerde volgorde van voorkomen in de log REDO alle write_items van gecommitte transacties in de volgorde zoals ze in de log voorkomen
Multi-user omgeving
• procedure RIU_M:– voor strikte roosters (b.v. strikte 2-fase locking)– gebruikt twee lijsten van transacties:
• transacties gecommit na laatste checkpoint
• actieve transacties
– mogelijke versnelling: alleen laatste aanpassing van elk item herdoen
![Page 87: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/87.jpg)
87
Agenda II
Herstel: begrippen
Technieken voor uitgestelde aanpassing
Technieken voor onmiddellijke aanpassing
Schaduwpaginering
![Page 88: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/88.jpg)
88
Idee
– bij begin van transactie:• construeer in centraal geheugen een paginatabel ("index") voor de
relevante delen van de gegevensbank
• kopieer paginatabel naar schijf (schaduwindex)
– gedurende transactie:• "aanpassen" van pagina = aangepaste pagina naar andere lokatie
op schijf schrijven + index aanpassen
– originele index blijft ongewijzigd (als schaduwindex)
– bij commit:• laat schaduwindex verdwijnen
• gewijzigde pagina's worden "echte" pagina's
– herstellen van toestand voor transactie :• pagina's met wijzigingen weer vrijgeven
• schaduwindex wordt weer actief
![Page 89: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/89.jpg)
89
Voorbeeld
![Page 90: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/90.jpg)
90
Voordelen en nadelen
– voordelen:• effect van transactie ongedaan maken is zeer eenvoudig
• geen REDO nodig
• bij single-user: geen log meer nodig
– nadelen:• aangepaste pagina's wijzigen van locatie op schijf
– moeilijk om bij elkaar horende pagina's bij elkaar te houden
• schrijven van (soms grote) paginatabel kan veel tijd vragen
• opruimen van overbodige pagina's na commit is nodig ("garbage collection")
• voor multi-user nog steeds log en checkpoints nodig
![Page 91: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/91.jpg)
91
Herstel na een catastrofe
• catastrofe (bv. brand) ook bestanden op schijf zijn verloren
• log niet meer beschikbaar, ...
• daarom:– regelmatige backups van hele gegevensbank– frequente backups van systeemlog
• log is kleiner dan hele gegevensbank
– na catastrofe:• gegevensbank uit laatste backup herstellen
• wijzigingen door gecommitte transacties uit meest recente beschikbare systeemlog uitvoeren
![Page 92: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/92.jpg)
92
Vooruitblik
Herstel: begrippen
Technieken voor uitgestelde aanpassing
Technieken voor onmiddellijke aanpassing
Schaduwpaginering
Data mining (en 2 woorden over data warehousing)
![Page 93: Gegevensbanken 2010 les16](https://reader036.vdocuments.site/reader036/viewer/2022070318/5577c086d8b42a1c068b4fed/html5/thumbnails/93.jpg)
93
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.
• p. 41: Robert H. Thomas, in ACM Transactions on Database Systems, 1979
• Verdere figuren: bronnen zie “Powerpoint comments field”
• Bedankt iedereen!