Download
1 / 69
E N D
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.
Tranzakcio adatbázis konzisztens (helyes) állapotban adatbázis konzisztens (helyes) állapotban
A tranzakció a konkurencia egysége; • A tranzakció a helyesség egysége; • A tranzakció a visszaállítás egysége.
Lekérdezés- feldolgozó Tranzakció- kezelő Napló- kezelő Puffer- kezelő Helyreállítás- kezelő Adat Napló
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
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.
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 Implicit - Explicit tranzakció
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)
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
Soros ütemezés Legyen T1 a következő tranzakció: BEGIN TRANSACTION X:= X – 10; Y:= Y + 10; COMMIT TRANSACTION T2 pedig: BEGIN TRANSACTION X:= X * 2; Y:= Y * 2; COMMIT TRANSACTION
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.
A T1, T2 soros ütemezésnek, egy nem sorba rendezhető ütemezése:
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:
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.
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.
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.
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.
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.
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)
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á
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).
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.
A holtpont megoldása • Módosítási zárak alkalmazása • Várakozási gráf (Wait-For-Graph) • Időkorlát mehanizmus
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.
Osztott(S), kizárólagos (X) és módosítási (U) zárak kompatibilitási mátrixa
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.
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.
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.
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.
