No title

Adatbázis rendszerek II. VII-VIII. előadás – Tranzakció-kezelés Előadó: Barabás Péter Dátum: 2008. 11. 13./2008.11.20.

Osztott erőforrások OS

DB

Tranzakció-kezelés

2

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ősforrás igény) megoldások: várakoztatás várakozó sorok (nyomtató) adatbázis-kezelésben egyedi vonások


3

ACID elvek Atomicity Consistency Isolation Durability Tranzakció-kezelés

4

Atomiság 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, illetve hibához, ellentmondáshoz vezethetnek pl. készpénzfelvétel automatából

◦ pinkód beírásellenőrzésművelet megadáskészpénz beállításhitelkeret ellenőrzéskészpénz levétele a számlárólpénz kiadásakártya kiadásabizonylat kiadása

a DBMS-nek képesnek kell lennie műveletek visszagörgetésre félig elvégzett műveletsor nem maradhat a rsz-ben


5

Konzisztencia minden felhasználó számára konzisztens kell legyen konzisztens állapotból konzisztens állapotba vigyen integritás őrzés pl. törléskor archiválás

kiváltó esemény választevékenység

gond: nem hajtódik végre a választevékenység

triggerarchív táblába beszúrás a rekord kitörlődik, de nem archiválódik nem megengedhető

integritás sértő műveletek megakadályozása

pl. életkor mezőbe 3012 kerül


6

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ügg, nem az egyéb tevékenységektől


7

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 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


8

Tranzakciókezelés az adatbázis-kezelés központi fogalma minden művelet tranzakcióba szervezetten hajtódik végre a DBMS nem enged tranzakción kívüli művelet végrehajtást

login

DML

logout commit

begin transaction … INSERT... … DELETE... … UPDATE... … end transaction

abort


9

Tranzakció fogalma

Tranzakció: egy logikailag összetartozó, egységként kezelt műveletsor, melyre teljesülnek az ACID elvekben megfogalmazott követelmények


10

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 Tranzakció-kezelés

11

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

nem minden gráf létező tranzakciót jelent 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


12

Tranzakciók ábrázolása II. r(x)

w(x)

w(x) 3 c

w’(x) 6 w(x) w’(x) w’(x) w(x)

w’(x) 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 Tranzakció-kezelés

13

Tranzakciók ábrázolása III. r(x)

w(x)

r(y)

c

r(x)

?

r(y)

w(x)

?

w(y)

w(y)

eredmény ugyanaz 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 Tranzakció-kezelés

14

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

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 Tranzakció-kezelés

15

Tranzakció formális leírása T = (Te,→) Te = { r(x), w(x’), a, c | x,x’ ∈ DB } → ⊆ Te × Te

ahol DB az adatbázisbeli objektumok halmaza T tranzakcióra teljesülnek: - a∈ Te ⇔ c∉ Te -∀p∈ Te⇒ p→ a, ha a∈ Te és p→ c, ha c∈ Te -∀p1,p2∈ Te, p1 és p2 konfliktusban áll ⇒ p1 → p2 vagy p2 → p1 Tranzakció-kezelés

16

Tranzakciók ekvivalenciája ugyanazon elemeket tartalmazza a konfliktusban álló műveletek között ugyanolyan a megelőzési sorrend ⇒ ugyanazon kiinduló állapotból, ugyanazon műveletek az eredmény szempontjából ekvivalens sorrendben hajtódnak végre


17

History fogalma 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 Tranzakció-kezelés

18

History példa

r1(x)

w1(x)

c1

r2(x)

w2(x)


a2

19

History formális leírása H = (He,→) He a history-hoz tartozó műveletek, → a megelőzési reláció, azaz He = ∪ Te

→ ⊇ ∪ →T és teljesül az alábbi feltétel ∀p1,p2∈ H, p1 és p2 konfliktusban áll ⇒ p1 → p2 vagy p2 → p1 Tranzakció-kezelés

20

Hibás history gráf r1(x)

w1(x)

c1

r2(x)

w2(x)

w2(y)

c2

r3(y)

w3(x)

w3(y)

c3

Kérdés: mi a hiba? Tranzakció-kezelés

21

History--k ekvivalenciája History

azonos feltételekből kiindulva azonos eredményt szolgáltatnak a konfliktusban álló műveletpárok sorrendje lényeges csak az elfogadott tranzakciók hatása marad meg ekvivalensek a history-k, ha ◦ azonos tranzakciókat tartalmaz ◦ minden nem abortált tranzakcióhoz tartozó, konfliktusban álló műveletek között ugyanolyan irányú megelőzési reláció áll fenn Tranzakció-kezelés

22

History típusok követelmények: ACID elvek nem mindegyik teljesíti az elveket

