Tranzakciókezelés.

Az előadások a következő témára: "Tranzakciókezelés."— Előadás másolata:

1 Tranzakciókezelés

2 Tranzakció - az adatbázison végzett műveletek (parancsok) sorozata, mely az ABKR szempontjából egy egységet alkot, olyan értelemben, hogy vagy az egész tranzakciót végrehajtja, ha ez lehetséges, ha nem lehetséges, akkor egyáltalán semmi változtatást ne végezzen az adatbázison. Lehessen parancsra vagy automatikusan a tranzakciókból elvégzett operációkat visszapörgetni, az adatbázis egy helyes állapotát visszaállítani.

3 Tranzakcio adatbázis konzisztens (helyes) állapotban adatbázis konzisztens (helyes) állapotban

4 A tranzakció a konkurencia egysége;
A tranzakció a helyesség egysége; A tranzakció a visszaállítás egysége.

5 Adat Napló Tranzakció- kezelő Napló- Puffer- Helyreállítás-
Lekérdezés- feldolgozó Tranzakció- kezelő Napló- Puffer- Helyreállítás-

6 Adatbázis és tranzakció kölcsönhatása
Ennek a kölcsönhatásnak három fontos színhelye van: Az adatbázis elemeit tartalmazó lemezblokkok területe; A pufferkezelő által használt memóriaterület A tranzakció memóriaterülete

7 Alapműveletek INPUT (X): Az X adatbázis elemet tartalmazó lemezblokk másolása a pufferbe. READ (X, t): Az X adatbáziselem bemásolása a tranzakció t lokális változójába. Ha az X adatbáziselemet tartalmazó blokk nincs a pufferben, akkor előbb végre-hajtódik INPUT (X), azután kapja meg t a változó X értékét. WRITE (X, t): A t lokális változó tartalma az X adatbáziselem pufferbeli tartalmába másolódik. Ha az X adatbáziselemet tartalmazó blokk nincs a pufferben, akkor előbb végrehajtódik az INPUT (X), azután másolódik át a t lokális változó értéke a puffebeli X-be. OUTPUT (X): Az X adatbáziselemet tartalmazó puffer kimásolása lemezre.

8 Implicit - Explicit tranzakció
INSERT INTO Alkalmazottak VALUES (123454, ’Kovács Lehel’, 2, 500) UPDATE Alkalmazottak SET Fizetés = Fizetés * 1.2 CREATE TABLE Activities (ActivID int IDENTITY (1, 1) NOT NULL , TaskID int NOT NULL , CCPersonID int NULL , PlannedStartDate datetime, PlannedEndDate datetime, RealStartDate datetime, … ) Tranzakció kezdete: BEGIN TRANSACTION sikeres befejeződése: COMMIT TRANSACTION sikertelen befejezése: ROLLBACK TRANSACTION

9 Konkurenciavezérlés az elveszett módosítás (lost update) problémája
tranzakció, mely nem véglegesített adatokat olvas (uncommited dependency) helytelen analízis (inconsistent analysis)

10 Elveszett módosítás problémája

11 Elveszett módosítás példa1

12 Elveszett módosítás példa2

13 „piszkos adat olvasása”

14 Az inkonzisztens analízis problémája
BankSz1 = 40 BankSz2 = 50 BankSz3 = 30 A tranzakció összegzi 3 különböző bankszámlán levő összegeket; B tranzakció áttesz 10 egységet a 3-ik számláról az első bankszámlára

15

16 Soros és sorba rendezhető ütemezések

17 Soros ütemezés Legyen T1 a következő tranzakció: T2 pedig:
BEGIN TRANSACTION X:= X – 10; Y:= Y + 10; COMMIT TRANSACTION T2 pedig: X:= X * 2; Y:= Y * 2;

18 T1 tranzakció megelőzi T2-öt

19 T2 tranzakció előzi meg T1-et

20 Sorba rendezhető ütemezések
Egy tranzakció megőrzi az adatbázis helyességét. Egymás után, tehát soros ütemezéssel végrehajtott tranzakciók is megőrzik az adatbázis helyességét. A soros ütemezésen kívül, a sorba rendezhető (serializable schedule) ütemezés biztosítja még az adatbázis konzisztenciájának a megmaradását. Egy ütemezés sorba rendezhető, ha ugyanolyan hatással van az adatbázis állapotára, mint valamelyik soros ütemezés.

21 A T1, T2 soros ütemezésnek, egy sorba rendezhető ütemezése:

22 A T1, T2 soros ütemezésnek, egy nem sorba rendezhető ütemezése:

