Databázové systémy 2 Přednáška č. 2 RNDr. David Žák, Ph.D. Fakulta elektrotechniky a informatiky

Prezentace na téma: "Databázové systémy 2 Přednáška č. 2 RNDr. David Žák, Ph.D. Fakulta elektrotechniky a informatiky"— Transkript prezentace:

1 Databázové systémy 2 Přednáška č. 2 RNDr. David Žák, Ph.D. Fakulta elektrotechniky a informatiky david.zak@upce.cz david.zak@upce.cz

2 Obsah Transakce, transakční protokoly, žurnály Databázové systémy 2 - př. 2 2

3 Transakce Transakce je logická část, která obsahuje jeden nebo více příkazů SQL. Transakce je atomickou jednotkou. Transakce je ukončena buď: -jejím dokončením (COMMIT) -vrácením zpět/odvoláním transakce (ROLLBACK bez uvedení názvu SAVEPOINTU) -Uživatel ukončí spojení se serverem Oracle (transakce je potvrzena automaticky) -Spojení uživatele se serverem se ukončí abnormálně – transakce se odroluje zpět -explicitně, když je proveden příkaz DDL (CREATE, DROP, RENAME, ALTER), ukončí se předchozí, v samostatné transakci se provede příkaz DDL Transakce buď proběhne jako celek nebo se jako celek odvolá. Cíl: zajištění konzistence dat v databázových tabulkách a nedělitelnost provedených změn, tj. princip VŠE NEBO NIC. Databázové systémy 2 - př. 2 3

4 Transakce Příklady: -není možné připustit provedení úpravy mzdy (inflační navýšení) jen u části zaměstnanců (než bylo požadováno), (při vrácení transakce se mzda nikomu nenavýší) -není možné strhnout platbu z účtu plátce a nezaúčtovat ji na účet příjemce (z důvodů např. zrušení účtu příjemce, nesprávného účtu čísla příjemce, selhání techniky atd.). (tj. při odvolání se peníze nestrhnou ani z účtu plátce) Databázové systémy 2 - př. 2 4

5 Příklad bankovní transakce Databázové systémy 2 - př. 2 5

6 Při zpracování transakce mohou nastat problémy: Nedostatek finančních prostředků na účtu odesílatele Nesprávné číslo účtu (odesílatele nebo příjemce) Jiné omezení na účtu (exekuce) HW problém Špatně sestavený SQL dotaz Příklad bankovní transakce Databázové systémy 2 - př. 2 6

7 Transakce – základní vlastnosti ACID Atomicity (Atomičnost) - Atomičnost transakce znamená, že buď je provedena celá transakce, nebo žádná z databázových operací, které ji tvoří. Consistency (Konzistence) - Konzistence transakce znamená, že izolovaná transakce zachovává konzistenci databáze. Isolation (Izolace) - Izolace transakce znamená, že i při souběžném běhu transakcí SŘBD zajistí, že pro každou dvojici souběžných transakcí T i a T j se T i jeví, že T j skončila dříve, než T i zahájila provádění nebo T j zahájila provádění až poté, co Ti skončila. Durability (Trvalost) - Trvalost transakce znamená, že poté, co transakce úspěšně skončí, budou mít všechny změny v databázi, které transakce provedla, trvalý charakter a to i při výpadku systému. Databázové systémy 2 - př. 2 7

8 Transakce - potvrzení Potvrzení transakce (committing) znamená, že změny provedené transakcí se stávají trvalými. Explicitní potvrzení – příkazem COMMIT Implicitní potvrzení – po normálním ukončení nějaké aplikace nebo provedením DDL operace Jakékoli příkazy DDL (např. create table či alter index) způsobí tedy ukončení aktivní transakce a implicitní vytvoření nové transakce. Změny provedené příkazy obsaženými v transakci jsou viditelné pro ostatní uživatele až od okamžiku potvrzení transakce. Databázové systémy 2 - př. 2 8

9 Transakce - vytvoření Transakce je inicializována implicitně. Pokud je po dokončení transakce příkazem COMMIT následně vložen, aktualizován či odstraněn alespoň jeden řádek, je tím implicitně vytvořena nová transakce. Po zahájení transakce je jí přiřazen dostupný undo tablespace, kam se ukládají změny pro možnost provedení rollbacku. Undo informace obsahují staré hodnoty dat, které byly SQL příkazem v rámci transakce změněny. Databázové systémy 2 - př. 2 9

