Begrippen van transactieverwerking

Transcriptie

1 Gegevensbanken 2010 Begrippen van transactieverwerking Bettina Berendt

2 Begrippen van transactieverwerking: Motivatie & Samenvatting 2

3 Waar zijn we? 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 functional dependencies and 9 KV normalisation 10 KV functional dependencies and normalisation 11 BB file structures and hashing 12 BB indexing I 13 BB indexing II and higher-dimensional structures 14 BB query processing 15 BB transactions 16 BB transactions II: concurrentie & herstel 17 BB Data warehousing and mining 18 ED XML, oodb, multimedia db Fysisch model / vragen 3

4 Dat willen wij niet! t reserveer! reserveer! 4

5 Agenda Inleiding tot concurrentie en herstel Transacties: begrippen Transactieroosters Serialiseren van roosters Transacties in SQL 5

6 Agenda Inleiding tot concurrentie en herstel Transacties: begrippen Transactieroosters Serialiseren van roosters Transacties in SQL 6

7 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 7

8 Interleaved en simultaneous verwerking interleaved - 1 processor simultaneous - 2 processors 8

9 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 9

10 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 T2 lees(x) X := X-N lees(x) X := X+M schrijf(x) lees(y) schrijf(x) Y := Y+N schrijf(y) vb: X = 84 N = 5 M = 4 resultaat: X = 88 i.p.v

11 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 T2 lees(x) X := X-N schrijf(x) lees(x) X := X+M schrijf(x) lees(y) Y := Y+N schrijf(y) 11

12 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) lees(x) som := som+x lees(y) som := som+y lees(y) Y := Y+N schrijf(y) T3 berekent het totaal aantal reservaties op vluchten terwijl T1 wordt uitgevoerd 12

13 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 13

14 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) 14

15 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, 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 15

16 Agenda Inleiding tot concurrentie en herstel Transacties: begrippen Transactieroosters Serialiseren van roosters Transacties in SQL 16

17 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) 17

18 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) 18

19 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 19

20 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 20

21 Overgangsdiagram tussen de statussen van de uitvoering van een transactie 21

22 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 ] 22

23 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 23

24 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 24

25 Bij faling voor transacties die gestart zijn maar niet gecommit: rollback voor gecommitte transacties: REDO alle writes Meer details: zie volgende les 25

26 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 26

27 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: niveau 0: geen overschrijven van een dirty read van een transactie op hoger niveau niveau 1: geen verloren aanpassingen niveau 2: geen verloren aanpassingen en geen dirty reads niveau 3: niveau 2 + repeatable reads Durability: duurzaamheid effect van transactie moet persistent zijn, mag niet verloren gaan 27

28 Agenda Inleiding tot concurrentie en herstel Transacties: begrippen Transactieroosters Serialiseren van roosters Transacties in SQL 28

29 Transactieroosters (schedules) Operaties van meerdere transacties in chronologische volgorde opgeschreven zie eerdere voorbeelden met T1 en T2 Ander voorbeeld: Fig roosters, 1 ervan is duidelijk fout 29

30 30