23 Konfliktusok Konkfliktus: olyan egymást követő műveletpár az ütemezésben, amelynek ha a sorrendjét felcseréljük, akkor legalább az egyik tranzakció viselkedése megváltozhat. Nem cserélhetjük fel a műveletek sorrendjét a következő esetekben:

24 Ugyanannak a tranzakciónak két művelete konfliktus, pl: ri(X); wi(Y)
Ugyanannak a tranzakciónak két művelete konfliktus, pl: ri(X); wi(Y) . Egy tranzación belül a műveletek sorrendje rögzített, az ABKR ezt a sorrendet nem rendezheti át. Különböző tranzaciók ugyanarra az adatbáziselemre vonatkozó írása konfliktus. Pl. wi(X); wj(X) . Ebben a sorrendben X értéke az marad, melyet Tj ír, fordított sorrendben pedig az marad, melyet Ti ír. Ezek az értékek pedig nagy valószínüséggel különbözőek.

25 Különböző tranzacióknak ugyanabból az adatbáziselemből való olvasása és írása konfliktus. Tehát ri(X); wj(X) konfliktus, mivel ha felcseréljük a sorrendet, akkor a Ti által olvasott X-beli érték az lesz, melyet a Tj ír és az nagy valószínűséggel nem egyezik meg az X korábbi értékével. Hasonlóan a wi(X); rj(X) is konfliktus.

26 A sorbarendezhetőség biztosítása zárakkal

27 Jelölések ri(X) - a Ti tranzakció olvassa az X adatbáziselemet (r - read) wi(X) - a Ti tranzakció írja az X adatbáziselemet (w -write) sli(X) - a Ti tranzakció osztott zárat kér az X-re xli(X) – a Ti tranzakció kizárólagos zárat kér az X-re ui(X) - a Ti tranzakció feloldja (unlock) X adatbáziselemen tartott zárát.

28 Kétfázisú lezárás tétel: Ha minden tranzakció betartja a kétfázisú lezárási protokollt, az összes lehetséges ütemezés sorbarendezhető. Kétfázisú lezárási protokoll: A zárolásoknak meg kell előzniük a zárak feloldását: Mielőtt egy tranzakció dolgozna egy objektummal, sikeresen le kell azt zárja; Miután felszabadított egy zárat a tranzakció nem kérhet más zárat.

29 A tranzakciók kérhetnek különböző zárakat, ha az ütemező nem tudja megadni a kért zárat a tranzakciók egy első-beérkezett-első-kiszolgálása (first-come-first-served) várási listába kerülnek, míg a szükséges adat felszabadul.

30 Azért, hogy a tranzakciók konzisztenciája megmaradjon, minden Ti tranzakció esetén bevezetjük a következő követelményeket: Az ri(X) olvasási műveletet meg kell előzze egy sli(X) vagy xli(X) úgy, hogy közben nincs ui(X) A wi(X) olvasási műveletet meg kell előzze egy xli(X) úgy, hogy közben nincs ui(X) Ha xli(X) szerepel egy ütemezésben, akkor ezután nem következhet xlj(X) vagy slj(X) valamely i-től különböző j-re anélkül, hogy közben ne szerepelne ui(X) Ha sli(X) szerepel egy ütemezésben, akkor ezután nem következhet xlj(X) i-től különböző j-re anélkül, hogy közben ne szerepelne ui(X)

31 upgrade lock to exclusive
Ha egy tranzakciónak már van osztott zára egy adatbáziselemen, melyet módosítani akar, felminősítheti a zárat kizárólagossá

32 lezárható az egész adatbázis, annak, akinek sikerült lezárnia könnyű dolga van a programozás szempontjából, de senki más nem férhet hozzá; lezárható egy rekord, általában ez a legkézenfekvőbb megoldás lezárható egy rekordcsoport (egy lemezblokkban lévő rekordok vagy fa szerkezetű indexnek megfelelő rekordcsoport).

33 Kompatibilitási mátrix

34 Elveszett módosítás problémája

35 Tranzakció, mely nem véglegesített adatokat olvas

36 Az inkonzisztens analízis problémája

37 Holtpont Holtpont, olyan állapot, mikor két vagy több tranzakció várási állapotban van, mindenik vár a másik által lezárt objektumra. A System R ABKR–el végzett kísérletek azt mutatták, hogy nem jelenik meg kettőnél több tranzakció holtpontban.

38 A holtpont megoldása Módosítási zárak alkalmazása
Várakozási gráf (Wait-For-Graph) Időkorlát mehanizmus

