Föreläsning 7: Transaktioner

Föreläsning 7: Transaktioner DVA234 Databaser IDT Akademin för Innovation, Design och Teknik

Innehåll Föreläsningens mål: Att ge en överblick transaktioner och samtidighet i databaser fungerar Transaktioner BEGIN TRANSACTION, COMMIT, ROLLBACK Transaktionshantering ACID-egenskaperna Rollbackhantering Samtidighet (concurrency) Pessimistic concurrency-control Optimistisk concurrency-control 2

Logiska arbetsenheter Tänk er en stored procedure för att föra över pengar mellan 2 konton Processen kräver flera delsteg som måste utföras tillsammans. Detta kallas en logisk arbetsenhet Steg 1: Läs saldot på konto 1 Steg 2: Minska saldot på konto 1 med N kr Steg 3: Läs saldot på konto 2 Steg 4: Öka saldot på konto 2 med N kr Vad händer om något går fel i steg 3 och proceduren avbryts? Kunden har förlorat N kr på konto 1 3

Orsaker till fel Så vad kan egentligen gå fel vid överföringen? 1. Fysiska fel, t.ex. Servern går plötsligt ner Diskfel gör att databasfilen är korrupt 2. Semantiska fel, t.ex. Konto 2 finns inte så steg 3 (läs saldo from konto 2) renderar fel 3. Samtidighetsfel (Concurrency errors), t.ex. Någon tar samtidigt ut pengar från samma konton i en bankomat Denna föreläsning tittar vi på hur man hanterar fall 2 och 3 Fysiska fel går vi igenom nästa vecka 4

Struktur på logisk arbetsenhet En stored procedure skrivs typiskt i SQL Denna kan dock brytas ner i mindre beståndsdelar SELECT är ju egentligen läsningar från DB INSERT är ju egentligen skrivningar till DB, och UPDATE och DELETE är ju skrivningar och ev. läsningar till/från DB Därför bryter vi ner proceduren i två beståndsdelar: En läsning av dataobjekt X till lokal variabel x WRITE X En skrivning av lokal variabel x till dataobjekt X Där X kan vara en rad i en tabell, en hel tabell eller ett enskilt värde I detta sammanhang spelar det inte så stor roll x (kursivt) är namnet på den lokala variabel som vi läser till/skriver från 5

Hur går läsningar/skrivningar till? Transaktion Databas 1. 2. x=x+15 3. WRITE X Dataobjekt X 1. Dataobjekt X läses in från databasen och lagras lokalt i transaktionen som x. 2. Lokala variabeln x ökas med 15 (X lämnas orörd). 3. Lokala variabeln x skrivs tillbaks till dataobjekt X i databasen. 6

Överföring som logisk arbetsenhet Vi kan därför bryta ner vår stored procedure till Logisk arbetsenhet 1 (WU1) x=x-n WRITE X READ Y y=y+n WRITE Y -- läs in konto X till lokal variabel -- minskning av lokal variabel med N kr -- skriv nya saldot till konto X -- läs in konto Y till lokal variabel -- ökning av lokal variabel med N kr -- skriv nya saldot till konto Y Låt oss också skapa en till logisk arbetsenhet för att sätta in pengar (WU2) -- läs in konto X till lokal variabel x=x+m -- ökning av lokal variabel med M kr WRITE X -- skriv nya saldot till konto X 7

Samtidiga användare En databasserver skall ju kunna hantera samtidiga användare Banker Massor av kunder som sätter in och tar ut samtidigt Det FÅR inte bli så att man nån gång tappar bort pengar Biljettsläpp till Bruce Springsteen tusentals personer vill åt biljetter Jobbigt om flera köper samma plats Därför klarar databasservrar av att köra flera arbetsenheter samtidigt: Man låter en arbetsenhet köra en liten stund Man avbryter körningen och låter en annan köra Sedan får den första köra igen, osv Detta kallas INTERLEAVING Ni kommer att jobba massor med detta i Operativsystemskursen 8