w1(x)

r1(y)

w1(y)

r2(x)

w2(x)

c2

a1

Mi okozza problémát? • létezik lezárásuk • a lezárás az utolsó művelet • minden konfliktus esetén létezik megelőzési reláció Tranzakció-kezelés

23

Megoldás

w1(x)

r1(y)

w1(y)

r2(x)

w2(x)

c2

a1

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 a 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 tartósság elvét kellene felrúgni

◦ konzisztencia vs. ACID-elvek Tranzakció-kezelés

24

RecoverAble history

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)

r2(x)

w2(x)

w1(y)

a1

c2


25

RA history II.

teljesül az RA history, mégis hibás az alábbi history w1(x)

r1(y)

w1(y)

r2(x)

w2(x)

…

r3(x)

w3(x)

r4(x)

a1

…

abortálási lavina! ◦ T2 olyan adatot olvasott, melyek helyessége még nem dőlt el Tranzakció-kezelés

26

Avoiding Cascadeless Abort history

Az abortálási lavinát elkerülő history-ban minden tranzakció csak már lezárt tranzakcióból olvas. ◦ T2 csak olyan adatokat olvashat, melyek helyessége már biztosított, vagyis csak a T1 által véglegesített adatokat szabad felhasználni

w1(x)

r1(y)

w1(y)

a1

r2(x)

w2(x)

…

r3(x) Tranzakció-kezelés

w3(x) 27

ACA history II.

mind az RA, mind az ACA kritériumai teljesülnek, mégis akad probléma r1(x)

probléma:

w1(x)

w1(z)

a1

r2(z)

w2(x)

a2

◦ előbb T1, majd T2 módosítja x-et, végén abortálódik mindkettő ◦ vissza kell állítani a módosítások előtti értékeket előbb a w1(x) előtti értéket, majd w2(x) előttit induló érték visszaírásához ki kell előbb olvasni (implicite) írás előtt Tranzakció-kezelés

28

STrict history

A szigorú history-ban egy tranzakció csak akkor írhat vagy olvashat egy adatelemet, ha az azt előtte módosító másik tranzakció már lezáródott ◦ T2 tranzakció csak olyan adatokat olvashat vagy írhat, melyet egy lezárt tranzakció módosított utoljára

r1(x)

w1(x)

w1(z)

a1

r2(z)

w2(x)


a2 29

Újabb probléma w1(x)

r1(x)

w3(x)

c3

r2(x)

c1

c2

w2(x)

r2(x)

T1: normál fizetés tranzakció T2: rendkívüli jutalmak tranzakció

200000 r1(x)

300000 250000

+100000

w1(x)

+50000 w2(x)

lost update T1 beli olvasás megelőzi T2 beli írást, T1 beli írás követi T2 beli olvasást Tranzakció-kezelés

30

SeRializable history A sorossal ekvivalens history-ban bármely két tranzakció minden konfliktusban álló műveletpárjai között, ahol a műveletek nem azonos tranzakcióhoz tartoznak, azonos a megelőzési reláció. a műveletek a tranzakciók szerinti sorrendben hajtódnak végre

r1(x)

w1(x)

r2(x)

a1

w2(x)

c2


31

Serial vagy soros history

A soros historyban egy tranzakció bármely két művelete közé nem ékelődik be egy másik tranzakció valamely művelete.

r1(x)

w1(x)

…

c1

w2(x)

…

c2


r3(x)

…

32

History--k kapcsolata History

ST

ACA

RA

SR

S

Cél: ST ∩ SR history Tranzakció-kezelés

33

Következmények kevés a megfelelő history lecsökkentik a párhuzamosságot, a konkurencia megvalósulási lehetőségeit teljesítmény korlátozás

ACID elvek

nagyobb konkurencia hatékonyabb rendszer


34

Izolációs problémák

konfliktusban álló műveletek keveré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)

w2(x)

w2(x)

r1(x)

◦ írás két olvasás között not repeatable read

r1(x)


35

Izolációs szintek • anarchia, mind a három hiba jelenség 0. szint felléphet 1. szint

2. szint

3. szint

• nincs átlapolt írás • első szint és nincs piszkos olvasás • második szint és ismételhető az olvasás Tranzakció-kezelés

36

SQL utasítások

SET TRANSACTION ISOLATION LEVEL szint; ◦ NOLOCK nem foglalja le a tranzakció által érintett objektumokat 0. szint

◦ READ UNCOMMITED piszkos, véglegesítés előtti adatokat is olvashatnak átlapolt írás nem megengedett = 1. szint

◦ READ COMMITED csak véglegesített, tiszta adatok olvashatók 2. szint

