Warehouse Builder fejlesztés kényelmessé tétele az ablakok automatikus átméretezésével és áthelyezésével.

Egy előző blog bejegyzésemben már írtam arról, hogy a fejlesztői munkát hogyan lehet hatékonyabbá tenni AutoHotkey használatával. Most egy újabb apró, azonban felettébb praktikus scriptet raktam össze. Munkám során nagyon bosszantott, hogy az OWB - ben felugró ablakokat folyton át kell helyeznem és méreteznem, mert túl kicsi az ablak ahhoz, hogy az információ normálisan megjelenjen. Az alábbi script automatikusan áthelyezi és átméretezi a beállított ablakokat, amint azok megjelennek a képernyőn.

loop {
sleep 100
WinGetActiveTitle, v_active_title
v_owbwindow := regexmatch(v_active_title, "^(Edit Flat File|Expression Builder|Constant Editor|Joiner Editor)")
if v_owbwindow
{
WinGetPos, X, Y, , , A
if x != 50 and y != 50
{
winmove %v_active_title%,, 50, 50, 1500, 800
}
}
}

Ez az egyszerű trükk megszabadított számtalan frusztráló, unalmas átméretezgetéstől, ezáltal gyorsabban és hatékonyabban tudok fejleszteni OWB - ben.

"Forró" adattárház táblák azonosítása

Egy adattárház vizsgálata közben feltettem magamnak a kérdést, hogy vajon melyek a felhasználók által leggyakrabban használt táblák. Erre a kérdésre, viszonylag könnyen választ lehet kapni az alábbi lekérdezéssel:

select
  t.object_name, s.statistic_name, sum(s.value) value
from
  dba_objects t,
  v$segstat s
where t.object_id = s.OBJ#
  and s.value <> 0
  and s.statistic_name = 'logical reads'
group by t.object_name, s.statistic_name
order by sum(s.value) desc
;

Adattárháznál szinte mindig az IO a szűk keresztmetszet, ezért célszerű megnézni, hogy mely táblák generálják a fizikai olvasásokat:

select
  t.object_name, s.statistic_name, sum(s.value) value
from
  dba_objects t,
  v$segstat s
where t.object_id = s.OBJ#
  and s.value <> 0
  and s.statistic_name = 'physical reads'
group by t.object_name, s.statistic_name
order by sum(s.value) desc
;

A fizikai olvasásokat vizsgálva kíváncsi lettem, hogy vajon milyen objektumok vannak bent az Oracle cahce - ben? Ezt az alábbi lekérdezéssel néztem meg.

select
  o.owner,
  o.object_name,
  b.block_size object_block_size,
  count(*) num_of_blocks_in_cache,
  min(s.segment_blocks) total_num_of_blocks,
  round(count(*) / min(s.segment_blocks) * 100) as percentage_in_cache,
  round(block_size * count(*) /1024/1024) as object_cace_size_mb,
  round(sum(block_size * count(*)) over ( partition by block_size) /1024/1024) as full_cace_size_mb
from
  v$bh b,
  dba_objects o,
  v$tablespace t,
  dba_tablespaces b,
  (
    select
      t.owner, t.segment_name, sum(blocks) segment_blocks
    from dba_segments t
    group by t.owner, t.segment_name
  ) s
where b.objd = o.object_id
  and b.TS# = t.TS#
  and t.name = b.tablespace_name
  and s.owner = o.owner
  and s.segment_name = o.object_name
group by o.owner, o.object_name, b.block_size
order by count(*) desc
;

A fenti információkat feldolgozva, a cache megfelelő méretezésével; cache hintek, cache opciók beállításával lehet csökkenteni a rendszer IO terhelését, azaz növelni a rendszer összteljesítményét.

Fejlesztői rutinműveletek automatizálása AutoHotkey - vel.

Egy újabb hasznos programmal bővült a fejlesztői eszköztáram. A legújabb Pl/Sql Developer makró funkcióit próbálgattam, s rá kellett jönnöm, hogy a billentyűkombinációk visszajátszása nem minden esetben történik meg korrektül, azaz nem tudom vele rendesen automatizálni a rutin műveleteket, ezért elővettem az AutoHotkey (AHK) programot, melyet már régebbről ismertem.

