Gagnasafnsfræði, haust 2011

Verkefni 9 - Hreyfingar

Lausnum skal skilað í hólf viðkomandi dæmakennara (sjá lista yfir dæmatíma).

Skiladagur: þriðjudaginn 1. nóvember fyrir kl 16:00

Skiladæmin í þessari viku verða með öðru sniði en vanalega. Við ætlum að leysa verkefni úr námskeiði hjá MIT.

Verkefnið fjallar um notkun á dagbók (e. write-ahead log) við útfærslu á hreyfingum, en með slíku kerfi er hægt að tryggja bæði A (Atomicity) og D (Durability) eiginleika hreyfinga, þ.e. tvo eiginleika af þeim fjórum eiginleikum (ACID) sem eiga að gilda um hreyfingar.

Í verkefninu fáið þið í hendurnar forritið "wal-sys", sem útfærir dagbókarkerfi utan um hreyfingar í einfölduðu bókhaldskerfi. Kerfið býður upp á þrjár bókhaldsaðgerðir: stofna reikning, framkvæma debit á reikning og framkvæma kredit á reikning. Það er síðan hægt að binda margar aðgerðir saman í eina hreyfingu með begin/commit, o.s.frv.

Hér er verkefnið sjálft: V9.pdf. Svarið öllum spurningum sem koma fram í verkefninu.

Hér er hægt að sækja wal-sys forritið (skrifað í Perl forritunarmálinu)

Í dæmatímum í vikunni verður farið stuttlega í uppsetningu og notkun á wal-sys forritinu.

Í fyrirlestrinum á föstudaginn verður fjallað um hreyfingar og útfærslu á þeim.

Annað efni sem gæti gagnast ykkur:

Kafli úr bók frá MIT sem fjallar um atomicity: Chapter 9: Atomicity
Glósur úr tímum hjá MIT sem fjalla um þetta efni: atomicity, logging
Umfjöllun um WAL í PostgreSQL
Umfjöllun um WAL í sqlite

Svör við spurningum:

Skipanaröð 1:

begin 1
create_account 1 studentA 1000
commit 1
end 1
begin 2
create_account 2 studentB 2000
begin 3
create_account 3 studentC 3000
credit_account 3 studentC 100
debit_account 3 studentA 100
commit 3
show_state
crash

Wal-sys displays the current state of the database contents after you type show_state. Why doesn't the database show studentB?
Það var ekki gert commit á hreyfingu nr. 2. Sú hreyfing er ókláruð (pending) þegar show_state er framkvæmt.
When the database recovers, which accounts should be active, and what values should they contain?
Eftir endurreisn þá ætti staðan að vera eftirfarandi:
```
studentA 900
studentC 3100
```
Can you explain why the "DB" file does not contain a record for studentC and contains the pre-debit balance for studentA?
Þegar hrunið varð (þ.e. "crash" skipunin framkvæmd) þá var búið að ljúka hreyfingu 3 með commit en það var ekki búið að uppfæra sjálfa DB stöðuna, þ.e. framkvæma s.k. install með end skipuninni í wal-sys.
What do you expect the state of "DB" to be after wal-sys recovers? Why?
Dagbókin inniheldur allar færslurnar og í henni eru þrjár hreyfingar.
- Hreyfing 1: Lokað með commit, DB uppfært
- Hreyfing 2: Ókláruð
- Hreyfing 3: Lokað með commit, ekki búið að uppfæra DB
Endurreisn notar dagbókina til að leiðrétta DB. Eftir endurreisn þá ætti DB að innihalda rétta stöðu, þ.e.
```
studentA 900
studentC 3100
```
Run wal-sys again to recover the database. Examine the "DB" file. Does the state of the database match your expectations? Why or why not?
Já, staðan er rétt. wal-sys framkvæmdi endurreisn þegar það var ræst og leiðrétti DB stöðuna samkvæmt LOG dagbókinni.
During recovery, wal-sys reports the action_ids of those recoverable actions that are "Losers", "Winners", and "Done". What is the meaning of these categories?
Í flokknum "winners" eru hreyfingar sem voru kláraðar með commit en hafa ekki enn verið settar í DB.
Í flokknum "losers" eru ókláraðar hreyfingar (hvorki commit né abort).
Í flokknum "done" eru kláraðar hreyfingar sem eru einnig í DB.

Skipanaröð 2:

begin 1
create_account 1 studentA 1000
commit 1
end 1
begin 2
create_account 2 studentB 2000
checkpoint
begin 3
create_account 3 studentC 3000
credit_account 3 studentC 100
debit_account 2 studentB 100
commit 3
show_state
crash

Why are the results of recoverable action 2's create_account 2 studentB 2000 command not installed in "DB" by the checkpoint command on the following line?
Því hreyfing nr. 2 er ennþá opin þegar checkpoint skipunin er framkvæmd.
How many lines were rolled back? What is the advantage of using checkpoints?
"6 lines rolled back".
Checkpoints leyfa okkur að stytta dagbókina (henda gömlum færslum). Í wal-sys líkaninu þá er dagbókin þó aldrei stytt eftir checkpoint, heldur er checkpoint bara notað til að þurfa ekki að lesa alla dagbókina í endurreisn.
Does the second run of the recovery procedure restore "DB" to the same state as the first run? What is this property called?
Já, endurtekin endurreisn gefur alltaf sömu niðurstöðu. Endurreisn er sjálfvalda (idempotent) aðgerð.
Compare the action_ids of "Winners", "Losers", and "Done" from the second recovery with those from the first. The lists are different. How does the recovery procedure guarantee the property from Question 9 even though the recovery procedure can change? (Hint: Examine the "LOG" file).
Listi í fyrri endurreisn:
Winners: id: 3 Losers: id: 2 Done: id: 1
Listi í seinni endurreisn:
Winners: Losers: id: 2 Done: id: 1 id: 3