◦ REPEATABLE READ teljesül az ismételhető olvasás 3. szint két olvasás között bővülhet a tábla

◦ SERIALIZABLE a teljesen soros végrehajtást kérvényezi nincs elméleti izolációs szint (3. szint) minden nemű módosítás tiltott


37

Zárolási módszerek

a tranzakció használat idejére lefoglalja az objektumot a többi tranzakció korlátozva van az objektum elérésében várakozás ◦ várakozás feloldás: elérhető már az objektum kiderül, hogy nem érdemes várni

nyilván kell tartani objektumonként kiegészítő információkat: ◦ szabad-e, ◦ ki foglalja (felszabadításnál tudni kell)

helytöbblettel jár a zárolás Tranzakció-kezelés

38

Zárolási szintek Mező szintű zárolás Rekord szintű zárolás Tábla szintű zárolás Tranzakció-kezelés

39

Előnyök és hátrányok

Előny

Mező szintű zárolás

Tábla szintű zárolás

• nagyobb fokú párhuzamosság • jelentősebb konkurencia

• sokkal egyszerűbb nyilvántartani • gyorsabban adminisztrálható

Hátrány • sokkal több kiegészítő információt kell tárolni és karbantartani • jelentős hely, idő költségnövekedés

• nagyon lecsökkenti a konkurenciát • nagyon sokáig kell várakozni a párhuzamosan futó tranzakcióknak egymásra


40

Zárolási költségfüggvények a tranzakciók közötti konkurencia mértéke a párhuzamos hozzáférések valószínűségétől függ rekord szintű zárolások közelében minimális

d u rv a

f in o m

H o s s z ú tr a n z a k c ió k

d u rv a

f in o m R ö v id tra n z a k c ió k


41

Zárolási idő

Alapelv: csak addig zároljunk egy objektumot, ameddig szükséges ◦ lefoglalás: amikor szükség van rá ◦ felengedés: adatok véglegesítése után, tranzakció végén hiba: a művelet után azonnal felengednénk T2 olvas T1 által írt, nem véglegesített objektumot RA, ACA feltétel sérülne


42

Kétfázisú zárolás (2PL)

1. fázis: zárolások lefoglalása 2. fázis: zárolások felengedése a tranzakció végén Kétfázisú zárolás esetén a tranzakció végéig csak zárolások történhetnek, majd a tranzakció végén egyidejűleg történik a zárolások felengedése. Minden zárolási művelet megelőz minden feloldást. a legtöbb RDBMS-ben 2PL zárolás biztosítja az ACID-elveknek megfelelő history-k megvalósítását Tranzakció-kezelés

43

Mely műveletnél zároljunk?

ST és SR szabályok: ◦ a konkurens műveleteknek sorosan kell végrehajtódniuk, beleértve a tranzakciók lezárási utasításait ◦ írási műveletkor szükséges a zárolás RA követelmény sérülne w1(x)

r1(x)

lw(x)

w1(x)

◦ olvasáskor is szükséges lehet az olvasás lost update jelenség r1(x)

r2(x)

w1(x)

w2(x)

lr(x)

r1(x)

gyakorlatban kissé módosul a zárolás Tranzakció-kezelés

44

Zárolás típusok

normál zárolás: ◦ zárolás alatt más tranzakció nem olvashatja és/vagy írhatja a foglalt elemet

írási és olvasási zárolás: ◦ írási zárolás: más tranzakció se nem olvashatja, se nem írhatja az objektum értékét

◦ olvasási zárolás: csak a másik tranzakció általi értékmódosítást akadályozza meg Tranzakció-kezelés

45

Példa normál és kétfajta zárolásra r1(x) w3(x)

c3

w1(x)

r2(x)

c1 w2(x)

c2

Normál zárolás esetén: ◦ T2 lefoglalja x-et, az r1(x) már nem tud végrehajtódni ◦ r1(x) várja T2 befejeződését ◦ T2 írja x-et, majd véglegesítődik ◦ ekkor folytatódhat T1 futása írja x-et, amely a megnövelt érték

◦ elkerülhető a lost update jelenség Tranzakció-kezelés

46

Példa normál és kétfajta zárolásra II. r1(x) w3(x)

c3

w1(x)

r2(x)

c1 w2(x)

c2

Írási és olvasási zárolás esetén: ◦ ◦ ◦ ◦ ◦

T2 zárolja x-et olvasásra, az r1(x) olvashatja T1 zárolja x-et olvasásra w1(x) írásra zárolja az elemet T1 véglegesítődik, majd az írási zárolás megszűnik ekkor folytatódik T2 futása zárolja az elemet írja az r2(x) által kiolvasott értéket felhasználva

◦ a lost update jelenség még mindig fennáll Tranzakció-kezelés

