Your SlideShare is downloading. ×
Gegevensbanken 2010 les16
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Gegevensbanken 2010 les16

401
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
401
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • http://a1.phobos.apple.com/us/r1000/036/Purple/b8/86/d6/mzl.wdgryvsi.320x480-75.jpg http://iconkits.com/images/vip/scope_user_large_preview.png
  • http://a1.phobos.apple.com/us/r1000/036/Purple/b8/86/d6/mzl.wdgryvsi.320x480-75.jpg http://iconkits.com/images/vip/scope_user_large_preview.png http://www.compu-seite.de/betriebssysteme/bluescreen1.gif
  • Machtiging = delegation
  • Machtiging = delegation
  • Machtiging = delegation
  • Machtiging = delegation
  • Machtiging = delegation
  • Machtiging = delegation
  • Machtiging = delegation
  • Machtiging = delegation
  • Machtiging = delegation
  • Machtiging = delegation
  • Machtiging = delegation
  • Machtiging = delegation
  • Machtiging = delegation
  • Transcript

    • 1. Gegevensbanken 2010 Begrippen van transactieverwerking II: technieken voor concurrentiecontrole en herstel Bettina Berendt www.cs.kuleuven.be/~berendt
    • 2. Concurrentiecontrole en herstel : Motivatie & Samenvatting
    • 3. Waar zijn we? transactions query processing indexing II and higher-dimensional structures Les Nr. wie wat 1 ED intro, ER 2 ED EER 3 ED relational model 4 ED mapping EER2relational 5 KV relational algebra, relational calculus 6 KV SQL 7 KV vervolg SQL 8 KV demo Access, QBE, JDBC 9 KV functional dependencies and normalisation 10 KV functional dependencies and normalisation 11 BB file structures and hashing 12 BB indexing I 13 BB 14 BB 15 BB 16 BB transactions II: concurrentie & herstel 17 BB Data mining (and a bit on d. warehousing) 18 ED XML, oodb, multimedia db Fysisch model / vragen
    • 4. Concurrentiecontrole t Nog een plaats! U heeft hem reserveer! Wacht even Sorry ...
    • 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
    • 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
    • 7. Herstel t (plan: commit) rollback Nog een plaats! reserveer!
    • 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
    • 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
    • 10. Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van items
    • 11. Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van items
    • 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
    • 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)
    • 14. Binaire grendels: lock en unlock
      • lock manager van DBMS houdt
        • status van grendels,
        • wachtende transacties etc. bij
      lock_item(X): B : als LOCK(X) = 0 dan LOCK(X) := 1 anders wacht 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
    • 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
    • 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)
    • 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)+1 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
    • 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
    • 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
    • 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
    • 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
    • 22. Voorbeeld
    • 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
    • 24. Voorbeeld: verschovene operaties 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) verschoven tot voor unlock(Y) T2:write_lock(Y) verschoven tot voor unlock(X)
    • 25. Voorbeeld: de twee fasen
    • 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
    • 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
    • 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)
    • 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)
    • 30. Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van items
    • 31. Deadlock-preventie met tijdstempels
        • elke transactie T krijgt tijdstempel TS(T) toegekend
          • als T 1 start voor T 2 : TS(T 1 ) < TS(T 2 )
        • mogelijke schema’s:
          • stel:
            • T i wil X vergrendelen maar kan niet omdat T j er een grendel op heeft
          • wait-die schema :
            • als TS(T i ) < TS(T j ) (T i is ouder dan T j )
              • dan mag T i wachten tot grendel vrijkomt
              • anders wordt T i afgebroken (= de jongere transactie) en later herstart met dezelfde timestamp
          • wound-wait schema :
            • als TS(T i ) < TS(T j ) (T i is ouder dan T j )
              • dan wordt T j (de jongere transactie) afgebroken
              • anders mag T i (de jongere transactie) wachten tot grendel vrijkomt
    • 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 : T i mogelijk vaak afgebroken en herstart
    • 33. Deadlock-preventie zonder tijdstempels
      • verschillende schema’s
        • niet wachten: &quot;no waiting&quot; schema
          • als een transactie een grendel niet kan krijgen, wordt ze direct afgebroken en na een zekere tijd herstart
        • voorzichtig wachten: &quot;cautious waiting&quot; schema
          • transactie mag alleen wachten op een grendel als de transactie die die grendel heeft niet zelf aan het wachten is
            • Stel: T i wil X vergrendelen, T j heeft grendel op X
            • als T j niet zelf wacht op een grendel
              • dan laat T i wachten
              • anders breek T i 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
    • 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 &quot;wacht op&quot;-graaf
          • lus in graaf = deadlock
        • indien deadlock:
          • kies slachtoffer om af te breken
            • &quot;victim selection&quot;:
              • voorkeur voor jonge transacties die weinig aanpassingen gemaakt hebben
              • of transacties die in meerdere cycles in de graaf betrokken zijn
    • 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 &quot;victim selection&quot; 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
    • 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
            • T 1 voor T 2 aangeboden  TS(T 1 ) < TS(T 2 )
        • tijdstempels ordenen de transacties
        • het transactierooster met tijdstempelordening is equivalent met het serieel rooster met precies die volgorde van transacties
    • 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
    • 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)
    • 39. Basis tijdstempelordeningsalgoritme 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 ongedaan anders 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))
    • 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
    • 41.
        • Thomas’ schrijfregel:
          • licht gewijzigde versie t.o.v. basis tijdstempelordeningsalgoritme
          • legt geen conflict-serialiseerbaarheid op
          • verwerpt minder write_items
          • wijziging aan write_item procedure:
      Transactie T voert write_item(X) uit: als read_TS(X) > TS(T): (write_item komt te laat) breek T af en maak T ongedaan anders 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)
    • 42. Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van items
    • 43. Multiversie-concurrentiecontrole
        • er worden meerdere waarden (versies) van een item X door het systeem bewaard:
          • X 1 , X 2 , ..., X k
        • voor elke versie zijn er twee tijdstempels:
          • read_TS( X i ):
            • grootste TS van alle T die X i met succes gelezen hebben
          • write_TS( X i ):
            • TS van de T die X i geschreven heeft
        • als T een write_item(X) mag uitvoeren:
          • creatie van nieuwe versie X k+1
          • met
            • read_TS(X k+1 ), write_TS(X k+1 ) := TS(T)
        • Als T de waarde van versie X i mag lezen :
          • wordt
            • read_TS(X i ) := max(read_TS(X i ), TS(T))
    • 44. Transactie T wil een write_item(X) uitvoeren: zij X i de versie van X met de grootste write_TS(X i ) <= TS(T) als TS(T) < read_TS(X i ) (d.w.z. versie X i zou dan moeten gelezen zijn nadat T geschreven heeft) dan breek T af en maak T ongedaan anders creëer nieuwe versie X j van X read_TS(X j ) := TS(T) write_TS(X j ) := TS(T) Transactie T wil een read_item(X) uitvoeren: zoek de versie i van X met hoogste write_TS(X i ) <= TS(T) geef de waarde van X i terug aan T
    • 45.
        • Er bestaan nog andere multiversie-technieken
          • bv. met grendels i.p.v. tijdstempels
          • ...
    • 46. Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van items
    • 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
    • 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
    • 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 T i niet interfereert met een committed transactie of met een transactie in valideringsfase:
            • Voor elke T j die gecommit of in valideringsfase is, moet één van volgende eigenschappen gelden:
              • 1. T j beëindigt zijn schrijffase voor T i zijn leesfase begint
              • 2. T i start zijn schrijffase nadat T j zijn schrijffase beëindigt, en read_set(T i )  write_set(T j ) = 
              • 3. T j beëindigt leesfase voor T i leesfase beëindigt, en
              • read_set(T i )  write_set(T j ) =  en write_set(T i )  write_set(T j ) = 
            • Indien OK:
              • succes;
              • zoniet: T i faalt ( later herstarten )
    • 50. Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van items
    • 51. Granulariteit van gegevensitems
      • keuze van een item
        • read_item, write_item: wat is een &quot;item&quot;?
          • 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
    • 52.
        • ideale granulariteit hangt af van soort transactie
          • bv. toegang tot veel records in een bestand:
            • niveau &quot;bestand&quot; beter
          • toegang tot slechts enkele records
            • niveau &quot;record&quot; beter
        • evt. mogelijk om vergrendeling op verschillende niveaus van granulariteit uit te voeren
          • keuze tussen bv. heel bestand vergrendelen, één record in bestand vergrendelen, ...
    • 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
    • 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
    • 55. Intention locks (II) compatibiliteitsmatrix: Geeft aan of een transactie T een knooppunt kan locken indien daar al een lock op staat S shared lock X exclusive lock
    • 56. Meervoudige granulariteitsvergrendelingsprotocol
      • de vergrendeling moet rekening houden met de compatibiliteit
      • de wortel van de boom moet eerst vergrendeld worden
      • 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
      • 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
      • een transactie T kan een knooppunt slechts vergrendelen indien het geen knooppunt ontgrendeld heeft (om aan 2-fase protocol te voldoen)
      • 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 lock X exclusive lock IS intention shared lock IX intention exclusive lock SIX shared-intention- exclusive lock
    • 57.
      • voorbeeld:
        • T 1 wil record r 111 en record r 211 aanpassen
        • T 2 wil alle records op pagina p 12 aanpassen
        • T 3 wil record r 11j en het volledige bestand f 2 lezen
        • een serializeerbaar rooster is hiernaast gegeven
      aanp. r 111 aanp. r 211 aanp. p 12 lees f 2 lees r 11j aanp. r 111 2
    • 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
    • 59. Mogelijke oplossingen (I)
        • wanneer geen toevoegingen of weglatingen gebeuren:
          • vergrendeling van actuele niveau is voldoende:
          • daarom:
            • vergrendeling van ouder opgeven zodra naar kind wordt overgegaan
    • 60. Mogelijke oplossingen (II)
        • 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
    • 61. Einde: Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van items
    • 62. Agenda II Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpaginering
    • 63. Agenda II Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpaginering
    • 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 (&quot;undo&quot;),
          • herdoe enkele bewerkingen
    • 65. Twee soorten hersteltechnieken (bij niet-catastrofale falingen)
      • uitgestelde aanpassing (&quot;deferred update&quot;)
        • 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 (&quot;immediate update&quot;)
        • 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
    • 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 (&quot;in-place update&quot;)  effectieve wijziging, log aanpassen (pagina moet evt. hersteld kunnen worden)
          • of naar andere locatie (&quot;shadowing&quot;)  meerdere versies van pagina blijven beschikbaar
    • 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: &quot;vastgepind&quot;  moet in cache blijven
    • 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
    • 69. Terminologie betreffende schrijven van cache blokken naar schijf
      • ” steal&quot; :
        • 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&quot;:
        • alle gewijzigde pagina's direct naar schijf geschreven na commit
      • vaak &quot;Steal - no force&quot; benadering
        • voordeel steal: minder intern geheugen nodig
        • voordeel no-force: kan heel wat I/O besparen, wanneer veel transacties aanpassingen in dezelfde pagina aanbrengen
    • 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
        • &quot;fuzzy checkpoint&quot;:
          • 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)
    • 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)
    • 72. COMMIT? COMMIT? Voorbeeld
    • 73. Agenda II Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpaginering
    • 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
    • 75. Single-user omgeving procedure 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
      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
    • 76. Systeemlog (voorbeeld)
    • 77. 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
      procedure RDU_M: REDO alle write_items van gecommitte transacties in de volgorde zoals ze in de log staan herstart alle actieve transacties
    • 78. write opdrachten van T 2 en T 3 worden herdaan T 4 en T 5 worden herstart Multi-user omgeving: voorbeeld
    • 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
    • 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)
    • 81. systeemlog Voorbeeld
    • 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
          • &quot;batch-jobs&quot;
    • 83. Agenda II Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpaginering
    • 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
    • 85. 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)
      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
    • 86. 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
      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
    • 87. Agenda II Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpaginering
    • 88. Idee
        • bij begin van transactie:
          • construeer in centraal geheugen een paginatabel (&quot;index&quot;) voor de relevante delen van de gegevensbank
          • kopieer paginatabel naar schijf (schaduwindex)
        • gedurende transactie:
          • &quot;aanpassen&quot; 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 &quot;echte&quot; pagina's
        • herstellen van toestand voor transactie :
          • pagina's met wijzigingen weer vrijgeven
          • schaduwindex wordt weer actief
    • 89. Voorbeeld
    • 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 (&quot;garbage collection&quot;)
          • voor multi-user nog steeds log en checkpoints nodig
    • 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
    • 92. Vooruitblik Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpaginering Data mining (en 2 woorden over data warehousing)
    • 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!