![]() |
![]() |
Deník transakcí
Tak jako na každé správné lodi existuje lodní deník, každý systém zpracování transakcí (SZT) by měl používat deník transakcí. Na rozdíl od lodi, kde se z deníku dají vyčíst všechny důležité události, včetně chybných rozhodnutí vedoucích např. k poškození lodi, z deníku transakcí nad databází lze poškozenou databázi ve většině případů dokonce rekonstruovat. Deník transakcí (nebo též žurnál) tedy slouží jako prostředek k akcím, které zajišťují zotavení z chyb. Nelze ho samozřejmě použít pro všechny možné druhy chyb. Obvyklé jde o chyby typu spadnutí systému vedoucí ke ztrátě obsahu vnitřní paměti. Stav transakce se v případě chyby systému stane nedefinovaný a je nutné po restartu systému použít operaci ROLLBACK. Dále může být nutné provést po restartu systému znovu ty transakce, které byly úplné před započetím chyby systému (čas tf), ale které nebyly dokončeny fyzicky (např. nedošlo k odeslání obsahu bufferů na disk). Vyvolání operace COMMIT nebo ROLLBACK zakládá tzv. synchronizační body tj. hranice mezi dvěma po sobě následujícími transakcemi (další a poslední operací zakládající synchronizační bod je inicializace programu). V praxi ovšem rozeznává SZT požadavky na znovuprovedení transakcí pomocí kontrolních bodů (checkpoints), které jsou pro daný účel vhodnější než synchronizační body. V mechanismu synchronizačních bodů totiž krátké transakce čekají na provedení delších transakcí. Kontrolní body se vytvářejí v jistých intervalech provádění transakcí automaticky - zahrnují odeslání obsahu bufferů na disk a zápis kontrolního záznamu (checkpoint record) do žurnálu. Tento záznam může např. obsahovat seznam všech transakcí, které se v době kontrolního bodu prováděly, tj. započaly a nebyly ukončeny (stav C, tj. potvrzení neboli provedení COMMIT). Kontrolní body jsou zvlášť vhodné, pracuje-li se s delšími transakcemi. Klíčové místo práce s transakcemi je mezi stavem PC (částečné potvrzení) a C. Abychom zajistili vstup do stavu C, je možné použít jednu ze dvou nejznámějších strategií: odkládaná aktualizace a bezprostřední aktualizace. V prvním případě se neprovádí aktualizace databáze dříve, pokud transakce nedosáhne stavu PC. V případě chyby před tímto okamžikem, nesmí být databáze změněna. Případně je nutná operace REDO provádějící efekty operací pomocí žurnálu, kde jsou obsaženy všechny potřebné informace U bezprostředních aktualizací je databáze aktualizována před dosažením stavu PC. Zotavení databáze v případě chyby do stavu před započetím transakce (operace ROLLBACK) je pak možné ze žurnálu, protože každá změna do něj byla před aktualizací zahrnuta. Transakce tedy je jak jednotkou práce, tak jednotkou zotavení z chyb. Např. po provedení COMMIT musí být zajištěno, že veškeré změny byly skutečně realizovány (např. obsah bufferů byl přesunut na disk). Tedy i žurnál musí být aktualizován před vydáním signálu COMMIT. Pro obě strategie si budeme představovat žurnál jako neuspořádaný sekvenční soubor. (1) 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 transakce dostane do stavu PC. Všechny změny jsou zapisovány do žurnálu, jehož záznamy obsahují trojice <T, jméno-atributu, nová-hodnota> Na počátku provádění transakce T se do žurnálu zapíše záznam <T, START>, ve stavu PC <T, COMMIT>. Teprve potom dochází k zápisu změn do databáze. Dojde-li k chybě v čase tf před dosažením PC, stačí informaci v žurnálu ignorovat a spustit RESTART (možnost vzniku nové transakce). V případě chyby, kdy tf je za počátkem stavu PC, jsou záznamy žurnálu k dispozici pro provedení operace REDO(T), která využije záznamů mezi <T,START> a <T,COMMIT>. Zřejmě i při procesu zotavení ale může dojít k chybě. Existenci žurnálu a co největší jistotu pro možnost rekonstrukce docílíme např. vytvářením kopií žurnálů na magnetických páskách či discích. Jde opět o jistou transakci, o níž se vedou informace v žurnálu. Mělo by platit, že další provedení REDO by mělo vést ke stejnému výsledku, jako zotavení po prvním REDO (hovoří se o idempotenci operace REDO). Uvedený postup zobrazený na jedné transakci se snadno zobecní do víceuživatelského prostředí, což souvisí obecně s faktem, že každá metoda zotavení z chyb je obvykle spjata s řízením paralelismu. Platí, že čím vyšší je stupeň paralelismu, tím obtížnější je zotavení z chyb. Např. při použití dvoufázového uzamykacího protokolu jsou objekty uzamknuty až do dosažení stavu C, teprve pak jsou uvolněny. Nedochází zde také k dominovému efektu, není totiž požadován ROLLBACK transakcí. (2) Tvorba žurnálu s bezprostřední realizací změn Oproti (1) se provádějí všechny operace WRITE přímo a v žurnálu se drží kromě záznamů obsahujících START či COMMIT čtveřice <T, jméno-atributu, stará-hodnota, nová-hodnota> Umístění záznamu do žurnálu se musí provést před WRITE(X) a před fyzickou změnou databáze (provedení OUTPUT(X)). Uvedený protokol se také někdy nazývá angl. protokol write-ahead. V případě zhroucení systému je možné pomocí žurnálu uvést databázi po fyzicky nedodělaných transakcích do původního konsistentního stavu. Zotavení z chyby se provádí kromě operace REDO(T) pomocí operace UNDO(T), která návrat do stavu před transakcí umožňuje. Obrázek 1 ukazuje jednotlivé možné případy transakcí k času tf (čas chyby systému) a času tc (poslední zápis kontrolního záznamu a odeslání obsahu bufferů na disk).
čas T1 T2 T3 T4 T5
kontrolní bod čas chyby čas tc systému tf
Obr. 1 Transakce v okamžiku chyby systému Uvažujme na chvíli strategii (2) zotavení z chyb. V případě restartu systému, musí být databáze po transakcích T2 a T5 uvedena do původního stavu (operace UNDO). Transakce T3 a T4 musí být provedeny znova (operace typu REDO). Transakce T1 se po restartu neuvažuje vůbec, protože její operace byly fyzicky v čase tc již realizovány. Po restartu systému se SZT v transakcích zorientuje podle následující procedury: 1. Vytvoří se dva seznamy transakcí zvané UNDO a REDO. Do seznamu UNDO se uloží všechny transakce z kontrolního záznamu. Seznam REDO bude prázdný. 2. Začne prohledávání žurnálu od okamžiku tc směrem dopředu. 3. Narazí-li se na začátek další transakce T, přidá se T do seznamu UNDO. 4. Je-li v žurnálu nalezen COMMIT pro transakci T, odstraní se T ze seznamu UNDO a převede se do seznamu REDO. 5. Na konci žurnálu obdržíme seznamy UNDO a REDO (které pro obrázek 1 obsahují transakce T2 a T5, resp. T3 a T4). Nyní je možné přejít k zotavení po chybě. 6. SZT zpracovává zpětným chodem v žurnálu transakce z UNDO seznamu a potom, chodem vpřed, transakce z REDO seznamu. Po ukončení procedury je teprve možné pokračovat v normální práci systému. Pro strategii (1) zotavení z chyb samozřejmě operace UNDO nejsou použity. V případě na obrázku 1 by se pro transakce T2 a T5 pouze odstranila jistá část záznamů ze žurnálu. Zotavení po chybě médií znamená obvykle natáhnutí celé databáze ze záložní kopie (BACKUP) a pak použití žurnálu k znovuprovedení všech ukončených transakcí od toho okamžiku, kdy ještě žurnál poskytuje potřebné informace. Není třeba dělat žádné akce UNDO pro transakce prováděné v čase tf, protože všechny odpovídající změny v databázi byly tak jako tak ztraceny. Záložní kopie se vytvářejí na levnější médium, např. jednou za den na magnetickou pásku v minimálně jedné kopii. V případě katastrofy se použije poslední kopie databáze, transakce mezi prováděné po vzniku této kopie jsou ztraceny. Zálohuje se tedy i žurnál. Je podstatně menší než kopie databáze a může být zálohován častěji. <seznam dílů seriálu> <COMPUTERWORLD> |