UNIVERSITETET I OSLO Transaksjonshåndtering Del 3 Ragnar Normann INF3100 24.3.2009 Ragnar Normann 1
Serialiserbarhet Vi har tidligere definert serialiserbarhet på denne måten: En eksekveringsplan kalles serialiserbar hvis den er ekvivalent med en seriell eksekveringsplan Problemet med denne definisjonen er at den ikke sier hva som menes med «ekvivalent» Hittil har vi sett på eksekveringsplaner som har vært konfliktekvivalente med serielle eksekveringsplaner, dvs. at rekkefølgen på lese-skrive- og skrive-skrivekonflikter er den samme som i en seriell plan, noe som igjen er det samme som at konfliktgrafen er asyklisk (uten noen sykel) Vi skal nå kort se på et par andre serialiserbarhetskriterier INF3100 24.3.2009 Ragnar Normann 2
Final-State serialiserbarhet (FS) En eksekveringsplan S kalles FS-serialiserbar hvis det finnes en seriell plan for transaksjonene i S som gir samme sluttilstand i databasen som S Dette betyr at med samme (vilkårlige) starttilstand skal det å utføre S gi samme sluttilstand som det å utføre den serielle planen Merk at det bare er sluttilstanden i databasen som må være lik Det er ingen krav om at enkelttransaksjonene skal lese eller skrive de samme verdiene i de to planene Dette gjør at lesetransaksjoner aldri vil ha noen innvirkning på FS-serialiserbarhet INF3100 24.3.2009 Ragnar Normann 3
Les-fra relasjonen La T og U være to transaksjoner Da sier vi at vi har en lese-fra avhengighet mellom T og U, notert (T,x,U), hvis U leser en verdi av x som T har skrevet La så S være en eksekveringsplan for transaksjonene {T 1,, T m } Definer to fiktive transaksjoner T 0 og T ved at T 0 skriver alle dataelementene i databasen før S startes T leser alle dataelementene etter at S er kjørt (dvs. at T leser «final state») Da defineres les-fra (Read-From) relasjonen til S som RF(S) = {(T k,x,t l ) T k S U {T 0 } og T l S U {T } } INF3100 24.3.2009 Ragnar Normann 4
View-serialiserbarhet La S 1 og S 2 være to eksekveringsplaner for de samme transaksjonene Vi sier at S 1 og S 2 er view-ekvivalente hvis RF(S 1 ) = RF(S 2 ) En eksekveringsplan er view-serialiserbar hvis den er view-ekvivalent med en seriell eksekveringsplan INF3100 24.3.2009 Ragnar Normann 5
Klassene FSR, VSR og CSR Vi har nå sett på tre måter å definere serialiserbarhet på Hver av disse gir opphav til en klasse av planer: FSR er klassen av alle Final-State serialiserbare planer VSR er klassen av alle view-serialiserbare planer CSR er klassen av alle konfliktserialiserbare planer INF3100 24.3.2009 Ragnar Normann 6
VSR vs FSR Alle view-serialiserbare planer er FS-serialiserbare, men ikke omvendt (VSR er en ekte delmengde av FSR) Begrunnelse: Anta at P er en view-serialiserbar plan Da finnes en seriell plan med RF(S) = RF(P) Spesielt må RF(S) og RF(P) inneholde de samme tuplene på formen (T k,x,t ) Altså gir P og S samme sluttilstand Siden FS-serialiserbarhet ikke tar hensyn til lesetransaksjoner, er det lett å lage en plan i FSR som ikke ligger i VSR: P = w 1 (x)r 2 (x)r 2 (y)w 1 (y)c 1 c 2 INF3100 24.3.2009 Ragnar Normann 7
VSR vs CSR Forskjellen mellom view- og konfliktserialiserbarhet viser seg når T skriver en x som ingen leser (fordi en annen transaksjon også skriver x før noen har lest x) En slik w T (x) kan gi en sykel i konfliktgrafen uten å stride mot view-seriabilitet Ved å legge på et krav om begrenset skriving: En transaksjon får ikke lov til å skrive et dataelement uten først å ha lest det blir alle view-serialiserbare eksekveringsplaner konfliktserialiserbare Konklusjon: Alle konfliktserialiserbare eksekveringsplaner er view-serialiserbare, men ikke omvendt INF3100 24.3.2009 Ragnar Normann 8
Et pre for konfliktserialiserbarhet Det er mye dyrere å håndheve FS- og view-serialiserbarhet enn konfliktserialiserbarhet Å håndheve view-serialiserbarhet (og også FS-serialiserbarhet) er en NP-komplett oppgave og derfor «umulig» for store transaksjonsmengder Å vedlikeholde konfliktgrafen kan gjøres i polynomisk tid (dette er ikke pensum, men informasjon til de interesserte) INF3100 24.3.2009 Ragnar Normann 9
Multiversjonsdatabaser Noen DBMSer kan lagre flere versjoner av hvert dataelement Dette forutsetter at transaksjonene får et tidsstempel (transaksjonsnummer) når de starter Når en transaksjon t k (der k er transaksjonsnummeret) skriver en ny verdi i et objekt x, blir det dannet et nytt objekt x k (den gamle verdien av x blir ikke overskrevet) Siden det kan bli mange versjoner av hvert objekt, må det finnes en prosess som sletter gamle versjoner som ingen lenger kan få bruk for (søppeltømming) INF3100 24.3.2009 Ragnar Normann 10
Snapshot Isolation (SI) SI er en protokoll som lager multiversjonsplaner SI er interessant fordi den brukes i flere mye brukte DBMSer, bl.a. Oracle PostgreSQL Microsoft SQL Server Merk at det disse DBMSene kaller Serializable (som er deres standardisolasjonsnivå), i virkeligheten er SI Vi skal senere vise at SI ikke er det samme som det som i SQL-1992-standarden kalles serialiserbar INF3100 24.3.2009 Ragnar Normann 11
SI-protokollen SI-protokollen består i å håndheve følgende to regler: 1. Når en transaksjon T leser et objekt X, så leser T den nyeste versjonen av X som er skrevet av en transaksjon som committet før T startet 2. Skrivemengden til to samtidige transaksjoner må være disjunkte Regel 2 betyr at hvis T 1 og T 2 er to transaksjoner hvor T 1 starter før T 2, og T 1 gjør commit etter at T 2 er startet, så får ikke T 1 og T 2 skrive samme objekt Det finnes flere metoder for å håndheve regel 2 én er å sammenligne skrivemengdene ved commit INF3100 24.3.2009 Ragnar Normann 12
Første oppdaterer vinner Oracle håndhever regel 2 slik at første oppdaterer vinner: Anta at to transaksjoner T 1 og T 2 er samtidige, at T 1 skriver X, og at T 2 også vil skrive X Da kan ikke T 2 skrive X før T 1 slipper sin skrivelås på X Det er da tre muligheter: Hvis T 2 står i kø for å skrive X, og T 1 gjør commit, blir T 2 øyeblikkelig abortert Hvis T 1 gjør commit før T 2 prøver å skrive X, blir T 2 abortert i det den prøver å skrive X Hvis T 1 slipper låsen fordi den aborterer, får T 2 skrive X INF3100 24.3.2009 Ragnar Normann 13
Søppeltømming ved bruk av SI Regelen for når søppeltømmeren kan fjerne «gamle» versjoner av dataobjekter, er slik: En versjon X i av et dataobjekt X kan fjernes hvis, og bare hvis, det finnes en nyere versjon X k av X slik at alle aktive transaksjoner startet etter at X k ble skrevet En konsekvens av denne regelen er at den sist skrevne versjonen av et dataobjekt aldri kan bli slettet av søppeltømmeren INF3100 24.3.2009 Ragnar Normann 14
SI og serialiserbarhet Betrakt planen P = r 1 (x)r 2 (y)w 1 (y)w 2 (x)c 1 c 2 P er et eksempel på skriveskjevhet (Write Skew) både T 1 og T 2 skriver objekter de selv ikke har lest, men som den andre transaksjonen har lest P er opplagt ikke konfliktserialiserbar (T 1 T 2 T 1 ) Derimot tilfredsstiller P SI både T 1 og T 2 leser bare data skrevet av T 0, og skrivmengdene deres er disjunkte INF3100 24.3.2009 Ragnar Normann 15
Monotonitet La S være en plan, og la T være en delmengde av transaksjonene i S Da definerer vi projeksjonen av S på T som den planen vi får hvis vi fra S fjerner alle operasjoner utført av transaksjoner som ikke ligger i T En klasse med planer kalles monoton hvis alle projeksjoner av planer i klassen selv ligger i klassen INF3100 24.3.2009 Ragnar Normann 16
Monotonitet og schedulere La E være klassen av planer som en gitt scheduler S kan lage (E er klassen av lovlige planer) Hvis E ikke er monoton, kan følgende skje: S lager en plan P for en mengde transaksjoner T En av transaksjonene i T aborterer Projeksjonen av P på resten av transaksjonene i T er ikke i E (de danner en ulovlig plan) Et annet problem er at en ulovlig plan kan bli lovlig hvis det kommer en ny transaksjon som skal flettes inn i planen INF3100 24.3.2009 Ragnar Normann 17
Monotonitet i multiversjonsdatabaser (Dette og neste lysark er hentet fra Lene Østbys masteroppgave) Det er ikke opplagt hvordan monotonitet skal defineres i multiversjonsdatabaser (Det egentlige problemet er hvordan projeksjoner skal defineres) Betrakt følgende multiversjonsplan for T 1, T 2 og T 3 : S = r 1 (x 0 )r 1 (y 0 )r 2 (y 0 )w 2 (y 2 )c 2 r 3 (x 0 )r 3 (y 2 )c 3 w 1 (x 1 )c 1 En rett frem projeksjon av S på T ={T 1,T 3 } blir slik: Π T (S) = r 1 (x 0 )r 1 (y 0 )r 3 (x 0 )r 3 (y 2 )c 3 w 1 (x 1 )c 1 Her leser T 3 en versjon av y skrevet av T 2 som ikke finnes i planen (så y 2 eksisterer ikke) Vi lar derfor T 3 lese siste committede verdi av y, som gir: Π T (S) = r 1 (x 0 )r 1 (y 0 )r 3 (x 0 )r 3 (y 0 )c 3 w 1 (x 1 )c 1 INF3100 24.3.2009 Ragnar Normann 18
Klassen av SI-planer er monoton Bevis (Lene Østby 2008): La S være en plan generert i henhold til SI-protokollen, dvs. at enhver transaksjon T i S bare leser verdier skrevet av transaksjoner som har committet før T startet, og at S ikke inneholder noen skrive-skrive konflikter La P være projeksjonen av S på en delmengde av transaksjonene i S Definisjonen av projeksjon på forrige lysark gjør at ingen transaksjon T i P kan lese en verdi skrevet av en transaksjon som ikke er committet før T startet Dessuten kan ikke en projeksjon innføre nye skrive-skrive konflikter Dermed oppfyller P begge kravene til SI q.e.d. INF3100 24.3.2009 Ragnar Normann 19
CSR er monoton Dette er en konsekvens av serialiserbarhetsteoremet som sier at en plan er konfliktserialiserbar hvis, og bare hvis, konfliktgrafen er asyklisk Begrunnelse: Anta at P er en plan i CSR, dvs. at P har en asyklisk konfliktgraf Konfliktgrafen til enhver projeksjon av P vil være en subgraf i Ps konfliktgraf, og slike subgrafer er også asykliske Altså ligger alle projeksjoner av P i CSR INF3100 24.3.2009 Ragnar Normann 20
FSR og VSR er ikke monotone Beviset for dette resultatet består i å finne en plan i VSR som har en projeksjon som ikke ligger i FSR Beviset for den siste påstanden ligger utenfor rammen for dette kurset INF3100 24.3.2009 Ragnar Normann 21
Vranglåser og «timeout» I et låsbasert system sier vi at vi har en vranglås når to eller flere transaksjoner venter på hverandre Når en vranglås er oppstått, er det generelt umulig å unngå å rulle tilbake (minst) en transaksjon En «timeout» er en øvre grense for hvor lenge en transaksjon får lov til å være i systemet En transaksjon som overskrider grensen, må frigi alle sine låser og bli rullet tilbake Lengden av «timeout» og velegnethet av denne metoden er avhengig av hva slags transaksjoner vi har INF3100 24.3.2009 Ragnar Normann 22
Vent-på-grafer For å unngå (evt oppdage) vranglåser, kan planleggeren vedlikeholde en Vent-på-graf: Noder: Transaksjoner som har eller venter på en lås Kanter T U: Det finnes et dataelement A slik at U har låst A T venter på å få låse A T får ikke sin ønskede lås på A før U frigir sin Vi har vranglås hvis, og bare hvis, det er en sykel i Vent-på-grafen En enkel strategi for å unngå vranglås er å rulle tilbake alle transaksjoner som kommer med et låseønske som vil generere en sykel i Vent-på-grafen INF3100 24.3.2009 Ragnar Normann 23
Vranglåshåndtering ved ordning Dersom alle låsbare dataelementer er ordnet, har vi en enkel strategi for å unngå vranglås: la alle transaksjoner sette sine låser i ordningsrekkefølge Bevis for at vi unngår vranglås med denne strategien: Anta at vi har en sykel T 1 T 2 T 3 T n T 1 i Ventpå-grafen, at hver T k har låst A k, og at hver T k venter på å låse A k+1, unntatt T n som venter på å låse A 1 Da er A 1 <A 2 < <A n <A 1, noe som er umulig Da vi sjelden har en naturlig ordning av dataelementene, er nytteverdien av denne strategien begrenset INF3100 24.3.2009 Ragnar Normann 24
Vranglåstidsstempler Vranglåstidsstempler er et alternativ til å vedlikeholde en Vent-på-graf Alle transaksjoner tildeles et entydig vranglåstidsstempel idet de starter, og dette tidsstempelet har følgende egenskaper ved tildelingen er det det største som er tildelt til nå det er ikke det samme tidsstempelet som (eventuelt) blir brukt til samtidighetskontroll det forandres aldri; transaksjonen beholder sitt vranglåstidsstempel selv om den rulles tilbake En transaksjon T sies å være eldre enn en transaksjon U hvis T har et mindre vranglåstidsstempel enn U INF3100 24.3.2009 Ragnar Normann 25
Vent Dø strategien La T og U være transaksjoner og anta at T må vente på en lås holdt av U Vent Dø (Wait Die) strategien er som følger: Hvis T er eldre enn U, får T vente til U har gitt slipp på låsen(e) sin(e) Hvis U er eldre enn T, så dør T, dvs at T rulles tilbake Siden T får beholde sitt vranglåstidsstempel selv om den rulles tilbake, vil den før eller siden bli eldst og dermed være sikret mot flere tilbakerullinger Vi sier at Vent Dø strategien sikrer mot utsultning (starvation) INF3100 24.3.2009 Ragnar Normann 26
Skad Vent strategien La T og U være transaksjoner og anta at T må vente på en lås holdt av U Skad Vent (Wound Wait) strategien er som følger: Hvis T er eldre enn U, blir U skadet av T Som oftest blir U rullet tilbake og må overgi sin(e) lås(er) til T Unntaket er hvis U allerede er i krympefasen Da overlever U og får fullføre Hvis U er eldre enn T, så venter T til U har gitt slipp på låsen(e) sin(e) Om U rulles tilbake, vil den før eller siden bli eldst og dermed være sikret mot flere tilbakerullinger, så også Skad Vent strategien sikrer mot utsulting INF3100 24.3.2009 Ragnar Normann 27
Vranglåstidsstempler gjør jobben sin TEOREM Både Vent Dø og Skad Vent forhindrer vranglås Bevis: Det er nok å vise at begge strategiene sikrer at det ikke kan bli sykler i Vent-på-grafen Så, ad absurdum, anta at Vent-på-grafen har en sykel, og la T være den eldste transaksjonen som inngår i sykelen Hvis vi bruker Vent Dø strategien, kan transaksjoner bare vente på yngre transaksjoner, så ingen i sykelen kan vente på T som dermed ikke kan være med i sykelen Hvis vi bruker Skad Vent, kan transaksjoner bare vente på eldre transaksjoner, så T kan ikke vente på noen andre i sykelen og kan følgelig ikke selv være med i den QED INF3100 24.3.2009 Ragnar Normann 28
Lange transaksjoner og sagaer En transaksjon kalles lang hvis den varer så lenge at den ikke kan få lov til å holde låser i hele sin levetid Vanlig samtidighetskontroll kan ikke brukes for lange transaksjoner de håndteres med sagaer: En saga representerer alle mulige forløp av en lang transaksjon og består av en mengde (korte) transaksjoner kalt aksjoner en graf hvor nodene er aksjonene og to terminalnoder abort og ferdig, og hvor en kant A i A k betyr at A k bare kan utføres dersom A i er utført, og hvor alle noder unntatt abort og ferdig har utgående kanter en markert startnode (første aksjon som utføres) Merk at en saga kan inneholde sykler INF3100 24.3.2009 Ragnar Normann 29
Samtidighetskontroll for sagaer En lang transaksjon L er en sti gjennom sagaen fra startnoden A 0 til en av terminalnodene (fortrinnsvis ferdig) Aksjonene er, og behandles som, vanlige transaksjoner L aborterer ikke selv om en aksjon blir rullet tilbake I en saga har hver aksjon A en kompenserende aksjon A -1 som opphever virkningen av A Presist: Hvis D er en lovlig databasetilstand og S er en eksekveringsplan, skal det å utføre S og ASA -1 på D gi samme resultattilstand Hvis L ender i abort, fjernes virkningen av L ved å kjøre de kompenserende aksjonene i omvendt rekkefølge: A 0 A 1 A n abort kompenseres med A n -1 A 1-1 A 0-1 ferdig INF3100 24.3.2009 Ragnar Normann 30