Udělejte si precizní aplikaci v Oracle

Testovali jsme optimalizační software Precise/SQL 2.5. Schopnosti produktu se nejlépe testují na reálném příkladě. V první části recenze se dozvíte něco o produktu a v druhé části se tedy pustíme rovnou do praxe.
Tento článek vyšel v šestém čísle časopisu Connect!

Ladislav Buřita, Vladimír Tučník

Jak Precise/SQL funguje

Precise/SQL je nástrojem spadajícím do skupiny produktů Precise/Enterprise. Zajišťuje aktivní monitorování, analýzy a ladění rozsáhlých aplikací v prostředí Oracle. Identifikuje problémy v databázi a pomáhá je řešit. Správcům databází nabízí komplexní pohled na výkonnost aplikace, k tomu snímá, měří a koreluje parametry výkonu ze všech kritických systémových komponent.

Ke zvýšení výkonu aplikace (po zjištění a analýze problémů) vede řada cest. Lze upravit SQL příkazy (Precise/SQL nabídne sadu alternativ), změnit přístupovou cestu k objektům databáze při vykonání SQL příkazu tím, že ji „vnutíme“ optimalizátoru Oracle, zobrazit relevantní indexy pro vyšší přístupovou rychlost k datům nebo například navrhnout vytvoření indexu nového.

Korekce výkonnosti zjištěných problémů však může na druhé straně způsobit problémy kdekoli jinde v aplikaci. Proto před vlastním provedením změn umožňuje Precise/SQL simulovat jejich důsledky a verifikovat je. Podle podkladů firmy Precise, je Precise/SQL jediným řešením, které snímá data o výkonnosti systému, aniž by došlo k zatížení zdrojů Oracle. Dosahuje to přímým sdílením globální systémové paměťové oblasti. To se nám nepodařilo ani potvrdit, ani vyvrátit.

Dlouhodobé trendy výkonnosti systému jsou predikovány s využitím datového skladu Performance Warehouse, který si Precise vytváří. Poskytuje zdroj pro analýzu trendů výkonu, plánování systémových kapacit a generování vysvětlujících zpráv k opatřením pro plynulý rozvoj systému.

Testovací prostředí, instalace produktu a jeho uživatelské rozhraní

Produkt jsme testovali se systémem řízení báze dat (SŘBD) Oracle/Enterprise Edition verze 8.1.7. na Windows NT 4.0 Serveru se Service Packem 6. Instalace produktu proběhla bez problémů během asi 90 minut.

Uživatelské rozhraní aplikace je poměrně jednoduché, ale přitom dostatečně komfortní. Pracovní plocha (viz obr. 1 až 4) je rozdělena na tři hlavní části. V levé části se přepínají jednotlivé pracovní plochy, z nichž každá nabízí jiný pohled na výsledky monitorování databáze.

V prostřední části obrazovky je pak uživatelem modifikovatelný hierarchický pohled na sledovaná data. Právě tato možnost libovolně si přizpůsobit zájmovou oblast nám připadala jako nejsilnější zbraň Precise/SQL. V pravé části obrazovky se pak zobrazují detailní informace k aktuálně vybrané situaci z hierarchického pohledu.

Ukázkové případy a jejich řešení

Paleta funkcí, které program Precise/SQL nabízí, je opravdu široká. Svědčí o tom také fakt, že za týden, po který jsme měli software pro recenzi k dispozici, jsme zvládli projít pouze základní možnosti této aplikace. Celý postup testování by se dal rozčlenit na oblasti, které víceméně pokrývají funkční rozsah produktu:
  • Ladění SQL příkazů a kódu PL/SQL, které spotřebují příliš mnoho systémových zdrojů.
  • Odhalování a řešení problémů uzamčených objektů a ladění problémů přístupu k datům.
Nejprve je nutno zdůraznit výchozí požadavky. Pokud nejste zběhlí v používání jazyka SQL, nerozumíte dokonale problematice databází a správě Oracle, je vám Precise/SQL téměř k ničemu. Problém sice jste schopni lokalizovat, můžete získat návrhy na řešení a tyto ověřit, ale musíte je až na výjimky nakonec vyřešit sami v jiném produktu (např. v Enterprise Manageru Oracle), a to na základě podkladů získaných z Precise/SQL. Nicméně právě pro takové odborníky je produkt určen. Zcela jistě si jej nebudou kupovat lidé, kteří pracují s databázovými aplikacemi jako koncoví uživatelé. Produkt je určen především pro vývojáře a správce databázových aplikací (v prostředí Oracle).

