Databázové systémy I. 7. Přednáška

Podobné dokumenty
Transakce a zamykání. Administrace MS SQL Serveru (NDBI039) Pavel Hryzlík

Databáze I. 5. přednáška. Helena Palovská

Databázové systémy. - SQL * definice dat * aktualizace * pohledy. Tomáš Skopal

Kurz Databáze. Obsah. Dotazy. Zpracování dat. Doc. Ing. Radim Farana, CSc.

Architektura SW pro transakční zpracování se skládá ze 3 modulů: - manažer dat - rozvrhovač - manažer transakcí

2. blok část B Základní syntaxe příkazů SELECT, INSERT, UPDATE, DELETE

Úvod do databázových systémů

Databáze I. Přednáška 4

Optimalizace dotazů a databázové transakce v Oracle

Úvod do databázových systémů

Transakce a zamykání Jiří Tomeš

Databáze II. 2. přednáška. Helena Palovská

RELAČNÍ DATABÁZOVÉ SYSTÉMY

Informační systémy 2008/2009. Radim Farana. Obsah. Jazyk SQL

Databáze SQL SELECT. David Hoksza

Jaký je rozdíl v definicicíh VARCHAR2(20 BYTE) a VARCHAR2(20 CHAR):

Jazyk SQL 3 - DML, DDL, TCL, DCL

Databázové systémy Cvičení 5.2

8.2 Používání a tvorba databází

7. Integrita a bezpečnost dat v DBS

7. Integrita a bezpečnost dat v DBS

Text úlohy. Systémový katalog (DICTIONARY):

Transakce. Ing. Marek Sušický, RNDr. Ondřej Zýka

Databázové systémy. Cvičení 6: SQL

InnoDB transakce, cizí klíče, neumí fulltext (a nebo už ano?) CSV v textovém souboru ve formátu hodnot oddělených čárkou

Databázové systémy a SQL

Návrh a tvorba WWW stránek 1/14. PHP a databáze

B0M33BDT Technologie pro velká data. Supercvičení SQL, Python, Linux

Databázové systémy I

Operátory ROLLUP a CUBE

6. blok část B Vnořené dotazy

PRŮBĚHOVÝ TEST Z PŘEDNÁŠEK

Databázové systémy Cvičení 5.3

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče.

Informační systémy ve zdravotnictví. 6. cvičení

Databázové systémy úvod

DUM 12 téma: Příkazy pro tvorbu databáze

Databázové systémy. Doc.Ing.Miloš Koch,CSc.

8. Zpracování dotazu. J. Zendulka: Databázové systémy 8 Zpracování dotazu 1

J. Zendulka: Databázové systémy 8 Zpracování dotazu Podstata optimalizace zpracování dotazu

Použití databází na Webu

Informační systémy 2008/2009. Radim Farana. Obsah. Dotazy přes více tabulek

Transakční zpracování Bezpečnost databází. Vladimíra Zádová, KIN, EF TUL- DBS 1

Jazyk SQL 1. Michal Valenta. Katedra softwarového inženýrství FIT České vysoké učení technické v Praze c Michal Valenta, 2012 BI-DBS, ZS 2011/12

DBS transakční zpracování

Databáze I. 1. přednáška. Helena Palovská

Jazyk SQL databáze SQLite. připravil ing. petr polách

KIV/ZIS cvičení 5. Tomáš Potužák

9. Transakční zpracování

Úvod do databázových systémů

Obchodní akademie a Jazyková škola s právem státní jazykové zkoušky Jihlava

Kapitola 6: Omezení integrity. Omezení domény

Databázové systémy Cvičení 5

Databázové systémy. Datová integrita + základy relační algebry. 4.přednáška

Transakční zpracování

Kapitola 4: SQL. Základní struktura

Základy informatiky. 08 Databázové systémy. Daniela Szturcová

Databázové systémy trocha teorie

Úvod do databázových systémů. Ing. Jan Šudřich

Obsah. Kapitola 1. Kapitola 2. Kapitola 3. Kapitola 4. Úvod 11. Stručný úvod do relačních databází 13. Platforma 10g 23

2. přednáška. Databázový přístup k datům (SŘBD) Možnost počítání v dekadické aritmetice - potřeba přesných výpočtů, např.

04 - Databázové systémy

1. Relační databázový model

Michal Krátký, Miroslav Beneš

Oracle XML DB. Tomáš Nykodým

