COMPUTERWORLD
pod kapotou
Transakce

O když si to nikdo nepřeje, také počítač podléhá chybám. Tyto chyby mohou být hardwarové (poruchy v síti, zhroucení disku) i čistě programátorské (chyba v operačním systému, SŘBD, či uživatelském programu). Typickým případem může být situace, kdy se spustí program měnící data v databázi. Dojde-li např. v průběhu chodu programu k výpadku systému, není po restartu známo, která data byla v databázi skutečně změněna a která data zůstala ve vyrovnávacích pamětech v okamžiku výpadku, tj., která data jsou ztracena. Důsledkem takového zpracování může být nekonzistence databáze.

Problému lze čelit definováním vhodné programové jednotky a vhodných mechanismů, které zabezpečí, že po skončení práce programu zůstane konzistence databáze zachována. V databázových pojmech to znamená, že v novém stavu databáze splňuje všechna integritní omezení definovaná ve schématu databáze. Jednotka uvedených vlastností se nazývá transakce. Transakce zachovává konzistenci databáze, i když, např. v průběhu provádění transakce, může být konzistence dočasně narušena (obrázek 1). Transakce končí v přijatelném čase. Program - transakce se tedy buď provede řádně celý nebo se neprovede vůbec.

Uvědomme si, že okolo nás se realizuje tisíce transakcí ve stejném slova smyslu. I taková posloupnost akcí jako je: < objednávka zboží, jeho dodávka, zaplacení, zjištění závady, navrácení zboží, navrácení peněz> je také transakcí. Pouze databázi představuje svět objektů a vztahů okolo nás.


čas

začátek Ti průběh Ti konec Ti

Ti

databáze je databáze je databáze je

v konzistentním dočasně v nekonzistentním v konzistentním

stavu stavu stavu

Obr.1 Běh transakce

Databázová praxe ovšem vyžaduje přístup více uživatelů, tj. paralelní zpracování transakcí. Není možné provádět transakce za sebou, nýbrž souběžně tak, že operace prováděné v transakcích jsou navzájem proloženy. Docílí se tak větší pružnosti ve využití zdrojů (procesor, periférie, ...) a tím i zlepšení celkového provozu zpracování uživatelských požadavků. Je však třeba docílit transparence paralelního zpracování, tj. očekává se, že databáze zůstává konsistentní a každému uživateli zdá, jakoby pracoval se systémem sám, bez jakékoliv interference s ostatními uživateli.

Transakční zpracování je také základem úspěšného systémového řešení zotavení z chyb. Atomicita vzhledem k chybám (failure atomicity) znamená udržet databázi v konzistentním stavu, i když se vyskytne chyba. Další zobecnění vede ke transakcím v distribuovaných DBS, tj. v případech, kdy více uživatelů přistupuje současně k více databázím.

Architekturu software pro transakční zpracování v DBS lze popsat pomocí tří modulů (obrázek 2). Komunikaci s databází pomocí požadavků na čtení a zápis dat zajišťuje manažer dat. Zodpovídá také za zotavení z chyb systému, tj. zajišťuje atomicitu vzhledem k chybám. Za řízení paralelního zpracování transakcí je zodpovědný modul, který se nazývá rozvrhovač (angl. scheduler). Jeho úkolem je zajistit transparenci paralelního zpracování. Komunikaci mezi rozvrhovačem a aplikačním programem zajišťuje manažer transakcí. Ten vyvolává transakci a posílá požadavky na data manažeru dat prostřednictvím rozvrhovače. Obecně nemusí být transakční zpracování nutně součástí databázového software, může patřit pod operační systém nebo být realizováno samostatným softwarovým modulem. Systémem pro zpracování transakcí (SZT) je např. slavný CICS (firma IBM) pro MVS, či moderní softwarový produkt ACMxp (firma DEC), který představuje portabilní transakční monitor podporující standardy pro otevřené zpracování transakcí. Standardizovaný transakční manažer má být součástí NT4 a WIN96.


aplikační manažer rozvrhovač manažer




program transakcí dat databáze

Obr. 2 Architektura transakčního zpracování v DBS

A nyní trochu přesněji. Transakce je jistá posloupnost nebo specifikace posloupnosti akcí, jako jsou čtení, zápis, výpočet, se kterou se zachází jako s jedním celkem (např. několik aktualizačních operací nebo dotaz v SQL).

