Transaktionshantering (kap 17+18) DAV B04 - Databasteknik Transaktionshantering (kap 17+18)

Transaktionshanteringssystem System med hundratals samtidiga användare som utför databastransaktioner Ex. banksystem, biljettbokning, näthandel Kräver hög tillgänglighet, snabba svarstider och hög pålitlighet För detta behövs både concurrency control och stöd för återhämtning av misslyckade transaktioner i databassystemet

Transaktioner En transaktion är en mängd operationer utförda i sekvens, som tillsammans bildar en logisk enhet Måste utföras i sin helhet eller inte alls Ex. BEGIN TRANSACTION read(konto1); konto1= konto1 – 1000; write(konto1); read(konto2); konto2= konto2 + 1000; write(konto2); COMMIT ELLER ROLLBACK END TRANSACTION

COMMIT och ROLLBACK COMMIT betyder att transaktionen i sin helhet utförts korrekt. Uppdateringar görs nu permanenta. ROLLBACK betyder att något har gått fel och transaktionen ”spolas tillbaka” till början. Eventuella uppdateringar måste göras ogjorda.

Önskvärda egenskaper hos transaktioner ACID-egenskaper: Atomicity en transaktion skall utföras helt eller inte alls Consistency preservation transaktionen gör att databaser växlar mellan konsistenta tillstånd Isolation transaktionen skall inte påverkas av andra transaktioner Durability or permanency ändringar är permanenta

Concurrency Innebär samtidig/jämlöpande körning av flera transaktioner kan ställa till problem om de jobbar mot samma datamängd Tre huvudsakliga problem finns: Problemet med förlorade uppdateringar Problemet med temporära uppdateringar Problemet med felaktiga summeringar

Förlorade uppdateringar / Lost Update Problem Transaktion A TID Transaktion B X = 80 Read(X) X = X - 5 X = X + 4 Write(X) X borde bli 79 men blir här 84. Transaktion B uppdaterar X utan att veta om transaktion A:s uppdatering. Transaktion A:s uppdatering går här förlorad.

Tillfälliga uppdateringar / Temporary Update Problem Transaktion A TID Transaktion B Read(X) X = X – 1 Write(X) X = X – 2 ROLLBACK Transaktion B ser här en uppdatering av X som senare görs ogjord. Därmed har Transaktion B använt ett felaktigt värde (dirty read).

Felaktiga summeringar / Incorrect summary problem Transaktion A tid Transaktion B Sum = 0 Read(konto1) Sum += konto1 Read(konto2) Konto2 -= 1000 Write(konto2) Sum += konto2 Read(konto3) Sum += konto3 Konto3 += 1000 Write(konto3) Tr. A summerar kontona 1,2,3. Samtidigt flyttar Tr. B över 1000kr från konto2 till konto 3. Tr A summerar här ett förändrat konto 2 men ett oförändrat konto3, dvs Tr A gör en felaktig summering

Transaktionsscheman Med schema (schedule) avses en beskrivning av ordningsföljden mellan de operationer (read/write) som görs för att antal transaktioner som använder gemensamma data Ex. Sa = r1(X),w1(X),r2(X),w2(X),r1(Y) Sb = r1(X),r2(X),w1(X),r1(Y),w2(X), w1(Y)

Konflikter mellan transaktioner Två operationer i ett schema sägs vara i konflikt om de uppfyller tre villkor: De tillhör olika transaktioner De accessar samma objekt X Åtminstone en av operationerna är en write(X) Sa = r1(X),w1(X),r2(X),w2(X),r1(Y) Sb = r1(X),r2(X),w1(X),r1(Y),w2(X), w1(Y) Vilka konflikter finns i schemana ovan?

Seriella scheman Seriellt schema (serial) Automatiskt seriellt en transaktion i taget aktiv och först när den avslutats (commit/abort) kan nästa börja Ett seriellt schema är alltid giltigt Automatiskt seriellt om transaktionerna är oberoende av varandra Seriella scheman anses ofta vara för ineffektiva i praktiken

