DAV B04 - Databasteknik

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 • 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 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 • 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) • 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 Tisom ingår i schemat S, skapa en nod som heter Tii 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 uppdateringarmed 2PL

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

DAV B04 - Databasteknik