Transakční zpracování Bezpečnost databází. Vladimíra Zádová, KIN, EF TUL- DBS 1

Transkript

1 Transakční zpracování Bezpečnost databází Vladimíra Zádová, KIN, EF TUL- DBS 1

2 Transakce Transakce systém zpracování transakcí vlastnosti ACID stavy transakce SŘBD a transakční zpracování Řešení transakcí seriové rozvrhy paralelní zpracování transakcí Uzamykací protokoly - dvoufázový uzamykací protokol Zotavení z chyb Vladimíra Zádová, KIN, EF TUL- DBS 2

3 Transakční systémy transakční zpracování OLTP - On-line Transaction Processing aplikace ERP, zčásti CRM, SCM charakteristika relativně jednoduché operace, změny v malých objemech dat, více současně pracujících uživatelů požadavky rychlý a spolehlivý přístup k datům - mnohdy 24x7x365 nekonfliktní zpracování, data odpovídající realitě zotavení z chyb - po HW a SW chybě zajištění paralelního zpracování Vladimíra Zádová, KIN, EF TUL- DBS 3

4 Transakční zpracování Chyby v oblasti: hardwarové (poruchy v síti, zhroucení disku) softwarové (operační systém, uživatelský program) možné problémy: Při aktualizaci dochází k přechodu z jednoho přípustného stavu databáze do druhého přípustného stavu databáze (tedy musí být pro danou databázi dodržena všechna definovaná integritní omezení) Při výpadku systému databáze nemusí být konzistentní (nesplňuje všechna IO) nemusí být zřejmé, která data byla při výpadku právě v operační paměti (vyrovnávacích pamětech), t.j. která data se nedostala na disk a při výpadku byla ztracena Pokud nebude situace možného výpadku ošetřena - mohou být poskytovány nesprávné (nekonzistentní ) údaje Vladimíra Zádová, KIN, EF TUL- DBS 4

5 I. Transakce Transakce je akce či posloupnost akcí, se kterou se zachází jako s jedním celkem. Je to logická jednotka práce, ale též jednotka zotavení z chyb Akce: prováděny uživatelem nebo aplikačním programem(i část programu, jednotlivý příkaz) čtení, zápis, výpočet (aktualizační operace, SQL příkaz..) pomocí akcí se přistupuje k databázi( SELECT), nebo ji mění (INSERT, UPDATE, DELETE) Transakce mění stav databáze = transakce aktualizační transakce nemění stav databáze složené z dotazů Vladimíra Zádová, KIN, EF TUL- DBS 5

6 Transakce - požadavky zachování konzistence databáze po provedení všech operací dané transakce jako celku Během transakce (tedy při provedení dílčích operací ) může být konzistence databáze dočasně narušena ukončení v přijatelném čase transakce je atomická vše e nebo nic Vladimíra Zádová, KIN, EF TUL- DBS 6

7 Transakce Příklad : knihovna změna čísla čtenáře pak se tato změna bude týkat tabulky (relace) ČTENÁŘ, ale též VÝPUJČKY a REZERVACE Konzistentnost databáze nebude zajištěna jednou operací, ale jejich poslopností (zatímco je v přirozeném jazyce vyjádřená jednou větou) Provedeme li UPDATE v relaci ČTENÁŘ a VÝPUJČKY, pak není databáze v konzistentním stavu, protože nebyla provedena změna u relace REZERVACE. Vladimíra Zádová, KIN, EF TUL- DBS 7

8 Vlastnosti ACID a transakce A = (atomicity) atomicita transakce transakce je jeden celek - musí proběhnout celáči vůbec ne C = (Consistency) konzistence transakce transformuje databázi z jednoho konzistentního stavu databáze do jiného konzistentního stavu I = (Isolation) nezávislost transakce transakce jsou nezávislé, dílčí efekty transakce nejsou viditelné jiným transakcím (nezávislost požaduje aby transakce měla vždy konzistentní databázi t.j. výsledky transakce viditelné pro ostatní transakce až pro potvrzení) D =(Durability) trvanlivost (perzistence) úspěšně ukončené transakce (potvrzené) jsou uloženy do databáze Údržba atomicity transakce se nazývá zotavení z chyb vlastnosti ACID jsou základním principem transakčního zpracování Vladimíra Zádová, KIN, EF TUL- DBS 8

