Dnes: 17. prosince 2017    | Registrace | Hledáme | Redakce | Info | Testy | Školení | Ocenění | Nápověda | Čtenář: nepřihlášen

Rychlé odkazy
  • Hlavní stránka
  • Seznam rubrik
  • Ankety
  • Editoriály
  • TOP 15
  • KONFERENCE 2008
  • KONFERENCE 2007
  • KONFERENCE 2006
  • KONFERENCE 2005
  • KONFERENCE 2004
  • Sborník
  • Testy
  • Virtuální školení
  • Personalizace


  • Hledáte práci?
    Hledáme redaktora - pojďte s námi tvořit Databázový svět!

    Vyhledávání

    Hledej
    na Databázovém světě!



    Rozšířené vyhledávání

    Rubriky
    Aktuality
    Bezpečnost
    Business
    Česká scéna
    Datové sklady
    Dokumentace
    Dotazovací jazyky
    Hardware
    Historie
    Komentáře
    Literatura
    Metodologie
    Nondb
    Open Source
    Poradna
    Produkty
    Případové studie
    Redakce
    Rozhovory
    Standardy
    Technologie
    Tipy - triky
    Tiskové zprávy
    Vývoj
    Vývojové nástroje
    Zajímavosti

    Co je to?
    Datový sklad
    Tento pojem poprvé formuloval koncem 80. let William Inmon jako strategii přístupu k datům určeným pro rozsáhlé analýzy. V případě datového skladu hovoříme o historických, časově rozlišených, agregovaných, průběžně rozšiřovaných datech uspořádaných pro podporu potřeb managementu.

    Akce
    Dynamická Datová Centra
    - na semináři se seznámíte s komplexním řešením a koncepcí Dynamických Datových Center od Fujitsu Siemens Computers se speciálním důrazem na řešení FlexFrame.

    Textová inzerce
    IBPhoenix - Vše o InterBase a Firebirdu.

    Smějete se rádi? - Pak je pro vás Vtipník to pravé!

    Prodejce reklamy - Hledáme schopného prodejce reklamního prostoru, možnost i externí spolupráce.

    Přihlášený čtenář
    Nepřihlášený čtenář

    O portálu
    Databázový svět
    ISSN: 1213-5933

    Web je optimalizován pro rozlišení 1024x768, nicméně kromě větších rozlišení podporujeme i 800x600. Podrobnosti najdete zde.

    Chcete-li mít kdykoliv možnost zkontrolovat obsah našeho portálu, můžete využít podporu rss. Podrobnosti najdete zde.
    Tipy a triky pro Oracle XVI. – rychlejší aplikace i bez změn dotazů podruhé


    [Aktuality] - V aktuálních pokračováních seriálu věnovaného praktickým tipům a trikům pro databázovou platformu Oracle Database se věnujeme možnostem zvýšení výkonu databázových aplikací. Cílem seriálu je přinášet vám nejen praktické informace, které vám mohou pomoci při správě či vývoji na této platformě, ale také upozorňovat na zajímavé funkce. O kterých možná ani nevíte, že existují.



    I když ladění výkonu evokuje často ladění SQL dotazů, jedním z častých důvodů výkonnostních problémů databázových aplikací je způsob práce se spojením, transakcemi a vlastními příkazy na straně aplikace. Ukážeme si, že drobná změna v této oblasti může znamenat třeba i 80x vyšší výkon.

    * Už jste se registrovali na Prague PostgreSQL Developers' Day 2009? *

    V minulém pokračování jsme si na vzorovém příkladu vkládání 100 000 záznamů ukázali, jak velkou zátěž může pro databázový server znamenat zbytečně časté potvrzování. Dobu zpracování této operace jsme snížili ze 167 na 105 sekund, tedy o třetinu. Ke slibovanému osmdesátinásobnému zrychlení nám chybí ještě dva kroky. V závěru předchozího dílu jsme zjistili, že parsování (rozbor a optimalizace) dotazu zabralo serveru celých 74 ze zmiňovaných 105 sekund. Svou pozornost dnes zaměříme právě na minimalizaci času parsování.

    3. Úspora při použití vázaných proměnných
    V dalším kroku se budeme snažit uspořit práci, kterou musí vykonat databázový optimalizátor. Cesta vede přes používání dotazů s vázanými proměnnými a ideálně i přes opakované využití stejného objektu PreparedStatement v aplikaci. Databázový server tak v jednotlivých voláních dostává stále stejný příkaz (text SQL). Vedle vlastního SQL však dostane ještě sadu parametrů, se kterými má dotaz provést.

    void vazaneProm(Connection conn, String dalsidata) 
      throws SQLException {            
      PreparedStatement stmt;
      String popis;
      stmt=conn.prepareStatement(
        "INSERT INTO mojeTab (datum,popis,dalsidata) VALUES(SYSDATE,?,?)");
        for(int recNo=0;recNo<100000;recNo++) {
          popis="Muj popis c." +recNo;
          stmt.setString(1,popis);                
          stmt.setString(2,dalsidata);
          stmt.execute();
        }
        stmt.close();
        conn.commit();
    } 
    

    Doba běhu klesla na 19 sekund, došlo tedy zhruba k pětinásobnému zrychlení. Tím, že použijete stejný objekt PreparedStatement šetříte nejen zdroje na úrovni vaší aplikace, ale též databázového serveru. Aplikace tímto postupem explicitně databázovému serveru přikazuje použít dříve vytvořený kursor, pro který byl prováděcí plán již sestaven. Server tak s výjimkou prvního volání nemusí provádět optimalizaci dotazu.

    Výhody opakovaného použití PreparedStatement s vázanými proměnnými v rámci jednoho spojení jsou známé. Může ale tato technika mít nějaký význam i v případech, kdy dotaz kladou různí klienti a objekt PreparedStatement proto nelze sdílet?

    To si můžete vyzkoušet, pokud v předchozím kódu přesunete volání stmt=conn.prepareStatement(...) a stmt.close() dovnitř cyklu. Tuto variantu budeme dále označovat jako 3b. Doba běhu sice vzroste z 19 na 27 sekund, ale pořád je zhruba tříkrát kratší, než ve variantě bez vázaných proměnných. Jak je to možné? Vždyť aplikace využívá pokaždé jiný cursor?

    Oracle cachuje již dříve vytvořené exekuční plány v části paměti SGA zvané Shared Pool. Pokud aplikace položí SQL dotaz, jehož text přesně odpovídá již dříve optimalizovanému dotazu, neprovádí se plná optimalizace (tzv. Hard Parse), ale vyhledá a použije se již dříve nacachovaný exekuční plán (v operaci nazývané Soft Parse). To je samozřejmě výrazně méně náročné. Je přitom jedno, zda byl dotaz položen v rámci stejného spojení, nebo v různých spojeních.

    Důležité je, aby se celý text dotazu nezměnil. Jakmile dojde ke změně textu, i když například jen nahrazením jednoho literálu druhým tak jak jsme to dělali v předchozím díle, optimalizátor existující exekuční plán nenajde a musí provést kompletní optimalizaci. Použití vázaných proměnných má tedy v Oracle význam nejen tam, kde spouštíte opakovaně stejný dotaz v rámci jednoho spojení, ale i tam, kde stejný dotaz spouští opakovaně různí uživatelé.

    Statistika2. commit 1x3a. sdílený PSÚspora3b. bez sdílení PSÚspora
    Čas a CPU
    Dosažený čas [s]1051982 %2675 %
    CPU used by this session (spotřeba CPU) [s]86593 %1088 %
    Optimalizace dotazů
    Parse time elapsed (Doba parsování dotazů) [s]740100 %0,899 %
    Opened cursors cumulative (Otevřené kurzory) [počet]100 08992100 %100 0900 %
    Parse count (hard) (Úplná optimalizace dotazů) [počet]100 0001100 %1100 %
    Parse count (total) (Optimalizace dotazů celkem) [počet]100 08992100 %100 0900 %
    Čtení a zápis dat
    Session logical reads (Logické čtení) [počet operací]426 928130 27469 %427 0260 %

    V obou případech – jak při sdílení objektu PreparedStatement (3a), tak i při jeho opakovaném vytváření (3b) pokleslo významně zatížení procesoru (CPU used by this session). Při sdílení objektu PreparedStatement (3a) server optimalizuje dotaz jen jedenkrát (parse count (hard)) a délka trvání této operace (parse time elapsed) poklesla pod setinu sekundy a není možné provést rozumné měření.

    Ve variantě, kdy vytváříme objekt uvnitř smyčky (3b), dochází k parsování pro každý záznam, jak ukazuje statistika parse count (total). Z rozdílu mezi statistikami parse count (total) a parse count (hard) je však vidět, že se jedná pouze o méně nákladný Soft Parse – vyhledání nacachovaného exekučního plánu.

    Cca 90 operací Soft Parse, o které tato statistika ve všech případech překračuje očekávanou hodnotu, jde z velké části na interní operace, které musí server provést v rámci zpracování našeho dotazu. Cca 10 operací z toho pak představují dotazy, které mi sloužily k uložení výkonnostních statistik během testu.

    Ukázali jsme si vliv použití vázaných proměnných na výkon vaší aplikace. Jejich použití však hraje důležitou roli také v zabezpečení vaší aplikace. Na rozdíl od spojování SQL v textu totiž používáním vázaných proměnných nevystavujete svou aplikaci nebezpečí SQLInjection.

    Ze slibovaného osmdesátinásobného zrychlení jsme se zatím dostali na zhruba osmi až devítinásobné zrychlení. Máme-li splnit svůj cíl, musíme naši operaci zrychlit ještě desetkrát. V závěrečném díle toho dosáhneme využitím hromadného zpracování dat.

    Dnešní ukázky si můžete vyzkoušet na libovolné edici Oracle Database, včetně volně dostupné Express Edition. V případě potřeby si Oracle Database můžete stáhnout na webu společnosti Oracle.

    O autorovi
    David Krch (*1976) pracuje ve společnosti Oracle Czech na pozici Technology Sales Consultant. Vystudoval obor Informační technologie na Vysoké škole ekonomické. Od roku 2001 působí ve firmě Oracle Czech na pozici Technology Sales Consultant, ve které je zodpovědný za podporu prodeje technologií Oracle. Z počátku se zaměřoval na portálová řešení. Od roku 2002 se specializuje na podporu prodeje databáze Oracle a témata související se zajištěním provozu, jako je bezpečnost a vysoká dostupnost. Jako nezávislý vývojář vyvíjel na zakázku databázové aplikace s využitím desktopových databází.

    Související články:
    Tipy a triky pro Oracle XV. – rychlejší aplikace i bez změn dotazů poprvé (21.11.2008)
    Tipy a triky pro Oracle XIV. – datová komprese (21.10.2008)
    Tipy a triky pro Oracle XIII. – externí data rychle (17.09.2008)
    Tipy a triky pro Oracle XII. – Jak na řízení přístupu na úrovni záznamů? (15.04.2008)
    Tipy a triky pro Oracle XI. – Error Logging Tables (12.11.2007)
    Tipy a triky pro Oracle X. – bojujete s češtinou v Oracle podruhé? (14.05.2007)
    Tipy a triky pro Oracle IX. – bojujete s češtinou v Oracle? (06.02.2007)
    Tipy a triky pro Oracle VIII. – jak na přenosy velkých dat podruhé (03.01.2007)
    Tipy a triky pro Oracle VII. – jak na přenosy velkých dat poprvé (21.11.2006)
    Tipy a triky pro Oracle VI. – trochu jiné triggery (25.09.2006)
    Tipy a triky pro Oracle V. – změna dat v pohledu? (06.09.2006)
    Tipy a triky pro Oracle IV. – analytické funkce podruhé (14.08.2006)
    Tipy a triky pro Oracle III. – analytické funkce poprvé (19.07.2006)
    Tipy a triky pro Oracle II. – jak na hierarchické struktury? (07.06.2006)
    Tipy a triky pro Oracle I. – jak na automatické přidělování ID? (05.05.2006)

    ( Celý článek! | Autor: David Krch | Počet komentářů: 1 | Přidat komentář | Informační e-mailVytisknout článek )

    Vyhledávání
     

    Anketa
    Kolik ročně utratíte za dovolené?

    Nic 
     (1507 hl.)
    Do 1 000,- Kč 
     (1044 hl.)
    Do 10 000,- Kč 
     (978 hl.)
    Do 25 000,- Kč 
     (1347 hl.)
    Do 50 000,- Kč 
     (994 hl.)
    Do 75 000,- Kč 
     (1151 hl.)
    Více než 75 000,- Kč 
     (993 hl.)

    Celkem hlasovalo: 8014


    Poslední komentáře
    frontierd@126.com
    frontierd@126.com
    frontierd@126.com
    c
    http://www.coachoutl

    Newsletter
    Přihlaste si nezávazně - i bez registrace - odběr informačního newsletteru. Podrobné informace najdete zde.

    Emailová adresa:


    Kalendář
    <<  Prosinec  >>
    PoÚtStČtSoNe
        123
    45678910
    11121314151617
    18192021222324
    25262728293031

    Redakci připojuje


    Nejčtenější

    Databáze je prázdná!


    Nejvíce komentářů

    Databáze je prázdná!


    Reklama






    Nenechte si ujít články na dalších webech




    Na této stránce použité názvy programových produktů, firem apod. mohou být ochrannými známkami
    nebo registrovanými ochrannými známkami příslušných vlastníků.

    Databázový svět | dfKlub - digitální fotografie | Vtipník - vtipy přímo k Vám | Reminder - přestaňte zapomínat | Databázový svět

    Copyright (c) 2004 AVRE Publishing, spol. s r.o. Všechna práva vyhrazena