Databázové systémy II Přednáška I Ing. Tomáš Váňa, Ing. Jiří Zechmeister Fakulta elektrotechniky a informatiky

Prezentace na téma: "Databázové systémy II Přednáška I Ing. Tomáš Váňa, Ing. Jiří Zechmeister Fakulta elektrotechniky a informatiky"— Transkript prezentace:

1 Databázové systémy II Přednáška I Ing. Tomáš Váňa, Ing. Jiří Zechmeister Fakulta elektrotechniky a informatiky tomas.vana@upce.cz, jiri.zechmeister@upce.cz

2 Harmonogram přednášek 1.Transakce, zpracování dotazů, 2.práva a bezpečnostní mechanismy, hierarchické dotazy, 3.úvod do PL/SQL, 4.PL/SQL - procedury, funkce, balíčky, 5.kolekce, záznamy, BULK operace, 6.triggery (spouště), 7.dynamické SQL, 8.analytické funkce, 9.exekuční plán, 10.systémový katalog, SQL Injection, plánovač 11.??? IDAS2 - Přednáška I 2

3 Podmínky k získaní zápočtu IDAS2 - Přednáška I 3 a)cvičení jsou povinná (účast = 1 bod) b)splněné úkoly ze zadání cvičení v požadovaných termínech, není-li uveden - půlnoc před následujícím cvičením (1 kompletně včas splněné cvičení = 1 bod) všechna cvičení musí být splněna před získáním zápočtu c)úspěšné absolvování zápočtového testu d)včasné odevzdání a kvalita semestrálních prací (body budou upřesněny), při pozdním odevzdání 0 bodů e)úspěšná „obhajoba“ semestrální práce před vyučujícím (max. 5 bodů) Podmínkou zápočtu je získání min. 70% bodů v každé kategorii a) až f). Další body je možné získat za aktivitu ve cvičeních. Při nedostatku bodů v jedné kategorii, ale dostatečném součtu 70% všech možných bodů, bude studentovi zadána individuální práce. Zápočet je třeba získat a zapsat do STAGu i indexu do 2 týdnů od ukončení výukového období. V tomto období budou vypsány i 2 náhradní termíny pro opakování zápočtových testů.

4 Zkouška Zkouška se bude skládat ze dvou částí: – Praktická část (2 příklady z PL/SQL), – doplňující teoretická část. IDAS2 - Přednáška I 4

5 Obsah Transakce, transakční protokoly, žurnály Konzistentní čtení, Undo Autonomní transakce Zpracování SQL dotazu IDAS2 - Přednáška I 5

6 Transakce Z obecného pohledu: – Jedna ze základních vlastností databází, jež je odlišuje od klasických souborů. Pokud uprostřed zápisu do souboru dojde k nějaké chybě, s velkou pravděpodobností zůstane soubor v nekonzistentním stavu. IDAS2 - Přednáška I 6

7 Transakce Transakce je logická část, která obsahuje jeden nebo více příkazů SQL. Transakce je atomickou jednotkou. Hlavní úkol transakce -> převést databázi z jednoho konzistentního stavu do druhého. 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. Právě transakce zásadně odlišují databázové systémy od klasického přístupu založeného na zápisu dat do souboru. IDAS2 - Přednáška I 7

8 8

9 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) IDAS2 - Přednáška I 9

10 Transakce 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 -V databázi Oracle není nutné explicitně inicializovat transakci. -Transakce automaticky začíná s prvním příkazem modifikující data. -Explicitně lze transakci zahájit pomocí příkazu SET TRANSACTION nebo balíčkem DBMS_TRANSACTION. IDAS2 - Přednáška I 10

11 Transakce Vždy by jste měli ukončit transakci jedním z příkazů COMMIT nebo ROLLBACK. – Jinak prostředí, ve kterém příkazy provádíte rozhodne za Vás co udělá s nepotvrzenou transakci. – A chovaní daného prostředí se může různit. IDAS2 - Přednáška I 11

12 Příklad bankovní transakce IDAS2 - Přednáška I 12

13 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 IDAS2 - Přednáška I 13

14 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. IDAS2 - Přednáška I 14

15 Atomičnost Transaction-Level Atomicity (Atomičnost transakce). Statement-Level Atomicity (Atomičnost příkazu). – Jeden samostatný příkaz může na pozadí spustí další příkazy. – Co když ale jeden z příkazů (i sám námi volaný) selže? – Oracle automatický vrátí všechny změny provedené příkazem - jako by vůbec příkaz neproběhl. – Tohoto chování dosahuje Oracle tak, že na pozadí „obaluje“ každý náš příkaz individuálním návratovým bodem (SAVEPOINT). Procedure-Level Atomiciti (Atomičnost procedurální) IDAS2 - Přednáška I 15