9 Zpracování transakcí Systém zpracování transakcí (SZT) obecně nemusí být součástí SŘBD, může patřit pod operační systém, nebo může být řešeno samostatným softwarem Vlastní architekturu softwaru pro transakční zpracování v databázových systémech lze popsat pomocí 3 modulů: manažer transakcí rozvrhovač manažer dat Aplikační program Manažer transakcí Rozvrhovač Manažer dat Databáze obr.: Architektura transakčního zpracování v DBS Vladimíra Zádová, KIN, EF TUL- DBS 9

10 Zpracování transakcí manažer dat komunikuje s databází pomocíčtení a zápisu dat zodpovídá za zotavení z chyb systému (zajištění atomicity vzhledem k chybám) rozvrhovač (sheduler) zodpovídá za řízení paralelního zpracování transakcí maximalizuje souběžnost zpracování transakcí aniž by se souběžně vykonávané transakce rušily je-li protokol souběžného zpracování (concurrency control)založen na uzamykání - pak se ještě odvolává na manažer uzamykání (lock manager) zajišťuje transparenci paralelního zpracování manažer transakcí zajišťuje komunikaci mezi prvními dvěma moduly koordinuje transakce v zájmu programu, vyvolává transakci a posílá požadavky na data manažeru dat prostřednictvím rozvrhovače Vladimíra Zádová, KIN, EF TUL- DBS 10

