0
Gegevensbanken 2010 Begrippen van transactieverwerking II: technieken voor concurrentiecontrole  en herstel Bettina Berend...
Concurrentiecontrole  en herstel :  Motivatie & Samenvatting
Waar zijn we? transactions query processing indexing II and higher-dimensional structures Les Nr. wie wat 1 ED intro, ER 2...
Concurrentiecontrole t Nog een plaats! U heeft hem reserveer! Wacht even Sorry ...
Herhaling:  Gewenste eigenschappen van transacties <ul><ul><li>Atomicity : ondeelbaarheid </li></ul></ul><ul><ul><ul><li>t...
Herhaling:  Testen of garanderen van serialiseerbarheid <ul><li>Problemen met testen van serialiseerbaarheid: </li></ul><u...
Herstel t (plan: commit) rollback Nog een plaats! reserveer!
Herhaling:  Gewenste eigenschappen van transacties <ul><ul><li>Atomicity : ondeelbaarheid </li></ul></ul><ul><ul><ul><li>t...
Herhaling:  Mogelijke falingen <ul><ul><li>Mogelijke falingen die tijdens de uitvoering van een transactie kunnen optreden...
Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van i...
Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van i...
Vergrendeling <ul><li>grendel (slot,  lock )  </li></ul><ul><ul><ul><li>variabele horend bij een gegevenselement in de geg...
Binaire grendels <ul><li>twee mogelijke toestanden: lock(X) = 1 of 0 </li></ul><ul><ul><li>1: X is niet toegankelijk </li>...
Binaire grendels: lock en unlock <ul><li>lock manager van DBMS houdt  </li></ul><ul><ul><li>status van grendels,  </li></u...
Regels voor vergrendeling: Elke transactie T moet volgende regels volgen <ul><ul><ul><li>1. T moet  </li></ul></ul></ul><u...
Lees- / schrijf-vergrendeling <ul><ul><li>twee soorten grendels: lees-grendels en schrijf-grendels </li></ul></ul><ul><ul>...
read_lock(X): B :  als  LOCK(X)=&quot;unlocked&quot;  dan   LOCK(X):=&quot;read-locked&quot;; aantal_reads(X) := 1 anders ...
unlock_item(X): B :  als  LOCK(X)=&quot;write-locked&quot;  dan   LOCK(X):=&quot;unlocked&quot;; als  er transacties zijn ...
Regels voor vergrendeling  (bij lees / schrijf-vergrendeling):   Elke transactie T moet volgende regels volgen: <ul><ul><u...
Afzwakken van regels <ul><ul><li>(*)  regels kunnen afgezwakt worden: </li></ul></ul><ul><ul><ul><li>upgrade:  </li></ul><...
Lees-/schrijf-vergrendeling    serialiseerbarheid? <ul><ul><li>Gebruik van bovenstaande regels vermijdt bepaalde probleme...
Voorbeeld
Twee-fasen-vergrendeling <ul><ul><li>protocol van vergrendeling om bepaalde problemen te vermijden: </li></ul></ul><ul><ul...
Voorbeeld: verschovene operaties T1  T2 read_lock(Y);  read_lock(X); read_item(Y);  read_item(X); write_lock(X) ;  write_l...
Voorbeeld: de twee fasen
Deadlock <ul><li>2 processen wachten op elkaar </li></ul><ul><ul><li>hebben elk een grendel die de ander wil </li></ul></u...
Varianten van twee-fasen-vergrendeling <ul><ul><li>basisversie:  </li></ul></ul><ul><ul><ul><li>zoals gezien </li></ul></u...
<ul><li>besluit:  </li></ul><ul><ul><li>twee-fasen-vergrendeling </li></ul></ul><ul><ul><ul><li>garandeert serialiseerbaar...
Deadlock-vermijdende protocollen <ul><li>alles vooraf vergrendelen (cf. conservatieve 2FV) </li></ul><ul><ul><li>grote bep...
Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van i...
Deadlock-preventie met tijdstempels <ul><ul><li>elke transactie T krijgt tijdstempel TS(T) toegekend </li></ul></ul><ul><u...
Vordelen en nadelen <ul><ul><li>in beide gevallen wordt jongste transactie afgebroken en later herstart </li></ul></ul><ul...
Deadlock-preventie zonder tijdstempels <ul><li>verschillende schema’s </li></ul><ul><ul><li>niet wachten: &quot;no waiting...
Deadlock-detectie <ul><li>periodieke controle of systeem in deadlock is </li></ul><ul><ul><ul><li>enkel interessant wannee...
Starvation  (“verhongeren”) <ul><ul><li>definitie: </li></ul></ul><ul><ul><ul><li>een transactie moet steeds maar blijven ...
Concurrentiecontrole d.m.v. tijdstempels <ul><ul><li>serialiseerbaarheid garanderen d.m.v. tijdstempels i.p.v. grendels en...
<ul><ul><li>met elk item X worden twee tijdstempelwaarden geassocieerd: </li></ul></ul><ul><ul><ul><li>read_TS(X) </li></u...
<ul><ul><li>wat als tijdstempels niet kloppen? </li></ul></ul><ul><ul><ul><li>transactie afbreken, ongedaan maken, en opni...
Basis tijdstempelordeningsalgoritme Transactie T voert  write_item(X)  uit: als  read_TS(X) > TS(T) of write_TS(X) > TS(T)...
<ul><ul><li>problemen met het basis tijdstempelordeningsalgoritme: </li></ul></ul><ul><ul><ul><li>cascading rollbacks </li...
<ul><ul><li>Thomas’ schrijfregel: </li></ul></ul><ul><ul><ul><li>licht gewijzigde versie t.o.v. basis tijdstempelordenings...
Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van i...
Multiversie-concurrentiecontrole <ul><ul><li>er worden meerdere waarden (versies) van een item X door het systeem bewaard:...
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...
<ul><ul><li>Er bestaan nog andere multiversie-technieken </li></ul></ul><ul><ul><ul><li>bv. met grendels i.p.v. tijdstempe...
Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van i...
Optimistische concurrentiecontrole <ul><ul><li>methode: </li></ul></ul><ul><ul><ul><li>er gebeurt geen controle terwijl tr...
<ul><ul><li>voordeel: </li></ul></ul><ul><ul><ul><li>alle controles voor een transactie in één keer (   weinig last voor ...
Implementering van optimistische concurrentiecontrole met tijdstempels <ul><ul><ul><li>voor elke transactie: </li></ul></u...
Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granulariteit van i...
Granulariteit van gegevensitems <ul><li>keuze van een item </li></ul><ul><ul><li>read_item, write_item: wat is een &quot;i...
<ul><ul><li>ideale granulariteit hangt af van soort transactie </li></ul></ul><ul><ul><ul><li>bv. toegang tot veel records...
vergrendeling met meervoudige granulariteitsniveaus <ul><li>een gegevensbanksysteem kan meerdere niveaus van granulariteit...
Intention locks (I) <ul><ul><li>extra type van grendels nodig: intention locks </li></ul></ul><ul><ul><ul><li>IS: intentio...
Intention locks (II) compatibiliteitsmatrix: Geeft aan of een transactie T een knooppunt kan locken  indien daar al een lo...
Meervoudige granulariteitsvergrendelingsprotocol <ul><li>de vergrendeling moet rekening houden met de compatibiliteit  </l...
<ul><li>voorbeeld: </li></ul><ul><ul><li>T 1  wil record r 111  en record r 211  aanpassen </li></ul></ul><ul><ul><li>T 2 ...
Concurrentiecontrole in indexen <ul><li>index als boom-structuur (b.v. B +  ): </li></ul><ul><ul><li>elke opdracht begint ...
Mogelijke oplossingen (I) <ul><ul><li>wanneer geen toevoegingen of weglatingen gebeuren: </li></ul></ul><ul><ul><ul><li>ve...
Mogelijke oplossingen (II) <ul><ul><li>wanneer wel toevoegingen of weglatingen gebeuren: </li></ul></ul><ul><ul><ul><li>ev...
Einde:  Agenda I Vergrendeling (locking) Tijdstempels Multiversietechnieken Optimistische concurrentiecontrole Granularite...
Agenda II Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpagine...
Agenda II Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpagine...
Herstel: begrippen <ul><li>Definitie:  </li></ul><ul><ul><li>herstellen na een faling  </li></ul></ul><ul><ul><ul><li>= co...
Twee soorten hersteltechnieken  (bij niet-catastrofale falingen) <ul><li>uitgestelde aanpassing  (&quot;deferred update&qu...
Cache: DBMS systemen gebruiken cache <ul><li>DBMS cache: </li></ul><ul><ul><li>een aantal buffers voor GB (en indexen en l...
<ul><ul><li>Per pagina in de cache: </li></ul></ul><ul><ul><ul><li>dirty bit: </li></ul></ul></ul><ul><ul><ul><ul><li>geef...
Log <ul><ul><li>Log inschrijvingen: </li></ul></ul><ul><ul><ul><li>voor REDO: nieuwe waarde (AFIM: after image) </li></ul>...
Terminologie betreffende schrijven van cache blokken naar schijf <ul><li>” steal&quot; :  </li></ul><ul><ul><li>pagina uit...
Checkpoints en systeemlog <ul><ul><li>checkpoint in systeemlog schrijven: </li></ul></ul><ul><ul><ul><li>pauzeer transacti...
Transactie-rollback <ul><li>Transactie faalt  </li></ul><ul><ul><li>   het effect van de transactie moet ongedaan worden ...
COMMIT? COMMIT? Voorbeeld
Agenda II Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpagine...
Hersteltechnieken gebaseerd op uitgestelde aanpassing <ul><ul><li>kenmerken van uitgestelde aanpassing: </li></ul></ul><ul...
Single-user omgeving procedure RDU_S <ul><li>gebruikt REDO:  </li></ul><ul><ul><li>opnieuw uitvoeren van een schrijfopdrac...
Systeemlog (voorbeeld)
Multi-user omgeving <ul><li>procedure RDU_M </li></ul><ul><ul><li>gebruikt weer REDO </li></ul></ul><ul><ul><li>houdt 2 li...
write opdrachten van T 2  en  T 3  worden herdaan T 4  en T 5  worden herstart Multi-user omgeving: voorbeeld
Efficiëntere versie van NO-UNDO / REDO <ul><ul><li>efficiëntere versie van NO-UNDO / REDO: </li></ul></ul><ul><ul><ul><li>...
RDU_M: vordelen en nadelen <ul><li>nadeel:  </li></ul><ul><ul><li>slechts beperkte concurrentie van transacties mogelijk: ...
systeemlog Voorbeeld
Andere transactie-bewerkingen <ul><ul><li>sommige transactie-bewerkingen hebben geen invloed op gegevensbank zelf </li></u...
Agenda II Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpagine...
Herstel gebaseerd op onmiddellijke aanpassing <ul><ul><li>aanpassingen gebeuren in gegevensbank zelf, zonder commit af te ...
Single-user omgeving: procedure RIU_S <ul><li>maakt weer gebruik van REDO </li></ul><ul><li>houdt twee lijsten bij:  </li>...
Multi-user omgeving <ul><li>procedure RIU_M: </li></ul><ul><ul><li>voor strikte roosters (b.v. strikte 2-fase locking) </l...
Agenda II Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpagine...
Idee <ul><ul><li>bij begin van transactie: </li></ul></ul><ul><ul><ul><li>construeer in centraal geheugen een paginatabel ...
Voorbeeld
Voordelen en nadelen <ul><ul><li>voordelen: </li></ul></ul><ul><ul><ul><li>effect van transactie ongedaan maken is zeer ee...
Herstel na een catastrofe <ul><li>catastrofe (bv. brand)    ook bestanden op schijf zijn verloren </li></ul><ul><li>   ...
Vooruitblik Herstel: begrippen Technieken voor uitgestelde aanpassing Technieken voor onmiddellijke aanpassing Schaduwpagi...
Bronnen <ul><li>Deze slides zijn gebaseerd op Henk Olivié‘s slides voor Gegevensbanken 2009 en op  Elmasri & Navathe, Fund...
Upcoming SlideShare
Loading in...5
×

Gegevensbanken 2010 les16

416

Published on

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

  • Be the first to like this

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

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 of "Gegevensbanken 2010 les16"

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

      Clipping is a handy way to collect important slides you want to go back to later.

    ×