Kihagyás

Tranzakciók

A tranzakciók olyan folyamatok, amik lekérdezéseket/módosításokat tartalmaz

  • Az utasítások szemantikusan kapcsolódnak
    • "Egy értelmes egészet" alkotnak
  • Jellemzően egy utasítást tartalmaznak, azonban SQL-ben explicit módon megadható
  • Szükséges, hogy a végrehajtásuk tartós legyen
    • Ha egy tranzakció befejeződött, az eredménynek akár közvetlen követő rendszerhibák esetén is meg kell maradnia

Tranzakció feldolgozó részei

  • Konkurenciakezelő
    • Tranzakciók oszthatatlanságára, elkülönítésére
    • pl. Ugyanazon rekordot egyidőben ketten változtatják. Hogyan kerüljük el a versenyhelyzetet?
  • Naplózás- és helyreállítás-kezelő
    • Tranzakciók tartósságára
    • pl. Módosítás közben áramkimaradás van. Mi a korrekt adatbázis állapot?

Motiváció: Több folyamat, vagy külső behatás esetén kialakuló rossz interakciók elkerülése

  • A műveletek végrehajtási sorrendje fontos
    • pl. foglaláskor kialakuló konkurencia esetén az első vásárlónak jár a jegy/hely/stb.

ACID tranzakciók

Atomicity - Atomiság

A tranzakció sikeressége esetén az abban foglalt minden utasítás garantáltan teljesül

Hiba, vagy a tranzakció megtagadása esetén a benne foglalt utasítások egyike sem lép életbe (visszagörgethető)

\[ \text{"Minden vagy semmi"} \]

Consistency - Konzisztencia

Az adatbázis megszorításai megőrződnek

\[ \text{"Helyesnek tűnik"} \]

Isolation - Elkülönítés

A felhasználóknak úgy tűnik, mintha a folyamatok, elkülönítve, egymás után futnának le.

Lényegében a felhasználó a tranzakció lezárása előtt a saját módosításait látja csak

\[ \text{"Mintha egyedül lenne"} \]

Durability - Tartósság

A befejeződött tranzakció módosításai nem veszhetnek el

\[ \text{"Túléli a hibákat"} \]

COMMIT

  • Tranzakció véglegesítése

ROLLBACK

  • Tranzakció visszagörgetése, módosítások elvetése
  • Felmerülő hiba mindenképp a tranzakció visszagörgetését okozza

Versenyhelyzet Példával

Szituáció

  • Vegyük a Felszolgál(kocsma, sör, ár) táblát, és TFH Sally olvasni, Joe pedig módosítani fog az adatbázison
    • Sally lekérdezi Joe legolcsóbb, és legdrágább sörét két utasításban
    • Joe úgy dönt, hogy Bud és Miller sörök helyett ezentúl Heinekent árul
    • Bud és Miller eredeti ára rendre 2.50 és 3.00, az új Heineken 3.50

Sally utasításai

Példa további részében \(\green{(max)}\)

SELECT MAX(ár) 
FROM Felszolgál
WHERE kocsma = 'Joe bárja';

Példa további részében \(\blue{(min)}\)

SELECT MAX(ár) 
FROM Felszolgál
WHERE kocsma = 'Joe bárja';

Joe utasításai

Példa további részében \(\red{(del)}\)

DELETE
FROM Felszolgál
WHERE kocsma = 'Joe bárja';

Példa további részében \(\orange{(ins)}\)

INSERT INTO Felszolgál
VALUES ('Joe bárja', 'Heineken', 3.50);

Átfedésben álló utasítások

A \(\green{(max)}\) mindenképp a \(\blue{(min)}\) előtt kell végrehajtódjon, hasonlóan a \(\red{(del)}\)-nek az \(\orange{(ins)}\) előtt.

Viszont mert nem voltak tranzakcióba gyűjtve, nincsenek egyéb megszorítások a sorrendre vonatkozóan.

Tételezzük fel a következő átfedést:

\[ \large{\green{(max)}\to\red{(del)}\to\orange{(ins)}\to\blue{(min)}} \]

Látható állapotok

Joe árai {2.50,3.0} {2.50,3.0} {3.50}
Utasítás \(\green{(max)}\) \(\red{(del)}\) \(\orange{(ins)}\) \(\blue{(min)}\)
Eredmény 3.0 3.50

Sally így azt látja, hogy a \(\green{(max)}\) eredménye kissebb a \(\blue{(min)}\) eredményénél