11 zabezpečení zotavení z chyb SŘBD - požadavky Pokud nebude provedena transakce do konce ( výpadek systému) nutnost vrátit databázi do stavu před započetím transakce zabezpečení korektního a rychlého přístupu více uživatelů požadavky realizovány pomocí komponent: komponenta zotavení z chyb (recovery) zajišťuje konzistentnost databáze (při chybě SW, systému, fyzického média) komponenta řízení paralelního zpracování (concurrency control) zajišťuje uživatelům vidění konzistentních stavů SŘBD - i když používá SŘBD více uživatelů tyto komponenty v modulu řízení databáze (viz moduly SŘBD -I. přednáška: vytváří rozhraní mezi daty a programy /dotazy, které vyžadují přístup do databáze, zajišťuje kontrolu dat po uživatelských transakcích, utajení dat, rekonstrukce databáze při chybách, řízení vícenásobného přístupu Vladimíra Zádová, KIN, EF TUL- DBS 11

12 5 stavů transakce aktivní (A) jde o stav od počátku provádění transakce částečně potvrzený (PC) stav po provedení poslední operace transakce chybný (F) pokud se objeví, že v normálním průběhu transakce nelze pokračovat zrušený (AB) nastane po skončení operace ROLLBACK (tedy po uvedení databáze do stavu před transakcí potvrzený (C) nastane po úspěšném zakončení, tj.po potvrzení operací COMMIT Vladimíra Zádová, KIN, EF TUL- DBS 12

13 Stavy transakce PC C A F AB Obr.: diagram stavů transakce Vladimíra Zádová, KIN, EF TUL- DBS 13

14 Stavy transakce transakce ukončena ve stavech AB, C ze stavu F po provedení operace ROLLBACK vstupuje do stavu AB ze stavu PC se může transakce dostat i do stavu F - např. díky výpadku systému nemusí se obsah vyrovnávacích pamětí odeslat na disk u stavu AB (zrušený) jsou 2 možnosti : restartovat transakci ponechat zrušenou transakci (tj. stav databáze bude jako před uskutečněním transakce) Klíčové místo práce s transakcemi je mezi stavem PC a C. Vladimíra Zádová, KIN, EF TUL- DBS 14

15 ROLLBACK a COMMIT COMMIT (=potvrzení) úspěšnost transakce : změny databáze jsou perzistentní, mohou se zviditelnit dalším transakcím po provedení příkazu operace nevratné V praxi ji není nutné explicitně vyvolávat, stačí normální ukončení programů, které realizují transakci (veškeré změny jsou permanentní) ROLLBACK (=ABORT) neúspěšnost transakce Databáze musí být vrácena do původního stavu. Použití Rollback vyžaduje existenci log file (žurnálu) Vladimíra Zádová, KIN, EF TUL- DBS 15

16 Zpracování transakcí Sériové zpracování transakcí transakce prováděny za sebou Paralelní zpracování transakcí se stejnou databází pracuje současně více uživatelů (resp. programů ) cílem je lépe využít spolupráce různých zařízení (př. procesor a periferie) transakce mohou být zpracovány paralelně různým způsobem rozvrhy a protokoly Vladimíra Zádová, KIN, EF TUL- DBS 16

17 Konzistence konzistence individuálních transakcí x konzistence databáze pod paralelním voláním transakcí konzistence individuálních transakcí je dána definicí transakce ( vše nebo nic) SZT (systém zpracování transakcí) ji považuje za konzistentní konzistence databáze pod paralelním voláním transakcí SZT používá vlastní kriteria korektnosti( protokoly) základní přístup uspořádatelnost rozvrhů jiná kriteria korektnosti Vladimíra Zádová, KIN, EF TUL- DBS 17

18 Problémy s paralelním zpracováním transakcí ztráta aktualizace (lost update problem) dočasná aktualizace ( the uncommitted dependency problem) nekorektní použití agregační funkce ( inconsistent analysis problem Vladimíra Zádová, KIN, EF TUL- DBS 18

19 Souběžné (paralelní) zpracování: Operace READ(). čtení WRITE () zápis do databáze př. Plat = plat * 1.3..nedatabázové operace - výpočet aktualizace tedy znamená: čtení z DB, výpočet, zápis do databáze pro SELECT - jen read operace BEGIN TRANSACTION. END TRANSACTION COMMIT, ROLLBACK Vladimíra Zádová, KIN, EF TUL- DBS 19

20 Ztráta aktualizace ČAS Transakce T 1 Transakce T 2 X t 1 t 2 t 3 t 4 t 5 t 6 begin transaction READ(x) x =x - 10 WRITE(x) COMMIT begin transaction READ(x) x =x WRITE(x) COMMIT Správný výsledek by měl být 190 Došlo ke ztrátě update transakce T 2 Vladimíra Zádová, KIN, EF TUL- DBS 20

21 dočasná aktualizace ( při chybě systému) ČAS Transakce T 1 Transakce T 2 X t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 begin transaction READ(x) x =x - 10 WRITE(x) COMMIT begin transaction READ(x) x =x WRITE(x)... ROLLBACK Správný výsledek: 90. Po chybě systému - aktualizace transakce T 2 je ztracena (vrací se zpět), toto ošetřeno není Vladimíra Zádová, KIN, EF TUL- DBS 21

22 nekorektní použití agregační funkce inconsistent analysis problem ČAS Transakce T 1 Transakce T 2 X Y Z SUM t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 t 9 t 10 t 11 begin transaction READ(x) x = x - 10 WRITE(x) READ(z) z = z + 10 WRITE(z) COMMIT begin transaction SUM = 0 READ(x) SUM = SUM + x READ(y) SUM = SUM + y READ(z) SUM = SUM + z COMMIT Vladimíra Zádová, KIN, EF TUL- DBS 22

23 Rozvrhy Rozvrh je stanovené pořadí provádění operací více transakcí včase pro více současně pracujících uživatelů může být prováděna jedna transakce po druhé ( seriově) či souběžně - pro lepší využití HW a zrychlení Nadále budeme předpokládat transakce T 1 a T 2 transakce T 1 má posloupnost operací (T 11, T 12, T 1n ), transakce T 2 má posloupnost operací (T 21, T 22, T 2m ) Vladimíra Zádová, KIN, EF TUL- DBS 23

24 Seriové rozvrhy zachovávají operace každé transakce pohromadě pro N transakcí existuje N! různých sériových rozvrhů. ( seriovost je uspořádatelnost.) Př. Pro 2 transakce existují právě 2 různé seriové rozvrhy : S 1 : {T 1, T 2 } a S 2 : {T 2, T 1 } Vladimíra Zádová, KIN, EF TUL- DBS 24

25 Souběžné (paralelní zpracování) pro zpracování transakcí lze použít i rozvrhy které dovolují prokládání operací navzájem podmínkou pro správnost zpracování je korektnost výsledku. Požadavky na korektnost: efekt (výsledek) paralelního zpracování transakcí musí odpovídat transakcím provedeným v nějakém seriovém rozvrhu o systému, který zaručuje tuto vlastnost seříká, že zaručuje uspořádatelnost Uspořádatelnost rozvrhu Rozvrh je uspořádatelný, jestliže existuje seriový rozvrh s ním ekvivalentní Vladimíra Zádová, KIN, EF TUL- DBS 25

26 Ekvivalence rozvrhů Dva rozvrhy jsou ekvivalentní, je-li splněno : 1. Jestliže se v jednom rozvrhu vyskytuje READ(A) v transakci T i a tato hodnota vznikla z WRITE(A) v transakci T j, potom totéž musí být zachováno ve druhém rozvrhu. (t.j. každá operace READ čte po stejné operaci WRITE) 2. Jestliže se v jednom rozvrhu vyvolá poslední instrukce WRITE(A) v transakci T i, pak totéž musí být zachováno v druhém rozvrhu. ( to zajišťuje, že konečný stav databáze je stejný v obou rozvrzích) Testování uspořádatelnosti rozvrhů - není pro praxi moc vhodné ( z časového hlediska) Je možné konstruovat transakce podle určitých pravidel ( protokolů) tak, že za splnění určitých předpokladů je každý jejich rozvrh uspořádatelný Vladimíra Zádová, KIN, EF TUL- DBS 26

27 Uzamykací protokoly pomocí uzamykání objektů v databázi lze zajistit to, aby s nimi nikdo jiný v daném čase nepracoval zamykání objektů (operace LOCK) je akce kterou vyvolá transakce na objektu, aby zamezila přístupu ostatních transakcí k danému objektu odemknutí objektů (operace UNLOCK) je akce uvolňující objekt pro zpracování dalšími transakcemi transakce, která uzamkla objekt má právo na něm provádět operace READ a WRITE (a další operace) Vladimíra Zádová, KIN, EF TUL- DBS 27

28 Uzamykací protokoly uzamykání může být: statické dynamické nejznámější protokoly založeny na dynamickém zamykání a odmykání objektů Vladimíra Zádová, KIN, EF TUL- DBS 28

29 Uzamykací protokoly statické uzamykání objekty používané v transakci jsou všechny uzamknuty na počátku transakce, odemknuty těsně před koncem prováděné transakce to znamená, že paralelně mohou být prováděny jen ty transakce, které jsou nekonfliktní (t.j. nesdílí žádné objekty) Vladimíra Zádová, KIN, EF TUL- DBS 29

30 Modely uzamykání transakcí a rozvrhy objekt může být v daném čase uzamčen pouze jednou transakcí objekt bude v transakci uzamknutý kdykoli k němu bude transakce přistupovat transakce se nebudou pokoušet uzamykat objekt uzamčený jinou transakcí legální rozvrhy takové rozvrhy, které splňují obě podmínky nelegální rozvrhy rozvrhy, které nesplňují alespoň jednu z podmínek někdy může nastat uváznutí (deadlock) - v jedné transakci chceme uzamknout objekt již uzamčený druhou transakcí Vladimíra Zádová, KIN, EF TUL- DBS 30

31 Uváznutí LOCK(B) READ(B) akce(b) WRITE(B) LOCK(A) UNLOCK(B) READ(A) LOCK(A) READ(A) LOCK(B) READ(B) UNLOCK(B) A = A + B WRITE(A) transakce T 2 chce uzamknout již uzamčený objekt B zde se pokouší uzamknout první transakce objekt již uzamčený Řešení provedením ROLLBACK jedné transakce Vladimíra Zádová, KIN, EF TUL- DBS 31

32 Modely uzamykání transakcí pro řešení uváznutíči prevenci uváznutí byly vyvinuty metody ( ROLLBACK transakce nemusí být vždy vhodný) Dobře formované transakce transakce uzamyká 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 k zajištění uspořádatelnosti všech legáln lních rozvrhů nepostačuje ani množina dobře formovaných transakcí (lze najít i legální rozvrh nedvoufázových transakcí, který je uspořádatelný) Vladimíra Zádová, KIN, EF TUL- DBS 32

33 Uspořádatelnost rozvrhů K zajištění uspořádatelnosti rozvrhů stačí, aby všechny transakce z množiny uvažovaných transakcí byly dvoufázové, tj. aby každá transakce splňovala dvoufázový uzamykací protokol Dvoufázov zová transakce v první fázi uzamyká všechny potřebn ebné objekty databáze, od prvního odemknutí objektu databáze již nedochází k žádnému zamykání Pozn.: Uzamykací protokol je množina pravidel, která udává kdy transakce bude uzamykat a odmykat objekty databáze Vladimíra Zádová, KIN, EF TUL- DBS 33

34 Platí tvrzení: 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ý. Uváznutí a dvoufázovost uváznutí je typické pro dvoufázové protokoly zamezení např. přiřazením priorit transakcím a čekáním na transakce s vyšší prioritou Kaskádové rušení transakcí provedení ROLLBACK jedné transakce může vyvolat ROLLBACK těch dalších transakcí, které využívaly hodnoty aktualizované touto transakcí odstranění : použitím striktních dvoufázových protokolů, které uvolní zámky až po ukončení transakce (COMMIT) nevýhoda - omezení paralelismu v současné době nejobvyklejší Vladimíra Zádová, KIN, EF TUL- DBS 34

35 Chyby systému Třídy možných chyb ( chyby, které se vyskytují v souvislosti s provozem DBS) globální chyby mají vliv na více transakcí (minimálně na tu právě prováděnou) lokální chyby jsou logické chyby, měly být ošetřeny na úrovni transakce Vladimíra Zádová, KIN, EF TUL- DBS 35

36 Globální chyby Spadnutí systému (př. výpadek proudu)- důsledkem je ztráta obsahu vnitřní paměti Systémové chyby (deadlock = uváznutí) ovlivňují transakce, ne celou databázi Chyby médii (porucha hlavy disku)- ohrožují celou databázi či jejíčást, ovlivňují i transakce, které se týkají právě téčásti Vladimíra Zádová, KIN, EF TUL- DBS 36

37 Zotavení z chyb systému Systémová chyba může vést ke ztrátě obsahu vnitřní paměti(př. vyrovnávacích pamětí databáze), stav systému je pak nedefinovaný řešení: po restartu je třeba použít ROLLBACK, provést znovu transakce, které byly dokončeny, ale neodeslány fyzicky (neodeslány vyrovnávací paměti na disk) systém požadavky na znovuprovedení transakcí rozezná pomocí kontrolních bodů Vladimíra Zádová, KIN, EF TUL- DBS 37

38 Žurnál (= deník transakcí angl. log file) obsahuje historii všech změn databáze začasovou periodu. Slouží jako prostředek k akcím, které zajišťují zotavení z chyb Stav transakce je v případě chyby nedefinovaný, po restartu systému je nutné použít ROLLBACK hlavně chyby vedoucí ke ztrátě obsahu vnitřní paměti je třeba provést po restartu systému znovu ty transakce které byly před započetím chyby systému sice úplné, ale které nebyly dokončeny fyzicky. Vladimíra Zádová, KIN, EF TUL- DBS 38

39 Synchronizační body Synchronizační body jsou hranice mezi dvěma po sobě následujícími transakcemi Zakládá je operace ROLLBACK a COMMIT další a poslední synchronizační bod je inicializace programu. V mechanismu synchronizačních bodů krátké transakce čekají na provedení delších transakcí. Jejich nejjednodušší implementace - odložení spuštění nových transakcí pokud nejsou ukončeny běžící transakce V praxi systém zpracování transakcí používá k určení transakcí, které je třeba znova provést kontrolní body Vladimíra Zádová, KIN, EF TUL- DBS 39

40 Kontrolní body (checkpoints) Kontrolní body se vytvářejí v intervalech provádění transakcí automaticky zahrnují odeslání obsahu vyrovnávacích pamětí na disk a zápis kontrolního záznamu (checkpoint record) do žurnálu záznam může obsahovat seznam všech transakcí, které se v době kontrolního bodu prováděly (byly započaty a nebyly ukončeny) Kontrolní body jsou vhodné, pracuje-li se s delšími transakcemi Vladimíra Zádová, KIN, EF TUL- DBS 40

41 Zotavení z chyby systému Klíčové místo je mezi stavem PC a C Známé strategie pro vstup do stavu C jsou : Inkrementální tvorba žurnálu s odloženými realizacemi změn (odložená aktualizace) Inkrementální tvorba žurnálu s bezprostřední realizací změn (bezprostřední aktualizace) Vladimíra Zádová, KIN, EF TUL- DBS 41

42 Inkrementální tvorba žurnálu s odloženými realizacemi změn Během provádění transakce T jsou všechny operace WRITE odloženy do okamžiku, než se dostane do stavu PC Všechny změny jsou zapisovány do žurnálu, jehož záznamy jsou tvořeny z trojic <T, jméno atributu, nová hodnota> na počátku transakce se do žurnálu zapíše <T, START> ve stavu PC <T, COMMIT>. Teprve potom dochází k zápisu změn do databáze. Vladimíra Zádová, KIN, EF TUL- DBS 42

43 Inkrementální tvorba žurnálu s odloženými realizacemi změn chyba nastane v čase t f před dosažením stavu PC stačí informaci v žurnálu ignorovat a spustit transakci znova ( t.j. RESTART) chyba nastane včase t f za počátkem stavu PC pak musí být záznamy žurnálu k dispozici pro provedení operace REDO, která využije záznamů mezi START a COMMIT. Pozn.: pro obnovu databáze je důležité zálohovat jak databázi, tak i žurnál ( soubory uložit na jiných mediích) i při procesu zotavení z chyb může nastat další chyba -vytvářením žurnálů ale také vytvářením jejich kopií se posílí jistota možností rekonstrukce dané databáze při chybě v době zotavení z chyb. Vladimíra Zádová, KIN, EF TUL- DBS 43

44 Inkrementální tvorba žurnálu s bezprostřední realizací změn všechny operace zápisu se provádějí přímo v žurnálu kromě zápisů počátku a konce drží i čtveřice záznamů <T, jméno atributu, stará hodnota, nová hodnota> umístění záznamů do žurnálu se musí provést před WRITE a před fyzickou změnou databáze Když dojde ke zhroucení, lze pomocí žurnálu uvést databázi do původního stavu - po fyzicky nedodělaných transakcích Zotavení se provádí podle operace REDO i UNDO ta návrat do stavu před započetím transakce umožňuje. Vladimíra Zádová, KIN, EF TUL- DBS 44

45 Inkrementální tvorba žurnálu s bezprostřední realizací změn Po restartu systému se systém v transakcích zorientuje podle procedury: 1. vytvoří se 2 seznamy transakcí UNDO, REDO do UNDO se uloží všechny transakce ze záznamu kontrolního bodu (tj. čas t c ) REDO je prázdný 2. začne se prohledávat žurnál od t c směrem dopředu 3. Pokud se narazí na počátek další transakce T, přidá se do seznamu UNDO 4. Je-li nalezen v žurnálu COMMIT pro transakci T, pak se přesune transakce T ze seznamu UNDO do REDO Na konci žurnálu budou 2 seznamy, podle těchto seznamů je možné přejít k zotavení po chybě Vladimíra Zádová, KIN, EF TUL- DBS 45

46 transakce, které jsou uvedeny v seznamu UNDO jsou zpracovány zpětným chodem, transakce uvedené v seznamu REDO jsou zpracovány chodem vpřed. Teprve po všech akcích REDO, UNDO je možné pokračovat dál. Zotavení z chyby medii obvykle natažení databáze ze záložní kopie použití žurnálu k znovuprovedení všech ukončených transakcí od té chvíle, kdy ještě žurnál poskytuje potřebné informace akce UNDO není třeba - protože u transakcí prováděných v době chyby byly odpovídající změny databáze ztraceny. Vladimíra Zádová, KIN, EF TUL- DBS 46