6. blok část C Množinové operátory

Stručný obsah. část III Aktualizace dat Kapitola 10: Aktualizace databáze 257 Kapitola 11: Integrita dat 275 Kapitola 12: Zpracování transakcí 307

SQL. strukturovaný dotazovací jazyk. Structured Query Language (SQL)

Fakulta elektrotechniky a informatiky Databázové systémy 2. Leden 2010 souhrn. Červené dobře (nejspíš), modré možná

Databáze II. 1. přednáška. Helena Palovská

Zotavení z chyb. Databázové systémy

TÉMATICKÝ OKRUH TZD, DIS a TIS

Databázové systémy a SQL

Transformace konceptuálního modelu na relační

Optimalizace SQL dotazů

Úvod do databází. Modelování v řízení. Ing. Petr Kalčev

Základy informatiky. 06 Databázové systémy. Kačmařík/Szturcová/Děrgel/Rapant

IDS optimalizátor. Ing. Jan Musil, IBM ČR Community of Practice for

1. Databázové systémy (MP leden 2010)

01. Kdy se začala formovat koncept relačních databází (Vznik relačního modelu, první definice SQL)? a) 1950 b) 1960 c) 1970 d) 1980

Kritéria hodnocení praktické maturitní zkoušky z databázových systémů

Základy databází. O autorech 17 PRVNÍ ČÁST. KAPITOLA 1 Začínáme 19

Základní přehled SQL příkazů

Databáze. Velmi stručný a zjednodušený úvod do problematiky databází pro programátory v Pythonu. Bedřich Košata

Konceptuální modelování a SQL

Replikace je proces kopírování a udržování databázových objektů, které tvoří distribuovaný databázový systém. Změny aplikované na jednu část jsou

DJ2 rekurze v SQL. slajdy k přednášce NDBI001. Jaroslav Pokorný

12. blok Fyzický návrh databáze

Deklarativní IO shrnutí minulé přednášky

Databáze 2011/2012 SQL DDL (CREATE/ALTER/DROP TABLE), DML (INSERT/UPDATE/DELETE) RNDr.David Hoksza, Ph.D.

Inovace a zkvalitnění výuky prostřednictvím ICT. Základní seznámení s MySQL Ing. Kotásek Jaroslav

Co bude výsledkem mého SELECTu? RNDr. David Gešvindr MVP: Data Platform MCSE: Data Platform MCSD: Windows Store MCT

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

Databáze I. Přednáška 6

Michal Krátký. Tvorba informačních systémů, 2008/2009. Katedra informatiky VŠB Technická univerzita Ostrava. Tvorba informačních systémů

Paralelní přístup k databázi

Dotazování v relačním modelu a SQL

Popis ovládání. Po přihlášení do aplikace se objeví navigátor. Navigátor je stromově seřazen a slouží pro přístup ke všem oknům celé aplikace.

Maturitní témata Školní rok: 2015/2016

4IT218 Databáze. 4IT218 Databáze

Transkript:

Databázové systémy I. 7. Přednáška

Co nás dnes čeká Uživatelské pohledy (Views) Optimalizace SQL dotazů Zpracování dotazu Naplnění tabulek daty (DML) Sekvence Transakce Indexy

Pohledy (views) představují zobecnění tabulek jde o virtuální tabulky definované pomocí dotazů nad jinými tabulkami nebo pohledy (nazýváme je základními tabulkami) neobsahují vlastní data obvykle jen pro čtení (read only), protože nelze jasně definovat zpětný rozpad na původní sloupce) při dodržení určitých pravidel můžeme vytvořit zapisovatelný (updatable) pohled

Proč používat pohledy? omezují přístup k datům základní tabulky, protože pohled může zobrazovat selektivní sloupce či řádka z původní tabulky v případě často opakovaných spojení usnadní uživateli dotazování poskytují uživatelům (skupinám uživatelů) přístup k údajům podle jejich konkrétních oprávnění

Jak na pohledy v SQL CREATE OR REPLACE VIEW jméno (definice pohledu) AS dotaz Definice pohledu představuje přehled sloupců, integritních omezení těchto sloupců a vícesloupcových integritních omezení na pohled Lze užít přejmenování sloupců dotazu V rámci dotazu nelze použít klauzuli ORDER BY Část s definicí pohledu vč. () lze vypustit