Exempel på Interleaving WU 1 WU 2 x=x-n WRITE X x=x+m WRITE X READ Y y=y+n WRITE Y Tid I detta fallet får WU1 köra en liten stund, WU2 kör hela, och WU1 kör sedan klart Semantiskt blir detta scenario rätt, men det kan gå väldigt snett!!! 9

Tre vanliga fel vid interleaving 1. Förlorade uppdateringar (Lost updates) 2. Smutsiga läsningar (Dirty reads) 3. Felaktiga summor Förutom dessa finns andra fel Spökposter (phantom reads), Oupprepbara läsningar (nonrepeatable reads) osv 10

Förlorade uppdateringar (lost updates) WU 1 WU 2 Exempel WU 1 läser in 100 kr från X x=x-n WU 1 minskar lok var till 50kr WU 2 läser in 100 kr från X x=x+m WU 2 ökar lok var till 125kr WRITE X WU 1 skriver 50kr till X i DB READ Y WRITE X WU2 skriver 125kr till X i DB y=y+n WRITE Y Denna uppdatering är förlorad I detta fallet skriver WU 2 över uttaget som WU 1 gjorde Man har 50 kronor för mycket på konto X 11

Smutsiga läsningar (Dirty reads) WU 1 WU 2 Exempel WU 1 läser in 100 kr från X x=x-n WU 1 minskar lok var till 50kr WRITE X WU 1 skriver 50kr till X i DB WU 2 läser in 50 kr från X x=x+m WU 2 ökar lok var till 75kr WRITE X WU2 skriver 75kr till X i DB READ Y WU 1 Error konto Y finns ej Vad skall WU2 göra nu??? WU2 har läst ett smutsigt data (från WU1 som inte avslutas) I detta fall har WU 2 baserat sin operation på WU 1 som avbröts Vi har här förlorat pengar Alt 1, WU 1 gör inget à 50kr borta Alt 2, WU 1 backar sin skrivning och sätter X =100 igen à 25 kr borta Notera att WU 1 inte förstår semantiken för WU 2 och kan rädda den 12

Felaktiga summeringar x=x-n WRITE X READ Y y=y+n WRITE Y WU 1 WU 3 Exempel sum=0 READ A sum=sum+a sum=sum+x READ Y sum=sum+y WU 3 skall summera saldon för en kunds alla konton Uttaget från X syns här Här tappas pengarna in transit bort N har tagits ut från X men inte hunnit sättas in på Y 13

Tre huvudproblem Hur skall databashanteraren hantera Backande av arbetsenheter som avbryts? Samtidiga arbetsenheter? Räddande av arbetsenheter (pågående och avslutade) vid en systemkrasch? (Detta tittar vi på på nästa föreläsning) 14

Transaktionshantering Transaktionshantering innebär en garanti att inget data går förlorat i en transaktion att förändringar som görs i en misslyckad transaktion blir ogjorda att förändringar som görs i en lyckad transaktion verkligen utförs DBMS-komponenten som tillhandahåller transaktionshantering kallas Transaction Manager Och operatorerna för att jobba mot TM är: BEGIN TRANSACTION: Signalerar början på en transaktion. COMMIT: Signalerar lyckat avslut för en transaktion, att ändringar som gjorts i transaktionen skall permanentas. ROLLBACK: Signalerar misslyckat avslut för en transaktion, att ändringar som gjorts i transaktionen skall göras ogjorda ( rullas tillbaka ). 15

Några ord om Rollback Det finns 3 skäl till varför en rollback sker: 1. Användaren väljer att göra rollback, t.ex. om man lägger till IF saldo<n ROLLBACK i sin transaktion 2. Databasen upptäcker något semantiskt fel i transaktionen, t.ex. konto 2 finns ej. 3. Transaktionen har kommit i konflikt med annan transaktion (vi kommer till det strax) 16

