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