39 Módosítási zárak Az uli(X) módosítási zár (update lock) a Ti tranzakciónak csak X adatbáziselem olvasására ad jogot, az X írására nem, viszont csak a módosítási zárat lehet később felminősíteni, az olvasásit nem. Ha egy tranzakciónak szándékában áll módosítani az X adatbáziselemet, akkor módosítási zárat kér rá. Módosítási zárat engedélyez a rendszer az X-en akkor is, ha már van osztott zár X-en. Ha már van egy módosítási zár X-en, akkor viszont minden más zárat elutasít a rendszer, legyen az osztott, módosítási vagy kizárólagos.

40 Osztott(S), kizárólagos (X) és módosítási (U) zárak kompatibilitási mátrixa

41 Elveszett módosítás problémája

42 Elveszett módosítás probléma megoldva, 2-es tranzakció késleltetve van, míg 1-es felszabadítja a zárat. “Tranzakció, mely nem véglegesített adatokat olvas” probléma nem oldódik meg. A gond, hogy a zárat túl hamar felszabadítja, később visszatérünk erre a problémára. Az inkonzisztens analízis problémája sem oldódik meg. A gond nem ott van, hogy mind a két tranzakció ugyanazt az adatbáziselemet módosítja.

43 Várakozási gráf A gráf csúcsait a tranzakciók alkotják. (Legyen T1 tranzakció az egyik csúcsban és T2 tranzakció egy másikban.) T1 és T2 csúcs között élet rajzolunk, ha: T1 lezárva tartja az A adatbáziselemet. T2 kéri az A adatbáziselemet, hogy zárolhassa azt. Az él irányítása a T1-től a T2 felé lesz és A az él címkéje.

44 Ha a gráf tartalmaz ciklust, azt jelenti, hogy van holtpont.
Ebben az esetben valamelyik tranzakciót, mely a körben szerepel meg kell szakítani és visszapörgetni. A rendszer ki kell derítse, hogy holtpont probléma áll fenn. A tranzakciót megszakítani azt jelenti, hogy valamelyik tranzakciót kiválasztja, mely a holtpontban szerepel – ez az áldozat (victim) –– és visszapörgetni, így felszabadul a lock, amit ez a tranzakció adott ki, és lehetősége nyílik a többi tranzakciónak, hogy folytatódjon.

45 Időkorlát mehanizmus A gyakorlatban nincs minden rendszernek holtpont felfedező mehanizmusa, csak egy időtúllépés (timeout) mehanizmusa, mely feltételezi, ha egy adott idő intervallumban a tranzakció nem dolgozik semmit, azt jelenti, hogy holtponton van. Az áldozatban nem lesz semmi hiba, egy pár rendszer újraindítja a tranzakciót, feltételezve, hogy változtak a feltételek, melyek a holtpontot okozták. Más rendszer olyan hiba kódot ad vissza, hogy “deadlock victim” az applikációnak és a programozó kell megoldja a feladatot, indítsa újra a tranzakciót. Mindkét esetben ajánlatos tudatni a felhasználóval a történteket.

46 Példa

47 Példa várási gráfja

48

49 Inkonzisztens analízis problémája

50

51 Szigorú két-fázisú lezárási protokoll
1. Egy tranzakció nem írhat az adatbázisba, míg nem éri el a COMMIT pontját. 2. Egy tranzakció nem szabadíthatja fel a zárait, míg be nem fejezi az írást az adatbázisba, tehát a zárak felszabadítása is COMMIT pont után történik.

52 Tehát egy tranzakció, mely betartja a szigorú két-fázisú lezárási protokollt a következő sorrendben hajtja végre a munkát: betartja a két-fázisú lezárási protokollt mikor elérkezik a COMMIT ponthoz beírja az adatbázisba a módosított adatbáziselemeket; majd felszabadítja a zárakat.

53 “piszkos adat olvasása” megoldása

54 Tranzakciók az SQL-ben
A gyakorlatban általában nem lehet megkövetelni, hogy a műveletek egymás után legyenek végrehajtva, mivel túl sok van belőlük, ki kell használni a párhuzamosság által nyújtott lehetőségeket. Az ABKR-ek biztosítják a sorbarendezhetősé-get, a felhasználó úgy látja, mintha a műveletek végrehajtása sorban történt volna, valójában nem sorban történik.

55 Csak olvasó tranzakciók
Ha a tranzakció csak olvas és nem módosítja az adatbázis tartamát, közölhetjük ezt az ABKR-el és akkor optimálisabb ütemezést valósít meg. Az utasítás amivel ezt közölhetjük az ABKR-el: SET TRANSACTION READ ONLY;

