Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie
Diplomant: Tomáš Pobuda Vedoucí diplomové práce: Ing. Dušan Chlapek Oponent diplomové práce: Ing. Martin Štrunc
TÉMA DIPLOMOVÉ PRÁCE
Ladění a testování databázových systémů pro potřeby digitálního archivu SAFE
školní rok 2007/2008
Tomáš Pobuda
Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem čerpal.
V Praze dne ........ ………………………………. podpis
Tomáš Pobuda
Poděkování
Rád bych tímto poděkoval panu Ing. Dušanovi Chlapkovi, za poskytnuté rady, cenné připomínky a odborné vedení celé práce.
Tomáš Pobuda
Abstrakt Práce se zabývá laděním databáze Oracle digitálního archivu SAFE. Konkrétně nastavením parametrů databáze a databázového. Je rozdělena na tři části. V první charakterizuje faktory, které ovlivňují výkon databáze. Ve druhé popisuje možnosti ladění a nastavení databáze Oracle. Ve třetí části je nejdříve představen systém SAFE, poté vybrán vhodný testovací nástroj pro generování zátěže a popis testovacích scénářů a naposled jsou provedeny testy a porovnány výsledky při různých nastaveních databáze. Cílem práce je popis a vyzkoušení ladění databáze Oracle, kterou využívá digitální archiv SAFE. Dalším cílem je test rychlosti vkládání souborů digitálního archivu SAFE při různých nastaveních (ukládání do databáze, na souborový systém). Těchto cílů je dosaženo generováním zátěže testovacím nástrojem a porovnáváním doby odezvy při různých nastaveních. Přínosem práce je především vyzkoušení ladění databáze Oracle, která je využívána digitálním archivem SAFE. Dokument může být použit jako příručka pro implementátory testované implementace digitálního archivu SAFE. Klíčová slova: SAFE, digitální archiv, ladění, testování, Oracle
Tomáš Pobuda
Abstract Thesis deal with tuning of database Oracle, which is used by digital archive SAFE. In the concrete deal with setting parameters of database. It is divided to three parts. In first part it characterizes factors that influence performance of database. In second part it describes possibilities of tuning and setting Oracle database. In third part it is first introduced digital archive SAFE, after that it is chosen suitable testing tool for workload generation and described test scenarios and last are performed tests and compared results at different database database settings. Goal of thesis is description and trial tuning of Oracle database, which is used by digital archive SAFE. Other goal is test of files inserting into digital archive at different settings (saving to the database, on file system). These goals are achieved by testing tool workload generation and compare response time at different settings. Contribution of this thesis is above all trial of tuning Oracle database, which is used by digital archive SAFE. Document can be used like handbook for implementatory of tested implementation of digital archive SAFE. Klíčová slova: SAFE, digital archive, tuning, testing, Oracle
Analýza vlivu ladění a jiných změn systému na výkonu SQL příkazů.............................. 52
LADĚNÍ DATABÁZE SYSTÉMU DIGITÁLNÍHO ARCHIVU SAFE ............................... 54 4.1 POPIS SYSTÉMU SAFE.......................................................................................................... 54 4.1.1 Charakteristika systému SAFE ........................................................................................ 55 4.1.2 Architektura ..................................................................................................................... 56 4.1.3 Datový model ................................................................................................................... 57 4.1.3.1 4.1.3.2
4.1.4
Definice objektů ............................................................................................................... 59
4.1.4.1 4.1.4.2 4.1.4.3 4.1.4.4 4.1.4.5
4.1.5
Statická část datového modelu .............................................................................................57 Dynamická část datového modelu ........................................................................................58 Struktura definice objektu ....................................................................................................59 Struktura definice vlastnosti .................................................................................................60 Struktura definice indexu .....................................................................................................62 Manipulace s definicemi.......................................................................................................62 Společné vlastnosti všech objektů ........................................................................................63
4.1.6 Popis testovacího systému SAFE ..................................................................................... 63 4.2 TESTOVACÍ NÁSTROJE .......................................................................................................... 63 4.2.1 Testovací nástroj Apache JMeter..................................................................................... 63 4.2.1.1
4.2.2
Tvorba testovacích scénářů ..................................................................................................63
PŘÍLOHA 1: POPIS STROMU TEST1 ...................................................................................... 63 PŘÍLOHA 2: POPIS STROMU TEST2 ...................................................................................... 63 PŘÍLOHA 3: POPIS STROMU TEST3 ...................................................................................... 63 PŘÍLOHA 4 : POPIS STROMU TEST4...................................................................................... 63 PŘÍLOHA 5: OBSAH TEXTOVÝCH SOUBORŮ .......................................................................... 63 PŘÍLOHA 6: VÝSTUP Z AGGREGATE REPORT A SROVNÁNÍ – NASTAVENÍ PAMĚTI .............. 63 PŘÍLOHA 7: VÝSTUPY AGGREGATE REPORT Z KAPITOLY 4.4 .............................................. 63 PŘÍLOHA 8: GRAFY MEDIÁNU ODEZVY PRO UŽIVATELE – KAPITOLA 4.4............................. 63
-7-
Úvod
Tomáš Pobuda
1 Úvod V poslední době vzrůstá počet firem, požadujících rychlý přístup k dokumentům. Tyto firmy pochází z různých segmentů trhu. Jsou to zejména finanční instituce (pojišťovny, společnosti poskytující nákupy na splátky) či průmyslové společnosti. V klasické papírové podobě dokumentů je vyhledávání pomalé, nákladné a hlavně závislé na tom kde dokument leží. Firmy požadují aplikaci, která bude dostatečně rychlá ve vyhledávání ve statisících až miliónech dokumentů, tak aby měli její zaměstnanci k dispozici dokumenty kdekoli a kdykoli. Například v pojišťovně aplikace ulehčí transport dokumentů mezi pobočkami. Díky aplikaci, si je může jakýkoli zaměstnanec s příslušnými právy vyhledat a zobrazit dokumenty, které potřebuje k práci, a nemusí čekat až mu je někdo pošle faxem nebo dokonce poštou. Základem takové aplikace je obrázek, zpravidla vícestránkový obrázek tiff (viz Term. slovník). V obrázcích se však nedá vyhledávat dle textových řetězců na nich uvedených. Obrázek tedy musí být opatřen popisnými údaji (metadaty). Například na faktuře to mohou být název dodavatele, identifikační číslo, daňové identifikační číslo, datum vystavení, atd. Dle těchto údajů lze pak fakturu vyhledat. Aby byly dokumenty přístupné kdykoli, je nutné použít vhodnou architekturu, kdy jsou dokumenty uloženy na jednom místě a jsou distribuovány jednotlivým klientům. Tedy architekturu klient / server. Pro dálkové přenosy (např. mezi pobočkami) lze využít celosvětovou síť internet. Aby byly dokumenty přístupné kdekoli, je dobré použít jako klienta nejrozšířenějšího klienta, což je internetový prohlížeč. Z toho také vyplívá, že aplikace, by měla být webovou aplikací. Požadavky na takovou aplikaci splňuje systém digitálního archivu SAFE. Tato diplomová práce zabývá laděním databázového systému Oracle, který je využíván digitálním archivem SAFE. Při použití digitálního archivu SAFE může být faktura či smlouva vyhledána kdekoli, kde je možné se připojit k internetu. Jsou to zejména faktury či smlouvy, jejichž denní přírůstky jsou u některých firem (např. pojišťovny) i několik tisíc. V databázi kde je uloženo několik miliónů dokumentů je komplikované vyhledávat. Při složitějších dotazech kdy se musí spojovat více tabulek (tzv. join) s velkým počtem záznamů je databáze extrémně zatížena. Objem dat však nemusí být jediný problém. Dalším je počet současně pracujících uživatelů. V těchto situacích je obtížné udržet odezvu pro uživatele na přijatelné úrovni. Hardwarové prostředky pro běh aplikace a databáze jsou zpravidla omezené a jen těžko lze přimět management k nákupu dalších prostředků. Právě zde se může uplatnit ladění databáze. Základem ladění databáze je sběr potřebných informací o jejím běhu (zpravidla tyto informace nazýváme statistiky). Tyto informace mohou pomoci odhalit problémy například v nastavení parametrů databáze, nedostatek hardwarových prostředků vzhledem k zátěži systému nebo problematické SQL příkazy. Cílem diplomové práce je prozkoumat možnosti ladění databázového systému Oracle. Poté tyto možnosti vyzkoušet prakticky pro databázi digitálního archivu SAFE a zjistit jak různé ladící postupy ovlivňují výkon systému, zejména odezvu pro uživatele. Dalším cílem je odpovědět na otázku, jestli je rychlejší ukládat soubory archivu do databáze Oracle či na souborový systém. Odpověď na tuto otázku by mohla změnit dosavadní způsob implementace systému SAFE, případně vysvětlit chování sytému v různých společnostech. Testy výkonu databází budou prováděny na hardware společnosti AiP SAFE s.r.o.. Tento dokument bude sloužit zejména jako informační zdroj pro databázové administrátory systému SAFE. Vzhledem k tomu, že bude popsáno ladění databázového systému Oracle, může být tento text užitečný pro všechny, kteří hledají informace o ladění databáze Oracle.
-8-
Faktory ovlivňující výkon databázových systémů
Tomáš Pobuda
2 Faktory ovlivňující výkon databázových systémů V této úvodní kapitole si popíšeme některé faktory, které ovlivňují výkon databázových systémů. To nám poskytne přehled nad problémy s výkonem, které jsou řešeny jak programátory, tak správci databáze. Některé je možné ovlivnit bez zásahu programátora do aplikace (např. indexy,nastavení parametrů), ale některé můžeme ovlivnit pouze programátorským zásahem do aplikace (např. normalizace databáze, konstrukce SQL příkazů). Mezi hlavní faktory ovlivňující výkon databázových systémů patří: •
Normalizace databáze
•
Denormalizace databáze
•
Indexy
•
Konstrukce SQL příkazů
•
Víceuživatelské prostředí
•
Nastavení parametrů
2.1 Normalizace databáze Normalizace databáze jedna z technik návrhu relačních databází, která minimalizuje redundantní informace. Dodržením pravidel pro normalizaci databáze nám pomůže vyvarovat se chyb v návrhu, které by mohly způsobovat nekonzistenci v datech při změnách. Stupně normalizace databáze rozlišujeme dle normálních forem. V praxi se normalizuje do třetí normální formy. My si tedy popíšeme první tři, které definoval Edgar F. Codd. První normální forma (1.NF) Tabulka je v první normální formě, pokud neobsahuje opakující se skupiny. Druhá normální forma (2. NF) Tabulka je v druhé normální formě, pokud je v 1. NF a žádné neklíčové atributy nezávisejí pouze na části primárního klíče. Třetí normální forma (3.NF) Tabulka je ve třetí normální formě, pokud je ve 2. NF a žádné atributy nezávisejí na jiných neklíčových atributech. Představme si jednoduchý příklad na, na kterém vysvětlíme normalizaci relační tabulky. Firma eviduje zaměstnance, jejich vedoucího a projekty na kterých pracuje. Nenormalizovaná tabulka by mohla vypadat jako na obrázku Obr. 1. Do 1.NF dostaneme tabulku tak, že odstraníme opakující se skupiny (ID_Projekt1, Nazev projektu1,...) a vytvoříme z nich novou tabulku ZamProjekt (viz Obr. 2)
Tabulka Zamestnanec vyhovuje 2. NF, ale tabulka ZamProjekt ne. Konkrétně její atribut Nazev_projektu nezávisí na obou klíčových atributech ID_Zamestnanec a ID_Projekt, ale pouze na ID_Projekt. Vytvoříme novou tabulku Projekt a relaci přes atribut ID_Projekt (viz Obr. 3). Obr. 3 - 2. NF
Oddělení ID_Oddělení Nazev_oddeleni Nyní nevyhovuje 3. NF tabulka Zamestnanec, kde atribut Nazev_oddeleni závisí na neklíčovém atributu ID_Oddělení. Vytvoříme proto novou tabulku Oddělení a relaci přes atribut ID_oddělení (viz Obr. 4). Vyšší stupně normalizace typicky vyžadují více tabulek což znamená více join operací a může zapříčinit omezení výkonu. Na druhou stranu snižují redundanci dat, což může výkon zlepšit díky menšímu objemu načítaných dat.
2.2 Denormalizace databáze Normalizace je proces ukládání jednoho údaje pouze na jedno místo. To je výhodné pro aktualizace, ale ne pro jejich získávání. Pokud je údaj uložen pouze na jednom místě, získání více různých údajů, které spolu souvisejí znamená, že se musí databázový sytém „kouknout“ na více míst. To může mít za následek zpomalení procesu získávání dat. Na druhou stranu update operace jsou díky tomu rychlejší. Obecně se doporučuje, aby byly databáze navrhovány na základě normalizovaného datového modelu. Přesto však existují situace, kdy je dobré uvažovat o denormalizaci. Tedy o procesu
- 10 -
Faktory ovlivňující výkon databázových systémů
Tomáš Pobuda
ukládání jednoho údaje na více místech, což zrychlí získávání dat na úkor zpomalení jejich modifikace. Důvody denormalizace Jediným důvodem denormalizace je zvýšení výkonu při získávání dat z tabulek. Podle následujících ukazatelů můžeme identifikovat tabulky, u kterých by se dalo uvažovat o denormalizaci: •
Existuje hodně kritických dotazů a reportů, které se dotazují na data z více než jedné tabulky. A tyto požadavky musí být zpracovávány v on-line prostředí.
•
Existují opakující se skupiny, které potřebují být zpracovávány ve skupině a ne individuálně.
•
Musí být aplikováno hodně výpočtů na jeden či více sloupců, než může být proveden dotaz.
•
K tabulkám je přistupováno více uživateli různými způsoby (update, select) ve stejných časových intervalech.
•
Existuje mnoho rozsáhlých primárních klíčů, které jsou těžkopádné pro dotazy a spotřebovávají velké množství místa na discích, když jsou přenášeny jako cizí klíče do jiných tabulek
•
Některé sloupce jsou dotazovány častěji než ostatní. O denormalizaci bychom měli uvažovat když jsou sloupce dotazovány více než 60 % času.
Existuje několik typů denormalizovaných tabulek: •
Pre-Joined tables - předběžně spojené tabulky
•
Report Tables – tabulky reportů
•
Mirror Tables – zrcadlené tabulky
•
Split Tables – rozdělené tabulky
•
Combined Tables – kombinované tabulky
•
Redundant Data – redundantní data
•
Repeating Groups – opakující se skupiny
•
Derivable Data – odvoditelná data
•
Hierarchies - hierarchie
Více o nich pojednává článek [MULLINS]. My je zde podrobně popisovat nebudeme.
2.3 Indexy Index je datová struktura, která umožňuje rychlejší vyhledávání záznamů v tabulce podle indexovaného sloupce (nebo více sloupců, pokud se jedná o složený index). Index obsahuje hodnoty z indexovaného sloupce a ukazatel na řádek, který hodnotě odpovídá. Představme si například tabulku, kde jednoznačným identifikátorem je sloupec ID. Když je pak položen dotaz SELECT * FROM tabulka WHERE ID=1234 a neexistoval by index, musel by databázový systém procházet celou tabulku (načíst všechna data tabulky do paměti). Průměrný počet řádků, které by prohledal je n/2, kde n je počet řádků tabulky. Když je index vytvořen nemusí se procházet postupně celá tabulka. Vyhledání záznamu je rychlejší a je k němu potřeba méně I/O operací disku. Většina databází ukládá indexy ve formě B-stromu (viz Obr. 5). B-strom je stromová struktura seřazených hodnot, kterou můžeme rozdělit na:
- 11 -
Faktory ovlivňující výkon databázových systémů
Tomáš Pobuda
•
branch blocks (větve) – Všechna patra, kromě posledního. Obsahují indexovaná data, která odkazují na nižší indexové bloky.
•
leaf blocks (listy) – Nejnižší patro stromu. Zde jsou všechny indexované hodnoty a jejich rowid, k určení hledaného řádku.
Obr. 5 - Struktura B-stromu [ORA-DC]
Klasické indexy uložené ve formě B-stromů, nemusí být vždy nejvhodnějšími pro všechny typy atributů. Jsou to atributy s nízkou mohutností (např. pohlaví - dvě hodnoty M (muž) , Z (žena)). Zde by klasický index vracel příliš mnoho řádků – jedna indexová hodnota by odkazovala na velké množství řádků. Řešení této situace může být bitmapový index. Princip spočívá v rozložení atributu do bitové masky. Bitmapový index efektivně zpracovává operátory AND a OR ve WHERE klauzuli, protože se provedou boolean operace přímo na indexech, před tím než se převede bitmapa na rowid. Představme si příklad tabulky kde jsou sloupce region a pohlavi (viz Tab. 1). Vytvoříme bitmapový index nad sloupci region (viz Tab. 2) a pohlavi (viz Tab. 3). Tab. 1 - Příklad tabulky pro bitmapový index
id 1 2 3 4
region východ střed východ západ
pohlavi M Z Z M
Tab. 2 - Bitmapový index sloupce region
region = východ 1 0 1 0
region = západ 0 0 0 1
region = střed 0 1 0 0
- 12 -
Faktory ovlivňující výkon databázových systémů
Tomáš Pobuda
Tab. 3 - Bitmapový index pro sloupec pohlavi
pohlaví = M 1 0 0 1
pohlaví = Z 0 1 1 0
Provedení dotazu SELECT COUNT(*) FROM tabulka WHERE pohlavi=‘M‘ AND region=‘východ‘, který najde všechny záznamy kde pohlaví je M a region je výhod, bude díky bitmapovému indexu velice rychlé (viz Tab. 4) Tab. 4 - Výpočet booleovské operace
region = východ 1 0 1 0
pohlavi = M 1 0 0 1
výsledek (AND) 1 0 0 0
2.4 Konstrukce SQL příkazů Špatný přístup ke konstrukci SQL příkazů může mít za následek špatný výkon aplikace. Je možné sestavit dva dotazy vracející stejný výsledek, ale každý bude jinak efektivní (např. jeden prohledá celou tabulku, jiný pouze jeden řádek). Pokud takový dotaz programátor zakomponuje do aplikace, databázový administrátor může dotaz odhalit (jestliže zatěžuje systém), ale opravit ho musí programátor v aplikaci. Existuje několik obecných zásad jak psát SQL dotazy. My si je zde uvedeme: •
Omezte výsledek dotazu použitím klauzule WHERE – tím, že bude klientovi vráceno méně řádků, bude za potřebí přenést méně dat po síti a to může zvýšit celkový výkon dotazu.
•
Omezte výsledek dotazu výběrem sloupců, které opravdu potřebujete – jestliže nevrátíme klientovy všechny sloupce, ale jen některé, tak bude zapotřebí přenést méně dat po síti ke klientovi, což může zvýšit celkový výkon dotazu.
•
Používejte constraints (omezení) místo triggerů, kdykoli je to možné – constraints jsou mnohem efektivnější než triggery. To znamená, že pokud se budeme držet tohoto pravidla, budou naše dotazy efektivnější.
•
Vyhýbejte se klausuli HAVING – tato klauzule se používá k omezení skupin ve výsledku dotazu s klauzulí GROUP BY. Pokud použijeme GROUP BY s HAVING, klauzule GROUP BY rozdělí řádky na skupiny a agreguje jejich hodnoty, klauzule HAVING odstraní nežádoucí agregované skupiny. To ukazuje, že práce na těchto skupinách klauzulí GROUP BY je zbytečná. Lepší je použít klauzuli WHERE kde odstraníme nepotřebné řádky a pak je seskupíme pomocí GROUP BY bez HAVING.
•
Co nejméně používejte klauzuli DISTINCT – pokud to není nutné a nepotřebujeme odstranit duplicitní hodnoty ve sloupci. Použití této klauzule je náročné na výkon.
2.5 Víceuživatelské prostředí (zámky) Při zpracování transakcí ve víceuživatelském prostředí se může stát, že transakce přistupují ke stejným datům v jeden okamžik. Pokud by neexistovali mechanismy jak takové situace řešit, mohlo by se stát, že jedna transakce změní data a než potvrdí změnu, tyto data změní jiná transakce. Obecně můžou vzniknout tři problémy: •
Dirty reads – čtou se řádky změněné nějakou transakcí, ale ještě neproběhl commit (potvrzení).
- 13 -
Faktory ovlivňující výkon databázových systémů
Tomáš Pobuda
•
Nonrepeatable reads – při opakovaném čtení stejných dat zjistí, že byla změněna jinou transakcí
•
Phantom reads – při opakovaném čtení stejných dat zjistí, že byla přidána nová data jinou již potvrzenou (commit) transakcí.
Proto aby nevznikaly tyto problémy s konzistencí byly standardem ANSI/ISO SQL (SQL 92) definovány izolační úrovně: •
Read uncommited – poskytuje nejvyšší propustnost. Blokovány jsou souběžné aktualizace, ale je možné, aby transakce četla nepotvrzené změny jiných transakcí. Tuto izolační úroveň lze použít pouze u transakcí, které buď pouze data mění nebo u nich nezáleží na korektnosti a konzistenci dat. Nedoporučuje se používat.
•
Read comminted – tato izolační úroveň blokuje souběžné aktualizace a dovoluje číst pouze potvrzené změny jiných transakcí. Použít jí lze u transakcí, které zejména mění data a nevyžadují stabilní pohled na data.
•
Repeatable read – mimo blokací úrovně read commited, zajišťuje stabilní pohled na čtená data (čtená data se uzamknou). Vhodné použití je u transakcí, které vyžadují stabilní pohled na data (např. generování sestav)
•
Serializable – vynucuje takové chování transakcí, jako by byly prováděny postupně. Jelikož při této úrovni izolace dochází k častému blokování transakcí, je vhodné ji používat jen v opodstatněných případech
Vlastnosti izolačních úrovní shrnuje tabulka Tab. 5 , kde „X“ znamená výskyt daného problému a „-“ znamená, že je problém eliminován. Tab. 5 - Izolační úrovně
Dirty Read Nonrepeatable read Phantom Read X X X X X X -
Problémy s izolačními úrovněmi •
Blokování – Ideálním případem pro konzistenci dat je izolační úroveň Serializable. Při této úrovni však dochází k častému vzájemnému blokování transakcí a to způsobuje degradaci výkonu. Je tedy nutné nalézt kompromis mezi konzistencí dat a propustností systému.
•
Deadlock – Deadlock vzniká, když transakce A čeká na zámek na záznam aktuálně zamčený transakcí B a zároveň transakce B čeká na zámek na záznam aktuálně uzamčený transakcí A.
Příklad deadlocku: V čase A jedna transakce (T1) uzamkne řádek empno=1000 a druhá transakce (T2) uzamkne řádek empno=2000. V čase B se pokusí transakce T1 uzamknout řádek empno=2000, který je uzamčen transakcí T2 a začne čekat než se řádek uvolní. Poté se pokusí transakce T2 uzamknout řádek empno=1000, který je uzamčen transakcí T1 a vznikne deadlock. Nezáleží na tom jak dlouho by transakce čekali na odemčení záznamu. V této situaci není možné, aby se některá z nich dočkala odemčení záznamu. Když taková situace nastane databázový systém Oracle jednu z čekajících transakcí zruší (rollback), a tím odstraní konfliktní zámky. Druhá transakce obdrží chybu ORA00060 a obvykle by měla být rollbackována nebo může počkat a zkusit znovu poslední příkaz. Obr. 6 - Deadlock [ORA-DC]
- 14 -
Faktory ovlivňující výkon databázových systémů
Tomáš Pobuda
Vzhledem k rollbackům a čekáním, deadlocky ovlivňují negativně výkon databáze. Měli bychom jejich výskyt zredukovat na minimum.
2.6 Nastavení parametrů Parametry lze nastavovat buď pro databázi nebo databázový systém. Databázi chápeme jako soubor, který je „obhospodařován“ databázovým systémem. Mezi parametry databáze se řadí nastavení jako je počet, velikost souborů, způsob zvětšování datových souborů, atd. Parametry databázového systému míníme nastavení inicializačních parametrů, paměťových prostorů, velikosti databázového bloku, atd. Jak je vidět, faktorů ovlivňujících výkon databázového systému je mnoho. Každý se dá nějakým způsobem ladit a zlepšovat tak výkon. My se zaměříme především na nastavování parametrů databáze a databázového systému.
- 15 -
Ladění databázového systému Oracle
Tomáš Pobuda
3 Ladění databázového systému Oracle V této kapitole jsou popsány možnosti ladění databázového systému Oracle 11g Release 1 (11.1). Informace v této kapitole jsou čerpány téměř výhradně z online dokumentace na stránkách společnosti Oracle. Ta je opravdu na vysoké úrovni. Seznam kapitol: •
Novinky a vylepšení v ladění výkonu databáze Oracle 11.1
•
Metoda The Oracle Performance Improvement Method
•
Nástroje pro ladění databáze oracle
•
Optimalizace výkonu databáze
V prvních třech podkapitolách se seznámíme s novinkami a vylepšeními v ladění výkonu databázového systému Oracle 11.1. Dále pak s metodou The Oracle Performance Improvement Method, abychom si ukázali jak se při ladění postupuje. A naposled uvedeme stručný popis nástrojů pro ladění databáze Oracle. Kapitola 3.4 se zabývá zejména správným nastavením parametrů databáze. To jak nastavit určitý parametr obvykle určíme dle nějaké statistiky či statistik. Dalšími tématy tak jsou zajištění sběru statistik a u každého parametru též kde statistiku zjistit. V poslední kapitole je popsáno jak využít nástroje pro automatické ladění SQL příkazů (SQL Tuning Advisor a SQL Access Advisor).
3.1 Novinky a vylepšení v ladění výkonu databáze Oracle 11.1 Úvodem této kapitoly si představíme nové či vylepšené funkce pro ladění výkonu, které Oracle 11.1 nabízí. Nejde o jejich vyčerpávající popis, ale spíše o stručné seznámení. Podrobněji budou jednotlivé nástroje a funkce popsány v samostatných kapitolách. •
Vylepšení ASH (active session history) - Statistiky ASH nyní poskytují informace o činnostech na úrovni řádků pro každý SQL příkaz. Mohou být využity například při identifikaci části SQL příkazu, která se při provádění nejvíce podílela na celkovém čase provádění tohoto příkazu.
•
Vylepšení ADDM (automatic database diagnostic monitor) - ADDM bylo vylepšeno tak, aby provádělo analýzu na databázových clusterech na různých úrovních granularity (databázový cluster, instance databáze) v daný časový interval.
•
Automatizované ladění SQL - Je možné automatizovat plánování činností SQL Tuning Advisor, aby běžely během automatické údržby.
•
Výchozí bod AWR (advaced workload repository) - Výchozí bod obsahuje data o výkonu za daný časový interval pro porovnání s jinými časovými intervaly s podobnou zátěží pokud se vyskytnou problémy s výkonem.
•
Database Replay (~ přehrání databáze) - Je možné zachytit zatížení databáze na produkčním systému a „přehrát“ ho na testovacím systému, aby bylo možné zjistit, jestli změny (upgrade databáze) přináší požadované výsledky.
•
Vylepšené statistiky I/O - Statistiky I/O jsou sbírány ze všech volání I/O databází Oracle v těchto úrovních: zákaznická skupina, databázový soubor, databázová funkce.
•
Vylepšená údržba statistik optimizátoru - Sběr a publikování statistik je odděleno. Statistiky pro optimizátor jsou sbírány jako „nevyřízené“ a po jejich otestování zveřejněny jen platné statistiky.
- 16 -
Ladění databázového systému Oracle
Tomáš Pobuda
•
Rozšířené statistiky - Optimizátor sbírá údaje o skupinách sloupců v tabulce (MultiColumn statistiky) k analýze závislostí sloupců ve skupině sloupců. Také shromažďuje údaje o výrazech ve sloupcích.
•
Kalibrace I/O - I/O kalibrační funkce Oracle databáze umožňuje zhodnotit výkonnost úložného subsystému a rozhodnout jestli jsou problémy s I/O výkonností zapříčiněné databází nebo úložným subsystémem.
•
Cache výsledků dotazů - Lze ukládat výsledky často zpracovávaných příkazů SQL v cache serveru nebo klienta. To umožňuje dosahovat rychlejší odezvu při těchto příkazech.
•
Monitorování SQL v reálném čase - Takové monitorování umožňuje sledování dlouhotrvajících SQL příkazů, právě když jsou vykonávány. Statistiky pro toto sledování jsou v nových pohledech V$SQL_MONITOR A V$PLAN_MONITOR.
•
SQL Performance Analyzer (analyzátor výkonu SQL) - Umožňuje předpovídat dopad změn systému na výkon SQL, testováním těchto změn při SQL zátěži na testovacím systému.
•
Výchozí body SQL exekučního plánu - Změny v exekučním plánu pro SQL příkaz může zapříčinit velké snížení výkonu. Databáze získává, vybírá a vyvíjí výchozí body SQL plánů, tak aby optimalizátor nepoužíval nový plán, dokud není ověřeno, že je efektivnější než stávající plán. Tato funkcionalita nahrazuje „plan stability“ používané v předchozí verzi Oracle Database (10gR2).
•
Tvorba testových případů SQL - Nástroj SQL Test Case Builder umožňuje vytvořit testový případ, který jde „přehrát“ na jiném systému. Problém s SQL tak může být vyřešen na testovacím systému.
3.2 Metoda The Oracle Performance Improvement Method Tato metoda si klade za cíl identifikovat a odstraňovat úzká místa systému, která mohou snižovat výkon databáze. Odstraněním jednoho úzkého místa však může být odhaleno jiné. Po odstranění jednoho úzkého místa tedy nemusí ihned dojít ke zlepšení výkonu. Zlepšení může nastat až po několika cyklech (identifikace, odstranění úzkého místa). Zlepšování výkonu je tedy iterativní metodou. Postup metody The Oracle Performance Improvement Method je rozdělen do šesti kroků: 1.
Provést výchozí kontrolu: a) Získat informace od uživatelů a definovat cíle ladění. b) Obstarat si kompletní statistiky operačního systému, databáze a aplikace ze systému, kde je výkon dobrý i špatný. c) Zkontrolovat jestli je plně využíván hardware a zdroje operačního systému, které mohou ovlivnit výkon pro uživatele. Také ověřit, že všechen hardware pracuje bezchybně.
2.
Zkontrolovat jestli se nejedná o jednu z deseti nejběžnějších chyb v Oracle popsaných níže. ADDM automaticky detekuje a hlásí devět z deseti těchto chyb.
3.
Vytvoření konceptuálního modelu chování systému, kde budou zaznamenány symptomy, které jsou vodítky k pochopení problémů s výkonem.
4.
Návrh série akcí odstraňující problémy s výkonem a jejich očekávaného efektu. Po té tyto akce vykonáváme v takovém pořadí v jakém pozitivně ovlivňují výkon aplikace. Nástroj ADDM (automatic database diagnostic monitor) vytváří návrhy jak zlepšit výkon, každý s očekávaným přínosem. Důležité je aplikovat jednotlivé akce jednotlivě, tak aby bylo možné změřit jejich dopad na systém. Pokud bychom aplikovali více změn najednou, pak by bylo nemožné měřit jejich jednotlivé přínosy.
- 17 -
Ladění databázového systému Oracle
Tomáš Pobuda
5.
Ověření zda měli provedené změny očekávaný efekt a zda se uživatel zaznamenal zlepšení výkonu. Pokud není dosaženo očekávaného efektu, pokračujeme v hledání dalších úzkých míst a vylepšujeme konceptuální model.
6.
Opakovat poslední tři kroky dokud nebudou splněny cíle ladění nebo se stane nemožným tyto cíle splnit díky dalším omezením.
Deset nejčastějších chyb v databázi Oracle: 1.
Špatná správa spojení – časté připojování a odpojování aplikace od databáze.
2.
Špatné využití kursorů a předem přeložených dotazů – nepoužívání kursorů má za následek opakovaný překlad dotazů. Pokud nejsou dotazy sestavovány s dosaditelnými proměnnými vyžaduje každé spuštění dotazu jeho opakované přeložení a vytvoření plánu zpracování. Měli bychom být nedůvěřivý k aplikacím generujícím dynamické SQL.
3.
Špatný kód SQL – špatný SQL kód je takový, který využívá více systémových zdrojů než je přiměřené pro prostředí dané aplikace. SQL příkazy, které spotřebovávají nadměrné množství systémových zdrojů by měli být prozkoumány, jestli je nejde zlepšit.
4.
Použití nestandardních inicializačních parametrů – takové nastavení může být provedeno na základě špatných rad nebo nesprávných předpokladů. Většina systémů pracuje s přijatelným výkonem, jestliže jsou nastaveny pouze základní parametry. Pokud tedy nastavujeme nějaké parametry, je nutné znát dopady těchto nastavení na celou databázi.
5.
Špatné I/O databáze – provozovatelé databází rozmístí špatně soubory databáze na disky, které má zrovna k dispozici. Jiní se příliš soustředí na kapacitu disků a ne na jejich propustnost.
6.
Špatné nastavení Redo logů – málo a malé redo logy mohou zapříčinit nadměrnou vytíženost buffer cache (cache pro zápis do datových souborů) a následně také I/O systému. Zápis do logů pak „zdržuje“ celou databázi.
7.
Serializace datových bloků v buffer cache kvůli nedostatku volných listů, skupin listů, transakčních slotů nebo rollback segmentů – to je běžné u aplikací, které vkládají hodně záznamů a byla nastavena velikost databázového bloku více než 8Kb nebo u aplikací s velkým množstvím aktivních uživatelů a málo rollback segmenty.
8.
Dlouhé zbytečné full table scany – mohou být zapříčiněny špatným designem transakcí, chybějícími indexy nebo špatnou optimalizací SQL příkazů. Způsobují zejména přetížení I/O systému.
9.
Vysoké objemy rekurzivního SQL – pokud se hodně rekurzivních SQL příkazů vykonává pod uživatelem SYS, může to znamenat operace správy místa databáze, jako je například alokace extentů. Odezva systému se tím může značně zhoršit.
10. Chyby při nasazení a migraci – při migraci z vývojového prostředí nebo starší implementace se může stát, že schéma vlastnící tabulky nebylo úspěšně zmigrováno. Příkladem jsou chybějící indexy nebo chybné statistiky. Dochází pak k přetěžování databáze.
3.3 Nástroje pro ladění databáze Oracle Chceme-li ladit výkon databáze, potom je nutné sbírat a analyzovat data týkající se výkonu databáze. Oracle nabízí dostatek nástrojů jak pro sběr dat, tak pro analýzu. Většina z těchto nástrojů je automatická a je řízena prvkem Oracle backgroud processes. Aby byly statistiky sbírány automaticky musí být nastaven inicializační parametr STATISTICS_LEVEL na hodnotu TYPICAL nebo ALL. Jednotlivé nástroje popíši důkladně v kapitole Optimalizace výkonu instance databáze. Nyní uvedeme seznam nástrojů a jejich stručný popis. •
Oracle Enterprise Manager (EM) – základní nástroj pro správu databáze založený na webovém uživatelském rozhraní. Odtud lze spravovat databázi (databáze) a také ostatní
- 18 -
Ladění databázového systému Oracle
Tomáš Pobuda
nástroje, které jsou do tohoto prostředí většinou implementovány. Jsou zde také rádci jako například Memory Advisor (optimalizace paměti pro instanci databáze) nebo jiní rádci pro optimalizaci MTTR(mean time to recovery), správu segmentů nebo nastavení undo tablespace. Na stránce Performance page v EM můžeme též sledovat zatížení systému v reálném čase. •
Automatic Workload Repository (AWR) – sbírá, zpracovává, a udržuje statistiky výkonu pro účel detekce problémů a sebe-ladění (automatické ladění).
•
Automatic Database Diagnostic Monitor (ADDM) – analyzuje data nasbíraná AWR a odhaluje možné problémy s výkonem databáze.
•
SQL Tuning Advisor – umožňuje rychlou a účinnou optimalizaci SQL příkazů bez změn v příkazech.
•
SQL Access Advisor – poskytuje rady ohledně materializovaných pohledů, indexů a logů materializovaných pohledů.
•
End to End Aplication Tracing – nástroj pro identifikaci uživatele, služby či komponenty, která enormně zatěžuje systém.
•
Server-generated Alerts – databáze umí upozornit na hrozící nebezpečí.
•
V$ Performance Views – V$ pohledy jsou zdrojem dat pro všechny ladící nástroje. Tyto pohledy jsou založeny na paměťové struktuře načtené při startu databázové instance. Paměťové struktury a pohledy, které je reprezentují, jsou automaticky udržovány databází při jejím běhu.
3.4 Optimalizace výkonu databáze V této kapitole popíšeme jak ladit jednotlivé prvky databáze, aby byl optimalizován výkon databázové instance Oracle.
3.4.1 Nastavení parametrů databáze Tato kapitola obsahuje přehled metodologie nastavování parametrů databáze. Ačkoli většina nastavení lze provádět při spuštěné databázi, správným nastavením inicializačních parametrů lze získat další významné zlepšení výkonu. Inicializační parametry Běžící databáze je nastavena dle inicializačních parametrů. Tyto parametry načítá při startu ze souboru parameter file. V tabulce 6 uvedeme důležité parametry, které mají vliv na výkon databáze.
- 19 -
Ladění databázového systému Oracle
Tomáš Pobuda
Tab. 6 – důležité inicializační parametry ovlivňující výkon [ORA-PTG]
Parametr COMPATIBLE
DB_BLOCK_SIZE
MEMORY_TARGET
SGA_TARGET
PGA_AGREGATE_TARGET PROCESSES
SESSIONS UNDO_MANAGEMENT UNDO_TABLESPACE
Popis Specifikuje verzi se kterou musí být Oracle server kompatibilní.Pokud například aktualizuji verzi databáze, ale aplikace která ji využívá je optimalizována na předchozí verzi, mohu zde nastavit tuto předchozí verzi a přesto využívat např. vylepšení správy v nové verzi. Určuje velikost databázového bloku ukládaného v souborech a cacheovaný v SGA. Pro systémy s transakčním zpracováním je to obvykle 8192 bajtů. Určuje celkovou velikost paměti. Aktivuje automatickou správu paměti. Oracle pak sám rozděluje paměť mezi SGA a PGA. Určuje celkovou velikost všech součástí SGA (system global area). Pokud je nastaven SGA_TARGET pak jsou paměťové prostory automaticky rozděleny mezi buffer cache, Java pool, shared pool, large pool (viz Obr. 7) Určuje celkovou velikost alokované paměti pro server procesy připojené k databázi. Nastavuje maximální počet procesů, které mohou být spuštěny databází. Toto je velmi důležitý parametr, jelikož se z něj odvozuje mnoho jiných parametrů (počet sessions, transactions, atd.). Tento parametr se odvozuje od parametru PROCESSES Nastavuje se s ním mód undo space management. Defaultní hodnota je AUTO. Určuje tablespace, který bude undo tablespacem po spuštění databáze.
Nastavení Undo Space Databáze používá prostor undo space pro účely zotavení,konzistenci čtení a rollback příkazy. Tato data jsou uložena v undo tablespacech. Oracle doporučuje nastavení parametru UNDO_MANAGEMET na AUTO. Manuální undo management využívající rollback segmenty je podporován pouze kvůli zpětné kompatibilitě. Obr. 7 – Struktura paměti Oracle Database [KRCH]
- 20 -
Ladění databázového systému Oracle
Tomáš Pobuda
Nastavení velikosti souborů Redo logů Velikost souborů redo logů může ovlivňovat výkon, protože ovlivňuje chování procesů database writer (zápis do souborů na disk) a archiver (zápis redo logů do archivních logů). Obecně větší redo logy poskytují lepší výkon. Poddimenzované log soubory zvyšují četnost checkpointů (intervaly zápisu) a snižují výkon. Optimální velikost redo logů lze získat dotazem na view V$INSTANCE_RECOVERY ve sloupci OPTIMAL_LOGFILE_SIZE nebo také v Enterprise Manager na stránce Redo Log Groups. Musí být nastaven parametr FAST_START_MTTR_TARGET, který udává jaký může být počet bloků (systémových) redo log souboru mezi posledním checkpointem a posledním zapsaným blokem. Vždy nemusí být možné poskytnout doporučení pro velikost redo logů. Avšak redo logy velikosti stovek megabajtů až jednotek gigabajtů jsou považovány za rozumné nastavení. Vždy bychom měli přihlížet k tomu, kolik redo operací generuje náš systém. Pro přibližné určení velikosti redo logů se uvádí, že by neměl nastat switch (změna z jedné redo log group na jinou – tzn. zaplnění jedné redo log group) dříve než po dvaceti minutách. Vytvoření dodatečných tablespace V každé databázi by měli být kromě tablespace SYSTEM a SYSAUX další tablespace: •
temporary tablespace – využívá se např. pro třídění
•
undo tablespace – obsahuje informace pro konzistenci čtení, zotavení a rollback příkazy.
•
alespoň jeden tablespace pro aplikaci
Pro permanentní tablespace (permanent tablespace) je doporučováno použití automatické správy volného místa v segmentech (automatic segmet-space managemet). Takovéto tablespace se obvykle nazývají bitmapové tablespace. Dále je doporučováno nastavení locally managed tablespace pro správu extentů. Pro dočasné tablespace (temporary tablespace) se doporučuje nastavení locally managed tablespace s UNIFORM extentem o velikosti 1 MB. Dobře nastavené dočasné tablespace pomáhají optimalizovat výkon disku při třídících operacích. Měli bychom monitorovat dočasné tablespace a zjišťovat kolik extentů je alokováno pro dočasný segmet. Pokud aplikace nadměrně využívá dočasné tabulky nebo uživatelé souběžně používají dočasné tabulky, měli bychom snížit velikost extentu např. na 256KB. Jelikož každé použití dočasné tabulky vyžaduje nejméně jeden extent.
- 21 -
Ladění databázového systému Oracle
Tomáš Pobuda
Obr. 8 – přehled nastavení správy prostoru [KRCH]
EXTENT MANAGEMENT (Jak se eviduje volné místo v tablespace, které nebylo alokováno do segmentů)
SEGMENT SPACE MANAGEMENT (Jak se eviduje volné místo alokované do segmentu)
LOCAL (Locally Managed Tablespace) AUTOALLOCATE (Rostoucí velikost extentů)
AUTOMATIC (Bitmap)
UNIFORM (Stálá velikost extentů)
DICTIONARY
MANUAL
(Dictionary Managed Tablespace)
(Freelisty)
Zastaralé technologie, nedoporučuje se používat
Vytváření a správa tabulek pro optimální výkon Když instalujeme aplikace, úvodním krokem je vytvoření všech nezbytných tabulek a indexů. Pokud vytvoříme segmet, například tabulku, Oracle alokuje místo pro data v databázi. Pokud dojde později k nárůstu dat v tabulce a překročí alokované místo, potom Oracle rozšíří segmet o extent. Nastavením parametru PCTFREE říkáme, kolik volného místa (v procentech) se má v databázovém bloku udržovat pro možné updaty existujících řádků. To znamená, že pokud je dosažena hranice např. 20% volného místa, blok již nedovolí vkládat nové řádky.
- 22 -
Ladění databázového systému Oracle
Tomáš Pobuda
Obr. 9 – Datový blok (databázový blok)[ORA-DC]
Header (Common and Variable) Hlavička obsahuje informace o adrese bloku, typu segmentu (např. data, index). Table Directory Informace o tabulce, která má řádky v tomto bloku. Row Directory Informace o počtu řádků v bloku a adresy dat pro každý řádek. Free Space Volné místo pro vkládání nových řádků nebo aktualizace řádků, která potřebuje další místo (např. když se změní hodnota null na nonnull hodnotu) Row Data Data řádků tabulek či indexů (řádky mohou být ve více blocích) Komprimace tabulky Heap-organized tabulky (neřazené záznamy jeden za druhým) lze ukládat v komprimovaném formátu. Komprimují se nejen duplicitní hodnoty v jednom sloupci, ale tam kde je to možné, je snaha komprimovat i vícesloupcové kombinace hodnot. Komprimace je vhodná pro tabulky, které jsou určeny zejména pro čtení. V tomto případě může komprimace zvýšit výkon při operacích čtení, protože se přenáší menší množství dat a tak je za potřebí méně I/O operací. Obnovení nepoužívaného místa Je běžné, že časem se místo segmentu fragmentuje nebo je mu alokováno hodně volného místa důsledkem update a delete operací. To zapříčiňuje řídce obsazené objekty a může způsobovat snížení výkonu při DML operacích. V databázi Oracle lze tento problém řešit pomocí Segmet Advisor. Tento nástroj poskytuje informaci o objektech, které mají místo pro obnovení, tak že v nich spočítá úroveň fragmentace. Pokud má některý objekt takové místo, pak je možné zmenšit segment nebo dealokovat nepoužité místo na konci segmentu. Indexování Dat Nejefektivnější způsob vytváření indexů je po nahrání dat. Díky tomu je správa místa jednodušší a nemusí vytvářet zvlášť index se pro každý vkládaný řádek(SQL*Loader to dělá automaticky). Pokud chceme zrychlit vytváření indexu a máme dost volných prostředků (CPU, disk controllers) použijeme paralelní zpracování SQL příkazu (př. CREATE INDEX PARALLEL). To znamená, že více procesů pracuje současně při zpracování jednoho SQL příkazu. Během vytváření indexů tabulek musí být data setříděna. Třídění je tím rychlejší, čím více paměti je pro třídění použito. Oracle doporučuje nastavit automatické nastavení velikosti SQL working area (místo pro práci s SQL). Toho docílíme nastavením inicializačního parametru PGA_AGREGATE_TARGET.
3.4.2 Automatické ladění výkonu Aby bylo možné zjistit příčinu výkonnostních problémů, je nutné mít statistiky. Bez nich by nebylo možné provádět diagnostiku. Oracle generuje velké množství kumulativních statistik, které jsou dostupné například přes dynamické pohledy V$SESSTAT nebo V$SYSSTAT. Když je zastavena (shutdown) databáze, tak jsou tyto statistiky vymazány. O jejich uchovávání se stará Automatic Workload Repository (AWR). Oracle dále zaznamenává statistiky, které nazýváme metrické. Tyto statistiky říkají jak mnoho se mění kumulativní statistiky (např. počet volání databáze za sekundu).
- 23 -
Ladění databázového systému Oracle
Tomáš Pobuda
Třetí typ statistik, které oracle zaznamenává jsou data snímků. Snímkování je prováděno nástrojem active session history (ASH) sampler. Dalším užitečným nástrojem diagnostiky jsou výchozí body (baseline). Statistická baseline je kolekce statistik naměřených v době kdy systém pracuje dobře při špičce. Porovnáním se statistikami získanými během špatného výkonu systému zjistíme, jaké ze statistik se podstatně změnili a kde může být problém. Databázové statistiky Databázové statistiky poskytují informace o druhu zatížení databáze a interních a externích zdrojích využívaných databází. Nejdůležitější statistiky jsou: •
Wait Events (čekání na událost)
•
Statistiky časového modelu
•
Historie aktivní relace (session)
•
Statistiky systému a relací (sessions)
Wait Events Jsou to statistiky, které jsou získávány server procesy, k indikaci toho, že proces musí počkat na událost než může pokračovat ve zpracování. Informace z těchto statistik mohou odhalit symptomy problémů jako je blokované spojení, kolize bufferů a I/O kolize. Statistiky dle časového modelu Každá komponenta databáze Oracle má vlastní sadu statistik. Analyzovat tak systém jako celek vyžaduje mít společné měřítko. Tím je čas. Nejdůležitější statistikou je DB time (databázový čas). Tato statistika zaznamenává celkový čas strávený voláními databáze a je ukazatelem celkového zatížení instance. Je počítána součtem časů CPU a Wait Event časů všech aktivních relací. Historie aktivní relace Pohled V$ACTIVE_SESSION_HISTORY obsahuje snímky aktivity relace v instanci databáze. Aktivní relace jsou snímkovány každou sekundu a jsou ukládány do circular buffer v paměti SGA. Část snímků je uložena na disk nástrojem Automatic Workload Repository. Díky tomu lze porovnávat aktuální data z pohledu V$ACTIVE_SESSION_HISTORY a historická data z pohledu DBA_HIST_ACTIVE_SESS_HISTORY. Statistiky systému a relací Pro systém a relace je k dispozici velké množství kumulativních statistik. Všechny mohou být nalezeny v pohledech V$SYSSTAT a V$SESSTAT. Statistiky operačního systému Mezi tyto statistiky řadíme ty, které poskytují informace o využití a výkonu hlavních hardwarových komponent systému a operačního systému jako takového. Díky těmto informacím můžeme objevit přetížené komponenty v systému. Mezi statistiky operačního systému řadíme: •
statistiky CPU
•
statistiky virtuální paměti
•
statistiky I/O operací disku
•
statistiky sítě
- 24 -
Ladění databázového systému Oracle
Tomáš Pobuda
Statistiky CPU Při ladění je využití procesoru nejdůležitější statistika operačního systému. Měli bychom zjišťovat využití procesoru pro celý systém a pro každou CPU ve víceprocesorových prostředích. Zpravidla se využití procesoru měří jako čas strávený v tzv. user mode (instrukce uživatelské aplikace) a kernel mode (instrukce jádra operačního systému). V prostředí kde jsou všechny procesory plně využity by měl Oracle běžet od 65% do 95% v user mode. Pohled V$OSSTAT obsahuje informace o vytížení hardware a pohled V$SYSMETRIC_HISTORY obsahuje hodinovou historii využití CPU. Statistiky virtuální paměti Používají se hlavně jako ověření, že prakticky nedochází ke stránkování či swapování (odkládání na disk) paměti. Pokud by k tomu docházelo, nepříznivě by to ovlivnilo výkon systému. Statistiky I/O operací disku Vzhledem k tomu, že jsou soubory databáze uloženy na discích, výkon I/O subsystému značně ovlivňuje výkon databáze. Nejdůležitějšími statistikami jsou aktuální doba odezvy a délka fronty na disku. Díky nim můžeme zjistit jestli disky pracují optimálně nebo jsou přetížené. Za normální dobu odezvy se považuje 5 až 20 milisekund. Pokud fronta na disku začne překračovat 2, je dobré prověřit jestli není disk potencionálním úzkým místem. Kromě těchto jsou sbírány ještě statistiky ve třech dimenzích pro jednotlivé a vícenásobné čtení bloku a operace zápisu: • uživatelské skupiny Pokud je aktivovaný Oracle Database Resource Manager, můžeme najít I/O statistiky pro všechny uživatelské skupiny v pohledu V$IOSTAT_CONSUMER_GROUP. Snímky jsou vytvářeny každou hodinu a ukládány jako historické statistiky v AWR. • soubory databáze I/O statistiky databázových souborů, na které byl přístup nalezneme v pohledu V$IOSTAT_FILE. • funkce databáze I/O statistiky databázových funkcí (jako jsou LGWR a DBWR) jsou v pohledu V$IOSTAT_FUNCTION. Statistiky sítě Síťové statistiky používáme podobně jako statistiky disků. K určení jestli síť nebo síťový interface není přetížený. V síťových aplikacích může být latence sítě velkou částí času odezvy uživatele. Statistiky můžeme nalézt v pohledu V$IOSTAT_NETWORK. Tab. 7 – Nástroje pro sběr statistik na operačním systému UNIX
3.4.2.1 Automatic Workload Repository (AWR) AWR je nástroj, který sbírá, zpracovává a zpravuje výkonnostní statistiky pro detekci problémů a samo-ladící účely. Tato data jsou uchovávána v paměti i v databázi (na disku). Nasbíraná data mohou být zobrazována v rámci reportů a pohledů (view). AWR sbírá a zpracovává tyto statistiky: •
statistiky přístupů a využití databázových segmentů
- 25 -
Ladění databázového systému Oracle
Tomáš Pobuda
•
statistiky dle časového modelu přístupné přes pohledy V$SYS_TIME_MODEL a V$SESS_TIME_MODEL
•
statistiky SQL příkazů, které vysoce zatěžují systém, založené na celkové době a čase CPU
•
statistiky ASH, reprezentující historii aktivity posledních relací.
Sběr statistik pomocí AWR je implicitně zapnuto a je regulováno pomocí inicializačního parametru STATISTICS_LEVEL jehož nastavení může být: •
BASIC – znemožní používat hodně nástrojů databáze Oracle včetně AWR a není doporučováno
•
TYPICAL – při tomto nastavení se sbírají všechny významné statistiky. Stačí pro většinu prostředí. Je to výchozí hodnota.
•
ALL – navíc se sbírají statistiky exekučních plánů a časové statistiky OS
Popis AWR zde můžeme rozdělit na následující části: •
Snímky (snapshots)
•
Výchozí body (baselines)
•
Spotřeba úložného prostoru (Space Consumption)
Snímky Jsou to historická data z daných časových okamžiků, která jsou používána pro porovnání výkonu nástrojem ADDM. Při základním nastavení, databáze Oracle automaticky generuje snímky dat výkonu každou hodinu a uchovává statistiky v centrálním úložišti 8 dní. Data ze snímků jsou pak analyzována ADDM. Výchozí body Výchozí bod obsahuje data z daného časového intervalu, která jsou uchovávána za účelem porovnání s jinými podobnými časovými intervaly, kdy je podobné zatížení databáze, ale objevují se problémy s výkonem. Ve výchozím bodu jsou snímky, které nejsou AWR nikdy automaticky mazány. Výchozí body můžeme rozdělit na: •
Stálé – odpovídá pevné časové době z minulosti
•
Pohyblivé – bere v úvahu všechna data z AWR
•
Šablony – dále se dělí na: o
jednotlivé – používáme je když potřebujeme vytvořit výchozí bod v budoucnosti
o
opakované – používáme je když potřebujeme vytvořit výchozí bod v budoucnosti dle plánu.
Spotřeba úložného prostoru Prostor potřebný pro uložení dat generovaných AWR je závislý na několika faktorech: •
Počet aktivních relací v systému
•
Interval snímků
•
Doba uchování historických dat
- 26 -
Ladění databázového systému Oracle
Tomáš Pobuda
Při výchozím nastavení kdy jsou data snímána každou hodinu a uchovávána 8 dní a 10-ti aktivních relacích jsou nároky dat AWR na úložný prostor zhruba 200 až 300 MB. Zvětšením intervalu snímků a zkrácením doby uchovávání dat můžeme snížit spotřebu místa. Pokud to uděláme, může to poznamenat přesnost některých nástrojů závislých na datech AWR, jako jsou: •
Automatic Database Diagnostic Monitor
•
SQL Tuning Advisor
•
Undo Advisor
•
Segment Advisor
Doporučuje se nastavit takovou dobu uchování dat, aby byl uložen celý cyklus zátěže. Například pokud je během pracovního týdne systém zatížen běžnou prací uživatelů a o víkendu se prování dávkové operace, můžeme nechat nastavenu implicitní dobu 8 dní, protože bude uložena jak zátěž během pracovního týdne tak i rozdílná zátěž o víkendu.
3.4.2.2 Automatic Database Diagnostic Monitor (ADDM) Pokud se v systému objeví problém, je nezbytné přesně a včasně diagnostikovat problém než začneme dělat v systému změny. Statistická data pro diagnostiku problému jsou uložena v AWR a jsou využívána ADDM (automatic database diagnostic monitor). Ve většině případů by mělo být ADDM první místo kam se podívat, pokud nastane problém. ADDM poskytuje následující funkce: •
Automatickou diagnostiku výkonu každou hodinu
•
Diagnostiku problému založenou na zkušenostech z ladění po desetiletí
•
Časová kvantifikace dopadů problémů a užitek z doporučení
•
Identifikace hlavních příčin, ne jen symptomů
•
Doporučení pro řešení problémů
•
Identifikace bezproblémových oblastí systému
•
Minimální zátěž systému během diagnostiky
Je nutné si uvědomit, že ladění je iterativní proces a odstranění jednoho problému, může zapříčinit vznik jiného problému. Takže i s funkcemi, které poskytuje ADDM, může být ladění vícekolový proces ladění, než systém dosáhne požadovaného výkonu. Další popis ADDM můžeme rozdělit následovně: •
ADDM analýza
•
Výsledky ADDM analýzy
ADDM analýza Každá ADDM analýza může být provedena na páru AWR snímků, které definují časové období pro analýzu. ADDM analýza je prováděna vždy, když AWR vygeneruje snímek a výsledky jsou uloženy do databáze. Časové období analyzované ADDM je definováno posledními dvěma snímky (při základním nastavení je to 1 hodina). Manuálně lze spustit analýzu pro jakékoli dva snímky z AWR, které nebyly dosud smazány. Základním prostředím pro ADDM je Oracle Enterprise Manager. Zde je možné spravovat ADDM i zobrazovat výsledky analýz. ADDM analýza je prováděna tak, že se nejdříve identifikují symptomy a poté z nich hlavní příčiny problémů s výkonem. Cílem analýzy je snížit metriku DB time (databázový čas). Pro připomenutí, je to celkový čas strávený databází vykonáváním uživatelských požadavků. Obsahuje čekací čas a
- 27 -
Ladění databázového systému Oracle
Tomáš Pobuda
čas CPU aktivních uživatelských relací. Snížením DB time je databáze schopná obsloužit více uživatelů při použití stejných zdrojů, což zvyšuje propustnost. Problémy nalezené ADDM jsou seřazeny podle DB time, který spotřebovávají. Části systému, které spotřebovávají malou část DB time jsou udávané jako bezproblémové. Některé typy problémů, které ADDM zvažuje: •
Vytíženost CPU – Je CPU zatěžováno Oraclem nebo jinou aplikací?
•
Nedostatečně velké paměťové struktury – Jsou paměťové struktury (SGA, PGA, buffer cache) nastaveny na dostatečnou velikost.
•
Otázky kapacity I/O – Pracuje I/O subsystém jak bylo předpokládáno?
•
Vysoce zatěžující SQL příkazy – Jsou zde SQL příkazy, které spotřebovávají velké množství systémových zdrojů?
•
Sub-optimální používání Oracle aplikací – Jsou zde problémy se špatnou správou spojení, nadměrné parsování nebo kolize zámků na aplikační úrovni.
•
Otázky konfigurace databáze – Je zde důkaz špatného nastavení velikosti log souborů, otázky archivace, nepřiměřené množství checkpointů nebo špatné nastavení parametrů?
•
Otázky současného přístupu – Jsou nějaké problémy s vytížeností bufferů?
Výsledky ADDM analýzy Kromě diagnostiky problému, ADDM navíc doporučuje možná řešení. Výsledky ADDM analýzy jsou prezentovány jako sada nálezů. Nálezy mohou být rozděleny na typy: •
Nálezy problémů popisují hlavní příčiny výkonového problému databáze.
•
Nálezy symptomů obsahují informace, které často vedou k jednomu či více nálezům problémů.
•
Informace relevantní pro pochopení dané oblasti výkonu databáze.
•
Upozornění obsahující informace o problémech které mohou ovlivnit úplnost a přesnost ADDM analýzy (např. chybějící data v AWR)
Každý nález problému je kvantifikován jako odhad DB time, který spotřebovává. Nálezu mohou být přiřazena doporučení, která sníží dopad na výkonový problém. Jaké typy doporučení můžeme dostat? •
Změna hardware – přidání CPU nebo změna konfigurace I/O subsystému
•
Konfigurace databáze – změna nastavení inicializačních parametrů
•
Změny schéma – rozdělení rozsáhlých datových tabulek do menších částí nebo použití automatické správy segmentů (ASSM – automatic segment-space management)
•
Změny aplikace – použití cache pro sekvence nebo používání vazebných proměnných
•
Využití jiných rádců – například SQL Tuning Advisor pro SQL zatěžující systém nebo Segment Advisor pro velké či hodně využívané objekty
Seznam doporučení může obsahovat několik alternativ jak vyřešit daný problém. Takže není nutné aplikovat všechna doporučení, aby byl problém vyřešen.
- 28 -
Ladění databázového systému Oracle
Tomáš Pobuda
3.4.3 Konfigurace paměti Oracle ukládá informace do paměti cashe a na disk. Přístup do cashe (RAM) je několikanásobně rychlejší (přístup do cashe je v řádech nanosekund a přístup na disk v řádech milisekund) než přístup na disk (fyzické I/O). Proto je výhodnější aby byly objekty, ke kterým se často přistupuje,v paměti cashe. Cílem ladění paměti je minimalizace přístupu na disk, jak je to jen možné. Lze toho docílit tím, že zvýšíme pravděpodobnost umístění požadovaných dat v cache nebo zefektivníme proces získávání dat. Oracle používá tyto paměti cache: • Shared pool •
Large pool
•
Java pool
•
Buffer cache
•
Streams pool size
•
Log buffer
•
Privátní paměť procesů
Automatic Memory Management Oracle doporučuje používání automatické správy paměti (automatic memory management). Automatická správa paměti umožní databázi spravovat a ladit paměť instance. Automatickou správu můžeme konfigurovat, tak že nastavíme parametry pro plánovanou velikost paměti (MEMORY_TARGET) a maximální plánovanou velikost paměti (MEMORY_MAX_TARGET). Databáze si pak paměť rozdělí mezi system global area (SGA) a program global area (PGA) tak jak potřebuje. Pokud potřebujeme konfigurovat rozvržení paměti je v Enterprise Manageru dostupný rádce Memory Advisor. Automatic Shared Memory Management Pokud si chceme zjednodušit nastavování SGA, můžeme použít Automatic shared memory management, nastavením inicializačního parametru SGA_TARGET na nenulovou hodnotu a parametru STATISTICS_LEVEL na TYPICAL nebo ALL. Nastavení parametru SGA_TARGET lze dynamicky měnit v Enterprise Manageru. Podmínkou je pouze aby parametr SGA_TARGET byl menší nebo roven parametru SGA_MAX_SIZE. Pro změnu velikosti parametru SGA_MAX_SIZE musíme restartovat databázi. Paměť přidělenou parametrem SGA_TARGET rozdělí automatická správa dle zátěže databáze na tyto paměťové prostory: •
Database buffer cache (default pool)
•
Shared pool
•
Large pool
•
Java pool
•
Strems pool
Pokud jsou pro tyto paměťové prostory nastavené parametry (DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE, STREAMS_POOL_SIZE) na nenulové hodnoty, pak je Automatic shared memory management bere jako minimální hodnoty, které může jednotlivým prostorům přiřadit. Následující paměťové prostory nejsou ovlivněny Automatic Shared Memory Management, ale jsou nastavovány manuálně:
- 29 -
Ladění databázového systému Oracle
Tomáš Pobuda
•
Log buffer
•
jiné buffer cache (např. KEEP, RECYCLE)
•
Fixed SGA a jiné interní alokace
Pro nastavení těchto prostorů jsou k dispozici následující parametry: DB_KEEP_CACHE_SIZE, DB_RECYCLE_CACHE_SIZE, DB_nK_CACHE_SIZE a LOG_BUFFER. Využití operační paměti systému Jelikož smysl SGA je ukládat data pro rychlý přístup, měla by být v operační paměti. Pokud by se data SGA swapovala (odkládala) na disk, pak už by nebyla rychle přístupná a negativně by to ovlivnilo výkon. Pokud tedy alokujeme velkou SGA paměť na systému, kde by pro ní nebylo místo v operační paměti, bude výhoda velké SGA převážena nevýhodou swapování na disk. Jestliže chceme, aby se za žádných okolností SGA neswapovala na disk, můžeme nastavit parametr LOCK_SGA na TRUE. Nevýhodou je, že pokud je nastaven parametr LOCK_SGA na TRUE, tak nelze použít parametry MEMORY_TARGET a MEMORY_MAX_TARGET. Když nastavujeme velikost SGA, musíme myslet také na individuální procesy serveru, operační systém nebo jiné programy běžící na serveru. Součet alokací paměti pro Oracle by měl být menší než množství operační paměti mínus paměť pro další aplikace a operační systém, aby nedocházelo ke swapování na disk. Tab. 8 – přehled módů správy paměti (Memory management) [ORA-DC]
Velikost PGA target pro Individual PGA sizes instanci
Manual PGA memory management (nedoporučuje se)
PGA
Maximální pracovní prostor velikost pro každý typ SQL operátoru
-
3.4.3.1 Konfigurace buffer cache Pro hodně typů operací využívá Oracle buffer cache k ukládání bloků přečtených z disku. Takto uložené bloky jsou rychleji přístupné, než uložené na disku.
- 30 -
Ladění databázového systému Oracle
Tomáš Pobuda
Nastavení velikosti buffer cache Je skoro nemožné vědět, jak velkou nastavit buffer cache na nové instanci. Dá se postupovat, tak že odhadneme velikost buffer cache a poté spustíme na databázi reprezentativní vzorek zátěže. Po sběru a vyhodnocení statistik můžeme usoudit, že je cache poddimenzovaná nebo předimenzovaná. Informace pro rozhodnutí o velikosti buffer cache nám mohou též poskytnout: •
V$DB_CACHE_ADVICE – pohled s odhady čtení z disku v závislosti na velikosti buffer cache (viz Tab. 9)
•
Buffer cache hit ratio – koeficient „zásahů“ do cache
V$DB_CACHE_ADVICE Tento pohled můžeme aktivovat nastavením parametru DB_CACHE_ADVICE na ON. Nastavení lze měnit i za běhu databáze. Lze tak sbírat data pro specifickou zátěž. Při aktivaci pohledu nepatrně vzroste zatížení CPU, kvůli zápisu dat do pohledu. Sloupce, které nás z V$DB_CACHE_ADVICE zajímají: •
size_for_estimate – velikost cache (v MB)
•
buffers_for_estimate – počet bufferů (db bloků)
•
estd_physical_read_factor – koeficient udávající procentní změnu fyzických čtení z disku
•
estd_physical_reads – odhadovaný počet fyzických čtení z disku
SQL dotaz: SELECT size_for_estimate, buffers_for_estimate, estd_physical_read_factor, estd_physical_reads FROM V$DB_CACHE_ADVICE WHERE name = 'DEFAULT' AND block_size = (SELECT value FROM V$PARAMETER WHERE name ='db_block_size') AND advice_status = 'ON'; Tab. 9 – příklad V$DB_CACHE_ADVICE [ORA-PTG] Cache Buffers Estd Phys Read Factor Estd Phys Reads Size (MB)
V tabulce s ukázkou pohledu V$DB_CACHE_ADVICE vidíme,že aktuální velikost buffer cache je 304 MB. Pokud bychom snížily paměť třeba na 273 MB, pak se odhaduje, že čtení z disku se zvýší o 13% (1,13 estd. phys. read factor). Naopak při zvýšení velikosti cache na 334 MB se předpokládá, že se čtení z disku sníží o 7% (0.93 estd. phys. read factor). Vztah mezi velikostí cache a počtem čtení z disku není vždy hladká funkce. Když nastavujeme velikost buffer cache musíme myslet na to, že ne každé zvýšení velikosti buffer cache musí vést k předpokládanému snížení čtení z disku. Pokud se podíváme na obrázek Obr. 10, vidíme, že čtení z disku se při zvětšení buffer cache z A na B zmenší méně než při zvětšení buffer cache z B na C. Obr. 10 – Čtení z disku a velikost buffer cache [upravený: ORA-PTG]
Buffer cache hit ratio Tento koeficient ukazuje jak často je požadovaný blok nalezen v buffer cache. Používá se k verifikaci odhadovaných čtení z disku. Vypočítáme ho z údajů v pohledu V$SYSSTAT (viz Tab. 10). K tomu Tab. 10 – statistiky pro výpočet hit ratio [zdroj: ORA-PTG]
Statistika consistent gets from cache db block gets from cache physical reads cache
Popis Počet požadavků na čtení shodného bloku z buffer cache. Počet požadavků na blok z buffer cache. Počet bloků načtených do buffer cache z disku
Buffer cache hit ratio spočítáme podle vzorce: 1 - (('physical reads cache') / ('consistent gets from cache' + 'db block gets from cache') Když je koeficient buffer cache hit ratio nízký, měla by být buffer cache zvětšena. Je však nutné zvážit další okolnosti, které mohou nízký koeficient způsobovat. Koeficient buffer cache hit ratio může být nízký například pokud aplikace generuje dotazy, při nichž se prohledávají všechny řádky velkých tabulek (full table scan). Bloky, které jsou čteny při prohledávání řádků velkých tabulek, jsou vloženy na konec LRU (least recently used – v poslední době nejméně používané) seznamu a ne na začátek. Tudíž jsou tyto bloky smazány dříve než bloky čtené při small table scanech nebo indexovém vyhledávání. Dalším faktorem ovlivňujícím buffer cache ratio je stavba aplikace. Pokud
- 32 -
Ladění databázového systému Oracle
Tomáš Pobuda
se provádí operace, které nevyužívají cache, zvětšení buffer cache nebude mít žádný dopad na výkon. Více bufferů Většinou stačí pokud je nastaven DEFAULT buffer prostor. Ale může být výhodné nastavit více prostorů bufferu. Když je objekt asociován s cache, všechny bloky tohoto objektu jsou umístěny do cache. Pokud není cache dostatečně velká pro uložení všech alokovaných segmentů, jsou mazány nejstarší bloky v cache. Při náhodném čtení velmi velkých segmentů (více než 10% velikosti buffer cache), mohou tyto vytlačovat menší segmenty z cache. Velké segmenty pak zabírají velkou část cache, ale vzhledem k malé četnosti jejich čtení není umístění v cache přínosem. Segmenty, do kterých je přistupováno atypicky, je dobré ukládat do speciálních prostorů bufferu: •
KEEP – pro malé, často DB_KEEP_CACHE_SIZE.
•
RECYCLE – pro velké, málo DB_RECYCLE_CACHE_SIZE.
čtené čtené
segmenty. segmenty.
Nastavuje Nastavuje
se
parametrem
se
parametrem
3.4.3.2 Konfigurace shared pool Shared pool je místo v paměti, které dále dělíme na library cache, dictionary cache a result cache. V library cache se ukládají nedávno vykonané SQL a PL/SQL příkazy ve spustitelné formě (parsované a zkompilované). Dictionary cache uchovává nedávno čtená data z data dictionary (informace o tabulkách, indexech, atd.). A v result cache se uchovávají výsledky dotazů (SQL) a funkcí PL/SQL. Nastavení velikosti shared pool není, stejně jako u buffer cache, jednoduché. Na nové instanci lze odhadnout velikost shared pool a poté spustit reprezentativní vzorek zátěže na databázi. Po prozkoumání relevantních statistik můžeme říci jestli je velikost shared pool dostatečná nebo je příliš malá. Pohled V$SHARED_POOL_ADVICE obsahuje podpůrné informace pro rozhodnutí o velikosti shared pool jako je odhadovaný čas parsování při různých velikostech shared pool. Cílem je nastavit takovou velikost shared pool, kdy všechny často používané SQL dotazy jsou v cache při minimální alokaci paměti. Pokud není vykonávaný SQL dotaz v paměti, pak se jedná o tzv. hard parse (SQL příkaz se parsuje). Pokud však v paměti je, jedná se o tzv. soft parse (SQL příkaz se čte z paměti ve spustitelné formě). Statistiky library cache Statistika, která ukazuje množství překladů (parsování) SQL příkazů dříve načtených do cache, je ve sloupci RELOADS pohledu V$LIBRARYCACHE. Pokud se tato hodnota blíží nule, je nastavena správná velikost shared pool. Ve sloupci INVALIDATIONS stejného pohledu je statistika ukazující kolikrát byla data v library cache zneplatněna (např. v důsledku DDL operace) a musela být znovu parsována. Tato statistika by se měla také blížit nule, pokud je systém dobře nastaven. Podílem součtů hodnot ve sloupcích PINS (počet požadavků na objekt z library cache) a PINHITS (kolikrát byl požadavek na objekt library cache nalezen v paměti) vypočítáme statistiku library cache hit ratio: Library cache hit ratio = sum(pinhits) / sum(pins).
- 33 -
Ladění databázového systému Oracle
Tomáš Pobuda
Tab. 11 – Příklad výstupu z pohledu V$LIBRARYCACHE [zdroj: ORA-PTG]
NAMESPACE BODY CLUSTER INDEX OBJECT PIPE SQL AREA TABLE/PROCEDURE
PINS 8870 393 380 29 0 55265 21536413 10775684
PINHITS 8819 0 0 0 55263 21520516 10774401
RELOADS 0 0 0 0 0 11204 0
INVALIDATIONS 0 0 0 0 2 0
Další důležitá statistika je velikost volné paměti (najdeme v pohledu V$SGASTAT) při zátěži ve špičce. Optimálně by měla být co nejmenší, ale tak velká aby nedocházelo k opětovnému překladu (RELOADS). Statistiky dictionary cache Pokud je dobře nastavena velikost shared pool pro library cache, pak je z pravidla dobře nastavena i pro dictionary cache. Efektivita dictionary cache pro každý typ z data dictionary je dostupná z pohledu V$ROWCACHE dotazem: SELECT parameter , sum(gets) , sum(getmisses) , 100*sum(gets - getmisses) / sum(gets) pct_succ_gets , sum(modifications) updates FROM V$ROWCACHE WHERE gets > 0 GROUP BY parameter;
Vysvětlení důležitých sloupců a příklad výstupu tohoto dotazu jsou v následujících tabulkách. Tab. 12 – Důležité sloupce pohledu V$ROWCACHE
Sloupec PARAMETER GETS GETMISSES MODIFICATIONS
Popis Jméno položky data dictionary (prefix dc_) Počet požadavků na informace o položce data dictionary Počet požadavků, které nebyli načteny z cache. Počet aktualizací dat v dictionary cache.
- 34 -
Ladění databázového systému Oracle
Tomáš Pobuda
Tab. 13 – Příklad výstupu pohledu V$ROWCACHE [zdroj: ORA-PTG]
Celkové cache hit ratio lze získat dotazem: SELECT (SUM(GETS - GETMISSES - FIXED)) / SUM(GETS) "ROW CACHE" FROM V$ROWCACHE;
Statistiky result cache K prohlížení statistik můžeme využít buď pohledů (viz Tab. 14) nebo balíčku PL/SQL DBMS_RESULT_CACHE. Tento balíček umožňuje nejen získávat statistiky o result cache, ale vykonávat i operace jako je například vyprázdnění paměti cache (flush). Tímto příkazem získáme přehled alokací paměti: SQL> set serveroutput on SQL> execute dbms_result_cache.memory_report
Tab. 14 – Pohledy pro result cache
Pohled V$_RESULT_CACHE_STATISTICS V$RESULT_CACHE_MEMORY
Popis Statistiky o nastavení cache a využití paměti (viz Tab. 15) Seznam všech paměťových bloků a jejich statistik.
Příkazem SQL získáme tabulku s daty(viz Tab. 15): column name format a20 select name, value from v$result_cache_statistics;
- 35 -
Ladění databázového systému Oracle
Tomáš Pobuda
Tab. 15 – Příklad výstupu pohledu V$_RESULT_CACHE_STATISTICS [zdroj: ORA-PTG]
NAME Block Size (Bytes) Block Count Maximum Block Count Current Result Size Maximum (Blocks) Create Count Success Create Count Failure Find Count Invalidation Count Delete Count Invalid Delete Count Valid
VALUE 1024 3136 32 156 2 0 0 0 0 0
Systém, který dobře používá result cache pro SQL příkazy by měl vykazovat malé hodnoty Create Count Failure a Delete Count Valid a relativně velké hodnoty Find Count.
3.4.3.3 Large pool Large pool nemá na rozdíl od shared pool LRU list. To znamená, že objekty z large pool nejsou mazány na základě jejich stáří. Konfigurovat large pool má smysl pokud naše databáze používá: •
Parallel query
•
Recovery Manager
•
Share server
Této oblasti se nebudeme více věnovat, protože nebude využívána v praktické části práce.
3.4.3.4 Konfigurace Redo log buffer Server procesy, které dělají změny do data bloků v buffer cache, generují redo data do log bufferu. LGWR (log writer) začíná zapisovat data z redo log bufferu do online redo logů pokud: •
log buffer je zaplněn z jedné třetiny
•
LGWR je informován server procesem o COMMIT nebo ROLLBACK
•
DBWR (database writer) informuje LGWR, že má zapsat data z bufferu
Jakmile jsou zapsána data z redo log bufferu do redo log souboru na disk, je možné přepsat tato data v paměti novými záznamy. LGWR zapisuje tak rychle, aby zajistil, že bude v bufferu dost místa pro nové záznamy i při velké zátěži. Čím je buffer větší, tím je větší šance, že zde bude místo pro nové záznamy. Také to dává čas log writeru efektivně zapisovat redo záznamy. Malý log buffer na systému, kde probíhá hodně UPDATE operací, může zapříčinit nepřetržité zapisování z bufferu na disk. To by znamenalo velkou degradaci výkonu. Velikost redo log bufferu určuje inicializační parametr LOG_BUFFER (udáván v bajtech). Lze ho nastavit před startem instance, poté už nemůže být modifikován.
- 36 -
Ladění databázového systému Oracle
Tomáš Pobuda
Obr. 11 – Redo log buffer [zdroj: ORA-PTG]
Nastavení velikosti redo log buffer Redo log buffer je malou částí SGA v porovnání s celkovou velikostí SGA. Jeho dobré nastavení však může významně ovlivnit výkon na systémech kde probíhá hodně UPDATE operací. Jako rozumný odhad velikosti bufferu se bere: MAX (0,5 MB, (128 KB * počet cpu) Na většině systémů nemá smysl nastavovat velikost redo log bufferu větší než 1 MB. Na druhou stranu nemá zvětšování velikosti bufferu negativní dopad na výkon. Pouze je plýtváno s pamětí. Statistiky redo log buffer Statistika REDO LOG BUFFER ALLOCATION RETRIES odráží počet čekání uživatelských procesů na místo v redo log bufferu. Tuto statistiku můžeme najít v dynamickém pohledu V$SYSSTAT příkazem: SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME = 'redo buffer allocation retries';
Měla by se pohybovat okolo nuly. Pokud by se zvyšovala, pak by to znamenalo, že procesy musí čekat na místo a tudíž je velikost redo log bufferu malá (jinou příčinou může být velký počet checkpointů).
3.4.3.5 Správa PGA paměti Program global area (PGA) je privátní paměť server procesů. Přístup do ní mají pouze server procesy. Data v této paměti jsou například runtime oblasti kurzorů. Při vykonávání komplikovaných dotazů je přiřazena velká část runtime oblasti pracovním oblastem. Ty jsou alokovány operátory, které potřebují hodně paměti: •
Třídící operátory (ORDER BY, GROUP BY, ROLLUP)
•
Hash-join
•
Slučování bitmap
•
Vytváření bitmap
•
Write buffery používané při importu velkého množství dat
- 37 -
Ladění databázového systému Oracle
Tomáš Pobuda
Třídící operátor používá pracovní oblast (třídící oblast) pro řazení řádků přímo v paměti. Podobně, hash-join operátor používá pracovní oblast (hash oblast) k vytvoření hash tabulky z jejího levého vstupu. Velikost pracovní oblasti může být kontrolována a laděna. Obecně větší pracovní oblast znamená zvýšení výkonu jednotlivého operátoru za cenu vyšší spotřeby paměti. Ideálně je pracovní oblast dost velká pro uložení vstupních dat a pomocných paměťových struktur alokovaných asociovaným SQL operátorem (optimální velikost pracovní oblasti). Pokud je velikost pracovní oblasti menší než optimální, zvýší se odezva, jelikož je proveden extra průchod částí vstupních dat (jednoprůchodová velikost pracovní oblasti). Když je velikost pracovní oblasti tak malá, že musí být prováděno více průchodů vstupními daty, nazýváme tuto situaci víceprůchodová velikost pracovní oblasti. Pokud například potřebuje třídící operace 10 GB ke třídění, bude potřeba o trochu více než 10 GB, aby mohla být provedena optimálně a nejméně 40 MB aby mohla být provedena jednoprůchodově. Při pracovní oblasti menší než 40 MB, bude muset být operace provedena víceprůchodově. Cílem je aby většina pracovních oblastí běžela optimálně, a pouze malé množství (například méně než 10%) jednoprůchodově. Měli bychom se vyhnout víceprůchodovému provádění. Jak je zřejmé z příkladu, tak i při třídění velkého množství dat je potřeba relativně malá třídící oblast pro jednoprůchodové provedení. Nastavení automatické správy PGA paměti Jestliže máme nastavenu automatickou správu paměti PGA, nastavení velikosti pracovních oblastí je automatické a _AREA_SIZE (SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE and CREATE_BITMAP_AREA_SIZE) parametry jsou ignorovány. Velikost PGA paměti dostupné pro pracovní oblasti je automaticky odvozena od inicializačního parametru PGA_AGGREGATE_TARGET. Je to velikost nastavená v PGA_AGGREGATE_TARGET mínus paměť alokovaná jinými komponentami systému (například PGA paměť alokovaná relaci). Zbývající paměť je pak rozdělována pracovním oblastem podle jejich paměťových požadavků. Při konfiguraci nové instance databáze je těžké odhadnout PGA_AGGREGATE_TARGET. Lze postupovat v těchto krocích:
jak
nastavit
parametr
•
Uděláme úvodní odhad pro PGA_AGGREGATE_TARGET. Standardně Oracle používá velikost 20 % SGA, což je dostačující prvotní nastavení pro OLTP systémy.
•
Necháme proběhnout representativní zátěž a monitorujeme výkon (sledujeme statistiky PGA)
•
Ladíme parametr PGA_AGGREGATE_TARGET za použití informací ze statistik
Monitorování výkonu automatické správy PGA paměti Před tím než začneme ladit velikost PGA paměti, měli bychom prozkoumat statistiky. Pro tyto účely jsou vhodné dynamické pohledy: •
V$PGASTAT
•
V$PROCESS
•
V$SQL_WORKAREA_HISTOGRAM
V$PGASTAT Tento pohled obsahuje informace o využití paměti PGA na úrovni instance databáze. Výstup z tohoto pohledu může vypadat například jako v tabulce Tab. 16.
- 38 -
Ladění databázového systému Oracle
Tomáš Pobuda
Tab. 16 – V$PGASTAT příklad výstupu [ORA-PTG]
NAME aggregate PGA target parameter aggregate PGA auto target global memory bound total PGA inuse total PGA allocated maximum PGA allocated total freeable PGA memory PGA memory freed back to OS total PGA used for auto workareas maximum PGA used for auto workareas total PGA used for manual workareas maximum PGA used for manual workareas over allocation count bytes processed extra bytes read/written cache hit percentage
aggregate PGA auto target – velikost PGA paměti, kterou může Oracle použít pro pracovní prostory běžící v automatickém módu. Pokud je tato hodnota malá v porovnání s hodnotou PGA_AGGREGATE_TARGET, pak je hodně paměti použito pro jiné komponenty systému (např. PL/SQL nebo Java memory) a zbývá jí málo pro třídící pracovní prostory.
•
global memory bound – hodnota maximální velikosti pracovní oblasti běžící v AUTO módu. Tato hodnota by neměla klesnout pod jeden megabyte.
•
total PGA allocated – aktuální množství PGA paměti alokované instancí. Oracle se snaží toto číslo udržet menší než hodnotu PGA_AGGREGATE_TARGET. Při velké zátěži však může o pár procent přesáhnout tuto hodnotu.
•
total freeable PGA memory – kolik může být uvolněno PGA paměti
•
total PGA used for auto workareas – kolik paměti PGA je právě používáno pracovními prostory běžícími v módu automatické správy.
•
over allocation count – kumulativní statistika překročení alokace paměti nad hodnotu PGA_AGGREGATE_TARGET. Pokud je alokace překračována, pak by měla být navýšena paměť dle informací z pohledu V$ PGA_TARGET_ADVICE.
•
total bytes processed (BP) – počet bajtů zpracovaných SQL operátory intenzivně využívající paměť. Je používána k vypočítání metriky cache hit percentage.
•
extra bytes read/written (EBP) – bajty zpracovávané při extra průchodech vstupních dat. Je používáno k výpočtu metriky cache hit percentage
•
cashe hit percentage – vypočítaná metrika odrážející výkon PGA paměti. Je vypočítaná dle vzorce: BP x 100 / (BP+EBP)
V$PROCESS Tento pohled obsahuje informace o všech procesech připojených k databázi. Výstup pohledu může vypadat například jako v Tab. 17.
V$SQL_WORKAREA_HISTOGRAM Tento pohled ukazuje počet provedených pracovních oblastí optimálně, jednoprůchodově a víceprůchodově od startu databáze. Pracovní oblasti jsou rozděleny do skupin. Každá skupina je definována dolní a horní mezí velikosti pracovní oblasti (LOW_OPTIMAL_SIZE a HIGH_OPTIMAL_SIZE). Tabulku zobrazíme dotazem: SELECT LOW_OPTIMAL_SIZE/1024 low_kb, (HIGH_OPTIMAL_SIZE+1)/1024 high_kb, OPTIMAL_EXECUTIONS, ONEPASS_EXECUTIONS, MULTIPASSES_EXECUTIONS FROM V$SQL_WORKAREA_HISTOGRAM WHERE TOTAL_EXECUTIONS != 0;
Výsledek dotazu může vypadat jako v Tab. 18. Tab. 18 - Výsledek dotazu na pohled V$SQL_WORKAREA_HISTOGRAM [ORA-PTG] LOW_KB
Jiným dotazem na pohled V$SQL_WORKAREA_HISTOGRAM můžeme získat procentuální vyjádření podílu optimálních, jednoprůchodových a víceprůchodových provedení. V našem příkladu je ještě podmínka aby byla spodní hranice (low_optimal_size) větší než 64 KB. SELECT optimal_count, round(optimal_count*100/total, 2) optimal_perc, onepass_count, round(onepass_count*100/total, 2) onepass_perc, multipass_count, round(multipass_count*100/total, 2) multipass_perc FROM (SELECT decode(sum(total_executions), 0, 1, sum(total_executions)) total, sum(OPTIMAL_EXECUTIONS) optimal_count, sum(ONEPASS_EXECUTIONS) onepass_count, sum(MULTIPASSES_EXECUTIONS) multipass_count FROM v$sql_workarea_histogram WHERE low_optimal_size > 64*1024);
Výsledek tohoto dotazu může vypadat například jako v Tab. 19: Tab. 19 - Procentuální zobrazení pohledu V$SQL_WORKAREA_HISTOGRAM OPTIMAL_COUNT
OPTIMAL_PERC
ONEPASS_COUNT
ONEPASS_PERC
MULTIPASS_COUNT
MULTIPASS_PERC
2239
81.63
504
18.37
0
0
Ladění PGA_AGREGATE_TARGET Databázový systém Oracle nám pomáhá s nastavením parametru PGA_AGGREGATE_TARGET dvěma pohledy: •
V$PGA_TARGET_ADVICE
•
V$PGA_TARGET_ADVICE_HISTOGRAM
Prozkoumáním těchto dvou pohledů, získáme dostatek informací pro rozhodnutí o hodnotě PGA_AGGREGATE_TARGET. V obou pohledech najdeme predikci statistik při měnící se hodnotě parametru PGA_AGGREGATE_TARGET. Pohledy se automaticky generují pokud jsou nastaveny parametry: •
PGA_AGREGATE_TARGET – pro aktivaci automatické správy PGA paměti.
•
STATISTICS_LEVEL – nastaven na TYPICAL nebo ALL.
Je potřeba upozornit na to,že hodnoty vypočítané simulací v těchto pohledech nemusí odpovídat realitě. Po tom co nastavíme parametr PGA_AGGREGATE_TARGET, bychom měli ověřit jestli výkon odpovídá očekáváním. V$PGA_TARGET_ADVICE Tento pohledu jsou vypočítávány statistiky cache hit percentage (procento „zásahu“ do cache) a overallocation count (počet alokací nad nastavení velikosti PGA paměti) v závislosti na velikosti parametru PGA_AGREGATE_TARGET. Typický dotaz na tento pohled vypadá takto: SELECT round(PGA_TARGET_FOR_ESTIMATE/1024/1024) target_mb, ESTD_PGA_CACHE_HIT_PERCENTAGE cache_hit_perc, ESTD_OVERALLOC_COUNT FROM V$PGA_TARGET_ADVICE;
Výsledek tohoto dotazu může vypadat například jako v Tab. 20:
- 41 -
Ladění databázového systému Oracle
Tomáš Pobuda
Tab. 20 - Příklad výsledku dotazu na pohled V$PGA_TARGET_ADVICE
V$PGA_TARGET_ADVICE_HISTOGRAM Tento pohled počítá odhadované hodnoty statistik z pohledu V$SQL_WORKAREA_HISTOGRAM pokud měníme parametr PGA_AGREGATE_TARGET. Příklad dotazu na tento pohled je uveden níže a odpovídá situaci kdybychom zvýšili parametr PGA_AGGREGATE_TARGET dvojnásobně oproti stávající hodnotě. SELECT LOW_OPTIMAL_SIZE/1024 low_kb, (HIGH_OPTIMAL_SIZE+1)/1024 high_kb, estd_optimal_executions estd_opt_cnt, estd_onepass_executions estd_onepass_cnt, estd_multipasses_executions estd_mpass_cnt FROM v$pga_target_advice_histogram WHERE pga_target_factor = 2 AND estd_total_executions != 0 ORDER BY 1;
Výsledek dotazu může vypadat například jako v Tab. 21. Tab. 21 - Příklad výsledku dotazu na pohled V$PGA_TARGET_ADVICE_HISTOGRAM LOW_KB HIGH_KB ESTD_OPTIMAL_CNT ESTD_ONEPASS_CNT ESTD_MPASS_CNT
3.4.4 Kalibrace a konfigurace I/O Výkon většiny aplikací je ovlivněn čtením/zápisem (I/O) na disk. Pokud pak taková aplikace stráví většinu času tím, že CPU čeká na I/O operace disku, pak můžeme říci, že hlavním omezením pro ni je disk. Databázový systém Oracle je navrhnut tak, aby nebyl limitován I/O (viz kap. 3.4.3). Ladění I/O pak může zlepšit výkon aplikace, jestliže nejsou požadavky na I/O vyřizovány v přijatelném čase. Pokud je však limitujícím faktorem například CPU, pak konfigurací I/O výkon nezlepšíme.
3.4.4.1 Kalibrace I/O Databázový systém Oracle umožňuje použít kalibraci I/O, abychom změřili výkon úložného subsystému. Pomůže nám určit jestli jsou problémy s výkonem zapříčiněny databází nebo úložným subsystémem. Dále popíšeme jaké jsou nezbytné předpoklady před spuštěním kalibrace a následně i spuštění kalibrace. Předpoklady před spuštěním kalibrace I/O: • uživatel musí mít přidělené právo SYSDBA • parametr timed_statistics musí být nastaven na TRUE • Musí být povoleno asynchronní I/O (nastavíme parametr filesystemio_options na SETALL) • zajistíme povolení asynchronního I/O pro datové soubory spuštěním tohoto příkazu: col name format a50 select name,asynch_io from v$datafile f,v$iostat_file i where f.file#=i.file_no and filetype_name='Data File';
Doporučuje se spouštět pouze jednu kalibraci v jeden okamžik. Jinak by byly výsledky zkresleny. Spuštění kalibrace I/O Kalibraci I/O se spouštíme procedurou DBMS_RESOURCE_MANAGER.CALIBRATE_IO. Tato procedura vytvoří zátěž intenzivním čtením z disku, aby určila maximum IOPS (I/O requests per second – I/O požadavky za sekundu) a maximum MBPS (megabytes of I/O per second – megabajty I/O za sekundu). Díky zátěži, která je kalibrací generována, by měla být kalibrace prováděna mimo špičky, když není databáze používána (například přes noc). Kalibraci spustíme příkazem: SET SERVEROUTPUT ON DECLARE lat INTEGER; iops INTEGER; mbps INTEGER; BEGIN -- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (, <MAX_LATENCY>, iops, mbps, lat); DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat); DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops); DBMS_OUTPUT.PUT_LINE ('latency = ' || lat); dbms_output.put_line('max_mbps = ' || mbps); end;
Kdykoli v průběhu kalibrace můžeme zjistit její stav dotazem na pohled V$IO_CALIBRATION_STATUS. Potom co je kalibrace úspěšně dokončena, je možné si zobrazit výsledky z tabulky DBA_RSRC_IO_CALIBRATE.
- 43 -
Ladění databázového systému Oracle
Tomáš Pobuda
3.4.4.2 Konfigurace I/O V této kapitole jsou popsány některá základní nastavení, která bychom neměli opomenout, při konfiguraci I/O. Doporučuje se zachovat konfiguraci tak jednoduchou jak je to jen možné, při zachování dostupnosti, obnovitelnosti a výkonu. Čím více je konfigurace složitá, tím je těžší jí spravovat, udržovat a ladit. Ruční rozmístění I/O Pokud nemáme k dispozici LVM nebo RAID (viz Terminologický slovník) pak musíme I/O mezi dostupné disky rozdělit ručně. Postup rozmístění souborů: 1. Zjistit požadavky na velikost souborů 2. Identifikovat očekávané zatížení I/O pro každý soubor. Určit, které soubory mají nejvyšší míru I/O a které jsou nevytížené. 3. Rozmístit soubory na disky tak aby byla míra I/O u všech soborů přibližně stejná. Kdy rozdělit soubory Pokud systém I/O není schopen zabezpečit míru I/O, která je potřebná, tak bez ohledu na to jestli používáme LVM, RAID či manuální rozmístění souborů, musíme oddělit soubory s vysokou mírou I/O od ostatních. Před tím než rozmístíme soubory, bychom měli ověřit, jestli je omezujícím faktorem opravdu I/O. Jak rozdělit soubory dle typů: •
Tabulky, indexy a TEMP tablespacy Když patří sobory s vysokou mírou I/O tablespacům, které obsahují tabulky a indexy, potom zjišťujeme jestli není možné I/O těchto souborů snížit laděním SQL nebo aplikace. Když patří sobory s vysokou mírou I/O tablespacu TEMP, potom zkoumáme zda nelze ladit SQL příkazy provádějící řazení na discích, aby k takovému řazení nedocházelo. Pokud jsme již vyladily SQL příkazy, aby nedocházelo ke zbytečným I/O, a výkon I/O nepokrývá požadavky, potom zvažujeme oddělení souborů s velkou mírou I/O.
•
Redo log soubory Pokud mají redo log soubory vysokou míru I/O, potom zvažujeme jejich oddělení od ostatních souborů. Možné varianty jsou: o
Umístit všechny redo logy na jeden disk bez ostatních souborů.
o
Umístit každou redo log skupinu na samostatný disk, na kterém nejsou uloženy jiné soubory
o
Data striping redo logů na několik disků (měli bychom se vyhnout umístění redo logů na RAID 5)
Redo log soubory jsou zapisovány sekvenčně procesem Log Writer (LGWR). Tato operace může být provedena rychleji, pokud na disk současně nepřistupuje více procesů. Umístěním redo logů na vyhrazený disk obvykle zajistí hladký chod LGWR a není nutné další ladění. •
Archivní logy
Pokud je proces archiver (ARCH) pomalý, je rozumné zamezit soupeření procesů ARCH a LGWR o I/O. To zajistíme tak, že čtení redo logů archiverem a zápis redo logů LGWR bude oddělené. Představme si, že máme systém s čtyřmi redo log skupinami po dvou členech (1a, 1b, 2a, 2b, 3a, 3b, 4a, 4b). Abychom oddělili diskové operace (čtení, zápis) budeme potřebovat nejméně čtyři disky pro redo logy a jeden pro archivní logy (viz Obr. 12).
- 44 -
Ladění databázového systému Oracle
Tomáš Pobuda
Obr. 12 - Rozdělení Redo logů na discích [ORA-PTG]
V okamžiku kdy LGWR switchne ze skupiny 1 na skupinu 2 může archiver číst skupinu 1 redo logů a zapsat jí do archivního logu. Jak je vidět, procesy nepřistupují současně na jeden disk. Operace čtení a zápisu tak mohou proběhnout rychleji. Velikost datového bloku Velikost bloku 8 KB je optimální pro většinu systémů. Nicméně OLTP systémy občas používají menší velikost datového bloku a DSS systémy zase větší. Popíšeme úvahy, které bychom měli zvážit. Jejich souhrn je uveden v Tab. 22. Čtení Bez ohledu na velikost dat je cílem minimalizovat počet čtení potřebných k získání požadovaných dat. •
Pokud jsou řádky malé a přístup je převážně náhodný, pak vybereme menší velikost bloku.
•
Pokud jsou řádky malé a přístup je převážně sekvenční, potom vybereme větší velikost bloku.
•
Pokud jsou řádky malé a přístup je náhodný i sekvenční, potom by mohla být efektivnější větší velikost bloku.
•
Pokud jsou řádky velké, například záznamy obsahující data velkých objektů (LOB), potom vybereme větší velikost bloku
Zápis Pro všechny systémy zpracovávající velké množství transakcí je 8 KB nejlepším kompromisem a většinou efektivním. Pouze systémy pracující velkými objekty (LOB) potřebují velikost bloku více než 8 KB.
- 45 -
Ladění databázového systému Oracle
Tomáš Pobuda
Tab. 22 – Výhody a nevýhody velikosti bloku
Velikost bloku Menší
Větší
Výhody Dobré pro malé řádky s náhodným přístupem. Redukuje současný přístup k bloku. Má menší režii úložného prostoru. Dovoluje číst jedním I/O velké množství řádků do buffer cache. Dobrá při sekvenčním čtení velmi velkých řádků (jako jsou LOB data)
Nevýhody Má relativně velkou režii úložného prostoru (hlavičky bloků). Nedoporučuje se pro velké řádky. Pokud je náhodně přistupováno k malým řádkům, plýtvá místem v buffer cache. Například s 8 KB blokem a 50 B řádkem, plýtváme 7950 B paměti v buffer cache, pokud je prováděn náhodný přístup. Není dobré pro bloky s indexy v OLTP prostředí, jelikož se zvyšuje konkurenční přístup k blokům.
3.5 Ladění SQL příkazů Ladění SQL příkazů se dá rozdělit na několik kroků. Stejně jako většina ladících postupů je to proces iterativní. Nyní popíšeme kroky nutné k identifikaci, ladění a optimalizaci zatěžujících SQL příkazů. 1. Identifikace zatěžujících SQL příkazů 2. Ladění zatěžujících SQL příkazů 3. Optimalizace přístupu k datům 4. Analýza vlivu ladění jiných změn systému na výkonu SQL příkazů 5. Opakování předchozích kroků dokud nejsou všechny zatěžující SQL příkazy vyladěny
3.5.1 Identifikace zatěžujících SQL příkazů Zatěžující příkazy mohou spotřebovávat velké množství systémových zdrojů. Dokonce i když je databáze dobře vyladěna, mohou neefektivní SQL příkazy výrazně ovlivnit výkon. Identifikovat zatěžující SQL příkazy dvěma způsoby: • s využitím ADDM nálezů Při standardním nastavení je ADDM spouštěno každou hodinu. Analyzuje klíčové statistiky nasbírané AWR za poslední hodinu a identifikuje problémy včetně zatěžujících SQL příkazů. Nálezy ADDM jsou pak zobrazeny na stránce Automatic Database Diagnostic Monitor v Enterprise Manageru. Pro každý nález jsou zde doporučení jak postupovat a jaký to bude mít dopad na výkon. U zatěžujících příkazů bývá doporučení spustit nástroj SQL Tuning Advisor. • s využitím Top SQL ADDM automaticky identifikuje zatěžující SQL příkazy, které působí problémy systému jako celku. V některých případech je nutné monitorovat SQL příkazy podrobněji. Na stránce Top Activity můžeme v tabulce Top SQL sledovat zatěžující dotazy v intervalech 5 minut (viz Obr. 13). Na stránce Top SQL lze také vytvářet takzvané SQL tuning Set, což je databázový objekt, který obsahuje jeden či více SQL příkazů spolu s jejich prováděcími statistikami. SQL tuning Set vytvoříme takto: 1. Na stránce Top Activity vybereme SQL příkazy zaškrtávacími tlačítky. 2. Z rozbalovacího menu nad seznamem Top SQL vybereme Create SQL tuning Set a klikneme na GO.
- 46 -
Ladění databázového systému Oracle
Tomáš Pobuda
3. Zobrazí se stránka, kde můžeme zadat jméno a popis SQL tuning Set a poté klikneme na OK 4. SQL tuning Set je vytvořen. Obr. 13 – Náhled stránky Top Activity [zdroj: ORA-2D]
3.5.2 Ladění zatěžujících SQL příkazů Potom co jsme identifikovaly nejvíce zatěžující dotazy, můžeme přejít k jejich ladění. K tomuto účelu využijeme nástroj SQL Tuning Advisor. Ten je zodpovědný zejména za doporučení jako je vytvoření SQL profilu a přeorganizování SQL příkazu. Nástrojem SQL Tuning Advisor můžeme ladit jeden či více SQL příkazů. Lze ladit manuálně, ale lze nastavit i automatické ladění SQL příkazů. To se spouští během okna údržby systému a snaží se vylepšit exekuční plány zatěžujících SQL příkazů.
3.5.2.1 Manuální použití SQL Tuning Advisor 1. Výběr SQL příkazů Pokud ADDM identifikuje zatěžující SQL příkazy, pak jednoduše klikneme na Schedule/Run SQL Tuning Advisor na stránce detailu doporučení. Další možností je vybrat SQL příkazy ze sekce Top SQL na stránce Top Activity. Zde zaškrtneme SQL příkazy, které chceme ladit a vytvoříme SQL tuning Set. Prvním či druhým způsobem se dostaneme na stránku s nastavením ladící úlohy.
2. Nastavení ladící úlohy Výběr rozsahu ladící úlohy: •
Limited – limitovaný rozsah zabere přibližně 1 sekundu na příkaz, ale nedoporučí SQL profil
•
Comprehensive – při tomto rozsahu trvá úloha déle, ale provede se kompletní analýza a bude doporučen SQL profil. Musíme také nastavit časový limit ladění na jeden příkaz.
•
Total Time Limit – nastavíme celkový časový limit v minutách
Časový plán: Zde nastavíme jestli se má úloha provést hned nebo v zadaný časový okamžik. Úlohu spustíme kliknutím na OK. 3. Zobrazení výsledků Na stránce s výsledky (Advisor Central) můžeme vidět seznam úloh a jejich stav. Pokud je stav COMPLETED, kliknutím na SQL ID se zobrazí stránka s doporučeními SQL Tuning Advisor. Obr. 15 – Stránka s doporučeními [zdroj: ORA-2D]
- 48 -
Ladění databázového systému Oracle
Tomáš Pobuda
4. Implementace doporučení Na stránce s doporučeními pro dané SQL může být více doporučení. Zpravidla vybereme to, které má nejvyšší Benefit(%). Po stisku tlačítka Implement se doporučení provede. V našem případě byl vytvořen SQL profil (viz Obr. 16). Obr. 16 – Stránka s doporučeními – implementované doporučení [zdroj: ORA-2D]
3.5.3 Optimalizace přístupu k objektům SQL Access Advisor je nástroj, kterým zajistíme optimální přístup k datům, která jsou potřebná pro provedení SQL příkazů. Generuje doporučení jak nastavit materializované pohledy a logy pohledů, indexy, SQL profily a partition pro dané zatížení databáze. Není to však zadarmo. Realizace těchto objektů je náročná při update operacích na čas i úložný prostor.
3.5.3.1 Spuštění SQL Access Advisor Tento úkol rozdělit do několika kroků: 1. Výběr počátečních parametrů •
3.5.3.2 Zobrazení doporučení SQL Access Advisor Na stránce Advisor Central je seznam úloh s možností filtrace dle typu úlohy. Mimo jiné jsou zde výsledky úloh SQL Access Advisor. Pro prohlížení vybereme úlohu a stiskneme tlačítko View Result. Dostaneme se na stránku úlohy, která je rozdělena na čtyři záložky: Summary, Recommendations, SQL Statements, Details. Na těchto záložkách jsou údaje o analyzovaných SQL příkazech, doporučení, možné zlepšení výkonu a rekapitulace nastavení.
3.5.4 Analýza vlivu ladění a jiných změn systému na výkonu SQL příkazů K analýze vlivu změn, které jsme udělali prostřednictvím nástrojů SQL Tuning Advisor a SQL Access Advisor, použijeme nástroj SQL Performance Analyzer. Použití SQL Performance Analyzeru v krocích: Zobrazíme si stránku SQL Performance Analyzer (Advisor Central – SQL Performance Analyzer) Vybereme Guided Workflow - to nás provede celým procesem: 1. Vytvoření úlohy SQL Performance Analyzer založené na SQL Tuning Set 2. „Přehrání“ SQL Tuning Set ve výchozím prostředí 3. „Přehrání“ SQL Tuning Set ve změněném prostředí 4. Porovnání kroku 2 a 3 5. Zobrazení výsledků porovnání
4 Ladění databáze systému digitálního archivu SAFE V předchozí kapitole jsme popsali jak nastavovat jednotlivé parametry databáze a také jak používat některé nástroje pro ladění. V této kapitole nejprve popíšeme systém SAFE a implementaci systému, na které provádíme testy a ladíme jeho databázi. Tato implemetace systému SAFE je základ pro většinu standardních implemetací pro firmy. Budeme pro ni zjišťovat, jaké nastavení paměti je pro ni nejvhodnější. To pomůže implementátorům tohoto systému vytipovat oblasti, kterým je vhodné se věnovat. Abychom mohli ladit databázi, musíme vybrat nástroj, který nám bude generovat zátěž systému. Tímto tématem se zabývá kapitola 4.2. Nejprve zmapujeme oblast testovacích nástrojů. Poté si definujeme kritéria výběru nástroje a nakonec jeden nástroj vybereme. Pomocí tohoto nástroje vytvoříme testovací scénáře, které použijeme při ladění databáze. Jakmile vytvoříme testovací scénáře, můžeme přistoupit k ladění databáze. Nejprve nastavíme inicializační parametry databáze, dle doporučení z kapitoly 3.4.1. Následně se budeme věnovat nastavení paměti databáze. Nejdříve ponecháme Automatickou správu paměti, aby rozdělila dostupnou paměť mezi paměťové prostory. Spustíme zátěž systému a zaznamenáme jeho výkon. Poté pomocí statistik popsaných v kapitole 3.4.3 rozhodneme, jaké nastavení paměťových prostorů by mohlo zvýšit výkon databáze. Nastavíme velikost paměťových prostorů ručně a spustíme zátěž a zaznamenáme si výkon. Díky těmto údajům pak porovnáme výkon při různých nastaveních. Jako poslední provedeme kalibraci a konfiguraci I/O. Nejprve spustíme kalibraci a poté rozhodneme, jaké akce by mohli zvýšit výkon databáze. Poslední kapitola se zabývá otázkou rychlosti ukládání souborů digitálního archivu SAFE na souborový systém a do databáze. Pomocí testovacího scénáře, který bude zajišťovat vkládání objektů archivu se sobory (obrázky), zjistíme, jestli je rychlejší ukládat soubory do databáze či na souborový systém. Při obou situacích si zaznamenáme výkon systému SAFE a tyto údaje porovnáme. Výkon systému budeme měřit porovnáváním odezvy pro uživatele. Jak je vidět z Obr. 22, tak je odezva pro uživatele složena z více časů. Jsou to časy internetového prohlížeče (překlad stránky), přenosů po síti (wan, lan), aplikačního serveru (Apache Tomcat,SAFE) a databáze (Oracle). My budeme laděním ovlivňovat pouze DB time (čas databáze). Obr. 22 – Čas odezvy pro uživatele [zdroj: ORA-2D]
4.1 Popis systému SAFE Tato kapitola má za cíl seznámit čtenáře se systémem SAFE a terminologií používanou v souvislosti s tímto systémem. Terminologie pro popis objektů použitá v této kapitole je odlišná od obecně rozšířené terminologie. Základní rozdíly jsou uvedeny v tabulce XWX. Další termín, který by mohl mást čtenáře je termín „definice“. Když implementátor vytváří datový model projektu (vytváří definice), tak vlastně definuje objekty a jejich vlastnosti.
- 54 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Tab. 23 – Rozdíly v terminologii
Obecně rozšířená terminologie objekt vlastnosti (atributy) objektu instance objektu
Terminologie implementátorů SAFE definice či definice objektu vlastnosti definice objekt(y) definice
4.1.1 Charakteristika systému SAFE Úvodem představíme systém SAFE. Zde jsou přehledně po bodech uvedeny jeho charakteristické rysy: •
Zpracování velkého množství dokumentů - Systém je navržen tak, aby byl schopný uložit velké množství dokumentů a uměl nad těmito daty efektivně pracovat - například rychlé vyhledávání a import dat. Systém byl nasazen na desítky miliónů dokumentů, rychlost importu až 120000 dokumentů za hodinu (bez souborů).
•
Objektový přístup - Veškerá data v systému SAFE jsou objekty. To umožňuje jednotný přístup, ať je objekt dokument, uživatele nebo dotaz systému. Například při exportu/importu dat, vyhledávání se pracuje stejně, nezávisle na typu objektu. Pomocí dědičnosti lze objekty rozšiřovat o požadované nové vlastnosti.
•
Verzování dokumentů - Systém automaticky verzuje uložená data. Lze se kdykoliv vrátit k dřívější verzi dokumentu a lze kdykoliv určit kdo a kdy změnil příslušný dokument. Verze jsou chápány jako speciální objekty, takže je možné informace o verzích i vyhledávat.
•
Souběžný přístup k dokumentům - Systém zaručuje, že jeden dokument může v jednom okamžiku editovat pouze jeden uživatel a díky tomu lze zamezit kolizím.
•
Parsování dokumentů - Při vložení souboru do systému se mohou automatiky načíst metadata souboru a uložit do vlastností dokumentu. Parsování lze provádět například nad soubory typu DOC, ODT, XML, PDF. Nad těmito daty lze efektivně vyhledávat.
•
Fulltextové vyhledávání - Systém umožňuje jak objektové, tak i fulltextové vyhledávání. Podle charakteru vložených dat lze předpřipravit nejvhodnější způsob, jak dokumenty vyhledat.
•
Workflow - Systém podporuje oběh dokumentů ve společnosti. Definuje zodpovědnost za úkol, termíny splnění, historii procesu. Procesy lze definovat ve standardním jazyku BPEL, jednodušší procesy lze pouštět v systému i bez přítomnosti BPEL.
•
Přístup přes WebDav - Uživatel nemusí vždy využívat webové rozhraní pro přístup k dokumentům. V případě jednoduchých akcí jako editace, nebo zobrazení dokumentu lze využít přístup přes WebDav. Potom se se soubory pracuje stejně tak, jako kdyby byly uložené na síťovém disku.
•
Více klientských aplikací -Systém je otevřený pro různé klientské aplikace. V současné době je implementováno webové rozhraní a přístup přes WebDav.
•
Rozšiřitelnost systému - Systém lze rozšířit podle specifických požadavků, například definovat validaci dokumentu, počítat generované vlastnosti, definovat vzhled uživatelského webového rozhraní.
•
Komplexní přihlašování do systému - Systém mimo jiné podporuje přihlašování přes Kerberos, data o uživatelích lze načítat přes LDAP. Podpora zastupování uživatelů.
•
Rozhraní pro aplikace třetích stran - Systém umí komunikovat s jinými aplikacemi pomocí standardních rozhraní CORBA a WebService. Dokumentované rozhraní umožňuje případnou návaznost jiných softwarových řešení v budoucnu a tím se životnost systému zvyšuje.
- 55 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
•
Nezávislost na operačním systému - Systém lze provozovat na všech moderních operačních systémech (kde běží JVM). Případná migrace na jiný operační systém není problém.
•
Podpora více datových úložišť - Pro uložení souborových dat lze využít databázi, souborový systém, nebo pásku. Jednotlivé typy uložení lze kombinovat a současně využívat výhod zmíněných zařízení.
•
Podpora více databází - Systém umí spolupracovat s databází Oracle, MS SQL a (MySQL).
•
Třívrstvá architektura - Moderní třívrstvá architektura (Databáze - Aplikační server - WWW server) zajišťuje bezpečnost řešení a umožňuje škálovat požadavky na server.
4.1.2 Architektura Systém SAFE využívá třívrstvou architekturu klient-server. • Datová vrstva - souborové úložiště a relační databáze. Tato vrstva dlouhodobě ukládá data uložená v systému. Datová vrstva je přístupná jen pro model. • Model – server systému Safe III. Poskytuje aplikační rozhraní pro přístup k datům a pro manipulaci s nimi. Nad nízkoúrovňovými daty (soubory, databázovými tabulkami) vytváří vyšší abstrakce v podobě aplikačního rozhraní. S daty nelze pracovat jinak než skrze toto rozhraní. • Prezentační vrstva - webový server, případně klientská aplikace. Nad aplikačním rozhraní staví grafické uživatelské rozhraní. Obr. 23 – Architektura SAFE
Datová vrstva a model neumožňují žádné alternativy k předchozímu obrázku. Na druhé straně prezentační vrstva je volitelná – klient může pracovat přímo s aplikačním rozhraním modelu. Toho se využije zejména pro realizaci neinteraktivních aplikací jako export a import, nebo pro integraci s jinými systémy. Interaktivní klient ovšem také není omezen pouze na prohlížení webových stránek pomocí webového prohlížeče. Klientská aplikace může komunikovat přímo s modelem a data prezentovat vlastním způsobem, např. pomocí místního grafického prostředí nebo na terminálové konzoli (v případě řádkových klientů). Ať už klient přistupuje k modelu přímo, nebo pomocí nezávislé prezentační vrstvy, jeho požadavky vždy nakonec používají jednotné aplikační rozhraní modelu. Toto rozhraní je specifikováno v jazyce IDL (OMG Interface Definition Language) a používá se skrze middleware CORBA - tedy z různých platforem i programovacích jazyků. Pro ty, kteří před CORBOU preferují jiné technologie, existuje možnost předřadit před model komponentu, která bude navenek komunikovat preferovaným protokolem. Distribuce SAFE standardně obsahuje popis části rozhraní i v jazyce WSDL (Web Service Definition Language) a modul pro webový server, který navenek komunikuje dle standardu Web-Services. Tento způsob se používá mimo jiné pro komunikaci s workflow strojem, tj. systémem, který řídí běh workflow procesů.
- 56 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Obr. 24 – Různé přístupy k SAFE
4.1.3 Datový model
4.1.3.1 Statická část datového modelu Statickou část datového modelu tvoří tabulky, ve kterých mají uložená data jednotlivé služby (např. Správce definic). O tyto tabulky se stará příslušná služba, tedy o vytvoření a případné změny. Popis statických tabulek: •
DynamicFS (služba DynamicFS) – jsou zde uloženy adresy souboru dynamického souborového systému.
•
EventList (služba EventLog) – je zde uložen seznam událostí, které mohou být v systému sledovány, a jejich parametry.
•
IndexDef (služba ObjectDefManager) – jsou zde uloženy definice indexů na vlastnostech objektů v systému.
•
ObjectDef (služba ObjectDefManager) – jsou zde uloženy definice objektů v systému.
•
ObjectRight (služba RightsStorage) – jsou zde uloženy práva účastníků na objekty v systému s příslušnou maskou práv.
•
PropertyDef (služba ObjectDefManager) – jsou zde uloženy definice vlastností objektů v systému
•
Sequences (služba Sequences) – jsou zde uloženy sekvence v systému, tzn. jméno sekvence a její aktuální hodnota.
•
ServiceList (správce služeb) – jsou zde uloženy nainstalované služby systému a jejich aktuální verze.
•
Storage (služba DBStorage) – tato tabulka je databázové datové úložiště.
- 57 -
Ladění databáze systému digitálního archivu SAFE
•
Tomáš Pobuda
UserLogin (služba LoginService) – v této tabulce jsou uloženy informace o přihlášení uživatelů.
4.1.3.2 Dynamická část datového modelu Dynamická část datového modelu je tvořena tabulkami objektů vytvořených podle definic v systému. Každá definice má hlavní tabulku, kde jsou uloženy všechny hodnoty jednoduchých vlastností objektů dané definice, a pak pro každou vícenásobnou vlastnost je vytvořena extra tabulka, kam se ukládají hodnoty této vícenásobné vlastnosti. Hlavní tabulka nemusí existovat, pokud definice nemá žádné jednoduché vlastnosti. Vzhledem k tomu že definice jsou hierarchicky uspořádané i jejich tabulky mají hierarchii. Do hlavní tabulky definice se ukládají jen hodnoty vlastností definované v této definici, zděděné vlastnosti z nadřazených definic se ukládají do tabulek příslušných definic. Tabulky vždy obsahují sloupec C_ID, což je identifikátor objektu, přes který jsou svázány do stromové hierarchie, přesně jako příslušné definice, vazba je realizována referenční integritou (cizí klíč). Jména tabulek vždy začínají prefixem t_ pak je připojeno jméno definice a u tabulek vícenásobných vlastností ještě podtržítko a jméno vícenásobné vlastnosti. Jména sloupců hlavní tabulky se shodují se jmény jednoduchých vlastností příslušné definice s připojeným prefixem c_. Obr. 25 – stromeček definic v systému SAFE
1. Menu pro tvorbu nových definic a úpravu stávajících. 2. Strom s jednotlivým definicemi. 3. Informace o označené definici – název, vlastnosti a zděděné vlastnosti. Tyto informace si zobrazíte kliknutím na některou z definicí ve stromu. 4. Název definice s konfiguračními atributy. 5. Vlastnosti definice. 6. Vlastnosti, které definice dědí od definice nadřazené. Dynamické je i vytváření indexů nad sloupci tabulek, takto vytvořené indexy mají jméno složené z prefixu IX_ a výsledku nějaké hašovací funkce (MD5), aplikované na parametry indexu.
- 58 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
4.1.4 Definice objektů Na systém SAFE se lze dívat jako na množinu trvalých objektů. Každý objekt je určitého typu. Typ objektu určuje, jaké má objekt vlastnosti, jak se zobrazí na obrazovce, či jak je možné jej vyhledat. Typy objektů nejsou předem dány, je možné zakládat nové, nebo měnit a rušit již existující typy. Při vytváření nového typu je třeba tento typ popsat. Tomuto popisu říkáme definice typu objektu nebo také definice objektu. Typy objektu tvoří hierarchii. Existuje jeden kořenový typ objekt. Ten má své potomky (dokument,účastník, úkol) a ty mohou mít další potomky. Například typ dokument může mít potomky soubor,svazek, rozhodnutí. Hlavním úkolem definice je stanovit seznam vlastností objektu. Seznam vlastností se dědí. To znamená, že dceřiná definice definuje kromě svých vlastností také stejné vlastnosti jako definice rodičovská. Každá vlastnost je nějak popsána. Tomuto popisu říkáme definice vlastnosti.
4.1.4.1 Struktura definice objektu Jméno - Jednoznačná identifikace definice. Smí obsahovat pouze ASCII písmena a číslice. První znak musí být písmeno. Identifikace se používá například ve vyhledávacích dotazech nebo ve jménech specializovaných JSP stránek. Titulek - Jednořádkový název definice objektu. Popis - Textový popis definice objektu. Smí obsahovat libovolný text a konce řádků. Vlastnosti - Seznam definic vlastností. Zobrazovaná položka - Často je třeba uživateli zobrazit objekt ve zkrácené podobě, bez všech vlastností, jen jako ikonu v nějaké stránce. Proto je možné vybrat jednu z vlastností a její text se pak v těchto případech používá. Atributy - Atributy umožňují provádět různá nastavení vztahující se k typu objektu. Zapisují se ve formě jméno_atributu=hodnota na samostatné řádky. Pomocí těchto nastavení lze například určit, že každý vkládaný soubor se má parsovat, nebo zda se pro tento typ dokumentu provádí fulltextová indexace.
- 59 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Obr. 26 – Editace definice
4.1.4.2 Struktura definice vlastnosti Jméno - Jméno jednoznačně identifikuje vlastnost uvnitř definice. Různé definice mohou obsahovat vlastnost se stejným jménem, nesmí však být jedna potomkem druhé. Smí obsahovat pouze ASCII písmena a číslice. První znak musí být písmeno. Identifikace se používá například ve vyhledávacích dotazech, ve jménech tagů v importovaných souborech, či uvnitř specializovaných JSP stránek. Titulek - Jednořádkový název definice vlastnosti. Popis - Textový popis definice vlastnosti. Smí obsahovat libovolný text a konce řádků. Typ - Určuje jaké hodnoty smí vlastnost obsahovat. string ASCII znaky. wstring Libovolné znaky. long_long 8B celé číslo. Rozsah je -2^63 až 2^63-1, neboli -9,223,372,036,854,775,808 až 9,223,372,036,854,775,807 long 4B celé číslo. Rozsah je -2^31 až 2^31-1, neboli -2,147,483,648 až 2,147,483,647 short 2B celé číslo. Rozsah je -2^15 až 2^15-1, neboli -32,768 až 32,767 double 8B desetinné číslo s plovoucí čárkou (standard IEEE 754 double precision). utct Datum a čas. object_XXX Odkaz na objekt typu XXX. Kardinalita - Určuje násobnost vlastnosti. optional Vlastnost se v objektu může vyskytovat nejvýše jednou. obligatory Vlastnost se v objektu může vyskytovat právě jednou. list Vlastnost se může v objektu vyskytovat vícekrát. Hodnoty vlastnosti se mohou opakovat, pořadí jednotlivých hodnot stanovuje uživatel. set Vlastnost se může v objektu vyskytovat vícekrát. Hodnoty vlastnosti se nemohou opakovat, pořadí jednotlivých hodnot určuje systém (např. podle abecedy).
- 60 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Fragment - Má význam jen u typů object_XXX. Je-li nastaven, znamená, že odkazované objekty jsou součástí odkazujícího se objektu. Například se pak řídí jeho právy nebo se odstraňují společně s ním. Jen čtení - Hodnotu takovéto vlastnosti uživatel nemůže měnit, může ji ale nastavit při vytváření objektu. Generované - Hodnotu generované vlastnosti uživatel nezadává při vytváření objektu, může ji ale následně měnit. Pro vlastnosti spravované systémem se proto používá nastavení Generovaná a Jen ke čtení. Odvozené - Většina vlastností se ukládá přesně definovaným způsobem do databáze. To umožňuje podle nich objekt nalézt a zkonstruovat. Některé vlastnosti ale systém buď počítá z jiných, nebo je ukládá jiným způsobem. Tyto vlastnosti mají příznak Odvozené, lze je zobrazovat, mohou jít i editovat, nelze však podle nich vyhledávat. Vytvoření odvozené vlastnosti musí vždy doprovázet její naprogramování. Velikost - Má význam pouze u typů string a wstring. U těchto typů je důležité stanovit maximální počet znaků. Podle velikosti se volí například způsob uložení vlastnosti a tím i rychlost vyhledávání. Velikost lze nastavit i na 0, pak je neomezená. (Je omezená délkou memo sloupce v použitém databázovém serveru.) Počet desetinných míst - Má význam pouze u typů short, long a long_long. Vlastnosti těchto typů pak mohou obsahovat desetinná čísla s přesně daným počtem desetinných míst. Lze použít například pro vyjádření měny. Atributy - Atributy vlastnosti umožňují provádět různá nastavení vztahující se k typu vlastnosti. Zapisují se ve formě name=value na samostatné řádky. Pomocí těchto nastavení lze například určit, jak se bude příslušná vlastnost zobrazovat uživateli, nebo jak se bude validovat. Atributy vlastnosti lze psát rovněž do atributů definice. V tom případě mají vždy tvar property.XXX.jméno_atributu=hodnota, kde XXX je jméno vlastnosti.
- 61 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Obr. 27 – Editace vlastnosti definice
4.1.4.3 Struktura definice indexu Seznam indexovaných sloupců - Uvádí se výčet sloupců, které mají být zahrnuty do indexu. Vícenásobné vlastnosti lze indexovat pouze samostatně. Nastavení indexu na fulltextový se provádí dodatečným parametrem a takový index, lze vytvořit jen nad jednou vlastnosti, v případě databázového serveru Microsoft navíc tato vlastnost nesmí být vícenásobná. Seznam dodatečných parametrů - Každý parametr je dvojice klíč=hodnota a musí být na samostatném řádku. Podporované dodatečné parametry: • fulltext – akceptovatelné hodnoty jsou „y“ a „n“, výchozí je „n“. Zapnutý - Příznak, je-li index zapnutý nebo vypnutý, tzn. existuje jeho definice v systému, ale index fyzicky vytvořen není.
4.1.4.4 Manipulace s definicemi Definice lze vytvářet, měnit nebo odstraňovat pomocí webového rozhraní nebo pomocí xml souboru. Operace může provádět pouze člen role DefinitionManagers. Odstranit lze jen takovou definici, která nemá potomky, na kterou neukazuje vlastnost typu object_ a podle níž neexistují v systému žádné objekty. Definici podle níž neexistují v systému žádné objekty lze měnit libovolně. U ostatních definic, jsou omezeny změny v seznamu vlastností. Nelze například změnit vlastnost typu řetězec na vlastnost typu číslo. Administrace definic se provádí také pomocí XML souboru. Ten musí být napsán podle definovaného XML schématu. Pro databázi Oracle dochází, při (re)instalaci definic dochází k přepočítávání statistik, které ovlivňují spouštění SQL příkazů do databáze. Přepočítávání se provádí pro každou definici po
- 62 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
vytvoření všech tabulek a indexů, pro definice bez indexů se přepočítávání neprovádí. Lze také spočítat statistiky i pro celé schéma. K tomuto účelu se používá balíček DBMS_STATS
4.1.4.5 Společné vlastnosti všech objektů Všechny definice jsou potomky definice Object. Ta má následující vlastnosti: •
id Jednoznačná identifikace objektu.
•
objectDefName Typ (jméno definice) objektu.
•
createUser Kdo objekt vytvořil.
•
createDT Kdy byl objekt vytvořen.
•
modifyUser Kdo objekt naposledy změnil.
•
modifyDT Kdy byl objekt naposledy změněn.
•
parent Je-li objekt fragmentem jiného objektu, ukazuje na něj vlastnost parent.
•
owner Ukazuje na nejvrchnějšího podle vlastnosti parent, nebo na sebe.
•
ownerDefName Typ objektu, na který ukazuje owner.
Objekty samy o sobě nedefinují žádná práva, to dělají až jejich potomci.
4.1.5 Vyhledávání Vyhledávat lze v systému SAFE v zásadě dvěma způsoby. Buďto hledáme objekty, to znamená, že hledáme v datech uložených v databázových tabulkách. Nebo hledáme fulltextově, což znamená, že hledáme v souborech (pdf, doc, txt, odt) uložených v archivu.
4.1.5.1 Objektové vyhledávání Pro tento způsob vyhledávání je nutná znalost uspořádání objektů systému SAFE a jejich vlastností. Syntaxe dotazu je podobná syntaxi dotazu jazyka SQL. Vyhledávací služba kontroluje nejen syntaxi dotazu, ale i existenci a datové typy vlastností použitých v podmínce pro vyhledávání. Do podmínky lze napsat jakoukoliv vlastnost z definice objektu a také všech jejích předků až k objektu Object. Dále se kontroluje vstupní formát data, desetinných čísel a použitelnost datových typů s konkrétním operátorem v podmínce. Syntaxe dotazu se skládá ze jména definice objektu, seznamu podmínek na hodnoty vlastností a seznamu zobrazených sloupců ve výsledku. Podmínky lze spojovat logickými operátory AND a OR, případně lze použít i operátor negace NOT. Podmínky lze libovolně závorkovat a je akceptována i prázdná podmínka (závorky ale musí zůstat). Do seznamu sloupců pro zobrazení ve výsledku se píší jména vlastností, oddělená čárkou. Navíc zde lze určit směr třídění výsledku a to zapsáním klíčových slov DESC nebo ASC a čísla, jako pořadí třídění, za jméno vlastnosti. Nelze třídit podle vícenásobných vlastností. Seznam vlastností smí obsahovat i vlastnosti z rodičovských definic objektů k definici jejíž objekty chceme vyhledávat. Obecný zápis dotazu: [<seznam_dodatečných_tributů>]<jméno_definice_objektu>(<seznam_podmínek>)[<seznam_slou pců_výsledku>]
4.1.5.2 Fulltextové vyhledávání Fulltextové vyhledávání je v systému SAFE realizováno pomocí externího vyhledávacího stroje Lucene. V současné době je možné indexovat libovolný dokument (resp. jeho vlastnosti, přílohy) uložený v systému SAFE. Podporované formáty souborů, které lze indexovat jsou PDF (pouze neuzamčené dokumenty), DOC, TXT, XML, a soubory OpenOffice resp. podle MIME typů
- 63 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
application/pdf, application/msword, text/plain, application/x-extension-txt, text/xml, application/vnd.oasis.opendocument.text. Indexace je nezávislá na velikosti písmen.Fulltextová služba pracuje tak, že asynchronně poslouchá události o změnách dokumentů. Při indexaci dokumentu se ve vyhledávacím stroji vytvoří „dokument“, který má vlastnosti, podle kterých lze později vyhledávat. Vlastnosti dokumentu se dělí na: •
indexované vlastnosti
•
indexované a uložené vlastnosti
Indexované a uložené vlastnosti jsou ty vlastnosti, podle kterých lze vyhledávat a jejichž obsah lze zobrazit (například v tabulce výsledků vyhledávání). Podle „indexovaných vlastností“ lze vyhledávat, ale jejich obsah již nelze zobrazit. Při indexaci perzistentního objektu se automaticky ukládá jeho identifikační číslo (v rámci systému jedinečné), jeho typ (jméno definice, podle které byl objekt vytvořen) a tzv. „Zobrazovaná položka“ (tj. vlastnost určená v definici, která popisuje objekt).
4.1.6 Popis testovacího systému SAFE Systém SAFE lze přizpůsobit každému zákazníkovi na míru. V tomto ohledu je velice flexibilní. Pro testy a ladění databáze jsem vybral implementaci systému SAFE, která je určena jako balík modulů pro typického zákazníka (adresář, smlouvy, faktury, pošta). My budeme z této implementace využívat agendu faktur. Pro jasné označení této implementace budeme používat název SAFE XY. Nyní popíšeme uživatelské prostředí této implementace, tedy SAFE XY. To proto, aby si čtenář dokázal představit jak se se systémem pracuje a lépe tak pochopil testovací scénáře popsané dále. Uživatelské prostředí můžeme rozdělit na tyto komponenty (viz Obr. 28): Obr. 28 – Komponenty uživatelského prostředí
Vyhledávací dotaz Záložka Složkový dotaz
Zakládací link
•
záložky – mění zobrazení složek a vyhledávacích dotazů, které se zobrazují uživateli. Pro naše účely budeme využívat pouze záložky Moje Faktury a Faktury (viz Obr. 28).
•
složkové dotazy (složky) – zobrazují dokumenty splňující příslušná kritéria, jejich počet a umožňují přístup k těmto dokumentům (viz Tab. 24). - 64 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Tab. 24 – Složkové dotazy na záložce Moje Faktury
Složkový dotaz
Popis a podmínka pro zobrazení faktury ve složce
Moje faktury NOVÉ
Faktury byly právě založeny a není u nich ještě vybrán žádný schvalovatel.
Moje faktury K ZAÚČTOVÁNÍ
Všechny faktury, které již byly schváleny, tj. faktury jsou ve stavu schválená. Nejsou zaúčtovány.
Moje faktury K PROPLACENÍ
Všechny faktury, které již byly schváleny, tj. faktury jsou ve stavu schválená. Nejsou proplaceny.
•
vyhledávací dotazy – umožňují zadat parametry dotazu a vyhledat tak požadovanou fakturu (viz Obr. 28). My budeme používat pouze dotaz Faktury přijaté (viz Obr. 29). Ten vyhledává nad všemi fakturami dle příslušných parametrů, které může uživatel zadat.
Obr. 29 – Vyhledávací dotaz Faktury přijaté
•
zobrazení faktury – umožňuje zobrazit vlastnosti faktury (čárový kód, částka, dodavatel) a přepnout se na stránku Průvodka.
Obr. 30 – Zobrazení faktury
- 65 -
Ladění databáze systému digitálního archivu SAFE
•
Tomáš Pobuda
podpisy – umožňují zpracování faktur, jsou analogií k razítkům, která by mohla být použita na fakturu v papírové formě. (např. schvaluji, neschvaluji, atd.). Na stránce Průvodka lze tyto podpisy vytvořit a sledovat jejich historii (viz Obr. 31). Popis podpisů viz Tab. 25.
Tab. 25 – Popis podpisů na stránce Průvodka
Podpis
Popis
Předat správu faktury
Na faktuře se tímto podpisem vybere nový účetní.
Potvrdit schválení
Účetní potvrzuje schválení faktury. Stav faktury se mění na schválená, a uzamkne se.
Zaúčtováno
Faktura byla již „fyzicky“ zaúčtována, tento podpis stvrzuje tuto provedenou akci. Hodnota vlastnosti zaúčtováno na faktuře se mění na 1.
Proplaceno
Faktura byla již „fyzicky“ proplacena, tento podpis stvrzuje tuto provedenou akci. Hodnota vlastnosti proplaceno na faktuře se mění na 1.
Obr. 31 – Podpisy na stránce Průvodka
•
zakládací linky – umožňují uživateli vytvářet faktury (viz Obr. 32).
Obr. 32 - Vytváření faktury
4.2 Testovací nástroje Tato kapitola má za cíl vybrat a popsat vhodný testovací nástroj pro aplikaci SAFE. Abychom mohli testovat databázový systém aplikace SAFE, potřebujeme generovat zátěž samotné aplikace SAFE. Jedna z možností je použití testovacího nástroje, který umí po naprogramování simulovat práci uživatelů. Jak bylo popsáno výše, uživatelé pracují s aplikací SAFE pomocí webových stránek (HTML dokumenty). Komunikace mezi WWW Serverem a uživatelem probíhá podle protokolu HTTP(Hypertext Transfer Protocol) (viz Obr. 33). Uživatel pošle serveru dotaz a server vygeneruje odpověď a pošle ji uživateli zpět. Díky znalosti HTTP protokolu a HTML formátu lze snadno simulovat uživatelské akce a kontrolovat odpovědi WWW serveru.
- 66 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Obr. 33 – HTTP protokol [HAVLIN]
Nástrojů, které umožňují takto generovat zátěž je celá řada. Ne všechny však zdarma k použití. Vybereme z nich pouze jeden, který bude nejvíce odpovídat našim potřebám. Nástroje, které byly vybrány z širšího výběru jsou: • Selenium – lze s ním rychle vytvářet testy v prohlížeči Mozilla Firefox. Vytvoření testu je opravdu velice rychlé a snadné. Stačí zaznamenat „klikáním“ chování uživatele. Takový test je pak možné spouštět. • Apache JMeter – nelze s ním vytvářet testy tak jednoduše jako se Seleniem, ale tento nástroj poskytuje daleko více možností simulace práce uživatele. Je vhodný pro zátěžové testy serverů, jelikož dokáže simulovat velké množství uživatelů. Pro výběr testovacího nástroje jsem zvolil tato kritéria a jejich váhy: •
kontrola příchozí odpovědi – váha 0,2
•
komfort tvorby testu – váha 0,2
•
možnosti nastavení testu – váha 0,3
•
zobrazení výsledků – váha 0,2
•
uživatelské prostředí – váha 0,1
Hodnocení dle těchto kritérií bylo provedeno subjektivně na stupnici 1-5 (1 nejhorší, 5 nejlepší). Analýza testovacích nástrojů není předmětem této práce a tak pouze uvedeme tabulku s hodnotami kritérií a výpočet pro výběr varianty(viz Tab. 26). Tab. 26 – Hodnocení testovacích nástrojů
Selenium Apache JMeter kontrola příchozí odpovědi 3 4 komfort tvorby testu 5 3 možnosti nastavení testu 3 5 zobrazení výsledků 2 5 uživatelské prostředí 4 4 Rozhodnutí o výběru testovacího nástroje provedeme metodou WSA (Weighted Sum Average metoda váženého součtu). Výpočet provedeme v tabulce (viz Tab. 27).
- 67 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Tab. 27 – Výběr testovacího nástroje metodou WSA
Selenium Apache JMeter váhy kontrola příchozí odpovědi 3 4 0,1 komfort tvorby testu 5 3 0,2 možnosti nastavení testu 3 5 0,4 zobrazení výsledků 2 5 0,2 uživatelské prostředí 4 4 0,1 WSA 3,3 4,4 Jak je vidět z výsledků v tabulce Selenium má vážený součet roven 3,3 a Apache JMeter 4,4. To znamená, že dle hodnocení a výběru metodou WSA, je vhodnějším nástrojem Apache JMeter. Proto si ho zvolíme jako testovací nástroj.
4.2.1 Testovací nástroj Apache JMeter Aplikace JMeter byla původně navržena pro testování webových rozhraní. Je však použitelná i pro testování jiných částí Java aplikací. My budeme využívat jeho schopnosti při testování webových rozhraní. Tento nástroj bude vytvářet zátěž na našem systému SAFE a my budeme sledovat jeho výkon. Konkrétně výkon databáze. JMeter dokáže vytvářet GET i POST HTTP dotazy, nahrání souboru na server, FTP dotazy, volání webových služeb, spouštění databázových příkazů, LDAP dotazy a mnoho dalších. My budeme využívat pouze HTTP dotazy.
4.2.1.1 Tvorba testovacích scénářů Test v JMeter se zadává ve formě stromu (viz Obr. 34) a nazývá se TestPlan. Tento strom může obsahovat různé elementy, které určují běh testu. Nyní si popíšeme ty, které budou použity v testech pro systém SAFE. TestPlan Je to kořenový uzel. Lze zde nastavit, aby se každá skupina vláken (Thread Group) spouštěla sériově nebo paralelně. Dalším nastavením je zaškrtávácí tlačítko Functional Test Mode. Při zapnutém se uchovává vše co přišlo od serveru. Velice však roste soubor, do kterého se data ukládají a není vhodné pro zátěžové testy. Dají se zde také definovat proměnné, které pak můžeme následně používat v ostatních elementech. Například jmenuje-li se proměnná port, pak se na ní odkazujeme zápisem ${port}. Thread Group Výchozí bod testovacího plánu. Všechny ostatní elementy musí být umístěny jako potomci nějakého elementu Thread Group. Tímto elementem se řídí spouštění testovacích vláken. Umožňuje nastavit (viz Obr. 34): •
Name – Jméno skupiny vláken
•
Comments – Komentář
•
Action to be taken after a Sampler error - Akce při chybě
•
Number of threads - Počet vláken
•
Ramp-Up Period – za jak dlouho se vytvoří všechna vlákna
•
Loop Count – počet opakování
•
Forever – při zaškrtnutí se test opakuje do nekonečna
- 68 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Obr. 34 – Rozhraní pro nastavení elementu Thread Group
Vzorkovače (Samplers) Slouží k odesílání požadavků na server a ke sledování rychlosti odezvy. Ke vzorkovačům mohou být přidruženy konfigurační elementy pro jednodušší správu. Získané vzorky jsou zpracovávány posluchači (Listeners). JMeter má k dispozici více druhů vzorkovačů (HTTP Request, FTP Request, JDBC Request, Java Request, LDAP Request, SOAP/XML-RPC Request, Web Service (SOAP) Request, atd.). Pro naše testy bude využíván vzorkovač: HTTP Request Slouží ke konfiguraci HTTP požadavků, které budou posílány na server. Následuje popis nastavení (viz Obr. 35): •
Name – Jméno požadavku
•
Commnents – Komentář
•
Server Name or IP – název nebo IP adresa serveru
•
Port Number – Číslo portu (Standardně: 80)
•
Protocol – použitý protokol (HTTP, HTTPS, FILE. Standardně: HTTP)
•
Method – metoda HTTP požadavku (GET simuluje „klasické“ klikání uživatele, POST obvykle odpovídá odeslání formuláře na zadanou stránku)
•
Content encoding – používané kódování
•
Path – cesta ke zdroji na serveru
•
Redirect Automatically – výchozí http ovladač autamoticky sleduje přesměrování, tzn. že není zaznamenáváno JMeterem.
•
Follow Redirects – následovat přesměrování
•
Use KeepAlive – posílá v hlavičce HTTP příznak Connection: keep-alive.
- 69 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
•
Send Parameters With the Request - lze posílat spolu s http požadavkem (např. hodnoty HTML formuláře či argumenty skriptu)
•
Filename – jméno souboru (např. a\b\c\file.txt)
•
Value for “name” attribute – hodnota “name” webového požadavku (file.txt)
•
MIME Type – např. text/plain
•
Retrieve All Embedded Resources from HTML Files – JMeter parsuje HTML soubor a posílá HTTP/HTTPS požadavky na odkazované obrázky, Java applety, JavaScript soubory, CSS soubory, atd.
•
Use as Monitor – pro použití s Monitor Result posluchačem.
•
Embedded URLs must match – regulární výraz, kterému musí odpovídat URL adresy.
Obr. 35 – Rozhraní pro nastavení elementu HTTP Request
- 70 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Posluchače (Listeners) Slouží k zachycení a prezentaci výsledků měření. Mohou být umístěny kdekoli ve stromu. Ale budou zachytávat pouze údaje ze vzorkovačů na nebo pod jejich úrovní. Další schopností posluchačů je ukládání naměřených hodnot do souboru. Standardně se ukládají do XML souborů s příponou .jtl. Jiný možný formát uložení dat je CSV (Comma Separated Values – hodnoty oddělené čárkou). Posluchačů je velké množství, popíšeme tedy pouze ty, které v testech používáme. View Results Tree Zobrazuje strom všech odpovědí serveru. Dokáže zobrazit jak požadavek generovaný vzorkovačem, tak i složit HTML stránku z odpovědi serveru nebo ji zobrazit textově (viz Obr. 36). My ho používáme zejména k ladění testu. Při spouštění testu ho vyřazujeme ze stromu (ušetříme tak zdroje počítače). Obr. 36 - Zobrazení view resutls tree
Aggregate Report Zobrazuje tabulku kde v řádcích jsou hodnoty pro každý pojmenovaný vzorkovač (viz Obr. 37). Zobrazuje sloupce: •
Label – Název vzorkovače.
•
# Samples – Počet generovaných požadavků.
•
Average – Průměrná odezva.
•
Median – Medián odezvy.
•
90% Line – Maximální odezva pro 90 % nejrychlejších požadavků.
•
Min – Minimální odezva požadavku.
•
Max - Maximální odezva požadavku.
•
Error % - Procento chyb.
- 71 -
Ladění databáze systému digitálního archivu SAFE
•
Throughput – Propustnost v počtu za sekundu/minutu/hodinu
•
Kb/sec – Propustnost v KB za sekundu
Tomáš Pobuda
Obr. 37 - Zobrazení aggregate report
Konfigurační elementy (Configuration elements) Jsou těsně spjaty se vzorkovači. Lze jimi nastavovat jejich společné vlastnosti. Například pokud v testu používáme 20 HTTP Request vzorkovačů, pak je výhodné nastavit na jednom místě “Server Name or IP” parametr. Konfigurační element ovlivňuje vzorkovače na stejné nebo nižší úrovni. Přičemž vyšší prioritu mají elementy, které jsou v hierarchii blíže k vzorkovači. Pro naše účely budeme používat konfigurační elementy: HTTP Cookie Manager Tento element má dvě funkce. Jednak ukládá cookies jako to dělá prohlížeč. To znamená, že pokud odpověď na HTTP požadavek obsahuje cookie, pak jí HTTP Cookie Manager automaticky uloží a použije ji pro další požadavky. Za druhé můžeme ručně přidat cookie do Cookie Mangeru. My ho používáme v režimu compatibility (viz Obr. 38). Obr. 38 - HTTP Cookie Manager
- 72 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Logické kontroléry (Logical controllers) Logickými kontroléry lze upravovat logiku, kterou JMeter používá při posílání požadavků. Lze jimi nastavit pořadí, opakování i upravovat požadavky, které jsou jejich potomky. Logické kontroléry mohou mít za potomky: vzorkovače, konfigurační elementy a jiné logické kontroléry. Simple controller Slouží především pro organizování vzorkovačů a jiných logických kontrolérů. Sám o sobě žádnou funkcionalitu nemá (viz Obr. 39). Obr. 39 - Simple controller
Loop controller Tento kontrolér opakuje požadavky, které jsou jeho potomky. Lze nastavit počet opakování nebo opakování do nekonečna (Forever) (viz Obr. 40). Obr. 40 - Loop controller
Interleave controller Při každém průchodu stromem vybere jednoho svého potomka a toho vykoná. Takto postupně vybírá všechny potomky (při dalších průchodech). Pokud má za potomky jiné kontrolery, pak je možné nastavit žaškrtávacím políčkem, aby z nich vždy vykonal pouze jeden požadavek (viz Obr. 41). Obr. 41 - Interleave controller
Časovače (Timers) Při výchozím nastavení posílá JMeter požadavky bez jakékoli prodlevy. To neodpovídá chování uživatele a s velkou pravděpodobností může test bez časovačů zaplavit server požadavky a tak ho ochromit. Doporučuje se tedy časovače nastavit. Gaussian Random Timer Slouží ke generování náhodných prodlev mezi požadavky. Stanovíme si odchylku (Deviation) a pevný čas (Constant Delay Offset) (viz Obr. 42).
- 73 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Obr. 42 - Gaussian Random Timer
Post-procesory (Post-Processors) Jsou to elementy, které provedou nějakou akci, potom co je potom co je proveden požadavek vzorkovače. Pokud je post-procesor potomkem vzorkovače, pak se vykoná okamžitě po provedení požadavku. Nejčastěji jsou post-procesory využívány ke zpracování odpovědi serveru (např. získání hodnot z html stránky). Regular Expression Extractor Umožňuje získávat hodnoty z odpovědí serveru použitím regulárních výrazů. Získanou hodnotu pak uloží do proměnné. Použití si vysvětlíme na příkladu. Představme si, že nám sever vrátí stránku kde je vysledek vyhledávání v řádcích. Na konci každého řádku je zaškrtávací políčko (checkbox). Jeho zápis v HTML je: My chceme získat hodnotu id dokumentu, která je v atributu value. Hodnotu value nahradíme regulárním výrazem ([0-9]+) („[0-9]“ - všechna čísla; „+“ - shoduje se jednou a více). Tak najdeme všechna čísla v hodnotách atrubutu value elementu HTML input (viz ). Nastavit lze tyto parametry: • Name – Jméno elementu. • Response Field to check – Jaká část odpovědi serveru se má zpracovat. • Reference Name – Jméno proměnné kam se uloží výsledek. • Regular Expression – Výraz podle kterého se zpracuje odpověď serveru. • Template - $1$ znamená, že se vybere hodnota rebulárního výrazu v závorkách „()“ • Match No. – Jaká hodnota, získaná zpracováním odpovědi serveru se má uložit do proměnné. „0“ znamená náhodný výběr. • Default Value – Pokud je výsledek zpracování odpovědi serveru prázdný. Pak se použije tato hodnota. Obr. 43 - Regular Expression Extractor
- 74 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Funkce Funkce v JMeteru jsou zvláštní hodnoty, které mohou být v polích každého vzorkovače nebo jiného elementu ve stromu. Obecný zápis funkce vypadá takto: ${__JménoFunkce(proměná1,proměná2,proměná3)} Random Tato funkce vrací náhodné číslo z rozsahu, který si definujeme a ukládá ho do proměnné, jejíž jméno si též určíme. Příkladem může být zápis ${__Random(10000000,19999999,ra_ean)}. Tato funkce bude vracet čísla z rozsahu 10000000 – 19999999 a bude je ukládat do proměnné ra_ean na kterou se pak můžeme odkazovat zápisem ${ra_ean} StringFromFile Funkce StringFromFile může být použita pro čtení textových řetězců ze souboru. Pokaždé když je zavolána, přečte další řádku z textového souboru. Když je dosaženo konce souboru, začne číst textové řetězce zase od začátku.
4.2.2 Testovací scénáře V této kapitole popíšeme testovací scénáře, které pak budeme používat k simulaci zátěže uživatelů či k naplnění databáze digitálního archivu SAFE daty v dalších kapitolách. U každého testovacího scénáře popíšeme jeho účel a logickou strukturu a také jak je realizován v testovacím nástroji JMeter.
4.2.2.1 TEST1: Reprezentativní zátěž systému Tento testovací scénář se snaží o simulaci práce uživatelů se systémem SAFE XY. V systému pracuje reálně několik typů uživatelů (viz Tab. 28). V testu tak musíme zohlednit práci všech těchto rolí uživatelů a přiblížit se tak reálné zátěži. Tab. 28 – Typy uživatelů
Role uživatele supervisor (účetní) schvalovatel čtenář
Typická činnost zakládá faktury schvaluje faktury vyhledává faktury
Proces zpracování faktur V reálném provozu je proces zpracování faktury složitější. Schvalovatelé si předávají faktury mezi sebou, případně i účetní a proces se může vracet do různých stavů. Pro testovací účely zjednodušíme tento proces a budeme používat čtyři podpisy (popsané v kapitole Popis testovacího systému SAFE): 1. Účetní se přihlásí, klikne na záložku Faktury a vybere volbu Založit fakturu přijatou. Po té vyplní vlastnosti faktury a uloží ji. 2. Účetní klikne na záložku Moje faktury a vybere složku Moje faktury NOVÉ. Zde vybere jednu fakturu. Zobrazí si stránku Průvodka a vytvoří podpis Předat správu faktury (předá schvalovateli). Odhlásí se. 3. Schvalovatel se přihlásí klikne na složku Moje Faktury Nové a vybere jednu fakturu. Na této faktuře si zobrazí stránku Průvodka a vytvoří podpis Potvrdit schválení. Buď klikne na záložku Moje Faktury a vybere složku Moje Faktury k ZAÚČTOVÁNÍ. Zde vybere jednu fakturu. Zobrazí si stránku Průvodka a vytvoří podpis Zaúčtováno. Nebo klikne na záložku Moje Faktury a vybere složku Moje Faktury k PROPLACENÍ. Zde vybere jednu fakturu. Zobrazí si stránku Průvodka a vytvoří podpis Proplaceno.
- 75 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
4. Čtenář se přihlásí klikne na záložku Faktury a vybere dotaz Přijaté faktury. Zde zvolí nějaké parametry dotazu a spustí vyhledávání. Vrátí se na parametry vyhledávání a zadá jiné. Seřadí si výsledek vyhledávání dle nějakého sloupce. Po té vybere z výsledku vyhledávání jednu fakturu, kterou si zobrazí. Bod 1 představuje vytváření faktur, bod 2 a 3 zpracování faktur a bod 4 vyhledávání faktur. Rozložení uživatelů bude následující: •
účetní - 2
•
schvalovatel - 3
•
čtenář - 10
To přibližně odpovídá rozložení uživatelů u zákazníků. Samozřejmě je to pouze odhad rozložení úloh a u každého zákazníka je to individuální. Budeme předpokládat, že rozložení zátěže odpovídá poměru 2:3:10 (vytváření : zpracování : vyhledávání). Realizace v Jmeter Test je rozdělen na 3 thread group (účetní, schvalovatel, čtenář). Jeho popis je uveden v příloze 1.
4.2.2.2 TEST2: Přidání faktury Tento testovací scénář používáme k vytvoření objektů faktur. Je konstruován tak aby v co nejkratší době vytvořil co nejvíce faktur. Jeho účelem není testování výkonu systému, ale vytvoření faktur v systému, tak abychom simulovali prostředí produkční databáze, která čítá zhruba 100 000 faktur. Tento test je tedy „podpůrným“ testem pro TEST1, který simuluje reálnou zátěž systému. Ke vkládání faktur používáme uživatele Účetní. Ten má pak faktury ve složce Moje faktury NOVÉ. Vkládání faktur: 1. Uživatel účetní se přihlásí 2. Vytvoří draft faktury a vyplní její vlastnosti. 3. Uloží fakturu. 4. Odhlásí se Aby nebyl systém zbytečně zatěžován přihlašováním a odhlašováním uživatelů, tak se kroky 2 a 3 opakují stokrát a pak se pokračuje krokem 4. Realizace v JMeter Popis stromu testu je uveden v příloze 2.
4.2.2.3 TEST3: Přidání objektu adresáře Jako předchozí testovací scénář je tento také „podpůrným“ testem pro TEST1 i pro TEST2. Tento test přidá do adresáře sytému SAFE XY 100 firem. Ty budou použity jako dodavatelé na fakturách. Bude tak zajištěna vyšší realističnost vkládaných dat. Realizace v JMeter Popis stromu testu je uveden v příloze 3
4.2.2.4 TEST4: Přidání faktury se souborem Tento testovací scénář je využit v kapitole 4.4. Vychází z TESTU2. Liší se v přidání souboru faktury. Realizace v JMeter Popis stromu testu je uveden v příloze 4.
- 76 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
4.3 Nastavení databáze pro optimální výkon Cílem této kapitoly je popsat nastavení konkrétní databáze, tak aby podávala optimální výkon. K tomu bude využita teorie popsaná v kapitole Optimalizace výkonu databáze. Nejprve nastavíme parametry databáze, poté budeme konfigurovat paměť a nakonec popíšeme nastavení I/O. Ještě před samotným popisem nastavení databáze si popíšeme prostředky (hardware a software) používané pro účely ladění a testování databáze digitálního archivu SAFE. Tab. 29 - Databázový server
Databázový server Operační systém CPU RAM Software
Microsoft Windows Enterprise 2x Intel Xeon 3,4 GHz 4GB Oracle 11g
Tab. 30 - Aplikační server
Aplikační server Operační systém CPU RAM Software
Microsoft Windows Server 2003 2x Intel Xeon 2,8 GHz 3 GB Apache Tomcat Digitální archiv SAFE
4.3.1 Základní nastavení databáze Před tím než začneme používat databázi, nastavíme nejdůležitější parametry databáze (viz Tab. 31). Toto nastavení provedeme pomocí Enterprise Manager. Přihlásíme se jako uživatel SYS. Klikneme na záložku server a zde na nastavení inicializačních parametrů (Initialization Paramaters). Tím si zobrazíme stránku se všemi inicializačními parametry (viz
- 77 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Obr. 44). Po nastavení parametrů na požadované hodnoty stiskneme tlačítko Save to File. Poté restartujeme databázový systém. Tab. 31 - Nastavení inicializačních parametrů
Hodnota 11.1.0.0.0 8192 800 150 necháme prázdný AUTO UNDOTBS1
- 78 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Obr. 44 - Stránka s parametry (nastavení parametru memory_target)
Nastavení velikosti souborů Redo logů Potom co jsme nastavili nejdůležitější parametry, nastavíme velikost redo logů. Jelikož by se nám špatně odhadoval počet bloků redo log souboru, kterém se má provést checkpoint (parametr FAST_START_MTTR_TARGET), odhadneme dostačující velikost redo log souboru na 51 200 KB. Velikost redo logů ověříme tak, že spustíme TEST1 a budeme sledovat v enterprise manageru (záložka server – Redo Log Groups), jestli se změní redo log group dříve než za 20 min. Stačí si zapamatovat číslo Sequence ( číslo posloupnosti) u skupiny, která je current a po dvaceti minutách podívat na to která skupina redo logů je aktivní a jaké má číslo Sequence. Spustíme zátěž systému použitím TEST1 a budeme sledovat, jestli se skupina přepne dříve než za 20 min. Po asi 30 minutách nenastal switch redo log skupiny. To znamená, že velikost souborů redo logů je dostačující a nebude negativně ovlivňovat výkon. Obr. 45 - Redo log group v EM
Nastavení temporary tablespace Dle doporučení z kapitoly 3.4.1 necháme nastavení na výchozích hodnotách: Extent management – Local, UNIFORM 1MB Segment space management - Automatic Nastavení tablespace pro SAFE Vytvoříme tablespace pro aplikaci SAFE a nastavíme jeho parametry: •
Klikneme na záložku server a zde vybereme položku Tablespaces. Zobrazí se stránka se seznamem tablespaců.
•
Klikneme na tlačítko Create.
•
Vyplníme parametry:
- 79 -
Ladění databáze systému digitálního archivu SAFE
•
Tomáš Pobuda
o
Name: USERS2
o
přidáme soubor tlačítkem Add (nastavíme jméno, cestu a počáteční velikost)
o
Na záložce Storage nastavíme Extent management a Segment space management na Automatic.
Klikneme na OK a tablespace se vytvoří a je zobrazena stránka s nastaveními tablespace (viz Obr. 46)
Obr. 46 - Zobrazení detailu nastavení tablespace
4.3.2 Nastavení paměti databáze Než začneme nastavovat paměť. Spustíme na hodinu TEST1 a zaznamenáme si výstup z Aggregate Report (viz Příloha 8.6). Až dokončíme nastavení paměti ručně, budeme moci porovnat, jestli byl výkon lepší při Automatické správě paměti, nebo při ručním nastavení.
4.3.2.1 Ruční nastavení paměťových prostorů Předpokládejme, že máme k dispozici 800 MB paměti(tak jako automatická správa), kterou můžeme rozdělit mezi paměťové prostory. Počáteční nastavení paměťových prostorů, tak jak byly nastaveny automatickou správou paměti jsou uvedena v tabulce. Paměťový prostor Buffer cache Shared pool Large pool Java pool Ostatní Aggregate PGA target
Nejdříve nasbíráme statistiky o paměťových prostorech a poté rozhodneme o změnách ve velikostech těchto prostorů. Postup jak jednotlivé statistiky získat a jejich interpretaci najdeme v kapitole 3.4.3.
- 80 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Sběr statistik – Buffer cache Jak bylo popsáno v kapitole 3.4.3.1, podíváme se na výstup z pohledu V$DB_CACHE_ADVICE a vypočítáme buffer cache hit ratio. pohled - V$DB_CACHE_ADVICE Cache Buffers Estd Phys Read Factor Size (MB) 16 1992 10,5628 32 3984 5,445 48 5976 2,9531 64 7968 2,0766 80 9960 1,458 96 11952 1,3608 112 13944 1,2734 128 15936 1,1941 144 17928 1,1231 160 19920 1,0606 176 21912 1,0229 188 23406 1 192 23904 0,989 208 25896 0,9555 224 27888 0,9229 240 29880 0,8919 256 31872 0,8555 272 33864 0,814 288 35856 0,7637 304 37848 0,6936 320 39840 0,5883
Library cache hit ratio SUM(PINHITS)/SUM(PINS) 0,908 Ze statistik library cache vidíme, že v SQL AREA dochází k mnoha opětovným překladům a zneplatněním. Pokusíme se to eliminovat zvětšením paměti.
- 82 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Dictionary cache pohled - V$ROWCACHE PARAMETER SUM(GETS) SUM(GETMISSES) PCT_SUCC_GETS UPDATES dc_tablespaces 3276177 9 100,0 0 dc_tablespace_quotas 1 1 0,0 1 dc_awr_control 96 1 99,0 4 dc_object_grants 1506 98 93,5 0 dc_histogram_data 479907 2652 99,4 0 dc_rollback_segments 1105 21 98,1 31 dc_sequences 50 13 74,0 50 dc_segments 685093 2021 99,7 10 dc_objects 2585729 5196 99,8 133 dc_database_links 189 1 99,5 0 dc_histogram_defs 1170423 7070 99,4 8 dc_users 3541057 102 100,0 0 outstanding_alerts 59 9 84,7 2 dc_files 42 6 85,7 0 dc_global_oids 10219 188 98,2 0 dc_profiles 216 2 99,1 0 global database name 3136 1 100,0 0 Celkové dictionary cache hit ratio = 0,99 Dle celkového hit ratio dictionary cache se zdá, že není potřeba zvětšovat tuto paměť. Result cache pohled - V$_RESULT_CACHE_STATISTICS NAME VALUE Block Size (Bytes) 1024 Block Count Maximum 2624 Block Count Current 0 Result Size Maximum (Blocks) 131 Create Count Success 0 Create Count Failure 0 Find Count 0 Invalidation Count 0 Delete Count Invalid 0 Delete Count Valid 0 Dobrým znakem je, že hodnoty Create Count Failure a Delete Count Valid rovné nule. Špatným znakem je, že se result cache nevyužívá, jelikož hodnota Create Count Success je rovná nule. Statistiky - Redo log buffer pohled - V$SYSSTAT NAME redo buffer allocation retries
VALUE 0
Když je tato statistika blízko nule, pak je velikost redo log buffer dostačující. Vzhledem k tomu, že je nastaven na více než 5 MB, zdá se že je plýtváno pamětí. Mohl by být snížen.
- 83 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
Statistiky - PGA paměti pohled - V$PGASTAT NAME aggregate PGA target parameter aggregate PGA auto target global memory bound total PGA inuse total PGA allocated maximum PGA allocated total freeable PGA memory process count max processes count PGA memory freed back to OS total PGA used for auto workareas maximum PGA used for auto workareas total PGA used for manual workareas maximum PGA used for manual workareas over allocation count bytes processed extra bytes read/written cache hit percentage
Jak je vidět z dat, tak jsou všechny dotazy zpracovány optimálně. Velikost paměti PGA je tedy buď dobře nastavena nebo je předimenzována a mohla by být zmenšena. Podívejme se na další statistiky.
Dle statistik PGA paměti se zdá, že je předimenzována. I při velikosti PGA paměti 144 MB je odhadováno, že pokud bude hledán nějaký objekt v cache, tak bude na 100 % nalezen. Podívejme se ještě jaký je odhad rozložení zpracování SQL dotazů, jestliže bychom snížily PGA paměť o polovinu, tedy na 144 MB. pohled - V$PGA_TARGET_ADVICE_HISTOGRAM LOW_KB
HIGH_KB
2 64 128 256 512 1024 2048 4096 8192 32768
4 128 256 512 1024 2048 4096 8192 16384 65536
ESTD_OPTIMAL_CNT
ESTD_ONEPASS_CNT
ESTD_MPASS_CNT
216953 338 294 239 23125 2565 958 196 194 2
0 0 0 0 0 0 0 0 0 2
0 0 0 0 0 0 0 0 0 0
I tato statistika ukazuje, že při snížení velikosti paměti PGA na 144 MB by to nemělo mít negativní vliv na zpracování dotazů. Odhaduje se, že pouze dva dotazy budou zpracovány jednoprůchodově. Nastavení parametrů Z nasbíraných statistik můžeme rozhodnout o změnách velikostí paměťových prostorů. Paměť PGA snížíme na 144 MB. Tím získáme volných 144 MB do našeho „rozpočtu“ 800 MB. Ty přidělíme paměťovému prostoru shared pool. Zejména jeho složka Library cache vykazuje známky potřeby zvětšení jejího paměťového prostoru. Parametry nastavíme takto: Paměťový prostor Buffer cache Shared pool Large pool Java pool Ostatní Aggregate PGA target
Nyní restartujeme databázi a spustíme na hodinu zátěž systému. K tomu použijeme TEST1. Po skončení testu si uložíme výstup z Aggregate Report (viz přílohu 8.6). Srovnání automatického a manuálního nastavení Po zvýšení paměti shared pool na úkor paměti PGA se celkově výkon databáze mírně zlepšil. Je to vidět z tabulky se srovnáními v příloze 8.6. Medián odezvy se snížil z 906 ms na 828 ms a odezva 90% nejrychlejších požadavků je snížila z 2375 ms na 2063 ms. Podívejme se nyní na jednotlivé požadavky a jejich odezvy u 90% nejrychlejších. U některých došlo ke zkrácení doby odezvy a u jiných k prodloužení. Významná prodloužení či zkrácení doby odezvy je vyznačeno tučně. Významná zkrácení odezvy u 90% Line Došlo k němu zejména u „běžných zobrazení“, jako jsou Návrat na parametry, Odhlášení, Podpis Potvrdit schválení či Podpis zaúčtováno, při kterých nejsou na server odesílány parametry pro dotaz či vytvoření objektu. Zvětšením Shared pool paměťového prostoru se vešlo více dotazů v parsovaném stavu do paměti a tak mohly být rychleji zpracovány. Významná prodloužení doby odezvy 90% Line Došlo k němu zejména u požadavků „editace podpisu ...“, při kterých se podpisy ukládají. To znamená, že se vytváří objekty podpisů a mění se nějaké vlastnosti podepisované faktury. Snížením velikosti paměti PGA měly procesy k dispozici méně paměti a tak trvalo déle vkládání a modifikace objektů. Potom co jsme dokončily analýzu změn odezvy bychom znovu nasbíraly statistiky pro jednotlivé paměťové prostory a snažili bychom se dále vylepšit nastavení paměti. My jsme provedli jednu iteraci z mnoha možných. To je pro rozsah této práce dostačující. Jak je vidět, nastavení paměti je náročné na čas (nastavení parametrů, spuštění testů, sběr a interpretace statistik). Otázkou je jakého zlepšení výkonu by se nám podařilo dosáhnout. V naší situaci, kdy máme pouze jeden typ zátěže databáze, je nastavení paměti jednodušší než v realitě, kde můžou existovat různě rozložené zátěže. Potom bychom museli znovu paměť ladit, jakmile by taková situace nastala. Doporučení Oracle používat automatickou správu paměti je tedy opodstatněné. K ručnímu nastavení paměti bychom se měli uchylovat pouze při dokonalé znalosti zátěže databáze a toho jaké paměťové prostory nejvíce využívá.
4.3.3 Nastavení I/O Před tím než začneme konfigurovat I/O subsytém spustíme kalibraci a zjistíme jestli je I/O dostatečně rychlé. • Před tím než spustíme konfiguraci zkontrolujeme následující nastavení: • parametr timed_statistics nastaven na TRUE • parametr filesystemio_options nastaven na SETALL • zkontrolujeme povolení asynchronního I/O pro datové soubory (viz Tab. 33) Tab. 33 - povolení asynchronního I/O pro soubory
NAME C:\ORACLE\ORADATA\OITZ\SYSTEM01.DBF C:\ORACLE\ORADATA\OITZ\SYSAUX01.DBF C:\ORACLE\ORADATA\OITZ\UNDOTBS01.DBF C:\ORACLE\ORADATA\OITZ\USERS01.DBF C:\ORACLE\ORADATA\OITZ\USERS2_01.DBF C:\ORACLE\ORADATA\OITZ\USERS3.DBF
Po kontrole nezbytných nastavení spustíme kalibraci příkazem popsaným v kapitole 3.4.4.1 (počet disků 1). Po skončení kalibrace se podíváme do tabulky DBA_RSRC_IO_CALIBRATE na výsledky (viz Tab. 34) Tab. 34 - Výsledek kalibrace – tabulka DBA_RSRC_IO_CALIBRATE START_TIME
END_TIME
MAX_IOPS
MAX_MBPS
LATENCY
NUM_PHYSICAL_DISKS
57:22,1
01:52,8
431
82
5
1
Latence (zpoždění) je 5 ms, maximální IOPS 431 požadavků za sekundu a maximální MBPS 82 MB/sec. jsou dostačující hodnoty pro naši databázi. Nebudeme tedy rozdělovat soubory na více disků.
4.4 Ukládání souborů digitálního archivu Cílem tohoto testu je rozhodnout, jestli je rychlejší vkládání souborů faktur do databáze Oracle nebo do souborového systému (FS). K tomu využijeme testovací scénář TEST4, který vkládá faktury se souborem (obrázkem). Dále máme připraveny obrázky velikostí 50 KB, 500 KB, 1 MB, 5 MB a 10 MB které budeme testovacím scénářem vkládat. Nejdříve nastavíme systém, tak aby vkládal soubory do databáze. Poté spustíme pětkrát TEST4 (50 KB, 500 KB, 1 MB, 5 MB, 10 MB) a uložíme si data z Aggregate Report (viz 8.7) Nyní nastavíme systém, tak aby soubory ukládal na disk serveru, kde je umístěna databáze Oracle. Znovu spustíme TEST4 pro všechny velikosti souborů a uložíme si data z Aggregate Report (viz 8.7) Porovnání výsledků Z nasbíraných dat vytvoříme grafy závislosti doby odezvy na velikosti souboru(viz příloha 8.8). Pro porovnání obou situací použijeme medián odezvy pro uživatele. Jak je vidět z grafů i z dat (viz 8.7), tak při vkládání faktur se soubory o velikostech 50 KB a 500 KB jsou obě nastavení srovnatelně rychlá. Při vkládání faktur se soubory 1 MB, 5 MB a 10 MB je rychlejší ukládání na souborový sytém. Z grafů je též vidět stoupající trend odezvy při zvětšování velikosti souboru. Při nastavení ukládání do databáze je trend strmější a při ukládání na souborový systém mírnější.
- 88 -
Závěr
Tomáš Pobuda
5 Závěr Cílem práce bylo prozkoumat a vyzkoušet možnosti ladění databáze Oracle, která je používána digitálním archivem SAFE. Tyto možnosti pak vyzkoušet prakticky a zjistit jak různá nastavení ovlivňují výkon systému. Dalším cílem bylo zjistit, jestli je rychlejší soubory digitálního archivu SAFE ukládat do databáze nebo na souborový systém. V kapitole 2 jsme popsali faktory, které ovlivňují výkon databázových systémů. Tím jsme čtenáře uvedli do problematiky ladění databází a zároveň jsme vymezili co bude náplní této práce. Tedy především nastavování parametrů databáze. Popisem možností ladění databáze Oracle se zabývá v kapitola 3. V prvních třech podkapitolách se zabýváme novinkami v ladění systému Oracle. Dále také metodou The Oracle Performance Improvement Method, což je doporučený postup ladění databáze od společnosti Oracle. A naposled popisem nástrojů pro ladění databáze, které jsou dostupné ve verzi Oracle 11.1. Nejvíce prostoru je věnováno správnému nastavení parametrů databáze. To je popsáno v kapitole 3.4. Při nastavení některých parametrů je dobré se držet rad uvedených v dokumentaci Oracle a popsaných v této kapitole. Některé parametry však vyžadují pro správné nastavení další informace. Těmito informacemi jsou statistiky. Ty jsou sbírány a udržovány nástrojem AWR. Analýzou těchto statistik je pak možné rozhodnout o správné hodnotě daného parametru. V poslední podkapitole popisujeme využití nástrojů SQL Tuning Advisor a SQL Access Advisor pro automatické ladění SQL příkazů. Tím byl splněn cíl, prozkoumat možnosti ladění databáze Oracle. V další části, tedy v kapitole 4, nejprve popisujeme systém SAFE a implementaci systému, na které pak provádíme testy a ladíme jeho databázi. Abychom mohli ladit databázi systému SAFE, museli jsme vybrat vhodný testovací nástroj pro generování HTTP požadavků (kap. 4.2). Nejprve jsme zmapovali oblast testovacích nástrojů a vybrali dva, které splňovali základní kritéria (generování HTTP požadavků). Poté jsme definovali další kritéria, dle kterých jsme vybrali testovací nástroj Apache JMETER. Pomocí tohoto nástroje jsme vytvořily potřebné testovací scénáře pro generování zátěže. Ty jsou popsány v kapitole 4.2.2. Po vytvoření testovacích scénářů jsme mohli přikročit k ladění databáze popsané v kapitole 4.3. Nejprve jsme nastavili inicializační parametry, dle doporučení uvedených v kapitole 3.4.1. Poté jsme se zabývali nastavením paměti databáze. Jako první jsme vyzkoušeli Automatickou správu paměti. Spustili jsme testovací scénář simulující reálnou zátěž (TEST1) a zaznamenali si výkon. Pak jsme provedli sběr statistik a jejich analýzou rozhodli o ručním nastavení paměťových prostorů databáze. Poté jsme znovu spustily TEST1 a zaznamenali si výkon. Porovnáním údajů jsme zjistily, že výkon se při ručním nastavení mírně zlepšil. Pokud předpokládáme, že zátěž generovaná testovacím scénářem TEST1 je blízká reálné zátěži většiny systémů. Můžeme doporučit snížit paměť PGA a takto získanou paměť rozdělit mezi paměťové prostory SGA, zejména Shared pool. Tím byl splněn cíl vyzkoušet, jak nastavení parametrů ovlivňuje výkon sytému. Jako poslední v kapitole 4.3 jsme provedli kalibraci I/O, která ukázala, že I/O není prvkem, který databázi brzdí, a tak jsme I/O dále nekonfigurovali. Jelikož by to nepřineslo žádné zlepšení výkonu systému. V kapitole 4.4 jsme se zabývali otázkou rychlosti ukládání souborů digitálního archivu SAFE do databáze a na souborový systém. Pro tuto kapitolu byl vytvořen testovací scénář TEST4, který vkládá do systému objekty se soubory (obrázky). Provedli jsme postupně vkládání souborů o velikosti 50 KB, 500 KB, 1 MB, 5 MB a 10 MB jak na souborový systém tak do databáze. Výsledky těchto testů jsou v příloze 7. Z výsledků je vidět, že vkládání objektů se soubory o velikosti 50 KB a 500 KB je srovnatelně rychlé při obou nastaveních. Vkládání objektů se sobory o velikosti 1 MB, 5 MB a 10 MB je rychlejší při ukládání souborů na souborový systém. Z grafů
- 89 -
Závěr
Tomáš Pobuda
v příloze 8 je vidět, že čím je sobor větší, tím je ukládání pomalejší u obou nastavení. Avšak při ukládání souborů na souborový systém se doba uložení souboru zvyšuje o mnoho méně než při ukládání souborů do databáze. To znamená, že pokud zákazník vkládá objekty se soubory do velikosti 500 KB, je možné použít obě nastavení. Pokud však vkládá objekty větší, je lepší použít ukládání souborů na souborový systém. Přínosem práce je zejména vyzkoušení ladění databáze Oracle, kterou využívá digitální archiv SAFE. Spolu s popisem mohou posloužit jako příručka při nastavování databáze Oracle pro použití s digitálním archivem SAFE. Dalším přínosem je zodpovězení otázky, jestli je rychlejší ukládat soubory digitálního archivu SAEF do databáze nebo na souborový systém. Tyto výsledky mohou být použity při rozhodování, kde ukládat soubory v digitálního archivu SAFE v závislosti na analýze velikosti souborů vkládaných objektů zákazníkem. Posledním přínosem jsou testovací scénáře, které jsou využitelné na reálných projektech k testování agendy faktur.
- 90 -
Literatura
Tomáš Pobuda
6 Literatura [KRCH] [HAVLIN] [HYNAR] [JMETER] [KUTAC]
[MULLINS] [ORA-2D]
[ORA-AG]
[ORA-DC]
[ORA-PTG]
[ORA-REF]
[SAFE]
KRCH, David. materiály ke cvičením předmětu 4IT340 (Základy správy databázového systému Oracle) na VŠE 2007. Havlín, Jaroslav, Porovnání testovacích nástrojů a technologií pro jednotlivé aplikační vrstvy J2EE aplikací, ČVUT FEL katedra počítačů, srpen 2007. HYNAR, Martin, Nástroje pro platformu Java, Neocortex, 2004, Praha, ISBN – 8086330-16-8 Apache Jakarta Project (Subproject JMeter), User manual [online]. Dostupné z WWW: http://jakarta.apache.org/jmeter/usermanual/index.html KUTÁČ, Daniel, Vyspělé databázové technologie III. – Bitmapové indexy [online], duben 2004. Dostupné z WWW: http://www.dbsvet.cz/view.php?cisloclanku=2004042701 MULLINS,S., Craig, Denormalization Guidelines [online], June 1997. Dostupné z WWW: http://www.tdan.com/view-articles/4142/ Oracle Corporation, Oracle Database 2 Day + Performance Tuning Guide, 11g Release 1 (11.1) [online], Oracle Corporation, červenec 2007. Dostupné z WWW: http://download.oracle.com/docs/cd/B28359_01/server.111/b28275/toc.htm Oracle Corporation, Oracle Database Administrator’s Guide, 11g Release 1 (11.1) [online], Oracle Corporation, říjen 2007. Dostupné z WWW: http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/toc.htm Oracle Corporation, Oracle Database Concepts, 11g Release 1 (11.1) [online], Oracle Corporation, říjen 2007. Dostupné z WWW: http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/toc.htm Oracle Corporation, Oracle Database Performance Tuning Guide 11g Release 1 (11.1) [online], Oracle Corporation, červenec 2007. Dostupné z WWW: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/toc.htm Oracle Corporation, Oracle Database Reference,11g Release 1 (11.1) [online], Oracle Corporation, červenec 2007. Dostupné z WWW: http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/toc.htm Aip SAFE s.r.o., Příručka administrátora
- 91 -
Terminologický slovník
Tomáš Pobuda
7 Terminologický slovník Termín ACID princip
Význam Atomicity, Consistency, Isolation, Durability (atomicita, konzistence, izolace, odolnost). To jsou principy, které garantují spolehlivost transakcí.
ADDM (automatic database diagnostic monitor) ANSI (American National Standards Institute)
AWR (advaced workload repository) CSV (Comma Separated Values)
Data striping
Databázový kurzor
doc HTTP(Hyper Text Transfer Protocol) I/O operace IP (Internet Protocol)
LDAP (Lightweight Directory Access Protocol)
LVM (Logical Management)
Volume
Materializovaný pohled
odt
[http://en.wikipedia.org/wiki/ACID] Nástroj pro analýzu statistik sbíraných AWR. [ORA-PTG] je americká standardizační organizace, sídlící ve Washingtonu. Celým názvem American National Standards Institute. Je to nezisková organizace, která vytváří průmyslové standardy ve Spojených státech. Je členem organizace ISO a IEC. [http://cs.wikipedia.org/wiki/Ip] Nástroj pro sběr statistik o databázi Oracle. [ORA-PTG] je jednoduchý souborový formát určený pro výměnu tabulkových dat. Soubor ve formátu CSV sestává z řádků, ve kterých jsou jednotlivé položky odděleny znakem čárka (,). [http://cs.wikipedia.org/wiki/CSV] Rozdělení logicky souvislých dat (např. soubor) tak, že jednotlivé části mohou být přiřazeny více diskům. [http://en.wikipedia.org/wiki/Data_striping] Objekt, pomocí kterého je možné ovládat pohyb po výsledku dotazu (po záznamech – řádcích), nejčastěji v rámci příkazu jazyka SQL SELECT. [http://www.dbsvet.cz/view.php?cisloclanku=2004100101] Přípona souborů vytvořených textovým editorem MS WORD. [autor] je internetový protokol určený původně pro výměnu hypertextových dokumentů ve formátu HTML. [http://cs.wikipedia.org/wiki/Http] Vstupní a výstupní operace disků. [autor] je datový protokol používaný pro přenos dat přes paketové sítě. Tvoří základní protokol dnešního Internetu. [http://cs.wikipedia.org/wiki/Internet_Protocol] je definovaný protokol pro ukládání a přístup k datům na adresářovém serveru. Podle tohoto protokolu jsou jednotlivé položky na serveru ukládány formou záznamů a uspořádány do stromové struktury (jako ve skutečné adresářové architektuře). Je vhodný pro udržování adresářů a práci s informacemi o uživatelích (např. pro vyhledávání adres konkrétních uživatelů v příslušných adresářích, resp. databázích). [http://cs.wikipedia.org/wiki/LDAP] Metoda alokace úložného prostoru v operačním systému Linux. Umožňuje spojovat více disků, diskových oddílů, RAID nebo jiných zařízení do logických celků, které lze dále využívat stejně jako klasické oddíly. [http://cs.wikipedia.org/wiki/LVM] Jsou to objekty schéma, které mohou být použity k shrnování, výpočtům, replikaci a distribuci dat. [ORA-DC] Přípona souborů vytvořených textovým editorem OpenOffice.org Writer. [autor] - 92 -
Terminologický slovník
Tomáš Pobuda
Termín pdf
RAID (Redundant Array of Independent Disks)
RAID5
SQL (Structured Language)
Query
SQL Profil
Transakce
txt XML (eXtensible Markup Language)
TIFF (Tag Format)
Image
File
Architektura klient / server
Význam Přípona souborů vytvořených ve formátu Portable Document Format (Přenosný formát dokumentů) vyvinutý firmou Adobe. [autor] Vícenásobné diskové pole nezávislých disků je typ diskových řadičů, které zabezpečují pomocí určitých speciálních funkcí koordinovanou práci dvou nebo více fyzických diskových jednotek. Zvyšuje se tak výkon a odolnost vůči chybám nebo ztrátě dat. [ http://cs.wikipedia.org/wiki/Raid] Jeden z typů RAID. Výhodou je, že jen jeden disk (i když pokaždé jiný) obsahuje redundantní informace a opět se dá využít paralelního přístupu k diskům, čímž se zkrátí doba odpovědi. Nevýhodou RAID 5 je ale pomalejší zápis. [http://cs.wikipedia.org/wiki/Raid#RAID_5] Standardizovaný dotazovací jazyk používaný pro práci s daty v relačních databázích. [http://cs.wikipedia.org/wiki/SQL] Soubor informací, které umožní optimalizátoru dotazů vytvořit optimální exekuční plán pro daný SQL příkaz. [ORA-PTG] Skupina příkazů, které převedou databázi z jednoho konzistentního stavu do druhého. [http://cs.wikipedia.org/wiki/Datab%C3%A1zov%C3%A1_transakce] Běžná přípona textových souborů. [autor] Obecný značkovací jazyk, který byl vyvinut a standardizován konsorciem W3C. Umožňuje snadné vytváření konkrétních značkovacích jazyků pro různé účely a široké spektrum různých typů dat. [http://cs.wikipedia.org/wiki/XML] Jeden z souborových formátů pro ukládání rastrové počítačové grafiky. Formát TIFF tvoří neoficiální standard pro ukládání snímků určených pro tisk. TIFF je složitější formát oproti jiným formátům pro ukládání rastrové grafiky. Tento formát vytvořila v roce 1986 společnost Aldus. TIFF umožňuje jako jeden z mála grafických formátů vícestránkové soubory a proto se často používá například pro ukládání přijatých faxů přijatých pomocí počítače a ISDN karty či faxmodemové karty. [http://cs.wikipedia.org/wiki/TIFF] Klient-server je síťová architektura, která odděluje klienta (často aplikaci s grafickým uživatelským rozhraním) a server. Jednotlivé instance klientů komunikují se serverem, který obvykle běží na vzdáleném počítači. Klasickou ukázkou může být prohlížení webových stránek, kde webový prohlížeč je klient, který při požadavku uživatele na novou stránku kontaktuje vzdálený server a vyžádá si od něj patřičnou webovou stránku. Server tedy poskytuje služby, které na vyžádání „konzumuje“ klient. [http://cs.wikipedia.org/wiki/Klient-server]
HTTP Request – Vytvoření podpisu Předat správu faktury
HTTP Request – Přepnutí na stránku průvodka
Získání náhodného id faktury z výsledku vyhledávání HTTP Request - Klik na fakturu ve výsledku vyhledávání
HTTP Request - Klik na složku Moje faktury NOVÉ
HTTP Request - Klik na záložku Moje Faktury
Thread group – 2 uživatelé
Čárový kód -${__Random(10000000,19999999,ra_ean)} Evidenční číslo - EV - ${__Random(10000000,19999999,ra_evNum)}A dle proměnných deviation, timer Dodavatel – získané id dodavatele ${id_id} HTTP Request - Přihlásí se uživatel účetní Datum vystavení ${__Random(1,28,ra_1)}.${__Random(1,12,ra_2)}.2008 Loop controller Datum účtování HTTP Request - Klik na záložku Faktury ${__Random(${__V(${ra_1})},28,ra_3)}.${__Random(${__V(${ra_2}) },12,ra_4)}.2008 HTTP Request - Klik vytvářecí link Datum splatnosti Získání id faktury ${__Random(${__V(${ra_3})},28,ra_5)}.${__Random(${__V(${ra_4}) },12,ra_6)}.2008 HTTP Request – Výběr dodavatele Variabilní symbol - ${__Random(10000,9999999,ra_variable)} z subjectName.txt a vložení. Částka bez DPH - ${__Random(1000,2000000,ra_sumTotal)} Celková částka s DPH získání id dodavatele – id_id ${__Random(${__V(${ra_sumTotal})},2000000,sum_sumTOtalDPH)} Měna - ${__StringFromFile(${datapath}\SODA_addInv\currency.txt)} Loop controller
Proměnné deviation = 500, timer = 3000
8.1 Příloha 1: Popis stromu TEST1
8 Přílohy
Přílohy
Přílohy
- 96 -
HTTP Request – Uložení podpisu Zaúčtováno
HTTP Request – Přepnutí na stránku Průvodka HTTP Request – Vytvoření podpisu Zaúčtováno
HTTP Request – Klik na fakturu ve výsledku vyhledávání
Získání náhodného id faktury z výsledku vyhledávání
HTTP Request – Vytvoření podpisu Potvrdit schválení HTTP Request – Uložení podpisu Potvrdit schválení HTTP Request - Klik na záložku Moje Faktury HTTP Request - Klik na složku Moje faktury K ZAÚČTOVÁNÍ
HTTP Request – Klik na fakturu ve výsledku vyhledávání HTTP Request – Přepnutí na stránku průvodka
dle proměnných deviation, timer HTTP Request - Přihlášení uživatele Schvalovatel Interleave controller Simple controller HTTP Request - Klik na záložku Moje Faktury HTTP Request - Klik na složku Moje faktury NOVÉ Získání náhodného id faktury z výsledku vyhledávání
HTTP Request – Přepnutí na stránku Průvodka HTTP Request – Vytvoření podpisu Zaúčtováno
HTTP Request – Klik na fakturu ve výsledku vyhledávání
Získání náhodného id faktury z výsledku vyhledávání
HTTP Request – Vytvoření podpisu Potvrdit schválení HTTP Request – Uložení podpisu Potvrdit schválení HTTP Request - Klik na záložku Moje Faktury HTTP Request - Klik na složku Moje faktury K ZAÚČTOVÁNÍ
HTTP Request – Klik na fakturu ve výsledku vyhledávání HTTP Request – Přepnutí na stránku průvodka
Simple controller HTTP Request - Klik na záložku Moje Faktury HTTP Request - Klik na složku Moje faktury NOVÉ Získání náhodného id faktury z výsledku vyhledávání
Tomáš Pobuda
Přílohy
- 98 -
HTTP Request – Odhlášení uživatele čtenář
HTTP Request – Přepnutí na stránku Průvodka HTTP Request – seřazení dle soupce definovaného v souboru ordercol.txt Získání náhodného id faktury z výsledku vyhledávání HTTP Request – Výběr faktury z výsledku vyhledávání
HTTP Request – Zadání parametrů Dodavatel a Datum vystavení
HTTP Request – Návrat na parametry dotazu HTTP Request – Zadání parametru Dodavatel pomocí souboru subjectName_3.txt HTTP Request – Návrat na parametry dotazu
HTTP Request – Klik na záložku faktury HTTP Request – Klik na dotaz Faktury přijaté HTTP Request – Zadání parametru Čárový kód - ${__Random(10000000,19999999,ra_ean)}
Získání vygenerovaného id souboru id_scan HTTP Request – Uložení objektu souboru (poslání souboru na server) HTTP Request – Výběr dodavatele ze souboru subjectName.txt Získání vygenerovaného id Dodavatele HTTP Request – Uložení faktury (viz Uložení faktury v příloze 1), kromě vlastnosti scan, kam se vyplní získané ${id_scan} HTTP Request – Odhlášení uživatele Účetní
HTTP Request – Klik na Vytvořit (viz Obr. 32)
HTTP Request – Založení draftu faktury Získání vygenerovaného id faktury
supplierTitle evNum sumTotal variable accountant state
currency.txt
CZK EUR USD CHF GBP SKK
- 102 -
MANUTAN Alois Dallmayr Automaten - Service VK čerpadla WANZL Kovos Nový Knín Ing. Josef Šimák MORAM CZ SSI SCHÄFER SHOP L’Oréal Professionnel LUCAFFE CZ – eshop ...
subjectName.txt MAN Alo VK WAN Kov Ing MOR SSI L’O LUC ...
subjectName_3.txt
Soubory obsahují textové řetězce, každý na novém řádku, protože každý řetězec, který má být přečten funkcí JMeter StringFromFile musí být na novém řádku. V testech jsou použity tyto soubory: currency.txt – obsahuje kódy jmen akceptované systémem SAFE XY ordercol.txt – obsahuje jména sloupců (systémová), dle kterých lze řadit ve výsledku vyhledávání dotazu Faktury přijaté. subjectName.txt – obsahuje 100 jmen firem subjectName_3.txt – obsahuje první tři písmena z názvu firmy
