Databasteknik II: Inlämningsuppgift 2 - Loggfilen

Mål

Scenario

En enkel databas består av ett antal heltal, som lagras på en fil. En transaktion går igenom heltalen, och genomför ändringar i databasen, till exempel genom 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

Inledande uppgifter

  1. 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.
  2. 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.
  3. 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.)
  4. Provkör programmet för att titta på innehållet i databasen.
  5. 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.)
  6. Provkör ändra-programmet ett par gånger, och kontrollera med visa-programmet att ändra-programmet fungerar.
  7. 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

  1. 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.)
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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.
  7. 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.
  8. 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), 25 januari 2017