56 Az elkülönítés szintjei SQL-ben

57 Nem ismételhető olvasás
Nem ismételhető olvasás (Unrepeteable read) akkor fordul elő, ha a tranzakciók párhuzamosan futnak, A tranzakció beolvas egy adatbáziselemet, időközben B tranzakció módosítja ugyanazt az adatbáziselemet, majd A tranzakció ismét beolvassa ugyanazt az adatbáziselemet, tehát A tranzakció “ugyanazt” az adatbáziselemet olvasta kétszer és két különböző értéket látott.

58 elmélet - gyakorlat Az elmélet szerint a sorba rendezhető elkülönítési szint a biztos, hogy semmilyen konkurencia probléma nem merül fel., vagyis a tranzakció úgy fut le, mintha minden más tranzakció teljes egészében vagy előtte vagy utána ment volna végbe. A gyakorlatban viszont megengednek nagyobb interferenciát a tranzakciók között.

59 Nem ismételhető olvasás

60 Fantomok A rendszer csak létező adatbáziselemeket tud zárolni, nem könnyű olyan elemeket zárolni, melye nem léteznek, de később beszúrhatók. T1 olvassa azon sorok halmazát, melyek adott feltételnek eleget tesznek, T2 új sort illeszt a táblába, mely kielégíti a feltételt, így a T1 eredménye helytelen.

61 Fantom T1: SELECT AVG(Atlag) FROM Diakok WHERE CsopKod = ‘531’
megismétli a kérést fantom-ot lát T2 beszúr egy új diákot a Diakok táblába

62 Fantom Ez valójában nem konkurencia probléma, ugyanis a (T1, T2) soros sorrend ekvivalens azzal ami történt. Tehát van egy fantom sor a Diakok táblában, melyet zárolni kellett volna, de mivel még nem létezett nem lehetett zárolni. A megoldás, hogy sorok beszúrását és törlését az egész relációra vonatkozó írásnak kell tekinteni és X zárat kell kérni az egész relációra, ezt nem kaphatja meg, csak ha a minden más zár fel van szabadítva, a példa esetén a T1 befejezése után. Egy más megoldás arra, hogy a rendszer megelőzze a fantom megjelenését: le kell zárjnia a hozzáférési utat (Acces Path), mely a feltételnek eleget tevő adathoz vezet

63 mit tehet a felhasználó?
Az izolálási szintet a tranzakciók esetén a felhasználó beállíthatja a: SET TRANZACTION ISOLATION LEVEL TO <elkülönítési szint> a felhasználó nem ad semmi zárolást, rábízza a rendszerre.

64 Elkülönítési szintek közötti relációk
a > erősebb feltételt jelent, akkor az elkülönítés szintjei között fennállnak a következő relációk: SERIALIZABLE > REPEATEBLE READ > > READ COMMITED > READ UNCOMMITED

65 Ha minden tranzakciónak SERIALIZABLE az elkülőnítés szintje, akkor több tranzakció párhuzamos végrehajtása esetén a rendszer garantálja, hogy az ütemezés sorbarendezhető. Ha egy ennél kisebb elszigeteltségi szinten fut egy tranzakció a sorbarendezhetőség meg van sértve.

66 SERIALIZABLE a tranzakció betartja a szigorú kétfázisú lezárási protokollt, lezárást alkalmaz, írás és olvasás előtt, tranzakció végéig tartja, úgy az objektum halmazon (indexen) is (ne jelenjen meg fantom)

67 REPEATABLE READ serializable –től abban különbözik, hogy indexet nem zárol – csak egyedi objektumokat, nem objektum halmazokat is. Olvasás előtt SLOCK, írás előtt XLOCK, tranzakció végéig tartja.

68 READ COMMITED – implicit – nem enged meg az adatbázisból visszatéríteni olyan adatot, mely nincs véglegesítve (uncommited) (dirty read nem fordulhat elő). Share lock –t kér olvasás előtt a tranzakcióban szereplő objektumokra, utána rögtön felengedi, XLOCK írás előtt, tartja tranzakció végéig.

69 READ UNCOMMITED share lock –t nem kér olvasás előtt, sem XLOCK –t írás esetén elolvashatja egy futó tranzakció által végzett változtatást, mely még nem volt véglegesítve ha valaki más közben kitörli az adatot, melyet olvasott, hibát sem jelez, vagy törli az egész táblát nem ajánlott egyetlen applikációnak sem esetleg, olyan statisztikai kimutatások esetén, ahol egy-két változtatás nem lényeges.