docDATABÁZOVÉ A INFORMAˇCNÍ SYSTÉMY
download 
Stížnost Transkript
DATABÁZOVÉ A INFORMAˇCNÍ SYSTÉMY
DAIS – 3. Transakce, zotavení 1/48 DATABÁZOVÉ A INFORMAČNÍ SYSTÉMY Michal Krátký [email protected] Katedra informatiky Fakulta elektrotechniky a informatiky VŠB – Technická univerzita Ostrava 2012/2013 DAIS – 3. Transakce, zotavení O BSAH P ŘEDNÁŠKY 1. Zotavení, řízení transakcí 2. Transakce 3. Zotavení systému 4. Transakce v SQL 2/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Z OTAVENÍ Zotavení (angl. recovery) znamená zotavení databáze z nějaké chyby (přetečení hodnoty atributu, pád systému). I Budeme se bavit především o velkých SŘBD, které zotavení řeší. I Při jakékoli chybě musí být databáze v korektním stavu. Jinými slovy: výsledkem zotavení musí být korektní stav databáze. I K dosažení tohoto stavu často využíváme nějaké redundantní informace, která je pro uživatele (za normálních okolností) skryta. I Při zotavení pak SŘBD využívá tuto redundantní informaci pro rekonstrukci databáze v nekorektním stavu. 3/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Transakce T RANSAKCE Transakce je logická (nedělitelná, atomická) jednotka práce s databází, která začíná operací BEGIN TRANSACTION a končí provedením operací COMMIT nebo ROLLBACK. 4/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Transakce P ŘÍKLAD TRANSAKCE Chceme převést 100Kč z úctu číslo 345 na účet číslo 789. BEGIN TRANSACTION; try { UPDATE Account 345 { balance -= 100; } UPDATE Account 789 { balance += 100; } COMMIT; } catch(SqlException) { ROLLBACK; } Je zřejmé, že převod musí být proveden jako jedna nedělitelná operace, ačkoli se jedná o dvě operace UPDATE. V tomto případě je databáze po provedení první operace UPDATE v nekorektním stavu – databáze nereflektuje stav reálného světa: 100Kč zmizelo. 5/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Transakce V LASTNOSTI TRANSAKCÍ I Obecně tedy transakce jako logická jednotka práce s databází nezahrnuje jednu databázovou operaci, ale častěji posloupnost operací. I Úkolem transakce je převést korektní stav databáze na jiný korektní stav, přičemž nemusí zanechat databázi v korektním stavu po jednotlivých operacích transakce. Poznámka: Abychom splnili podmínku korektnosti, musíme v tomto případě provést obě nebo žádnou operaci UPDATE. 6/48 DAIS – 3. Transakce, zotavení 7/48 Transakce, zotavení Transakce Z OTAVENÍ I Jak může dojít k chybě při provádění transakcí? I Rozlišujeme: I I lokální chyby: chyba v dotazu, přetečení hodnoty atributu I chyby globální I chyby systémové (soft crash): výpadek proudu, pád systému či SŘBD I chyby média (hard crash) Komponenta SŘBD, která se stará o řízení transakcí se nazývá manager transakcí (angl. transaction management) nebo monitor transakčního zpracování (angl. transaction processing monitor). DAIS – 3. Transakce, zotavení 8/48 Transakce, zotavení Transakce F REKVENCE VÝSKYT Ů A ČAS ZOTAVENÍ PRO ZÁKLADNÍ TYPY CHYB Theo Härder and Andreas Reuter: Principles of Transaction-Oriented Database Recovery. ACM Computing Survey, Vol. 15(4), ACM Press, 1983: Typ chyby Popis chyby Lokální Přetečení hodnoty atributu, syntaktická chyba v SQL příkazu Pád systému Chyba disku Systémová Chyba média Frekvence výskytu 10-100/min Čas zotavení Několik za týden 1-2/rok Několik minut 1-2 hodiny Stejný jako je čas provedení transakce DAIS – 3. Transakce, zotavení Transakce, zotavení Transakce U KON ČENÍ TRANSAKCÍ Programátor transakce řídí pomocí operací: I COMMIT – signalizuje úspěšné ukončení transakce. Programátor oznamuje transakčnímu manageru, že transakce byla úspěšně dokončena, databáze je nyní v korektním stavu, a všechny změny provedené v rámci transakce mohou být trvale uloženy v databázi. Jinými slovy všechny změny jsou potvrzeny (angl. comitted) pro trvalé uložení v databázi. I ROLLBACK – signalizuje neúspěšné provedení transakce. Programátor oznamuje transakčnímu manageru, že databáze může být v nekorektním stavu a všechny změny provedené v rámci transakce musí být zrušeny (angl. roll back nebo undo). 9/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Transakce U KON ČENÍ TRANSAKCÍ , P ŘÍKLAD BEGIN TRANSACTION; try { UPDATE Account 345 { balance -= 100; } UPDATE Account 789 { balance += 100; } COMMIT; } catch(SqlException) { ROLLBACK; } V tomto případě jsou operací COMMIT zaznamenány nové částky na obou účtech; v případě nějaké chyby, operace ROLLBACK nastaví částky na obou účtech na hodnoty platné před začátkem transakce. 10/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Transakce JAK JE MOŽNÉ ZRUŠIT ZM ĚNY PROVEDENÉ V RÁMCI TRANSAKCE ? I Programátor připojením k SŘBD nepracuje přímo s datovým souborem. I SŘBD se skládá z celé řady komponent a programátor, naštěstí, nemůže přímo pracovat s fyzickou reprezentací dat. I Pro podporu operace ROLLBACK má systém k dispozici log nebo journal na disku kde jsou zaznamenány detaily o všech provedených operacích. I V případě ROLLBACK operace je systém na základě záznamu v logu schopen vrátit hodnoty příslušného záznamu na původní hodnoty. 11/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Transakce T RANSAKCE , VLASTNOSTI 1/2 I Zotavení a transakce přináší větší režii systému, nicméně drtivé množství aplikací se bez nich neobejde. I Na první pohled je patrné, že zotavení úzce souvisí s paralelním během transakcí (tzv. souběhem), v této chvíli ale nebudeme souběh uvažovat. 12/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Transakce T RANSAKCE , VLASTNOSTI 2/2 I V této chvíli se budeme zajímat o transakce jako o prostředek zotavení: jakmile po UPDATE/DELETE/INSERT zadám COMMIT, databázový systém nesmí za žádných okolností o tyto aktualizace přijít. I Transakce nemůže být uvnitř jiné transakce, tedy BEGIN TRANSACTION se nemůže vyskytovat bez toho aby předchozí transakce byla ukončena operací COMMIT nebo ROLLBACK. Tato vlastnost plyne z nedělitelnosti transakcí. 13/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Transakce KOREKTNÍ VS KONZISTENTNÍ STAV DATABÁZE ? I Pojem konzistentní databáze znamená přesně to, že v databázi neexistují žádné výjimky z daných integritních omezení. I V příkladu s převodem peněz mezi účty nejsme schopni žádné integritní omezení definovat. I Proto tedy říkáme, že transakce je posloupnost operací převádějící databázi v korektním stavu do jiného korektního stavu. I Pojem korektní má tedy ten význam, že respektujeme výsledek operací, který jsou vykonány v reálném světě. 14/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Zotavení transakce P OTVRZOVACÍ BOD 1/2 I Transakce začíná vykonáním operace BEGIN TRANSACTION a končí vykonáním COMMIT nebo ROLLBACK. I Operace COMMIT zavádí tzv. potvrzovací bod (angl. commit point, u starších systémů mluvíme o synchpoint, tedy o synchronizačním bodu). I Potvrzovací bod odpovídá úspěšnému ukončení logické jednotky práce s databází a představuje tedy bod ve kterém je databáze v korektním stavu. I Naproti tomu ROLLBACK vrací databázi do stavu ve kterém byla při vykonání BEGIN TRANSACTION, jinými slovy vrací databázi k předchozímu potvrzovacímu bodu. 15/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Zotavení transakce P OTVRZOVACÍ BOD 2/2 V okamžiku potvrzení transakce jsou: I všechny změny provedené v rámci transakce trvale uloženy v databázi, I všechny adresace (např. ty nastavené pomocí kurzorů) a zámky entic uvolněny (viz pozdější přednášky). Z předchozího výkladu je zřejmé, že transakce není jen jednotkou práce s databází, ale rovněž jednotkou zotavení: pokud systém zhavaruje, uživatel musí mít k dispozici databázi, která bude obsahovat všechny potvrzené změny. 16/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Zotavení transakce Z P ŮSOBY IMPLEMENTACE S ŘBD I Všechny aktualizace jsou uloženy v paměti ⇒ po pádu systému přijdeme o data. I Všechny aktualizace jsou uloženy okamžitě na disk ⇒ výsledkem bude pomalý (nepoužitelný) systém. I Práce s pamětí je o tři řády rychlejší než práce s diskem. I Pamět’: až GB/s I Sekvenční čtení/zápis na disk: desítky-stovky MB/s I Náhodné čtení/zápis na disk: stovky kB/s (SSD poskytují vyšší propustnost). 17/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Zotavení transakce I MPLEMENTAČNÍ DETAILY 1/3 I Z důvodu efektivity používá SŘBD vyrovnávací pamět’ umístěnou v hlavní paměti (angl. cache buffer) obsahující aktuální záznamy z databáze. I Může se tedy stát, že potvrzené záznamy nebyly před pádem systému fyzicky zapsány na disk. Přesto musí být systém schopen zotavení. 18/48 DAIS – 3. Transakce, zotavení Transakce, zotavení Zotavení transakce I MPLEMENTAČNÍ DETAILY 2/3 I Všechny změny musí být zapsány do logu před samotným zápisem změn do databáze. Před ukončením vykonávání operace COMMIT je do logu zapsán tzv. COMMIT záznam. I Takovéto pravidlo nazýváme pravidlo dopředného zápisu do logu (angl. write-ahead log rule). Systém je pak schopen na základě informací z logu provést zotavení databáze. 19/48 DAIS – 3. Transakce, zotavení 20/48 Transakce, zotavení Zotavení transakce I MPLEMENTAČNÍ DETAILY 3/3 Cache Buffer data DBMS data/příkazy log Disk data Tabulky Indexy ... SELECT … UPDATE … DELETE ... DAIS – 3. Transakce, zotavení Transakce, zotavení Zotavení transakce L OG VS DATA I Proč není možné zapsat aktualizace do databáze na disku, ale můžeme zapsat záznamy do logu na disku (z pohledu efektivity)? I Aktualizace dat jsou často řešeny náhodnými zápisy do souborů datových struktur. Rychlost řádově stovky kB/s. I Do logu zapisujeme na konec sekvenčním zápisem (desítky–stovky MB/s). 21/48 DAIS – 3. Transakce, zotavení Transakce, zotavení ACID V LASTNOST ACID Každá transakce musí splňovat vlastnost ACID: atomičnost (angl. atomicity), korektnost (angl. correctness), izolovanost (angl. isolation) a trvalost (angl. durability): I A - Atomičnost – transakce musí být atomická: jsou provedeny všechny operace transakce nebo žádná. I C - Korektnost – transakce převádí korektní stav databáze do jiného korektního stavu databáze, mezi začátkem a koncem transakce nemusí být databáze v korektním stavu. I I - Izolovanost – transakce jsou navzájem izolovány: změny provedené jednou transakcí jsou pro ostatní transakce viditelné až po provedení COMMIT. I D - Trvalost – jakmile je transakce potvrzena, změny v databázi se stávají trvalými i po případném pádu systému. 22/48 DAIS – 3. Transakce, zotavení Zotavení systému v případě globální chyby Z OTAVENÍ SYSTÉMU I Zotavení není vázáno pouze na jednu transakci, ale i na celý databázový systém. I Takovéto zotavení je nutné v případě globálních chyb (chyba systému, chyba média apod.). I Tato chyba ovlivňuje všechny transakce ve kterých se vyskytla, na rozdíl od chyb lokálních, které se týkají pouze transakce jedné. I V případě chyby média ovšem navíc dochází ke zničení části databáze. 23/48 DAIS – 3. Transakce, zotavení Zotavení systému v případě globální chyby Zotavení po systémové chybě Z OTAVENÍ SYSTÉMU I Základním problémem vzniklým při systémové chybě, je ztráta obsahu hlavní paměti, tedy ztráta obsahu vyrovnávací paměti SŘBD. I Přesný stav transakce přerušené chybou není tedy znám a transakce musí být zrušena (angl. undo). Pro tuto akci budeme často používat označení UNDO. I Někdy je transakce úspěšně ukončena, ovšem změny nejsou přeneseny z vyrovnávací paměti na disk. V tomto případě musí být po restartu systému transakce přepracována (angl. redo). Pro tuto akci budeme často používat označení REDO. 24/48 DAIS – 3. Transakce, zotavení Zotavení systému v případě globální chyby Zotavení po systémové chybě KONTROLNÍ BODY I Z důvodu efektivity nezapisujeme do databáze na disk všechny potvrzené aktualizace. I Aby SŘBD věděl, které operace musí být pro danou transakci provedeny, vytváří tzv. kontrolní body (angl. check points). Kontrolní body jsou vytvářeny např. po určitém počtu záznamů, které byly zapsány do logu a zahrnují: I I zápis obsahu vyrovnávací paměti na disk, I zápis záznamu o kontrolním bodu do logu. Záznam o kontrolním bodu zahrnuje všechny transakce vykonávané v době vytvoření kontrolního bodu. 25/48 DAIS – 3. Transakce, zotavení 26/48 Zotavení systému v případě globální chyby Zotavení po systémové chybě KONTROLNÍ BODY, P ŘÍKLAD 1/4 Transakce T5 T4 T3 T2 T1 Kontrolní bod tc Systémová chyba tf Čas DAIS – 3. Transakce, zotavení 27/48 Zotavení systému v případě globální chyby Zotavení po systémové chybě KONTROLNÍ BODY, P ŘÍKLAD 2/4 I Systémová chyba nastala v čase tf . Transakce T5 T4 T3 Kontrolní bod tc byl vytvořen ze T T všech kontrolních bodů nejpozději před tím než nastala systémová Systémová chyba Kontrolní bod t t chyba. I Transakce typu T1 byla úspěšně dokončena před časem tc . I 2 1 c f I Transakce typu T2 začala před časem tc , byla úspěšně dokončena po tc a před tf . I Transakce typu T3 začala před časem tc nebyla ale dokončena před tf . I Transakce typu T4 začala po tc a byla dokončena před tf . I Transakce typu T5 začala po tc , ale nebyla dokončena před tf . Čas DAIS – 3. Transakce, zotavení 28/48 Zotavení systému v případě globální chyby Zotavení po systémové chybě KONTROLNÍ BODY, P ŘÍKLAD 3/4 Transakce T5 T4 T3 T2 T1 Kontrolní bod tc Systémová chyba tf Čas I Po restartu systému musí být transakce typu T3 a T5 zrušeny (undo). I Transakce typu T2 a T4 musí být přepracovány (redo). I Jelikož změny provedené transakcí T1 byly provedeny před kontrolním bodem tc , tuto transakci při zotavení vůbec neuvažujeme. DAIS – 3. Transakce, zotavení Zotavení systému v případě globální chyby Zotavení po systémové chybě Z OTAVENÍ : UNDO A REDO FÁZE Po restartu SŘBD spustí tento algoritmus: 1. Vytvoř dva seznamy transakcí: UNDO a REDO. 2. Do UNDO vlož všechny transakce, které nebyly úspěšně dokončeny před posledním kontrolním bodem. Seznam REDO je prázdný. 3. Začni procházet záznamy v logu od záznamu posledního kontrolního bodu. 3.1 Pokud je pro transakci T nalezen v logu záznam BEGIN TRANSACTION, ponech T v seznamu UNDO. 3.2 Pokud je pro transakci T nalezen v logu záznam COMMIT, přesuň T ze seznamu UNDO do seznamu REDO. 29/48 DAIS – 3. Transakce, zotavení 30/48 Zotavení systému v případě globální chyby Zotavení po systémové chybě KONTROLNÍ BODY, P ŘÍKLAD 4/4 Transakce T5 T4 T3 T2 T1 Kontrolní bod tc Systémová chyba tf Čas Po skončení algoritmu obsahuje seznam UNDO transakce T3 a T5 a seznam REDO transakce T2 a T4 . Nyní systém prochází log zpětně a ruší transakce ze seznamu UNDO (tedy jejich jednotlivé operace), poté prochází logem dopředu a přepracovává transakce ze seznamu REDO. Po zpracování obou seznamů je zotavení ukončeno a systém je připraven k dalšímu provozu. DAIS – 3. Transakce, zotavení Zotavení systému v případě globální chyby Zotavení po chybě média Z OTAVENÍ PO CHYB Ě MÉDIA I Zotavení v případě chyby média začíná obnovením databáze ze záložní kopie popř. dump souboru1 . I V dalším kroku je procházen log a všechny transakce, které byly dokončeny po čase vytvoření zálohy jsou přepracovány. I V tomto případě nejsou žádné transakce zrušeny: aktualizace byly zrušeny prostou ztrátou dat. 1 Tento soubor obsahuje úplný obraz databáze a je vytvářen z databáze popř. využit pro rekonstrukci databáze nejčastěji utilitami dump/restore nebo unload/reload. 31/48 DAIS – 3. Transakce, zotavení Základní techniky zotavení Z ÁKLADNÍ TECHNIKY ZOTAVENÍ Dosud jsem popsali koncepty zotavení, nyní si představíme dvě základní techniky zotavení: I zotavení odloženou aktualizací, I zotavení okamžitou aktualizací. Tyto názvy se vztahují k aktualizaci logu a datového souboru. 32/48 DAIS – 3. Transakce, zotavení Základní techniky zotavení Z OTAVENÍ ODLOŽENOU AKTUALIZACÍ 1/2 I Zotavení odloženou aktualizací (angl. deferred update) neprovádí aktualizaci databáze na disku dokud transakce nedosáhne potvrzovacího bodu: všechny aktualizace databáze jsou zaznamenány do pamět’ového bufferu. I Jakmile transakce dosáhne potvrzovacího bodu (je zadán COMMIT), aktualizace jsou nejprve zaznamenány do logu a následně do databáze (pravidlo dopředného zápisu do logu). I Pokud transakce selže, není nutné provést UNDO (databáze nebyla aktualizovaná). 33/48 DAIS – 3. Transakce, zotavení Základní techniky zotavení Z OTAVENÍ ODLOŽENOU AKTUALIZACÍ 2/2 I REDO bude provedeno v případě kdy systém zapsal aktualizace do logu, ale k zapsání změn do databáze nedošlo. I Do logu jsou v případě odložené aktualizace zapsány nové hodnoty (kvůli REDO). I Tato technika zotavení se nazývá NO-UNDO/REDO algoritmus. I Ačkoli se tato technika zdá výkonná (zejména z pohledu minimalizace I/O), v praxi se používá pouze v případě, kdy systém provádí krátké transakce a každá transakce mění pouze několik málo položek. Pro ostatní typy transakcí hrozí přetečení popř. velká expanze lokálních bufferů. 34/48 DAIS – 3. Transakce, zotavení Základní techniky zotavení Z OTAVENÍ OKAMŽITOU AKTUALIZACÍ 1/2 I Zotavení okamžitou aktualizací (angl. immediate update) může provádět aktualizace databáze na disku před tím než transakce dosáhne potvrzovací bod. I Operace jsou v tomto případě zapsány do logu vynuceným zápisem a poté je aktualizována databáze (pravidlo dopředného zápisu do logu). I Pokud transakce selže před dosažením potvrzovacího bodu a během provádění transakce došlo k aktualizaci databáze, pak je nutné provést UNDO. I V případě okamžité aktualizace ukládáme do logu původní hodnoty, což umožní systému provést při zotavení operaci UNDO. 35/48 DAIS – 3. Transakce, zotavení Základní techniky zotavení Z OTAVENÍ OKAMŽITOU AKTUALIZACÍ 2/2 I V tomto případě budou pro zotavení aplikovány jak operace UNDO tak operace REDO, proto tuto techniku nazýváme UNDO/REDO algoritmus. I Ve speciálním případě, kdy jsou všechny aktualizace transakce zapsány do databáze před dosažením potvrzovacího bodu (a při zotavení tedy odpadá REDO), pak mluvíme o UNDO/NO-REDO algoritmu. 36/48 DAIS – 3. Transakce, zotavení Základní techniky zotavení Z OTAVENÍ VS SOUB ĚH I V některých aktuálních databázových systémech (např. Key-value DBMS), nejsou, kvůli dosažení maximálního výkonu, podporovány transakce pro řešení problémů paralelního přístupu, ale pouze jako prostředek pro zotavení. I Programátor má zaručeno, že jednou potvrzené aktualizace se z databáze neztratí (z ACID tedy například dodržujeme jen ACD ne I). I V relačních SŘBD není možné řešení paralelního běhu transakcí vypnout, to je jeden z důvodu, proč takové databáze poskytují nižší propustnost než některé specializované SŘBD. 37/48 DAIS – 3. Transakce, zotavení Transakce v SQL Záchranné body Z ÁCHRANNÉ BODY I Transakci jsme dosud prezentovali jako nedělitelnou jednotku práce s databázi. I Koncept záchranných bodů (angl. savepoints) zavedený v SQL99, ale transakci rozděluje na menší části. I V případě operace ROLLBACK nedochází ke zrušení celé transakce, ale k návratu na záchranný bod. I Musíme si uvědomit, že záchranný bod není ekvivalentní potvrzení změn: změny provedené transakcí nejsou stále viditelné pro ostatní transakce dokud ta neprovede operaci COMMIT. 38/48 DAIS – 3. Transakce, zotavení Transakce v SQL Transakce v SQL T RANSAKCE V SQL I Transakce v SQL následují teorii, která byla popsána v předchozích kapitolách. I Všechny SQL příkazy jsou atomické2 . I Operace BEGIN TRANSACTION se v SQL provede příkazem START TRANSACTION, operace COMMIT příkazem COMMIT WORK a operace ROLLBACK příkazem ROLLBACK WORK. I Při práci s databázovým systémem musíme dát pozor zejména na AUTOCOMMIT ⇒ Pokud je nastaveno AUTOCOMMIT ON pak operace ROLLBACK nedává smysl. 2 s výjimkou příkazů CALL a RETURN 39/48 DAIS – 3. Transakce, zotavení Transakce v SQL Transakce v SQL S YNTAXE P ŘÍKAZU START TRANSACTION 1/2 START TRANSACTION <volitelné parametry>; Kde <volitelné parametry> specifikují režim přístupu (angl. access mode), úroveň izolace (angl. isolation level) a velikost diagnostikované oblasti (angl. diagnostics area size): 40/48 DAIS – 3. Transakce, zotavení Transakce v SQL Transakce v SQL S YNTAXE P ŘÍKAZU START TRANSACTION 2/2 I Úroveň izolace zadáváme ve tvaru ISOLATION LEVEL <izolace>, kde <izolace> je READ UNCOMMITED, READ COMMITED, REPEATABLE READ a SERIALIZABLE (viz další přednášky). I Režim přístupu může být READ ONLY nebo READ WRITE. Pokud nespecifikujeme žádný režim, je nastaven READ WRITE. Pokud ovšem zvolíme úroveň izolace READ UNCOMMITED, pak je nastaven režim READ ONLY. Pokud tedy zvolíme režim READ WRITE, pak úroveň izolace nesmí být READ UNCOMMITED. I Velikost diagnostikované oblasti se nastavuje jako celé číslo uvedené za klíčovým slovem DIAGNOSTICS SIZE a specifikuje kolik výjimek bude systém ukládat na zásobníku. 41/48 DAIS – 3. Transakce, zotavení Transakce v SQL Transakce v SQL S YNTAXE COMMIT A ROLLBACK COMMIT [WORK] [AND [NO] CHAIN]; ROLLBACK [WORK] [AND [NO] CHAIN]; I Vidíme tedy, že WORK je doplňkové slovo a implicitní volba je AND NO CHAIN. I AND CHAIN automaticky vykoná START TRANSACTION se stejnými parametry jako v předchozím případě po provedení COMMIT. I Po potvrzení transakce jsou automaticky uzavřeny všechny kurzory, je tedy proveden CLOSE, s jedinou výjimkou kurzoru deklarovaného jako WITH HOLD (viz další přednášky). 42/48 DAIS – 3. Transakce, zotavení Transakce v SQL Transakce v SQL Z ÁCHRANNÉ BODY V SQL I Záchranný bod je vytvořen příkazem: SAVEPOINT <jméno záchranného bodu>; I Příkazem ROLLBACK TO <jméno záchranného bodu>; provedeme zrušení všech operací provedených za specifikovaným záchranným bodem. I Příkaz RELEASE <jméno záchranného bodu>; zruší specifikovaný záchranný bod, po tomto příkazu tedy nemůže provést ROLLBACK k tomuto bodu. I Po ukončení transakce jsou automaticky zrušeny všechny záchranné body. 43/48 DAIS – 3. Transakce, zotavení 44/48 Transakce v SQL Transakce v SQL T RANSAKCE V PL/SQL, P ŘÍKLAD I, 1/2 Vezměme v úvahu tabulku Student: CREATE TABLE Student ( login CHAR(5) PRIMARY fname VARCHAR(30) NOT lname VARCHAR(30) NOT email VARCHAR(40) NOT ); KEY, NULL, NULL, NULL DAIS – 3. Transakce, zotavení 45/48 Transakce v SQL Transakce v SQL T RANSAKCE V PL/SQL, P ŘÍKLAD I, 2/2 Nyní chceme vložit do databáze záznamy o dvou studentech, v případě chyby nebude vložen ani jeden záznam. BEGIN INSERT INTO Student VALUES(’sob28’, ’Jan’, ’Sobota’, ’[email protected]’); INSERT INTO Student VALUES(’sob28’, ’Jan’, ’Neděle’, ’[email protected]’); COMMIT; EXCEPTION WHEN OTHERS THEN ROLLBACK; END; V tomto případě se nepodaří vložit druhý záznam, celá transakce bude tedy zrušena. DAIS – 3. Transakce, zotavení Transakce v SQL Transakce v SQL T RANSAKCE V PL/SQL, P ŘÍKLAD II, 1/3 Vezměme v úvahu část schématu systému evidujícího autory a recenzenty článků. V takovém systému může být jedna osoba v celé řadě rolí (autor, recenzent, administrátor apod.). Vezměme v úvahu tabulku Person: CREATE TABLE Person ( login VARCHAR(20) PRIMARY KEY, email VARCHAR(50) UNIQUE NOT NULL, password VARCHAR(20) NOT NULL, firstName VARCHAR(20) NOT NULL, middleName VARCHAR(20), secondName VARCHAR(20) NOT NULL, email2 VARCHAR(50), web VARCHAR(70)); 46/48 DAIS – 3. Transakce, zotavení 47/48 Transakce v SQL Transakce v SQL T RANSAKCE V PL/SQL, P ŘÍKLAD II, 2/3 tabulku Role: CREATE TABLE Role ( id INT NOT NULL PRIMARY KEY IDENTITY, name VARCHAR(50) NOT NULL UNIQUE); a tabulku evidující role osob: CREATE TABLE PersonRole ( idPerson INT REFERENCES Person NOT NULL, idRole INT REFERENCES Role NOT NULL, UNIQUE(idPerson, idRole)); DAIS – 3. Transakce, zotavení Transakce v SQL Transakce v SQL T RANSAKCE V PL/SQL, P ŘÍKLAD II, 3/3 Při vložení nové osoby chceme zároveň přidat této osobě roli "Autor" (která má id=1). Transakce tedy bude vypadat takto: BEGIN INSERT INTO Person VALUES(’sob28’, ’[email protected]’, ’heslo’, ’Jan’, NULL, ’Sobota’, NULL, NULL); INSERT INTO PersonRole(’son28’, 1); COMMIT; EXCEPTION WHEN OTHERS THEN ROLLBACK; END; Pokud selže vložení osoby (např. osoba je už v systému evidována), pak vložení role osoby nedává smysl a celá transakce bude zrušena. 48/48
Podobné dokumenty
Evropský parlament
předložit prohlášení o darech s vyjádřením, zda v příslušném roce poslanec
přijal dar o hodnotě převyšující 600 EUR spolu s podrobnostmi o každém
takovém daru. Za dar se považuje každý příspěvek uč...
DATABÁZOVÉ A INFORMAˇCNÍ SYSTÉMY
Tyto proměnné mají stejný efekt jako bychom na databázi
poslali totožné dotazy, přestože za proměnou dosazujeme
pedagogická fakulta zápočtová práce databáze divadelních souborů
Představení – konkrétní uvedení hry pro diváky charakterizované datem, místem, hodinou,
zda se jedná o festival, počtem diváků a souborem.
Soubor – nabývá dvou hodnot: Kašpárek a Jitřenka.
Festival...
Práce s databází
s klientským softwarem používaného databázového systému. Je tedy nutné aby na klientské
stanici byl nainstalován příslušný software.
Pojistné podmínky
a pojistné smlouvy bude probíhat v českém jazyce. Kodex etiky v pojišťovnictví
a kodex etiky finančního trhu jsou uloženy na www.das.cz. Uzavřená pojistná
smlouva je v elektronické podobě uložena u...
Příručka k programu REVIZEprofi 2
ILLKO. V takovém případě máte nárok na vrácení uhrazeného licenčního poplatku, za předpokladu zničení všech kopií tohoto programu,
uložených na pevném disku či jakkoli jinak archivovaných, odinstal...
Uživatelská příručka k webové aplikaci Novell Filr 1.2
Dále společnost Novell, Inc. nenese žádnou zodpovědnost nebo záruky s ohledem na jakýkoli software a výslovně neuznává
jakékoli vyjádřené nebo mlčky předpokládané záruky obchodovatelnosti nebo vhod...
Amadeus Hotel Store
ubytovacích zariadení. Tento systém významne rozširuje Vaše možnosti výberu hotela a zaisťuje Vašu províziu