Serialiserbarhet och seriellt ekvivalenta scheman Icke-seriellt (nonserial) schema Transaktionerna exekverar parallellt (interleaved) Ett schema är serialiserbart om det är ekvivalent med något seriellt schema för samma mängd transaktioner Konflikt-ekvivalent schema Ett schema är konflikt-ekvivalent med ett annat om operationer som är i konflikt exekverar i samma ordning i de båda schemana Om A är ett seriellt schema och schema B är (konflikt)ekvivalent med A, så är B ett (konflikt)serialiserbart schema.

Hur kan man avgöra om ett schema är serialiserbart eller inte? För varje transaktion Ti som ingår i schemat S, skapa en nod som heter Ti i en precedensgraf För varje fall i S där Tj utför en read(X) efter att Ti utfört en write(X), skapa en kant (Ti  Tj ) i precedensgrafen För varje fall i S, där Tj utför en write(X) efter att Ti utfört en read(X), skapa en kant (Ti  Tj ) i precedensgrafen För varje fall i S, där Tj utför en write(X) efter att Ti utfört en write(X), skapa en kant (Ti  Tj) i precedensgrafen Schemat S är serialiserbart omm precedensgrafen saknar cykler

Tekniker för concurrency control Vanligast är olika protokoll som använder låsning (locking) av dataobjekt Andra tekniker Tidsstämpling (timestamps) Multiversion concurrency control Optimististic concurrency control

Delade/exklusiva lås Shared/Exclusive (Read/Write) Locks En transaktion som vill göra en operation på ett objekt X måste först skaffa ett lås på det objektet Om låset inte beviljas ställs transaktionen i väntekö 3 låsoperationer: read-lock(X), write-locked(X) och unlock(X) DBHS har en tabell där för varje lås anges: < objekt, typ av lås, antal läsare, låsande transaktioner >

Regler för delade/exklusiva lås En transaktion T måste utföra operationen read_lock(X) eller write_lock(X) innan någon read(X) utförs i T En transaktion T måste utföra operationen write_lock(X) innan någon write(X) utförs i T En transaktion T måste utföra operationen unlock(X) efter att alla read(X) och write(X) är utförda Låsning av transaktioner garanterar inte serialiserbarhet automatiskt

Two-phase locking protocol (2PL) Teorem: om alla transaktioner följer protokollet för 2PL så garnteras serialiserbarhet 2PL: Alla låsningar (read_lock och write_lock) föregår första unlock i transaktionen Lås skaffas i den växande fasen och släpps i den krympande fasen Dock är protokollet inte helt problemfritt…

Förlorade uppdateringar med 2PL Transaktion A TID Transaktion B X = 80 Read_lock(X); Read(X) X = X – 5 X = X + 4 Write_lock(X); //vänteläge Write(X)

Deadlock Prevention Protocols Varje transaktion förses med en tidstämpel TS(T), där TS(T1) < TS(T2) om T1 startar före T2. man säger även att T1 är äldre än T2 Antag att T1 försöker låsa X som redan är låst av T2 Wait-die: Om T1 är äldre än T2, så får T1 vänta annars avbryts T1 och återstartas senare med samma tidstämpel Wound-wait: Om T1 är äldre än T2, så dödas T2 och återstartas senare med samma tidstämpel Annars får T1 vänta

Utan tidstämpel No waiting Cautious waiting Om transactionen inte kan få ett lås avbryts den omedelbart och återstartas efter viss fördröjning utan att kontrollera om deadlock kommer att uppstå Cautious waiting Antag att T1 försöker låsa X men att X redan är låst av T2 Om T1 inte är blockerad (inte väntar på någon annan låst variabel) så blockeras T1 och får vänta annars avbryts T2

Deadlock Detection and Timeouts Upptäck deadlock genom att konstruera en wait-for graph (en graf som visar vem som väntar på vem) Deadlock omm det finns cykler i grafen Victim selection Välj ut en transaktion som offer och döda den Timeouts Om en transaktion väntat för länge, döda den

Starvation En transaktion får vänta orimligt länge på grund av låg prioritet eller annat Lösningar FCFS : first-come-first-serve i väntekö Prioritet : ge högre prioritet åt den som väntat länge