Vytvoření pohledu CREATE [OR REPLACE] [FORCE NOFORCE] VIEW view_name [(alias [, alias]...)] AS subquery [WITH CHECK OPTION [CONSTRAINT constraint]] [WITH READ ONLY [CONSTRAINT constraint]];

Typy pohledů Vlastnost Jednoduchý pohled Komplexní pohled Počet tabulek z nichž jsou získávána data Jedna Jedna nebo více Smí obsahovat funkce Ne Ano Smí obsahovat seskupování Lze provádět DML operations (INSERT, UPDATE, DELETE) prostřednictvím pohledu Ne Ano Ano Ne vždy

Modifikace pohledu K modifikaci pohledu dochází prostřednictvím přetvoření pohledu Použitím klauzule OR REPLACE při vytváření pohledu dojde k nahrazení staré verze nově definovaným pohledem

Omezení DML operací Nelze použít: víceřádkové funkce (D, U, I) GROUP BY (D, U, I) DISTINCT (D, U, I) pseudosloupec ROWNUM (D, U, I) sloupce definované pomocí výrazů (U, I) Neosahuje NOT NULL sloupce ze zdrojové tabulky (I)

Optimalizace dotazů Optimalizace de facto znamená nalezení optimální strategie zpracování dotazu Relační SŘBD je tak dobrý, jak je dobrý jeho optimalizátor dotazů. Optimalizace je vedena ve dvou krocích: Konstrukce alternativních plánů vyhodnocení. Odhad ceny alternativních plánů a volba plánu s nejnižší odhadnutou cenou. Optimalizaci provádí SŘBD, má více informací než programátor

Strategie optimalizace dotazů Algebraická optimalizace Indexy a velikost relace Řízené cenou operace Syntaxí řízená optimalizace

Algebraická optimalizace Nahrazuje jeden relační výraz druhým za účelem efektivnějšího přímého vyhodnocení. Zásada zmenši před operací spojení co nejvíce řádků a sloupců. Optimalizátor vyžaduje jisté informace o databázi. Je vhodná znalost, jak jsou podmínky omezující.

Algebraická optimalizace Prakticky se provádí transformacemi stromů dotazů. Listy jsou tvořeny základními relacemi, ostatní uzly reprezentují operace relační algebry Pravidla pro převod vycházejí z komutativních a distributivních zákonů vyplývajících z definice relačních operací.

Zákony

Zákony

Příklad Nalezněte jména filmů, u nichž existují kopie, které mají být vráceny do 30. 9. 2007. Pokorný (2007)

Příklad Použitím pravidel 1 a 2 rozdělíme čtyři spojení do dvou, nahradíme je kartézskými součiny a použijeme přejmenování atributů. Pokorný (2007)

Příklad Poslední výskyt spojení přepíšeme také pomocí kartézského součinu. Pokorný (2007)

Příklad Aplikací zákona 3 na selekci (DATUM_V > 30. 9. 2007) obdržíme záměnu selekční podmínky projekcí [K.JMÉNO_F, REŽISÉR, ROK, JMÉNO, ADRESA, V.Č_KOPIE, V.ROD_Č, DATUM_V], následně zaměníme danou selekci se selekcí V.Č_KOPIE=K. Č_KOPIE a po použití zákona 4 dostaneme danou selekci až k levému kartézskému součinu. Další aplikací zákona 3 a ze zákona 4 dostaneme tutéž selekci do kartézského součinu VÝPŮJČKY ZÁKAZNÍCI. Zároveň také podle 8 se zredukovaly po sobě jdoucí závěrečné projekce v jednu. Pokorný (2007)

Příklad Výsledek předchozích operací Pokorný (2007)

Příklad Další aplikací zákona 3 dostaneme před podmínku V.Č_KOPIE=K. Č_KOPIE projekci [K.Č_KOPIE, K.JMÉNO]. Pokorný (2007)

Příklad Nakonec je patrné, že první argument vnějšího kartézského součinu lze zjednodušit na VÝPŮJČKY (DATUM_V<30.9.2007)[V.Č_KOPIE] J. Pokorný. Databázové systémy 2. Praha: ČVUT, 2007. ISNB 978-80-01-03797-3.

Optimalizace založená na indexech a velikostech relací Problém bývá určit optimální pořadí operací spojení. Většina SŘBD používá jako základní algoritmy pouze binární spojení => vícenásobné spojení je nutné rozložit na posloupnost binárních. Řešení pomocí technik dynamického programování případně heuristických přístupů