Az AutoHotkey egy ingyenes script program, melynek segítségével inputokat küldhetünk a Windows programjainknak, azaz alkalmas a Pl/Sql Developer makró funkciójának kiváltására.

Egyik vesszőparipám, hogy gyakran van szükségem arra, hogy egy tény táblában levő kód értékhez lekérdezzem egy kódtáblából a kód leírását. A kódtábla lekérdezésre persze van egy bejáratott, paraméterezett scriptem. AutoHotkey segítségével ennek a feladatnak az automatizálása így oldható meg:

#q::
 send ^c
 send !f
 send o
 send s
 WinWaitActive Open
 sendinput C:\path\select dim table.sql{ENTER}
 send {F8}
 send ^v
 send {ENTER}
return

A ResultGrid - ben dupla kattintással kijelölöm a kérdéses cella tartalmát, majd a Windows+q billentyűkombinációt lenyomva az AHK futtatja a scriptemet a cella értékkel paraméterezve. A Pl/Sql Developer nem nyit újabb ablakot, ha már egyszer meg lett nyitva az sql fájl, hanem csak a már meglevő ablakot aktiválja, azaz a script kényelmesen futtatható többször is, nem kell az ablakokat csukogatni.

A script bővíthető úgy is, hogy az AHK automatikusan átváltson a megfelelő Pl/Sql Developer ablakra. Ez akkor jön jól, amikor a dokumentációt olvasom és az abban szereplő információ alapján akarok lekérdezést futtatni.

#q::
 send ^c
 WinActivate PL/SQL Developer - user@database
 send !f
 send o
 send s
 WinWaitActive Open
 sendinput C:\path\select dim table.sql{ENTER}
 send {F8}
 send ^v
 send {ENTER}
return