Pseudokod för en transaktion BEGIN TRANSACTION; UPDATE Konto SET Saldo=Saldo-300 WHERE Pnr= 7603311234 AND Kontonr=1; IF error ROLLBACK; COMMIT; UPDATE Konto SET Saldo=Saldo+300 WHERE Pnr= 7603311234 AND Kontonr=2; IF error ROLLBACK; Dessa tre operatorer BEGIN TRANSACTION, ROLLBACK, COMMIT är egentligen det enda ni behöver veta som användare av transaktioner 17

Arbetsenhet vs transaktion En arbetsenhet som annoteras med transaktionsoperationer blir en transaktion, t.ex.: WU 1 x=x-n WRITE X READ Y y=y+n WRITE Y T 1 BEGIN TRANSACTION IF x<n ROLLBACK x=x-n WRITE X READ Y y=y+n WRITE Y COMMIT 18

ACID-egenskaperna Transaktioner har fyra viktiga garantier, de sk. ACID-egenskaperna Atomicity En transaktion utförs atomärt, dvs allt eller inget Consistency En transaktion bevarar konsistens i databasen DB ska vara konsistent före och efter men ej nödvändigtvis inom en transaktion Isolation Transaktioner är isolerade från varandra, dvs ändringar som sker inom en transaktion ska inte synas för andra transaktioner förrän efter COMMIT. Durability När en transaktion gör COMMIT skall ev. ändringar alltid bestå, även vid en efterföljande krasch 19

Vad innebär då detta? Transaktionshanteraren som finns i servern upprätthåller automatiskt ACID egenskaperna. Det behöver man alltså inte tänka på som användare Detta sker med hjälp av ett flertal mekanismer i servern som: Loggar alla skrivningar som transaktioner gör Låser transaktioner som är i potentiell konflikt med varandra Avbryter transaktioner som hamnat i olösbara konflikter Bara för att vara tydlig: Resten av denna föreläsning visar de interna mekanismerna inne i servern. Som användare eller utvecklare av transaktioner behöver man inte skapa loggar eller sätta lås i sina transaktioner utan det gör servern utifrån era transaktionsoperationer!!!! 20

Transaktionsloggning En transaktionslogg används för att hålla reda på vilka transaktioner som f.n. kör, samt hur långt de har kommit i exekveringen. Loggen (eller journalen) sparas på disk (eller på band i riktigt stora databassystem) Transaktionsloggen konsulteras när en transaktion vill göra ROLLBACK program avslut 21

Transaktionsloggen Transaktionen T1 Begin Transaction Read X.attr à a Read Y.attr à b Write Z.attr ß a + b Write W.attr ß a * b COMMIT Transaktionslogg för T1 <TIME1> Transaction begins (a,b är lokala variabler) EXEMPELTABELL PK Attr X 2 Y 4 Z 99 W 7 22

Transaktionsloggen Transaktionen T1 Begin Transaction Read X.attr à a Read Y.attr à b Write Z.attr ß a + b Write W.attr ß a * b COMMIT Transaktionslogg för T1 <TIME1> Transaction begins <TIME2> Write Z, Old=99, New=6 (a,b är lokala variabler) EXEMPELTABELL PK Attr X 2 Y 4 Z 99 6 W 7 25

Transaktionsloggen Transaktionen T1 Begin Transaction Read X.attr à a Read Y.attr à b Write Z.attr ß a + b Write W.attr ß a * b COMMIT Transaktionslogg för T1 <TIME1> Transaction begins <TIME2> Write Z, Old=99, New=6 <TIME3> Write W, Old=7, New=8 (a,b är lokala variabler) EXEMPELTABELL PK Attr X 2 Y 4 Z 99 6 W 7 8 26