47

Helyesen formált zárolás minden művelet előtt van egy zárolás minden zárolást követi annak művelet utáni felengedése

l1(x)

w1(x)

u1(x)


48

Helyes zárolás helyesen formált a zárolás minden művelet zárol van írási és olvasási zárolás 2PL teljesül, a tranzakció végén felengedve az objektumokat

Megjegyzés: gyakorlatban enyhítenek a szigoron a párhuzamosság miatt Tranzakció-kezelés

49

Zárolások felminősítése

a zárolás szintjének, szigorúságának megnövelése

lr1(x)

r1(x)

u1(x)

…

lw1(x)

w1(x)

u1(x)

nem 2PL más tranzakció megszerezheti az objektumot T1 előtt ◦ a T’ csak egyszer zárolhat, és ha írni is akar, akkor írásra kell zárolni lw1(x)

r1(x)

…

w1(x)


u1(x)

50

Zárolások felminősítése II.

Probléma: ◦ nem biztos, hogy a tranzakció tudja előre, hogy írni is fog ◦ nagyon lecsökkenti a párhuzamosság lehetőségét, mivel túl hamar lefogja kizárólagos használatra az x objektumot

Megoldás: ◦ a zárolást felengedés nélkül egy magasabb szintre kell vinni lr1(x)

r1(x)

…

lw1(x)

w1(x) Tranzakció-kezelés

u1(x) 51

Zárolások gyenge pontja a zárolások biztos megoldást nyújtanak a helyes history megvalósításra gyenge pont:

◦ tranzakciók várakozásra kényszerítése ◦ többen várakoznak körbevárakozás alakulhat ki végtelen várakozás lr2(x)

r2(x)

lr1(x)

r1(x)

DEADLOCK

?

w1(x)

w1(x)

várakozás

várakozás


52

Deadlock kezelése lefoglalás igénylés

X

T1

W

Y

T2

Z

egyik tranzakció sem tud továbblépni, mindkettő a végtelenségig várakozna Feloldási módszerek: ◦ Timeout módszer ◦ WFG gráf Tranzakció-kezelés

53

Timeout mechanizmus

a rendszer figyeli, mennyi ideig várakozott a tranzakció a zárolás feloldására ha a várakozási idő túllép egy megadott időhatárt, akkor a TM deadlock jelenségként értékeli, melyet fel kell oldani egyik megoldás: ◦ valamelyik tranzakció abortálása ◦ abortálandó tranzakció kiválasztására számos stratégia létezhet ~ OS memóriakezelés kérdés: mit preferálunk? eltöltött idő elvégzett módosítások még hátralévő idő Tranzakció-kezelés

54

Wait--For Graph Wait

a gráf elemei a futó tranzakciók a gráf élei irányítottak ◦ T1-ből mutut él T2-be, ha van olyan objektum, amit T2 lefoglalt és T1 is szeretne elérni, s T1 ezen objektum felszabadulására vár

deadlock jelentése a várakozások szintjén: ◦ nincs vége a várakozási láncnak, azaz nincs esély, hogy a várakozási lánc valamikor is megszűnjön

WFG gráfban: ◦ akkor van deadlock, ha a létezik körút ◦ amennyiben a gráf körútmentes, úgy a history végrehajtása során nem lépett fel deadlock Tranzakció-kezelés

55

WFG II. Körútmentes: T1

T2

T3

T1

T2

T3

Deadlock:


56

Felminősítésből adódó deadlock

lr1(x)

r1(x)

…

lw1(x)

w1(x)

u1(x)

lr2(x)

r2(x)

…

lw2(x)

w2(x)

u2(x)

olvasási zárolások futhatnak párhuzamosan két írási zárolás nem élhet egyidejűleg lw1(x)-nél T1 kénytelen várakozni ◦ T2 olvasásra fogta T1

lw2(x)-nél T2 kénytelen várakozni ◦ T1 olvasásra fogta T2

deadlock alakult ki Tranzakció-kezelés

57

Módosítási zárolás (update lock) lock) a fenti blokkolás elkerülése végett módosítási zárolás arra utal, hogy az adatot a tranzakció később módosítani szeretné egyidejűleg csak egy tranzakció módosíthat

◦ nem szabad megengedni, hogy más tranzakció is jelezze ez irányú szándékát

felminősítést viszont már csak módosítási zárolásból lehet engedélyezni, hogy ne legyen váratlan írási igény lu1(x)

r1(x)

…

lw1(x)

w1(x)

u1(x)

lu2(x)

r2(x)

…

lw2(x)

w2(x)

u2(x)


58

Kompatibilitási mátrix lr

lu

lw

lr

Igen

Igen

Nem

lu

Nem

Nem