MAX < MIN!

  • Ha Sally utasításait tranzakcióba gyűjtjük, akkor ez az inkonzisztencia nem történhet meg.
  • Joe árait akkor egy időpontban látja
    • Vagy a változtatások előtt, vagy utánuk
    • Ezzel garantálva, hogy a MAX és a MIN ugyanazon árakból (előfordulásból) számolódjon ki

Másik hibaforrás - Visszagörgetés

TFH, hogy Joe a \(\red{(del)}\to\orange{(ins)}\) utasításokat nem véglegesíti a tranzakciójában, hanem úgy dönt, visszagörgeti a módosításokat

Új felállás:

\[ \large{\gray{(del)}\to\gray{(ins)}\to(\green{(max)}\blue{(min)})\to\gray{rollback}} \]

Ekkor Sally az \(\orange{(ins)}\) után, de a visszagörgetés előtt végrehajtáskor kaphat olyan értéket, ami nincs is benne az adatbázisban (és soha nem is volt 👻)

  • Erre megoldás az, ha Joe is tranzakcióban hajtja végre az utasításait, így csak akkor válik láthatóvá, ha a tranzakció egy COMMIT utasításra nem véglegesítődik
    • Így visszagörgetéskor a hatás sosem következik be, nem lesz látható

Elkülönítési szintek

Az SQL nég elkülönülési szintet definiál, amik a megengedett interakciókat mondják meg az egyidőben végrehajtódó tranzakciók között

Minden DB rendszer tetszőlegesen implementálhatja a tranzakciókat

Az elkülönítési szint személyes választás, nincs kihatással más felhasználók elkülönítésére

Elkülönítési szint kiválasztása

SET TRANSACTION ISOLATION LEVEL X

Ahol \(X=\)

  1. SERIALIZABLE
  2. REPEATABLE READ
  3. READ COMMITED
  4. READ UNCOMMITED

READ UNCOMMITED

Akkor is láthatja az adatokat, amikor a változtatások még nem lettek véglegesítve

"Piszkos adatok"

READ COMMITED

Csak kommitálás utáni adatokat láthat, de nem feltétlen ugyanazt az adatot

Ha közben kommitálás történik, annak módosításai láthatóvá vállnak új utasításoknál

REPEATABLE READ

Hasonló a READ COMMITED megszorításhoz, azonban azok az adatok, amik a tranzakció kezdetekor láthatóak voltak, azok láthatóak is maradnak kommitálás esetén is

Emiatt a kezdetihez képest több sor is látható lehet (Fantom adatok jelenhetnek meg)

SERIALIZABLE

Ez felel meg teljesen az ACID tranzakciókkal

A sorbarendezhetőség jelen esetben azt jelenti, hogy csak a tranzakciók előtt vagy utáni állapotban látja az adatokat, köztes állapot nem lehetséges

Elkülönítési szintek összesítő

Elkülönítési szint Piszkos adat olvasása Mem ismételhető olvasás Fantomadatok
READ UNCOMMITED Megengedett Megengedett Megengedett
READ COMMITED Nem Megengedett Megengedett Megengedett
REPEATABLE READ Nem Megengedett Nem Megengedett Megengedett
SERIALIZABLE Nem Megengedett Nem Megengedett Nem egengedett

Tranzakciós szintek az előző példával

  • Ha Sally READ UNCOMMITED szintet választ, akkor láthatja a 3.50 árat, még akkor is, ha Joe utána abortál
  • READ COMMITED esetén a \(\small{\green{(max)}\to\red{(del)}\to\orange{(ins)}\to\blue{(min)}}\) átfedés megengedett
    • Szóval MAX < MIN, again...
  • REPEATABLE READ esetén Sally a \(\small{\green{(max)}\to\red{(del)}\to\orange{(ins)}\to\blue{(min)}}\) átfedéskor az alábbit tapasztalja:
    • \(\green{(max)}\) > a 2.50 és 3.00 árakat látja
    • \(\blue{(min)}\) > látja a 3.50-t, de a 2.50-t és 3.00-t is látja, mert a korábbi olvasáskor már látta azokat
  • SERIALIZABLE esetén Sally az ACID által ígért módon vagy Joe módosítása előtt, vagy az után fogja látni az árakat, ha visszagörget Joe, ha nem
  • Bármilyen elkülönítési szintet választ Joe, Sally választására nincsen kihatással