Adatbázis Rendszerek II. 6. Ea: Tranzakciók B I v: T 2014.02.15 M A N 1/39
Párhuzamosság Hasznos és kényelmes a felhasználó oldaláról Kihívás problémák a konkurens végrehajtásnál konfliktus helyzetek (azonos erőforrás igény) Megoldások: várakoztatás várakozó sorok (nyomtató) adatbázis-kezelésben egyedi vonások 2/39 DB
Tranzakció fogalma Logikailag összetartozó, egységként kezelt műveletsor. Az adatbázis-kezelés központi fogalma Minden művelet tranzakcióba szervezetten hajtódik végre A DBMS nem engedi tranzakción kívüli művelet végrehajtását Pl.: Az A számláról átutalunk 50 egységet a B számlára 3/39 1. 2. 3. 4. 5. 6. 7. 8. BEGIN READ(A) A:=A - 50 WRITE(A) READ(B) B:=B + 50 WRITE(B) END
Tranzakció fogalma A tranzakció az adatbázisműveletek egy olyan csoportja, amelyek vagy mindegyike érvényre jut (commit) vagy közülük egyik sem (abort). Megkötés: a mindent vagy semmit elv szerint hajtódnak végre. A tranzakcióknak úgy kell végrehajtódniuk, hogy megfeleljenek az adatbáziskezelés sajátosságainak, ezek az ACID elvek. 4/39 login DML logout commit abort begin transaction insert delete update end transaction
ACID elvek Atomicity Atomi Consistency Konzisztens Isolation Izolált Durability Tartós 5/39
ACID elvek Atomicity Consistency Isolation Durability Atomiság Konzisztencia Izoláció Tartósság Atomi, vagyis a tranzakció minden művelete végrehajtódik, vagy egy sem. Konzisztens, vagyis konzisztens állapotból konzisztens állapotba visz. Izolált, vagyis az eredmény ne függjön más párhuzamosan futó tranzakció hatásától. Tartós, vagyis a véglegesített tranzakció hatása már nem szüntethető meg. 6/39
Atomiság Atomiság A műveletek nem izoláltak, egyediek, hanem kapcsolat van közöttük A felhasználó rendszerint műveletsort akar végrehajtani, nem egyedi műveletet Külön-külön nincs értelmük a műveleteknek, illetve hibához, ellentmondáshoz vezethetnek pl. készpénzfelvétel automatából pinkód beírás -> ellenőrzés művelet megadás -> készpénz beállítás hitelkeret ellenőrzés -> készpénz levétele a számláról pénz kiadása, kártya kiadása, bizonylat kiadása 7/39
Atomiság Atomiság A DBMS-nek képesnek kell lennie a műveletek visszagörgetésre. Félig elvégzett műveletsor nem maradhat a rendszerben. 8/39
Konzisztencia Konzisztencia Minden felhasználó számára konzisztens kell legyen (egységes, ellentmondás mentes) Konzisztens állapotból konzisztens állapotba vigyen Integritás őrzés pl. leokéztuk az összeget, de nem kapjuk meg! Integritás sértő műveletek megakadályozása pl. életkor mezbe 3012 kerül 9/39
Izoláció Izoláció A felhasználó a párhuzamosság káros mellékhatásaiból minél kevesebbet érezzen Legjobb, ha a felhasználó úgy érzi, hogy egyedül dolgozik a rendszerben Munkájának eredménye csak a kiinduló állapottól függjön, ne az egyéb tevékenységektől 10/39
Tartósság Tartósság Műveletsor sikeres végrehajtása esetén a felhasználó visszajelzést kap Biztos lehet abban, hogy a műveletsor hatása véglegesen beíródott az adatbázisba Későbbi művelet nem törölheti vissza A lezárt tranzakciók eredményeit az adatbázis-kezelő mindenáron őrizze meg Gondoskodjon a véglegesített adatok elvesztése elleni védelemről 11/39
Tranzakciók leírása Műveletsort kell megadni Elemei: Műveletek: olvasás: r, írás: w objektum, amelyre hatnak paraméterként: r(x), w(x) tranzakció lezárása véglegesítés (commit): c visszagörgetés (abort): a Sorrendiség: megelőzési reláció: p1 -> p2 12/39
Tranzakciók ábrázolása Ábrázolás gráffal: Csomópontok a műveletek, irányított élei a megelőzési relációk Kötöttségek érvényes tranzakció esetén: Tartalmaznia kell egy lezárási műveletet (c,a) Pontosan csak az egyiküket tartalmazhatja A lezárási művelet az utolsó, az összes többi megelőzi Egyértelmű végrehajthatósági feltétel: A műveletsor eredménye azonos kezdőfeltételek mellet mindig egyezzen meg a leírt tranzakció eredményével 13/39
Tranzakciók ábrázolása 2. r(x) w1(x) c w2(x) w1(x) = 3 w2(x) = 5 w1(x) -> w2(x) =/= w2(x) -> w1(x) 14/39
Tranzakciók jellemzése Bármely két művelet között létezzen megelőzési reláció: egyértelmű, de nem szükséges minden esetben általában csak a tranzakció eredménye a fontos a közbenső állapotok érdektelenek több út is adhatja ugyanazt az eredményt ekkor a rendszer bármelyiket választhatja 15/39
Tranzakciók ábrázolása 3. r(x) w(x) c r(y) w(y) r(x) -> w(x) -> r(y) -> w(y) == r(y) -> r(x) -> w(x) -> w(y) Kérdés: mely elemek közötti relációk (nem) hagyhatók el? Válasz: amelyek sorrendje fontos a végeredmény szempontjából Konfliktusban álló műveletpárok 16/39
Konfliktusban álló műveletek Sorrendiség kihat az eredményre! Konfliktus esetén: azonos objektumnak kell szerepelnie mindkét műveletben különböző objektumokhoz való hozzáférés nincs hatással egymásra legalább az egyik írási művelet az olvasások nem módosítják az adatbázist, bármikor felcserélhetőek írási műveletek időbeli pozíciója lényeges 17/39
Konfliktusban álló műveletek 2. Gráf esetén egyértelmű a végrehajtás eredménye: a gráfban bármely két konfliktusban álló műveletpár között létezik megelőzési reláció ezt a tranzakció megadásánál meg is követeljük 18/39
Tranzakciók ekvivalenciája Ugyanazon kiinduló állapotból, ugyanazon műveletek az eredmény szempontjából ekvivalens sorrendben hajtódnak végre. 19/39
History (esetleírás, történet) A rendszerben futó tranzakciók összessége Megadása hasonló a tranzakció megadásához műveletekből áll lényeges a végrehajtási sorrend Ábrázolása: gráffal a tranzakció azonosítóját is feltüntetjük, mint művelet indexet 20/39
History - Példa w1(x) r1(y) w1(y) a1 21/39 r2(x) w2(x) c2 T1 kiír egy értéket x-be T2 olvassa ezt, majd ez alapján új értéket ír x-be T2 véglegesíti az eredményt T1 tovább fut, olvassa y-t, majd módosítja T1 abortálódik w1(x) utasítás-t hogyan görgetjük vissza? T2 nem véglegesített adatokat használt fel, ezért T2 tranzakciót is vissza kell görgetni
RecoverAble history (jóvá tehető, visszaállítható) Egy history visszagörgethető, ha minden tranzakció később zárul le minden olyan tranzakciónál, amiből ő olvasott. w1(x) r1(y) w1(y) a1 r2(x) w2(x) c2 22/39
Megoldási ötletek A tranzakció csak a már lezárt másik tranzakció után írhatja ugyanazt az elemet. A tranzakció csak a már lezárt másik tranzakció után olvashatja ugyanazt az elemet. Teljes izoláció, vagyis csak sorban, egymás után hajtódhatnak végre a tranzakciók. 23/39
Anomáliák (1) Konfliktusban álló műveletek keveredése: Két írás egymás után lost update w1(x) w2(x) Olvasás két írás között dirty read w1(x) r2(x) w1(x) Írás két olvasás között non repeatable read r1(x) w2(x) r1(x) Írás két olvasás között phantom read 24/39 r1(x) w2(x) r1(x)
Anomáliák (2) Lost update Elveszett frissítés A=50 1. 2. BEGIN READ(A) w1(x) w2(x) A=50 3. READ(A) A=70 4. A:= A + 20 A=80 A=70 A=80 A 100 5. 6. 7. 8. A:= A + 30 WRITE(A) WRITE(A) END 25/39
Anomáliák (3) Dirty read Piszkos olvasás (ideiglenes frissítés) A=50 1. 2. BEGIN READ(A) w1(x) r2(x) w1(x) A=70 3. A:= A + 20 A=70 4. WRITE(A) A=70 5. READ(A) A=50 6. ROLLBACK(A) A=50 7. WRITE(A) A 70 8. END 26/39
Anomáliák (4) Non repeatable read Nem megismételhető olvasás A=30 1. 2. BEGIN READ(A) r1(x) w2(x) r1(x) B=20 3. READ(B) A=0 4. DELETE(A) A=50 5. SELECT(A+B) A 30 6. END 27/39
Anomáliák (5) Phantom read Fantom olvasás 1. BEGIN r1(x) w2(x) r1(x) S=300 2. SUM(WHERE) I=20 3. INSERT(WHERE) S=320 4. SUM(WHERE) S S 5. END 28/39
Izolációs szintek (1) NOLOCK Nem foglalja le a tranzakció által érintett objektumokat. A tranzakciók nem támogatottak, nincs tranzakció kezelés. 0. szint 29/39
Izolációs szintek (2) READ UNCOMMITED Piszkos, véglegesítés előtti adatok is olvashatók, átlapolt írás nem megengedett. 1. szint Olvasáskor mindig az aktuális (módosított) értéket kapjuk, még akkor is, ha az adott insert/update tranzakciót a kezdeményező nem commit-olta. A következő problémák léphetnek fel: Dirty reads, Non repeatable reads, Phantom reads. 30/39
Izolációs szintek (3) READ COMMITED Csak véglegesített, tiszta adatok olvashatók. 2. szint Olvasáskor mindig az adott rekord véglegesített értéket kapjuk. Ez az esetek 99%-ra használható, a tranzakcióink mindig csak olyan rekordokat olvasnak, amik véglegesítve vannak, azaz nincs nyitott tranzakció, ami dolgozna rajtuk. A baj ezzel az, hogy ha sokan írják és olvassák az adott rekordot vagy táblát akkor könnyen kialakulhat az a helyzet, hogy az olvasó tranzakciók arra várnak hogy az írás (pl egy nagy tábla update-je) befejeződjön. Ez a főleg a rekordokra vonatkozik így csak a dirty read-től véd, probléma lehet: Non repeatable reads, Phantom reads. 31/39
Izolációs szintek (4) REPEATABLE READ Teljesül az ismételhető olvasás, két olvasás között bővülhet a tábla. 3. szint 32/39 Ez annyival jobb a READ_COMMITTED-nél, hogy már a non-repeatable read hibát is képes kiszűrni a tranzakcióból. Egyszerűbben: csak a rekordok véglegesített értékeit használja, és a rekordok tranzakció közbeni törlése nem befolyásolja a selecteket. Ebben az esetben csak egy probléma marad: Phantom reads
Izolációs szintek (5) SERIALIZABLE A teljesen soros végrehajtást kérvényezi, nincs elméleti izolációs szint (3. szint), mindennemű módosítás tiltott. Annyival több a REPEATABLE_READ-től, hogy más tranzakció nem írhatja felül a mi tranzakciónk által olvasott értékeket, azaz addig várakoztatja azokat míg be nem fejeződik a tranzakciónk. Így nem fognak tranzakció közben fantom sorok keletkezni a táblában. Itt elég problémás lehet, ha több résztvevő folyamatosan olvas egy táblát, amíg az updatelő szál várakozik, mert a tábla lock-olva van és nem tud bele írni 33/39
Zárolás Az egyik legismertebb és leginkább elterjedt tranzakció kezelési módszer. A tranzakció rátelepszik, lefoglalja az objektumot arra az időre, amíg használni szeretné. A zárolás hatására a többi tranzakció korlátozva van az objektum elérésében, ezért rendszerint várakozásra kényszerülnek. A várakozás akkor vagy oldódik fel, ha újra elérhető már az objektum. 34/39
Zárolás (2) A zárolás nem akadályozza az adatok olvasását, csak a mások által való módosítást Nyilván kell tartani objektumonként kiegészítő információkat: Szabad-e, Ki foglalja (felszabadításnál tudni kell) Nő a holtpont esélye Helytöbblettel jár a zárolás 35/39
Zárolási szintek Tábla szintű Dolgozó Rekord szintű A3 Kovács B 14 S1 Mező szintű A3 Kovács B 14 S1 36/39
A zárolások finomsága A különböző adatbázis-kezelők eltérnek abban, hogy milyen fajta adattételek zárolását teszik lehetővé. Van amelyik mezők, van amelyik rekordok, és van amelyik teljes relációk zárolását megengedi. Minél nagyobb a zárolt objektum, annál nagyobb az esélye annak, hogy egy tranzakciónak egy másikra kell várnia, még akkor is, ha a két tranzakció ténylegesen nem ugyanazt az adatelemet szeretné elérni. Viszont minél kisebb a zárolható adattétel, annál terjedelmesebb és bonyolultabb a zárolást kezelő mechanizmus. 37/39
Előnyök és hátrányok Előny Hátrány Mező szintű zárolás Nagyobb fokú párhuzamosság Jelentősebb konkurencia Sokkal több kiegészítő információt kell tárolni és karbantartani Jelentős hely, idő és költségnövekedés Tábla szintű zárolás Sokkal egyszerűbb nyilvántartani Gyorsabban adminisztrálható Nagyon lecsökkenti a konkurenciát Nagyon sokáig kell várakozni a párhuzamosan futó tranzakcióknak egymásra 38/39
VÉGE V É G E 39/39