16 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. IDAS2 - Přednáška I 16

17 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. IDAS2 - Přednáška I 17

18 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. IDAS2 - Přednáška I 18

19 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) IDAS2 - Přednáška I 19

20 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 IDAS2 - Přednáška I 20

21 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; IDAS2 - Přednáška I 21

22 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. IDAS2 - Přednáška I 22

23 Příkazy pro řízení transakcí SET TRANSACTION - příkaz sloužící pro nastavení různých atributů transakcí. – Umožňuje například nastavit stupeň izolace transakce. – Umožňuje nastavit, zdali je transakce read-only. IDAS2 - Přednáška I 23

24 Základy návratové technologie Každá databáze Oracle musí evidovat informace, které lze použít k vrácení provedených změn. – Tyto informace se skládají ze záznamů akcí transakcí před jejich potvrzením. – Záznamy obsahují obraz dat před jejich změnou (před startem transakce). – Tyto záznamy jsou souhrnně označovány jako undo. Undo záznamy se využívají k: – Při použití příkazu ROLLBACK při „odrolování“ transakce. – K obnově databáze. – Zajišťují konzistentní čtení. Undo záznamy se ukládájí do tzv. undo tablespace. – Díky Automatic Undo Management mode, se správou tohoto tabulkového prostoru není nutné zabývat. IDAS2 - Přednáška I 24

25 Undo Segment IDAS2 - Přednáška I 25

26 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 IDAS2 - Přednáška I 26

27 Konzistentní čtení Konzistentní čtení na úrovni - SQL příkazů - transakcí IDAS2 - Přednáška I 27

28 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). IDAS2 - Přednáška I 28

29 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. IDAS2 - Přednáška I 29

30 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. IDAS2 - Přednáška I 30

31 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. IDAS2 - Přednáška I 31

32 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. IDAS2 - Přednáška I 32

33 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í. IDAS2 - Přednáška I 33

34 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á. IDAS2 - Přednáška I 34

35 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í. IDAS2 - Přednáška I 35

36 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í. IDAS2 - Přednáška I 36

37 Izolace transakcí IDAS2 - Přednáška I 37

38 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. IDAS2 - Přednáška I 38

39 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. IDAS2 - Přednáška I 39

40 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. IDAS2 - Přednáška I 40

41 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. IDAS2 - Přednáška I 41

42 Zamykání Zámek = mechanismus, který se snažit předejít destruktivním interakcím mezi jednotlivými transakcemi přistupujícím ke stejnému zdroji (např. stejnému řádku). – Zamykání je automaticky zajišťováno databázovým systémem. – Zámek trvá po celou dobu transakce. – Zámky jsou uvolněny v případě úspěšné operace COMMIT či v případě operace ROLLBACK. IDAS2 - Přednáška I 42

43 Zamykání IDAS2 - Přednáška I 43

44 Zamykání Vysvětlení k předcházejícímu obrázku: – Transakce T1 aktualizuje řádek s id = 100. Tím zároveň vytvoří nad tímto řádkem zámek. Zatím v transakci není proveden COMMIT či ROLLBACK. – Transakce T2 se chvíli po transakci T1 pokusí aktualizovat stejný řádek. Jelikož je nad řádkem zámek, nedostaneme informaci o úspěšné aktualizaci řádku a transakce bude čekat na zámek. – Transakce T1 provede COMMIT. V tu chvíli je uvolněn zámek na řádkem s id = 100, T2 získá zámek a provede aktualizaci. IDAS2 - Přednáška I 44

45 Zamykání IDAS2 - Přednáška I 45

46 Zamykání Vysvětlení k předcházejícímu obrázku: – Transakcí T1 je opět aktualizován řádek s id=100, není použit COMMIT, tudíž T1 opět drží zámek. – Tentokrát se transakce T1 pokusí nejprve před samotnou aktualizací získat zámek. – Využije při tom speciální klauzule FOR UPDATE příkazu SELECT. – Využití klíčového slova NOWAIT klauzule FOR UPDATE způsobí, že příkaz se pokusí zámek nad daným řádkem okamžitě, nebo skončí výjimkou. – Tím lze jednak zjistit, zdali náhodu není záznam uzamčen (zdali právě někdo neprovádí jeho modifikaci) a je také možné tím eliminovat ono čekání na zámek, jako v předcházejícím případě. IDAS2 - Přednáška I 46

47 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í. IDAS2 - Přednáška I 47

48 Zamykání - Deadlock IDAS2 - Přednáška I 48