Bonyolultabb rutinművelet automatizálásával is próbálkozom, erre példa az alábbi kód, melyet arra használok, hogy egy már meglevő select - ből subselect - et készítsek. A script a kijelölt szöveget tabulálja és a select * from (#kijelölt szöveg#) kódot eredményezi.

#p::
 sendinput {TAB}
 sendinput ^x
 sendinput {HOME}
 sendinput select{ENTER}
 sendinput {TAB}*{ENTER}
 sendinput {HOME}from ({ENTER}
 sendinput {TAB}^v{ENTER}
 sendinput {HOME})
return

Amikor kódrészletet másolok át alkalmazások között, akkor gyakran szükségem van rá, hogy csak a szövegtartalmat vigyem át, a formázást figyelmen kívül hagyva. AHK - val ez az alábbi scripttel oldható meg. Én ezt a Windows+c gombra raktam, amit a Ctrl+c alternatívájaként tudok alkalmazni.

#c::
 send ^c
 clipboard = %clipboard%
return

Nemrég kezdtem el használni az AHK - t, még rengeteg potenciált látok benne, bízom benne, hogy megszabadít az unalmas, időpazarló rutinmunkától.

Hatékony eljárás aktív dimenzió rekordok történetének lekérdezésére.

A minap belefutottam egy feladatba, melyben arra volt szükség, hogy egy dimenzió táblából leválogassam azon elemek történetiségét, melyeknek van éppen érvényes rekordja. Első nekifutásra az alábbi megoldással álltam elő:

create table dim_table
(
  code_1 number,
  desc_1 varchar2(200),
  start_of_validity date,
  end_of_validity date
);

select
  hist.code_1,
  hist.desc_1,
  hist.start_of_validity,
  hist.end_of_validity
from
  dim_table curr,
  dim_table hist
where curr.start_of_validity <= sysdate
  and curr.end_of_validity > sysdate
  and curr.code_1 = hist.code_1;

Mivel hatalmas tábláról volt szó és több hónapra visszamenőlegesen kellett futtatni a feldolgozást, ezért elkezdtem gondolkodni rajta, hogyan lehet lefaragni a futási időből. Az alábbi megoldással rukkoltam elő:

select
  code_1,
  desc_1,
  start_of_validity,
  end_of_validity
from (
  select
    curr.code_1,
    curr.desc_1,
    curr.start_of_validity,
    curr.end_of_validity,
    max(case
      when curr.start_of_validity <= sysdate and curr.end_of_validity > sysdate then 1
      else 0
    end) over (partition by code_1) as curr_ind
  from
    dim_table curr
)
where curr_ind = 1;

Ez utóbbi megoldás ugyanazt az eredményhalmazt adja, azonban a végrehajtás során csak egyszer kell felolvasni az alaptáblát. Az én esetemben ez közel megfelezte a végrehajtási időt.

SQL Tuning, futó lekérdezések memória és temp használatának megjelenítése végrehajtási lépésenként.

Ambrus Gábor kollégámtól kaptam az alábbi, praktikus script - et, melynek segítségével megtekinthető egy éppen futó sql végrehajtási terve, s a végrehajtási tervhez kapcsolódó egyes lépések aktuális memória és temp használata. Ez a lekérdezés nagyon megtetszett nekem, mert segítségével betekintést nyerhetünk lekérdezésünk végrehajtási állapotába, a memória és temp értékek vizsgálatával könnyen kiszúrhatjuk, ha valahol "hiba" csúszott a végrehajtási tervbe.

A lekérdezés második sorába kell beilleszteni a futtatás előtt a vizsgálandó futó lekérdezés sql_id azonosítóját.


with sqlid as (
    select '9c9qwv489rxfk' sql_id from dual
)
select
    woac.temp_mb,
    woac.mem_mb,
    substr(translate(
        substr(sys_connect_by_path(branch, ','), 1, length(sys_connect_by_path(branch, ',')) - 2) ||
            case when branch = '. ' then '`-' else '|-' end,
        ',.',
        '  '
    ), 4) || operation operation,
    plta.options,
    plta.object_owner,
    plta.object_name,
    plta.object_alias,
    plta.cardinality,
    plta.other_tag,
    plta.access_predicates,
    plta.filter_predicates,
    plta.partition_start,
    plta.partition_stop,
    plta.partition_id
from
    (
        select
            sql_hash_value,
            sql_id,
            operation_id,
            sum(tempseg_size/1048576) temp_mb,
            sum(actual_mem_used/1024/1024) mem_mb
        from
            v$sql_workarea_active
        group by
            sql_hash_value,
            sql_id,
            operation_id
    ) woac,
    (
        select
            pl.*,
            nvl2(lead(pl.id) over (partition by pl.parent_id order by pl.position), '| ', '. ') branch
        from
            v$sql_plan pl,
            sqlid
        where
            pl.sql_id = sqlid.sql_id and
            pl.child_number = 0
    ) plta
where
    woac.sql_hash_value (+) = plta.hash_value and
    woac.sql_id (+) = plta.sql_id and
    woac.operation_id (+) = plta.id
connect by
    prior plta.id = plta.parent_id
start with
    plta.parent_id is null
order siblings by plta.position;

Ingyenesen elérhető tesztsorok Oracle vizsgákhoz.

Célul tűztem ki magamnak, hogy további Oracle minősítéseket szerzek meg, leteszem az Oracle Database 11g: Administration I (1Z0-052) vizsgát.

Elkezdtem kutakodni az interneten tananyagok, vizsgasorok után s rátaláltam a http://www.examcollection.com/ oldalra. Erről az oldalról ingyenesen letölthetőek vizsgasorok. Az 1Z0-052 vizsgához is van legalább egy tucatnyi vizsgasoruk. Az oldal felhasználóinak visszajelzései alapján a vizsgasorok aktuálisak és jól használhatóak.

Az egyetlen trükk, hogy a Visual CertExam Suite programot meg kell vásárolni a letölthető vce fájlok megtekintéséhez, azonban kisebb kutakodás után sikerült rátalálnom a lenti linken letölthető kis programra, mely képes a vizsgasorok megjelenítésére, azaz használatával sikeresen fel lehet készülni.

VCE Engine

Az ExamCollection számos vizsgához nyújt felkészülési anyagokat, ezért egy klikket mindenképpen megér a site.

Sok sikert a vizsgákhoz!

Tippek az Oracle Database 11g: Data Warehousing Certified Implementation Specialist minősítés megszerzéséhez.

A nyáron rátaláltam az Oracle oldalain a fenti, adattárház szakmai minősítésre. Úgy gondoltam, hogy ha már évek óta Oracle alapú adattárházak építésével foglalkozom, akkor illik megszereznem ezt a minősítést.

Átnéztem az Oracle által kiírt vizsgatematikát és az Oracle partnerek számára biztosított oktatási anyagot s világossá vált, hogy ennek a vizsgának is csak úgy érdemes nekimenni, ha előtte egy teszt programmal alaposan felkészülünk.

Az SQL és PL/SQL vizsgák megszerzésénél a uCertify platform bizonyult hasznosnak, ezért most is a uCertify felkészítő anyagát vettük meg. A vizsgán ért minket a meglepetés, hogy a uCertify anyag csak egy harmadában fedi le a tényleges vizsgakérdéseket. Ennek ellenére sikerült első nekifutásra átmenni a vizsgán, azonban ha valaki fel akar készülni, akkor inkább a PassGuide – ot ajánlom, az ő anyaguk jobban illeszkedik a tényleges vizsgakérdésekhez.

A vizsgára való felkészüléskor az alábbi témaköröket célszerű alaposan átnézni:

• Adaptive parallelism
• Oracle Exadata
• teljesítménynövelő módszerek
• adattárolási képességek
• Tömörítési funkciók
• SQL Result Cache működése
• result set – ek típusai
• engedélyezés
• cache tartalom milyen eseményekre változik
• Materializált nézetek, frissítési típusok
• Direct path load – ot eredményező adatbázis műveletek
• Partícionálási típusok 
• partícionálás előnyei (pruning)
• partition-wise joins
• Resource Manager működése
• ODI felépítés, template – ek, Knowledge Modul – ok funkciója

Kollégáim találtak rá az alábbi két blog bejegyzésre, melyek gyakorlatilag teljesen lefedik a vizsga anyagát, ez a két cikk elengedethetetlen a felkészüléshez:

Oracle 1z0-515 Data Warehousing 11g Essentials 1/2
Oracle 1z0-515 Data Warehousing 11g Essentials 2/2

Az adattárház konzisztenciáját automatikusan ellenőrizni kell!

Az egyik projekt munkám során az adattárház adatainak egy részhalmazát egy különálló szerverre replikáztuk. A replika frissítése deltatöltéseket is tartalmazott. A megvalósítás során felmerült a kérdés, hogy, na de honnan fogjuk észrevenni, ha a replikációs eljárásunk hibázik, azaz az eredeti adathalmazunk és a másolat már nem konzisztens, eltér egymástól.

Ennek a kérdésnek már tervezéskor is fel kellett volna merülnie, nem csak a megvalósítás közben. Azért is írom ezt a blog bejegyzést, hogy legközelebb nekem is hamarabb eszembe jusson, hogy az automatikus konzisztencia ellenőrzéseket is bele kell tervezni a megvalósításba, nem szabad elfeledkezni róluk.

Murphy törvénye szerint, ami elromolhat az előbb utóbb el is romlik. Megelőzendő, hogy a végfelhasználók vegyék először észre a hibát, a töltési folyamat megvalósításába ellenőrzéseket kell beiktatni. Nem kell az ellenőrzés alatt nagyon komoly dologra gondolni, az aktuális szituációban az is elegendőnek bizonyult, hogy egy segédtáblában nyilvántartjuk a forrásrendszerben levő táblák rekordszámát és ezt a rekordszámot ellenőrizzük a delta csomagok bedolgozása után. Egy ilyen egyszerű ellenőrzés már biztosítani tudja azt, hogy automatikusan értesüljünk arról, hogy hiba csúszott a gépezetbe, biztosítani tudja, hogy ne csak késve értesüljünk a hibáról, amikor annak javítása már sokkal időigényesebb lehet.

Egy adattárház feldolgozásai nagyon komplexek is lehetnek, több ponton is van lehetőség hibára, ezért ahol delta csomagok feldolgozása történik, ott célszerű megvalósítani egy egyszerű ellenőrzési eljárást is, hogy biztosak lehessünk adataink konzisztenciájában.

Relációs adatok utófeldolgozása Excel - ben

A vállalati adatok előbb utóbb Excel - ben kötnek ki, így elkerülhetetlen, hogy az üzleti intelligencia területen dolgozó szakember az Excel - hez is értsen valamelyest. Egy aktuális projektemen azon dolgozom, hogy egy Excel – ben levő „adatpiac” – ot átültessek Oracle alapokra.

Elemeztem a meglévő, Excelben megírt adatfeldolgozási módszereket és belefutottam egy klasszikus problémába. Hogyan lehet a VLOOKUP függvényt alkalmazni, ha több mezős feltétel mentén akarunk illeszteni?  Azaz hogyan lehet egy összetett kulccsal rendelkező táblázatból kulcs mentén értékeket kivenni? A klasszikus megoldás erre az, hogy a két kulcs mezőt összefűzzük és az összefűzött mezőre keresünk rá. Ez a megoldás relációs adatbázisokhoz szokott szakemberek szívét nem melengeti meg túlságosan, ezért elkezdtem kutatni, hogy az alap Excel funkciókat használva hogyan lehet megoldani a problémát.

A Google a „vlookup multiple criteria” keresésre tömérdek eredményt ad, melyek legtöbbje az INDEX és MATCH függvények trükkös paraméterezését adja meg megoldásul. Nem elégedtem meg ezzel a bonyolult válasszal, tovább gondolkodtam. Néztem a DGET adatbázis függvényt, de ennek a használatához külön cellaterületen kell megadni a kritériumokat, úgy találtam, hogy egy cellában való képletezéssel ennek a függvénynek a használata nem megoldható.

Végül véletlenül rájöttem egy trükkre. Ha az adatokat tartalmazó táblázatunkra épülve létrehozunk egy kimutatást, akkor a GETPIVOTDATA függvényt alkalmazva egész kulturáltan lehet konkrét adatértékeket egy cellában paraméterezve lekérdezni. A GETPIVOTDATA függvénynek meg kell adni, hogy mely tény oszlop értékét akarjuk megkapni, mely PivotTable – ből, majd ezt követően egymást követve megadhatjuk a dimenziók mentén történő szűrési feltételeinket dimenzió név, érték párosokban. Ilyen párosból tetszőlegeset felvehetünk.

Ezzel a módszerrel egy adattábla tartalmát egyszerűen, tetszőleges elrendezésben szétteríthetjük egy Excel munkafüzetekben, az elemzők ízlésének megfelelően.

Ha az olvasóim közül valaki ismert jobb, szebb, praktikusabb megoldást a problémára, kérem, ossza meg velem!

Könyvajánló: Data Warehouse Project Management

Data Warehouse Project Management Sid Adelman, Larissa T. Moss

Újabb könyvön rágtam át magam adattárház projekt menedzsment témakörben. A szerző, Sid Adelman több mint 30 éve tevékenykedik az üzleti intelligencia területen. A könyvet olvasva az a gondolat jutott eszembe, hogy „a profi listából dolgozik, nem bízza a dolgokat a véletlenre”.  A könyvben minden egyes projekt menedzsment témakör átfogóan, tételesen ismertetésre kerül, melyből könnyen megalkothatjuk a mindennapi munka során alkalmazott saját szamárvezetőinket.

A könyv fejezetei az alábbi témaköröket ölelik fel:

• Az adattárházak általános rövid és hosszú távú céljai.
• DW projektek sikerkritériumai
• Tipikus projekt kockázatok, azok kezelése
• Költség – haszon elemzés
• Szoftver kiválasztás folyamata
• Projektszervezet, szerepkörök
• Rapid Application Development módszertan
• Adatminőségi hibák kezelése
• Projekttervezés, projekt-kommunikáció

A könyvben a szerzők gyakorlati tapasztalataikat osztják meg, számos tanácsuk igen praktikus és hasznos. Ebben a könyvben találkoztam először olyan széleskörű ismertetéssel, mely teljesen felöleli az adattárház projektekben előforduló összes tipikus problémát, kockázatot.

A praktikus felhasználást segíti elő, hogy minden fejezet egy workshop – pal zárul, mely célirányos kérdéseken és feladatokon keresztül támogatja az olvasót abban, hogy rögtön alkalmazza is az újonnan megszerzett ismereteket a saját helyzetére. Ezek a workshop – ok és a könyvben szereplő összes sablon elektronikus formában is elérhető, a könyv CD mellékletén.

A könyvet mindenkinek ajánlom olvasásra, aki érintett üzleti intelligencia projektek vezetésében.

Gépírási hibák kiküszöbölése a billentyűzet - kiosztás módosításával.

A mindennapi munkám során szembesültem azzal a problémával, hogy a programozási nyelvek alapvetően angol billentyűzetre lettek kitalálva, az angol billentyűzet kiosztás mellett kényelmes a használatuk, míg a dokumentáció és levelezés a magyar billentyűzetkiosztás használatát teszik szükségessé. A fentiek kiemelten érvényesek, ha tudunk gépírni.

Azt vettem észre, hogy bármennyire igyekeztem is, nem tudtam megszokni, hogy a két billentyűzet kiosztáson a z és az y billentyűk fel vannak cserélve. Nem vagyok képes arra, hogy fejben tartsam, mikor épp hol helyezkednek el ezek a billentyűk, rendszeres volt a mellégépelés. Rájöttem, hogy ez a helyzet gyakorlással és odafigyeléssel nem oldható meg.

Nyilvánvalóvá vált, hogy valamelyik, vagy a magyar, vagy az angol billentyűzetkiosztáson fel kell cserélnem a z és az y karaktereket ahhoz, hogy gond nélkül menjen a gépelés mind programozás, mind levélírás közben.

Kisebb keresgélés után rátaláltam a Microsoft Keyboard Layout Creator – ral, aminek segítségével készítettem egy saját angol nyelvű billentyűzet kiosztást, melyen fel van cserélve a z és az y, ezt a kiosztást elneveztem amizy – nek.

Az elmúlt két hónapban már ezt az új billentyűzet kiosztást alkalmaztam a munkahelyemen, sikeresen átszoktam rá, sikerült megszabadulnom az állandó, idegesítő elgépelésektől.

Az amizy billentyűzet kiosztás telepítő készlete az alábbi link – ről letölthető, vagy bárki készíthet magának sajátot a Microsoft Keyboard Layout Creator programjával.

amizy.zip

Hogyan lehet lekérdezni egy futó OWB MAP tényleges végrehajtási tervét?

Az adattárház fejlesztő feladata, hogy az általa készített feldolgozások megfelelő teljesítményt nyújtsanak, azaz lefussanak a lehető legkevesebb erőforrás felhasználásával, a lehető legrövidebb idő alatt.

Személyes véleményem, hogy a fejlesztőnek folyamatosan foglalkoznia kell a teljesítmény kérdésével, már a kezdetektől fogva, a fejlesztési folyamat teljes életciklusa alatt. Ez az odafigyelés megtérül, mert a hosszabb futási idők, a pazarló végrehajtások a fejlesztő életét is megnehezítik, kevesebb fejlesztési időt, odafigyelést, szervezést igényel egy 5 perc alatt lefutó feldolgozás, mint egy hasonló bonyolultságú, de 60 perc futási idejű.

Én úgy dolgozom a fejlesztéseim során, hogy nyomon követem a fejlesztett MAP – ek végrehajtási tervét. Ezt a legegyszerűbben úgy tudom megtenni, hogy ha futtatok egy MAP – et, akkor az alábbi sql lekérdezést használva lekérdezem az Oracle adatbázisban éppen aktuálisan futó MAP – ek listáját ás a hozzájuk tartozó sql – t azonosító sql_id – t. A lenti lekérdezés összekapcsolja a session információkat az OWB audit adatokkal, így látom a konkrét MAP elnevezéseket is.

select s.sql_id, s.threads, s.module, a.map_name, a.elapsed

from (

  select S.SQL_ID, s.MODULE, count(*) threads, substr(s.module, 23, 7) aid

  from v$session s

  where s.MODULE like '%MODUL NEV%'

  group by sql_id, module

) s,

(

  select t.execution_audit_id, t.map_name, round((sysdate - t.start_time)*24*60) elapsed

  from owb_adw_run.all_rt_audit_map_runs t

  where t.start_time > sysdate - 1

) a

where s.aid = a.execution_audit_id (+);

Az eredményül kapott sql_id alapján lehetőség van a v$sql_plan táblában levő tényleges sql végrehajtási terv megjelenítésére. Ha nem innen vesszük a végrehajtási tervet, hanem azt explain plan – nel hozzuk létre egy külön session – ben, akkor beleeshetünk abba a csapdába, hogy a különböző környezeti beállítások miatt más végrehajtási tervet kapunk, mint amivel a tényleges OWB futtatás történik.

Az előző lekérdezésben kapott sql_id – t mint paramétert felhasználva hívom meg az alábbi parancsfájlt:

set pages 0;

set linesize 300;

column plan_table_output format a200;

select t.plan_table_output

from table(dbms_xplan.display_cursor('&sql_id')) t;

PL/SQL Developer – t használva ez a folyamat makrók segítségével automatizálható is, így könnyedén, bármikor ellenőrizni tudom a feldolgozásaim végrehajtási terveit, szükség esetén be tudok avatkozni.

Skálázható, hibatűrő feldolgozások egyszerű kialakítása.

Ezt a cikket elsősorban azoknak az olvasóimnak szánom, akik még sosem használták az Oracle adatbázis beépített, Advanced Queueing (AQ) funkcionalitását, esetleg még nem is hallottak róla. Érdemes vele alapszinten megismerkedni, mert hasznos eszközként szolgálhat minket fejlesztéseink során.

Egyik projektemen a következő feladatot kellett megoldanom. Egy Oracle adatbázisba, egyszerű függvényhívásokon keresztül érkeznek be feldolgozandó feladatok, amelyeket egy különálló alkalmazás szerveren futó, java nyelven fejlesztett szoftver komponens fog végrehajtani. A feladatok végrehajtása aszinkron módon történik, a függvényhívás nem várja meg a feldolgozást, csak a feladat átadására szolgál, a feladatok eredményét egy táblába írja vissza a java program, amely eredmény aztán továbbításra kerül egy másik adatbázisba. A probléma ott kapcsolódik az Üzleti Intelligenciához, hogy a beérkező feladatok konkrét riport igények, a java komponens pedig PDF dokumentumokat generál az adattárház adattartalmából.

Ha ezt a feldolgozást szeretnénk párhuzamosítani, skálázhatóvá tenni, úgy kialakítani, hogy akár több különálló alkalmazás szerveren futó java komponens párhuzamosan végezze a feladatok feldolgozását, akkor a konkurens működést meg kell szerveznünk. Ha emellett még szeretnénk hibatűrővé tenni a megoldást, azaz gondoskodni arról, hogy ha a végrehajtás közben a java program elhal, attól még ne vesszen el a feladat, azt egy másik végrehajtó program automatikusan felvegye, akkor komolyan el kell gondolkodnunk, hogy ezt a vezérlést hogyan valósítsuk meg, mert számtalan problémát rejt magánban a feladat.

A fenti, egyébként komplex problémának az egyszerű megoldására képes az Advanced Queueing, mely könnyedén elbánik az aszinkron termelők, fogyasztók klasszikus problémájával. Ha belenézünk az „Advanced Queuing User's Guide and Reference” dokumentációba, akkor elsőre ijesztőnek tűnik a 480 oldalas leírás, azonban az alábbiakban bemutatom mennyire egyszerűen bevethető az Advanced Queueing a szoftveres megoldásunkban. Én magam is ezt az utat jártam végig, mikor először megismerkedtem az Advanced Queueing – gal, belenéztem a dokumentációba mely túl bonyolultnak tűnt számomra, aztán szerencsémre belefutottam egy angol nyelvű cikkbe, mely egy egyszerű példán keresztül megmutatta a funkció használatát.

Az Advanced Queueing arra képes, hogy egy tetszőleges objektum típus sorban állását kezelje, első lépésként tehát létre kell hoznunk egy objektum típust, mely a végrehajtandó feladatot reprezentálja. A fent felvázolt feladat megoldásához elég volt egy egyszerű objektum típust definiálni, mely csak egy kérés azonosítót tartalmaz.

create or replace type KERES_OBJECT as object

(

  KERES_ID NUMBER(12)

);

Ezt a típus felhasználva, a lenti függvényhívást kiadva létrehozunk egy táblát, mely a várakozási sorunkat fizikailag tárolni fogja az adatbázisban.

begin

  dbms_aqadm.create_queue_table(

    queue_table => 'KERESEK_AQ',

    queue_payload_type => 'KERES_OBJECT'

  );

end;

Erre a táblára alapulva létrehozunk egy várakozási sort, melynek az a tulajdonsága, hogy kétszer próbálkozik egy feladatot kiadni végrehajtásra, mielőtt a feladatot egy hibalistába helyezné át.

begin

  dbms_aqadm.create_queue(

    queue_name => 'KERES_Q',

    queue_table => 'KERESEK_AQ',

    max_retries => 2

  );

end;

Az én gyakorlati tapasztalatom az, hogy a kétszeri próbálkozás bőven elegendő, ha másodszorra sem sikerül a feladat végrehajtása, akkor valószínűleg valami logikai hiba van a programunkban, amely nem fog megoldódni az újrapróbálkozások következtében.

Annyi dolgunk van még hátra, hogy el kell indítanunk a frissen kreált sorunkat, amit az alábbi utasítással tehetünk meg.

begin

  dbms_aqadm.start_queue(queue_name => 'KERES_Q');

end;

Készen is vagyunk, létrehoztunk egy saját Advanced Queue – t, melyet használhatunk a feladatok kiosztásához. Két függvényt kell még elkészítenünk, egyet, mely egy feladatot berak a sorba és egyet, mely végrehajtásra felvesz egy feladatot a várakozási sorunkból.

Az alábbi két függvény kódját egy az egyben a megoldásomból illesztettem be ebbe a cikkbe. Az enq_keres eljárás a paraméterében megadott keres_id feladatot behelyezi a sorba, ahhoz, hogy ez ténylegesen meg is történjen ki kell adnunk egy commit – ot az eljáráshívás után.

procedure enq_keres(keres_id number) is

  l_enqueue_options     DBMS_AQ.enqueue_options_t;

  l_message_properties  DBMS_AQ.message_properties_t;

  l_message_handle      RAW(16);

begin

  dbms_aq.enqueue(

    queue_name          => 'KERES_Q',

    enqueue_options     => l_enqueue_options,    

    message_properties  => l_message_properties,  

    payload             => keres_object(keres_id),            

    msgid               => l_message_handle

  );

end;

A deq_keres függvény, amennyiben van végrehajtandó feladat a sorban, akkor kivesz egyet a feladatok közül, amennyiben nincs további feladat, akkor null értékkel tér vissza.

function deq_keres return number is

  l_dequeue_options     DBMS_AQ.dequeue_options_t;

  l_message_properties  DBMS_AQ.message_properties_t;

  l_message_handle      RAW(16);

  l_keres_object        keres_object;

 

  e_no_task EXCEPTION;

  PRAGMA EXCEPTION_INIT(e_no_task, -25228);

BEGIN

  l_dequeue_options.wait := dbms_aq.NO_WAIT;

 

  begin

    DBMS_AQ.dequeue(

      queue_name          => 'EKERES_Q',

      dequeue_options     => l_dequeue_options,

      message_properties  => l_message_properties,

      payload             => l_keres_object,

      msgid               => l_message_handle

    );

  exception

    when e_no_task then return null;

  end;

  return l_keres_object.KERES_ID;

END;

A feladat feldolgozását végző algoritmust úgy kell megvalósítanunk, hogy a deq_keres függvényhívás után csak akkor kerüljön az adott session – ben commit parancs kiadásra, ha teljes mértékben, sikeresen elkészült a feladat. Ha a session – ben nem kerül commit kiadásra, akkor az AQ gondoskodik róla, hogy egy következő függvényhívás esetén a konkrét feladat újra kiosztásra kerüljön.

A fenti alig pár sornyi kódra volt szükség ahhoz, hogy kialakítsak egy aszinkron, hibatűrő, skálázható riport kiszolgálási megoldást.

Az Advanced Queueing másik klasszikus alkalmazási területe az adattárházban a feladatok ütemezése és végrehajtása. AQ használatával lehet egyszerűen olyan ütemező algoritmust készíteni, mely egy Oracle adatbázisban, háttérben futó JOB – ok számára folyamatosan osztja ki azokat a feladatokat, melyek végrehajthatóvá váltak. Egy ilyen ütemezővel lehetőségünk van arra, hogy maximális mértékben kihasználjuk a hardver adta lehetőségeket, az teljes feldolgozási ablakunk átfutási idejét a lehető leg rövidebbre csökkentsük.

Remélem sikerült felkeltenem azok érdeklődését, akik még nem használták az Advanced Queueing által nyújtott szolgáltatásokat!