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 XI. – Error Logging Tables


    [Tipy - triky] - V jedenáctém pokračování seriálu věnovaného praktickým tipům a trikům pro databázovou platformu Oracle Database se podíváme na řízené zpracování chyb při provádění DML příkazů pomocí mechanismu Error Logging Tables. 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í.



    Když nechcete vylévat s vaničkou i dítě? Co s tím? Chyba při provádění DML příkazu znamená jeho kompletní odvolání (rollback). Co když ale nechcete, aby kvůli jednomu chybnému záznamu bylo zrušeno i zpracování dalšího tisíce bezchybných záznamů? Řešením je právě mechanismus Error Logging Tables.

    REKLAMA
    Už jste se přihlásili na Databázový svět 2007?

    Jednou z důležitých služeb, které vám databázový server poskytuje pro zajištění konzistence dat je atomicita zpracování jednotlivých DML příkazů. To znamená, že se daný DML příkaz buď provede celý, nebo se neprovede vůbec a data zůstanou v podobě jako před spuštěním příkazu. Dnes si ukážeme, jak lze v Oracle Database řešit případy, kdy vám toto chování nevyhovuje.

    Nejprve si na příkladu ukažme standardní chování – potřebujete vložit data z tabulky SRC do tabulky DEPARTMENTS v demo schématu HR. Nejprve si vytvoříme tabulku SRC:

    CREATE TABLE src(
      dept_id   NUMBER,
      dept_name VARCHAR2(100),
      mgr       NUMBER,
      loc       NUMBER);
    
    INSERT INTO src
             (dept_id, dept_name, mgr, loc)
           VALUES
             (990, 'Praha - vedeni pobocky', 100, 1800);
    
    INSERT INTO src
             (dept_id, dept_name, mgr, loc)
           VALUES
             (991, 'Praha - Vyroba kulickovych lozisek', 100, 1800);
    
    INSERT INTO src
             (dept_id, dept_name, mgr, loc)
           VALUES
             (111111, 'Praha - Uctarna', 100, 1800);
    
    INSERT INTO src
             (dept_id, dept_name, mgr, loc)
           VALUES
             (992, 'Praha - Prodej', 9100, 1800);
    
    INSERT INTO src
             (dept_id, dept_name, mgr, loc)
           VALUES
             (993, 'Praha - Sklad', 100, 1800);
    

    Nyní provedeme vložení dat ze SRC do DEPARTMENTS:

    INSERT INTO departments
             (department_id,department_name,
              manager_id,location_id)
             SELECT dept_id,dept_name,mgr,loc 
               FROM src;
    ERROR at line 3:
    ORA-12899: value too large for column "HR"."DEPARTMENTS"."DEPARTMENT_NAME"
    (actual: 34, maximum: 30)
    

    Příkaz skončí chybou, protože jeden ze vkládaných záznamů má název oddělení delší než je velikost pole v tabulce DEPARTMENTS. I když by pro některé záznamy proběhla operace bez problémů, v tabulce DEPARTMENTS se neobjeví žádný nový záznam.

    U takto krátké tabulky jednoduše zjistíte, že chybu způsobil druhý záznam (dept_id=991), jenže zjistit problémový řádek v tabulce s tisíci záznamy už vyžaduje udělat kontrolní SQL dotaz. Server navíc ohlásí jen první nalezenou chybu, nikde není záruka, že problémových záznamů není více. Celý proces by se tak mohl několikrát opakovat, a to je pak krásná práce na dlouhé zimní večery.

    To ani nemluvím o tom, že po takové chybě musí platforma provést odvolání změn, které již v rámci daného příkazu provedla. Pokud k chybě dojde až po zpracování pár tisíc záznamů, může tedy odvolání znamenat docela náročnou operaci.

    Obecně je atomicita zpracování DML příkazu určitě užitečná. Bylo by hodně obtížné udržet konzistenci dat v aplikaci, pokud by u každého DML příkazu bylo třeba počítat i s možností částečného úspěchu. Na druhou stranu v řadě případů jako je ten výše uvedený, nebo při plnění datových skladů by bylo docela pohodlné, přikázat serveru ať provede změny tam kde může a pak vás nechá projít problémové záznamy a zpracovat je individuálně.

    Přesně tento způsob zpracování vám nabízí nový mechanismus Oracle Database – takzvaný Error Logging Tables. S jeho pomocí můžete stanovit, že se příkaz dokončí i v případě výskytu chyby a záznamy způsobující chybu se vloží do jiné (tzv. chybové) tabulky spolu s identifikací chyby.

    Nejdříve ze všeho musíte vytvořit chybovou tabulku. Lze to udělat i ručně, ale nejjednodušší je použít proceduru DBMS_ERRLOG.CREATE_ERROR_LOG:

    BEGIN
      DBMS_ERRLOG.CREATE_ERROR_LOG ('DEPARTMENTS');
    END;
    /
    

    Tímto příkazem jsme vytvořili chybovou tabulku pro DML operace nad tabulkou DEPARTMENTS. Pokud neuvedete jiný název, bude chybová tabulka standardně nazvána ERR$_DEPARTMENTS. Další parametry této procedury jsou popsány v dokumentaci.

    Zápis samotné operace vložení dat je jednoduchý:

    INSERT INTO departments
             (department_id, department_name, 
              manager_id, location_id)
             SELECT dept_id, dept_name, mgr, loc
               FROM src 
             LOG ERRORS INTO err$_departments('TEST1') 
             REJECT LIMIT UNLIMITED;
    

    Poslední dva řádky příkazu požadují, aby příkaz proběhl bez ohledu na počet odmítnutých záznamů (REJECT LIMIT UNLIMITED) a tyto odmítnuté záznamy byly vloženy do tabulky ERR$_DEPARTMENTS. Protože se v této tabulce mohou postupně nashromáždit chybové záznamy z více běhů dotazu či dokonce více dotazů, lze ještě záznamy označit tzv. tagem, v našem případě 'TEST1'. V reálném případě byste ale jako tag samozřejmě použili nějaký jednoznačný identifikátor. Bližší popis klauzule LOG ERRORS naleznete u jednotlivých SQL dotazů.

    Příkaz nyní proběhne zdánlivě bez chyb. Jak ale zjistíte, do tabulky DEPARTMENTS se vložily pouze dva záznamy (dept_id 990 a 993). Důvod proč se nevložily další záznamy vám poskytne ERR$_DEPARTMENTS:

    SELECT department_id, department_name, 
           manager_id, 
           ora_err_number$, ora_err_mesg$
      FROM err$_departments
      WHERE ora_err_tag$ = 'TEST1';
    
    DEPARTMENT_ID  DEPARTMENT_NAME  MANAGER_ID  ORA_ERR_NUMBER$  ORA_ERR_MESG$
    ---------------------------------------------------------------------------------
    991            Praha - Vyroba   100         12899            ORA-12899: value 
                   kulickovych                                   too large for column
                   lozisek                                       "HR"."DEPARTMENTS".
                                                                 "DEPARTMENT_NAME"
                                                                 (actual: 34, 
                                                                 maximum: 30)
    111111         Praha – Uctarna  100         1438             ORA-01438: value 
                                                                 larger than 
                                                                 specified precision
                                                                 allowed for this 
                                                                 column
    992            Praha – Prodej   9100        2291             ORA-02291: integrity 
                                                                 constraint 
                                                                 (HR.DEPT_MGR_FK) 
                                                                 violated
                                                                 - parent key not found
    

    Jednoduše tak zjistíte, že zatímco jeden záznam (DEPARTMENT_ID=991) neprošel díky příliš dlouhému názvu oddělení, další záznam (DEPARTMENT_ID=992) neprošel kvůli porušení referenční integrity – manažer číslo 9100 neexistuje. Chybová hláška v prostředním záznamu by sice mohla být konkrétnější, ale asi vám nedá příliš práce zjistit, že zde je problémem příliš dlouhé DEPARTMENT_ID.

    Všimněte si, že z chybové tabulky vybírám pouze záznamy s tagem, který jsem dříve při INSERTu uvedl v klauzuli LOG ERRORS (podmínka ORA_ERR_TAG$ = 'TEST1'). Chyby vzniklé jinými dotazy, které mohou být v tabulce také obsaženy, mne v danou chvíli nezajímají.

    Chybová tabulka má stejně nazvané sloupce jako původní tabulka DEPARTMENTS a databáze se snaží, pokud je to možné, vyplnit je příslušnými hodnotami. Aby byla minimalizována šance, že hodnota nepůjde vložit ani do chybové tabulky, jsou standardně všechny sloupce typu VARCHAR2(4000).

    Chybová tabulka navíc obsahuje těchto 5 sloupců, pomocí kterých zjistíte proč operace nad daným záznamem selhala.:

    • ORA_ERR_NUMBER$ – číslo chybové hlášky
    • ORA_ERR_MESG$ – text chybové hlášky
    • ORA_ERR_ROWID$ – jednoznačný identifikátor záznamu, na kterém došlo k chybě (jen pro Update a Delete).
    • ORA_ERR_OPTYP$ – typ operace (Insert/Update/Delete)
    • ORA_ERR_TAG$ – tag pro identifikaci běhu příkazu (text uvedený v závorkách klauzule LOG ERRORS

    Pomocí mechanismu Error Logging Tables lze zajistit provedení DML operace pro odpovídající záznamy a zároveň velmi rychle zjistit, jaké záznamy způsobují chyby. Tabulku s chybovými záznamy lze následně použít pro další automatické či ruční zpracování problematických záznamů.

    Bez tohoto mechanismu by bylo nutné procházet vstupní sadu záznam po záznamu a individuálně provádět DML operace. Nejen že to znamená napsat více kódu, ale také výkonnostně jde o výrazně horší řešení. Kdykoliv můžete použít hromadné zpracování dat, má smysl to udělat. V tom jsou databázové platformy nejlepší.

    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.

    Diskutovat o tomto článku můžete na našem diskusním fóru.

    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 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 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