10 Statement-Level Rollback Pokud během provádění SQL příkazu nastane nějaká chyba, všechny změny provedené příkazem jsou odrolovány zpět. Toto se nazývá Statement-Level Rollback (rollback na úrovni příkazu). Příklady takových chyb: -Pokus o vložení řádku s duplicitní hodnotou primárního klíče -Narušení referenční integrity -Deadlock (pokus o současnou změnu shodných dat dvěma transakcemi) Syntaktická chyba při parsingu neumožní spustit provádění příkazu, proto se nejedná o Statement-Level Rollback. Chyba při provádění příkazu nezpůsobí změny provedené předchozími příkazy v rámci dané transakce. Databázové systémy 2 - př. 2 10

11 Příkazy pro řízení transakcí COMMIT – potvrzení transakce, zafixování stavu. ROLLBACK – odvolání celé transakce, návrat do původního/zafixovaného stavu, odvolat transakci je možné pouze uživatelem, který operaci provedl a jen do okamžiku jejich potvrzení příkazem COMMIT (takto můžeme například obnovit záznamy, které jsme omylem vymazali, protože jsme například zapomněli na podmínku v klauzuli WHERE) Databázové systémy 2 - př. 2 11

12 Odvolání ROLLBACK Statement level rollback (rollback příkazu) Rollback to savepoint Rollback celé transakce na žádost uživatele Rollback celé transakce z důvodu abnormálního ukončení procesu Rollback nedokončených transakcí, když dojde k ukončení instance Rollback nekompletní transakce z důvodu zotavení systému Databázové systémy 2 - př. 2 12

13 Příkazy pro řízení transakcí Použití návratových bodů: SAVEPOINT - slouží pro označení místa (například po provedení některých operací), kam bychom se v případě potřeby mohli navrátit, slouží pro rozdělení velké transakce na menší části ROLLBACK TO – odvolání transakce, návrat do bodu návratu Příklad: SAVEPOINT plosne_zvyseni_mzdy; UPDATE pracovnici SET mzda=mzda*1.04; SAVEPOINT navyseni_manazeri; UPDATE pracovnici SET mzda=mzda+1000 WHERE pozice LIKE ‘manažer’; ROLLBACK TO navyseni_manazeri; Databázové systémy 2 - př. 2 13

14 Příkazy pro řízení transakcí Po odrolování transakce k návratovému bodu: jsou vráceny pouze změny provedené SQL příkazy po nastavení návratového bodu Všechny návratové body nastavené po daném savepointu jsou ztraceny Oracle uvolní všechny uzamčené tabulky a řádky, které byly uzamčeny po nastavení návratového bodu (ty nastavené dříve zůstanou zachovány) Transakce zůstává aktivní a může dále pokračovat Databázové systémy 2 - př. 2 14

15 Základy návratové technologie Návratové tabulkové prostory (undo) zajišťují vrácení změn provedených transakcemi. Kromě toho zajišťují další funkce, například -zajištění konzistence dat s ohledem na čtení, -provádění operací souvisejících s obnovou dat databáze. Databázové systémy 2 - př. 2 15

