Undo/Redo log (Semmisség/helyrehozó naplózás)
Undo ugye túl sokszor ír, Redo pedig átlagosan nagy puffert igényel
Na de ha csak naivan összevonjuk a két dolgot, akkor a
COMMITmit is jelent? (semmi jót)
Bejegyzés tartalma
<T1, A, 5, 7>
T1- Tranzakció azonosítójaA- Módosított mező5- módosítás előtti érték7- módosítás értéke
Írás sorrendje
- Mindent előre naplózunk, csak utána hajthatjuk végre
- Write after log
COMMITelőtt, és után is történhet lemezre írás- Nagyobb naplóhoz vezet
| 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\) | \(8\) | \(8\) | ||
| 3 | t:=t*2 |
\(16\) | \(8\) | \(8\) | \(8\) | ||
| 4 | WRITE(A,t) |
\(16\) | \(16\) | \(8\) | \(8\) | <T,A,8, 16> |
|
| 5 | READ(B,t) |
\(8\) | \(16\) | \(8\) | \(8\) | \(8\) | |
| 6 | t:=t*2 |
\(16\) | \(16\) | \(8\) | \(8\) | \(8\) | |
| 7 | WRITE(B,t) |
\(16\) | \(16\) | \(8\) | \(8\) | \(8\) | <T,B,8, 16> |
| 8 | FLUSH LOG |
\(16\) | \(16\) | \(16\) | \(8\) | \(8\) | |
| 9 | OUTPUT(A) |
\(16\) | \(16\) | \(16\) | \(\green{16}\) | \(8\) | |
| 10 | <T, COMMIT> |
||||||
| 11 | OUTPUT(B) |
$16 | $16 | $16 | 16 | \(\purple{16}\) |
COMMITa jelen esetben a 10-es lépés, de lehettt volna éppen annyira a 9-es output lőtt, amennyire a 11-es output után
Ez azt jelenti, hogy előfordulhat az, hogy egy befejezett tranzakciónak még semelyik írása sem került lemezre, vagy egy nem befejezett tranzakció eddigi összes módosítása már lemezen van
Gyors tipp
- Ha a rendszerhiba a
COMMITután történik akkor REDO szerint,COMMITelőtti hiba esetén meg UNDO szerint járunk e COMMITelőfordulását azonnalFLUSH LOG-al be kell iktatni, különben már befejezett változtatásokat is megsemmisíthetünk- Viszont, mint eddig, ha egy
<START CKPT(...)>le van zárva<END CKPT>-vel, akkor az utolsó lezárt start mögé már nem kell menni, az ottani összes lépés már a lemezen van
Sajnos előfordulhat, hogy egy befejezett
Atranzakció értékét visszaállítjuk, de az egy nem befejezettBtranzakció módosítására építNem igazán van olyan sorrend, ami egy ilyen konkurens helyzetből konzisztens állapotot tudna visszahozni (Erről EA beszél később...)
Ellenőrzőpont működés közben
<START CKPT(T1, ..., Tk)>az aktív tranzakciókkal, mint mindig (majd írjuk is lemezre a naplót)- Írjunk minden piszkos puffert a lemezre
- Azokat, amelyek egy vagy több adatbáziselemet tartalmaznak
<END CKPT>, majd írjuk a naplót a lemezre
UNDO/REDO minden írást elvégez checkpoint-nál, míg REDO csak a befejezett tranzakciókat írja ki
Ellenőrzőpont helyreállítása
- UNDO szerint a Napló végétől az utolsó checkpoint kezdetéig
- Meghatározzuk a befejezett tranzakciókat (legyen
S) - Megsemmisítjük azokat a hatásokat, amelyek nincsenek
S-ben
- Meghatározzuk a befejezett tranzakciókat (legyen
- Megsemmisítjük a függő tranzakciókat
- Visszamegyünk a
{T1, ..., Tk} \ Stranzakcióin- Aktív, és még nem befejezett tranzakciók
- Visszamegyünk a
- REDO szerint az utolsó checkpoint kezdetétől a napló végéig
- Helyrehozzuk
Stranzakcióinak hatását
- Helyrehozzuk