Téma 12 Transakce, řízení souběhu a obnova dat Obsah 1. Transakce a jejich stavy 2. Souběh transakcí 3. Sériovost, serializovatelnost, obnovitelnost 4. Řízení souběhu 5. Úrovněkonzistence 6. Řídicí protokoly pro práci se zámky 7. Uváznutí transakcí, detekce, prevence a zotavení 8. Obnova dat po havárii 9. Postupy obnovy 10. Obnova založená na protokolech 11. Kontrolní body (check-pointing) verze: Jaro 2014 Transakce a řízení souběhu 1 Pojem transakce Transakceje krokem vykonáváníprogramu, který přistupuje k datům v databázi a případně je i modifikuje Z abstraktního pohledu uživatelského programu na DBMS, za transakci považujeme logicky svázanou série čtecích a zápisových operací Každá transakce musí"vidět" databázi v konzistentním stavu Během provádění transakce může být databáze dočasně nekonzistentní Musíbýt zaručeno, že sekvence celéřady akcí, z nichžse transakce skládá, proběhne atomicky jako celistvý Kdyžtransakce skončíúspěšně(tj. výsledky jsou zapamatovány), databáze musí být opět konzistentní Pokud transakce zhavaruje, konzistence musí zůstat zachována Více transakcí může probíhat souběžně(paralelně) Hlavnídva problémy, ježje třeba řešit: Havárie různých typů: např. hardwarové chyby, problémy OS Souběh transakcí při vícenásobném přístupu (uváznutí...) verze: Jaro 2014 Transakce a řízení souběhu 2 Vlastnosti ACID K zachování konzistence a integrity databáze musí transakční mechanismus zajistit: Atomicitu(Atomicity): Buďse správnězobrazído databáze výsledky všech dílčích operací nebo se nezapíší žádné změny Konzistence(Consistency): Transakce samotná neporuší konzistenci databáze Izolovanost(Isolation): Přestože může běžet více transakcí paralelně, žádná z transakcí nesmí ovlivnit výsledek jiné souběžně prováděné transakce. Mezivýsledky transakce musí být skryté a ostatní transakce nesmí tyto mezivýsledky vidět Tzn., pro každý pár transakcí T i a T j musíplatit, že transakci T i je jeví databáze jakoby transakce T j jižskončila nebo ještěnezačala Trvalost(Durability):Všechny změny dat, kterétransakce provedla, se po jejím úspěšném ukončenípromítnou do databáze a jižnemohou být ztraceny ideálně ani při havárii systému verze: Jaro 2014 Transakce a řízení souběhu 3 Příklad převodu peněz Transakce k převodu 500 Kčz účtu A na B: 1. read(a) 4. read(b) 2. A:= A 500 5. B:= B + 500 3. write(a) 6. write(b) Konzistence Součet A a B se MUSÍtransakcízachovat Atomicita Pokud transakce selže mezi kroky 3 a 6, systém MUSÍzaručit, že v do dat se nepromítne žádná změna (jinak by se narušila konzistence) Izolovanost Jestliže by mezi kroky 3 a 6 přistoupila jinátransakce k týmžúčtům, nalezla by je v nekonzistentním stavu (suma A + Bbude menší, nežby měla být), což je nepřípustné Izolace lze snadno dosáhnout tak, že transakcím bude dovoleno běžet výhradně sériově, tj., jedna po druhé Sériovéprováděnítransakcívšak výrazněsnižuje průchodnost a efektivitu DBMS Trvalost Jakmile je uživatel (tj. uživatelův program volajícídatabázový stroj) informován o tom, že 500 Kčbylo převedeno, tento fakt zůstane zachycen v databázi natrvalo verze: Jaro 2014 Transakce a řízení souběhu 4
Stavy transakcí Aktivní počátečníi průběžný stav; transakce se nacházív tomto stavu během svého vykonávání(běhu) Částečně potvrzená(partially committed) poté, kdy proběhla poslední dílčí operace Chybná(Failed) poté, co se zjistí, že nelze pokračovat v normálním provádění Zrušená(Aborted) stav, kdy transakce odstranívšechny uskutečněnézměny a databáze je uvedena do stavu před zahájením transakce (rollback) Potvrzená(Committed) po úspěšném ukončení, kdy všechny změny jsou natrvalo zapsány v databázi verze: Jaro 2014 Transakce a řízení souběhu 5 Implementace atomicity a trvalosti Komponenta DBMS zvaná správce zotavení implementuje podporu atomicity a trvalosti Primitivní metoda stínové databáze: Předpokládejme, že běží vždy jen jedna transakce Ukazatel označovaný db_pointer vždy odkazuje na momentálně konzistentní databázi Všechny aktualizace se provádějína stínové kopiidatabáze a db_pointerbude změněn teprve poté, co všechny akce se stínovou kopií úspěšně skončily a byly zobrazeny na disku Pokud transakce zhavaruje, bude se nadále používat původní konzistentníkopie odkazovanáukazatelem db_pointer a stínovákopie se smaže Předpoklad: disk nezhavaruje Extrémně neefektivní pro velké databáze (proč?) Neřešíotázky souběhu transakcí Existujílepšíschémata db_pointer Původní databáze db_pointer Původní databáze (ke zrušení) Nováverze databáze Před aktualizací Po aktualizaci verze: Jaro 2014 Transakce a řízení souběhu 6 Souběh transakcí, rozvrhování akcí Souběžnétransakce zvyšují průchodnost systému a redukují průměrný čas odpovědi při sériovém zpracováníkrátkétransakce čekajína dokončenídlouhých (viz konvojový efekt u FCFS ) Transakce se obvykle implementují jako samostatné procesy nebo vlákna Rozvrh (plán)operacív transakcích je posloupnost udávající chronologické pořadí dílčích operací v souběžně prováděných transakcích rozvrh musízahrnout všechny operace všech souběžných transakcí musí zachovat pořadí, v němž jsou prováděny operace každé jednotlivé transakce Transakce, kteráskončila bezchybně, provede na závěr operaci commit, kterou potvrdí svůj úspěch Transakce, kterázhavaruje, bude volat operaci abort, která značí potřebu obnovy původního stavu databáze verze: Jaro 2014 Transakce a řízení souběhu 7 Příklady korektních rozvrhů Nechť převádí50 z účtu A na B, a převádí10% zůstatku z A na B S 1 a S 2 jsou tzv. sériové rozvrhy S 3 nenísériový, ale je ekvivalentnísériovému S 1 či S 2 Rozvrh S 3 Rozvrh S 1 Rozvrh S 2 Všimněte si různých výsledkůrozvrhů S 1 a S 2 Všechny uvedenérozvrhy zachovávajíkonzistenci (A+ B =const.) verze: Jaro 2014 Transakce a řízení souběhu 8
Chybný rozvrh Rozvrh S 4 nezachováváhodnotu (A + B) a tím porušuje požadavek konzistence Rozvrh S 4 Serializovatelnost (uspořádatelnost) Základnípředpoklad každájednotlivátransakce zachovává konzistenci databáze Sériové vykonávání transakcí tedy zachovává konzistenci také Rozvrh (uvažující možný souběh) je serializovatelný, jeli ekvivalentní některému sériovému rozvrhu Budeme uvažovat pouze operace reada write(služby OS) a budeme ignorovat všechny ostatní Transakce mohou s daty provádět libovolnédalšíoperace ve svých lokálních proměnných a vyrovnávacích pamětech mezi read a write "Naše" rozvrhy budou tvořeny jen operacemi read a write verze: Jaro 2014 Transakce a řízení souběhu 9 verze: Jaro 2014 Transakce a řízení souběhu 10 Vzájemně neslučitelné operace Operace (instrukce) I i a I j patřícík transakcím T i a T j jsou vzájemně neslučitelné(konfliktní) právě tehdy, když existuje datovápoložka (záznam) Q, k nížpřistupují I i i I j, a aspoňjedna z těchto operacído Qzapisuje 1. I i = read(q), I j = read(q) nekonfliktní 2. I i = read(q), I j = write(q) konfliktní 3. I i = write(q), I j = read(q) konfliktní 4. I i = write(q), I j = write(q) konfliktní Konflikt mezi I i a I j si vynucuje časovéuspořádání operací I i a I j. Pokud I i a I j následujív nějakém rozvrhu a nejsou ve vzájemném konfliktu, pak výsledek bude stejný, i kdyžbudou vzájemně prohozeny Serializovatelný rozvrh Jestliže rozvrh S lze transformovat na rozvrh S sérií vzájemných záměn nekonfliktních operací, pak se S a S označují za ekvivalentní vůči konfliktu Rozvrh pak označujeme jako serializovatelný, je-li ekvivalentní vůči konfliktu se sériovým rozvrhem Rozvrh S 3 lze převést na sériový S 6, kde sérií vzájemných prohození nekonfliktních operací S 3 je tedy serializovatelný rozvrh Rozvrh S 5 serializovatelný není Nelze najít posloupnost vhodných prohození nekonfliktních operací tak, aby vznikl sériový rozvrh T 3 T 4 nebo T 3 T 4 verze: Jaro 2014 Transakce a řízení souběhu 11 verze: Jaro 2014 Transakce a řízení souběhu 12
Příklad serializace Příklad: r 1, w 1 operace transakce 1, r 2, w 2 operace transakce 2 S = r 1 (A), w 1 (A), r 2 (A), w 2 (A), r 1 (B), w 1 (B), r 2 (B), w 2 (B) r 1 (B) w 2 (A) r 1 (B) r 2 (A) w 1 (B) w 2 (A) S = r 1 (A), w 1 (A), r 1 (B), w 1 (B); r 2 (A), w 2 (A), r 2 (B), w 2 (B) verze: Jaro 2014 Transakce a řízení souběhu 13 Test serializovatelnosti Uvažme rozvrh jistémnožiny transakcí,,..., T n Precedenční graf je orientovaný graf, kde vrcholy jsou transakce a hrana vede z T i do T j, když T i a T j jsou v konfliktu a transakce T i přistoupila ke konfliktním datům dříve Ke hranám se obvykle připisuje označení datové položky způsobující konflikt Příklad: r(a) = read(a) w(a) = write(a) T 3 T 4 T 5 r(x) r(y) r(z) r(v) r(w) r(y) w(y) w(z) r(u) r(u) w(u) r(y) w(y) r(z) w(z) verze: Jaro 2014 Transakce a řízení souběhu 14 T 3 Z Z Y, Z Y T 4 A Y B T 5 Test serializovatelnosti (pokr.) Rozvrh je serializovatelný právě tehdy, jeli precedenční graf acyklický Algoritmy na detekci cyklů (Téma 5) majíčasovou složitost n 2, kde n je počet vrcholů grafu Existujíi algoritmy se složitostí n+ e, kde epočet hran Je-li precedenčnígraf acyklický, pak sériovépořadítransakcílze určit tzv. topologickým řazením grafu Je to lineárnířazení, v němžkaždý uzel předcházívšechny uzly, k nimžvedou jeho výstupní hrany. Topologické řazení není jednoznačné Např., topologickéřazenípro rozvrh z předchozí stránky může být T 5 T 3 T 4 Existují nějaká jiná řazení? Najděte je! verze: Jaro 2014 Transakce a řízení souběhu 15 T i T j T k T j T m T 3 Z Z T i T m Y Y, Z T 4 T k T i T k T j T m Y T 5 Obnovitelné rozvrhy Vzhledem k tomu, že obvykle nelze zabránit chybovým stavům souběžných transakcí, je třeba zajistit obnovu výchozího stavu Obnovitelný rozvrh Jestliže transakce T j čte data dříve modifikovanátransakcí T i, pak potvrzení(commit) operace T i musí předcházet potvrzení(commit) operace T j. Rozvrh S 11 by nebyl obnovitelný, pokud by transakce T 9 potvrdila svůj úspěch bezprostředně po čtení Kdyby transakce T 8 zhavarovala a byla nucena provést abort, T 9 by četla a možnái prezentovala uživateli databázi v nekonzistentním stavu DBMS mj. musí zajistit, že rozvrhy budou obnovitelné verze: Jaro 2014 Transakce a řízení souběhu 16
Kaskáda návratů(rollbacks) Havárie jednétransakce může způsobit nutnost návratu databáze do výchozího stavu pro celou sérii transakcí. Taková situace se nazývá kaskáda návratů(cascaded rollback) Rozvrh, kde žádnáz transakcídosud nepotvrdila úspěšné ukončení Pokud 0 zhavaruje, musídojít k návratu i pro 1 a 2 Dochází k velkým ztrátám Nekaskádovérozvrhyjsou rozvrhy, kde nedochází ke kaskádovým návratům Pro každý pár transakcí T i a T j takových, že T j čte data modifikovanádříve transakcí T i, musíoperace potvrzenív T i (commit)předcházet operaci readv transakci T j. Každý nekaskádový rozvrh je též obnovitelný Je žádoucí tvořit jen nekaskádové rozvrhy bohužel ne vždy to jde verze: Jaro 2014 Transakce a řízení souběhu 17 Řízení souběhu DBMS musíposkytovat mechanismy, kterézajistí, že všechny rozvrhy při paralelním běhu transakcí budou serializovatelné, obnovitelné a (pokud možno) nekaskádové Strategie sériových rozvrhů, kdy běží transakce jedna po druhé sice splňuje tyto požadavky, ale systém mášpatnou průchodnost Cíl: vyvinout protokoly pro řízení souběhu, které zajistí serializovatelnost Protokoly musídovolit souběh za současnétvorby serializovatelných, obnovitelných a nekaskádových rozvrhů Protokoly obvykle nezkoumajíprecedenčnígraf. Místo toho formulujízávaznápravidla vylučujícírozvrhy, kterénejsou serializovatelné Protokoly pro řízenísouběhu se navzájem lišístupněm paralelismu a velikostípůsobených režijních ztrát Testy serializovatelnosti se explicitněneaplikují, pouze pomáhají pochopit, proč je ten který protokol korektní verze: Jaro 2014 Transakce a řízení souběhu 18 Úrovně konzistence Některé aplikace se spokojí s nepřesnými výsledky, což dovoluje, aby rozvrhy nemusely být serializovatelné Např. transakce, kteráchce zjistit přibližný součet zůstatkůna všech účtech Takové transakce nemusí být serializovatelné vůči transakcím ostatním Kompromis mezi přesností a výkonností Úrovně konzistence podle standardu SQL-92 Serializable implicitní úroveň(nejpřísnější) Repeatable read smí se číst jen potvrzené záznamy (commit), opakované čtení téhož záznamu musí dodat tutéž hodnotu. Avšak transakce nemusí být plně serializovatelná může např. najít jen některézáznamy vloženéjinou transakcí, ale ne nutně všechny Read committed smíse číst jen potvrzenézáznamy, ale opakovanéčtenínemusívždy vrátit totéž Read uncommitted lze číst i nepotvrzené záznamy Nižšíúrovněkonzistence lze použít pro získávánípřibližných informací verze: Jaro 2014 Transakce a řízení souběhu 19 Protokoly využívající zamykání Zamykacímechanismy k řízenísouběhu jsou tytéžjako u kritických sekcí Položky dat lze zamykat ve dvou režimech: 1. výlučný exclusive(x) režim: Položka je plněuzamčena a může být vlastníkem zámku čtena i zapisována. X-zámek nad datovou položkou se zakládá pomocí"instrukce" lock-x 2. sdílený shared(s) režim: Položka se smípouze číst S-zámek se zakládá pomocí"instrukce" lock-s Matice kompatibility zámků S X S true false X false false Transakce smípřistoupit k položce (zamknout ji), jen pokud požadovaný režim zámku je kompatibilnís existujícími zámky vlastněnými jinými transakcemi nad stejnou položkou Libovolný počet transakcímůže současnězískat S-zámek, avšak transakce "držící" X-zámek brání všem ostatním v přístupu k položce Pokud zámek nelze získat, transakce je nucena čekat na uvolnění položky. Poté je přístup umožněn Je to tatážsituace jako u semaforůa dalších synchronizačních mechanismů verze: Jaro 2014 Transakce a řízení souběhu 20
Protokoly využívající zamykání(pokr.) Příklad transakce se zamykáním: : lock-s(a); read(a); unlock(a); lock-s(b); read(b); unlock(b); display(a+b); Uvedená posloupnost zamykání není dostatečná k zaručení serializovatelnosti pokud by Aa/nebo Bbylo změněno jinou transakcí, zobrazený součet by byl chybný Zamykací protokol je množina pravidel, která se aplikují při operacích lock-s, lock-x a unlock Zamykací protokoly omezují množinu přípustných rozvrhů Zamykání může být nebezpečné Nebezpečí uváznutí(deadlock) Nelze kompletněvyřešit transakce budou musíbýt občas rušeny ("zabíjeny") a stav databáze obnovován Nebezpečí stárnutí(starvation) Transakce je opakovaně rušena a je vynucováno obnovování kvůli uváznutí Manažer souběhu je schopen vhodnými prostředky zabránit stárnutí verze: Jaro 2014 Transakce a řízení souběhu 21 Dvoufázový zamykací protokol Jde o protokol, který zajišťuje rozvrhy ekvivalentnívůči konfliktu s rozvrhy sériovými Fáze 1: Růst transakce smějí pouze zamykat a nemohou zámky uvolňovat Fáze 2: Smršťování transakce smějí zámky pouze uvolňovat a nemohou nic dalšího zamykat Protokol zajišťuje serializovatelnost. Dá se dokázat, že transakce poběží v sérii podle pořadí dosahování svých zamykacích bodů(tj. bodů, kdy transakce získaly svůj poslední potřebný zámek) verze: Jaro 2014 Transakce a řízení souběhu 22 Dvoufázový zamykací protokol (pokr.) Dvoufázový zamykacíprotokol nevylučujeuváznutía neobsahuje ani prevenci vzniku kaskádových návratů K tomu účelu byl vyvinut protokol zvaný striktní dvoufázové zamykání Transakce musí držet všechny své exkluzivní zámky, dokud nepotvrdí své úspěšné ukončení(commit) nebo nezhavaruje (abort) Rigoróznídvoufázovézamykáníje ještěpřísnější: Všechny(tj. Xi S) zámky musítransakce držet do svého úspěšného konce nebo havárie (commit/abort). V tomto protokolu jsou transakce serializovány v pořadí, jak končí Počet zámků verze: Jaro 2014 Transakce a řízení souběhu 23 Automatické získávání zámků Transakce T i užívájen databázové operace read/write bez explicitního zamykání, které je součástí těchto operací Operace read(d) je implementována jako read_os a write_os značí základní operace poskytované OS if T i vlastnízámek Dthen read_os(d) else begin ifněkterájinátransakce drží lock-xna Dthen wait; přiřaďtransakci T i lock-sna D; read_os(d) end Operace write(d) se implementuje jako if T i vlastní lock-xna Dthen write_os(d) else begin if některá jiná transakce drží jakýkoliv zámek na D then wait; if T i vlastní lock-sna D then změň("povyš") zámek z lock-sna Dna lock-x else přiřaďtransakci Ti lock-xna D; write_os(d) end; Všechny zámky jsou uvolněny jako součást commit/abort verze: Jaro 2014 Transakce a řízení souběhu 24
Implementace zamykání Správu zámkůmázpravidla ve svékompetenci samostatný výpočetní proces (či vlákno) správce zámků (lock manager), jemužvšechny transakce zasílajížádosti o přidělení a uvolňování zámků Žádající transakce čeká na odpověď od správce zámků Správce zámků odpovídá na žádost o přidělení zámku zasláním zprávy o přidělenízámku v případěúspěchu, nebo zprávy se žádostío návrat (obnovení) dat v případě, že je detekováno uváznutí Správce zámkůse opíráo tabulku zámků Obsahuje přidělené zámky a čekající nevyřízené žádosti U přiděleného zámku či žádosti se pamatuje i typ zámku (X/S) Tabulka zámků je zpravidla implementována jako hašovaná tabulka v operačnípaměti, indexovanájménem datovépoložky podléhající zamykání Tabulka zámků Novážádost o přidělenízámku je zařazena na konec fronty žádostía je ihned vyřízena, pokud je kompatibilnís existujícími zámky k příslušné datové položce Žádost o odemčení způsobí smazánízámku. Pak je prohledán zbytek fronty, kdy se zjišťuje, zda lze přidělit zámky čekajícím žádostem Kdyžse transakce ruší(abort), všechny přidělené zámky i čekající žádosti se smažou. Dále se postupuje jako při odemykání zámků k zefektivněnítéto operace může správce zámkůudržovat i seznam zámků přidělených dané transakci verze: Jaro 2014 Transakce a řízení souběhu 25 verze: Jaro 2014 Transakce a řízení souběhu 26 Grafově orientované protokoly Grafovéprotokoly jsou alternativou k dvoufázovému zamykání Zavedeme částečnéuspořádání na množině = {d 1, d 2,..., d h } datových položek, s nimižsouběžnétransakce potřebují pracovat Jestliže d i d j,pak transakce používajícíjak d i tak i d j musí přistoupit k d i před přístupem k d j. Na množinu lze nynípohlížet jako na orientovaný acyklický graf, zvaný graf databáze Srovnejme s dříve vysvětleným principem "číslovánísdílených prostředků" u kritických sekcí, který zabraňuje uváznutí Jednoduchým grafovým protokolem je stromový protokol (tree-protocol) verze: Jaro 2014 Transakce a řízení souběhu 27 Stromový protokol G D 1. Uvažujme jen X-zámky 2. Jako prvnímůže transakce T i zamknout kteroukoliv položku dat. Následněpoložka Qsmíbýt transakcí T i uzamčena pouze tehdy, je-li některý předchůdce položky Q ve stromu též uzamčen touto transakcí 3. Odmykat lze kdykoliv 4. Pokud byla položka transakcí T i jednou zamčena a pak odemčena, transakce T i se nesmíznovu pokusit o zamčenítéže položky verze: Jaro 2014 Transakce a řízení souběhu 28 H J B E A I C F
Vlastnosti stromového protokolu Výhody Stromový protokol zabezpečuje serializovatelnost a odstraňuje riziko uváznutí Odmykánízáznamůmůže proběhnout dříve nežu dvoufázového zamykání kratší čekání, lepší průchodnost, vyšší stupeň paralelismu Díky neexistenci rizika uváznutí není potřeba návrat (rollback) Nevýhody Protokol nezaručuje obnovitelnost ani odolnost vůči kaskádním návratům Je tedy nutno zavést vzájemnézávislosti mezi operacemi commit, aby se zajistila obnovitelnost Vlivem toho, transakce budou muset držet zámky i na záznamech, které již nepotřebují, což vede k částečné degradaci uvedených výhod Některérozvrhy nerealizovatelnépři dvoufázovém zamykání jsou pro stromový protokol přípustné, ale také naopak verze: Jaro 2014 Transakce a řízení souběhu 29 Granularita zamykání Data mají různou důležitost a velikost celádatabáze, relace a s níspojený index, jen index, jeden záznam,... Mátedy smysl definovat hierarchii působnosti zámků, kde "jemnější zámky" jsou zanořeny (podřízeny) hrubším Hierarchii lze znázornit stromem POZOR: nejde o stromový protokol, ač hierarchie má tvar stromu Kdyžtransakce explicitnězamkne některý uzel stromu, pak se implicitněa automaticky zamknou všechny podřízenépoložky, a to ve stejném režimu zamykání verze: Jaro 2014 Transakce a řízení souběhu 30 Mějme 2 transakce: : write(x) write(y) Rozvrh s uváznutím Uváznutí : write(y) write(x) Protokoly s prevencí uváznutí zajistí, že k uváznutí nikdy nedojde Základní strategie prevence jsou: Požaduj, aby transakce předem zamkla vše, co bude potřebovat pro svoji budoucí práci dvoufázové zamykání Částečné uspořádání datových položek grafový protokol Ne vždy je lze použít Vždy limitují průchodnost verze: Jaro 2014 Transakce a řízení souběhu 31 Pokročilé strategie prevence uváznutí Strategie s časovými značkami na počátku je každé transakci přiřazena časová značka Nepreemptivní strategie wait-die(čekej-zahyň) Staršítransakce smíčekat, dokud mladšítransakce neuvolnídrženou datovou položku. Naopak, mladšítransakce nikdy nečeká, místo toho volá abort a obnoví data do stavu před svým spuštěním (zahyne) Transakce může zahynout mnohokrát, než se jí podaří získat data Preemptivní strategie wound-wait(poraň-čekej) Starší transakce poraní(= vynutí obnovu stavu - rollback) mladší transakci, místo čekání na ni. Mladší transakce však mohou na starší čekat Obecně způsobuje méně návratů než strategie wait-die Pro obě strategie platí Transakce, kteréobnovily stav dat, jsou restartovány se svými původními časovými značkami. Tím je zaručeno, že starší(tj. dříve zahájené) transakce budou mít přednost před mladšími, čímžje odstraněno riziko stárnutí. Strategie založené na časových prodlevách (timeout) Transakce čeká na zámek nejvýše určitou dobu Kdyžse nedočká, voláabort(a tím obnovu dat) Časové omezení brání vzniku uváznutí Snadnáimplementace, avšak hrozístárnutí. Obtížné je stanovení dobré hodnoty časového omezení verze: Jaro 2014 Transakce a řízení souběhu 32
Detekce uváznutí a zotavení Uváznutí se detekuje pomocí čekacího grafu ( Téma 5) Vrcholy jsou transakce T i Orientovanáhrana T i T j značí, že T i čeká, až T j odemkne datovou položku Je-li v čekacím grafu cyklus, došlo k uváznutí Algoritmus detekce byl popsán v dříve (Téma 5) Když se detekuje uváznutí Je nutno nalézt obětnítransakci a vnutit jíabort(a tím i obnovu dat). Obětuje se obvykle nejmladšítransakce, tj. ta, která ještě neudělala mnoho změn Transakce mohou stárnout, bude-li za oběťvybírána vždy nejmladšítransakce. Proto je vhodnédo kritéria výběru oběti zahrnout i počet touto transakcí dosud provedených návratů Kterádata se ale majíobnovovat? Totálníobnova transakci úplnězruší, data se vrátído počátečního stavu, a transakce se restartuje. To může být velmi nákladné Efektivnějšíje, kdyžse transakce "vracípostupně" do stavu, kdy uváznutízmizí. Tento postup je ale náročný na evidenci krokůa změn transakcí provedených Používáse např. tzv. metoda kontrolních bodů(checkpointing) verze: Jaro 2014 Transakce a řízení souběhu 33 Klasifikace chybových stavů Chyby transakcí Logickéchyby: vlivem nějakévnitřnílogicképodmínky nemůže transakce úspěšně skončit Systémovéchyby: DBMS musípřerušit aktivnítransakci kvůli vzniku chybového stavu, který je detekován (např. uváznutí) Havárie systému Výpadek napájení nebo jiná chyba hardware či selhání podloženého operačního systému způsobí havárii Předpoklad: obsah persistentní paměti nebude havárií narušen DBMSdělajívětšinou celou řadu kontrolních operacís cílem zabránit poškození dat na disku (nebo aspoň jejich konzistence) Havárie disku: Chyba či havárie diskovéjednotky způsobízničeníčásti nebo dokonce celého obsahu disku Předpoklad: Destrukce je detekovatelná diskové jednotky používají kontrolní součty k detekci chyb RAID (Redundant Array of Independent Disks) pole disků verze: Jaro 2014 Transakce a řízení souběhu 34 Obnova konzistentního stavu databáze Metoda stínové databáze je velmi neefektivní Potřeba lepších řešení Algoritmy obnovy (zotavení) Způsoby a techniky, jak zajistit konzistenci databáze podmíněnou atomicitou transakcía trvalostíjejich výsledkůi v případě existence chyb a havárií Algoritmy obnovy mají dvě komponenty 1. Akce prováděné během běžného zpracování transakcí, které poskytnou dostatek informací nutných k zotavení v případě selhání 2. Akce, kterépo vzniku chybovésituace spolehlivědovedou databázi do stavu, který zaručí konzistenci, atomicitu transakcí a trvalost konzistentního stavu Typy pamětí Volatilní paměť obsah nepřežije havárii systému Příklady: cache, operační(primární) paměť Persistentní paměť obsah zůstane zachován, i když systém zhavaruje Příklady: disk, mg. páska, flashpaměť, CD-ROM, bateriízálohovanáram Stabilní paměť teoretickáideální(a tudížneexistující) paměť, jejížobsah přežije všechny chyby a havárie Aproximuje se pomocívícenásobných kopiídat ukládaných na různápersistentnímedia např. redundantní disková pole RAID verze: Jaro 2014 Transakce a řízení souběhu 35 verze: Jaro 2014 Transakce a řízení souběhu 36
Přístup k datům Fyzickéblokyjsou uloženy na persistentním disku Vyrovnávacípaměti blokůjsou dočasnékopie fyzických bloků v hlavní(primární) paměti Přesuny blokůmezi diskem a pamětíjsou vyvolány operacemi input(b) přenáší obsah fyzického bloku B do hlavní paměti output(b)přenášíobsah vyrovnávacípaměti bloku B na disk a přepíše obsah příslušného fyzického bloku Každátransakce T i másvůj privátnípracovníprostor, v němž jsou lokální kopie datových položek, s nimiž transakce pracuje Lokálníkopii datovépoložky Xpatřícítransakci T i budeme značit x i. Pro jednoduchost (a lepšíčitelnost) budeme předpokládat, že každádatovápoložka je uložena uvnitřjednoho bloku Nepřechází tedy přes hranici bloku verze: Jaro 2014 Transakce a řízení souběhu 37 Přístup k datům (pokr.) Transakce přenášídatovépoložky mezi systémovými vyrovnávacími pamětmi blokůa svým privátním pracovním prostorem pomocí operací read(x) přiřadíhodnotu položky Xlokáníproměnné x i. write(x) zapíše hodnotu lokálníproměnné x i do datové položky {X} nacházející se ve vyrovnávací paměti bloku obětyto operace vyvolajípotřebu operace input(b X )před tím, nežlze provést přiřazení, pokud blok B X obsahující položku Xneníjižv hlavnípaměti Transakce musíprovést read(x)při prvním přístupu k X Všechny dalšípřístupy se pak dějínad lokálníkopií Po poslednímodifikačnímanipulaci s položkou je nutno provést write(x) Ne každá operace write(x) vyvolá okamžitě output(b X ). Z důvodů efektivity odkládá systém fyzické zápisy output až do doby, kdy to považuje za vhodné verze: Jaro 2014 Transakce a řízení souběhu 38 Příklad přístupu k datům Vyrovnávací paměti (buffers) Vyrovnávací paměť bloku A input(a) X Vyrovnávací paměť bloku B x 1 y 1 Y read(x) write(y) pracovní prostor x 2 pracovní prostor output(b) A B Zotavenía atomicita Každá transakce musí proběhnout buď úspěšně celá (commit) nebo se databáze musívrátit zpět do konzistentního stavu Transakce T i převádějícípeníze z účtu Ana účet B musípřevést celou částku (tj. uskutečnit všechny modifikace) nebo nic K završení T i bude nutno uskutečnit několik operacíoutput (zde pro Aa B). Chyba může nastat poté, kdy se první modifikace úspěšně zapsala na disk, avšak druhou kvůli chybě nelze dokončit K zaručeníatomicity i v případěchyb se nejprve ukládají informace popisující předpokládané modifikace na stabilní paměť a teprve pak se provádějí vlastní modifikace databáze Ukážeme základnípřístup zotavenís protokolem (log-based recovery) Zpočátku předpokládejme, že transakce poběží čistě sériově paměť disk verze: Jaro 2014 Transakce a řízení souběhu 39 verze: Jaro 2014 Transakce a řízení souběhu 40
Zotavení založené na protokolu Na stabilní paměti se vytváří a udržuje protokol(log) Je to sekvence protokolových záznamů, která eviduje aktuální akce prováděné s databází(zejména zápisové operace) Protokol se buduje následovně: Při startu se transakce T i registruje záznamem T i start Před jakýmkoliv write(x) transakce T i uložízáznam T i, X, [V 1 ], V 2, kde V 1 je hodnota Xpřed writea V 2 je zapisovaná hodnota položky X Je tedy zaprotokolována jak původnítak i nováhodnota položky Xspolu s informací, že jde o aktivitu transakce T i. Původní hodnota se někdy neukládá Když T i končíúspěšně, zaprotokoluje se záznam T i commit Předpokládáme zatím, že transakce běžísériověa záznamy protokolu se zapisují přímo na stabilní paměť tj. nepřecházejí přes vyrovnávací paměť(unbuffered) Používají se dva přístupy založené na protokolování Odložená modifikace databáze Okamžitá(průběžná) modifikace databáze verze: Jaro 2014 Transakce a řízení souběhu 41 Odložená modifikace databáze Princip metody odloženémodifikace databáze je v tom, že se modifikuje jen protokol a všechny operace write jsou odloženy Transakce začínázápisem záznamu T i start do protokolu Operace write(x) zapíše záznam T i, X, V, kde V je nová hodnota X Původní hodnotu při odložené modifikaci nepotřebujeme Vlastní modifikace dat se zatím nedělá Když T i úspěšněukončísvoji poslednídatovou operaci, dostane se do stavu částečněpotvrzená(partially committed) a zapíše do protokolu T i commit Na závěr se prochází protokol a všechny zaznamenané akce týkajícíse T i jsou interpretovány tedy uskuteční se všechny odložené operace write verze: Jaro 2014 Transakce a řízení souběhu 42 Odložená modifikace databáze (pokr.) Při zotavení po havárii je nutno modifikace vytvořené transakcíopakovat právětehdy, jsou-li v protokolu oba záznamy T i start a T i commit Opakovánítransakce T i (redo T i ) nastavuje hodnoty všech datových položek na hodnoty zaznamenané v protokolu Havárie mohou nastat při původním zapisování nových hodnot, nebo při opakování těchto zápisů Příklad: Nechť T 0 běžípřed T 0 : read(a) : read(c) A := A 50 write(a) C:= C 100 write(c) read(b) B := B+ 50 write(b) verze: Jaro 2014 Transakce a řízení souběhu 43 Odložená modifikace databáze (pokr. 2) Stav protokolu ve třech okamžicích T 0 start T 0, A, 950 T 0, B, 2050 T 0 start T 0, A, 950 T 0, B, 2050 T 0 commit start, C, 600 T 0 start T 0, A, 950 T 0, B, 2050 T 0 commit start, C, 600 commit (a) (b) (c) Dojde-li k havárii v čase (a) Nemusíse dělat nic (chybí T 0 commit nic neníani částečně potvrzeno, žádná změna dat se neuskutečnila) (b) Je nutno udělat redo(t 0 ), neboťje zaznamenáno T 0 commit (c) Je nutno udělat redo(t 0 ) následovanéredo( ), neboťv protokolu je jak T 0 commit tak i commit verze: Jaro 2014 Transakce a řízení souběhu 44
Okamžitá modifikace databáze Metoda okamžitémodifikace databázeumožňuje, aby aktualizace databáze probíhala souběžněs operacemi write Protože přicházív úvahu anulování(undo) všech provedených zápisů, protokol musí obsahovat jak nové tak i původní hodnoty Záznam o aktualizaci položky musíbýt zapsán do protokolu před zápisem do databáze Opět předpokládáme, že záznamy protokolu se zapisují přímo na stabilní paměť Zápisy to protokolu lze dokonce odsunout aždo okamžiku, kdy se provádíoutput(b), kde Bdatový blok se zapisovanou položkou. Před output(b) však musíbýt protokol se všemi změnami hodnot v B na stabilní paměti Skutečný zápis aktualizovaných blokůlze však provést kdykoliv po bezpečném uloženíprotokolu, a to i před úspěšným ukončením transakce Pořadí, v jakém se bloky vypisujína disk, se může lišit od pořadí operací write Okamžitá modifikace databáze může být rychlejší verze: Jaro 2014 Transakce a řízení souběhu 45 Okamžitá modifikace databáze - příklad T 0 : read(a) : read(c) A := A 50 C:= C 100 write(a) write(c) read(b) B := B+ 50 write(b) Protokol Write Output T 0 start T 0, A, 1000, 950 T 0, B, 2000, 2050 A= 950 B= 2050 T 0 commit start, C, 700, 600 C= 600 B B, B C commit B A B X značíblok obsahující X verze: Jaro 2014 Transakce a řízení souběhu 46 Okamžitá modifikace databáze (pokr.) Procedura zotavení je složitější a potřebuje dvě operace undo(t i ) anulovánívýsledkůtransakce T i obnovípůvodní hodnoty všech datových položek modifikovaných T i zpětným průchodem protokolu lze zjistit, co kdy bylo modifikováno a jaké byly původní hodnoty redo(t i ) nastavínovéhodnoty všech položek modifikovaných T i podle protokolu počínaje prvním záznamem pro transakci T i Obě operace musí být idempotentní Tj., i kdyžse operace provede několikrát, výsledek musíbýt stejný, jakoby operace proběhla právě jednou Nutné, protože operace mohou být během obnovy restartovány Obnova Transakce T i musíbýt anulována (undo), pokud protokol obsahuje záznam T i start, avšak neobsahuje T i commit Transakce T i musíbýt opakována (redo), pokud protokol obsahuje jak záznam T i start tak i T i commit Napřed se dělajívšechny operace undoa pak všechny redo Obnova při okamžité modifikaci - příklad Stav protokolu ve třech okamžicích T 0 start T 0, A, 1000, 950 T 0, B, 2000, 2050 T 0 start T 0, A, 1000, 950 T 0, B, 2000, 2050 T 0 commit start, C, 500, 600 T 0 start T 0, A, 1000, 950 T 0, B, 2000, 2050 T 0 commit start, C, 700, 600 commit (a) (b) (c) Dojde-li k havárii v čase (a) undo(t 0 ) vrátí Ana 1000 a Bna 2000 (b) undo( ) obnoví Cna 700 a redo(t 0 ) nastaví Ana 950 a Bna 2050 (c) redo(t 0 ) nastaví Ana 950 a Bna 2050 a redo( ) nastaví Cna 600 verze: Jaro 2014 Transakce a řízení souběhu 47 verze: Jaro 2014 Transakce a řízení souběhu 48
Kontrolní body - checkpointing Problémy s obnovou 1. Prohledávání celého protokolu je časově náročné 2. Zbytečnéopakovánítransakcí(redo), jejichžvýsledky jsou již uloženy v databázi Efektivnějšího zotavovánílze dosáhnout periodickým voláním metody zvané checkpointing 1. Vypiš(flush) všechny protokolovézáznamy uloženév operační paměti na stabilní paměť 2. Vypiš všechny vyrovnávací paměti bloků na disk 3. Když se vše podaří, ulož do protokolu záznam kontrolní bod checkpoint a vypiš protokol na stabilní paměť Při zotavení se lze opírat o polohu záznamu checkpoint a starší akce lze ignorovat Kontrolní body checkpointing(pokr.) Stačíuvažovat transakci T k, kterázačala jako poslední před kontrolním bodem, a všechny transakce, které začaly po T k 1. Prohlížej protokol zpětněod konce aždo nalezeníposledního záznamu checkpoint 2. Pokračuj ve zpětném hledánído nalezenízáznamu T k start 3. Nynístačíuvažovat jen část protokolu, kteránásleduje po T k start. Staršízáznamy lze ignorovat či dokonce vymazat 4. Pro transakci T k a všechny transakce, kterézačaly po T k a které nemajív protokolu záznam T i commit,proveďundo(t i ) Má smysl jen při okamžité modifikaci databáze 5. Prohledávej protokol od T k směrem vpřed a pro transakci T k a všechny transakce, kterézačaly po nía majív protokolu záznam T i commit, proveďredo(t i ). verze: Jaro 2014 Transakce a řízení souběhu 49 verze: Jaro 2014 Transakce a řízení souběhu 50 Checkpointing příklad t c checkpoint T 3 bude ignorována aktualizace jsou již uloženy na disku, o čemž svědčí exitence kontrolního bodu S a T 3 se musíprovést redo Transakce T 4 musíbýt anulována (undo) T4 t f havárie čas Zotavení při souběžných transakcích Zotavenípodle protokolu lze použít i pro případ souběžných transakcí Všechny transakce sdílí společnou vyrovnávací paměť diskových bloků a jediný protokol Obsah vyrovnávacípaměti jednoho bloku může být modifikován jednou či více transakcemi Uvažujme řízenísouběhu striktním dvoufázovým zamykáním tj. ostatnítransakce nesmívidět aktualizace provedenédosud nepotvrzenými transakcemi Kdyby tomu tak nebylo, pak situace, kdy změní A, pak změní Aa potvrdíúspěch, a poté zhavaruje, by byla neřešitelná Protokol záznamy různých transakcí budou v protokolu promíchány Technika kontrolních bodů se ale musí upravit v okamžiku, kdy vznikákontrolníbod, může být rozpracováno několik transakcí verze: Jaro 2014 Transakce a řízení souběhu 51 verze: Jaro 2014 Transakce a řízení souběhu 52
Zotavení při souběžných transakcích (pokr.) Kontrolní body Ukládáníkontrolních bodůdo protokolu je shodnés předchozím případem, avšak záznam mátvar checkpoint L, kde Lje seznam transakcí, kterébyly aktivnív okamžiku, kdy se kontrolní bod vytvářel Předpokládáme, že při vypisováníprotokolu na stabilnípaměťa vyrovnávacích pamětíblokůna disk jsou aktualizace pozastaveny (tento požadavek lze oslabit) Kdyžse systém zotavuje z havárie 1. Utvoř prázdné seznamy undo-list a redo-list 2. Procházej protokol od konce zpětněažpo prvnízáznam checkpoint L. Pro každý záznam nalezený během zpětného průchodu: je-li to T i commit, přidej T i k seznamu redo-list je-li to T i start a přitom T i nenív seznamu redo-list, přidej T i do seznamu undo-list 3. Pro všechny transakce T i v Ltestuj, zda T i jižje v seznamu redo-list, pokud ne, tak přidej T i do undo-list Zotavení při souběžných transakcích (pokr.) Nyní undo-listobsahuje seznam všech nekompletních transakcí, které musí být anulovány (undo), a redo-list všechny hotovétransakce, kteréje nutno zopakovat (redo) Zotavení pokračuje následovně: 1. Pokračuj dále ve zpětném procházeníprotokolu, dokud nenajdešzáznam T i start a to pro všechny T i v undo-listu. Při procházeníproveďundotransakcínacházejících se v undo-listu 2. Přesuň se na poslední záznam checkpoint L 3. Procházej protokol vpřed směrem ke konci Při procházeníhledej záznamy transakcínacházejících se v redo-listu a pro každou z nich proveďredo verze: Jaro 2014 Transakce a řízení souběhu 53 verze: Jaro 2014 Transakce a řízení souběhu 54 Vyrovnávací paměti protokolu Pro zefektivněnítvorby protokolu potřebujeme vyrovnávací paměť Protokolovacízáznamy se tvořív bloku v hlavnípaměti místo přímého zápisu na stabilnípaměť. Záznamy se vypíší, ažkdyžje blok zaplněn nebo při akci log force. Log forcese provádíjako součást committransakce, aby se všechny informace o transakci uložily na stabilní paměť Takto se přenese najednou několik záznamůprotokolu a tím se redukuje počet I/O operací K zabezpečeníprotokolu s vyrovnávacípamětíje nutno dodržet několik pravidel Protokolovacízáznamy jsou přenášeny na stabilnípaměťv pořadí, jak byly vytvářeny Transakce T i přejde do stavu "Potvrzená" (committed) pouze kdyžzáznam T i commit je bezpečnězapsán na stabilnípaměť Před tím, nežzačne být vyrovnávacípaměťdatového bloku zapisována na disk, musíbýt všechny záznamy v protokolu, týkající se tohoto bloku, uloženy na stabilní paměti Pravidlo write-ahead logging verze: Jaro 2014 Transakce a řízení souběhu 55 Vyrovnávací paměti datových bloků DBMS udržuje v primárnípaměti sadu vyrovnávacích pamětí na datové bloky (database buffer) Kdyžje třeba nový blok a sada je plná, je nutno uvolnit paměť dosud obsazenou jiným blokem (oběť) Byl-li obsah bloku modifikován, je nutno ho uložit na disk Obsahuje-li takový blok nepotvrzenéaktualizace, pak všechny záznamy v protokolu týkajícíse tohoto bloku musíbýt na stabilnípaměti dříve, nežse začne příslušný blok vypisovat na disk write-ahead logging Když je blok ukládán na disk, nelze připustit žádné aktualizační operace s tímto blokem. To lze zajistit následovně: Transakce musízískat výlučný zámek (X-lock) k bloku obsahujícímu modifikovanou datovou položku ještě před zápisem datové položky Zámek lze uvolnit, jakmile je modifikace provedena Blok je uzamčen velmi krátkou dobu Systém musízískat výlučný zámek vyrovnávacího bloku před pokusem o jeho zápis na disk verze: Jaro 2014 Transakce a řízení souběhu 56
Správa vyrovnávacích pamětí Sada vyrovnávacích pamětív reálnépaměti v oblasti vyhrazenédatabázi Paměťje fixněrozdělena předem na vyrovnávacípaměťa prostor pro ostatníaplikace (včetnědatabázového stroje), cožomezuje pružnou práci. Požadavky se v čase mění, ale zde je vše rozděleno dopředu. Běžně se vyrovnávací paměti umisťují do virtuální paměti Nevýhoda: Kdyžoperačnísystém potřebuje obětovat stránku a ta byla modifikována, musíji napřed vykopírovat do odkládacího prostoru na disku Kdyžse DBMS rozhodne, že vyrovnávacípaměťbloku je třeba vypsat na disk a stránka s tímto blokem je odložena, musíji OS napřed zavést do paměti, aby ji DBMS mohl opět uložit na disk (ale jinam). To vede ke zbytečným I/O přenosům. V ideálním případě, potřebuje-li OS obětovat stránku s vyrovnávacípamětí, měl by předat řízenídatabázi, kteráby měla 1. Vypsat stránku do databáze místo do odkládacího prostoru (samozřejmě za dodržení pravidla write-ahead logging) 2. Uvolnit stránku pro potřeby OS Bohužel OS většinou takovou funkcionalitu neposkytují verze: Jaro 2014 Transakce a řízení souběhu 57 Dotazy verze: Jaro 2014 Transakce a řízení souběhu 58