Uvažujme příklad, kdy chceme změnit číslo čtenáře z hodnoty H38 na I45. Je zřejmé, že nelze změnit pouze hodnotu v jednom řádku tabulky ČTENÁŘ, ale také všechny potřebné řádky tabulek VÝPŮJČKY a REZERVACE. Transakce, která byla v přirozeném jazyce vyjádřena jednou větou, tedy není vyjádřitelná v SŘBD jednou databázovou operací (např. operace UPDATE aplikovaná na jednu relaci), nýbrž posloupností takových operací. Program implementující tuto transakci dokonce obecně pro změnu čísla libovolného čtenáře může vypadat následovně:

Begin_transaction Změna_čísla_čtenáře (1)

begin

input(staré_číslo, nové_číslo); (2)

read (temp, ČTENÁŘ.Č_ČT = staré_číslo); (3)

if temp = empty then begin (4)

output(“čtenář neexistuje”) (5)

ABORT (6)

end

else begin modify1(ČTENÁŘ, staré_číslo, nové_číslo); (7)

modify2(VÝPŮJČKY, staré_číslo, nové_číslo); (8)

modify3(REZERVACE, staré_číslo, nové_číslo); (9)

end

end_transaction (11)

Operace read (řádek 3) a modify (řádky 7-9) mohou být implementovány pomocí hostitelské verze SQL. Operace Begin_transaction (nebo START, BOT) a end_transaction (nebo EOT) označují počátek a konce transakce. Řádky 1 a 11 tedy slouží jako závorky naznačující SZT, že množina řádků mezi nimi se chápe při volání programu jako atomická. Příkaz ABORT na řádku 6 znamená ukončení transakce (je ekvivalentní příkazu EXIT) v případě, že neexistuje řádek v relaci ČTENÁŘ s klíčem staré_číslo. Obecně ABORT (či ROLLBACK) znamená, že běh transakce je zastaven a že databáze musí být uvedena do původního stavu (v daném případě ke změnám nedošlo, takže k žádným akcím nedochází). Příkaz může být také inicializován programem transakce, ale SZT, např. v případě chyby.

Všimněme si, že v momentě opravy čísla čtenáře v relacích ČTENÁŘ a VÝPŮJČKY, a před opravou v relaci REZERVACE, databáze není v konzistentním stavu.

SŘBD, který podporuje zpracování transakcí, ovšem nezaručuje, že transakce bude vždy provedena do konce. V případě, že např. vypadne systém v průběhu zpracování transakce, je nutné, aby byl pomocí SŘBD stav databáze obnoven na stav před započetím provádění transakce. Aby se uživateli transakce jevila jako jedna atomická operace, jsou nutné příkazy COMMIT a ROLLBACK. První z nich signalizuje SŘBD úspěšnost provedení transakce (tj. je zajištěno, že veškeré změny databáze se stanou persistentními a mohou být zviditelněny dalším transakcím), druhý signalizuje opak (tj. databáze musí být reorganizována do původního stavu). V praxi není nutné vyvolávat operaci COMMIT explicitně, stačí normální ukončení programů realizujících transakci. V našem příkladě transakce slouží jako implicitní příkaz COMMIT příkaz End_transaction. Příkazu COMMIT říkáme česky potvrzení. Po jeho provedení jsou tedy výsledky transakce trvalé (tj. nevratné např. operací UNDO) a viditelné. Příkaz ROLLBACK zajišťuje návrat do stavu databáze pře započetím transakce. K tomu je třeba použit tzv. žurnálu (angl. log file) na nějakém stabilním paměťovém médiu. Žurnál je vlastně další databáze obsahující historii všech změn uživatelské databáze v jisté časové periodě.

Některé transakce nemění stav databáze. Patří k nim např. transakce read-only (dotazy). Ostatní transakce jsou aktualizační.

Transakce se může dostat do jednoho z pěti stavů:

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

Ve stavech AB nebo C říkáme, že transakce je ukončena. Ze stavu F vstupuje po provedení operace ROLLBACK (nebo UNDO) do stavu AB. V případě částečně potvrzeného stavu se může transakce dostat do stavu F, protože např. díky výpadku systému nemusí být vyrovnávací paměti odeslány na disk. V případě stavu AB máme dvě možnosti - buď restartujeme transakci, nebo ji ponecháme zrušenou (např. do okamžiku, kdy je opravena logická chyba programu).

Jednotlivé stavy transakce lze zobrazit stavovým diagramem na obrázku 3.

 

 

 

 

 

Obr. 3 Stavy transakce

Zatím se zdá, že na transakcích není nic příliš zajímavého. V dalších pokračováních databázové abecedy však uvidíme, že vše se zesložití, když běží najednou více transakcí. Dokonce se dá říci, že řešení těchto problémů je v databázích primární a s rozvojem sítí představuje téma, které se stále zkoumá.



<seznam dílů seriálu>   <COMPUTERWORLD>