Transaktionsloggen Transaktionen T1 Begin Transaction Read X.attr à a Read Y.attr à b Write Z.attr ß a + b Write W.attr ß a * b COMMIT Transaktionslogg för T1 <TIME1> Transaction begins <TIME2> Write Z, Old=99, New=6 <TIME3> Write W, Old=7, New=8 <TIME4> Transaction commits (a,b är lokala variabler) EXEMPELTABELL PK Attr X 2 Y 4 Z 99 6 W 7 8 Vid COMMIT sker följande: 1. Transaktionsloggen skrivs till disk 2. Användaren får ett OK tillbaks 3. Eventuell uppstädning sker i databasen Vid ett ROLLBACK används transaktionsloggen för att återställa värdena. 27

Samtidiga/parallella transaktioner Serialiserbarhet Låsning Två-faslåsning (Pessimistisk samtidighethantering) Optimistisk samtidighetshantering 28

Transaktionskonflikter Ett transaktionschema består av en eller flera transaktioner Om två eller flera transaktioner utförs seriellt i ett transaktionsschema så utförs de korrekt. Om transaktionerna utförs samtidigt kan konflikter mellan operationer uppstå. (Dirty reads, lost updates osv ) En konflikt mellan två operationer kan uppstå om: Operationerna tillhör olika transaktioner Operationerna använder samma data/objekt Om minst en av operationerna skriver till gemensamma datat/objektet 29

Serialiserbarhet Givet en mängd transaktioner; Om man (i efterhand) kan konstruera en ordning av samtliga ingående transaktioners händelser så att slutresultatet blir detsamma som om varje transaktion exekverades seriellt så är transaktionsschemat serialiserbart. Trans 3 Trans 5 T4 Trans 3 Trans 2 Trans 1 30

Exempel på serialisering T1 T2 Värde på X Värde på Y X 1 Y 1 x=x-n WRITE X X 2 Y 1 READ Y y=y+n WRITE Y X 2 Y 2 x=x+m WRITE X X 3 Y 2 DB-state Read-set Write-Set DB-state Read-set Write-Set DB-state X 1 Y 1 X 1 Y 1 T1 X 2 Y 2 X 2 Y 2 X 2 T2 X 3 X 3 Y 2 Schemat är serialiserbart. T1 hände före T2 31

Exempel på serialisering T1 T2 Värde på X Värde på Y X 1 Y 1 x=x+m WRITE X X 2 Y 1 x=x-n WRITE X X 3 Y 1 READ Y y=y+n WRITE Y X 3 Y 2 DB-state Read-set Write-Set DB-state Read-set Write-Set DB-state X 1 Y 1 X 1 T2 X 2 X 2 Y 1 X 2 Y 1 T1 X 3 Y 2 X 3 Y 2 Schemat är serialiserbart. T2 hände före T1 32

Exempel på serialisering T1 T2 Värde på X Värde på Y X 1 Y 1 x=x-n WRITE X X 2 Y 1 x=x+m WRITE X X 3 Y 1 READ Y y=y+n WRITE Y X 3 Y 2 DB-state Read-set Write-Set DB-state Read-set Write-Set DB-state X 1 Y 1 X 1 Y 1 T1 X 2 Y 2 X 2 Y 2 X 2 T2 X 3 X 3 Y 2 Schemat är serialiserbart. T1 hände före T2 Detta TROTS att T2 avslutade före T1 33

Exempel på serialisering T1 T2 Värde på X Värde på Y X 1 Y 1 x=x-n x=x+m WRITE X X 2 Y 1 READ Y WRITE X X 3 Y 1 y=y+n WRITE Y X 3 Y 2 DB-state Read-set Write-Set DB-state Read-set Write-Set X 1 Y 1 X 1 Y 1 T1 X 2 Y 2 X 2 Y 2 X 1 T2 X 3 OK, detta gick ju inte T1 kan inte ha hänt före T2 Vi får prova tvärtom 34