Ladění SQL příkazů

Tento příklad využití dává poměrně dobrý přehled o většině funkcí, které program nabízí. Na následujícím popisu jsme se snažili podrobně ilustrovat možnosti využití programu. Ladění SQL příkazů je svázáno s pracovní plochou „Recent Activity“, která obsahuje informace o běhu aplikace, získané z Oracle.

Informace jsou zachytávány speciálním programem, kterému se říká „Collector Agent“. Doba, ve které data chceme zachytávat, se dá jednoduše nastavit (v našem případě se jednalo o posledních 10 hodin). Veškeré informace, které se během této doby nasnímají (a těch je na frekventované databázi opravdu hodně), jsou pak sumarizovány do menších časových celků (dle našeho nastavení 2 hodiny), aby se v nich dalo přehledně orientovat. SQL příkazy mají přiřazen jednoznačný identifikátor, sestávající ze čtveřice pětimístných čísel, a sledovaný SQL příkaz, skrytý pod tímto identifikátorem, lze podrobněji zobrazit a analyzovat.

Pomocí informací z „Recent Activity“ můžeme identifikovat SQL příkazy, které čerpají velký objem systémových zdrojů. U všech SQL příkazů lze snadno graficky výsledky vyjádřit. Například je možné zjistit, že příkaz 00323.48958.47220.42692 využívá CPU během dvouhodinové periody měření celkem 44 minut a 50 sekund, což je jistě hodně (viz obr. 1) a svědčí to o nějakém problému.

Poté, co výše uvedeným způsobem identifikujete jádro problému, máte na výběr jednu ze dvou možností. Buď SQL příkaz přepíšete do jiné formy, ve které bude sice vykonávat totéž, ale s podstatně menší spotřebou systémových prostředků, nebo změníte strukturu databáze tak, aby příkaz mohl pracovat efektivněji (např. změnou nebo přidáním indexu).

V prvním případě nabízí Precise/SQL možnost automatického vygenerování alternativních forem SQL příkazu. Precise/SQL ale nezůstává pouze u generování alternativ. Každou alternativu ohodnotí a je schopen vypsat podrobné informace o jejím výkonu, včetně odhadované doby zpracování. To dává vývojářům do rukou mocný nástroj, který umožňuje všechny problematické příkazy nejprve testovat a pak najít jejich nejvhodnější formu. Tím se výrazně sníží doba nutná k ladění aplikace.

Na druhou možnost, spojenou se změnou struktury databáze, se podíváme blíže, protože zde jsou přehledně vidět hlavní přínosy Precise/SQL. Vezměme například příkaz dle obr. 1. Z něho je patrné, že příkaz je velkým konzumentem výkonu procesoru. Je však potřeba zjistit, která konkrétní část příkazu problém způsobuje, a proto příkaz dále analyzujeme. U každého SQL příkazu je v Precise/SQL možno vypsat jeho tzv. „execution plan“, což by se do češtiny dalo přeložit jako „plán provádění“. Jinými slovy to znamená, že Precise/SQL vypíše jednotlivé kroky, ve kterých zpracování SQL příkazu probíhá, a ke každému kroku poskytne stručné vysvětlení. Odhadne náročnost provádění každého kroku a vypíše i další informace, jako je předpokládaný počet procházených záznamů atd.

Již ze způsobu provádění příkazu lze ve velké většině případů odvodit možný zdroj problému. Někdy je ovšem nutno znát podrobnější informace o příkazu, a to například tím, že si k danému příkazu necháme vypsat indexy (viz obr. 2). Precise/SQL během zobrazování indexů zpřehledňuje práci tím, že v příkazu zobrazeném v pravém okně zvýrazňuje podtržením části kódu, které využívají index, se kterým zrovna v levém okně pracujeme. I tyto drobné pomůcky dle našeho názoru velmi usnadňují práci.

V našem případě bylo možno odvodit příčinu problému až z podrobného výpisu indexů, které jsou definovány v tabulce, se kterou příkaz pracuje. U každého indexu jsme si dále nechali vypsat sloupce tabulky, nad kterými je index definován. V podrobnosti různých detailních výpisů bychom mohli jít ještě dál, ale pro náš problém tato úroveň zpodrobnění stačila. Po analýze jednotlivých indexů jsme došli k závěru, že problém je způsoben nevhodnou definicí indexu EMPLOYEE_IND2. Druhé dva indexy v příkazu totiž vlastně nejsou využity.

