Kihagyás

Undo log (Semmisségi naplózás)

Cél: Az konzisztens adatbázis állapot visszaállítása

Undo - Példa

Folytatva az előző példával, illetve előző megkötéssel (miszerint A=B)

Read(A, t); t <- t*2
Write(A, t);
Read(B, t); t <- t*2
Write(B, t);
Output(A);
Output(B);

Bejegyzés tartalma

<T1, A, 5>

  • T1 - Tranzakció azonosítója
  • A - Módosított mező
  • 5 - módosítás előtti érték

Naplózás ideje

Naplóba írás után kell , hogy az új adat rákerüljön a lemezre

  • Adatmódosításról a napló a változtatás előtt frissül
    • ha elszálna, a régi érték saját magával felülírása nem okozhat gondot
  • Sikeres tranzakciónak állapotát <COMMIT> csak minden változtatás elvégzése után kerülhet be a naplóba
    • Különben lehetne hiányzó módosítás, amit nem tudnánk felderíteni

Ebből következik, hogy ha módosítás van bent, nem biztos, hogy még megtörtént, ha COMMIT van bennt, akkor minden hozzá tartozó bejegyzés már megtörtént.

Írás sorrendje

  • A módosítások maguk, illetve azok bejegyzésük külön-külön kell végrehajtani
  • Nem lehet csoportosítani őket!
  • A bejegyzések lemezre írásának elrendelésére(kikényszerítésére) a FLUSH LOG művelet kell
    • Ekkor a pufferkezelő minden még lemezre nem írt naplóblokkot kiírja a lemezre

Legend

  • t - Változó
  • M-A - A értéke a memóriában
  • M-B - B értéke a memóriában
  • D-A - A értéke a lemezen
  • D-B - B értéke a lemezen
  • Napló - napló, lol
Lépés Tevékenység t M-A M-B D-A D-B Napló
1 <T, START>
2 READ(A,t) 8 8 16 8 8
3 t:=t*2 16 16 16 8 8
4 WRITE(A,t) 16 16 16 8 8 <T,A,8>
5 READ(B,t) 8 16 8 8 8
6 t:=t*2 16 16 8 8 8
7 WRITE(B,t) 16 16 16 8 8 <T,B,8>
8 FLUSH LOG 16 16 16 8 8
9 OUTPUT(A) 16 16 16 8 8
10 OUTPUT(B) 16 16 16 8 8
11 <T, COMMIT>
12 FLUSH LOG
What EA gave us 
(1) Let S = set of transactions with <Ti, start> in log, bur no <Ti, commit> (or <Ti, abort>) record in log
(2) For each <Ti, X, v> in log, in reverse order (latest -> earliest) do:
    if Ti ∈ S then ⎧ - write (X, v)
                   ⎨
                   ⎩ - output(X)
(3) For each Ti ∈ S do:
    write <Ti, abort> to log
(4) Flush log

Gyors tippek

Ha hiba történik, és visszaállításra van szükség:

  • Ha a tranzakciónak a START, és vagy COMMIT, vagy ABORT bejegyzése naplóban van már(!), akkor rendebn van, nem kell helyreállítani
  • Ha START van, de nincs lezárva, akkor minden lépését meg kell ismételni visszafele, majd abortálni a tranzakciót

Ellenőrzőpont

  • CHECKPOINT paranccsal megtiltunk minden új tranzakció indítását, amíg minden más tranzakció le nem zárul
  • Ilyenkor FLUSH LOG-al kiírunk mindent
  • Felvesszük a <CKPT>-t a naplóba
  • Újabb FLUSH LOG
  • Újra kezdhetőek tranzakciók

Éppen ezért elég csak a legutolsó CHECKPOINT-ig elmenni helyreállításkor, mert előtte minden tranzakció már lezárult

Na de Kotlin, egy tranzakció órákig is tarthat Enterprise™️ rendszereken, nem érünk rá mindent megvárni...

Hát jah, de cseppet se félj, van erre is módszer (send help)

Ellenőrzőpont működés közben

Non-quiescent checkpointing

  • <START CKPT(T1,...,Tk)>
    • Ahol T1, ..., Tk az akkor még aktív tranzakciók nevei
  • FLUSH LOG
    • Ezután meg kell várni, hogy ezek befejeződnek (valahogy), de továbbra is indíthatóak újjabb tranzakciók
  • <END CKPT>
    • Miután az aktív tranzakciók mind lezárultak

Ellenőrzőpont helyreállítása

Így két eset fordulhat elő helyreállításkor:

  • Keresünk, és <START CKPT(...)>-t találunk
    • Tudjuk ebből, hogy melyek voltak aktívak, minden más OK volt
    • Tehát állítsuk vissza T1, ... , Tk tranzakciókat, és jó lesz
    • A legkorábban kezdődő T1 tranzakcióig viszont vissza kell menni, hogy undo-olhassuk
  • Keresünk, és <END CKPT>-t találunk
    • Előtte minden jó, kész vagyunk

Speciális(abb) eset:

  • <START CKPT(...)> előtt egy másik <START CKPT(...)>-ot találunk
    • Egyszerre csak egy checkpoint kezdeményezhető, akkor ez meg mi??!
    • Fun, I know
  • Ez csak azt jelenheti, hogy az előző checkpoint létrehozásakor egyszer már történt redszerhiba, ami vissza lett állítva
    • (különben nem lennénk itt)
  • Az ilyen bejegyzéseket figyelmen kívül kell hagyni

Pro tipp

  • Egy <END CKPT>-hez tartozó <START CKPT> előtt minden bejegyzés törölhető
  • Az ugynazon tranzakcióhoz tartozó naplóbejegyzéseket összeláncolva elég csak ezeken a láncokon iterálni helyreállításkor