Exempel på serialisering T1 T2 Värde på X Värde på Y X 1 Y 1 x=x-n x=x+m WRITE X X 2 Y 1 READ Y WRITE X X 3 Y 1 y=y+n WRITE Y X 3 Y 2 DB-state Read-set Write-Set DB-state Read-set Write-Set X 1 Y 1 X 1 T2 X 3 X 3 Y 1 X 1 Y 1 T1 X 2 Y 2 Detta gick inte heller T2 kan inte ha hänt före T1 Transaktionsschemat är INTE serialiserbart 35

Samtidighetshantering Concurrency-control Så, vi har sett att T1 och T2 potentiellt kan hamna i konflikt med varandra Hur löser vi detta? Svaret är Concurrency-Control En av de mest komplexa mekanismerna i en DBMS!!!!! Består av en kontrollmekanism som tillåter eller förbjuder vissa sekvenser av operationer. Kan blockera eller begära rollback/restart på vilken transaktion som helst 2 vanligaste varianterna Låsningsprotokoll (Pessimistic Concurrency-Control) Optimistic-Concurrency Control 36

Låsningsprotokoll Ett lås (lock) är en variabel som förknippas med ett dataobjekt i databasen. I regel kan det finnas ett lås för varje dataobjekt i db n. Låset används för att synkronisera operationer mot ett dataobjekt. En transaktion/operation låser ett lås för att markera en slags behörighet (ensamrätt) till dataobjektet. Ett olåst lås är ledigt för låsning av en annan transaktion. Olika typer av lås: Binära lås: har två tillstånd, låst och olåst Delade/Exklusiva lås: har flera låstillstånd 37

Binära lås Ett binärt lås har två tillstånd: låst (1) eller olåst (0). Ett låst lås för dataobjektet X innebär att inga (andra) operationer får använda X. Ett försök att låsa X leder till att transaktioner försätts i vänteläge. T1 LOCK X x=x-m WRITE X UNLOCK X X T2 LOCK X x=x-m WRITE X UNLOCK X 38

Delade/Exklusiva lås Binära lås är för restriktiva! Varför? Det skadar inte om flera transaktioner får läsa samma dataobjekt Därför finns s.k. shared/exclusive lås (kallas även för read/write-lås) som tillåter: Multipla läslåsningar (Shared lock) En skrivlåsning (Exclusive lock) Alltså: Shared Lock Exclusive Lock Shared Lock Compatible Not Compatible Exclusive Lock Not Compatible Not Compatible 45

Exempel med låsning i transaktioner Betänk följande 2 transaktioner Båda tar lås innan de accessar databasen och släpper dem när de är klara med ett visst data T1 READ_LOCK Y READ Y UNLOCK Y WRITE_LOCK X x=x+y WRITE X UNLOCK X T2 READ_LOCK X UNLOCK X WRITE_LOCK Y READ Y y=x+y WRITE Y UNLOCK Y 46

Exekveringsscenario DB-state X 1 Y 1 DB-state X 1 Y 1 T1 T2 Värde på X Värde på Y READ_LOCK Y X 1 Y 1 READ Y UNLOCK Y READ_LOCK X UNLOCK X WRITE_LOCK Y READ Y y=x+y WRITE Y X 1 Y 2 UNLOCK Y WRITE_LOCK X x=x+y WRITE X X 2 Y 2 UNLOCK X Read-set X 1 Y 1 Read-set X 1 Y 1 Write-Set T1 X 2 Write-Set T2 Y 2 DB-state X 2 Y 1 DB-state X 1 Y 2 Read-set X 1 Y 1 Read-set X 1 Y 1 Denna borde inte låsts upp här! Vi behöver bättre regler för låsningar Write-Set T2 Y 2 Write-Set T1 X 2 Hmm Något är 47 fel!!