Optimalizace řízená cenou Jedná se o jeden z heuristických přístupů pro spojení n relací, kde n > 2, generuje plány ve tvaru (((R 1 R 2 ) R 3 ) R n ). Vybere nejlepší plán pro spojení dvou relací, potom plám pro spojení třetí atd. Mají-li podmínky realizující spojení dvou relací R 1 a R 2 resp. R 3 a R 4 nízké ceny, je vhodnější zvolit způsob zpracování (R 1 R 2 )* (R 3 R 4 ).

Syntaxí řízená optimalizace Zde se předpokládá, že uživatel zahrne informaci pro optimalizaci od textu dotazu. SELECT * FROM zaměstnanci WHERE plat > 6700 AND adresa= 'Zemědělská 1 SELECT * FROM zaměstnanci WHERE adresa= 'Zemědělská 1' AND plat > 6700

Optimalizace v Oracle Oracle disponuje vlastním optimalizátorem dotazů Nastavení režimu optimalizace ALTER SESSION SET OPTIMIZER_MODE = {FIRST_ROWS FIRST_ROWS_ n ALL_ROWS RULE CHOOSE } Volíme Cíle optimalizace Minimální doba odezvy Maximální propustnost Přístup k optimalizaci Založený na statistikách (doporučený) Založený pouze na pravidlech

Data modification language Prostředek pro zanášení změn do databáze (modifikace relací) Nemůže ovlivnit datový slovník Musí realizovat tři základní operace: INSERT DELETE UPDATE Provádění operace musí být atomické, konzistentní a nesmí porušit integritu

Úplná kopie tabulky Je realizováno kombinací příkazů CREATE a SELECT CREATE TABLE copy_názevtabulky AS (SELECT * FROM názevtabulky) Omezení, příkaz nekopíruje primární klíče a IO cizího klíče Pro kontrolu takto zkopírovaných dat provedeme DESCRIBE copy_názevtabulky; SELECT * FROM copy_názevtabulky;

Vkládání nových záznamů Je realizováno přidáváním nových řádků do tabulky příkazem INSERT Existují dvě varianty vkládání: jeden řádek specifikovaný hodnotami více řádků určených dotazem Při vkládání se kontrolují integritní podmínky tabulky (definovanost, implicitní hodnoty, omezení, klíče) a provádí se současně potřebné definované indexování

Vkládání nových záznamů

Jak na to v SQL INSERT INTO tabulka [ (sloupce) ] VALUES (hodnoty) dotaz Počet hodnot musí odpovídat počtu sloupců (včetně domén), analogicky počet sloupců dotazu musí odpovídat počtu sloupců v definici INSERT Než začneme vkládat, zkontrolujeme si cílovou tabulku (DESCRIBE) Neuvedením sloupců se uvažují všechny sloupce z tabulky v pořadí odpovídající definice

Kontrola tabulky

Jak na NULL Při vkládání je nutné uvést hodnoty všech sloupců pro které vkládáme hodnoty Pro vložení nedefinovaných hodnot, lze použít NULL, pro chybějící údaje se používá prázdný řetězec ( )

Vkládání speciálních hodnot Typicky se jedná o hodnoty jako SYSDATE nebo USER SYSDATE, vloží aktuální datum a čas USER, vloží jméno uživatele aktuální session U APEXu to bude OAE_PUBLIC_USER

Vkládání speciálních hodnot Kromě funkcí (př. SYSDATE), lze vkládat rovněž výrazy

Použití zanořených dotazů Pro vkládání více údajů z jiné tabulky je možné požít vnořeného dotazu Představte si přesun banned uživatelů na fóru Namísto 100 samostatných insertů tak spustíme jeden Při tomto způsobu není potřeba uvádět VALUES klauzuli

CREATE TABLE lidi (id NUMBER(5) NOT NULL PRIMARY KEY, jmeno VARCHAR2(50) NOT NULL, login VARCHAR2(8) UNIQUE, vek NUMBER(3) CHECK (vek > 0)); INSERT INTO lidi (id,jmeno,vek) VALUES (1, Metuzalém,784) INSERT INTO lidi VALUES (1, Metuzalém, xmetuz,784) Příklad použití INSERT

Problém primárního klíče Často řešený problém co je primárním klíčem redukuje se na tvorbu sloupce ID Tento sloupec je číselný, vždy definovaný a označený jako primární klíč (a tedy automaticky také indexovaný) Jak zajistit přidělování čísel záznamům? Problém MAX(id) při kolizi dvou uživatelů Řešením jsou sekvence