31 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 T i is volledig indien S alle operaties van de transacties T 1,, T i,, T n bevat (met inbegrip van een commit of abort operartie als laatste operatie van elke transactie, en geen andere elk paar operaties van één transactie T i in dezelfde volgorde voorkomt in S als in T i voor elk paar conflicterende operaties geldt dat de volgorde eenduidig vastligt 31

32 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 32

33 Voorbeeld schema a schema c schema d schema e T1 read (X) write(x) read(y) write(y) write(y) commit T2 read(x) write(x) commit T1 read (X) write(x) read(y) abort T2 read(x) write(x) commit T1 read (X) write(x) read(y) write(y) commit T2 read(x) write(x) commit T1 read (X) write(x) read(y) write(y) abort T2 read(x) write(x) abort herstelbaar, maar wel probleem van verloren aanpassing niet herstelbaar, T2 leest item X geschreven door T1, en commit vooraleer T1 commit, abort van T1 daarna maakt die waarde van X ongeldig wel herstelbaar: commit van T2 is uitgesteld tot na commit van T1 wel herstelbaar: indien T1 abort, moet ook T2 een abort uitvoeren 33

34 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 34

35 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 35

36 In volgorde van restrictiefheid: herstelbaar cascadeloos - strikt 1. herstelbaar rooster 2. casacadeloos rooster ; impliceert 1 3. strikt rooster ; impliceert 2 en 1 36

37 Agenda Inleiding tot concurrentie en herstel Transacties: begrippen Transactieroosters Serialiseren van roosters Transacties in SQL 37

38 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 38

39 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 39

40 Conflict-equivalentie twee roosters S 1 en S 2 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" 40

41 Testen van conflict-serialiseerbaarheid 1. maak voor elke transactie T i een knoop 2. maak een boog van T i naar T j a.s.a. T j voert een read_item(x) uit na een write_item(x) van T i of T j voert een write_item(x) uit na een read_item(x) van T i of T j voert een write_item(x) uit na een write_item(x) van T i i schrijf(x) lees(x) schrijf(x) j lees(x) schrijf(x) schrijf(x) 3. 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 ( T i,t j ) bestaat moet T i voor T j komen 41

42 Voorbeeld (1) 42

43 Voorbeeld (2) 43

44 Nog een voorbeeld (1) 44

45 Nog een voorbeeld (2) 45

46 Nog een voorbeeld (3) (roooster E op p. 44) (roooster F op p. 45) 46

47 View-equivalentie een andere, minder restrictieve definitie van equivalente roosters: Roosters S 1 en S 2 zijn view equivalent als voor elke read_item(x) in T i in S 1 geldt: de laatste write_item(x) voor die read_item(x) moet in beide roosters dezelfde write_item van dezelfde transactie T j zijn voor elke X waarvoor een write_item(x) voorkomt: de laatste write_item(x) moet dezelfde write_item van dezelfde transactie T k zijn in beide roosters m.a.w.: elke leesopdracht in S 1 leest (ziet) dezelfde waarde als overeenkomstige leesopdracht in S 2 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 47

48 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 T2 T3 read (X) write(x) write(x) write(x) commit commit commit 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 48

49 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 T3 ) 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) 49

50 In volgorde van restrictiefheid: serieel conflict-serialiseerbar view-serialiseerbar in volgorde van restrictiefheid: serieel meest restrictief conflict-serialiseerbaar view-serialiseerbaar minst restrictief minder restrictief betekent: flexibeler qua concurrentiemogelijkheden moeilijker te testen of rooster serialiseerbaar is 50

51 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 51

52 Agenda Inleiding tot concurrentie en herstel Transacties: begrippen Transactieroosters Serialiseren van roosters Transacties in SQL 52

53 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: READ UNCOMMITTED READ COMMITTED REPEATEABLE READ SERIALIZABLE default waarde 53

54 SQL serializable (1) "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 54

55 SQL serializable (2) 55

56 Voorbeeld EXEC EXEC SQL SQL WHENEVER WHENEVER SQLERROR SQLERROR GOTO GOTO UNDO; UNDO; EXEC EXEC SQL SQL SET SET TRANSACTION TRANSACTION READ READ WRITE WRITE DIAGNOSTICS DIAGNOSTICS SIZE SIZE 5 5 ISOLATION ISOLATION LEVEL LEVEL SERIALIZABLE; SERIALIZABLE; EXEC EXEC SQL SQL INSERT INSERT INTO INTO EMPLOYEE EMPLOYEE (Fname, (Fname, Lname, Lname, Ssn, Ssn, Dno, Dno, Salary) Salary) VALUES('Robert', VALUES('Robert', 'Smith', 'Smith', ' ', ' ', 2, 2, 35000); 35000); EXEC EXEC SQL SQL UPDATE UPDATE EMPLOYEE EMPLOYEE SET SET Salary Salary = = Salary Salary * * WHERE WHERE Dno Dno = = 2; 2; EXEC EXEC SQL SQL COMMIT; COMMIT; GOTO GOTO THE_END; THE_END; UNDO: UNDO: EXEC EXEC SQL SQL ROLLBACK; ROLLBACK; THE_END: 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. 56

57 Vooruitblik Inleiding tot concurrentie en herstel Transacties: begrippen Transactieroosters Serialiseren van roosters Transacties in SQL Transacties II: Concurrentie-controle en herstel 57

58 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 Alle kopieën zonder bronspecificatie: Elmasri & Navathe, Fundamentals of Database Systems, Addison Wesley / Pearson, 5e editie Verdere figuren: bronnen zie Powerpoint comments field Bedankt iedereen! 58