Två-faslåsning (ursprungliga) Den vanligaste låsningsalgoritmen. Serialiserbarhet med låsningsprotokoll garanteras om alla låsningar (både läsning och skrivning) kommer före den första upplåsningen i en transaktion. Denna regel kallas two-phase locking protocol Två faser åsyftar på att transaktionen kan delas in i: En växande fas (expanding/growing phase) där den tar en eller flera lås, men utan att låsa upp ngt En krympande fas (shrinking phase) där den låser upp låsta lås, men utan att den försöker låsa nya Det finns flera utökningar av två-faslåsningar (läs boken, ej del av kursen) Rigorous, conservative, strict 2PL Den mest använda är Strict 2PL som behåller writelocks till efter commit 48

Våra transaktioner med två-faslåsning Upplåsning sker nu EFTER sista låsningen Undviker det felaktiga exekveringsscenariot T1 READ_LOCK Y READ Y WRITE_LOCK X UNLOCK Y X=X+Y WRITE X UNLOCK X T2 READ_LOCK X WRITE_LOCK Y UNLOCK X READ Y Y=X+Y WRITE Y UNLOCK Y Växande fas Krympande fas 49

Exekveringsscenario T1 T2 Värde på X Värde på Y READ_LOCK Y X 1 Y 1 READ Y WRITE_LOCK X UNLOCK Y READ_LOCK X WRITE_LOCK Y UNLOCK X READ Y y=x+y WRITE Y UNLOCK Y T2 kan inte starta här eftersom X är låst här, T2 måste vänta tills T1 låst upp X. Schemat är nu serialiserbart!! x=x+y WRITE X X 2 Y 2 UNLOCK X Dock finns det nu en ny fiende som vi måste hantera Någon som ser??? 50

Exekveringsscenario 2 Vad händer om T2 avbryter T1 precis innan T1 låser X?? T1 READ_LOCK Y READ Y WRITE_LOCK X T2 READ_LOCK X WRITE_LOCK Y Y LÅST AV T1, T2 BLOCKED X LÅST AV T2, T1 BLOCKED Ingen av transaktionerna kan nu fortsätta. 51

Problem med 2PL:Deadlock Med 2PL finns alltid risken att två eller flera transaktioner blockerar varandra Detta MÅSTE hanteras Någon form av detektionsalgoritm krävs Deadlock-grafer vanligast à Operativsystemskursen!!! När deadlock upptäcks måste det hanteras Transaktionshanteraren kommer att göra ROLLBACK på transaktioner tills deadlocket är upphävt 52

Optimistisk Samtidighetshantering Används av en del kommersiella databaser Använder inga lås (i princip) Transaktioner kan: Göra vad dom vill, dvs, läsa och skriva vilka värden som helst (om rättigheterna tillåter) Alla skrivningar lagras dock i lokala (för transaktionen) datastrukturer Vid COMMIT så: Låser man temporärt databasen/de berörda objekten Validerar att inga konflikter uppstått (har någon läst/uppdaterat någon av de värden jag vill uppdatera eller vice versa?) Skriver alla ändringar till databasen Låser upp databasen Har man en konflikt slängs alla lokala datastrukturer bort och transaktionen får börja om. 53

Optimistisk Samtidighetshantering Varför är detta bra då? Faktum är att: konflikter mellan transaktioner sällan uppstår i realiteten kostnaden för att ta och släppa tusentals eller miljontals lås ofta är betydligt högre än att behöva köra om en transaktion då och då. Rollback blir också väldigt enkelt. Deadlockhantering behövs inte. Nackdelar: För tidskritiska system (realtidssystem) är detta inte bra I teorin kan en transaktion startas om oändligt många gånger 54

Summering av föreläsning Föreläsningens mål: Att ge en överblick transaktioner och samtidighet i databaser fungerar Transaktioner BEGIN TRANSACTION, COMMIT, ROLLBACK Transaktionshantering ACID-egenskaperna Rollbackhantering Samtidighet (concurrency) Pessimistic concurrency-control Optimistisk concurrency-control 55