Nem

lw

Nem

Nem

Nem


59

SGT (Serialization (Serialization Graph Testing) módszer

a history SR tulajdonságának ellenőrzésére szolgál ◦ a konfliktusban álló műveletekre vonatkozóan teljesül-e a soros végrehajtás ◦ az SR végrehajtás esetén bármely két tranzakció között csak egyféle megelőzési reláció érvényesül

az SG-gráf a history-hoz rendelhető, és a history SR voltának eldöntésére szolgál Tranzakció-kezelés

60

SG gráf

Az SG gráf, egy olyan gráfot jelöl, melynek ◦ elemei a history-ban futó, commit-tal véglegesített tranzakciók,

◦ élei irányítottak.

Akkor létezik él egy T1 csomópontból a T2 csomópontba mutatva, ◦ ha létezik olyan konfliktusban álló műveletpár, ◦ melynek egyik tagja T1-hez, a másik tagja T2-höz tartozik, ◦ s a T1 csomóponthoz tartozó művelet megelőzi a T2höz tartozó műveletet. Tranzakció-kezelés

61

SG gráf II.

két csomópont között két él is létezhet ◦ ellentétes irányításúak (T1T2, T2T1)

a gráfban nem vesznek részt az abortált tranzakciók SR history esetén a history linearizálható kapcsolatban álló tranzakciókból épül fel

◦ nem keverednek a különböző tranzakciókhoz tartozó műveletek (a konfliktusban álló műveletek esetén) Tranzakció-kezelés

62

SG gráf III.

A history akkor és csak akkor SR tulajdonságú, ha a hozzá tartozó SG gráf körútmentes. ◦ körút esetén a tranzakciók nem alkotnak lineáris láncot r1(x)

w1(y)

w1(y)

c1

r2(z)

w2(z)

r2(y)

w1(z)

c2

r3(x)

w3(x)

c3

r4(z)

w4(y)

a4

T3

T1


T2

63

Módosított SG gráf

régebbi, érdektelen tranzakciók kikerülnek a gráfból ◦ helytakarékossági okok ◦ élek kialakításához ismerni kell a tranzakció által elvégzett műveleteket ◦ minden tranzakciónál nyílván kell tartani, mely objektumot írta, ill. olvasta

a felhasznált SG gráf tartalmaz még le nem zárt, még futó tranzakciókat is ◦ ciklikusság időbeni felfedezése ◦ kevesebb idő és erőforrás pazarlás történik egy tranzakció korábban történő abortálása révén Tranzakció-kezelés

64

SGT mechanizmus 1.

2. 3. 4. 5. 6. 7. 8.

új beérkező művelet esetén a TM ellenőrzi, hogy benn vane már a tranzakció az SG gráfban, vagy egy új tranzakcióról van szó új tranzakció esetén bekerül a gráfba, mint új csomópont ellenőrzésre kerül, hogy a művelet mely más korábban kiadott műveletekkel van konfliktusban minden érintett csomóponthoz él kerül az aktuális csomópontból kiindulva az új SG gráf tesztelése, hogy tartalmaz-e körutat ha igen, akkor az új művelet nem érvényesíthető, a tranzakcióját is vissza kell görgetni abortálódik a tranzakció és a gráfból is kikerül a hozzá tartozó élekkel ha nincs körút, akkor a művelet elvégezhető a korábbi műveletek sikeres nyugtázása után Tranzakció-kezelés

65

SGT csomópont törlése csak akkor, ha a jövőben nem válhat körút láncszemévé egy csomópontba bármikor mutathat új él

◦ későbbi műveletek konfliktusban állhatnak a korábbiakkal

körútban való részvétel kizárása: ◦ a csomópontból nem indul és nem is indulhat ki új él ◦ tranzakció lezárása után ilyen művelet már nem jöhet létre ◦ ha a tranzakció lezárásakor nem indul ki él, akkor a jövőben sem fog

Egy csomópont akkor törölhető az éleivel együtt: ◦ ha már lezáródott ◦ nem indul ki belőle él

Csomópont törlése több csomópont is törölhető Tranzakció-kezelés

66

Timestamp Ordering (TO)

minden tranzakcióhoz rendel egy időbélyeget, mely jelzi hogy mikor jött létre a tranzakció a többihez viszonyítva időbélyeg egy sorszám ◦ korábbi tranzakciók időbélyege kisebb ◦ későbbi tranzakcióké nagyobb

A különböző tranzakciókhoz tartozó, egymással konfliktusban álló műveletek esetén a műveletek végrehajtási sorrendje feleljen meg ◦ a tranzakciók időbélyeg sorrendjének. ◦ Vagyis azon műveleteknek kell előbb végrehajtódniuk, amelyek időbélyege kisebb. Tranzakció-kezelés

67

TO II.

amennyiben egy tranzakció olyan objektumot akar módosítani vagy olvasni, melyet egy fiatalabb tranzakció egyszer már módosított ◦ a műveletet a TM megakadályozza ◦ abortálja az idősebb tranzakciót ◦ abortálás után újraindítja a tranzakciót nagyobb időbélyeggel ◦ újra próbálkozhat Tranzakció-kezelés

68

Zárolás vs. TO

Zárolás ◦ lefoglalás felengedése után bármely tranzakció hozzáférhet az objektumhoz ◦ sokat várakoztat, deadlock léphet fel

TO ◦ nincs foglalási idő, az objektum bármikor elérhető ◦ csak az utolsó foglalást végző tranzakciónál fiatalabb tranzakciók férhetnek hozzá egy objektumhoz ◦ túlságosan könnyen kerülhet abortálásra egy tranzakció ◦ nincs benne várakoztatás súlyos hibák Tranzakció-kezelés

69

TO követelmények csak az utolsó hozzáférést végző tranzakció időbélyegét figyeli, nem a feldolgozottságot egy objektumon egyidejűleg csak egy művelet végezhető szükséges rendszerkomponens:

◦ egy művelet ne kezdődjön el addig, amíg a korábban engedélyezett kisebb sorszámú műveletek be nem fejeződnek ◦ műveletek késleltetése Tranzakció-kezelés

70

TO problámák

w1(x)

r1(y)

w1(y)

r2(x)

w2(x)

c2

a1

az x objektumot előbb T1 azután T2 kezeli az y objektumhoz csak T1 fér hozzá mindkét tranzakció lefuthat probléma ◦ T1 abortálása miatt r2(x) hamis értéket kap ◦ nem teljesül az RA history

módosítani kell az alap TO-n ◦ minden tranzakció csak már véglegesített adatokhoz férjen hozzá késleltetés Tranzakció-kezelés

71

STST-TO módszer olyan TO módszer, amely biztosítja a TO history-t egy műveletet addig kell késleltetni, amíg az objektumot utoljára módosító kisebb sorszámú tranzakció le nem záródik egyfajta zárolást kell alkalmazni


72

TO ütemezés működése

alapelem: ◦ tudjuk, mely tranzakció használta az egyes objektumokat utoljára

minden objektumhoz kell egy jelzőt társítani ◦ az objektumot utoljára kezelő tranzakció időbélyege

ezen jelző és az új igénnyel fellépő tranzakció időbélyegének összehasonlítása alapján dől el az objektumhoz való hozzáférés engedélyezése, vagy abortálása egy olvasási művelet csak egy írásival áll konfliktusban

◦ külön nyílván kell tartani mind az olvasásra, mind az írásra, mely időbélyegű tranzakció volt az utolsó engedélyezett művelet igénylője ◦ egy objektumhoz olvasási és írási jelzőt is csatolni kell Tranzakció-kezelés

73

Abortálások csökkentése a tranzakciók konkurenciájának csökkentésével oldható meg egyik javaslat: teljesen soros végrehajtás

◦ a TM létrehoz egy várakozósort a végrehajtásra jelentkező műveletek számára ◦ a várakozólistában minden futó tranzakciónak legyen pozíciója, bejegyzése ◦ a bejegyzett műveletek közül a legkisebb sorszámút veszi sorra

biztosítható az S history ◦ egy T tranzakció első művelete csak akkor kerülhet végrehajtásra, ha a rendszerben nem létezik tőle kisebb időbélyeggel rendelkező és még futó tranzakció ◦ ha viszont a tranzakció megkapta a vezérlést, akkor nem engedi el, míg ő maga be nem fejeződik, hiszen menet közben nem jöhet tőle kisebb sorszámú tranzakció


74

Optimista TO a TM megpróbálja kiküszöbölni a menetközbeni várakozásokat és a később feleslegesnek bizonyuló abortálásokat a műveleteket hagyjuk addig futni, amíg van esély a tranzakció megmaradására menetközben feltesszük, hogy a tranzakció sikeresen le fog futni ehhez módosítanunk kell az alap TO ütemezésen


75

Optimista TO II.

objektum  írási, olvasási TS jelző ◦ a jelzők a maximális értékű TS-t tartalmazzák

a tranzakciók nem közvetlenül a DB-t módosítják ◦ kapcsolódik hozzájuk egy egyedi munkaterület

az így letárolt módosítások egyszerre, a tr. végén kerülnek át az adatbázisba így a DB csak lezárt tranzakciók által módosított adatokat tartalmaz olvasás esetén:

◦ ha a tr. még nem módosította az objektumot, akkor az adatbázisból kell venni az értékét időbélyeg ellenőrzés, módosítás ha a TS(Tr)TS(Xw), elvégezhető a művelet Tranzakció-kezelés

76

Optimista TO III.

commit esetén: ◦ TM megpróbálja véglegesíteni a műveleteket ◦ sorba veszi a módosított objektumokat a saját munkaterületéről ◦ mindegyikre ellenőrzi, hogy a véglegesítés során nem sérül-e a TO-elv a DB-ben nagyobb írási v. olvasási jelző szerepel ekkor abortálni kell a tranzakciót

◦ sikeres ellenőrzés esetén a DB-beli objektumok is átíródnak az új értékekre ◦ az írási időbélyegek is aktualizálódnak

biztosítható az RA, ACA, ST history Tranzakció-kezelés

77

Lost update optimista TOTO-val r1(x)

c0

r2(x)

w1(x)

c1

w2(x)

c2

r2(x) beállítja x olvasás jelzőjét 2-re r1(x) engedélyezett, de nem módosítja az olvasásjelzőt w1(x) elvégzi a módosítást a saját munkaterületén c1 hatására megpróbálja véglegesíteni az adatokat ◦ x olvasásjelzőjében 2 szerepel ◦ az 1-es időbélyegű tranzakció akar módosítani ◦ abortálni kell az 1-es tranzakciót, majd újraindítani

w2(x) is elvégzi a módosítást a saját munkaterületén c2 hatására megpróbálja véglegesíteni az adatokat ◦ az olvasási jelző 2, az írási ennél is kisebb, engedélyezi a módosításokat ◦ az írási jelző is felveszi a 2-es értéket Tranzakció-kezelés

78

Oracle tranzakciótranzakció-kezelése alapvetően zároláson alapszik, de megtalálhatóak benne bizonyos TO elemek is csak írási zárolás létezik

◦ legnagyobb konkurencia biztosítása végett ◦ olvasási művelet sohasem gátol más műveletet ◦ olvasást bármikor végre lehet hajtani soha nem várakozik más műveletre más műveletek sem várakoznak miatta

az adatbázisban konzisztens adatok vannak ◦ csak a lezárt tranzakciók eredményeit tárolja ◦ olvasási műveletek mindig konzisztens képet adnak ◦ a módosítási utasítások egy közös munkaterületen kerülnek bejegyzésre, véglegesítéskor kerülnek bele a konzisztens adatbázisba Tranzakció-kezelés

79

Oracle tranzakciótranzakció-kezelése II.

a közös munkaterületen minden objektum csak egy példányban foglal helyet ◦ egyidejűleg csak egy tranzakció módosíthat egy objektumot

ST elvek betartása: ◦ addig nem enged egy objektumot módosítani, amíg az őt utoljára módosító tranzakció le nem záródik ◦ a TM a közös munkaterületen zárolja az objektumokat Tranzakció-kezelés

80

Oracle zárolás 2PL zárolás nincs olvasási zárolás

◦ konkurencia megnövekedése ◦ kisebb mértékű biztonság lost update jelenség fenáll

hosszú tranzakciónál nagy valószínűséggel megváltozik a konzisztens adatbázis képe ◦ más tranzakciók sikeresen lezáródtak ◦ hatásai láthatóvá váltak a többiek számára

bizonyos esetekben előnyös lenne a tranzakción belüli állandó tartalom olvasása ◦ tranzakció szintű olvasási-konzisztencia ◦ külön igényelni kell

létezik művelet szintű olvasási-konzisztencia (alapért.)


81

Oracle zárolás II.

SET TRANSACTION READ ONLY ◦ új tranzakció kezdődik ◦ tranzakció szintű olvasási-konzisztencia ◦ csak olvasási műveleteket enged

nagyobb erőforrás ráfordítás ◦ SCN mechanizmus


82

SCN mechanizmus

olvasási konzisztenciát igénylő végrehajtási egységhez feljegyzésre kerül ◦ mikor indult el ◦ a konzisztens képbe kerülő elemek, mikor kerületek a konzisztens DB-be

ezen időpontjelző az SCN (system change number) ◦ időbélyeg jellegű szerepe van

egy hosszabb tranzakció alatt több lezárt tranzakció is módosíthatta az érintett blokkot ◦ a blokknak több különböző SCN azonosítású példányt is nyílván kell tartani

lekérdezés során: ◦ az indulási SCN értéknek megfelelő SCN adatblokkokat fogja felhasználni Tranzakció-kezelés

83

SAVEPOINT sikertelenség esetén a tranzakciókat vissza kell görgetni az utolsó konzisztens állapotig hosszú tranzakciók nagy veszteség tranzakción belül definiálhatunk több savepoint-ot is:

◦ SAVEPOINT azonosító

a tranzakció a savepoint-ig is visszagörgethető ◦ ROLLBACK TO SAVEPOINT azonosító Tranzakció-kezelés

84

Megjegyzések a zárolásokhoz

DDL utasításoknál is figyelembe kell venni ◦ szerkezetmódosítás v. törlés csak teljesen szabad táblánál lehetséges ◦ a DDL utasítás csak a művelet idejére zárol

Példa: ◦ több különböző ugyanazt a táblát bővíti ◦ PRIMARY KEY szerepel a táblában ◦ azonos kulcs felvitele esetén az első megteheti a felvitelt a második várakozik az első sikerességére azután kap hibajelzést, miután az első befejeződött Tranzakció-kezelés

85

Recovery mechanizmus

az adatok konzisztens állapotba való visszaállítása tekintettel kell lenni ◦ a korábban elvégzett és lezárt műveletekre ◦ az éppen futó tranzakciókra

RM szükségessége: ◦ tranzakció abortálásakor visszagörgetés ◦ váratlan hibaesemény esetén újra felépítés rendszer összeomlás (közös munkaterület elvész) commit-tal lezárt adatmódosítások is elveszhetnek

◦ fizikai meghibásodás esetén helyreállítás Tranzakció-kezelés

86

Oracle recovery SGA DATA 1. 2.

1212 1435

ROLLBACK 3. 5.

1212 6.

REDO 4.

RS 1212 DS 1435

7.

COMMIT

8.

Adatbázis állomány

REDOLOG napló állomány Tranzakció-kezelés

87

Oracle recovery II. UPDATE auto SET ar=1435 WHERE rsz=‘RST345’; COMMIT;

Lépések: 1.

a rendszer megnézi, hogy a módosítandó objektum benne van-e a memóriában, ha nincs, akkor be kell hozni a megfelelő adatlapot ha benne van, akkor átírható a korábbi értéke az új értékre a módosítás elvégzése előtt az objektum korábbi értéke a ROLLBACK területre mentődik sor kerül a módosításra a memóriában az elvégzett tevékenységeket a rendszer naplózza a REDOLOG területen naplózás után COMMIT, véglegesítődik a tranzakció hatása

2. 3. 4. 5. 6. 1. 2.

7. 8.

a ROLLBACK szegmensbeli bejegyzések törlődnek a REDOLOG területre bekerül a COMMIT végrehajtása is

a naplóállományba kimentődik a REDOLOG tartalma az adatérték ezután íródik ki aszinkron módon Tranzakció-kezelés

88

Helyreállítás abortálás esetén

tranzakció abortálása esetén: ◦ a ROLLBACK szegmens aktuális tranzakcióhoz tartozó bejegyzéseinek végigolvasása ◦ az ott letárolt értékeket kell beírni az adatterület megfelelő objektumába ◦ ezután a ROLLBACK és a REDOLOG megfelelő bejegyzései törlődnek


89

Helyreállítás rendszerösszeomlás esetén

bonyolultabb a helyzet ◦ a REDOLOG-ban nemcsak lezárt tranzakcióra vonatkozó bejegyzések vannak ◦ később eldönthető melyek záródtak le tartalmaznak COMMIT bejegyzést is

◦ visszamentésnél gondolni kell a le nem zárult tranzakciók bejegyzéseire is


90

Helyreállítás rendszerösszeomlás esetén II. SGA DATA 2. 3.

1212 1435

4. 6.

ROLLBACK 7b. 1212 7a.

REDO 5.

RS 1212 DS 1435 COMMIT

8. 1. Adatbázis állomány

REDOLOG napló állomány Tranzakció-kezelés

91

Helyreállítás rendszerösszeomlás esetén III.

Lépések: 1. az Oracle sorba veszi azon műveleteket a REDOLOG-ból, melyek hatása még nem került át az adatbázis állományba 1. a naplóállományban minden pontosan le van tárolva, így visszajátszhatóak

2. ha a napló COMMIT-ot is tartalmaz, akkor a tranzakció újra véglegesítődik 3. ha nincs COMMIT, akkor egy ROLLBACK utasítással visszagörgetődik az újrajátszott műveletsor Tranzakció-kezelés

92

Helyreállítás sérülés esetén a REDOLOG segítségével újrajátszhatóak a tranzakciók nem lehet tetszőlegesen hosszú időre visszamenni a naplóállományban (kapacitása véges)

◦ az adatbázis tartalmat is rendszeresen menteni kell

ha nincs meg a kívánt rendszerállapot, a helyreállítás nem oldható meg Tranzakció-kezelés

93

Köszönöm a figyelmet!


94

No title

Recommend Documents