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.
2011. július 19., kedd
2011. június 2., csütörtök
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!
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!
2011. március 10., csütörtök
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.
2011. március 5., szombat
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
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
2011. február 26., szombat
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.
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:
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.
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.
2011. február 16., szerda
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.
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.
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.
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.
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.
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.
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!
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!
2011. február 15., kedd
Kitöltöttem a BI-TREK 2011 kutatás kérdőívét.
A bi.hu portálon találtam rá a BI-TREK 2011 kutatásra, melyet ki is töltöttem. A kutatás eredményét a kitöltők megkapják, engem ez motivált a kérdőív kitöltésére.
Alapvetően az érdekelt, hogy mennyire elterjedtek az egyes BI megoldások ma Magyarországon, melyik eszközt ismerik sokan, mely eszközhöz lehet könnyen és gyorsan szakembereket találni. A fentieken túl további, számomra is érdekes kérdésekkel találkoztam, a különböző BI technológiák elterjedtségére is kíváncsi vagyok.
A sikeres felméréshez szükséges, hogy minél többen kitöltsük a kérdőívet, ezért mindenkit erre buzdítok: http://kutatas.bi.hu/
Alapvetően az érdekelt, hogy mennyire elterjedtek az egyes BI megoldások ma Magyarországon, melyik eszközt ismerik sokan, mely eszközhöz lehet könnyen és gyorsan szakembereket találni. A fentieken túl további, számomra is érdekes kérdésekkel találkoztam, a különböző BI technológiák elterjedtségére is kíváncsi vagyok.
A sikeres felméréshez szükséges, hogy minél többen kitöltsük a kérdőívet, ezért mindenkit erre buzdítok: http://kutatas.bi.hu/
2011. február 12., szombat
Könyvajánló: Business Intelligence Roadmap
 | Business Intelligence Roadmap The Complete Project Lifecycle for Decision - Support Applications Larissa T. Moss, Shaku Atre, 2003 |
