Databasteknik II: Inlämningsuppgift 2 - Loggfilen
Mål
-
Att förstå principerna för hur en loggfil används i transaktionshantering,
med write-ahead logging och återhämtning (recovery).
-
Att kunna implementera enkel transaktionshantering med en loggfil.
-
Att inse att de saker som databashanteraren gör inte är magi,
utan går att skriva som ett program.
-
Att lära sig lite mer om hur filhantering fungerar när man programmerar,
till exempel i vilken mån ens favoritspråk buffrar utmatning till filer,
och hur det kan påverka om man bygger en databashanterare i det språket.
Scenario
En enkel databas består av ett antal heltal, som lagras på en fil.
En transaktion går igenom heltalen, och genomför en enkel ändring,
till exempel att öka vart och ett av talen med ett.
Tyvärr kan transaktionen avbrytas mitt i,
till exempel genom en systemkrasch, ett strömavbrott eller en otålig användare.
Vi måste därför hantera sådana avbrutna transaktioner.
Förberedelser
-
Läs lämpligt kursmaterial med mera.
-
Man behöver tillgång till en programmeringsomgivning,
där man kan programmera i något vanligt programmeringsspråk,
till exempel C, C++, Java eller C#.
Själv har jag använt C med kompilatorn GCC under Linux,
men andra alternativ går också bra,
till exempel C i Visual Studio 2008.
Inledande uppgifter
-
Skriv ett program som skapar en "databas",
som består av en mängd heltal som lagras på en fil.
Här är ett exempel på hur ett sådant program kan se ut:
createdb.c.
(Man kan använda det programmet om man vill.)
Det bör vara en binärfil,
för med en textfil kan det bli svårt att sen skriva över enskilda tal med nya värden.
-
Kör programmet för att skapa databasen.
Man kan prova med en databas som innehåller en miljon heltal,
men senare kan man anpassa storleken på databasen efter hur snabb dator man har.
-
Skriv ett annat program som visar innehållet i databasen.
Här är ett exempel på hur ett sådant program kan se ut:
showdb.c.
(Man kan använda det programmet om man vill.)
-
Provkör programmet för att titta på innehållet i databasen.
-
Skriv ett tredje program som går igenom talen i databasen,
och ökar vart och ett av dem med ett.
Här är ett exempel på hur ett sådant program kan se ut:
incrementdb.c.
(Man kan använda det programmet om man vill.)
-
Provkör ändra-programmet ett par gånger,
och kontrollera med visa-programmet att ändra-programmet fungerar.
-
Kör ändra-programmet en gång till, och avbryt det mitt under körningen.
Nu bör databasen vara i ett inkonsistent tillstånd,
där en del av talen uppdaterats, och andra inte.
Verifiera detta med visa-programmet.
Den riktiga uppgiften
-
Skriv ett nytt program som går igenom talen i databasen,
och ökar vart och ett av dem med ett.
men till skillnad från det tidigare ändra-programmet,
ska det här programmet även anteckna alla ändringar på en loggfil,
så att transaktionen kan rullas tillbaka.
(Tips: Loggfilen kan vara i textformat,
så har man mindre behov av att skriva ett särskilt
program som visar innehållet i den.)
-
Glöm inte att skriva commit i loggfilen.
Gärna start-transaction också,
men om man inte skriver commit
vet man inte om transaktionen är committad ("färdig") eller inte,
och vid recovery vet man i så fall inte om ändringarna som transaktionen gjort
i databasen ska tas bort eller skrivas på nytt.
-
Meningen är att alla ändringarna från en körning av ändra-programmet
ska bilda en stor transaktion,
inte att det varje ändring ska ske i en egen transaktion.
Vi vill kunna visa vad som händer med halvfärdiga transaktioner
som gjort vissa av sina ändringar i databasen men inte alla.
-
Provkör det nya ändra-programmet ett par gånger,
och kontrollera med visa-programmet att också det här nya ändra-programmet fungerar.
Ser loggfilen riktig ut?
-
Skriv ett recovery-program,
som utifrån den materialiserade databasen
och loggfilen
återställer databasen till ett konsistent tillstånd.
Det räcker med att man kan köra en enda transaktion,
och sen återställa den.
-
Verifiera att det går att avbryta ändra-programmet mitt i,
och sen använda recovery-programmet för att
återställa den inkonsistenta databasen.
-
Verifiera att det går att köra klart ändra-programmet,
så att transaktionen committas,
och att recovery-programmet sen inte tar bort transaktionens ändringar.
-
Frivilligt:
Gör så att man kan köra flera transaktioner
(efter varandra, inte samtidigt),
och att recovery-programmet går igenom loggfilen och
på lämpligt sätt hanterar alla de transaktioner som finns med.
Redovisning
Visa programmen för läraren, demonstrera hur de fungerar, och diskutera,
eller,
skicka
e-post
med fullständiga och tydliga beskrivningar av hur programmen fungerar och är uppbyggda.
Skicka med väl valda och väl kommenterade testkörningar, med in- och utdata.
Skicka också med källkoden, med förklaringar.
Om man arbetat i en miljö som Visual Studio eller Eclipse bör man packa ihop hela projektkatalogen
som en Zip-fil och skicka den som en bilaga.
(Även rar- och tar-filer fungerar.)
Men döp först om Zip-filen från nånting.zip till exempelvis nånting.info för att överlista överambitiösa virusfilter.
Arbeta i grupper om en eller två studenter.
I undantagsfall kan man arbeta i grupper om tre, men fråga läraren först.
Det är tillåtet att samarbeta i större grupper än så,
men varje grupp om 1-3 studenter måste fortfarande redovisa separat,
och det måste också tydligt framgå (i rapporten eller på annat sätt)
vilka som deltog i samarbetet.
Thomas Padron-McCarthy
(thomas.padron-mccarthy@oru.se),
22 mars 2016