Øving 5: Transaksjonshåndtering, logging og normalisering Lars Kirkholt Melhus Oppgave 1 a) ACID Atomic En transaksjon er en minste enhet. Alle ledd i transaksjonen må gå feilfritt for at transaksjonen skal gjennomføres. Hvis ikke forblir databasen uendret, slik den var før transaksjonen. Consistency En transaksjon holder databasens tilstand konsistent, ved at nøkler, referanser, verdier og constraints er gyldige. Under operasjonene i transaksjonen kan godt tilstanden være inkonsistent, men tilstanden før og etter er garantert konsistent. Isolation Transaksjoner er uvitende om andre transaksjoner. Transaksjoner som utføres i parallell påvirker ikke hverandre. Durability Når en transaksjon er gjennomført skal databasens nye tilstand holde (til en annen transaksjon begynner). b) Tofaselåsing Om databasesystemet kjører tofaselåsing vil det si at når en transaksjon utføres deles tiden i to: Først et intervall hvor låser tildeles og ingen frigjøres, deretter en periode hvor låser kun frigjøres. Denne strategien garanterer serialiserbarhet, som igjen garanterer korrekt utførelse.
Oppgave 2 Har historiene S 1 til S 6. For å avgjøre om de er serialiserbare kan man skjekke at presedensgrafen ikke inneholder sykler. En transaksjon T i må skje før transaksjon T j dersom RAW, WAR eller WAW. S 1 : w 2 (X); w 1 (X); r 3 (X); r 1 (X); w 2 (Y); c 1 ; r 3 (Y); r 3 (Z), c 3 ; r 2 (X); c 2 ; S 2 : r 3 (Z); r 3 (Y), w 2 (Y); r 2 (Z); w 2 (X); w 1 (X); c 2 ; r 1 (X); c 1 ; r 3 (X); c 3 ; S 3 : r 3 (Z); w 2 (X); w 2 (Y); r 1 (X); r 3 (X); r 2 (Z), c 2 ; r 3 (Y), c 3 ; w 1 (X); c 1 ; S 4 : r 2 (Z); w 2 (X); w 2 (Y), c 2 ; w 1 (X); r 1 (X); c 1 ; r 3 (X); r 3 (Z); r 3 (Y); c 3 ; S 5 : r 1 (X); r 2 (X); w 2 (X); w 2 (Y); c 2 ; w 1 (X); r 3 (Z); w 1 (Y); c 1 ; r 3 (Y); r 3 (X); c 3 ; S 6 : r 2 (X); w 2 (X), r 1 (X); r 2 (Y); w 1 (Y); c 1 ; r 2 (Z); w 2 (Z); c 2 ; a) Serialiserbarhet Som grafene viser er S1, S3, S4 og S6 serialiserbare. b) Recovery-egenskaper (strict, cascadeless, recoverable, ingen av delene) S1 og S6 er ingen av delene. S2 er cascadeless. S3 er recoverable, siden alle transaksjoner venter med å committe til transaksjoner som endret data relevant for transaksjonen committer først. S4 og S5 er strict, siden objekter som leses eller skrives av en transaksjon ikke røres av andre transaksjoner før den første transaksjonen har committet.
Oppgave 3 Exercise 16.6 Isolasjon- og aksessnivåer i SQL 1. READ UNCOMMITTED Dirty read er mulig, da databasesystemet tillater å lese data som ikke er committed av en annen transaksjon, er det ingen garantier for at de ikke er oppdaterte. Unrepeatable read er mulig, siden poster som leses ikke blir låst. Phantom problem kan forekomme. Eksempel på transaksjon som går bra på dette isolasjonsnivået er å finne statistikk av en stor datamengde, da du ikke forventer at resultatet blir veldig feil fordi du kan gå glipp av uncommitted forandringer underveis. 2. READ COMMITTED Dirty read er ikke mulig, siden transaksjonene bare får lest ting som er committed. Unrepeatable read er mulig, siden verdier som leses godt kan bli forandret av andre transaksjoner. Phantom problem kan forekomme. Samme eksempel som over. 3. REPEATABLE READ Dirty read er ikke mulig, siden transaksjonen låser alle felter den leser. Unrepeatable read er ikke et problem, av samme grunn som over. Phantom problem kan forekomme. Alle transaksjoner som ikke skriver til databasen er trygge å kjøre her. 4. SERIALIZABLE Dirty read er ikke mulig. Unrepeatable read er ikke mulig. Phantom problem kan ikke forekomme. Alle transaksjoner går greit på dette isolasjonsnivået. Aksessnivået til transaksjoner kan settes til READ ONLY eller READ WRITE. Ved å sette for eksempel REPEATABLE READ READ ONLY er du sikker på konsistens, siden isolasjonsnivået er trygt ved kun lesetilgang.
Excercise 18.1 1. Databasesystemets recovery manager sikrer at transaksjoner er «atomic» og «durable». Dersom en transaksjon ikke committet sørger systemet for å «angre» alle operasonene transaksjonen fikk gjort, slik at transaksjonen kan ses på som atomisk. Dersom systemet krasjer har recovery manageren ansvar for å få databasen i en konsistent tilstand. 2. Forskjellen mellom «stable storage» og disk er at stable storage garanterer å overleve systemfeil. I realiteten er dette tull, siden stable storage gjerne også er disklagring, men med mange kopier på forskjellige steder for å minimere sannsynlighet for datatap. Logg er typisk lagret på stable storage. 3. «System crash» kan for eksempel være softwarefeil som får datamaskinen til å krasje. «Media failure» vil si at disken er fysisk ødelagt, «korrupt». 4. WAL står for Write Ahead Log, og går ut på at loggen for hva som gjøres med databasen oppdateres før endringene faktisk utføres. På denne måten sikrer systemet seg mot datatap, som kunne oppstått mellom oppdatering av databasen og skriving til loggen. 5. «Steal»: Dersom en pågående (uncommitted) transaksjon S er ferdig med en frame i minne (den er unpinned) kan en annen transaksjon stjele framen hvis databasesystemet tillater å skrive data forandret av S før S er ferdig. «Force»: Når en transaksjon er ferdig (committed) kan databasesystemet tvinge alle endringer til å skrives til disk. En «no-force»-policy blir da det motsatte, at endringer utført av S ikke nødvendigvis skrives med en gang S er committed.
Exercise 18.3 1. Agoritmen ARIES tar hånd om å gjenopprette databasen i en konsistent tilstand gjennom tre faser: Analysis: Finner ut hvilke data som ikke har blitt skrevet til databasen og aktive transaksjoner idet systemet krasjet. Redo: Starter et sted i loggen og utfører alle sørringer på nytt opp til det punktet hvor systemet krasjet. Undo: Angre (abort) transaksjoner som ikke ble korrekt utført (uncommitted). 2. Gitt historikken på bildet over, ARIES-algoritmen vil gjøre følgende under restart: a) I analysefasen identifiseres T1 som aktiv transaksjon. Alt de andre transaksjonene gjorde før restart identifiseres som «dirty», dvs at T1 skriver P5 og T3 skriver P3. b) Under redo-fasen gjøres alle operasjoner om igjen fra checkpoint fram til krasj. P3 skrives til disk siden det blir gjort av A2, som blir committed. c) Under undo-fasen angres alle endringer gjort av T1 og T3, dvs skriving av P3 og P5. Exercise 19.2 Har gitt relasjonen R (A, B, C, D) med avhengighetene: A B, BC E og ED A. 1. C og D er nøkler i R, de har ingen inn-piler. En må vite en av A, B og E for å bestemme alle, så alternativene blir CDA, CDB eller CDE. 2. R er i 3NF siden A B, BD E og ED A alle inneholder deler av nøkkelen på høyresiden. 3. R er ikke i BCNF, siden det krever at alle avhengigheter er enten trivielle eller er på formen superkey felt. En superkey er en nøkkel som definerer alle andre feltene i relasjonen, dvs enten CDA, CDB eller CDE. Ingen av FD-ene for R oppfyller dette kravet.
Exercise 19.5 Har en relasjon R(A, B, C, D, E, F, G, H, I), ser på oppdelinger R1 R5. 1. R1(A, C, B, D, E) : A B, C D Nøkkelen her er ACE. Avhengighetene oppfyller ikke kravet til 3NF, siden verken B eller D er en del av nøkkelen. Alle feltene er atomiske, R er på 1NF. Dekomponering til BCNF: Algoritmen er enkel; Så lenge det finnes avhengigheter X A som ikke oppfyller BCNF, del opp i R A og XA. Først «fjerner» vi A B, og lager AB og ACED (R B). Videre det samme med C D som gir ACE og CD. AB, ACE og CD er R på BCNF. 2. R2(A, B, F) : AC E, B F Nøkkel er AB. R2 er på 1NF. Dekomponering til BCNF gir BF, AB. 3. R3(A, D) : D G, G H Nøkkel er AD, relasjonen er allerede på BCNF. 4. R4(D, C, H, G) : A I, I A Nøkkel er DCHG, igjen er relasjonen ferdig på BCNF. 5. R5(A, I, C, E) : Ø Her må alle feltene være nøkkel, siden det ikke finnes avhengigheter. R5 er på BCNF. Exercise 19.6 Har relasjonen S (A, B, C) med følgende data: A B C 1 2 3 4 2 3 5 3 3 1. a) A B holder, siden alle A-verdier er unike. b) BC A holder ikke, siden (2,3) for B og C gir både 1 og 4 for A c) B C holder, B lik 2 eller 3 gir C lik 3. 2. Andre avhengigheter som holder over S: AC B AB C
Exercise 19.10 Har relasjonen R (A, B, C, D). 1. B C, D A. Oppdeling: BC og AD Nøkkelkandidater: AB Oppdelingen fungerer dårlig siden man taper informasjon ved join. Dvs, en join mellom BC og AD blir mye mer enn den opprinnelige relasjonen ABCD. 2. AB C, C A, C D. Oppdeling: ACD og BC Nøkkelkandidater: BC eller BA. Oppdelingen er tapsfri, siden ACD BC = C, og C er nøkkel i den første relasjonen ACD. Den inneholder derimot ikke avhengigheten AB C, siden det er C som er nøkkel i ACD. 3. A BC, C AD. Oppdeling: ABC, AD Nøkkelkandidater: A eller C. Relasjonen er allerede på BCNF, siden både C og A fungerer som superkey. Oppdelingen er lossless, siden ABC AD = A, men avhengigheten C AD mistes og det er liten vits i å dele opp relasjonen som allerede var på BCNF. 4. A B, B C, C D. Oppdeling: AB og ACD Nøkkelkandidater: A. Relasjonen er verken på BCNF eller 3NF, når vi har C D og ACD. Kravet for 3NF er at enten C er en superkey, eller at D er en del av en nøkkel, som ikke oppfylles. Igjen, lossless oppdeling, men avhengigheten B C mistes og det er ikke på 3NF. 5. A B, B C, C D. Oppdeling: AB, AD, CD Nøkkelkanidater: A. Oppdelingen er lossless; (AB AD) CD = B CD = C CD = C, men tar ikke vare på avhengigheten B C. En bedre oppdeling (også BCNF) er AB, BC, CD.