Gegevensbanken_2012_Les14_Transacties

January 8, 2018 | Author: Anonymous | Category: Engineering & Technology, Elektrotechniek, Microelectronics
Share Embed Donate


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

Copyright � 2017 NANOPDF Inc.
SUPPORT NANOPDF