16 Data v návratových tabulkových prostorech Data v návratovém tabulkovém prostoru mohou být ve 3 stavech: -Aktivní (platná, unexpired) – vyžadována pro zachování konzistence pro čtení nebo pro dokončení transakce, případně nevypršela doba platnosti návratových dat -Neplatná (expired) – po dokončení všech dotazů, které vyžadovaly platná návratová data a pokud bylo dosaženo doby platnosti návratových dat (možno využít např. pro podporu technologie Flashback -Nepoužitá – veškeré volné místo v návratovém tabulkovém prostoru Databázové systémy 2 - př. 2 16

17 Konzistentní čtení Konzistentní čtení na úrovni - SQL příkazů - transakcí Databázové systémy 2 - př. 2 17

18 Konzistentní čtení Oracle zabraňuje destruktivní interakci mezi transakcemi, které přistupují ke stejným zdrojům dat, tento proces je automatický a nevyžaduje od uživatelů žádnou součinnost. Doporučuje se, aby jedna transakce obsahovala co nejméně operací. Pokud obsahuje mnoho kroků, zpomaluje práci databázového serveru, protože musí mnoho dat ukládat do transakčního žurnálu. Server do nich neukládá příkazy SQL, ale informace o všech změnách, které provedl. Představme si situaci, kdy probíhá SELECT, jehož vyhodnocení trvá několik hodin a mezitím někteří uživatelé provedou určité změny dat a tyto potvrdí příkazem COMMIT. Výsledek bude takový, že: – ve výsledku dříve spuštěného dotazu nebudou provedené změny během doby zpracování zahrnuty, – ostatní uživatelé budou normálně pracovat s aktuální verzí dat (tedy po potvrzení změn). Databázové systémy 2 - př. 2 18

19 Konzistentní čtení Obrázek ukazuje příklad pro čtení dat z tabulky. Příkaz SELECT je spuštěn v okamžiku SCN (system change number) = 10023. Pokud se při čtení narazí na bloky dat změněné po tomto „čase“ (SCN je vyšší), budou pro výsledek dotazu vstupní data rekonstruována s využitím informací uložených v návratovém segmentu. Tím je zajištěna konzistence vstupních dat pro zpracování dotazu a tím platnost výsledku. SCN se při každé transakci zvyšuje o 1. Databázové systémy 2 - př. 2 19

20 Konzistentní čtení – na úrovni SQL dotazu Oracle vždy zajišťuje konzistenci pro čtení na úrovni dotazu. Ani potvrzení jiné transakce příkazem COMMIT během zpracování dotazu neovlivní jeho výsledek – vždy je důležitý stav při zahájení dotazu. Tato konzistence je zajištěna automaticky bez účasti uživatele. Vztahuje se i na vnořené dotazy. Toto ovšem také znamená, že daný dotaz nevidí změny vyvolané jím samotným, ale vždy pracuje s daty ve stavu při jeho spuštění! Poznámka: Problém by mohl nastat, pokud by příkaz SELECT spouštěl funkci, která by opět obsahovali jiný SELECT (ta by ovšem měla jiné SCN začátku) a uvažovala by již změněná data. Databázové systémy 2 - př. 2 20

21 Konzistentní čtení – na úrovni transakce Oracle nabízí možnost zajištění konzistence pro čtení na úrovni transakcí. Pokud transakce běží v seriazible módu, všechny přístupná data reflektují stav databáze v čase zahájení transakce. To platí pro všechny příkazy v rámci transakce kromě změn provedených transakcí samotnou. Databázové systémy 2 - př. 2 21

22 Izolace transakcí Oracle nabízí možnost zajištění konzistence pro čtení na úrovni transakcí. Pokud transakce běží v seriazible módu, všechny přístupná data reflektují stav databáze v čase zahájení transakce. To platí pro všechny příkazy v rámci transakce kromě změn provedených transakcí samotnou. Databázové systémy 2 - př. 2 22

23 Izolace transakcí Standard SQL92 definuje čtyři úrovně izolace transakcí s různým ovlivňováním transakcí a různou propustností. Smyslem izolací je chránit data zpracovávaná transakcí před 3 vlivy: ■ Dirty reads: Transakce čte data zapsaná jinou transakcí, která ještě nebyla potvrzena ■ Nonrepeatable (fuzzy - zmatené) reads: Transakce čte data již jednou čtená a shledává, že jsou ovlivněna (upravena či smazána) jinou transakcí, jejíž potvrzení nastalo během probíhání dané transakce. ■ Phantom reads (or phantoms - zjevení): Transakce opětovně spouští dotazy vracející množinu řádků vyhovující vyhledávacím podmínkám a nachází, že jiná potvrzená transakce přidala další řádky, které splňují podmínky vyhledávání. Databázové systémy 2 - př. 2 23

24 Dirty read Transakce může číst data, která byla zapsána jinou transakcí, ale ještě nedošlo k jejich potvrzení. V tabulce mohou být v aktuální chvíli jakákoliv data. Není tedy zaručena úplnost dat. V databázích Oracle je Dirty read nemožné. Příklad: Transakce 1 provede dvakrát příkaz SELECT. Mezi těmito dvěma příkazy ale Transakce 2 změní řádek zobrazovaný Transakcí 1 bez potvrzení transakce. Transakce 1 při druhém SELECTu přečte nepotvrzená data a poté co bude Transakce 2 odrolována zpět, tak mohou být tato podruhé zobrazená data špatná. Databázové systémy 2 - př. 2 24

25 Nonrepeatable read (Fuzzy read) Transakce čte opakovaně stejné hodnoty, ale dostává různé výsledky. Ty jsou ovlivněny potvrzenými změnami v současně běžících jiných transakcích. Příklad: Transakce 1 se skládá ze dvou příkazů SELECT. V mezičase mezi dvěma příkazy Transakce 2 změní řádek a příkazem COMMIT se ukončí. Transakce 1 při obou vykonávaných příkazech čte potvrzená data, ale i přesto se tato data při běhu jedné transakce liší. Nezmění se počet řádků na výstupu, ale změní se jejich obsah. Nastalo tedy tzv. Nonrepeatable read neboli neopakovatelné čtení. Databázové systémy 2 - př. 2 25

26 Phantom read Když uživatel provede čtení v čase t1 a v čase t2 provede ten stejný příkaz, do databáze, mohou být přidány další řádky jinou současně běžící transakcí a ty mohou ovlivnit výsledek. Od Nonrepeatable read se Phantom read liší v tom, že data, která uživatel právě čte, nejsou změněna, ale je výsledku v čase t2 je více dat. Příklad: Transakce 1 je opět složena příkazů SELECT. Současně s Transakcí 1 nyní Transakce 2 provede vložení řádku a následné potvrzení transakce. Oba dva příkazy SELECT v Transakci 1 budou vracet na výstupu potvrzená data, ale počet řádku se od sebe bude lišit. Objeví se tzv. zjevení. Databázové systémy 2 - př. 2 26

27 Izolace transakcí Databázové systémy 2 - př. 2 27

28 Read Uncommited Tato izolační úroveň dovoluje nejvyšší propustnost ze všech standardem definovaných možností. Souběžné aktualizace jsou sice blokovány, ale transakce může číst i dosud nepotvrzené změny provedené jinými transakcemi. To ovšem odporuje samotnému principu transakcí. Ačkoliv nemůže dojít ke ztrátě informace z důvodu přepsání změn jinou transakcí, může dojít k celé škále anomálií při čtení nepotvrzených dat. Z výše uvedených důvodů lze tuto izolační úroveň použít jen pro transakce, které buď pouze data mění, nebo u kterých nezáleží na korektnosti a konzistenci přečtených dat. Protože jen málokterá transakce splňuje tyto podmínky, je vhodné tuto izolační úroveň vůbec nepoužívat. Databázové systémy 2 - př. 2 28

29 Read Commited Jak již název napovídá, blokuje tato izolační úroveň nejen souběžné aktualizace, ale navíc dovoluje čtení pouze potvrzených změn provedených jinými transakcemi. Pokud jsou transakce, jež provádějí změny krátké, dovoluje tato izolační úroveň velmi vysokou propustnost srovnatelnou s propustností úrovně Read Uncommitted. Ačkoliv nelze číst nepotvrzená data, může stále docházet k anomáliím při čtení dat. Úroveň Read Committed je vhodná pro transakce, jež provádějí především změny dat, a které nevyžadují stabilní pohled na data. Není vhodná pro transakce provádějící zpracování velkého množství dat, případně mění data na základě dříve přečtených údajů. Tato úroveň je standartní pro databáze Oracle. Databázové systémy 2 - př. 2 29

30 Repeatable Read Mimo vlastností úrovně Read Committed zajišťuje tato úroveň izolace navíc stabilní pohled na čtená data tak, aby bylo zajištěno, že jednou přečtené údaje nebudou změněny. Mohou ovšem vznikat anomálie z přidání nových dat, kdy opakované čtení téže množiny může vrátit odlišný počet záznamů. U mnoha databázových platforem vyvolá pouhé čtení dat jejich uzamčení proti změnám. Tuto izolační úroveň je tedy vhodné používat pouze u takových transakcí, které ze své podstaty vyžadují stabilní pohled na data. Možnost vzniku phantomových záznamů ovšem vylučuje použít tuto izolační úroveň pro transakce, jež na základě načtených údajů přidávají nebo mění data. Tato úroveň není normálně podporována v databázích Oracle. Databázové systémy 2 - př. 2 30

31 Serializable Úroveň Serializable zabraňuje všem interferencím mezi transakcemi stejným způsobem, jakoby transakce byly prováděny postupně a nikoliv souběžně. Ostatní transakce sice mohou číst data ze zpracovávaných tabulek, ale nemohou je měnit ani přidávat nové údaje. Z důvodu značného blokování ostatních transakcí je vhodné používat tuto úroveň izolace pouze v nezbytných případech. Databázové systémy 2 - př. 2 31

32 Automatické zamykání Slouží pro řešení sdíleného (konkurenčního) přístupu více klientů k datům v tabulkách. Je třeba zajistit situace, kdy by například příkaz SELECT byl spuštěn v době, kdy právě probíhá navyšování mezd zaměstnanců - nutno zajistit konzistentní odpověď. Řešení: k nepotvrzeným změnám, které provedl jeden uživatel ostatní uživatelé nemají přístup, tj. databázový systém zajišťuje konzistentní pohled na data v každém okamžiku (ostatní uživatelé kromě autora změn vidí data ve stavu před provedením změn až do okamžiku potvrzení) Upozornění: u APEX (WWW SQL konzole) dochází k potvrzení každého dotazu a není možný návrat zpět; Databázové systémy 2 - př. 2 32

33 Módy zamykání a typy zámků Oracle používá 2 módy zamykání: -Exklusívní (uzamčený zdroj nemůže být sdílen) -Sdílený – zamčený zdroj může být sdílen, což umožňuje zejména více přístupů pro čtení, ale zabraňuje konkurenčním zápisům Kategorie zámků -DML zámky – např. uzamykání celých tabulek či vybraných řádků -DDL zámky – chrání např. strukturu tabulek či pohledů -Interní zámky – chrání interní databázové struktury, jako například datové soubory Uzamykání a odemykání probíhá automaticky dle požadavků transakcí. Databázové systémy 2 - př. 2 33