Sekvence Představují jediný nástroj nezávislý na transakcích a relacích uživatele Jdou napříč celým DBS Sekvence na zavolání vždy vrátí další číslo v řadě (podle stanovených podmínek) V jednom SQL příkazu vrátí sekvence vždy jen jedno číslo (tzv. nextval) Nelze získat aktuální stav sekvence

Práce se sekvencí v SQL Součást datového slovníku (DDL): CREATE SEQUENCE jméno Pro získání nové hodnoty slouží funkce sekvence.nextval Pro získání hodnoty již jednou vytvořené v SQL příkazu slouží sekvence.currval Příklad použití: INSERT INTO lidi (id,jmeno) VALUES (lidi_seq.nextval, Eva )

Rušení záznamů Je realizováno vyhledáním a rušením existujících řádků tabulky příkazem DELETE Existují dvě varianty rušení: vybraných řádků určených podmínkou všech řádků tabulky Při rušení se kontroluje konzistence integritních omezení, rušení tak může být zakázáno nebo vyvolá kaskádové rušení Co se stane když vynecháme podmínku WHERE?

Jak na to v SQL DELETE [ FROM ] tabulka [ WHERE podmínka ] Neuvedením části WHERE dojde k vymazání celé tabulky (ovšem pouze obsahu, vlastní tabulka je součástí datového slovníku nemůže jí zrušit DML) Klíčové slovo FROM je nepovinné pouze v Oracle

Neopomenout IO

Určení podmínky v DELETE Lze užít část dotazovacího jazyka SQL Kombinujeme sloupce z příslušné tabulky, relační operátory, konstanty, závorky a logické spojky (AND, OR, NOT) Můžeme použít množinový vnořený dotaz pomocí operátoru IN (ptáme se, zda je hodnota obsažena v množině) Můžeme použít množinový poddotaz o jedné hodnotě místo konstanty v relaci

Použití zanořených dotazů v DELETE

DELETE FROM lidi DELETE FROM lidi WHERE vek < 18 DELETE FROM lidi WHERE vek < 18 OR vek > 62 DELETE FROM lidi WHERE vek IN (15,18,21) DELETE FROM lidi WHERE vek < (SELECT prah FROM limity WHERE typ = plnoletost ) Příklad použití DELETE

Změna (modifikace) záznamů Je realizováno vyhledáním a změnou existujících řádků tabulky příkazem UPDATE Existují dvě varianty rozsahu změn: vybraných řádků určených podmínkou všech řádků tabulky Při modifikaci se též kontroluje veškerá konzistence integritních omezení a všechny podmínky jako při vkládání nových záznamů

Který z řádků bude změněn? Kontrolní otázka?

Jak na to v SQL UPDATE tabulka SET změnový seznam [ WHERE podmínka ] Neuvedením části WHERE dojde ke změně v celém rozsahu tabulky Změnový seznam je čárkou oddělená posloupnost údajů tvaru jméno sloupce = hodnota Podmínka se určuje stejným způsobem jako u DELETE

Použití vnořeného dotazu

Update 2 sloupců 2 vnořenými dotazy

MERGE Umožňuje provést současně INSERT i UPDATE a to ve 2 případech Chybí-li vkládaná hodnota, pak je vložena nová Je-li nutné aktuální hodnotu nahradit novou Pro provedení těchto změn je nutné disponovat právy pro pro příkazy INSERT a UPDATE MERGE umožňuje použití aliasů

MERGE v příkladu

Datové typy Znakové typy CHAR(n), pevný počet znaků, až do 2000 znaků VARCHAR2(n), variabilní počet znaků, až do 4000 znaků CLOB, variabilní počet znaků, až do 128 TB Číselné typy NUMBER(prec, scale), variabilní počet číslic, až do 38 desetinných míst Typ datum a čas DATE, TIMESTAMP, INTERVAL Binární objekty (jako JPG, WAV, MP3 atd.) RAW(n), variabilní délka, až do 2000 bytů BLOB, variabilní délka, až do 128 TB

Datové typy Best practices Pro znakové typy je lepší použití VARCHAR2 nebo CLOB na místo CHAR (úspora místa) NUMBER ukládá kladná i záporná čísla, např. NUMBER(6,2) > uloží +9999,99 i -9999,99 TIMESTAMP WITH LOCAL TIME ZONE uloží hodiny včetně odchylky od Universal Coordinated Time (UCT), dříve GMT Při použití v SELECT je čas automaticky převeden na aktuální čas v dané časové zóně

