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?
    Systémový katalog
    Struktury, ve kterých jsou uloženy informace o dané databázi, případně databázovém serveru. Někdy je možné se z anglického Data Dictionary setkat s pojmem datový slovník.

    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 XV. – rychlejší aplikace i bez změn dotazů poprvé


    [Tipy - triky] - V několika následujících pokračováních seriálu věnovaného praktickým tipům a trikům pro databázovou platformu Oracle Database se zaměříme na možnosti 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.

    Přemýšleli jsme, jestli má smysl psát článek o tématu, o kterém toho bylo již tolik napsáno. Každý kdo se alespoň trochu zabývá vývojem databázových aplikací již musel číst některý ze skvělých textů třeba od Toma Kytea – a musel se tak již dovědět, jak efektivně pracovat s databázovými spojeními a transakcemi, jak využívat vázané proměnné nebo postupy hromadného zpracování dat, aby dosáhl vyššího výkonu.

    Jenže proč se pak pořád setkáváme s aplikacemi, které tyto otázky neřeší ani zdaleka efektivně? Možná si prostě v každodenní praxi neuvědomujeme, jak zásadní vliv na výkon mohou tyto snadné postupy mít. Možná pomůže, když si úspory ukážeme a vyčíslíme na jednoduché ukázce.

    Ve třech pokračováních našeho seriálu si postupně ukážeme, jak se při použití stejného SQL i stejného datového modelu může lišit výkon operace podle způsobu práce s transakcemi a dotazem jako takovým. Ukázky kódu jsou v Javě, ale stejné mechanismy fungují v .NET, C++, PHP nebo jiných prostředích. V rámci testu budeme vkládat 100 000 záznamů do tabulky s následující strukturou:

    CREATE TABLE mojeTab(
      datum date, 
      popis varchar2(100), 
      dalsidata varchar2(200));
    

    Do sloupečku POPIS budeme vkládat měnící se text, ostatní sloupečky nám slouží pro dosažení reálnější velikosti záznamu, do DATUM budeme vkládat aktuální datum a čas, DALSIDATA budeme plnit konstantním řetězcem 200 znaků.

    Je zřejmé, že konkrétní zrychlení závisí na řadě faktorů a výsledky ve vašich aplikacích se mohou významně lišit. I tak doufáme,0že pro vás osmdesátinásobné zvýšení výkonu, které v této konkrétní úloze postupně dosáhneme, bude zajímavé. Ostatně ukážeme si, že zkrácení doby zpracování není jediným efektem. Postupně se nám významně podaří snížit jak počet čtecích a zápisových operací, které musí server provést, tak i objem síťové komunikace i zátěž procesoru. Naše aplikace tak možná ve výsledku vystačí s levnějším diskovým polem a serverem s menším počtem procesorů.

    1. Základ – Skládání SQL dotazů v textu, častý commit
    Jako základ si vezmeme bohužel často používaný postup, kdy jsou hodnoty proměnných přímo vkládány do textu dotazu, objekt Statement je vytvářen pro každý příkaz znovu a po každém příkazu následuje Commit – ať již explicitní nebo autocommit. Výchozí kód tedy vypadá takto:

    void zaklad(Connection conn, String dalsidata) throws SQLException {            
      Statement stmt;
      String sql, popis;
      for(int recNo=0;recNo<100000;recNo++) {
        stmt=conn.createStatement();
        popis="Muj popis c." + recNo;
        sql="INSERT INTO mojeTab (datum,popis,dalsidata) "
          + "VALUES(SYSDATE,'" + popis + "','"+dalsidata+"')";
        stmt.execute(sql);
        stmt.close();
        conn.commit();
      }
    }           
    

    Vložení 100 000 záznamů trvalo 168 sekund. Nebyl přitom velký rozdíl mezi explicitním commitováním, jak je uvedeno v příkladu, nebo použitím autocommit. Ze sebraných provozních statistik sice vyplývá, že zapnutí autocommitu zmenší na polovinu množství zpráv předávaných z klienta na server, ale výsledný čas se zkrátil jen o jednotky procent. Rozdíl by nejspíš byl vyšší, pokud bychom měli mezi klientem a serverem síťové spojení s vyšší latencí.

    Mimochodem ještě významně horší výsledek dosáhneme, pokud bychom rezignovali na opakované použití stejného spojení a vytvářeli si nové spojení pro každý Insert – v tom případě by doba zpracování vzrostla zhruba na desetinásobek. Vytvářet spojení ve smyčce nám všem určitě přijde jako nesmysl, ale kolik webových aplikací vytváří nové spojení na začátku každé stránky a na jejím konci zase spojení uzavírá, místo aby používaly connection pool?

    2. Commitovat jen, když je to třeba
    Jednou z možností další optimalizace je snížení počtu commitů. Otázka jak často používat Commit je stará jak lidstvo... ehm, vlastně... databáze samy. Častý Commit zajišťuje okamžitou viditelnost změn pro ostatní spojení. Navíc krátké transakce znamenají i krátkou dobu držení zámků a zkracují tak případné vzájemné blokování transakcí.

    Jenže každý Commit na druhou stranu zvyšuje objem dat, která je třeba zapsat do redo logů a undo tablespace. Navíc vynucuje okamžitý zápis redo dat z log bufferu na disk do redo log souborů, aby byla zajištěna trvalost transakce. Jde tedy výkonově o poměrně drahou operaci.

    Častý Commit sice zvyšuje objem redo a undo dat, které daná transakce generuje, což znamená více zápisových operací, málo častý Commit a tudíž dlouhé transakce však naopak prodlužují dobu, po kterou musí Oracle udržovat v undo tablespace informace pro případný rollback. Zápisových operací je tak méně, ale undo tablespace musí být obvykle větší.

    Jak se tedy změní výkon naší aplikace, pokud operaci Commit "vysuneme" ven ze smyčky a provedeme ji pouze jedenkrát a to na konci procedury?

    void commitJednou(Connection conn, String dalsidata) throws SQLException {            
      Statement stmt;
      String sql, popis;
      for(int recNo=0;recNo<100000;recNo++) {
        stmt=conn.createStatement();
        popis="Muj popis c." + recNo;
        sql="INSERT INTO mojeTab (datum,popis,dalsidata) "
          + "VALUES(SYSDATE,'" + popis + "','"+dalsidata+"')";
        stmt.execute(sql);
        stmt.close();
      }
      conn.commit();
    }           
    

    Nyní již ke vložení 100.000 záznamů stačilo pouhých 106 sekund. Vynecháním opakovaných Commitu jsme tedy uspořili zhruba třetinu času. Úspora se projevila i v objemu čtených a měněných dat.

    Statistika1. základ2. commit 1xÚspora
    Čas a CPU
    Dosažený čas [s]16710537 %
    CPU used by this session (spotřeba CPU) [s]1038616 %
    Čtení a zápis dat
    Session logical reads (logické čtení) [počet operací]71535842692840 %
    Db block changes (změny datových bloků) [počet operací]42181921928248 %
    Redo size (objem dat zapsaný do redo logů) [bajty]757490264822163236 %
    Undo change vector size (objem dat zapsaný do undo tblspc.) [bajty]12669468640198449 %
    Optimalizace dotazů
    Parse time elapsed (doba parsování dotazů) [s]80748 %

    Tabulka ukazuje očekávané snížení objemu dat zapisovaných do redo logů (redo size) o třetinu a dat zapisovaných do undo tablespace na polovinu. Celkové množství čtecích a zápisových operací pokleslo také na polovinu. Můžeme si sice říkat, že čtení (session logical reads) bude ve většině případů probíhat z cache, a že tedy jde tedy o relativně levnou operací. Avšak i málo náročná operace opakovaná tolikrát významně zatíží serveru. Mimochodem již snížení frekvence commitování na každých 100 či 1.000 záznamů vedlo k velmi podobným výsledkům.

    Ze slibovaného osmdesátinásobného zrychlení jsme ušli jen kousek – zrychlili jsme operaci o 37%, v dalších dílech tedy budeme mít ještě hodně práce. Kde ušetřit další čas nám může napovědět poslední sekce z tabulky vybraných statistik. Z těch celkem 106 sekund běhu operace zabralo celých 74 sekund parsování dotazů, tedy rozbor a optimalizace dotazu (statistika parse time elapsed). Pouze zbylých 32 sekund zabralo vlastní uložení dat. Musí opravdu databázový server opakovaně parsovat každý z těch 100 000 příkazů, které se liší jen vkládanými hodnotami? V příštím díle seriálu zkusíme serveru ušetřit tuto práci díky použití vázaných proměnných a uvidíte, že rázem budeme celkovou dobu zpracování měřit ve velmi malých desítkách vteřin.

    Metodika provádění testů
    Testy probíhaly na notebooku s dualcore procesorem, kde byl současně provozován databázový server Oracle Database 10g Release 2 Express Edition i testovací Java aplikace. Java aplikace byla spouštěna přímo z vývojového prostředí Oracle JDeveloper. Dosažený čas byl měřen v klientské aplikaci. Údaje o spotřebovaných zdrojích byly získány prostředky databáze Oracle - jako rozdíl snímků ze systémového pohledu v$sesstat získaných před započetím a po ukončení každého testu. Každý test byl prováděn 5x po sobě. Uváděné hodnoty jsou pak průměrem všech spuštění testu.

    Před každým spuštěním libovolného testu byla zrušena a znovu vytvořena cílová tabulka, čímž současně došlo ke zrušení všech nacachovaných exekučních plánů k dotazům nad touto tabulkou.

    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 XVI. – rychlejší aplikace i bez změn dotazů podruhé (03.02.2009)
    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ářů: 5 | 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