49 Autonomní transakce Autonomní transakce je nezávislá transakce vyvolaná jinou - nadřazenou transakcí. – „Transakce uvnitř transakce“ – Autonomní transakce je nezávislá na transakci nadřazené. Obě transakce tedy můžou sdílet jen potvrzená data. Využitelná jen v rámci bloku kódu PL/SQL. K autonomním transakcím je nutné přistupovat obezřetně. Tom Kyte říká: – „in 999 times out of 1000, if you find yourself "forced" to use an autonomous transaction - it likely means you have a serious data integrity issue you haven't thought about “ Jediné opodstatnitelné využití autonomních transakcí je logování průběhu dlouhotrvajících transakcí. IDAS2 - Přednáška I 49

50 Zpracování SQL příkazu IDAS2 - Přednáška I 50

51 Zpracování příkazu Analýza – kontrola syntaxe a sémantická kontrola příkazu pro ověření jeho platnosti. Optimalizace – generování optimálního prováděcího plánu, který bude použit ke zpracování příkazu v databázi Generování řádkového zdroje – stanovení prováděcího plánu podle optimalizátoru. Provedení příkazu – zpracování výstupů z předchozího kroku IDAS2 - Přednáška I 51

52 Analýza (Parsing) Proces analýzy začíná dvěma kroky: 1.Syntaktická analýza Je dotaz platným SQL příkazem? 2.Sémantická analýza Přistupuje dotaz k objektům, ke kterým má právo přistupovat. Existují vůbec dotazované objekty? Pokud se jedná o DML příkaz, pak proces pokračuje třetím krokem: Analýzou sdíleného fondu IDAS2 - Přednáška I 52

53 Analýza (Parsing) 3.Kontrola sdíleného fondu Pokud byl stejný příkaz již jednou analyzován, je možné tuto analýzu využít a výrazně tak snížit množství práce spojené s prováděním příkazu. Pokud již byl dotaz někdy předtím proveden (analyzován, optimalizován), pak bude tato analýza uložena v tzv. sdíleném fondu. Pak je možné tuto analýzu využít a vyhnout se tak úplné analýze (hard parse) - příkaz pak prochází všemi fázemi provádění příkazu. Místo toho pak může proběhnout jen tzv. jemná analýza (soft parse), která neprochází všemi kroky - přeskočena je především optimalizace (nejnákladnější operace) IDAS2 - Přednáška I 53

54 Optimalizace a generování řádkového zdroje Každý DML příkaz je alespoň jedenkrát optimalizován (při prvním odeslání databázi). – Tento proces probíhá během úplné analýzy. – Každé další zpracování syntaktická a sémanticky totožného dotazu může opětovně využít předcházející úplnou analýzu. – Úplná analýza zahrnuje krok optimalizace, což je proces intenzivně využívající procesor. Tento krok navíc může trvat déle než samotné provedení dotazu. – Cílem optimalizace dotazu je nalézt nejlepší plán, podle kterého budou DML příkazy zpracovávány. – Databáze Oracle podporuje dva režimy optimalizátoru: RBO (Rule-based optimizer) - Optimalizátor založený na pravidlech. CBO (Cost-based optimizer) - Optimalizátor založený na nákladech. IDAS2 - Přednáška I 54

55 Optimalizace a generování řádkového zdroje Optimalizátor RBO – Plán dotazu je vytvořen na základě dobře známe sady pravidel. – Tento optimalizátor nebere v úvahu fyzické parametry objektů se kterými pracuje (počet řádku v tabulce, mohutnost sloupců, …). – Dnes již považováno za zastaralé. Optimalizátor CBO – Optimalizace dotazu je založena na statistických informacích o objektech k nimž je přistupováno. – Při rozhodování o optimálním planu jsou uvažovány informace jako počet řádků tabulky, velikost datové sady atd. – CBO generuje více plánů najednou, přičemž jednotlivým plánům přiřazuje číselně vyjádřenou cenu. – Použit je plán s nejnižší cenou (s nejnižšími náklady). IDAS2 - Přednáška I 55

56 Optimalizace IDAS2 - Přednáška I 56

57 Optimalizace a generování řádkového zdroje Generování řádkového zdroje – Generátor přijímá výstup z optimalizátoru a zformátuje jej do skutečného prováděcího plánu. – Optimalizátor plán vytvoří a generátor z něj vytvoří datovou strukturu (strom), jenž využijí ostatní komponenty systému Oracle. IDAS2 - Přednáška I 57

58 Provedení příkazu Provedení (Execution) – Jediný povinný krok procesu zpracovávání příkazu DML. – Je možné přeskočit analýzu, optimalizaci i generování řádkového zdroje a příkaz jen opakovaně provádět. – To je nejefektivnější přístup -> záměrem je vyvíjet aplikace, jenž se snaží dostát pravidlu „jedna analýza, mnoho spuštění“. IDAS2 - Přednáška I 58

59 Zpracování příkazu IDAS2 - Přednáška I 59

60 Děkuji za pozornost Otázky? IDAS2 - Přednáška I 60