CREATE TABLE time_example (first_column TIMESTAMP WITH TIME ZONE, second_column TIMESTAMP WITH LOCAL TIME ZONE); INSERT INTO time_example (first_column, second_column) VALUES ('15-NOV-2007 08:00:00 AM -05:00, '15-NOV-2007 08:00:00'); Uživatel v Istanbulu provede: a uvidí... LOCAL TIME ZONE TIMESTAMP WITH

Intervalové datové typy Pro uchování uběhlého času, nebo intervalu času mezi dvěma dny-časovými hodnotami INTERVAL YEAR TO MONTH, uloží časovou periodu měřenou rokem a měsícem INTERVAL DAY TO SECOND, uloží časovou periodu měřenou ve dnech, hodinách, minutách a sekundách

Intervalové datové typy

Co si představíte pod pojmem transakce?

Transakce provedení, uzavření obchodu, převod (http://slovnik-cizich-slov.abz.cz/web.php/slovo/transakce) je dohoda, komunikace, přenos nebo výměna čehokoliv mezi dvěma samostatnými entitami nebo objekty. (http://cs.wikipedia.org/wiki/transakce)

Bankovní transakce

Databázová transakce Databázová transakce je skupina příkazů, které převedou databázi z jednoho konzistentního stavu do druhého. (http://cs.wikipedia.org/wiki/databázová_transakce)

Bankovní transakce http://docs.oracle.com/

Vlastnosti transakcí Atomicity (atomičnost) Consistency (zajištění konzistence) Isolation (izolovanost) Durability (trvalost)

Atomičnost transakce Databázová transakce je jako operace dále nedělitelná (atomární). Provede se buď jako celek, nebo se neprovede vůbec. Při neprovedení transakce dochází zpravidla k chybovému hlášení

Konzistence Databáze zůstává neustále konzistentní. Při a po provedení transakce nesmí být porušeno žádné integritní omezení.

Izolovanost Transakce musí být vzájemně nezávislé, dílčí efekty transakce neovlivní jiné transakce. Operace uvnitř transakce jsou skryty před vnějšími operacemi. Vrácením transakce není zasažena jiná transakce, jinak i tato musí být vrácena. V důsledku tohoto chování může dojít k tzv. řetězovému vrácení.

Trvalost Změny, které se provedou jako výsledek úspěšných transakcí, jsou skutečně uloženy v databázi a již nemohou být ztraceny. Efekt celé transakce je trvalý perzistentní.

Způsoby ukončení transakce COMMIT veškeré změny transakce jsou přijaty, od okamžiku potvrzení se stávají viditelné pro všechny ostatní transakce v databázovém systému ROLLBACK situace se vrací do okamžiku před zahájením transakce, všechny změny jsou označeny za neplatné

Příkazy pro řízení transakce SAVEPOINT: Vytvoří značku v transakci, která rozděluje transakci na menší kousky. ROLLBACK TO SAVEPOINT: Umožňuje uživateli vrátit zpět aktuální transakci do zadaného bodu. Byla-li k chybě, uživatel může použít příkaz ROLLBACK TO SAVEPOINT, čímž zahodí pouze ty změny, které byly provedeny poté, co byl založen SAVEPOINT.

Co se stane v této transakci?

Dva režimy práce s databází Sekvence transakcí první transakce je zahájena operací BEGIN TRANSACTION, poté probíhají jednotlivé transakce zakončené COMMIT či ROLLBACK, přičemž ukončení jedné transakce má za následek začátek další transakce Tzv. autocommit režim každá operace je chápána za samostatnou transakci, která implicitně končí COMMIT, pokud nenastala chyba

Aktualizace aplikace App1 je ztracena, jakmile aplikace App2 provede svou aktualizaci, proto se takovému problému říká Ztráta aktualizace. Ztráta aktualizace IBM DB2 Express-C

App2 čte nepotvrzená, neplatná data. Této situaci se také říká nepotvrzené čtení. Nepotvrzené čtení IBM DB2 Express-C

V tomto případě nemůže být znovu reprodukována původní datová sada, App1 nedostane stejná data při čtení; těmto problémům se říká neopakovatelné čtení. Neopakovatelné čtení IBM DB2 Express-C

V tomto případu App1 nedostane stejná data při opakovaném čtení, získá jich více, proto je tento problém nazývaný fantomové čtení. Fantomové čtení IBM DB2 Express-C

Řešení uvedených problémů Definujme pojem rozvrh jako celkový plán posloupnosti všech operací v rámci všech uvažovaných transakcí Řešení uvedených problémů pak spočívá v tzv. uspořádatelnosti rozvrhu Hledáme takový způsob uspořádání operací v jednotlivých transakcích, aby byly všechny stanovené ACID vlastnosti (zejména izolace) z vnějšího úhlu pohledu zachovány

Konkrétní řešení Pro uvedené problémy je jediné možné uspořádání serializace rozvrhu spojení operací odečtení a přičtení N v T1 do jedné posloupnosti nepřerušené jinou transakcí Serializace potláčí paralelní zpracování transakcí snižuje tedy významně výkon databázového serveru

Jiné způsoby uspořádání rozvrhu Mimo serializaci (vysoce neefektivní způsob) by hledání jiných způsobů uspořádatelnosti rozvrhů bylo časově velmi neefektivní (iterativní úloha) Využívá se konstrukcí rozvrhů podle předem stanovených pravidel soubor těchto pravidel označujeme jako protokol Nejčastěji se tyto protokoly konstruují na základě zamykání a odemykání objektů K zamčenému objektu (LOCK) nemá jiná transakce přístup (ochrana izolace)

Dobře formovaná transakce před přístupem k objektu provádí jeho uzamknutí (LOCK) neprovádí LOCK na objekty, které už zamkla neprovádí UNLOCK na objekty, které nezamkla před koncem provede UNLOCK na všechny objekty, které ve svém průběhu zamkla a jsou dosud zamčené

Dvoufázový uzamykací protokol Dvoufázová transakce v první fázi uzamyká vše, co bude potřebovat při svém průběhu Druhá fáze začíná okamžikem prvního odemknutí Ve druhé fázi se zamčené objekty pouze odemykají, tj. nelze již použít žádné operace LOCK Tedy transakce musí mít všechny objekty uzamčené před tím, než nějaký objekt odemkne

Uspořádatelnost 2F protokolu Pokud všechny transakce ve vstupní množině transakcí jsou současně: dobře formované transakce dvoufázové transakce pak každý jejich rozvrh je uspořádatelný Stále ovšem existuje nebezpečí tzv. deadlocku vzájemného uváznutí, tj. vzájemné čekání na dokončení některé operace druhé transakce

Uváznutí http://csunplugged.org/sites/default/files/cartoons/deadlock.jpg

Definice uváznutí Uváznutí (deadlock) je situace, kdy pro každou transakci ze skupiny transakcí jsou splněny následující podmínky: každá transakce ze skupiny je blokována čekáním na objekt databáze (na jeho odemknutí) ukončení všech transakcí mimo uvedenou skupinu transakcí neumožní odblokování žádné transakce ve skupině

Uváznutí (deadlock) Jedná se o situaci, kdy jednotlivé transakce nekonečně dlouho čekají na uvolnění zamknutého objektu http://docs.oracle.com/

Problémy souběhu transakcí Definujme si následující zjednodušené operace: read(x) načtení hodnoty X z databáze write(x) zápis hodnoty X do databáze commit potvrzení transakce rollback odmítnutí transakce Zkusme porovnat souběh dvou transakcí užívajících zjednodušené operace

Řešení problému uváznutí Protože uváznutí je stav, který neumožňuje úspěšně pokračovat v korektním plnění požadavků, je nutné zabránit vzniku uváznutí nebo toto uváznutí detekovat a odstranit ho detekci uváznutí a následné odstranění užíváme při uzamykacím protokolu předcházení uváznutí řešíme metodou časových razítek

Metoda časových razítek I Metoda zajišťující uspořádatelnost rozvrhu Ke každému objektu jsou přiřazena dvě tzv. časová razítka: čas posledního čtení (TSR) čas posledního zápisu (TSW) Každá transakce T dostane na svém začátku svou vlastní hodnotu TS(T), která je unikátní a stále roste (např. pořadové číslo transakce razítko)

Metoda časových razítek II Pokud transakce T volá operaci write(x) jestliže TSR(X) > TS(T), zruš transakci T a proveď rollback(t) (nějaká transakce s razítkem větším než TS(T) již četla X před tím, než T mělo šanci provést zápis) jestliže TSW(X) > TS(T), zruš operaci write(x)a pokračuj (nějaká transakce s razítkem větším než TS(T) již zapisovala X, náš zápis by byl přepsán) jinak proveď write(x), TSW(X) := TS(T)

Metoda časových razítek III Pokud transakce T volá operaci read(x) jestliže TSW(X) > TS(T), zruš transakci T a proveď rollback(t) (nějaká transakce s razítkem větším než TS(T) již zapisovala X před tím, než T mělo šanci číst) jinak proveď read(x), TSR(X) := max(ts(t),tsr(x)) Metoda časových razítek umožňuje rozšíření na metodu nezpůsobující uváznutí (deadlock)

Detekce uváznutí Využívá teorie grafů (předmět v navazujícím stupni studia) Při zamykání vytváří tzv. čekací graf (která transakce čeká na kterou) Pokud v grafu vznikne cyklus, došlo k uváznutí a je nutné cyklus přerušit (ukončit některou transakci obvykle nejstarší nebo nejnovější) Oracle využívá detekce uváznutí

Předcházení uváznutí Některé metody umožňují zabránit vzniku uváznutí Obvykle se jsou tyto metody charakteristické nepovolením přístupu k objektu, se kterým pracuje jiná transakce Významným způsobem redukují paralelizaci rozvrhů a tedy snižují výkon databázového systému Nepodporuje sdílení objektů (např. pro čtení) více různými transakcemi

Implementace v Oracle Základní systém transakcí podporuje ACID, využívá dvoufázového zamykání a provádí detekci uváznutí (deadlocků) s jejich přerušením formou výjimky Implicitní režim transakcí bývá dán aplikací (dbman autocommit, SQL*Plus transakční režim) Existuje možnost stanovení úrovně izolace transakcí pro operace čtení (DQL)

Stanovení úrovně izolace Pomocí parametru relace (session) ALTER SESSION SET ISOLATION LEVEL režim Podporované režimy: READ COMMITED běžný režim (není žádná izolace v rámci DQL) READ UNCOMMITED nepotvrzené čtení REPEATABLE READ čtecí stabilita SERIALIZABLE vytváří větší prostor pro deadlock

Porovnání úrovní izolace Oracle, PgSQL, MSSQL, MySQL IBM DB2 Nepotvrzené čtení Neopakovatelné čtení Fantomové čtení Read uncommitted Read committed Uncommited Read možné možné možné Cursor Stability - možné možné Repeatable read ReadStability - - možné Serializable Repeatable Read - - -

Indexy Index je seřazená sada klíčů, které vedou k řádku v tabulce. Index bere v potaz jedinečnost a také vylepšuje výkon. Index může být řazen vzestupně nebo sestupně Indexové klíče mohou být unikátní nebo neunikátní Pro index může být použito několik sloupců Pokud jsou index a fyzická data klastrovány v podobné indexové sekvenci, jsou klastrovaným indexem CREATE UNIQUE INDEX artno_ix ON artists (artno)

Typy indexů Unique index definován automaticky při použití PRIMARY KYE nebo UNIQUE KEY Nonuniquie index pro rychlejší přístup k řádkům např. FOREIGN KEY Function based index použití UPPER nebo LOWER v klauzuli WHERE CREATE INDEX d_evnt_dt_indx ON d_events (to_char(event_date, mon ))

Kdy použít indexy Rozsáhlé hodnoty ve sloupci Sloupec obsahuje vysoký počet NULL hodnot Jeden nebo více sloupců jsou často využívány dohromady v klauzuli WHERE nebo JOIN Velká tabulka ze které chceme dotazem vrátit méně než 2-4% z celkového počtu řádků K zapamatování: každá DML operace (INSERT, UPDATE, DELETE) nad tabulkou s indexem znamená, že také index musí být přepočítán!

B-stom je druh stromu. Je specifický tím, že má řád n a limity na maximální (n), i minimální (n/2) počet potomků vrcholu. B-strom je díky této vlastnosti vyvážený, operace přidání, vyjmutí i vyhledávání tedy probíhají v logaritmickém čase. (http://cs.wikipedia.org/wiki/b-strom)

Projekt 2 Odevzdat do 19. 4. 2016 17:00 Samostatná práce Převod do fyzického modelu Vytvoření tabulek a integritních 18 dotazů zajímají mě pouze výsledky