Transakce = programová jednotka, která: - zachovává konzistenci databáze - končí v konečném čase - se provede celá nebo vůbec Architektura SW pro transakční zpracování se skládá ze 3 modulů: - manažer dat - rozvrhovač - manažer transakcí Systém pro zpracování transakcí (SZT) Program transakce má: - zahájení - posloupnost akcí pracujících s obsahem databáze - ukončení (návrat = ROLLBACK / potvrzení = COMMIT) read-only transakce - nemění obsah databáze aktualizační transakce - mění obsah databáze
Transakce se může dostat do jednoho z pěti stavů: A - aktivní - stav od počátku provádění transakce, PC - částečně potvrzený - stav po provedení poslední operace transakce, F - chybný - v normálním průběhu transakce nelze pokračovat, AB - zrušený - po skončení operace ROLLBACK, C - potvrzený - po úspěšném potvrzení COMMIT. Transakce ve stavech AB nebo C označujeme jako ukončené. Vlastnosti ACID: Atomicity (atomicita) - transakce se tváří jako jeden celek, musí buď proběhnout celá nebo vůbec ne, Consistency (konzistence) - transakce transformuje databázi z jednoho konzistentního stavu do jiného konsistentního stavu, Independence/Isolation (nezávislost) - transakce jsou nezávislé, dílčí efekty transakce nejsou viditelné jiným transakcím, Durability (trvanlivost) - efekty úspěšně ukončené (potvrzené) transakce jsou uloženy do databáze.
Transakční model je charakterizován: strukturou objektů strukturou transakce Struktura objektů: jednoduché objekty, objekty jako instance abstraktních datových typů (ADT), složité objekty (objekty objektově orientovaných DBS), aktivní objekty. Struktura transakce: ploché transakce, - jednoduché body startu a ukončení, kritérium uspořádatelnosti uzavřené hnízděné transakce, - odpovídá distribuovaným systémům otevřené hnízděné transakce - sága, vnější úroveň nepodporuje atomicita pracovní toky - moderní přístup
Operace v transakcích: READ(X,x) - přiřazuje hodnotu atributu X lokální proměnné x. WRITE(X,x) - přiřazuje hodnotu lokální proměnné x atributu X ve vyrovnávací paměti. Paralelní zpracování v transakcích: - pořadí operací z transakcí = rozvrh Možné problémy paralelního zpracování: lost update T2: READ(X) T1: WRITE(X) T2: WRITE(X) dirty read T2: WRITE(X) T1: READ(X) T2: WRITE(X) Phantom problem - pro stejný dotaz se vrátí různý výsledek
Sériové rozvrhy: - pro N transakcí je N! různých sériových rozvrhů - sériový rozvrh korektních transakcí vede ke konzistentnímu stavu O rozvrhu říkáme, že je uspořádatelný, jestliže existuje sériový rozvrh s ním ekvivalentní (resp. že je rozvrh serializovatelný). Ekvivalence založená na komutativitě dvou operací vede na dělení: konfliktní dvojice operací kompatibilní dvojice operací Dva rozvrhy jsou ekvivalentní, pokud jsou všechny konfliktní operace (nepřerušených) transakcí provedeny v témž pořadí (pořadí kompatibilních operací není důležité). Neserializovatelné rozvrhy: - mohou být také upořádatelné - vychází se z precedenčního grafu rozvrhu Rozvrh je uspořádatelný, jestliže v jeho precedenčním grafu neexistuje cyklus.
Uzamykací protokoly: - protokol = soustava pravidel zaručujících uspořádatelnost rozvrhu Zamykání a odmykání může být: dynamické - průběžné, jak to transakce vyžaduje statické - zamčení na začátku transakce, odemknutí na konci Zamykání - operace LOCK - akce, kterou vyvolá transakce na objektu, aby ho ochránila před přístupem ostatních transakcí. Odemčení - operace UNLOCK - akce, kterou vyvolá transakce na objektu, aby povolila přístup ostatních transakcí. Legální rozvrh musí splňovat následující podmínky: objekt bude nutné mít v transakci uzamknutý, kdykoliv k němu chce tato transakce přistupovat, transakce se nebudou pokoušet uzamknout objekt již uzamknutý jinou. Nelegální rozvrh je pak takový, který není legální.
Uváznutí (deadlock): - dvě transakce se blokují, neboť první transakce čeká na uvolnění objektu, který uzamkla druhá transakce a naopak. Dobře formulované transakce - splňují tyto požadavky: transakce zamyká objekt, chce-li k němu přistupovat, transakce nezamyká objekt, když je již touto transakcí uzamčený, transakce neodmyká objekt, který není touto transakcí uzamčený, po ukončení transakce všechny objekty, které byly touto transakcí uzamčeny, jsou odemknuty. Dvoufázové protokoly: 1. fáze: transakce uzamyká vše co bude potřebovat 2. fáze: transakce postupně odemyká objekty, které zamkla Jestliže všechny transakce v dané množině transakcí T jsou dobře formované a dvoufázové, pak každý jejich legální rozvrh je uspořádatelný. Protokol, ve kterém je každá transakce dvoufázová, se nazývá dvoufázový uzamykací protokol.
Dvoufázové protokoly: - zaručuje uspořádatelnost - nezaručuje absenci uváznutí - nepředchází problému kaskádového rušení transakcí (striktní dvoufázový protokol - odemyká zámky až po potvrzení COMMIT transakce) - nejvýše jedna transakce uzamyká jeden objekt (sdílené a výlučné zámky) Výlučný zámek - může být aplikován na objekty pro operace READ i WRITE. Sdílený zámek - uzamyká objekty, které chceme pouze číst (operace READ). Protokol pro používaní těchto zámků obsahuje následující pravidla: transakce nezamyká objekt sdíleným ani výlučným zámkem, když je již touto transakcí uzamčený, transakce nikdy neodmyká objekt, který není touto transakcí uzamčený, po ukončení transakce všechny objekty, které byly touto transakci uzamčeny, jsou odemknuty, před každou operací READ(X) musí být použito R_LOCK(X) nebo W_LOCK(X), před každou operací WRITE(X) musí být použito W_LOCK(X).
Protokoly, které nejsou dvoufázové: a) Stromové protokoly V stromovém protokolu může každá transakce T používat zámky s následujícími pravidly: První W_LOCK(X) transakce T lze použít na jakémkoli objektu X. Další objekt může být uzamčen transakcí T pouze když předchůdce byl v transakci T uzamčen. Objekty mohou být odemknuty kdykoliv. Prvek, který byl transakcí T zamknut a odemknut nemůže být následně znovu zamknut v transakci T. Všechny rozvrhy, které jsou legální pod stromovým uzamykacím protokolem jsou uspořádatelné. Na rozdíl od dvoufázových protokolů zde nedochází k uváznutí. b) B-stromy - speciální případ a)
c) Časová razítka Metodou pro určení uspořádatelnosti, která nezamyká objekty. Používá tři typy časových razítek: časové razítko transakce - je jí přiděleno, když je vyvolána, jde o jednoznačný identifikátor realizovaný, operaci přidělující transakci razítko budeme označovat TS. časové razítko pro zápis objektu X - označuje pro objekt X největší časové razítko transakce, která úspěšně provedla operaci WRITE(X), časové razítko pro čtení objektu X - označuje pro objekt X největší časové razítko transakce, která úspěšně provedla operaci READ(X) Poslední dvě časová razítka jsou aktualizována, kdykoliv dojde k přístupu k X. Odpovídající operace, které tato razítka přidělují, označujeme TSW, resp. TSR.
Protokol uspořádání podle časových razítek pracuje podle následující strategie: 1. Transakce T volá operaci WRITE(X). a) if TSR(X) > TS(T) then zruš T a ROLLBACK(T); b) if TSW(X) > TS(T) then zruš operaci WRITE(X) a pokračuj; c) if nenastává a), b) then begin WRITE(X); TSW(X):=TS(T) end 2. Transakce T volá operaci READ(X). a) if TSW(X) > TS(T) then zruš T a ROLLBACK(T); b) if TSW(X) < TS(T) then begin READ(X); TSR(X):= max(ts(t),tsr(x)) end Řízení paralelismu s více verzemi: - dosahuje menšího množství rušených transakcí - obtížnější implementace - větší prostorová náročnost
d) Optimistické algoritmy Nevýhody uzamykacích algoritmů: údržba zámků představuje zbytečnou režii pro transakce typu read-only, neexistují žádné uzamykací algoritmy, zabezpečující vysoký stupeň paralelismu ve všech případech, uzamykaní velké části databáze obsahující často přistupované objekty vede k snižování stupně paralelismu, v praxi hojně využívané uvolňování zámků na konci transakce snižuje stupeň paralelismu. Postup metody optimistických algoritmů: - všechny aktualizace se provádějí do kopií objektů ve vnitřní paměti, - před koncem transakce se provede kontrola na narušení uspořádatelnosti, - dle výsledku kontroly se transakce potvrdí a změny se promítnou do databáze, nebo se transakce zruší. Základním předpokladem pro úspěch této strategie, spočívá v tom, že očekáváme malou interferenci transakcí.
Porovnání přístupů k řízení paralelismu: Míra vhodnosti protokolu je charakterizována tím: kolik zámků je na objektech databáze, jak dlouho trvá uzamčení objektů. Porovnat dvoufázový protokol se stromovým je obtížné: ve stromovém protokolu se uzamyká více objektů než jich bude skutečně použito (dáno kořenem podstromu) naopak u dvoufázového protokolu je nevýhodou to, že objekt je obecně uzamčen déle. u dvoufázového protokolu navíc může nastat uváznutí, u stromového nikoliv. První zákon řízení paralelismu: Současné vykonávání transakcí nesmí zapříčinit selhání programu. Druhý zákon řízení paralelismu: Metoda řízení paralelismu při současném vykonávání transakcí nesmí vést k nižší průchodnosti systému oproti sériovému vykonávání transakcí.
Transakce v paralelních a distribuovaných systémech: paralelní architektura - více CPU fyzicky spojených do kompaktního celku, distribuované architektury - CPU obvykle odděleny geograficky. Transakce vyvolaná v jednom uzlu je rozdělena na podtransakce, prováděné v dalších uzlech. Koordinace - zaručení globální atomicity a globální trvanlivosti (viz. ACID). Protokoly: předpokládaný ABORT předpokládaný COMMIT
Zotavení z chyb: globální: - spadnutí systému - ztráta vnitřní paměti - systémové chyby - ovlivní transakce - chyby médií - ohrozí celou databázi lokální: - měli by být ošetřeny na úrovni transakcí Zotavení z chyby systému: - synchronizační body - kontrolní body - žurnál - strategie: odkládaná aktualizace - < T, jméno_atributu, nová_hodnota > - REDO(T) bezprostřední aktualizace - < T, jméno_atributu, stará_hodnota, nová_hodnota >
Zotavení z médií: - obnova ze záložní kopie (Backup) - záložní kopie minimálně v jedné kopii např. jednou denně - záloha žurnálu častěji (je menší) Měření výkonu transakčního provozu: - testy výkonu (benchmark) nebo garance vlastností ACID TPC-A: - nejvýznamnější test výkonu Jméno tabulky Počet řádků Velikost řádku Primární klíč Účet 10.000.000 100 Bytes Číslo_účtu Pokladna 1000 100 Bytes ID_pokladny Pobočka 100 100 Bytes ID_pobočky Historie proměnný 50 Bytes (Číslo_účtu, Časové_razítko) Kritérium pro dobu odezvy u TPC-A: odezva není větší než 2s u 90% uživatelů TPC-B, TPC-C, TPC-D,... Wiskonsin benchmark, CITY benchmark,...