Jak jsme vlastně přišli na to, kde je chyba? Nejprve jsme se museli zamyslet nad daným SQL příkazem a odůvodnit si, které indexy vlastně příkaz využívá. Částečně se to dá ukázat již z hierarchického pohledu v levém okně. Index EMPLOYEE_IND3 je zcela nevyužitý, protože ani na jeden sloupec, nad kterým je index definován, není v příkazu odkazováno.

Další index EMPLOYEE_IND1 není využíván, protože nad jeho sloupcem se provádí pouze operace projekce, nikoli restrikce. Poslední index, jak jsme již výše naznačili, je opravdu jádrem problému. Z hierarchického pohledu jsme zjistili, že první sloupec indexu MGR není dotazem využíván. Optimalizátor dotazů Oracle se zřejmě rozhodl index vůbec nevyužít na základě toho, že první sloupec indexu není v příkazu uplatněn. Je to vidět i ze způsobu provádění příkazu, kdy v daném kroku Oracle provádí „full scan“ (tj. prochází tabulku řádek po řádku). Tím se samozřejmě neúměrně zvyšuje časová náročnost provedení celého SQL příkazu.

Řešení problému se v našem případě zdá být poměrně jednoduché. Stačí prohodit pořadí sloupců v indexu (přesunout sloupec MGR na konec) a rázem by se výkon aplikace měl rapidně zlepšit. Ve složitější aplikaci však změna indexu nemusí vždy vyústit v optimální řešení a někdy je dokonce vhodnější nechat index nezměněn. Vždy je potřeba mít na paměti, že hlavní je celkový výkon aplikace. Tím, že zrychlíme jeden příkaz a výrazně zpomalíme další tři, si mnoho nepomůžeme.

I na tuto problematiku má Precise/SQL řešení, a tím je simulace změn. Precise/SQL umožňuje změnu ve struktuře databáze nejprve simulovat a zjistit její dopad na aplikaci. Teprve na základě výsledků simulace se můžete rozhodnout, zda danou změnu provedete. Dle našeho názoru je tato funkce opravdu velmi užitečná a maximálně usnadňuje ladění aplikace. Simulaci změn si můžeme ukázat i na našem případě. Budeme simulovat změnu v indexu EMPLOYEE_IND2. Přesuneme sloupec MGR na konec seznamu indexovaných sloupců. Precise/SQL v hierarchickém pohledu ukáže seznam SQL příkazů, které změna v indexu ovlivnila. Zároveň lze v pravém okně zobrazit grafický přehled o spotřebě systémových prostředků navrženými příkazy (viz obr. 3).

Z tohoto pohledu je zřejmé, že opravdu dojde ke katastrofické situaci. Je vidět, že další čtyři příkazy velmi zhoršily svůj výkon v důsledku změny analyzovaného indexu. V podrobném výpisu (viz obr. 4) je pak možno zjistit, kde je problém. Postupujeme analogicky s výše uvedeným postupem. V našem případě se problém vyřeší přidáním sloupce SAL do indexu.

Jaký je výsledný verdikt?

Po otestování produktu Precise/SQL můžeme jen potvrdit pozitivní první dojem. Je to mohutný a velmi účinný nástroj pro správu Oracle aplikací, predikování jejich vývoje i potenciálních problémů. Tím je možné učinit reálné provozní plánování rozsáhlých systémů v prostředí Oracle. Efektivní uplatnění Precise/SQL předpokládá dokonalou připravenost správy databáze a podrobnou znalost spravovaných aplikací. Za těchto podmínek je Precise/SQL skutečně precizní a tomu odpovídá i jeho cena.

Název produktu: Precise/SQL verze 2.5
Zapůjčil: OKsystem
Výrobce: Precise Software Solution, USA
Orientační cena: Windows NT/2000 Server (do 2 procesorů) 5 000 USD
Unix (do 2 procesorů) 10 000 USD
Web: www.precise.com, www.oksystem.cz

Doc. Ing. Ladislav Buřita, CSc. - pracuje jako vysokoškolský učitel se zaměřením na informační systémy na Vojenské akademii v Brně.

Ing. Vladimír Tučník - pracuje jako vysokoškolský učitel se zaměřením na databázové systémy na Vojenské akademii v Brně.

Diskuze (4) Další článek: Kauza Rambus - vyděrači skončils!

Témata článku: , , , , , , , , , , , , , , , , , , , , , ,