A könyv bevezet az üzleti intelligencia területébe, könnyen olvasható, arra fókuszál, hogy egy átfogó képet adjon, átlátható keretbe foglalja az ilyen témájú projekteket. A vezetők számára legfontosabb, legalapvetőbb eljárásokat ismerteti, minden fő BI koncepció röviden ismertetésre kerül benne. Jól integrálja az üzleti, technikai és menedzsment nézőpontokat.
Az üzleti intelligencia területét feldolgozó szakirodalom nagy klasszikusa ez a kiadvány. Karrierem kezdetén, nyolc évvel ezelőtt már láttam ezt a könyvet a főnököm asztalán, és most elérkezett az ideje, hogy én is megszerezzem a könyvben rejlő szaktudást. Az amazon.com – on az üzleti intelligencia kifejezésre keresve a harmadik találatként jön fel ez a könyv, mely ugyancsak azt tanúsítja, hogy a szakmában széles körben ismert és olvasott mű, s ezt az eladási adatok is alátámasztják, alapvetően ezért olvastam el én is.
A könyv két részből áll. Az első rész olvasmányos, egy átlátható, önálló szakaszokból felépülő projekt vázon keresztül mutat be egy BI projektet. Minden egyes projektlépésnél a projekt menedzser szemszögéből szemlélve bemutatja az adott szakasz főbb tevékenységeit, a szakaszban felmerülő problémákra fókuszálva, a szakma által széleskörűen használt „legjobb gyakorlatokat” bemutatva. Az egyes teendőknél megkapjuk az indoklást, hogy az adott lépés miért fontos, és elhagyása esetén milyen kockázatokkal kell számolnunk.
Kifejezetten tetszett a könyvet átszövő célorientált szemléletmód, a projekttervezést megelőző vállalati infrastruktúra felmérés módszere. A prototípuskészítésre vonatkozóan hasznos tanácsokat, részletes tervezési utasításokat is tartalmaz a könyv. Jól felépített vázat ad arra, hogyan kell egy fejlesztési ütemet kiértékelni az élesbe állást követően.
Véleményem szerint az első szakasz végére a könyv kicsit ellaposodik, szinte csak trivialitásokat tartalmaz, bár ez az érzés lehet, hogy csak annak köszönhető, hogy nekem személy szerint e területeken van több személyes tapasztalatom.
A könyv második részében gyakorlatilag egy teljes BI projekt tervet kapunk, melyet ízlésünk szerint testre szabhatunk. Szakaszokra lebontva felvázolja a projektek humán erőforrás szükségletét, részletes listában összegezve a projekt leszállítandókat, a projektben megoldandó feladatokat és részfeladatokat, a végrehajtás során meglévő párhuzamosítási lehetőségeket. A művet a szerzők által az évek során összegyűjtött, témakörökre lebontott praktikus tanácsok sora zárja.
Kiválóan alkalmazható referenciaként, csontvázként vagy ellenőrző listaként BI projektek tervezésekor. A könyv felhasználásával biztosíthatjuk, hogy a feladat tervezése során minden szükséges lépést átgondoljunk. Nem szükséges az elejétől a végéig kiolvasnunk, hanem akár fejezetenként is önállóan feldolgozható, az egyes témakörök egymástól függetlenül is megállják a helyüket.
A könyvet elsősorban projekt menedzsereknek, üzleti intelligencia területet irányító vezetőknek ajánlom. A jövőben én is elsősorban projektek tervezésekor fogom a kezembe venni és forgatni ezt a könyvet.
2011. február 5., szombat
Milyen információkat gyűjt össze egy teljes körű, eszköz független riport felmérő kérdőív?
Projektjeink igényfelmérési fázisában mindannyian szembesültünk már azzal a kérdéssel, hogy hogyan mérjük fel a riport igényeket, mire kérdezzünk rá, milyen sablonokat alkalmazzunk. Összegyűjtöttem, hogy szerintem milyen fontos részekből áll össze egy teljes körű, a megvalósítás eszközeitől független kérdőív.
Az alábbiakban végigmegyek az egyes információ blokkokon, vázlatosan megadom azok tartalmát. A bejegyzés végén csatolok egy Word állományt, mely egy konkrét felmérő kérdőívet tartalmaz, amely kiindulási alapot adhat jövőbeni projektjeinkhez, és amelyet szabadon tudunk bővíteni – szűkíteni igényeinknek megfelelően.
Akkor csapjunk bele, a kérdőív felépítése és tartalma az alábbi:
Általános Riport információk
Célszerű minden egyes riportot egyedileg elnevezni és valamilyen szisztéma szerint kiosztani hozzá egy riport kódot, amivel a későbbiek során egyszerűen tudunk hivatkozni a riportra. Nagyobb projekt esetén a riportokat csoportokba, modulokba kell szerveznünk. A felmérő kérdőív fontos része, hogy rögzítsük a dokumentum készítőjét, felelősét és a felmérésben résztvevő összes szereplő nevét/elérhetőségét. A projekt során valószínűleg folyamatosan változnak majd a projekt résztvevők, az új belépők számára ezen információk segítik a gyors betanulást.
Előzmények
Amennyiben a riportunkat nem a nulláról kell felépítenünk, akkor gyűjtsünk be minden elérhetőséget, meglévő dokumentációt az előzmény riportunkról.
Üzleti definíció
A riport üzleti célját rögzítjük a kérdőívben, annak érdekében, hogy biztosítani tudjuk a fejlesztés végén a célnak megfelelő termék keletkezik.
Adattartalmi specifikáció
A riportban szereplő adatok javasolt forrásainak rögzítésével kezdődik az adattartalmi specifikáció. Táblázatos formában rögzíteni kell a riporton megjelenő összes fogalmi elemet, melyeket csoportokba szervezünk. Felmérjük, hogy a riport adattartalmán milyen globális szűréseket kell alkalmazni, aktuális adatokat kell megjelenítenünk, vagy szükséges az adatok történetiségének, múltbéli értékeinek a megjelenítése is. Kérdés, hogy a riport adattartalmát milyen gyakorisággal kell frissíteni, szükséges – e a riportot ütemezetten futtatni.
Formai specifikáció
A formai specifikáció első kérdése, hogy milyen formátumban / formátumokban kell előállítani a riportot: PDF / HTML / Excel. Szükséges tudnunk, hogy hogyan fog történni a hozzáférés módja: Internet, intranet, fájl rendszer, stb. A riport formai specifikációját két módon is célszerű bekérni: egyrészt készüljön el egy Word vagy Excel állomány, melyben vázlatosan megrajzoljuk, hogyan kell kinéznie a riportnak, e mellett szabad szöveges formában is célszerű rögzíteni a formai sajátosságokat. Szenteljünk fülön figyelmet a riportban megjelenő csoportosításokra, az adatok rendezési szabályaira. A riportok közötti kapcsolatokat is ki kell deríteni, írjuk le, hogy milyen átkattintásokat tervezünk a riportjaink között, milyen egymásra mutató linkeket hozzunk létre.
Funkciók, felhasználói interakciók
A riportunk nem feltétlenül statikus, amennyiben böngészőben készül, akkor lehet több lépcsős, és tartalmazhat olyan elemeket, melyek felhasználói interakciót tesznek lehetővé. Ezen funkciók használati eseteit rögzítjük ebben a szekcióban.
Jogosultság, naplózás
A riport biztonsági aspektusának két fontos részét határozzuk meg itt: kik férhetnek hozzá s riporthoz, milyen adatkorlátozásokkal, az egyes hozzáféréseket, riportfuttatásokat hogyan kell naplózni, szükséges – e például a megadott riport paramétereket külön naplózni?
Teljesítményjellemzők
A hardver és szoftver környezet méretezéséhez tudnunk kell, hogy a riportot várhatóan milyen gyakorisággal fogják a felhasználóink futtatni. Napi 10/100/1000 vagy 10000 - es futtatással kell megbirkóznia a megoldásunknak? A méretezéshez szükséges információként próbáljuk megsaccolni, hogy a riportunknak körülbelül hány sor lesz az eredménye, az eredmény hány MB méretű, az extrém nagy riportok külön kezelést igényelnek.
Tesztelés
Már az igények felmérésekor célszerű átgondolnunk, hogy az elkészült riportunkat hogyan tervezzük tesztelni, milyen adatokhoz akarunk majd hasonlítani, mi lesz az elfogadás kritériuma.
A tartalmi leírást követően pedig itt az ígért link:
Feliratkozás:
Bejegyzések (Atom)