3 Ladění databázového systému Oracle

Transkript

Tomáš Pobuda
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
Obsah
Tomáš Pobuda
Obsah
1
ÚVOD............................................................................................................................................. 8
2
FAKTORY OVLIVŇUJÍCÍ VÝKON DATABÁZOVÝCH SYSTÉMŮ ................................. 9
2.1
2.2
2.3
2.4
2.5
2.6
3
NORMALIZACE DATABÁZE ..................................................................................................... 9
DENORMALIZACE DATABÁZE ............................................................................................... 10
INDEXY ................................................................................................................................. 11
KONSTRUKCE SQL PŘÍKAZŮ ................................................................................................ 13
VÍCEUŽIVATELSKÉ PROSTŘEDÍ (ZÁMKY) ............................................................................. 13
NASTAVENÍ PARAMETRŮ...................................................................................................... 15
LADĚNÍ DATABÁZOVÉHO SYSTÉMU ORACLE ............................................................. 16
3.1
NOVINKY A VYLEPŠENÍ V LADĚNÍ VÝKONU DATABÁZE ORACLE 11.1 ................................ 16
3.2
METODA THE ORACLE PERFORMANCE IMPROVEMENT METHOD ....................................... 17
3.3
NÁSTROJE PRO LADĚNÍ DATABÁZE ORACLE ........................................................................ 18
3.4
OPTIMALIZACE VÝKONU DATABÁZE .................................................................................... 19
3.4.1 Nastavení parametrů databáze ........................................................................................ 19
3.4.2 Automatické ladění výkonu .............................................................................................. 23
3.4.2.1
3.4.2.2
3.4.3
Konfigurace paměti.......................................................................................................... 29
3.4.3.1
3.4.3.2
3.4.3.3
3.4.3.4
3.4.3.5
3.4.4
Automatic Workload Repository (AWR) .............................................................................25
Automatic Database Diagnostic Monitor (ADDM)..............................................................27
Konfigurace buffer cache .....................................................................................................30
Konfigurace shared pool.......................................................................................................33
Large pool.............................................................................................................................36
Konfigurace Redo log buffer ................................................................................................36
Správa PGA paměti ..............................................................................................................37
Kalibrace a konfigurace I/O ............................................................................................ 43
3.4.4.1
3.4.4.2
Kalibrace I/O ........................................................................................................................43
Konfigurace I/O....................................................................................................................44
3.5
LADĚNÍ SQL PŘÍKAZŮ .......................................................................................................... 46
3.5.1 Identifikace zatěžujících SQL příkazů.............................................................................. 46
3.5.2 Ladění zatěžujících SQL příkazů ..................................................................................... 47
3.5.2.1
3.5.3
3.5.3.1
3.5.3.2
3.5.3.3
3.5.4
4
Manuální použití SQL Tuning Advisor................................................................................47
Optimalizace přístupu k objektům ................................................................................... 49
Spuštění SQL Access Advisor..............................................................................................49
Zobrazení doporučení SQL Access Advisor ........................................................................51
Implementace doporučení SQL Access Advisor ..................................................................51
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
Vyhledávání ..................................................................................................................... 63
4.1.5.1
Objektové vyhledávání .........................................................................................................63
-6-
Obsah
Tomáš Pobuda
4.1.5.2
Fulltextové vyhledávání .......................................................................................................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
Testovací scénáře............................................................................................................. 63
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
TEST1: Reprezentativní zátěž systému ................................................................................63
TEST2: Přidání faktury ........................................................................................................63
TEST3: Přidání objektu adresáře..........................................................................................63
TEST4: Přidání faktury se souborem ...................................................................................63
4.3
NASTAVENÍ DATABÁZE PRO OPTIMÁLNÍ VÝKON.................................................................. 63
4.3.1 Základní nastavení databáze ........................................................................................... 63
4.3.2 Nastavení paměti databáze .............................................................................................. 63
4.3.2.1
Ruční nastavení paměťových prostorů .................................................................................63
4.3.3 Nastavení I/O ................................................................................................................... 63
4.4
UKLÁDÁNÍ SOUBORŮ DIGITÁLNÍHO ARCHIVU ...................................................................... 63
5
ZÁVĚR ........................................................................................................................................ 63
6
LITERATURA............................................................................................................................ 63
7
TERMINOLOGICKÝ SLOVNÍK ............................................................................................ 63
8
PŘÍLOHY.................................................................................................................................... 63
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
PŘÍLOHA 1: POPIS STROMU TEST1 ...................................................................................... 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)
-9-
Obr. 1 - Nenormalizovaná tabulka
Zamestnanec
ID_Zamestnanec
Jmeno
Prijmeni
ID_Oddeleni
Nazev_oddeleni
ID_Projekt1
Nazev_projektu1
ID_Projekt2
Nazev_projektu2
ID_Projekt3
Nazev_projektu3
Tomáš Pobuda
Obr. 2 - 1. NF
Zamestnanec
ID_Zamestnanec
Jmeno
Prijmeni
ID_Oddeleni
Nazev_oddeleni
1. NF
ZamProjekt
ID_Zamestnanec
ID_Projekt
Nazev_projektu
2. NF
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
Obr. 4 - 3. NF
ZamProjekt
ID_Zamestnanec
ID_Projekt
ZamProjekt
ID_Zamestnanec
ID_Projekt
Projekt
ID_Projekt
Nazev_projektu
Projekt
ID_Projekt
Nazev_projektu
Zamestnanec
ID_Zamestnanec
Jmeno
Prijmeni
ID_Oddeleni
Nazev_oddeleni
Zamestnanec
ID_Zamestnanec
Jmeno
Prijmeni
ID_Oddělení
3. 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 -
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 -
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 -
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 -
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ě
Read uncommited
Read comminted
Repeatable read
Serializable
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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
Komponenta
CPU
Paměť
Disk
Síť
nástroj UNIX
sar, vmstat, mpstat, iostat
sar, vmstat
sar, iostat
netstat
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 -
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 -
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 -
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 -
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 -
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]
Memory Management Mód
Pro
Nastavujeme
•
Automatic memory
management
Automatic shared memory
management
(Automatic memory
management deaktivován)
SGA
a
PGA
SGA
•
Celkovou
velikost
paměti pro instanci
(Volitelně) Maximální
velikost paměti pro
instanci
Oracle
automaticky ladí
•
•
•
•
Database
Celkovou velikost SGA
Velikosti
SGA
komponent
Velikost PGA v instanci
Individuální velikosti
PGA
•
•
velikosti SGA komponent
SGA target size
(Volitelně) maximální
velikost SGA
•
•
•
•
Shared pool size
Buffer cache size
Java pool size
Large pool size
Manual shared memory
management
(Automatic memory
management and automatic
shared memory management
deaktivován)
SGA
Automatic PGA memory
management
PGA
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 -
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)
30
60
91
121
152
182
212
243
273
304
334
364
395
424
456
486
517
547
577
608
3,802
7,604
11,406
15,208
19,010
22,812
26,614
30,416
34,218
38,020
41,822
45,624
49,426
53,228
57,030
60,832
64,634
68,436
72,238
76,040
18.70
12.83
7.38
4.97
3.64
2.50
1.74
1.33
1.13
1.00
.93
.87
.83
.79
.76
.74
.71
.69
.67
.66
192,317,943
131,949,536
75,865,861
51,111,658
37,460,786
25,668,196
17,850,847
13,720,149
11,583,180
10,282,475
9,515,878
8,909,026
8,495,039
8,116,496
7,824,764
7,563,180
7,311,729
7,104,280
6,895,122
6,739,731
- 31 -
10% z aktuální velikosti
Aktuální velikost
200% z aktuální velikosti
Tomáš Pobuda
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 -
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 -
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 -
Tomáš Pobuda
Tab. 13 – Příklad výstupu pohledu V$ROWCACHE [zdroj: ORA-PTG]
PARAMETER
dc_database_links
dc_free_extents
dc_global_oids
dc_histogram_defs
dc_object_ids
dc_objects
dc_profiles
dc_rollback_segments
dc_segments
dc_sequence_grants
dc_sequences
dc_synonyms
dc_tablespace_quotas
dc_tablespaces
dc_used_extents
dc_user_grants
dc_usernames
dc_users
SUM
(GETS)
81
44876
42
9419
29854
33600
19001
47244
100467
119
26973
6617
120
581248
51418
76082
216860
376895
SUM
(GETMISSES)
1
20301
9
651
239
590
1
16
19042
16
16
168
7
10
20249
18
12
22
PCT_SUCC_GET
S
98.8
54.8
78.6
93.1
99.2
98.2
100.0
100.0
81.0
86.6
99.9
97.5
94.2
100.0
60.6
100.0
100.0
100.0
UPDATES
0
40,453
0
0
52
53
0
19
40,272
0
26,811
0
51
0
42,811
0
0
0
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 -
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 -
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 -
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 -
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
VALUE
41156608
21823488
2057216
16899072
35014656
136795136
524288
1713242112
0
2383872
0
8470528
291
2124600320
39949312
98.15
UNIT
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
percent
Popis důležitých řádků z pohledu V$PGASTAT:
–
současná
hodnota
inicializačního
parametru
•
PGA_AGGREGATE_TARGET.
•
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.
- 39 -
Tomáš Pobuda
Tab. 17 – Příklad výstupu pohledu V$PROCESS [ORA-PTG]
PSEUDO
oracle@dlsun1690 (PMON)
oracle@dlsun1690 (MMAN)
oracle@dlsun1690 (DBW0)
oracle@dlsun1690 (LGWR)
oracle@dlsun1690 (CKPT)
oracle@dlsun1690 (SMON)
oracle@dlsun1690 (RECO)
oracle@dlsun1690 (q001)
oracle@dlsun1690 (QMNC)
oracle@dlsun1690 (MMON)
oracle@dlsun1690 (MMNL)
oracle@dlsun1690 (q000)
oracle@dlsun1690 (TNS V1-V3)
oracle@dlsun1690 (CJQ0)
oracle@dlsun1690 (TNS V1-V3)
PGA_USED_MEM
0
314540
313992
696720
10835108
352716
541508
323688
233508
314332
885756
315068
330872
635768
533476
430648
PGA_ALLOC_MEM
0
685860
685860
1063112
22967940
710376
948004
685860
585128
685860
1996548
685860
716200
928024
1013540
812108
PGA_FREEABLE_MEM
0
0
0
0
0
0
0
0
0
0
393216
0
65536
0
0
0
PGA_MAX_MEM
0
685860
685860
1063112
22967940
710376
1603364
816932
585128
685860
1996548
685860
716200
1255704
1144612
812108
Popis sloupců pohledu V$PROCESS:
•
PGA_USED_MEM – použitá paměť PGA
•
PGA_ALLOC_MEM – alokovaná paměť PGA
•
PGA_FREEABLE_MEM – uvolnitelný paměť PGA
•
PGA_MAX_MEM – maximální paměť PGA
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
HIGH_KB
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
524288
OPTIMAL_EXECUTIONS
ONEPASS_EXECUTIONS
156255
150
89
13
60
8
657
551
538
243
137
45
0
0
0
0
0
0
0
0
0
0
0
16
26
28
35
107
153
73
44
22
- 40 -
MULTIPASSES_EXECUTIONS
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Tomáš Pobuda
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 -
Tomáš Pobuda
Tab. 20 - Příklad výsledku dotazu na pohled V$PGA_TARGET_ADVICE
TARGET_MB
63
125
250
375
500
600
700
800
900
1000
1500
2000
3000
4000
CACHE_HIT_PERC
23
24
30
39
58
59
59
60
60
61
67
76
83
85
367
30
3
0
0
0
0
0
0
0
0
0
0
0
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
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
524288
156107
148
89
13
58
10
653
530
509
227
176
133
66
15
0
0
0
0
0
0
0
0
0
0
0
0
0
16
103
47
48
23
- 42 -
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Tomáš Pobuda
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 (<DISKS>, <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 -
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 -
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 -
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 -
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.
- 47 -
Tomáš Pobuda
Obr. 14 – Stránka SQL Tuning Advisor [zdroj: ORA-2D]
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 -
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ů
•
zobrazíme stránku SQL Advisor: Initial options (Advisor Central – SQL Advisors – SQL
Access Advisor)
•
Vybereme Recommend new access structure
•
Stiskneme Continue – zobrazí se stránka SQL Access Advisor: Workload Source
Obr. 17 – stránka SQL Acces Advisor: Initial Options [zdroj: ORA-2D]
2. Výběr zdroje zátěže
•
Vybereme možnost Use existing SQL Tunning Set
•
Klikneme na baterku a vybereme SQL tuning Set
•
Klikneme na next
3. Definice filtrů
Tuto možnost používat nebudeme, tudíž jí nebudeme ani popisovat.
- 49 -
Tomáš Pobuda
4. Výběr doporučení
•
zaškrtnutím vybereme doporučení, která chceme generovat (indexes, materialized views,
partitioning)
•
vybereme hloubku analýzy (limited mode, comprehensive mode)
•
klikneme na next
5. Naplánování úlohy SQL Access Advisor
•
nastavíme jméno a popis
•
ostatní hodnoty ponecháme standardní
•
klikneme na next
•
zobrazí se stránka s rekapitulací nastavení
•
klikneme na submit
Obr. 18 – stránka SQL Access Advisor: Schedule [zdroj: ORA-2D]
- 50 -
Tomáš Pobuda
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í.
Obr. 19 – stránka zobrazení SQL Acces Advisor [zdroj: ORA-2D]
3.5.3.3 Implementace doporučení SQL Access Advisor
Implementaci popíšeme v několika krocích:
•
Přejdeme na záložku Recommendations
•
Vybereme doporučení zaškrtnutím
•
Stiskneme tlačítko Schedule Implementation
•
Zobrazí se stránka pro zadání úlohy
•
Nastavíme jméno úlohy a jestli se má pokračovat v úloze, když dojde k chybě
•
Stiskneme tlačítko Submit
•
Je vytvořena úloha, která implementuje doporučení
- 51 -
Tomáš Pobuda
Obr. 20 – záložka Recommendation zobrazení SQL Acces Advisor [zdroj: ORA-2D]
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í
- 52 -
Tomáš Pobuda
Obr. 21 – Guided Workflow SQL Performance Analyzeru [zdroj: ORA-2D]
- 53 -
Ladění databáze systému digitálního archivu SAFE
Tomáš Pobuda
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 -
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 -
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 -
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 -
•
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
•
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 -
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 -
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 -
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 -
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 -
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 -
•
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 -
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 -
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:
<input type="checkbox" name="multiboxArray" value="12345" />
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 -
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 -
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 -
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 -
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ů
Parametr
COMPATIBLE
DB_BLOCK_SIZE
MEMORY_TARGET
PROCESSES
SESSIONS
UNDO_MANAGEMENT
UNDO_TABLESPACE
Hodnota
11.1.0.0.0
8192
800
150
necháme prázdný
AUTO
UNDOTBS1
- 78 -
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 -
•
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
Parametr
DB_CACHE_SIZE
SHARED_POOL_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
Velikost
188 MB
304 MB
4 MB
12 MB
8 MB
PGA_AGGREGATE_TARGET 288 MB
SGA
512 MB
Celkem
800 MB
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 -
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
Estd Phys Reads
27433849
14141901
7669778
5393289
3786780
3534276
3307386
3101378
2916825
2754595
2656693
2597212
2568677
2481656
2396931
2316581
2221983
2114195
1983511
1801484
1527920
Buffer cache hit ratio vypočítáme z dat z pohledu V$SYSSTAT (viz Tab. 32).
Tab. 32 - Výstup z pohledu V$SYSSTAT a hit ratio
NAME
db block gets from cache
consistent gets from cache
physical reads cache
buffer cache hit ratio
VALUE
144303002
512063613
2626338
100%
Vzhledem k tomu že je buffer cache hit ratio 100% je paměť 188 MB dostačující. Její zvětšení by
přineslo menší počet čtení z disku.
- 81 -
Tomáš Pobuda
Statistiky – Shared pool
pohled - V$SHARED_POOL_ADVICE
SHARED_PO
OL_SIZE_FOR
_ESTIMATE
SHARED_P
OOL_SIZE_
FACTOR
ESTD
_LC_
SIZE
ESTD_LC_
MEMORY_
OBJECTS
ESTD_L
C_TIME
_SAVED
ESTD_LC_T
IME_SAVE
D_FACTOR
ESTD_L
C_LOA
D_TIME
ESTD_LC_L
OAD_TIME
_FACTOR
ESTD_LC_M
EMORY_OBJ
ECT_HITS
176
208
240
272
304
336
368
400
432
464
496
528
560
592
624
0,5789
0,6842
0,7895
0,8947
1
1,1053
1,2105
1,3158
1,4211
1,5263
1,6316
1,7368
1,8421
1,9474
2,0526
17
49
81
113
145
177
209
241
273
305
337
369
401
433
465
2717
5857
7678
9577
11347
13025
14686
16326
17951
19620
21447
23368
25085
26451
27739
5798
5861
6684
7347
7371
7376
7377
7378
7380
7381
7381
7382
7382
7384
7384
0,7866
0,7951
0,9068
0,9967
1
1,0007
1,0008
1,0009
1,0012
1,0014
1,0014
1,0015
1,0015
1,0018
1,0018
2313
2250
1427
764
740
735
734
733
731
730
730
729
729
727
727
3,1257
3,0405
1,9284
1,0324
1
0,9932
0,9919
0,9905
0,9878
0,9865
0,9865
0,9851
0,9851
0,9824
0,9824
324104
597907
601952
603103
603755
604037
604188
604349
604548
604696
604749
604779
604963
605172
605265
Library cache
pohled - V$LIBRARYCACHE
NAMESPACE
PINS
BODY
12308
CLUSTER
505
INDEX
61
JAVA DATA
873
JAVA RESOURCE
0
JAVA SOURCE
0
OBJECT
0
PIPE
0
SQL AREA
265064
TABLE/PROCEDURE 354287
TRIGGER
2199
PINHITS
11375
496
0
867
0
0
0
0
217239
345236
2007
RELOADS
11
1
0
0
0
0
0
0
377
1532
0
INVALIDATIONS
0
0
0
0
0
0
0
0
150
0
0
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 -
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 -
Tomáš Pobuda
Statistiky - PGA paměti
pohled - V$PGASTAT
NAME
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
VALUE
301989888
222160896
60397568
55090176
86758400
110872576
0
44
47
0
0
19378176
0
0
0
12769409024
0
100
- 84 -
UNIT
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
percent
Tomáš Pobuda
pohled - V$PROCESS
PSEUDO
ORACLE.EXE (PMON)
ORACLE.EXE (VKTM)
ORACLE.EXE (DIAG)
ORACLE.EXE (DBRM)
ORACLE.EXE (PSP0)
ORACLE.EXE (MMAN)
ORACLE.EXE (DIA0)
ORACLE.EXE (DBW0)
ORACLE.EXE (LGWR)
ORACLE.EXE (CKPT)
ORACLE.EXE (SMON)
ORACLE.EXE (RECO)
ORACLE.EXE (MMON)
ORACLE.EXE (MMNL)
ORACLE.EXE (D000)
ORACLE.EXE (S000)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (FBDA)
ORACLE.EXE (SMCO)
ORACLE.EXE (QMNC)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (q000)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (q001)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (CJQ0)
ORACLE.EXE (SHAD)
ORACLE.EXE (W000)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
ORACLE.EXE (SHAD)
PGA_USED_MEM
0
437878
437078
433902
510242
437078
438278
467378
2309906
4662438
482514
968562
642054
1733138
507834
712777
266489
2200673
701146
1139210
434922
506734
1187954
2309954
1283113
768618
1296833
2192589
1914041
1848549
1688989
2970489
675274
701146
1499642
2038034
1204137
929458
696982
602114
7010722
701146
701146
PGA_ALLOC_MEM
0
716366
716366
716366
781902
716366
716366
830410
4067042
9629262
1002818
2223694
912974
2403274
781902
912974
454222
2616910
1691098
1747914
716366
781902
1568334
2936282
1502798
1240654
1502798
2420302
2223694
2289230
1830478
4779598
978510
1822170
2084314
2616910
1633870
1240654
1691098
847438
13601622
839130
839130
PGA_FREEABLE_MEM
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
PGA_MAX_MEM
0
716366
716366
716366
781902
716366
716366
1223626
4067042
10546766
1002818
3599950
912974
3910602
781902
1437262
519758
32173646
21941722
1878986
716366
781902
10088014
7327194
3272270
1568334
1961550
3198426
3984858
3919322
2813518
11176790
978510
21876186
2543066
3862094
4910670
7007822
4247002
847438
23366486
6868442
6999514
pohled - V$SQL_WORKAREA_HISTOGRAM
LOW_KB
HIGH_KB
2
64
128
256
512
1024
2048
4096
8192
4
128
256
512
1024
2048
4096
8192
16384
OPTIMAL_EXECUTIONS
ONEPASS_EXECUTIONS
MULTIPASSES_EXECUTIONS
32506
154
278
161
5203
2220
654
196
194
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
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.
- 85 -
V$PGA_TARGET_ADVICE
TARGET_MB CACHE_HIT_PERC
36
75
72
98
144
100
216
100
288
100
346
100
403
100
461
100
518
100
576
100
864
100
1152
100
1728
100
2304
100
Tomáš Pobuda
272
0
0
0
0
0
0
0
0
0
0
0
0
0
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
Parametr
DB_CACHE_SIZE
SHARED_POOL_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
188 MB
448 MB
4 MB
12 MB
8 MB
PGA_AGGREGATE_TARGET 144 MB
- 86 -
Velikost
SGA
656 MB
Celkem
800 MB
Tomáš Pobuda
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
- 87 -
ASYNCH_IO
ASYNC_ON
ASYNC_ON
ASYNC_ON
ASYNC_ON
ASYNC_ON
ASYNC_ON
Tomáš Pobuda
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:
Oracle Corporation, Oracle Database Concepts, 11g Release 1 (11.1)
[online], Oracle Corporation, říjen 2007. Dostupné z WWW:
Oracle Corporation, Oracle Database Performance Tuning Guide 11g Release 1 (11.1)
[online], Oracle Corporation, červenec 2007. Dostupné z WWW:
Oracle Corporation, Oracle Database Reference,11g Release 1 (11.1) [online], Oracle
Corporation, červenec 2007. Dostupné z WWW:
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 -
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]
- 93 -
Tomáš Pobuda
- 94 -
HTTP Request – Klik na uložit
Tomáš Pobuda
- 95 -
HTTP Request – Uložení podpisu Předat správu faktury
HTTP Request - Odhlášení
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í
HTTP Request – Vytvoření podpisu Potvrdit schválení
HTTP Request – Uložení podpisu Potvrdit schválení
HTTP Request - Klik na složku Moje faktury K ZAÚČTOVÁNÍ
HTTP Request - Přihlášení uživatele Schvalovatel
Interleave controller
Simple controller
Therad Group – 3 uživatelé
Tomáš Pobuda
Přílohy
- 97 -
HTTP Request – Uložení podpisu Zaúčtováno
HTTP Request – Odhlášení uživatele Schvalovatel
HTTP Request – Vytvoření podpisu Zaúčtováno
HTTP Request – Vytvoření podpisu Potvrdit schválení
HTTP Request – Uložení podpisu Potvrdit schválení
HTTP Request - Klik na složku Moje faktury K ZAÚČTOVÁNÍ
Simple controller
Tomáš Pobuda
Přílohy
- 98 -
HTTP Request – Odhlášení uživatele čtenář
HTTP Request – seřazení dle soupce definovaného v souboru ordercol.txt
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)}
HTTP Request – Přihlášení uživatele čtenář
Loop controller
Thread group – 10 uživatelů
Tomáš Pobuda
Přílohy
- 99 -
HTTP Request – Odhlášení uživatele účetní
HTTP Request – Uložení faktury (viz Uložení faktury v příloze 1)
Získání vygenerovaného id dodavatele id_id
HTTP Request – Založení draftu faktury
Získání vygenerovaného id faktury
HTTP Request – Výběr dodavatele ze souboru subjectName.txt
HTTP Request – Přihlášení uživatele účetní
Loop controller – 100 opakování
Simple Controller
Thread Group – 10 uživatelů
proměnné deviation 500 a timer 2000
Tomáš Pobuda
- 100 -
Jméno subjektu - ${__StringFromFile(${datapath}subjectName.txt)}
Typ subjektu - ${__Random(1,6,ra_type)}
IČ - ${__Random(10000000,99999999,ra_ic)}
DIČ - CZ${ra_ic}
HTTP Request – Odhlášení uživatele Administrátor
Získání vygenerovaného id subjektu
HTTP Request – Založení draftu subjektu
dle proměnných deviation a timer
Loop Controller – 100 opakování
HTTP Request – Přihlášení uživatele Administrátor
proměnné deviation = 500 a timer = 2000
Přílohy
Tomáš Pobuda
- 101 -
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
Loop controller – 300 opakování
Simple Controller
HTTP Request – Přihlášení uživatele Účetní
proměnné deviation 500 a timer 2000
8.4 Příloha 4 : Popis stromu TEST4
Přílohy
Tomáš Pobuda
Tomáš Pobuda
ordercol.txt
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
8.5 Příloha 5: Obsah textových souborů
Přílohy
Label
# Samples Average Median 90% Line
339
2475
2453
3530
Dotaz Faktury přijaté
943
1209
1000
2109
editace podpisu Potvrdit schválení
72
8030
8125
15297
Editace podpisu Proplaceno
73
1177
969
1687
editace podpisu Předat správu faktury
235
299
265
453
Editace podpisu Zaúčtováno
293
1384
1188
2203
Návrat na parametry
190
8352
8000
19969
Odhlášení
18
438
250
547
odhlášení účetní
950
1656
1578
2579
Podpis Potvrdit schválení
72
936
828
1407
Podpis Proplaceno
336
1036
922
1687
podpis Předat správu faktury
73
8022
7406
15828
Podpis Zaúčtováno
148
1289
969
2110
Přihlášení
100
1739
1172
2860
Přihlášení ctenar
20
1553
922
3984
Přihlášení účetní
147
8408
7250
20497
Seřazení "náhodně"
72
1536
1391
2141
Složka Moje faktury K PROPLACENÍ
191
960
875
1437
Složka Moje faktury K ZAÚČTOVÁNÍ
953
686
609
1031
Složka Moje faktury NOVÉ
40
2238
1641
4125
Stránka průvodka
191
1165
984
2000
Stránka Průvodka
951
1594
1515
2516
Uložit fakturu
40
349
250
563
Výběr dodavatele
1902
724
641
1078
Výběr faktury
944
1489
1453
2359
Vybrání faktury
74
1539
1390
2031
Vybrat fakturu
953
1008
891
1515
Zadání parametrů ean
148
1278
1125
1922
Zadání parametrů supplierTitle
148
1054
891
1703
Zadání parametrů supplierTitle + issueDate
40
1550
1156
2500
Založit fakturu přijatou
993
716
297
1984
Záložka Faktury
487
1035
406
2609
Záložka Moje Faktury
12136
1416
906
2375
TOTAL
Automatická správa paměti
Min
782
203
828
469
171
515
750
187
437
531
422
828
453
484
469
875
875
453
265
765
422
437
140
281
437
813
390
500
484
656
157
171
140
- 103 -
Max
Error % Throughput (sek.) KB/sec
11469
0,0
0,10
5,3
4812
0,0
0,27
6,4
21610
0,0
0,02
0,5
5422
0,0
0,02
0,5
906
0,0
0,07
0,5
6094
0,0
0,08
1,9
22875
0,0
0,05
1,1
3250
0,0
0,01
0,0
6515
0,0
0,27
11,4
2047
0,0
0,02
0,5
4235
0,0
0,10
1,9
21812
0,0
0,02
0,5
7047
0,0
0,04
0,4
12875
0,0
0,03
0,3
8437
0,0
0,01
0,1
21922
0,0
0,04
0,8
4063
0,0
0,02
1,2
4421
0,0
0,05
1,1
3750
0,0
0,27
4,7
10266
0,0
0,01
0,3
4109
0,0
0,05
1,4
7344
0,0
0,27
11,2
1906
0,0
0,01
0,0
4703
0,0
0,54
9,7
4532
0,0
0,27
11,7
5843
0,0
0,02
1,2
5890
0,0
0,27
5,3
7656
0,0
0,04
0,8
6656
0,0
0,04
0,8
8953
0,0
0,01
0,4
12843
0,0
0,28
4,0
12188
0,0
0,14
2,0
22875
0,0
3,39
86,3
8.6 Příloha 6: Výstup z Aggregate Report a srovnání – nastavení paměti
Přílohy
Tomáš Pobuda
1312
828
2063
141 23532
20002
TOTAL
- 104 -
0,0
3,47
88,7
Max
6421
0,0
0,27
4,8
21953
0,0
0,04
0,8
23532
0,1
0,02
0,5
23422
0,0
0,06
1,2
22031
0,0
0,02
0,5
5328
0,0
0,55
9,9
1172
0,0
0,07
0,5
625
0,0
0,01
0,0
4218
0,0
0,04
0,8
3422
0,0
0,02
0,5
1828
0,0
0,06
1,1
2047
0,0
0,02
0,5
9078
0,0
0,04
0,4
19656
0,0
0,03
0,3
6515
0,0
0,01
0,1
9437
0,0
0,27
12,0
8625
0,0
0,02
1,2
2782
0,0
0,02
1,2
8094
0,0
0,10
5,4
11296
0,0
0,04
0,8
6641
0,0
0,10
2,0
14156
0,0
0,01
0,3
2015
0,0
0,01
0,0
10485
0,0
0,08
1,9
6953
0,0
0,28
6,5
3766
0,0
0,06
1,4
7891
0,0
0,27
5,4
7532
0,0
0,27
11,5
8140
0,0
0,27
11,7
11578
0,0
0,01
0,4
16344
0,0
0,28
4,1
15328
0,0
0,14
2,0
Min
297
797
890
750
844
297
156
172
500
515
484
515
453
469
546
438
687
766
828
500
438
781
141
422
172
468
406
406
422
609
172
203
Label
1571
621
562
907
241
8203
7437
18219
119
8127
7532
20439
313
7836
7281
18313
121
8581
7938
17313
3141
651
609
906
Odhlášení
390
298
250
468
30
296
266
516
241
892
781
1265
Podpis Proplaceno
119
947
860
1438
313
895
844
1313
121
966
921
1359
Přihlášení
243
1204
1000
1875
160
1693
1187
2203
32
1233
922
1890
1564
1428
1391
2203
120
1549
1328
2218
121
1448
1359
2031
557
2460
2437
3797
Stránka průvodka
242
1130
953
1516
Stránka Průvodka
554
977
875
1468
Uložit fakturu
64
2060
1625
2672
Výběr dodavatele
64
360
281
562
Výběr faktury
484
1171
1016
1781
Vybrání faktury
1561
995
890
1531
Vybrat fakturu
313
1100
1031
1656
1571
929
813
1328
1570
1458
1453
2188
1565
1489
1453
2235
64
1396
1078
1782
Záložka Faktury
1635
646
282
1641
798
892
407
2047
Manuální nastavení paměti
Přílohy
Tomáš Pobuda
TOTAL
Label
Odhlášení
Podpis Proplaceno
Přihlášení
Stránka průvodka
Stránka Průvodka
Uložit fakturu
Výběr dodavatele
Výběr faktury
Vybrání faktury
Vybrat fakturu
Záložka Faktury
Srovnání dle Median, Min, Max
Přílohy
90% Line – Aut.
2375
3530
2109
15297
1687
453
2203
19969
547
2579
1407
1687
15828
2110
2860
3984
20497
2141
1437
1031
4125
2000
2516
563
1078
2359
2031
1515
1922
1703
2500
1984
2609
90% Line – Man.
2063
907
18219
20439
18313
17313
906
468
516
1265
1438
1313
1359
1875
2203
1890
2203
2218
2031
3797
1516
1468
2672
562
1781
1531
1656
1328
2188
2235
1782
1641
2047
- 105 -
906
828
140
141
22875
23532
Median – Aut.
Median – Man.
Min – Aut.
Min – Man.
Max – Aut.
Max – Man.
2453
562
782
297
11469
6421
1000
7437
203
797
4812
21953
8125
7532
828
890
21610
23532
969
7281
469
750
5422
23422
265
7938
171
844
906
22031
1188
609
515
297
6094
5328
8000
250
750
156
22875
1172
250
266
187
172
3250
625
1578
781
437
500
6515
4218
828
860
531
515
2047
3422
922
844
422
484
4235
1828
7406
921
828
515
21812
2047
969
1000
453
453
7047
9078
1172
1187
484
469
12875
19656
922
922
469
546
8437
6515
7250
1391
875
438
21922
9437
1391
1328
875
687
4063
8625
875
1359
453
766
4421
2782
609
2437
265
828
3750
8094
1641
953
765
500
10266
11296
984
875
422
438
4109
6641
1515
1625
437
781
7344
14156
250
281
140
141
1906
2015
641
1016
281
422
4703
10485
1453
890
437
172
4532
6953
1390
1031
813
468
5843
3766
891
813
390
406
5890
7891
1125
1453
500
406
7656
7532
891
1453
484
422
6656
8140
1156
1078
656
609
8953
11578
297
282
157
172
12843
16344
406
407
171
203
12188
15328
Tomáš Pobuda
328
922
31
415
TOTAL
520
Min
360
203
46
281
62
218
31
1781
Label
Přihlášení
10
551
485
1234
100
424
390
718
Vytvoření souboru
100
89
79
140
Uložení souboru
100
418
390
594
Výběr dodavatele
100
172
140
328
Uložit
100
992
937
1453
Odhlášení
10
56
47
125
500 KB – databáze
297
31
679
TOTAL
520
Min
641
218
46
125
78
516
31
Label
Přihlášení
10
1927
1218
4734
100
687
515
1469
Vytvoření souboru
100
103
78
188
Uložení souboru
100
303
250
547
Výběr dodavatele
100
288
187
641
Uložit
100
1949
1594
3594
Odhlášení
10
68
62
141
50 KB – databáze
0.0
2,3
34,9
1953
- 106 -
0.0
2,3
37,0
Max Error % Throughput (sek.) KB/sec
1234
0.0
0,2
3,2
922
0.0
0,5
20,7
250
0.0
0,5
0,0
891
0.0
0,5
0,1
610
0.0
0,5
0,3
1953
0.0
0,5
18,5
125
0.0
0,2
1,4
5625
4734
0.0
0,2
2,9
3203
0.0
0,5
19,7
500
0.0
0,5
0,0
1781
0.0
0,5
0,1
1766
0.0
0,5
0,3
5625
0.0
0,5
17,4
141
0.0
0,3
1,7
8.7 Příloha 7: Výstupy Aggregate report z kapitoly 4.4
Přílohy
Tomáš Pobuda
100
100
100
100
10
520
Vytvoření souboru
Uložení souboru
Výběr dodavatele
Uložit
Odhlášení
TOTAL
10
100
100
100
100
100
10
520
Přihlášení
Vytvoření souboru
Uložení souboru
Výběr dodavatele
Uložit
Odhlášení
TOTAL
Label
1210
293
2099
604
1782
357
1337
826
734
63
1438
141
1234
109
687
672
3250
2344
5141
2235
3562
1391
3438
2625
2878
42
3576
284
6796
457
3689
1576
641
47
1078
125
6777
109
594
812
9514
63
12106
500
9685
1062
10899
5043
2671
3250
31
31
5043
5452
5249
31
31
14137
63
407 13601
62
2889 14137
31
218 12841
406
Max
6219
2344
266 6219
62
672 4922
31
235 5063
390 2625
# Samples Average Median 90% Line Min
100
5 MB – databáze
10
1,9
0,2
0,4
0,4
0,4
0,4
0,4
0,2
- 107 -
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1,5
0,2
0,3
0,3
0,3
0,3
0,3
0,2
Error % Throughput (sek.)
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
30,6
1,3
14,3
0,2
0,1
0,0
17,1
6,5
KB/sec
45,7
1,3
22,1
0,2
0,1
0,0
25,5
9,0
# Samples Average Median 90% Line Min Max Error % Throughput (sek.) KB/sec
Přihlášení
Label
1 MB – databáze
Přílohy
Tomáš Pobuda
100
100
100
100
100
10
520
Vytvoření souboru
Uložení souboru
Výběr dodavatele
Uložit
Odhlášení
TOTAL
6354
129
5971
977
17531
284
7823
4421
641
62
1609
110
16969
93
484
1891
20297
469
18891
1281
27516
672
23860
16484
3265
15234
31
31
38360
469
360 25656
62
4828 37344
32
187 38360
344 16484
Max
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1,0
0,1
0,2
0,2
0,2
0,2
0,2
0,2
Error % Throughput (sek.)
10
100
100
100
100
100
10
520
Vytvoření souboru
Uložení souboru
Výběr dodavatele
Uložit
Odhlášení
TOTAL
496
45
1297
210
357
118
458
1329
235
31
1015
125
172
79
375
1079
1203
78
2438
344
671
203
750
2625
2312
2922
797
16
16
5531
78
375 5531
62
78
46
203 2218
500 2625
- 108 -
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
2,3
0,2
0,5
0,5
0,5
0,5
0,5
0,2
# Samples Average Median 90% Line Min Max Error % Throughput (sek.)
Přihlášení
Label
50 KB – souborový systém
10
Přihlášení
Label
10 MB – databáze
Přílohy
36,6
1,6
18,5
0,3
0,1
0,0
20,8
3,1
KB/sec
13,9
0,8
6,1
0,1
0,1
0,0
8,0
2,9
KB/sec
Tomáš Pobuda
100
100
100
100
100
10
520
Vytvoření souboru
Uložení souboru
Výběr dodavatele
Uložit
Odhlášení
TOTAL
462
42
1175
174
396
107
496
499
235
32
1016
109
250
78
344
468
1172
78
2000
328
828
156
891
906
906
1375
2844
31
31
5125
78
218 5125
62
156 3156
32
188 3078
359
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
2,4
0,3
0,5
0,5
0,5
0,5
0,5
0,2
39,8
1,7
20,2
0,3
0,1
0,0
22,0
3,1
10
100
100
100
100
100
10
520
Vytvoření souboru
Uložení souboru
Výběr dodavatele
Uložit
Odhlášení
TOTAL
394
51
871
139
480
76
432
434
312
47
829
109
422
78
312
375
906
78
1328
234
719
125
672
797
797
172
734
31
31
2469
78
234 2469
62
297 1532
31
187 2282
359
- 109 -
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
2,3
0,2
0,5
0,5
0,5
0,5
0,5
0,2
34,3
1,5
15,9
0,3
0,1
0,0
20,4
3,1
Přihlášení
Label
1 MB – souborový systém
10
Přihlášení
Label
500 KB – souborový systém
Přílohy
Tomáš Pobuda
100
100
100
100
100
10
520
Vytvoření souboru
Uložení souboru
Výběr dodavatele
Uložit
Odhlášení
TOTAL
964
56
1468
188
2159
110
1015
695
485
62
1188
156
1891
94
531
437
2688
110
3094
375
3265
188
2688
1984
10
100
100
100
100
100
10
520
Vytvoření souboru
Uložení souboru
Výběr dodavatele
Uložit
Odhlášení
TOTAL
1782
60
2278
350
5107
143
1281
1015
563
47
1515
157
4453
94
531
703
5235
110
5375
782
9250
296
3719
2453
484
844
31
31
1016
5297
2453
31
31
266
62
12359
110
9797
2703
2031 12359
31
203
375
Max
4328
110
234 3812
62
1000 4328
31
203 3484
2,1
0,2
0,4
0,4
0,4
0,4
0,4
0,2
34,6
1,4
16,2
0,2
0,1
0,0
20,1
4,3
- 110 -
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1,8
0,2
0,4
0,4
0,4
0,4
0,4
0,2
32,6
1,0
15,1
0,2
0,1
0,0
18,5
5,3
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
359 1984
Přihlášení
Label
10
Přihlášení
Label
Přílohy
Tomáš Pobuda
0
50kb
1000
2000
3000
4000
5000
Uložit
Přihlášení
Výběr dodavatele
500kb
Soubory ukládány do DB
Odhlášení
Vytvoření souboru
- 111 -
1MB
8.8 Příloha 8: Grafy mediánu odezvy pro uživatele – kapitola 4.4
Přílohy
ms
Uložení souboru
5MB
hodnoty
6777
a
16969 jsou mimo
zobrazení
10MB
Tomáš Pobuda
0
50kb
1000
2000
3000
4000
5000
Přílohy
ms
Uložit
Přihlášení
Výběr dodavatele
500kb
Soubory ukládány na FS
Odhlášení
Vytvoření souboru
- 112 -
1MB
Uložení souboru
5MB
10MB
Tomáš Pobuda

3 Ladění databázového systému Oracle

Transkript

Podobné dokumenty

gloriapolo

o Debianu

Automatic Storage Management (ASM)

Příklad

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE Efektivní datové

Informace - Česká neurologická společnost

Počáteční nastavení / info

Ebook Oracle DBA - Tomas Solar Consulting

4 / Národní infrastruktura prostorových dat 20 / Funkce malých

Technický manuál - Státní pokladna

Zátěžové testování informačních systémů a aplikací

GeoPlan - geometrplan.cz

Healtcheck databáze ORCL běžící na serveru db.tomas