Éberhardt Péter Oracle blogja

Timesten 11.2.1 - rengeteg újítással

2009-06-24T10:28:00.004+02:00

A TimesTen fejlesztőcsapata új verziót adott ki a memóriarezidens-adatbázisból. Első pillantásra a legszembetűnőbb változás, hogy új számozással látták el a frissített terméket. A legújabb verzió TimesTen 11.2.1.1.0 néven érhető el. A sorszám első három tagja a TimesTen kiadás sorszáma, tehát 11g release 2, az utolsó kettő pedig a patch sorszámára utal. Azt nem tudom, hogy a 7.0.5 után miért lett egyből release 2, de mindenesetre jobb, mintha release 1 lenne, mert sokan csak a 2-től tekintik használhatónak a termékeket. Marketing?

Platformok

Az új verzió egyelőre csak Linux 32/64 biten, ill. Windows 32 biten érhető el, azonban az Oracle-t ismerve meg sem állnak, míg el nem jutnak legalább 10 különböző platformig. Itt olvasható, hogy a jövőben milyen platformokon lesz elérhető az adatbázis: TTplatform

Újdonságok
Nézzünk pár érdekes újdonságot. Először is örömmel jelenthetem, hogy végre a TimesTen is támogatja a PL\SQL nyelvet, de... Sajnos nem minden platformon, a Windows rendszert használók nem élvezhetik a kibővített SQL nyújtotta előnyöket. Ettől eltekintve mindenképp az új verzió egyik mérföldkövének tekintem ezt a fejlesztést.
Új támogatott platformok
Bővült a támogatott platformok listája az alábbiakkal:

AIX 6.1
Asianux 3.0
Monta Vista 5.0
Windows Vista
Windows Server 2008.

Itt halkan megjegyzem, hogy volt szerencsém már korábban tesztelni Windows Vistán (32 és 64 bitesen egyaránt) és igaz akkor még nem volt hivatalosan támogatott, de gond nélkül lehetett használni. Természetesen csak teszt célokra érdemes, mert ha egy éles rendszert építünk valamilyen nem támogatott platformra, és valamilyen funkció nem működik megfelelően, akkor az Oracle-s kollégák csak széttárt kézzel azt fogják mondani, hogy ha "...nincs a listán, nincs mit tenni"...
Cache Grid
További érdekes újítás, hogy a TimesTen Cache-t tovább gondolták és az Oracle Coherencehez hasonlóan egy speciális grid funkcióval látták el - Cache Grid. Ennek segítségével az egy csoportba tartozó TimesTen példányok elosztottan képesek együttműködni, ezzel is növelve a megbízhatóságot, rendelkezésre állást és nem utolsó sorban a teljesítményt, ráadásul lehetővé válik a horizontális skálázhatóság is. A dokumentációkat olvasgatva úgy találtam, hogy a fejlesztők egy olyan eszközt adtak ki a kezükből, ami egy kezdő TimesTen felhasználó számára sem okozhat gondot. Erősen ajánlott a Cache Grid funkciót automatikus beállításokkal használni, azaz dinamikus betöltéssel és az Asynchronous writethrough (AWT) funkció bekapcsolásával. Ekkor szinte semmiféle további hangolásra nincsen szükség.
Clusterware
Az újdonságokat mazsolázva még egy fontos dolgot emelnék ki. Mostantól a TimesTen adatbázisokat is lehet Clusterware-rel együtt használni, ami tovább növeli az integrálhatóságát Oracle rendszerekbe. Ennek segítségével egy olyan köztes réteg jön létre, amin keresztül a node-okat monitorozhatjuk és azonnal beavatkozhatunk, ha valami probléma lépne fel. Ráadásul az alkalmazások szemszögéből egyetlen szervernek látszik a kiszolgáló rendszer, így jól skálázható, lehet használni több, olcsóbb szervert is akár, nem kell egy nagyteljesítményű, drágát vásárolni.

Természetesen további újdonságok is megjelentek, én csak a legérdekesebbeket emeltem ki. Ezekről bővebben Sárecz Lajos blogjában olvashattok, részeltesen pedig itt: TimesTen Release Notes 11.2.1

Ezzel a verzióval úgy érzem sokat tett az Oracle afelé, hogy a TimesTent befogadják szélesebb körben is a rendszerfejlesztők, ne csak úgy tekintsenek rá, mint egy jópofa, de semmire sem jó játékra. Látszik, hogy eltökélt szándéka a terméket közös alapokra helyezni más termékeivel, így is elősegítve az integrációt már szoftvereivel. Összességében elmondható, hogy egy nagyobb mérföldkőhöz érkezett a TimesTen a korábban felsorolt újdonságok miatt, és érdemes számításba venni rendszertervezéskor, mert felahsználása immár rengeteg előnnyel jár.

Tank War 3D

2009-05-17T21:00:00.004+02:00

Az elmúlt időszakban az időm nagyrészét az kötötte le, hogy teljesítsem a maradék egy tárgyat, amit a diploma előtt még meg kell csinálnom. Igen, a Számítógépes grafikáról van szó. Ez a negyedik félév, hogy hallgatom. Aláírást már az elsőben szereztem és minden félévben ott voltam legalább két vizsgán, de nem sikerült átugranom Szirmay tanárúr lécét. Vagy a léc volt rossz, vagy a tanár gonosz. Nekem mindig úgy tűnt, hogy az utóbbi.
Ebben a félévben mindent egy lapra feltéve az összes kötelező és opcionális évközi feladatot megcsináltam, hogy jó eséllyel pályázzak megajánlott jegyre, elkerülve a vizsgán való számonkérés gyötrelmeit. Ez négy kisházit és egy nagyházit jelent. A kisházik szigorúan specifikált feladatok megoldását jelenti, a nagyházi pedig egy teljesen önálló ötlet megvalósítását.
A félév elején egy látványos fizikával megáldott tereprallli-szerű játékot akartam csinálni, azonban ez változott, és az utolsó kisházi után úgy döntöttem, hogy egy egyszerűbb fizikával megáldott tankos-lövöldözős játék fejlesztésébe fogok. A határidőig 3 nap volt hátra, így nem sokat pepecselhettem. A terepet úgy oldottam meg, hogy rombolható legyen, valamint bármilyen domborzatot elő lehessen álíltani egy egyszerű képfájlból. A tankok irányzékot tudnak állítani, valamint tűzerőt. A kilőtt lövedék ballisztikus pályán repül a becsapódási pontig és figyelembe veszi a szélirányt és erősséget. A játékmenet a klasszikus 2D-s játékkal megegyezik, tehát egymás után célozhatnak és lőhetnek a tankok. Az nyer, amelyik hamarabb találja el a másikat. Szerintem elég jóra sikerült figyelembe véve, hogy ilyen kevés idő alatt kellett valamit prezentálnom.

Két videó a játékból:
Tank War 3D terep
Tank War 3D ingame

Külső program hívása adatbázis-kezelőből

2009-04-19T17:17:00.002+02:00

Oracle

Az Oracle adatbázis-kezelője elérhető programozói interfészeken keresztül, mint például C-ből az OCI (Oracle Call Interface) segítségével, Javaból JDBC API-n (Java Database Connectivity) keresztül, .NET környezetből ODP.NET felhasználásával, vagy más programnyelvek esetén ODBC (Oracle Database Connectitity) segítségével. Az Oracle fejlesztők törekednek arra, hogy a napjainkban használt, szinte összes programnyelvből elérhető legyen az adatbázis, szállítóként pedig nem tehetik meg, hogy ne szenteljenek ennek elegendő figyelmet. Az egyes programnyelvekhez készített programozói interfészeken (API) keresztül azonban csak kliens-szerver architektúrában képesek a programok kommunikálni az adatbázis-kezelővel, tehát minden esetben csak a kliens kezdeményezhet, a szerver passzív szerepet tölt be. Szerepcsere ezzel a technológiával nem lehetséges.

ODP.NET (pl. C#) használata esetén lehetőségünk van a Database Change Notification featuret kihasználni, aminek a segítségével azonnal értesülhetünk az adatbázisban bekövetkezett változásokról. Ehhez a kliens oldali alkalmazásnak folyamatos kapcsolatban kell lennie az adatbázissal, így tudja feldolgozni az onnan kapott üzeneteket.

http://download.oracle.com/docs/cd/B28359_01/win.111/b28375/featChange.htm#CJAGGGHA

Van lehetőség szerveroldalon, az Oracle példány címtartományán belül Java alkalmazás futtatására. Ezen lehetőség felhasználásával összetettebb üzleti logikát lehet megvalósítani adatbázisoldalon, ráadásul jelentős IPC (Inter Process Comunication) és hálózati overheadet spórolhatunk meg vele. További előnye a megoldásnak, hogy az alkalmazás indítását szerveroldalon kezdeményezhetjük, így tetszőleges adatbázis esemény hatására lefuttathatjuk, például triggerek segítségével. A hátránya azonban az, hogy csak a Java nyelven implementált programjaink használhatóak.

Létezik azonban egy univerzális megoldás arra a problémára, hogy adatbázis oldalon kezdeményezve tetszőleges programnyelven implementált alkalmazást lefuttathassunk. Az Oracle a fejlesztők rendelkezésére bocsát egy olyan technikát, amivel mindezt megvalósíthatják. Lehetőséget biztosít arra, hogy C (vagy Java) nyelven implementált eljárásokat PL/SQL eljárásként meghívhassunk. Ez a technika a külső eljárásnak (External Procedure) hívása, ami nem más, mint DLL (Dynamic Link Library) hívás PL/SQL kódból. Ha pedig van rá mód, hogy akármikor meghívjunk egy C függvényt, akkor minden olyan más programnyelven implementált kódot képesek vagyunk futtatni, ami futtatható az adott környezetben, vagy egy szkript segítségével működésre lehet bírni.

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_externproc.htm#ADFNS1402

External procedure használata

Ahhoz, hogy egy C vagy Java nyelven implementált programot meghívhassunk Oracle környezetből, három feladatot kell helyesen megvalósítani: Load, Publish & Call.

Load

Először be kell tölteni a szükséges DLL-t vagy java osztályt, másképp nem tudjuk meghívni.

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_externproc.htm#i1006311

Publish

Utána rögzíteni kell a meghívható függvények nevét, paraméterlistáját és a visszatérési érték típusát. Ezek után szinte ugyanúgy kezelhető, mint egy belső PL/SQL tárolt eljárás.

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_externproc.htm#i1006405

Call

Nincs más hátra, mint a PL/SQL környezetből meghívni az így elérhetővé tett külső eljárásokat.

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_externproc.htm#i1007572

Microsoft SQL Server

Ugyan úgy, mint az Oracle adatbázis, az SQL Server is elérhető különféle adatbáziskapcsolat-kezelő API-kon keresztül (például ODBC). Java nyelvből a JDBC API, C# esetén pedig az ADO.NET használható. Ezeken keresztül azonban csak a kliens kezdeményezheti a kapcsolatot.

A .NET CLR (Common Language Runtime) integrálva van az SQL Server-be, így könnyen lehet olyan menedzselt .NET kódot (pl. C#) írni, amit tárolt eljárásként (Managed (CLR) Stored Procedure) lehet közvetlenül hívni a szerveroldali T-SQL kódból. Ennek a technikának az alkalmazásával elérhetjük, hogy bonyolultabb üzleti logikát is bele lehessen csempészni a szerveroldali programozásba. Értem itt ezalatt, hogy az adatkezelést a T-SQL-re bízzuk, azonban az adatok feldolgozását .NET kóddal végezzük, így mindenki azt csinálhatja amire kitalálták. .NET-ből akár más, tetszőleges program hívható/indítható.

http://msdn.microsoft.com/en-us/library/ms131045.aspx

Az SQL Server lehetőséget ad arra, hogy Microsoft Visual C vagy C++ kódot lehessen hívni szerver oldalról (Extended Stored Procedure). Ehhez kódunkból az Opends60.lib fájllal linkelt DLL-t kell készíteni, majd a sp_addextendedproc T-SQL tárolt eljárással regisztrálni. Ezek után már ugyan úgy használható, mint egy belső tárolt eljárás. A kód annak a címtartományában fog futni, ahonnan meghívták. Kezelése nagyon hasonló az Oracle External Procedure-éhez.

http://support.microsoft.com/kb/190987

HOUG '09

2009-04-15T23:02:00.003+02:00

Véget ért az idei HOUG konferencia, melyen az elejétől a végéig részt vettem. Sajnálatosan az előadásom rajtam kívülálló okok miatt meghiúsult, azonban így is jól óreztem magam ez alatt a néhány nap alatt. Ezt nem csak a környezet alapozta meg, hanem a programok igényessége és szakmai változatossága is.
Azt hiszem a legnépszerűbb előadást Mocsai Lajos tartotta első nap, aki a sikeres vezetőről, és annak ismérveiről beszélt. Úgy gondolom a közönség nagyon évezte a beszédet, a tréner a végén vastapsot kapott.
Ezalatt a pár nap alatt sok ismerősöm tartott előadást, többek között Marton József Ernő (BME), Kocsis István (BME), Müller János (BME), Izsák Tamás (Független szakértő), Kardkovács Zsolt Tivadar (BME, U1 Kutató Központ), Sárecz Lajos (Oracle). Ha még engem is hozzávennénk a felsoroláshoz, akkor látható, hogy ezen a konferencián a Budapesti Műszaki és Gazdaságtudományi Egyetem (BME) egyre nagyobb számban képviselteti magát, ami az Oracle Hungary és az egyetem jó kapcsolatát mutatja. Misem bizonyítja ezt jobban, minthogy egy új, diákszekció is indult (Jövünk! címmel), ahol kizárólag diákok meséltek eddigi tapasztalataikról.
A szervezők gondoskodtak a szórakozásról is, minden este szponzorált programok voltak, melyek közül nekem a kedd esti GuitarHero tetszett a legjobban. Időt és energiát nem kímélve bandában zenélve szórakoztattuk magunkat és egymást (dobszekció rulez :D).
Az idei konferencia nagyon tetszett, rengeteg pozitív élménnyel és tapasztalattal tértem haza.

A közel valós idejű adattárház létrejöttének feltételei

2009-03-04T15:04:00.012+01:00

Közel valós idejű adattárházat egy hagyományos adattárház módosításával hozhatunk létre. Ahhoz, hogy megfeleljen az elvárásoknak, és az üzleti igényeket ki tudja szolgálni, alapvetően három feltételnek kell eleget tennie:

Folyamatos adatintegráció, mely az adatforrásokból az adatokat közel valós időben gyűjti és tölti az adattárházba. [1] [2]
Nagy rendelkezésre-állású analitikai környezet, melynek feladata a valós idejű adattárházra támaszkodva az üzleti döntéseket elősegítő összegzések és származtatott értékek előkészítése. Továbbá a felhasználóknak gyors hozzáférést biztosítani ezekhez az adatokhoz. [1] [2]
Szabály alapú döntéshozó komponens, melynek feladata, hogy az analitikai komponensre támaszkodva bizonyos szabályrendszert felh asználva üzleti ajánlásokat kínáljon, valamint automatikus eseményeket generáljon üzleti alkalmazások számára. [1] [2]

A CTF technológia bemutatása adattárház környezetben [3 old.: 5]

A folyamatos adatintegráció (1.) az adattárházak kezdetétől jelenlévő ETL (Extract, Transform & Load) folyamatot váltja le. Az ETL alapvetően kötegelt végrehajtásra lett kitalálva, ami a közel valós idejű megvalósításban nem kaphatott szerepet. Helyette egy CTF (Capture, Transform and Flow) modellt kell implementálni, ami a keletkezett adatokat begyűjti a forrásrendszerből, transzformálja a megfelelő formába, majd továbbítja a valós idejű adattárház felé. Ezt a harmadik fázist tekinthetjük úgy, mintha a sok különböző adatforrásból kinyert adatot egyetlen csőbe, adatfolyamként öntenénk. Természetesen a folyam célja nem csak egyetlen adattárház lehet, tetszőleges adattárak feliratkozhatnak rá, így többen is valós idejű adatokat kapnak. [3]

Mivel a CTF leváltotta az ETL-t, ezért az adattárházakban használatos egyik alapvető komponensre nincsen szükség, mégpedig az állomásoztató területre. A CTF modell a transzformációt „on-the-fly” végzi el, így nincsen szükség adattároló egységre, ahol a transzformáció előtt az adatokat tároljuk. A CTF technológia azért képes tárolás nélkül elvégezni ezt a műveletet, mert az ETL-el ellentétben nem kötegelten hajtja végre egyszerre sok adaton a transzformációt, hanem mindig csak egyen.

A valós idejű adattárház megvalósításnak a kulcsa, hogy míg az adatokat folyamatosan gyűjtjük egy valós-idejű partícióra, addig a forrásrendszerekből periodikusan érkező pillanatképeket is tároljuk egy statikus partíción. (ábra) A valós idejű partíción a forrásrendszerekből érkező adatok alapján az üzleti elemzésekhez szükséges aggregátumokat készítjük el inkrementális jelleggel. Ez a megvalósítás nem más, mint egy hagyományos adattárház, amit kiegészítünk egy valós idejű környezettel, így egyszerre van lehetőség részletekbe menő adatokat és előkészített aggregátumokat gyorsan felhasználni. [2]

A három komponensből a legfontosabb a folyamatos adatintegrációt (1.) végző folyamat. E nélkül nem lehetne megvalósítani a közel valós idejű adattárházat. Az analitikai komponens (2.) és a döntéshozó komponens (3.) nem feltétlenül szükséges a működéshez, de ha az összegyűjtött információt fel is szeretnénk használni, akkor mindenképpen érdemes implementálni őket.

Forrás:
[1]. White, Colin. Real-Time Data Warehousing Heats Up. DM Review Magazine. augusztus, 2002.
[2]. Araque, Francisco. Real-time Data Warehousing with temporal requirements. Granada, Spain, 2003.
[3]. Vandermay, john. Considerations for Building a Real-time Data Warehouse. : DataMirror, 2002.

Memóriarezidens adatbázis-kezelő

2009-02-09T23:32:00.005+01:00

A memóriarezidens adatbázis-kezelők (Main Memory Database System - MMDS) bemutatására a legjobb módszer, ha a tulajdonságait a diszk rezidens, „hagyományos” adatbázis-kezelőkéhez (Disk Resident Database System - DRDB) hasonlítjuk, mert így válnak egyértelművé azok a képességek, melyek jellemzik ezeket a rendszereket.

Első közelítésben azt gondolhatnánk, hogy egy memória-adatbázis és egy diszk rezidens adatbázis között csak annyi a különbség, hogy az előbbi az adatokat a memóriában tartja, míg utóbbi a háttértáron. Ahhoz azonban, hogy a különbséget a kettő működése között ténylegesen megértsük, mélyebbre kell ásnunk. A két rendszer sajátosságait alapvetően a kétféle adattároló médium tulajdonságai határozzák meg, ezért ezek ismerete elengedhetetlen a működés megértéséhez.

A memória és a merevlemez különböző tulajdonságokkal rendelkezik mind az adattárolás, mind az adatok hozzáférése terén.

· A memória kikapcsolás után elfelejti tartalmát, a lemez nem.

· A memóriához való hozzáférési idő legalább egy nagyságrenddel rövidebb, mint a merevlemezé, ami teljesítmény kritikus rendszerek esetében fontos tulajdonság.

· A háttértár blokkszervezésű, ami a működéséből adódik, míg a memória direkt hozzáférésű. Éppen ezért a memória minden egyes megcímezhető egységnyi tartományát ugyan annyi idő alatt érhetjük el, míg a lemez alapú tárolás esetében ez az idő változó, ráadásul még egyazon blokk esetében sem tekinthető állandónak.

· A merevlemezen tárolt adatok szervezése fontos, mivel a lemez szekvenciális hozzáférés esetén jobb átlagos teljesítményre képes, mint véletlen hozzáférés esetén. A memóriában nem annyira fontos az adatok elrendezése a teljesítmény szempontjából.

· A processzor a memóriában lévő adatokhoz közvetlenül hozzá tud férni, míg a merevlemezen tárolt adatokhoz nem. Emiatt a memória-adatbázisban lévő adatok sérülékenyebbek ebből a szempontból.

Ezek a tulajdonságok alakították ki a memóriarezidens adatbázis-kezelő rendszer felépítését és működését. [1]

Az alábbiakban bemutatom, hogy egy memóriarezidens adatbázis-kezelő hogyan teljesíti egy adatbázis-kezelő jellemző funkcionális feladatait:

Konkurens adathozzáférés - Zárkezelés ugyanúgy megvalósítható, mint a diszkrezidens adatbázis-kezelő rendszerek esetében, azonban erre nem minden esetben van szükség. Mivel a memóriában sokkal gyorsabban férhetünk az adatokhoz mintha merevlemezen tárolnánk őket, ezért az egyes műveletek is rövidebb ideig tartanak . Ez pedig azt jelenti, hogy a konkurens műveleteknek a valószínűsége is kisebb. Ebben az esetben megfontolandó a műveletek szekvenciális végrehajtása, mert a zárkezelés megvalósítása egy ilyen rendszerben jelentős overhead-et jelent.

Commit kezelés, tranzakciós naplózás - Mivel a memória sérülékeny, rendszerhiba esetén az adatok elveszhetnek. Ennek elkerülésére a tranzakciós műveleteket naplózni (tranzakciós log) kell és ezt a naplót olyan helyen tárolni, ahol védve van egy kritikus rendszerleállástól. A tároló média elsősorban merevlemez lehet, ami azt jelenti, hogy a költséges I/O műveletek teljes egészében nem eliminálhatóak egy memóriarezidens adatbázis rendszerből. Minden egyes commit előtt a változásokat ki kell írni a log (napló) fájlba.
Alternatív megoldásként szóba jöhet egy olyan architektúra, ahol a napló legfrissebb részét egy nem felejtő, kis kapacitású memóriában tároljuk. Onnan pedig egy független folyamat rendszeresen átmozgatja a bejegyzéseket a merevlemezen tárolt végleges log fájlba. A funkcionalitás mit sem változott, a tranzakciónak azonban sokkal kevesebbet kell a naplózás miatt várnia.

Adathozzáférés - A keresett rekordok megtalálásához az adatbázis-kezelő rendszerek indexelési technikát használnak. Diszkrezidens adatbázisokban B^-fa indexet használnak, mert ez az indexelési eljárás a legmegfelelőbb a merevlemez adattárolási struktúrájához. Ez azonban a memóriában való kereséshez nem a legoptimálisabb. A T-fa kifejezetten a memória-adatbáziskezelők részére lett kifejlesztve. A legjobb megoldás azonban arra, hogy egy rekordot megtaláljunk a memóriában, hash táblák használata. Ezzel azonban intervallumkeresés nem hajtható végre. [2]

Adatkezelés - Minden egyes adatnak az adatbázisban van egy memóriacíme, mely a memória egy területére mutat. Ezzel könnyen lehet kezelni akár változó méretű mezőket is, mert egy rekordot a memóriában egy pointer gyűjtemény reprezentál. Ha egy táblának kicsi a kardinalitása, akkor az azonos értékeket csak egyszer kell tárolnunk, és elegendő csak erre a címre hivatkozni az érintett rekordoknak. Ez nagy adatméret esetén rendkívül hatékony adattárolást jelent.

Lekérdezés optimalizálás - A diszkrezidens adatbázis-kezelők lekérdezés optimalizálója a költséges I/O műveletek minimalizálását tartja elsődlegesen szem előtt. Ehhez költség alapú elemzéseket végez, mielőtt kiválasztani azt a végrehajtási tervet, mely a legrövidebb végrehajtási idővel kecsegtet. A memória-adatbáziskezelőkben ez a stratégia nem biztos, hogy a legjobb megoldást adja, mivel a legnagyobb költséget nem feltétlenül az adatok elérése jelenti. Sokkal inkább az egyes műveletek számítási ideje. Éppen ezért érdemes ezeket a műveleteket a lehető legjobban csökkenteni, úgymint indexek építése, felesleges adatmásolatok készítése. A lekérdezések optimalizálása ezért memória-adatbázisokban javarészt rendszerfüggő.

Helyreállítás kezelés - A biztonsági mentés és helyreállítás ugyanúgy működik, mint egy hagyományos adatbázis-kezelő rendszer esetében. A rendszer működéséről teljes mentést készíthetünk, amit a merevlemezen tárolunk. Ha ezt a tranzakciós naplózással kombináljuk, akkor egy teljesen megbízható rendszert kapunk, mert kritikus rendszerhiba esetén a memória tartalma törlődhet ugyan, de a biztonsági menésként tárolt checkpoint fájlból és az azóta eltelt tranzakciós naplóból a hiba előtti állapot teljes mértékben visszaállítható. Egy memóriarezidens adatbázis-kezelőnek a háttértárat kezelni csak naplózáskor és biztonsági mentés készítésekor kell, valamint helyreállításkor.

Teljesítmény - A hagyományos adatbázisrendszerek a teljesítményt elsősorban az I/O műveletek alapján becslik meg. Memória-adatbáziskezelő esetén alapvetően a műveletek processzorideje számít, tehát más metrika alapján számítható a teljesítmény, ennek ellenére a háttértárműveletek is befolyásolják azt. Ha a teljesítmény előbbre való, mint az adatok integritása, akkor nem kell tranzakciós naplózás. Ekkor azonban rendkívül sérülékeny a rendszer, és adatok veszhetnek el. Ha a legfőbb szempont az adatok biztonsága, akkor ezeket a háttértárigényes folyamatokat be kell kapcsolni, ami viszont a teljesítmény rovására megy. Természetesen a biztonsági mentés gyakoriságának állításával az átlagos teljesítmény mértéke befolyásolható, de a maximális teljesítményt a tranzakciós naplózás miatt biztosan nem érheti el.

API és védelem - Egy memória-adatbázisnak meg van az az előnye a diszkrezidenssel szemben, hogy a még nagyobb teljesítmény érdekében direkt kapcsolódási módot biztosítson a programozónak. Ez azt jelenti, hogy az adatbázis-kezelő a program rendelkezésére bocsátja az általa használt memóriaterületet, és objektumok helyett memóriacímeket küld ad át, így a program közvetlenül olvashatja ki a rekordokat. Ennek a módszernek az előnye, hogy nincs szükség felesleges objektummásolatokra a küldő pufferbe, hanem egyből kiolvasható az eredmény. Ez azonban a hátránya is, mivel csak körülményesen garantálható a többi adat biztonsága a memóriában. Ráadásul ez csak akkor használható, ha a program és az adatbázis-szerver egyazon hoszton helyezkedik el, mert közös memóriaterületet használnak. Természetesen a programok kapcsolódhatnak az adatbázishoz az egységes programozói interfészen (ODBC - Open Database Connenctivity) is.

Adatcsoportosítás – klaszterezés - Memóriarezidens adatbázis esetén nincsen szükség az adatok csoportosítására, mert a rekordokat egy-egy memóriacím azonosít a memóriában. Mindegy, hogy hol helyezkedik el, mert az nem befolyásolja az adathozzáférési időt. Ez azonban egy problémát is felvet, amikor diszkrezidens adatbázisba szeretnénk migrálni a memória-adatbázist, mert nem egyszerű eldönteni, hogy mely rekordok kerüljenek egy klaszterbe. [1]

Felmerülhet a kérdés, hogy ha egy memóriarezidens adatbázis-kezelőnek nem kell megküzdenie a rendkívül költséges háttértárműveletekkel, akkor miért nem használjuk őket a diszk alapúak helyett? Erre egyszerű a válasz. Azért nem, mert egy adatbázis sok esetben olyan nagymennyiségű adatot kezel, ami nem fér el a memóriában. Ez azonban nem azt jelenti, hogy ez a megvalósítás teljesen működésképtelen és használhatatlan. A memória előállításának költsége napjainkra drasztikusan lecsökkent, ezért a kereskedelmi forgalomban kapható modulok ára egyre alacsonyabbak lettek. A mai rendszerekben már nem ritka a 128GB, 256GB vagy akár az 512GB memória sem (ezek nagyon szerény becslések, mert vannak olyan top konfigurációk, melyekben akár 4096GB memória is lehet). Éppen ezért megfontolandó, hogy egy adatbázist memóriarezidens adatbázis-kezelőre bízzunk, vagy sem. Mivel a tárolási kapacitás egyre kevésbé jelent problémát, a minél jobb teljesítmény érdekében egyre több memória-adatbázis fog megjelenni.

Jelenleg sok esetben fordul elő, hogy egy hagyományos adatbázis ugyan nagy méretű, de szükség lenne a felgyorsítására memória-adatbázis segítségével. Ekkor az adatokat csoportosítani kell, hogy melyek azok az adatok, amelyeket sűrűn, rendszeresen használnak, és melyek azok, amelyeket csak ritkán. Ezek közül a gyakoribb adatokat érdemes a memória-adatbázisba tölteni, hogy azokat gyorsan el lehessen érni. Ha az adatbázisunk nem csak olvasható, akkor szinkronizációs problémák léphetnek fel a két adatbázis között, melyeket meg kell oldani (ez azonban implementációs kérdés). Az így létrejött architektúra tekinthető a hagyományos adatbázis kiterjesztésének egy memória-cache segítségével.

Mi a különbség egy memória-adatbázis és egy nagy pufferel rendelkező diszkrezidens adatbázis között?

Ha egy hagyományos adatbázisnak elegendő memória áll a rendelkezésére, hogy minden adatot a memóriában tartson, akkor gondolhatnánk, hogy így elérhetjük egy memória-adatbázis teljesítményét. Ez azonban tévedés, mert ekkor még mindig egy diszkrezidens adatbázis-kezelő kezeli az adatokat. Ahhoz, hogy egy alkalmazás hozzáférjen egy rekordhoz először a kezelő kiszámítja a diszken lévő helyét, utána a pufferkezelő lekérdezni, hogy esetleg a memóriában van-e? Mivel ott van, onnan átmásolja a küldő pufferbe, ahonnan az alkalmazás már elérheti a kívánt rekordot. Ehhez természetesen a blokkszervezésű, lemezre optimalizált B-fa indexet is fel kellett használni.

Ezzel szemben a memóriarezidens adatbázis-kezelő miután megkapta, hogy melyik rekordra van szükség, a hash táblával meghatározza a memóriacímet és ezt átadja az alkalmazásnak (direkt hozzáférés esetén). Ebből is látszik, hogy ez mennyi felesleges számítást spórol meg.

Forrás

[1]. Main Memory Database Systems: An Overview. Garcia-Molina, Hector és Salem, Kenneth. 1992., IEEE Transactions on Knowledge and Data Engineering, old.: 509-516.

[2]. Oracle Corporation. Oracle TimesTen Products and Technologies. Redwood Shores, California, U.S.A. : Oracle Corporation, 2007.

HOUG előadás

2009-01-18T14:56:00.005+01:00

Nagy örömömre szolgál, hogy az idei HOUG-on (nagy valószínűséggel) előadóként fogok részt venni. Az előadás a TDK-ra készített IPTV rendszerhez készített kiszolgáló rendszer prototípusát, a tervezés nehézségeit és a megvalósítást mutatja be. Az előadást természetesen nem egyedül fogom tartani, mivel a megoldás, amivel pályáztunk több embert is érint a tanszékről, a társam Kardkovács Zsolt lesz.
A félév eleji megbeszélésekkor Sárecz Lajos leszögezte, hogy az idei HOUG részvétel feltétele lesz egy TDK dolgozat megírása, azt azonban remélni sem mertem volna, hogy ilyen szorosan fog kapcsolódni a HOUG-hoz. Számomra ez mindenképp nagy lehetőség, hogy gyakoroljam és fejlesszem előadási képességeimet nagyközönség előtt (reméljük sokan kíváncsian lesznek ránk), ráadásul a gyenge TDK szóbeli szereplésemet is javíthatom.
Ezek az információk még nem hivatalosak, mert csak a pályázatot adta le Zsolt, a program még nem készült el az idei HOUG-ra. Ha majd ott szerepel a nevünk és témánk a programban, akkor válik véglegessé.
Addig is érdemes néha ránézni a HOUG hivatalos honlapjára, hátha felkerült már a program.

TimesTen telepítés windowsra

2009-01-18T00:21:00.005+01:00

A minap bukkantam erre a kis Viewlet-re, amely összesen 64 állomáson keresztül segíti a kezdő TimesTen telepítőket. A bemutató windows környezetben lett felvéve és nagyon szemléletesen mutatja be, hogy nem is kell olyan bonyolult utat bejárnunk ahhoz, hogy egy működőképes TT példányunk legyen kedvenc operációs rendszerünkön.
Felhívnám a figyelmet azonban arra, hogy a telepítés egyszerűségével szemben a TimesTen példányunk és a DataStore-ok kezelése velősebb feladat. Ehhez segítséget itt találhatsz, a hivatalos dokumentációk között.
Jó szórakozást!

HOUG 2009

2009-01-11T12:58:00.004+01:00

Mint minden évben, idén is megrendezésre kerül a HOUG (Hungarian Oracle User Group) konferenciája április 6-9-ig. Az eseményre lehetőség van előadóként pályázni, melyről már több hírportál is beszámolt: computerworld, hwsw. A pályázat menetéről, feltételeiről és pontos kiírásáról a HOUG hivatalos weboldalán kaphatsz tájékoztatást. A helyszín a régi, a Balaton partján lévő Hotel Azúr, Siófok ad otthont a találkozónak.
A tavalyi tapasztalatok alapján idén is érdekes és szakmai tartalomban gazdag előadásokat hallgathatunk végig, melyet az igényes környezet és a szálloda szolgáltatásai még kellemesebbé tesznek.

Önlab III

2008-12-11T17:10:00.008+01:00

Ez a félév is eltelt és nem is kevés munkával. A korábbi bejegyzésemben beszámoltam a TDK-n belül végzett munkámról, tapasztalataimról. Ezen kívül az Önálló laboratóriumot is teljesíteni kellett, amihez nagyon jó alapnak szolgált a félév közben megírt dolgozat. A szóbeli beszámolót megúsztam, mert a TDK-val kiváltható volt, de az írásbelit meg kellett írnom. A legtöbb munkám nem a tartalommal, sokkal inkább a formai követelmények betartásával volt. 10-12 oldal terjedelmű beszámolót kellett írni. Nekem kb. 16 oldal lett volna kényelmes, ez azonban talán a 2-es jegyet sem érte volna el, ezért beltuszkoltam 12 oldalba. Visszajelzést majd csak a neptunból kapok, ha beírják a jegyet. A dolgozat itt érhető el.

TDK

2008-11-21T21:42:00.003+01:00

Egy hónapja, hogy nem írtam a webnaplómba. Az elmúlt időszakban nem volt sajnos túl sok szabadidőm, mert a legfontosabb dolog a TDK munkám megírása volt. Ez azonban minden fáradtságot megért, mert a 2008-as TDK konferencián 3. díjat nyertem.
A felkészülési időszakban nem telt el úgy nap, hogy ne foglalkoztam volna vele. A leadási határidő közelében pedig egyenesen "ennek éltem". Nem azért, mert szörnyen élveztem, hanem azért, mert elhatároztam, hogy megcsinálom. Ha már majdnem egy hónapnyi munkám benne volt, akkor az a két-három átdolgozott éjszaka nem számított. Az utolsó napokban nem sokat aludtam, a leadás előtti éjjel pedig semennyit. Mivel elég kevés idő alatt terveztük meg és írtam meg a dokumentációt, ezért nem lett tökéletes, de a körülményekhez képest szerintem egészen jól sikerült.
Egy korábbi bejegyzésemben már említettem a témát, azonban részletesebben még nem mutattam be a tervezett rendszert, amely egyébként két Oracle11g adatbázisra épült, és mindegyikhez tartozott egy-egy TimesTen cache is. Egy egyoldalas összefoglaló itt olvasható: absztrakt.
A TDK dolgozat leadása után kicsit szusszanhattam, de a munkának még koránt sem volt vége. Következett a konferencia, ahol szóban, 20 percben kellett bemutatni, hogy mit csináltam. Erre összesen két hét felkészülési időm volt. Mivel hátra volt még némi implementáció is, ezért az előadás előkészítésére szánt idő körülbelül megfeleződött. Az implementáció technikai akadályokba ütközött, így az előadásra nem tudtam elkészülni bizonyos mérésekkel.
A Szoftver szekcióba kaptam jegyet, melynek elnöke a konferencián Dr. Pataricza András volt a MIT tanszékről. A részletes szekció program itt olvasható: Szoftver szekció, TDK, 2008
Szerencsére névsorrenben következtek egymás után az előadások, így harmadikként adhattam elő. Nagyon izgultam előtte, ezért nem éreztem magam magabiztosnak előadás közben. Ezt a 15 perces prezentáció utáni 5 percnyi kérdésnél tovább rombolták a jobbnál jobb kérdésekkel. Zsolt véleménye szerint a szóbeli előadásom előtt jobb helyen szerepelhettem a szekció rangsorban, mint utána. Van benne valami. Inkább túléltem, mint megéltem a prezentációmat. Se' baj, tanulópénz. Egy biztos, nagyon sokat tanultam belőle. És nem csak a szóbeliből, hanem a teljes 4+2 hétnyi munkával töltött időszakból.

III. Oracle Blogger Dinner

2008-10-25T17:07:00.003+02:00

Eljött az idő, hogy megtartsuk szokásos találkozónkat, melyre jövő hétfőn délután 17:00-kor kerül sor. Lajos elküldte a meghívókat, ahogy elnéztem a címlistát, szép számmal leszünk jelen. A helyszín még nem biztos, de gondolom a szokásos helyen, a Déli Point irodaház 5. emeletén lesz. Az immár szokásos pizza mellé egy kis fejtágítást is fogunk kapni, melyet Tánczos Zoltán végez majd előadás formájában. A téma pedig SQL Server migráció Oracle adatbázis-kezelőre. Egy konzultáció alkalmával már volt szerencsém valamennyit megtudni, hogy mit is fogunk hallani. Szerintem érdekes lesz mindenki számára, aki eljön.

Félév eleji köszöntő

2008-10-06T12:20:00.005+02:00

Már régen jelentkeztem, leginkább azért, mert a nyári időszakban leginkább a pihenés és nyaralás volt előtérben. Szeptember beköszöntével elkezdődött egy új félév, számomra a 9-edik. Ez azt jelenti, ha minden jól megy, akkor a következő félévben tervezhetem a diplomámat. De addig van dolgom bőven, pláne, hogy egy kis lemaradást is elkönyvelhettem a következő félévben. A Számítógépes grafika nem tartozik a könnyen teljesíthető tárgyak közé. Nekem sajnos már harmadszorra kellett felvennem, és ha diplomázni akarok, akkor most már meg kell csinálnom.
Rögtön a félév elején nagy fába vágtam a fejszémet, mert Kardkovács Zsolt rábeszélt, hogy írjak meg egy TDK dolgozatot, hejj, de jó lesz nekem akkor. Nos, kis hezitálás után beláttam, nem olyan nagy hülyeség, végtére is az Önálló labor keretein belül is valami ilyesmit kéne csinálnom, így mondhatjuk két legyet üthetek egy csapásra. Bele is kezdtem gőzerővel a téma feldolgozásába, ami nem áll olyan messze attól, amivel eddig foglalkoztam. A dolgozat címe: Valós idejű analitikai rendszer támogatása állandó hozzáférésű adatpiac segítségével
Ebben a félévben kell tehát teljesíteni az Önálló laboratórium 3-at, amiből már meg is volt az első közös konzi. Jelen voltunk vagy 11-12-en, ami a csoport felét sem teszi ki. Zsolt, mint a csoport fő konzulense igyekezett egy kis ízelítőt adni az új önlabozóknak, valamint megkérdezett minket, "öreg motorosokat", hogy mivel is foglalkoztunk eddig, mondjunk róla pár szót. Ez után Sárecz Lajos beszélt egy kicsit, hogy az Oracle hogyan támogatja a munkánkat és ezért mit vár el. Idén is a blogírás alappillére a jó kapcsolatnak, de a HOUG-on való részvételt most egy TDK dolgozat megírásához kapcsolta.
Néhány szó erejéig megemlítem, hogy idén is elindult a MAVE (Magyar Villamosmérnök- és Informatikus-hallgatók Egyesülete), Oracle, BME TMIT (BME Távközlési és Médiainformatikai Tanszék) szervezésében az Oracle szemináriumsorozat, melyről bővebb információt itt olvashattok.

Adósság

2008-08-07T17:17:00.004+02:00

Egy kis késéssel ugyan, de közzé teszem a félév során összehozott rendszertervet, melyet a témában írtam. Ez a rendszerterv közös alapokon nyugszik Nyárády Péter rendszerével. A vizsgaidőszak után kellett még egy kicsit dolgoznom rajta, míg tartalmilag és küllemre is megfelelt az elvárásaimnak.
Ezt most megosztom a nagyközönség számára is: Hallgatói Információs Rendszer - Rendszerterv
A félév során összesen 34 oldal dokumentációt írtam, melybe beletartozik az itt a blogon közzétett néhány cikk is.
A következő félévig jó nyaralást kívánok mindenkinek!

"Gyorsfagyasztott" adatbázis szerver

2008-07-15T19:40:00.003+02:00

Az elmúlt hét eseményei annyira felkorbácsolták itthon a hangulatot, hogy még mindig nem sikerült kihevernem teljesen. Épp a legfrissebb Oracle InDepth hírlevelet olvasgattam, amikor egy mondat a TECH DIVE rovatban hirtelen szemetszúrt: "Deploy Linux Faster with Oracle Validated Configurations". Érthető módon azonnal kattintottam, hogy a cím mögötti tartalom is előkerüljön. Mint kiderült, más is sok időt eltöltött már linux telepítéssel és véleményének hangot is adhatott, mert az Oracle-nek van egy csapata, akik előretelepített konfigurációkat gyártanak, tesztelnek és validálnak (szép magyar szó:D). Mikor ezt megtudtam, akkor szidtam az Istent, hogy ez a levél hamarabb is landolhatott volna a postaládámban. Viszont akkor nem biztos, hogy felfigyelek erre a mondatra. Mindegy. Tovább nézegetve a letölthető konfigurációkat rájöttem, hogy nem igazán ilyen garázs projektekhez állították össze őket, mint az enyém. Van a listán HP, Dell, IBM szerver, de sok más gyártó termékei is. Összesen 61 konfigurációt számolhatunk össze (foylamatosan bővítik), melyek megbízhatóan működnek. Vannak 10g, 11g szerverek OEL4 vagy OEL5-tel, VM-mel vagy anélkül, RAC-cal vagy nélküle. Szóval színes a lista. Az én AMD Sempron 2600+ -os x86-osomhoz nem találtam konfigurációt :D Talán egyszer majd arra is sort kerítenek...

11g on OEL5

2008-07-07T19:10:00.017+02:00

Engem is utolért a végzet, mint sok más blogger kollégámat. Linuxra 11g-t telepíteni nem hogy nehéz, de egyenesen lehetetlen [...ha nem értesz hozzá:)] Itt megjegyezném, hogy a sokat szidott operációs rendszer kapott tőlem pár plusz pontot ez idő alatt - főleg a kényelem és használhatóság terén - , de azért a linuxot sem becsülöm le.

Nagy ötletem volt a félév végén. Próbáljuk ki, hogy amit megterveztünk hogyan működik valójában. Ehhez össze kell állítani egy tesztkörnyezetet, ami egy Oracle 11g szerverből áll, valamint egy vele hálózatba kötött gépből, amin egy kliens alkalmazást futtatunk, ami elvégzi a szükséges funkciókat. Arra gondoltam, hogy itt az alkalom kipróbálni az Oracle által szállított Enterprise Linux legújabb 5-ös verzióját (félreértés ne essék, életemben egy linux disztribúcióval volt dolgom, azzal sem sokáig), mert azt gondoltam, hogy ezzel lesz a legkevesebb telepítési és konfigurációs probléma. Tévedtem. Nem vehetjük kézpénznek az Oracle által támogatott Linux disztribúció (Oracle Enterprise Linux 5 - OEL5) és saját adatbázisuk (Oracle Database 11g) felhőtlen viszonyát.

Telepítés előtt felkutattam azokat a dokumentációkat, melyek segítenek a telepítésben és felhívják a figyelmet a kritikus pontokra (van belőlük bőven). Amíg vártam, hogy levánszorogjon az 5 CD-s OEL5, valamint a 11g (1.7G), átolvasgattam, hogy mire kell felkészülnöm, milyen műveleteket kell végrehajtanom a helyes konfiguráció elérése érdekében. Itt megemlíteném, hogy az Oracle munkatársai csak CD-s verzióban bocsátják rendelkezésünkre az ingyenes Linux disztribúciójukat. Természetesen van 1 DVD-s verzió is, de azt postai úton kell megrendelni valamennyi térítés ellenében. Mivel manapság CD-t nem használok, ezért kicsit hülyén éreztem magam, miközben DVD-re írom ki a 700 megás képfájlokat.

A linux telepítés viszonylag simán ment elsőre (legalábbis akkor még azt hittem), csak utána kezdődtek a gondok. Mondhatom, hogy amikor behelyeztem a letöltött és DVD-re kiírt 11g legújabb verzióját, megkezdődött vesszőfutásom.
A telepítési útmutatóban leírtaknak megfelelően létrehoztam a felhasználókat és könyvtárakat, megadtam a jogokat, ezzel nem volt semmi gond. A telepítő is elindult sikerrel, beállítottam a kívánt paramétereket, amolyan Windows User módjára nyomkodtam a Next-et. Ezután elkezdte felmásolni a fájlokat, de csak egy darabig, mert kis idő elteltével hibüzenetet kaptam, mely arról árulkodott, hogy szüksége lenne egy .oui fájlra, de sehol sem találja a DVD-n. Gondoltam hú de jó, még ez is, lehet hegesztgetni a frissen kiadott adatbázis telepítőjét. Rákerestem magam is a fájlra, hogy esetleg valami elérési út probléma állhat-e a probléma mögött, de nem találtam egyáltalán a médián. A következő lépés az volt, hogy a tömörített képfájlban megtalálom-e, mert ha igen, akkor a tömörítéssel lehetett gond. Természetesen abban meg volt, csak DVD-re nem került rá valahogy. Még egyszer kitömörítettem a TotalCommander-em beépített tömörítőjével, csak a teszt kedvéért. Nem csalatkoztam, a tömörítés hiánytalan volt. Egyetlen láncszem maradt a folyamatban, amely a hibát okozhatta, mégpedig az író program. Világ életemben az Ahead Nero programját használtam CD/DVD írásra, mert részletesen be lehetett állítani, de az új gépemen valamiért egy másik szoftver van fent. Roxio Creator Basic. Egyszerű felület, még az írási sebességet sem kell beállítani(természetesen van rá mód), és kész is a lemez. Most is jól elintézte, mert úgy néz ki, hogy a számára értelmezhetetlen fájlokat egy adatlemez készítésénél önkényesen kihagyja, és még csak nem is tájékoztat a műveletről. Így történt, hogy a ".oui" nevű fájl nem felelt meg az elnevezési konvenciónak és lemaradt a lemezről. Az esetből tanulva az archiv fájlt írtam ki a DVD-re és a tömörítést a felmásolás után parancssorból végeztem, ahogy a telepítési útmutató is ajánlotta.

Újra belevágtam a telepítésbe és sikerrel jártam. Egy aggasztó képernyő fogadott a konfigurációs panelnál. Mégpedig az operációs rendszer(OEL5) adatbázishoz szükséges hiányzó csomagjainak a listája. Nem volt rövid. Kérdem én. Miért hihányoznak ezek a csomagok? Miért nincsenek feltelepítve? Talán elrontottam a telepítést? Nem a default módot kellett volna választani, hanem a Telepítés adatbázis számára? De ilyen opció nem volt. Akkor miért nincsenek alap esetben telepítve ezek? Hiszen ki a fene választaná az Oracle által csomagolt operációs rendszert, ha nem az, aki az Oracle adatbázis-kezelőjét szeretné használni? Más biztos nem választja, hiszen igazából egy összepofozott RedHat Linuxról van szó. Nem értem. Ezzel a problémával más is szembe találkozott és nem hagyta szótlanul: oracle forum.

Belenyugodtam, hogy ez a telepítés nem lesz egy leányálom és tovább kutakodtam, mi módon fogok egy minden Error és Warning nélküli, jól működő Oracle adatbázist kapni Linuxra telepítve. A hivatalos telepítési doksiban van egy "Pre-installation tasks" rész, de azt eddig átugrottam, mert nem feltételeztem, hogy csomagokat kell telepítgetnem ehhez az "összeszokott pároshoz". Tévedtem. -Azt azért megemlítem, mivel gyakorlatlan Linux használó vagyok, ezért még egyszer megkíséreltem egy "Clear install"-t a pingvines csodából és nagyon megnéztem a telepítési módokat, hátha van olyan, hogy "Install Linux for Oracle Database", de sajnos nem volt. Sebaj, legalább nöttek a tapasztalati pontjaim Linux telepítésből.- Tehát nekiláttam a csomagok telepítésének a leírás alapján. Már az első lépés után egy halom hibaüzenetet kaptam, ami természetesen nem volt betervezve, így a leírás alapján nem tudtam(/lehet) felrakni a kívánt csomagokat, melyek megtalálhatóak a telepítő CD-ken. Igazából ezekre a csomagokra van szükség a 11g telepítéséhez:

* binutils-2.17.50.0.6
* compat-libstdc++-33-3.2.3
* compat-libstdc++-33-3.2.3 (32 bit)
* elfutils-libelf-0.125
* elfutils-libelf-devel-0.125
* gcc-4.1.1
* gcc-c++-4.1.1
* glibc-2.5-12
* glibc-2.5-12 (32 bit)
* glibc-common-2.5
* glibc-devel-2.5
* glibc-devel-2.5-12 (32 bit)
* libaio-0.3.106
* libaio-0.3.106 (32 bit)
* libaio-devel-0.3.106
* libgcc-4.1.1
* libgcc-4.1.1 (32 bit)
* libstdc++-4.1.1
* libstdc++-4.1.1 (32 bit)
* libstdc++-devel 4.1.1
* make-3.81
* sysstat-7.0.0

Ha default Linux installt csinálunk, akkor a következő csomagokat kell még feltelepíteni:

* compat-libstdc++-33-3.2.3
* compat-libstdc++-33-3.2.3 (32 bit)
* elfutils-libelf-devel-0.125
* gcc-4.1.1
* gcc-c++-4.1.1
* glibc-devel-2.5
* glibc-devel-2.5-12 (32 bit)
* libaio-devel-0.3.106
* libstdc++-devel 4.1.1
* sysstat-7.0.0

Itt hozzátenném, hogy nem csak ezekre a csomagokra lesz szükség, hanem a függőségek figyelembe vételével azokra is, amelyekre ezek támaszkodnak. Szerencsére minden szükséges csomag megtalálható az 1., 2., 3. CD-ken.

Most már készen állok az adatbázis telepítésére. Ezt mi sem bizonyítja jobban, mint a telepítő "Product-Specific Prerequisit Checks" oldalán a "Checking operating system package requirements" teszt megfeleltté van nyilvánítva. Igen! Megcsináltuk! :D A telepítés további részletei nem voltak érdekesek, pont úgy kell, mint Windows-on, hála a java alapú telepítő GUI-nak.

Nem esett még szó a tárhelyről. Elvileg ajánlatos Automatic Storage Managementet(ASM) alkalmazni, de mivel ezen a gépen van még két NTFS partíció, amolyan Windows célokra és nem nagyon bízom meg az ilyen automatikusan konfigurálódó, particionáló és formázó technológiákban, ezért ezt nem alkalmazom. A vas egy 2600+ Sempron, 1G memóriával. Ehhez egy 2Gb méretű SWAP-ot foglaltam le, valamint vagy 50Gb EXT3 fájlrendszerű tárterületet. Egyébként a telepítő doksiban is az EXT3-at ajánlják.

Összegzésül elmondanám, hogy a nehézségek ellenére nem bántam meg, hogy "felszenvedtem" egy 11g-t OEL5-re. Azonban megfontolandó, hogy ha erre a NAGYON támogatott operációs rendszerre ennyi megpróbáltatás árán sikerült telepíteni a szoftvert, akkor egy olyan rendszerrel mennyi gond lehet, amely a KEVÉSBÉ támogattottak listáján csücsül. Ha bárki hasonló telepítési gondokkal küzd, mint amikkel én is szembe találkoztam, annk egy jó tanács, hogy a csomagokat figyelmesen telepítse fel. Ehhez nyújt segítséget ez a pár dokumentáció:
* Installing Oracle Database 11g Release 1 on Enterprise Linux 5 (32- and 64-bit) by John Smiley
* Installation of Oracle 11g Release 1 (11.1.0.6.0) on RedHat EL 4, 5 and (Oracle) Enteprise Linux 4, 5
* Install 11g on Unbreakable Linux 5 failing on Community Discussion Forums, Oracle

Pém Gábor blogjában lehet még olvasni 11g telepítési HowTo-t. Ő Debian-nal próbálkozott és érdekes problémákba ütközött, melyekre mind megtalálta a megoldást:
* Oracle 11g telepítése Debian 4.0 Etch-re (AMD64) - Előkészületek
* Oracle 11g telepítése Debian 4.0 Etch-re (AMD64) - Az adatbázis telepítése
* Oracle 11g telepítése Debian 4.0 Etch-re (AMD64) - Telepítés utáni feladatok

foci EB

2008-06-11T15:07:00.006+02:00

Annak idején, amikor beadtam az írásbeli beszámolóm anyagát, akkor még korán sem voltam kész. De úgy gondoltam, hogy a tárgyfelelősnek így is jó lesz. Tudom, kicsit gonosz, de jó lett... Úgy érzem, hogy jóval kevesebb munkával is lehetett volna teljesíteni ezt az önlabot, ha csak erre a dolgozatra koncentrálok. De nem így lett, és utólag már nem bántam meg. A félévi munkámat reprezentáló dokumentum közel 34 oldal lett (összehasonlításul a tárgyfelelősnek szánt verzióval, ami 11 oldal minden klisével és képpel együtt), igaz van pár majdnem ugyan-olyan oldal, de képet csak egyet tartalmaz. A rövidebb dokumentumból pont az maradt ki, ami a félév lényege volt számomra, de ezt a véglegesben már pótoltam. Az adatbázis memória hangolása érdekes téma volt, de szerintem még nem sikerült kimerítenem teljesen. Az elméleti megfontolásaimat jó lenne teszteken is látnom, hogy tényleg gyorsabbá tudtam tenni ez által a lekérdezéseket. Lehet, hogy a nyáron összeállítok egy tesztkonfigurációt, amin megnézem mindezeket. Érdekes lenne a TimesTen-nel is tesztelni a teljesítményt. Majd meglátjuk. Mindezek előtt a maradék 4 vizsgámat szeretném sikerrel teljesíteni, ami még 20 kredit :D Eddig már zsebben van 21, de a szakirányos tárgyak még hátra maradtak. Na és a foci EB...

II. Oracle Blogger Dinner

2008-05-29T10:23:00.002+02:00

Második alkalommal kerül megrendezésre az Oracle Blogger Dinner (2008. június 9 17:00, Oracle irodaház), melynek nem titkolt szándéka, hogy lehetőséget teremtsen a magyarországi Oracle bloggereknek a személyes találkozásra. Kaptunk meghívást szép számmal, remélem mindenki el tud jönni. Ez csak egy rövid találkozás lesz, de nem esemény nélküli. A végleges program még nem hivatalos, de elöljáróban annyit elfecsegek, hogy lesz egy előadás Application Express témakörben, valamint többen fogunk a nemrég megrendezett HOUG2008-ról élménybeszámolót tartani.
Izgalmas eseménynek ígérkezik. Aki kapott meghívást de nem szeretne eljönni, az is gondolja meg, mert a kötetlen beszélgetések közben némi pizza és üdítő is található majd a teremben...

Félév végi hajtás

2008-05-18T13:57:00.002+02:00

Mint minden félévben, ebben is a szorgalmi időszak vége a leghúzosabb, mert minden munkának ekkor van a határideje. Ilyenkorra kell befejezni a házikat, összeállítáani a prezentációt, és a pótzh-kat is ekkor lehet csak megírni. Ezek közül számomra most mind kijutott, így nem tudtam a blogommal foglalkozni.
Most azonban sok mindenről kell beszámolnom, mert Önlab II-ből is elkészültek anyagok, amiket megosztok veletek.
Először is egy rendszerterv elkészítése volt a feladat ebben a félévben, ami még most sem készült el teljesen. A tárgyfelelősnek ezt írásban és szóban is be kellett mutatni. Az írásbelivel sajnos késtem pár napot, mert elnéztem a beadási határidőt a Pünkösd hétfő miatt. Na jó, nem néztem el, csak lusta dög voltam időre megcsinálni :). Meg is lett az eredménye :(. Be kell valljam, kicsit későn kaptam észhez, hogy egy rendszertervvel még adós vagyok. Nyárády Petivel összefogtunk, mivel hasonló a témánk - optimalizálás- , ezért az alapkoncepció lehetne közös. Marton Józsival gyorsan le is ültünk konzultálni, az első ötletünket lefújta, ami egy számlázó rendszer volt. Jogosan, teszem hozzá, mert nem tudjuk, milyen folyamatok zajlanak pontosan egy ilyen rendszerben. Aztán egy kézenfekvő dolog jutott eszünkbe. Hallgatói információs rendszer, vagyis Neptun, de mégsem az. Ez már jónak bizonyult. Petivel gyorsan össze is dobtuk az adatbázis sémát, amihez a szkriptet utána megcsinálta PLSQL és TSQL nyelven is. Ez volt a kiindulási alap. Innentől ő az SQL optimalizálással foglalkozott nagyrészt, én pedig a helyes rendszer konfiguráció - értem itt ezalatt az adatbázis memória kiosztását (SGA) - megalkotásával töltöttem az időmet. Azonban rossz stratégiát választottam. Úgy gondoltam, hogy először megcsinálom a teljes koncepciót, aminek nincsenek formai, csak tartalmi követelményei, és majd ebből kiemelem a lényeget és beadom azt a tárgyfelelősnek. Na emiatt kicsúsztam a határidőből és későn változtattam az elképzelésemen. A tanulmány megírásának a felénél belekezdtem a kiírt formai követelményekbe tuszkolni az irományt, ami nem volt túl egyszerű, és időm sem maradt elég, ráadásul nem sikerült mindent belerakni, amit szerettem volna. Végül leadtam 27 óra késéssel, ami 2 munkanapnak felelt meg, így 9% levonásra számíthattam a végleges jegyemből.
Szóbeli.
Egyéb házi feladatok írása közben összeállítottam a szóbeli prezentációmat, amit természetesen nem töltöttem fel a kívánt határidőre, mert elfelejtettem. Csak a beszámoló napján délben jutott eszembe, hogy van egy ilyen feltétele is a szóbelinek. Nem történt nagy baj, bevittem magammal pendrive-on. Elég kalandos volt Marton Józsit előkerítenem a szóbelire, mert legutoljára a szóbelimről 1 hónappal előtte beszéltünk, de nem elékeztettem közvetlenül előtte. Két beszámoló után kijöttem a teremből és elindultam megkeresni. Először a termében (IL109), aztán meg mindenféle kollégáját leszólítva a folyosón, meg más laborokba bekukkantva. Végül Erős Levente oldotta meg a problémámat, aki tudta a mobil számát és felhívta, hogy meg kell jelennie konzulens minőségben egy szóbeli beszámolón. Minden a helyén volt, jöhetett a prezentációm. Megtartottam. 10 és fél perc lett körülbelül, ami fél perccel volt több a megengedettnél. Marosits Tamás volt a hallgatóság és értékelő egyben. A szóbelimben és írásbelimben egyetlen kivetnivalója volt. Az, hogy nem különült el egyértelműen, hogy mi az, amit én csináltam, és mi az, amit közösen Péterrel. Ezt szóban meg is cáfoltam neki, de úgy tűnik valamiért mindenképp rosszabb jegyet akart nekem adni. Talán a két nap késés miatt, nem tudom. A lényeg az, hogy, a késés önmagában még nem rontott volna a jegyemen, de sajnos nem értékelte tökéletesre a beszámolóimat, így a végén csak 4-est kaptam a tárgyra.
A végleges, konzulensnek szánt beszámolómat csak később tudom befejezni, de nem maradok vele adós. Most a változatosság kedvéért Adatbázisok szerveroldali programozása vizsgám lesz, de utána befejezem a művem :D.

Anyagok
Írásbeli beszámoló a tárgyfelelősnek: link
Szóbeli prezentáció: link

HOUG 2008 anyagok

2008-05-01T12:16:00.002+02:00

Izsák Tamás jelezte egy hozzászólásban, hogy felkerültek a HOUG honlapjára a konferencia előadás anyagai. Akit érdekelnek a részletek, az nyugodtan válogathat közülük.
Kellemes olvasgatást!

Memória konfiguráció - Alapelvek

2008-04-19T16:34:00.004+02:00

Az Oracle adatbázis alapvetően memóriában tárol minden információt. Azonban, ha nincs elegendő erőforrás, akkor az operációs rendszer kénytelen átmenetileg kitenni egy részét a merevlemezre, amíg ismét szükség lesz rá. Ez sajnos elkerülhetetlen elegendő memóriával nem rendelkező rendszerek esetében. (Ugye a memória olvasási és írási sebessége nagyságrendekkel gyorsabb, mint a lemezé.) Egy másik probléma pedig, hogy csak a működéshez elengedhetetlen információk vannak a memóriában, az adatok viszont a merevlemezen pihennek(a TimesTen az adatokat is a memóriában tárolja). Ezeket be kell olvasni, ha szükség van rájuk. A gyakran használt adatokat pedig valamilyen stratégia szerint minél tovább a memóriában kell marasztalni, hogy elkerüljük a felesleges I/O műveleteket.
A cél tehát kirajzolódni látszik. Csökkenteni a fizikai írás/olvasás műveleteket amennyire csak lehet akár cache-eléssel, vagy akár az adatblokkok behozásának hatékonyabbá tételével.

Az alapvető memória részek, melyek hatással vannak a teljesítményre:

Shared pool
Large pool
Java pool
Buffer cache
Streams pool size
Log buffer
Rendezéshez és hasheléshez szükséges memória(saját processz memória)

Automatikus memória kezelés
Alapesetben a telepített Oracle példányunk automatikusan kezeli a rendelkezésére álló memóriát. Ebbe csak nagyon kevés beleszólásunk van. Mindössze a felhasznált memória célméretét (MEMORY_TARGET) és maximumát (MEMORY_MAX_TARGET) szabhatjuk meg, minden más az adatbázis dolga. Elvégzi a területek kiosztását és méretezését az SGA-nak és PGA-nak. Törekszik a legoptimálisabb megoldásra.
Ha mégis úgy döntünk, hogy magunk szeretnénk kezelni a kiosztott memória területeket, akkor érdemes használni a beépített Memory Advisort.

Automatikus osztott memória kezelés
Ha a szerverpéldányunk SGA-ját szeretnénk egyszerűsítve kezelni, akkor ezt megtehetjük egyszerűen. Csupán az SGA_TARGET paramétert kell nullánál nagyobb értékre állítani (ezzel foglalhatjuk le az SGA-nak szükséges területet), utána pedig a STATISTICS_LEVEL-t TYPICAL vagy ALL módba kapcsolni. Ezekkel a beállításokkal az SGA automatikusan szétosztja a rendelkezésére álló memóriát az alábbi területek között: buffer cache, shared pool, large pool, java pool, streams pool. Ha az ezekhez tartozó memóriaterületeket nullánál nagyobb értékekre állítjuk, akkor ezzel a számukra szükséges minimum területet állítottuk be. Ezt figyelembe veszi az adatbáziskezelő a területek szétosztásánál.
Az SGA_TARGET változót dinamikusan is állíthatjuk, ezzel hozzá hangolva az éppen aktuális rendszerműködéshez. Ha az SGA_TARGET-et nullára állítjuk szerver induláskor, akkor a legutolsó beállítások fognak vonatkozni az SGA területeire(buffer cache, shared pool,...). Ezeket azonban személyesen is átállíthatjuk a megfelelő változókkal: DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE, STREAMS_POOL_SIZE. Erről azonban majd később.
Vannak azonban olyan memóriaterületek is, melyekre az automatikus osztott memória kezelésnek nincsen hatása(log buffer, más cache-ek, belső SGA foglalások), azonban az SGA-ból területet vonnak el. Érdemes odafigyelni rájuk.

Memóriaterületek dinamikus változtatása
Ha magunk szeretnénk a memóriaterületeinket kezelni, akkor ezt megtehetjük, de ekkor körültekintően kell eljárnunk. A területek méretének beállítását az alábbi paraméterekkel tehetjük meg: DB_CACHE_ADVICE, JAVA_POOL_SIZE, LARGE_POOL_SIZE, LOG_BUFFER, SHARED_POOL_SIZE. Ezek közül a Log buffer beállítása indítás után nem változtatható meg, a többi viszont dinamikusan kezelhető. A memória foglalás alapegysége az SGA-nak 4MB, amíg 1GB alatt van, felette viszont 16MB. Ezt menet közben nem lehet megváltoztatni. (Egyébként a V$SGA_DYNAMIC_COMPONENTS nézet tartalmazza az aktuális alapegységet.)
Azzal, hogy beállítjuk induláskor az SGA maximális méretét (SGA_MAX_SIZE) korlátot szabunk a teljes memóriahasználatnak. Az ide tartozó komponenseknek nem adhatunk több operatív tárak, mint amennyit kezdetben allokáltunk. Ezért amikor kiszámoljuk, hogy mennyi hely fog kelleni a szerverünk működéséhez, mindig becsüljük kissé túl, hogy ha valamilyen váratlan okból meg kell növelnünk egyes komponensek rendelkezésére álló memória területet, akkor ne kelljen feltétlenül elvennünk valamely máséból, hogy beleférjünk a keretbe.
Segítség a dinamikus újraméretezéshez
Ahhoz, hogy olyan döntéseket hozzunk meg, melyek eredményeként át kelljen méretezni memória területeket, információra van szükségünk az adatbázisunk állapotáról, teljesítményéről, elvégzett műveleteiről. Ebben segítenek nekünk előre definiált nézetek, melyek az alábbiak:

V$MEMORY_CURRENT_RESIZE_OPS - A jelenleg is futó átméretezési műveletek listáját tartalmazó nézet.
V$MEMORY_DYNAMIC_COMPONENTS - Az összes dinamikusan állítható paraméter aktuális értéke, beleértve az SGA és PGA méretét is.
V$MEMORY_RESIZE_OPS - A legutóbbi 800 végrehajtott átméretezési művelet (csak a befejezettek).
V$MEMORY_TARGET_ADVICE - Hangolási tanácsokat tartalmaz a MEMORY_TARGET paraméter állítására.
V$SGA_CURRENT_RESIZE_OPS - Az éppen futó SGA átméretezési műveletek listáját jeleníti meg.
V$SGA_RESIZE_OPS - A legutóbbi 800 végrehajtott SGA átméretezési művelet (csak a befejezettek).
V$SGA_DYNAMIC_COMPONENTS - Az SGA dinamikus komponenseiről tárol információt. Tartalmazza az indítástól számított összes SGA átméretezési műveletet.
V$SGA_DYNAMIC_FREE_MEMORY - Az SGA számára fennálló szabad memória mennyiségét tárolja, ha a jövőben át szeretnénk méretezni.

Megfontolások alkalmazás oldalon
A memória konfigurációját természetesen az alkalmazáshoz kell igazítani, azonban ha a memóriahasználatot megfelelően hangoljuk, akkor nagyban csökkenthetjük az erőforrás szükségleteket. Ha hatékonyan használjuk az adatbázis erőforrásait, akkor jobb teljesítményt érhetünk el, mintha ezzel nem foglalkoznánk.
A legjobb teljesítmény elérése érdekében tehát az alkalmazás memóriahasználatát optimálisan kell kezelni, valamint az adatbázis memória struktúráját az alkalmazás igényeihez kell teljesen igazítani. Ha változtatunk az alkalmazáson, akkor újra kell gondolni az adatbázis memória használatát is.
Ha Java kódot használunk, akkor ezzel külön kell foglalkozni, mert az Oracle adatbáziskezelő külön erre a célra fenntart egy memória területet (Java pool).

Az operációs rendszer memóriahasználata
A legtöbb operációs rendszer használja a lapozási technikát. Vagyis ha nincs elegendő memória, akkor valamilyen stratégia szerint kiválaszt egy memóriaterületet és azt a merevlemezre mozgatja, hogy a helyére az éppen aktuálisan futó processz adatai kerüljenek. Ez teljesítmény csökkenést eredményez az operációs rendszer szintjén. Ebből a megközelítésből tehát a teljesítmény növelése csak a rendelkezésre álló memória növelésével érhető el. Vagy a felesleges processzek leállítása, így szabad memóriaterülethez juthatunk.
Az SGA szemszögéből nézve nagyban rontaná a hatékonyságot, ha egy szerverpéldány egy része nem férne el a memóriába (pl. sok más folyamat miatt) és így folyton használni kéne a lapozást. Ezért ajánlatos valamilyen módon az SGA-t mindig a memóriában tartani. Ennek egy módja, ha van elég hely ugyan a memóriában, hogy megparancsoljuk az operációs rendszernek, hogy nem nyúlhat az SGA-hoz. Ezt az adatbázis LOCK_SGA paraméterével állíthatjuk be. Azonban ha ezt beállítjuk, akkor nem használhatjuk a MEMORY_TARGET és MEMORY_MAX_TARGET paramétereket.
Ha megalkottuk a helyes SGA beállításokat az alkalmazásunkhoz, akkor sem szabad megfeledkeznünk a kapcsolódó felhasználókról, mert nekik is szükségük lesz szabad memóriára, hogy elvégezhessék a műveleteket.
Az SGA aktuális állapotáról a SHOW SGA PL/SQL parancs kiadásával tájékozódhatunk.

Forrás: Oracle Database Performance Tuning Guide 11g Release 1 (11.1) - 7 Memory Configuration and Use - 7.1 Understanding Memory Allocation Issues

Memória konfiguráció

2008-04-19T16:15:00.003+02:00

A most következő néhány bejegyzésben szeretném bemutatni, hogy adatbázisunk teljesítményét miként befolyásolja a rendelkezésre álló memória mennyisége és kiosztása. Először csak az alapelveket tisztázom, majd belemegyek az SGA részletes konfigurálási lehetőségeibe. Itt a Buffer Cache, Shared Pool, Large Pool és Redo Log Buffer tárgyalásáról lesz szó, majd kitérek a PGA beállítási lehetőségeire és használatára is.

Ahhoz, hogy adatbázisunk teljesítménye a lehető legjobb legyen, szükséges a konkrét feladathoz hangolni a rendszer memóriahasználatát. Olvasva ehhez kapcsolódó dokumentációkat mindig feltűnt egy mondat: "Oracle recommends using automatic memory management to manage the memory on your system." Ha szót fogadnék neki, akkor mondhatnám, hogy kész is vagyunk, mert alap esetben így működik adatbázisunk, és nekikezdhetünk a rendszer tervnek. De nem hiszek neki, ezért tovább olvasom ezeket a dokumentumokat. Rájövök, hogy jól tettem, hogy nem fordultam vissza rögtön az elején, mert rengeteg lehetőségünk van finomhangolni rendszerünket, amitől a rejtett teljesítmény növekedést várom.

HOUG 2008

2008-04-12T10:58:00.002+02:00

Lezajlott az idei HOUG konferencia, melyen idén először én is részt vehettem 3 "sorstársam" társaságában. Köszönet érte az Oracle Hungary Kft. -nek és természetesen Sárecz Lajosnak a meghívásért.

A rendezvény ideje alatt plenáris és szekció előadások voltak, de esténként a szórakozás sem maradt el. Minden nap a plenáris előadásokkal kezdődött a nap, de arra az első napot kivéve nem sikerült odaérni, mert az ébredés és reggeli eléggé elhúzódott. Rendszerint az első kávé szünetre, vagy az azelőtti előadásra értünk a helyszínre. Mentségünkre legyen, hogy minket nem a Konferencia helyszínén, a Hotel Azúrban szállásoltak el, hanem 10 percre onnan, a siófoki móló legvégén a Hotel Yacht Klubban.

Visszatérve a konferenciára sok pihenésre nem maradt időnk, mert mindig akadt érdekes előadás, amit nem lehetett kihagyni, így reggeltől(délelőtt) délután 5-6-ig elfoglaltuk magunkat. Utána akadt egy kis pihenő, majd vacsora, ami után rendszerint érdekes programokkal kedveskedtek a szervezők. Itt kiemelném az esténként díjmentesen fogyasztható csapolt Heinekent :) Persze más ital is ingyen volt a résztvevőknek, de én csak ezt próbáltam ki.

Az előadások közül legjobban Hoppán Gergely (Alpha Consulting 1996 Kft.) Blogoljunk és prosperáljunk című előadása tetszett, aki arról beszélt, hogy mi értelme egy szakmai blognak és azt hogyan kell írni ahhoz, hogy minél többen olvassák. A legjobban az a rész tetszett, amikor egy blogot egy nőhöz hasonlított kiemelve a két végletet. Egy céges honlap unalmas, lassan frissülő, száraz. Egy személyes blog szubjektív, abszolút szórakoztató és érdekes. Ennek a kettőnek az ötvözete adja a szakmai blogot, mely szórakoztató céges weboldal. És akkor a hasonlat: "Amikor feleséget választunk, akkor az a célunk, hogy a hölgy legyen egyszerre úrinő is, meg szexistennő is." Ez vitte a pálmát.

Volt még érdekes előadás bőven, de talán Papp Péter (Kancellár.hu) Oracle Hacking háziasszonyoknak című előadását érdemes kiemelni. Az előadás egy demóból állt, ahol megmutatta, hogy kell eltéríteni egy Oracle 10g patchek nélküli rendszert egy távoli gépről. Azt hiszem a hallgatóság majd lefordult a székről amikor már azt is elérte, hogy minden jogot megkapjon az egyszerű felhasználónk. Ültek a teremben sokan, akik ebben a pillanatban legszívesebben felhívták volna céges adatbázisuk adminisztrátorát, hogy azonnal telepítse fel a patcheket... :) Én mindenesetre jól szórakoztam.

Kardkovács Zsolt (BME TMIT) és Benkő Borbála (BME TMIT) közös előadását is volt alkalmam meghallgatni, melyben arról számoltak be, hogy milyen eredményeket értek el a saját magyar szótövesítő rendszerük fejlesztésében. Ennek alapja az Oracle Text technológia, mely lehetőséget ad arra, hogy szövegeket kezeljünk, rendszerezzünk OracleDB alapokon. Az általuk elkészített rendszer a HunLexer, amit egy rövid demón keresztül prezentáltak.

Nagy örömömre szolgált, hogy két előadás is volt TimesTen témakörben, így egy kis betekintést kaphattam a TT ipari környezetben lévő használatáról.

Az első előadást Ökrös Péter (Astron Informatikai Kft.) tartotta Oracle TimesTen for Real Time Business címmel. Az előadás első része a TimesTen technológia ismertetéséről szólt, majd két megvalósítást hozott fel példának, ami Magyarországon egyedülállónak mondható.
Az első példa egy Applikációs adatbázis felgyorsítása a Mavir Zrt.-nél, mely az első magyar TT prodzsekt volt. Ez nem volt egyszerű feladat, mert egy valós idejű vezérlőrendszerből kellett valós idejű konvertálást végezni az alkalmazások számára. Ezt a TimseTen Cache Connect funkciójával valósították meg.
A megoldandó problémák a következők voltak: gyorsabbnak kell lennie (10x, ha már Times<->Ten), tárolt eljárásokat pótolni kellett (mivel a TT nem támogatja), nagy rendelkezésre állás biztosítása Oracle adatbázis tárolt eljárásaival, TT csak valós (materializált) adatokat kezel. A feladatokat sikerrel oldották meg és a rendszert tényleg sikerült felgyorsítani, ha nem is tízszeres sebességre. Tanulságként annyi vonható le, hogy a TimesTen nem minden esetben gyorsít fel egy már meglévő rendszert, főleg akkor nem, ha ehhez nincs megfelelő szakértelem. Viszont, ha hozzáértő szakember készíti el a terveket, akkor jelentős gyorsulásra tehetünk szert.
A második példa egy Ügyviteli Jelentési Rendszer felgyorsítása volt, ahol a fő gondot az okozta, hogy az alkalmazásokhoz nem lehetett nyúlni, tehát egy olyan integrációs megoldást kellett kitalálni, ahol a beillesztett TimesTen réteg transzparensen tudja ellátni a feladatát. Ezt ugyancsak a Cache Connect funkcióval valósították meg. Érdekessége a dolognak, hogy összesen 10 mérnöknap ráfordítással értek el átlagosan 3x sebesség növekedést. Természetesen további ráfordítással és fejlesztéssel a sebesség tovább növelhető.
Az előadás végén még megemlítésre kerültek a TimesTen további alkalmazási területei, mint például a Call Center-ek (azonnali hibafeloldás), telekommunikáció (sms nyugtázás), banki alkalmazások (gyorsabb adathozzáférés).

A másik TimesTen előadást Mészáros András (Allround Informatikai Kft.) tartotta A TimesTen lehetőségei a Magyar Telekom mobil árazó rendszerében címmel. Az előadó arról számolt be, hogy a TimesTennel milyen eredményeket lehet elérni ezen területen. Ez egy tanulmány ismertetése volt, a megvalósítás még várat magára. Szó volt a számlázó rendszer architektúrájáról, komponenseiről és hogy mihez érdemes hozzányúlni ahhoz, hogy teljesítmény növekedést érjenek el. Megemlítette a tervezési döntéseket is, valamint az elvárásokat a fejlesztéssel kapcsolatban. Az előadás végén összefoglalta a vizsgálat menetét és a mérések eredményeit. Természetesen megéri elvégezni az átalakítást a TT felhasználásával. Az előadó megemlítette, hogy a várt eredményeken túl egy pozitív észrevételük is volt, mégpedig, hogy még kedvezőtlen helyzetben is nagyon gyors volt ez megoldás. A mérések alapján jó választás.

Ezeken kívül természetesen még sok előadást meghallgattam a három nap alatt, azonban nem sikerült megszerettetnem magammal a Business Intelligence témát. Pedig én megpróbáltam. Összesen három ilyen témájú előadást hallgattam végig, de kivétel nélkül mindnek a vége felé már kapartam a falat. Volt amelyikről ki kellett jönnöm. Na de mindegy.
Összességében nagyon hasznos volt a konferencia és örülök, hogy elmehettem. Remélem jövőre is részt vehetek, talán már a másik oldalon...

Tervezés és fejlesztés a teljesítmény nevében - Rendszer architektúra

2008-04-02T23:47:00.001+02:00

Rendszer architektúra

Hardver és szoftver komponensek

Hardver

Egy rendszer hardver elemeit érdemes úgy méretezni, mint ahogy egy hídépítő mérnök tervezi a hidat. Mivel a költségekkel mindig számolni kell, ezért nem érdemes bizonyos részeit a legjobb és legdrágább anyagokból építeni, míg más részeit olcsóbb, és így gyengébb elemekből. A híd teherbírása a leggyengébb rész teherbírása lesz. Sokkal erősebb hidat lehet építeni, ha valamiféle egyensúlyt keresünk az egyes részek minősége között, és próbáljuk ezt egymáshoz közel tartani és a költségeket ennek megfelelően minimalizálni.

Egy számítógépes rendszer tervezésénél is pontosan ez a helyzet. Törekedni kell tehát az egyensúlyra és úgy méretezni leendő rendszerünket.

Az alapvető hardver komponensek:

Processzor
Memória
I/O alrendszer
Hálózat

Szoftver

Úgy, mint a számítógépeknek is vannak közös hardver elemei a szoftvereknek is vannak funkcionálisan közös elemeik. Ha az alkalmazásokat szétválasztjuk funkcionális elemekre, jobban megértjük ezek működését.

A legtöbb alkalmazás tartalmazza az alábbi komponenseket:

Felhasználói felület
Üzleti logika
Felhasználói kérések és erőforrás foglalás
Adat és tranzakció kezelés

Felhasználói felület

A felhasználó ezen a felületen keresztül kommunikál a programmal.

Feladatai:

Kép megjelenítése
Adatgyűjtés és kézbesítés az üzleti logikai rétegnek
Bejegyzéseket érvényesíti
Navigál az alkalmazás állapotai között

Üzleti logika

Az alapvető logikai egység. Ettől függ, hogy az alkalmazás milyen feladatot lát el. Ha ebben hiba van, annak helyreállítása nagyon költséges is lehet. Procedurális és deklaratív részek alkotják.

Feladatai:

Adatmodell átültetése relációs sémába
Kényszerek definiálása a relációs sémában
Az üzleti logika megvalósítása függvények segítségével

Felhasználó kérések és erőforrás foglalás

Ez a komponens minden alkalmazásban szerepel. Egy több felhasználós rendszerben az erőforrás foglalást elvégzi az adatbázis szerver, vagy az operációs rendszer. Azonban nagyon nagy alkalmazás esetén a rendszer tervezőjének meg kell bizonyosodnia, hogy nagy terhelés esetén is garantálható a normális működés.

Az ide tartozó feladatok:

Adatbázis-kapcsolat kezelése
Lekérdezések végrehajtása
Kliensek kezelése
Egyensúlyban tartani a felhasználói kéréseket a hardver erőforrások függvényében

Adat és alkalmazás kezelés

Ezért főleg az adatbázis szerver és az operációs rendszer felelős.

Feladatok:

Egyidejű adathozzáférés garantálása zárak és tranzakciók segítségével
Optimalizált adathozzáférés indexek és cache segítségével
Gondoskodni az adatmódosítások logolásáról
Érvényesíteni az adatokra vonatkozó szabályokat

A szükségleteknek megfelelő helyes rendszer-architektúra beállítása

Meghatározni a helyes rendszer architektúrát nem egyszerű feladat. Sokszor többször át kell gondolni a tervezés különböző fázisaiban. Alapvetően megkülönböztetünk interaktív (pl. árusító rendszerek, email szerverek, web alapú alkalmazások…) és processz alapú (pl. csalás detektáló rendszer, direct mail) rendszert. A legtöbb esetben ez utóbbit könnyebb fejleszteni, mert itt hiányzik a felhasználói felület. Azonban itt a feladat is nehezebb, mert a célok nem annyira tiszták, mint egy felhasználói igényeket kielégítő rendszerben. A tervező mérnökök nincsenek hozzászokva nagy adatmennyiségek kezeléséhez.

A rendszer architektúra meghatározása nem tartozik a determinisztikus dolgok közé. Ahhoz, hogy valaki jó tervező mérnökké váljon, rengeteg tapasztalatra van szükség. Azonban álljon most itt néhány kérdés, melyek megválaszolása elősegítheti a helyes architektúra kialakítását.

Elsődleges kérdések:

Hány felhasználó fogja használni a rendszert?
Majdnem minden alkalmazás besorolható az alábbi kategóriák egyikébe.

· Nagyon kevés felhasználó egy keveset használt számítógépen
Ez általában egy felhasználót jelent. A tervezésnél a fő szempont az, hogy ez az egy felhasználó a lehető legjobb hatékonysággal tudja használni az alkalmazást, minimális válaszidővel. Ezeknek az alkalmazásoknak a felhasználói ritkán zavarják egymást és az erőforrás ütközések is minimálisak.

· Közepesen sok és sok felhasználó egy vállalati, osztott alkalmazásban
Ebben az esetben a felhasználók száma limitált és megjósolható, például egy vállalat alkalmazottai. Azonban a megbízhatóság döntő szempont a tervezésnél. A felhasználók közös erőforrást használnak, így nagy terhelésnél is fontos a válaszidő kordában tartása.

· Megszámolhatatlan felhasználó fér a rendszerhez az interneten keresztül
Ennél az alkalmazástípusnál fontos a mérnöki hozzáértés, mert gondosan meg kell tervezni az erőforrások elosztását. Ha elfogy valamelyik hardverkomponens tartaléka, akkor könnyen kialakulhat ’bottleneck’, ami a rendszer instabilitásához vezethet. Az ilyen alkalmazásokhoz szükséges terhelés kiegyenlítés, állapotmentes alkalmazás szerver, és hatékony adatbázis kapcsolat menedzsment.

Milyen lesz a felhasználói hozzáférés?
A felhasználói felület megválasztása a web-alapú technológiáktól egészen a saját kliens programig.
Hol vannak a felhasználók?
A felhasználók közötti távolság szabja meg bizonyos esetekben, hogy mennyi lehet a késleltetési idő. De a felhasználók helye még azt is befolyásolhatja, hogy melyik napszakban legyen a karbantartás, és mikor legyen feltétlenül elérhető.
Mekkora a hálózati sebesség?
A hálózati sebesség nagyban befolyásolja azt, hogy mennyi adatot célszerű küldeni egyszerre a felhasználói felület és az adatbázis szerver között. Ha lassú a sebesség, akkor nem érdemes minden egyes új információt átküldeni, hanem csak tömbösítve, mert akkor nem lesz szétdarabolt a bevitel. Ha pedig gyors a hálózati elérés, amit használunk, akkor megoldható az, hogy a szerver gyorsan reagáljon minden bevitelre.
Mennyi adathoz férhet hozzá egy felhasználó és ebből mennyi csak olvasható?
A lekérdezett adatmennyiség kihat a tervezési döntésekre. A tervezőnek meg kell bizonyosodni róla, hogy a válaszidő az adatbázis méretétől nem függ. Ha az alkalmazás jórészt csak lekér adatokat, akkor az adatreplikáció és adat elosztás egy jó megoldás a fő szerver tehermentesítésére (terhelés megosztás).
Mekkora a maximális megengedhető válaszidő?
Ezt felhasználója válogatja. El kell döntenünk, hogy aki használni fogja a rendszert, annak milliszekundumos válaszidőre van szüksége, vagy elegendő akár másodperces nagyságrend is.
Szükség van-e napi 24 órás elérésre?
Az internetről is elérhető rendszerek számára ez kötelező. Azonban a vállalati rendszerek, melyek csak egy időzónában működnek, elegendőek csak a munkaidő alatt elérhetőnek lenniük. A maradék időben pedig el lehet rajtuk végezni a karbantartási munkákat és átkonfigurálásokat.
Minden változtatást valós időben kell elvégezni?
Fontos a tervezéskor eldöntenünk, hogy a felhasználó által kért változtatásokat azonnal végre kell hajtanunk, vagy ráér esetleg később is, aszinkron módon.

Másodlagos kérdések:

Mekkora lesz az adatbázis?
Az adatbázis mérete határozza meg a szerver gép erőforrásait. Az olyan szerver, amin nagy adatbázist használunk egy kicsivel nagyobb gépet igényel, mint amekkorára feltétlenül szüksége lenne. Ez azért van, mert az adminisztrációs folyamatok végrehajtási ideje nagyban függ az adatbázis méretétől. Ha nincs elegendő plusz erőforrás, akkor ezek a műveletek nagyon hosszúra is nyúlhatnak.
Mennyi a szükséges teljesítmény egy művelethez?
Mik a rendelkezésre állási szükségletek?
Milyen kompromisszumokat tudunk kötni, ha finanszírozási megszorítások lennének?

Forrás

Tervezés és fejlesztés a teljesítmény nevében - Skálázhatóság

2008-04-02T23:40:00.003+02:00

Skálázhatóság

Mit hívunk skálázhatóságnak?

A skálázhatóság egy rendszerképesség, mely azt mondja meg, hogy ha növeljük a folyamat által felhasználható fizikai erőforrások számát, akkor a rendszer mennyivel több terhelést bír el. Ha például egy skálázható rendszerben kétszeresére növeljük a munkaterhelést, akkor az erőforrás felhasználás is a kétszeresére növekszik. Ez nyilvánvalónak tűnik, azonban egy nem skálázható rendszerben ez nem így van, mert ott a terhelés növelése megsokszorozhatja az erőforrás szükségleteket. Az okok a következők lehetnek: megnövekedett zárhasználat, operációs rendszer terhelése, rosszul megtervezett lekérdezések és indexek növelhetik az I/O műveletek hosszát… Azonban az is okozhatja a lassulást, hogy elfogyott a memória, vagy lemezterület, a hálózati kapcsolat sebessége nem tudja kielégíteni az igényeket, vagy akár annyi folyamatot indítunk (és memóriát foglalunk számukra), hogy az operációs rendszer nem tudja kezelni őket.

A rendszer skálázhatósága

Napjaink legtöbb adatbázis rendszerének meg kell felelnie annak a követelménynek, hogy a nap 24 órájában elérhető legyen az interneten. Ha kezdetben egy kisebb rendszert is tervezünk, szem előtt kell tartani azt is, hogy később szükség lehet jóval nagyobb munkaterhelést is elbírnia. Tehát jól skálázhatónak kell lennie a kezdetektől fogva. Ha erre nem szentelünk elegendő figyelmet, akkor a későbbiekben szembesülhetünk azzal a problémával, hogy a megnövekedett igények miatt újra kell tervezni a teljes rendszert, ami az üzleti világban nem biztos, hogy megmagyarázható lépés. Egy rendszer áttervezése miatti leállás költsége elérheti egy rendszer teljes fejlesztésének költségeit.

Skálázottságot befolyásoló tényezők

Egy rendszer megtervezésénél és megépítésénél a szakemberek mindig arra törekednek, hogy a lehető legjobb legyen a skálázhatóság. Ez optimális esetben lineáris skálázhatóságot jelent, vagyis a processzorok duplázásával duplájára nő a terhelhetőség is. Ez azonban elérhetetlen.
Az alábbiakban összefoglaljuk, hogy melyek azok a tényezők, melyek a leginkább befolyásolják a rendszer skálázhatósági képességét.

• Gyenge alkalmazás tervezés, implementáció és konfiguráció.
(Az alkalmazásnak van a legnagyobb hatása a skálázhatóságra.)

Gyenge adatbázisséma tervezésből adódó drága SQL lekérdezések.
Gyengén megtervezett tranzakciók okozhatnak zárolási és sorosítási problémákat.
Gyengén megtervezett hálózati kapcsolat okozhat nagy válaszidőket és nem megbízható működést.

Azonban nem csak a tervezés okozhat gondot, hanem az alkalmazás gyenge implementációja is:

Rosszul implementál I/O stratégia.
Éles környezetben megváltozhat a végrehajtási terv a tesztkörnyezethez képest.
Nagy memória-igényű alkalmazások nem fordítanak elegendő figyelmet a nem használt memória felszabadítására.
Nem hatékony memória használat okozhat gondokat a virtuális-memória kezelésben. Ez hatással van a teljesítményre és hozzáférhetőségre.

• Hibásan méretezett hardver komponensek

Napjaink hardver árai kisebbek, mintsem azzal foglalkozzunk, hogy megvegyük-e még ezt az 1Gb RAM-ot a 10Gb-os rendszerünkbe vagy sem. Azonban a túl nagy hardver kapacitás elfedheti a skálázhatósági problémákat, így csak később vesszük észre azokat, mikor már nagyobb gondot okozhatnak.

• Hardver komponensek korlátozása

A hardver nem tökéletesen skálázható. A legtöbb multiprocesszoros gép közel lineárisan skálázódik, azonban egy meghatározott processzorszám után a növekedés ugyan összességében folytatódik, de arányaiban nem annyival, mint eddig. Ha tovább növeljük, akkor pedig elérünk oda, ahol a teljesítmény növekedés megtorpan, sőt vissza is esik. Ez a viselkedés nagyban függ a munkaterheléstől és az operációs rendszer beállításaitól.

Forrás

Tervezés és fejlesztés a teljesítmény nevében - Beruházási lehetőségek megértése

2008-04-02T23:38:00.001+02:00

Beruházási lehetőségek megértése

Napjainkra a hardverek ára meglehetősen olcsó. Nem okoz gondot, ha a rendszerünk teljesítménye nem megfelelő, akkor vásároljunk még memóriát, vagy háttértárat, esetleg lecseréljük egy több processzort használó rendszerre. Azonban ez hosszútávon nem vezet jóra, mert a teljesítménycsökkenés okát nem szűnteti meg, ami a legtöbb esetben a nem megfelelő tervezésnek köszönhető. A rendszer kapacitásának növelése után, ha az alkalmazásunk tovább növekszik, akkor a probléma rövid időn belül újra jelentkezni fog,
Vannak olyan esetek is, amikor további memória, háttértár beszerzése nem növeli a teljesítményt. Vásárlás előtt mindig érdemes átgondolni, hogy alkalmazásunkban minden folyamat a lehető legoptimálisabban működik-e. Az adatbázisunk sem futtat feleslegesen sok, erőforrást felemésztő műveletet. Hosszú távon sokkal hatékonyabb megoldás ezen hibák kigyomlálása.

Forrás

Tervezés és fejlesztés a teljesítmény nevében - Bevezetés, Oracle módszertan

2008-04-02T23:34:00.003+02:00

Bevezetés

Optimális rendszerteljesítményt elérni nem könnyű. Ahhoz, hogy ez sikerüljön, már a tervezési fázisban is figyelembe kell venni teljesítmény specifikus szempontokat. Meg kell hozni olyan döntéseket, melyek a későbbiekben segíthetnek hangolni rendszerünket.

Ez az összefoglaló segít megérteni a teljesítményre hatással lévő rendszerkomponensek óvatos kezelésének fontosságát. Megpróbál egy olyan körképet adni, aminek a segítségével tudatosabban fejleszthető egy rendszer a teljesítmény nevében.

Oracle módszertan

A rendszer-teljesítmény napjainkban egyre fontosabb dolog, mert a számítógép rendszerek folyamatosan nőnek és egyre összetettebbeké válnak. Ehhez még az is hozzájárul, hogy az Internet egyre nagyobb szerepet játszik ebben, mert ezeket a komplex megoldásokat még össze is kapcsoljuk, így létrejőve még ennél is nagyobb bonyolultságú rendszer.

Az Oracle mérnökei kialakítottak egy módszertant, melyet, ha figyelembe veszünk a tervezés és fejlesztés ideje alatt, akkor a végül sokkal jobb teljesítményt érhetünk el, mint ezt nélkülözve. Ez a leírás ismerteti ezeket az alapelveket.

A teljesítmény-stratégiák hatékonysága különbözőek lehetnek attól függően, hogy milyen profilú rendszert építünk. Például egy operatív rendszernek más teljesítmény mutatókkal kell rendelkezni, mint egy döntést támogató adatbázis-rendszernek. Ez a módszertan segít összpontosítani azokra a területekre, melyeknél szükséges a nagy hatékonyság, a célokat figyelembe véve.

A teljesítmény mindig egy konkrét rendszerre van hangolva, mely hardver és szoftver elemekből, erőforrásokból állnak. A teljesítménycsökkenés általában ezeknek az erőforrásoknak a kimerülése miatt következik be. Ha elfogyott valamely rendszerkomponens összes tartaléka, akkor a rendszer nem méretezhető tovább és visszaesik a teljesítmény is.

Ez a módszertan figyel a teljesítmény maximalizálására. A tervezésnél nagy figyelmet fordít az erőforrásokkal való óvatos bánásmódra. A kész rendszernél pedig segít feltárni az erőforráshiányt vagy erőforrás-ütközést, hogy ezeket megszűntetve növelhessük rendszerünk teljesítményét.

Forrás

Tervezés és fejlesztés a teljesítmény nevében

2008-04-02T23:17:00.002+02:00

Az elmúlt időszakban nem voltam valami termelékeny, ám nem töltöttem az időm hasztalan. Mint korábban írtam, ebben a félévben az Oracle adatbázis teljesítmény kérdéseivel szeretnék foglalkozni. Ennek fényében egy kis Oracle architektúra gyorstalpalón vettem részt Nyárády Péternek köszönhetően, aki blogjában írt a témáról elég kimerítően. Ezek után a hivatalos Oracle Database Concepts dokumentációban lévő Memory architecture részt tanulmányoztam át.
Péter javaslatára ezután a Performance Tuning Guide-ot lapozgattam, melyből egy összeállítással is elkészültem. Ebben a félévben az irodalomfeldolgozáson kívül egy rendszertervet is össze kell állítani. Ehhez szeretnék segítséget nyújtani ezzel az összefoglalóval, melynek témája a címben is szereplő "Tervezés és fejlesztés a teljesítmény nevében". Még nem készültem el vele teljesen, de ami eddig formába van öntve, azt közzé teszem.
Holnap (2008. április 3. csütörtök) a közös konzultáción az előadásom vezérvonala is ez a téma lesz, erről fogok beszélni. Remélem a rendszerterv megalkotásához segítséget tud majd nyújtani.

Új lendület

2008-02-23T19:43:00.002+01:00

Legutóbbi bejegyzésem óta elég sok idő telt el. Lezárult a vizsgidőszak, síeltem, elkezdeődött az új félév. Erre a rövid szünetre szükség volt, hogy átgondoljam milyen irányba folytassam az Önálló laboratóriumot. Marton József konzulensemmel több levelet is váltottam ez ügyben, és személyesen is leültünk megbeszélni, hogyan tovább. Több lehetőség közül választhattam, de a legszimpatikusabbnak azt tartottam, hogy erre a félévre kicsit félreteszem "pihenni" a TimesTen-t, de azért nem megyek olyan messzire a memóriára alapozott rendszerteljesítménytől, mert az Oracle11g memória kezelését, és konfigurálását fogom vizsgálni. Egészen pontosan azt fogom gorcső alá venni, hogy meghatározott típusú adatbázisterhelés mellett milyen SGA beállításokkal érhető el a legnagyobb teljesítmény.
A jövőben ezt a témát és az előző félévben feldolgozott témát szeretném minél közelebb hozni egymáshoz. De ez még csak egy ötlet, addig még rengeteg midnen történhet.
Ebben a félévben a labor már négyszer(8) annyi kreditet ér, mint az előzőben(2). Ennél fogja több munkára is szükség lesz, hogy az elvártaknak megfelelően teljesítsek. A konzulenseim hozzáállása is sokat változott ebben félévben. Itt gondolok arra, hogy 3-heti rendszerességgel lesz közös konzultáció, ahol az Oracle technológiát feldolgozó társaság egy részének(mindig más) kell előadást tartania az elvégzett munkájáról.
Mint az fent olvasható, a blogom címe is megváltozott. Ezentúl az "Éberhardt Péter Oracle blogja" címet viseli, mert már nem csak speciálisan TimesTen-nel kapcsolatos bejegyzések vannak benne, hanem sokkal áltlánosabb, Oracle-el kapcsolatos dolgok is.

Triggerek

2008-01-22T22:50:00.001+01:00

Múlt héten kaptam egy feladatot a munkahelyemen, amit úgy gondoltam, hogy egy trigger elkészítésével tudom a legegyszerűbben és leghatékonyabban megoldani. Ez pont jó alkalom volt arra, hogy kicsit közelebbről is megismerkedjek vele. Az eseménygyűjtő rendszerünk egy Microsoft SQL Server 2005 adatbázisra épül, így a T-SQL nyelvet kellett használnom.
Álljon itt egy áttekintés a triggerekről, melyeket megpróbálok rendszertől függetlenül bemutatni. Természetesen kitérek a Microsoft által használt T-SQL és az Oracle által használt PL/SQL közötti szintektikai és szemantikai különbégekre, valamint szó lesz a TimesTen és a triggerek kapcsolatáról is.

Trigger
A trigger nem más, mint egy tárolt eljárás, melynek lefutását egy esemény vált ki. Az események típusa szerint háromféle trigger létezik. DML(Data Manipulation Language), DDL(Data Definition Language), logon trigger.
DML trigger akkor aktiválódik, ha valamilyen DML esemény történik. Ilyen események az INSERT, UPDATE vagy DELETE , melyeket táblákon vagy nézeteken hajthatunk végre.
DDL trigger akkor aktiválódik, ha DDL esemény történik. DDL események a CREATE, ALTER, DROP műveletek végrehajtása.
A logon trigger akkor tüzel, ha valamilyen LOGON esemény történik.
Egy trigger egy esemény előtt, helyett vagy után futhat le. Ennek a segítségével jóval összetettebb megszoírtásokat készíthetünk az adatbázisunkhoz, így növelve a biztonságot és a megbízhatóságot.
Ha például az adatbázisunkban csak olyan eseményeket szetnénk tárolni, melyek nem öregebbek 1 évnél, akkor ezt egy helyettesítő triggerrel szűrhetjük. Csak azt az adatot engedjük beilleszteni, melynek időpontja 1 évnél fiatalabb.
A triggerek logikailag az adattáblákhoz tartoznak. Egy táblához és egy eseményhez tőbb trigger is tartozhat, azonban ezeknek a tüzelési sorrendje nem meghatározható.
A trigger által generált visszatérési értékek, pl. egy SELECT utasítás eredménye a sikeres lefutás után átadódik a kiváltó eseménynek, mely úgy kezeli, mintha az ővé lenne. Ha azt szeretnénk, hogy ez ne jelenjen meg, akkor a trigger elején be kell állítani a NOCOUNT-ot ON-ra. (SET NOCOUNT ON) Ezzel természetesen szelektálhatunk, hogy mi az az érték, amire szükségünk van, és mi az, a mire nincs.
Rendelkezésünkre áll két átmeneti tábla a triggerben. Az egyik az INSERTED, a másik a DELETED. Az INSERTED táblába kerülnek az új értékek, ha INSERT, vagy UPDATE művelet hatására fut le a trigger. A DELETED táblában pedig a régi adatok lesznek, melyek DELETE vagy UPDATE hatására töltődnek be.
Trigger létrehozása. Csak a legalapvetőbb beállításokat mutatom be, bővebben itt lehet róluk olvasni:
T-SQL CREATE TRIGGER
PL/SQL CREATE TRIGGER
A két esetben a szintaxis majdnem ugyan az. Én a T-SQL -t használva mutatom meg egy trigger
létrehozását.

DML trigger készítése:

CREATE TRIGGER [ schema_name . ]trigger_name
ON { table | view }
[ WITH  [ ,...n ] ]
{ FOR | AFTER | INSTEAD OF }
{ [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE ] }
AS { sql_statement  [ ; ] [ ,...n ] | EXTERNAL NAME  }

[ schema_name . ] - a schema, melyben az adattáblánk is
     szzerepel trigger_name - általunk
     megadott trigger név
ON { table | view } - megadjuk, hogy melyik táblához,
       vagy nézethez akarjuk létrehozni
       a triggert
 ::= [ ENCRYPTION ] - ennek segítségével meggátolhatjuk,
       hogy ha az adatbázis replikálják,
       akkor ez a trigger ne kerüljön át
[ EXECUTE AS Clause ] - lehetőségünk van a triggert egy
  meghatározott felhasználó nevében
  futtatni
FOR - a trigger a kiváltó esemény előtt fut le
AFTER -  a trigger a kiváltó esemény után fut le
INSTEAD OF - a trigger a kiváltó esemény helyett fut le
INSERT|UPDATE|DELETE - kiválaszthatjuk, hogy milyen
        eseményre triggereljünk, tetszőleges
        kombináció előállítható
AS sql statement - az AS utáni rész maga a trigger feltétel
   teljesülése esetén végrehajtandó rész ha
   több műveletből áll, akkor BEGIN .. END
   közé kell rakni

Pl.:
use teszt_db
CREATE TRIGGER ins_trigger
ON tabla1
INSTEAD OF INSERT
AS
BEGIN
IF ((SELECT id FROM inserted)>10) INSERT INTO tabla1 (id, nev)
VALUES (SELECT id, nev FROM inserted)
END

Rövid magyarázat: Ez a trigger csak abban az esetben engedi beillszteni
az új sort, ha az "id" > 10.

A DDL- és logon-trigger létrehozása nagyon hasonló felépítésű a DML-
hez, csak ott nem a táblához, hanem egy adatbázishoz vagy szerverhez
rendeljük hozzá a triggert és helyettesítés nincsen.
Érdekes kérdés, hogy egy többsoros INSERT esetében mi történik. A
trigger csak egyszer hívódik meg, vagy minden sorra külön külön. Na
itt különbség van a PL/SQL és T-SQL között. A PL/SQL-ben lehetőség
van megadni, hogy többsoros INSERT esetén a trigger soronként tüzeljen,
míg T-SQL esetében erre nincs mód.
Ennek a korántsem teljes beszámolónak a végén meg kell még említenem,
hogy a TimesTen-ben nincs lehetőség triggerek létrehozására. Ennek
az lehet az oka, hogy triggerek kezelése nagyon megbonyolítaná a
tudatosan leegyszerűsített működést.

Pár hasznos link:
MSDN - CREATE TRIGGER (T-SQL)
hu.wikipedia.org - trigger
wikipedia.org - trigger
psoug.org - jó példák tipikus alkalmazásokra (PL/SQL)

Oracle Blogger Dinner

2008-01-19T12:46:00.000+01:00

Lezajlott az első Oracle Blogger Dinner, melyet Sárecz Lajos szervezett. A találkozó lényege az volt, hogy azok az emberek, akik ma Magyarországon blogot írnak valamilyen Oracle technológia témában, azok személyesen is találkozhassanak. 2007 őszéig összesen két ilyen blog létezett, melyet Izsák Tamás ír Oracle Application Express témában(apexblog.hu), valamint Darvas Tamás OracleDBA témában(OracleDBA). Az előző(őszi) félévben viszont a bloggerek száma megsokszorozódott, mivel az Önálló Labor keretein belül az Oracle technológiát választóknak feladatuk volt az is, hogy munkájukról blogot készítsenek, hogy ezzel tájékoztassák konzulensüket és az érdeklődőket - itt elsősorban az Oracle Hungary kapcsolattartójára gondolok, Sárecz Lajosra. Ez a blog is ennek köszönheti létét. Összesen körülbelül a félév során 16 blog működött aktívan melynek összetétele 2 "öreg motorosból" (Izsák Tamás és Darvas Tamás), 13 TMIT(Távközlési és Médiainformatikai Tanszék) hallgatóból és 2 AUT(Automatizálás és Alkalmazott Informatikai Tanszék) hallgatóból állt.
A találkozó előtt Sárecz Lajos megkért, hogy tartsak egy rövid beszámolót a félév során szerzett TimesTen tapasztalataimról. Így a többiek is megismerkedhetnek más Oracle technológiákkal, nem csak azzzal, amivel ők maguk foglalkoztak.
Az első Oracle Blogger Dinner-en körülbelül 8-10-en jelentünk meg. Ez számomra meglepő volt, mert azt hittem, hogy ezt a lehetőséget senki nem hagyja ki. Bár gondolom azok, akik nem jöttek el, biztos más elfoglaltságuk akadt, ami fontosabb volt.
Az összejövetel címe vagy neve egy kis magyarázatra szorul. Oracle Blogger Dinner. Az Oracle az egyértelmű. Szerintem a Blogger is. Ez a kettő már igazából meghatározza azt a közösséget, akinek szól ez az egész. A Dinner pedig csak arra utal, hogy miközben találkozunk, pizzát eszünk. :) A találkozó pontosabb címe az lehetne, hogy Oracle Blogger Pizza Meeting. De ez nagyon viccesen hat és elveszíti minden komolyságát az ügy. Így sokkal hivatalosabban fest a Dinner. Szóval Oracle Blogger Dinner.
Az összejövetel bemutatkozással kezdődött kerekasztal formájában. Mindenkinek el kellett mondania, hogy mi motiválta, hogy Oracle termékkel foglalkozzon az ÖnállóLabor keretein belül. Valamint arról is kellett beszélnie, hogy mi a véleménye a blogírásról. Van-e haszna, vagy abszolút hülyeség.
A beszélgetés nagyon jó hangulatban zajlott, mindenki kifejthette a véleményét a témával kapcsolatban.
A találkozó második fele pizzázással és előadással telt, melyet én tartottam a TimesTen memória adatbázisokról. Azt hiszem sikerült megértetnem a technológia jelentőségét és lényegét. Azt, hogy a hallgatóság mennyire unatkozott, azt nem tudom, de a végén kapott kérdésekből arra következtetek, hogy azért valamennyire figyeltek.
A találkozó bő két órán át tartott, ami alatt azt hiszem senki nem unatkozott. Ha mégis, akkor remélem a pizza valamennyire lekötötte a figyelmét. :D Megegyeztünk, hogy a következő, azaz a második Oracle Blogger Dinner negyed év múlva kerül megrendezésre. Akkor is lesz (remélem) pizza, eszmecsere és előadás, melyet ha jól emlékszem Tóth László és Szabó Gergely tart a .NET és OracleDB kapcsolatáról.

A magyar Oracle blogok listája, melyet Sárecz Lajos gyűjtött össze:
http://gyurak.blog.hu/
http://oraclefarkas.blog.hu/
http://vasvari.blog.hu/
http://bozsik.blog.hu/
http://sumeghy-onlab.blog.hu/
http://benyo-oracle.blogspot.com/
http://bblog.notice.hu/
http://pglabor.blogspot.com/
http://rai-labor.blog.hu/
http://orabusiness.blogspot.com/
http://oraoptimization.blogspot.com/
http://www.apexblog.hu
http://eptentimes.blogspot.com/
http://oracle-with-dotnet.blogspot.com/
http://oracleondotnet.blogspot.com/
http://oracle.blog.hu/

Féléves összefoglaló

2007-12-10T20:52:00.000+01:00

A múlt héten elkészült az írásbeli összefoglaló a féléves munkámról, melyben számot adok arról, hogy mennyit foglalkoztam a témámmal. Tételesen felsorolom az elolvasott dokumentáció mennyiségét. A befektetett munka mennyiségét ismertetem és, hogy hány oldal leírást, dokumentációt készítettem. A beszámolóban röviden ismertetem is a feldolgozott témát.
A dokumentáció az alábbi linken érhető el:
Féléves írásbeli beszámoló.

Végleges dokumentum verziók

2007-11-29T11:13:00.000+01:00

Mint már korábban látható volt, az általam eddig megírt összes dokumentációt folyamatosan javítom, hogy ne tartalmazzanak hibákat és a lehető legkönnyebben érthetőek legyenek. Most, a félév vége felé ezek a doksik elnyerték végső formájukat (és tartalmukat). Az alább felsorolva lehet őket megtekinteni:
TimesTen Introduction 2.1
TimesTen Installation
TimesTen kiegészítések a telepítéshez
TimesTen Cache Connect to Oracle 2.0

Cache Connect to Oracle

2007-11-26T20:56:00.000+01:00

Elkészültem egy átfogó irodalomfeldolgozással, melyben a TimesTen cache-ként való működését írom le. Ebben kitérek az összes működési módra, lehetőségekre, beállításokra. Ez nem azt jelenti, hogy ebből a leírásból bárki képes lenne felkonfigurálni egy ilyen cache adatbázist, de átfogó képet kaphat az, aki elolvassa ezt az irományt. Törekedtem arra, hogy mindenki számára érthető legyen amiről írok, persze alapvető műszaki - informatikai ismeretekre szükség van a téma megértéséhez.
A féléves munkám utolsó dolgozata ez. Ezek után az írásbeli anyagot fogom összeállítani az elkészült dokumentációkból, majd egy szóbeli prezentációt is előkészítek.
TimesTen Cache Connect to Oracle

Bevezetés 2.0

2007-11-18T16:34:00.000+01:00

Korábban már írtam egy összefoglalót, melyben a TimesTen alapvető funkcióiról és működéséről volt szó(TimesTen intro). Konzulensem, Marton József segítségével javításokat végeztem benne. Megjegyzései felhívták a figyelmemet apró hibákra, félreértésekre. Sok hasznos tanáccsal is ellátott, melyekkel javíthattam a dokumentáció érthetőségén és átláthatóságán. A dokumentum második kiadása itt található: TimesTen intro 2.0

Első próbálkozás a Cache Connect to Oracle -el

2007-11-11T13:13:00.000+01:00

Mint korábban írtam, ezentúl speciálisan a Cache Connect to Oracle opcióval fogok foglalkozni, ennek lehetőségeivel.
Első lépésként a hivatalos doksiban(cache connect 13.oldal) lévő egyszerű Quick Start-tal kezdtem, ami lépésenként leírja egy csak olvasható Cache Group létrehozását, és annak beállításait. Ez a legegyszerűtt használata a Cache Connect funkciónak, mely annyit tesz, hogy egy Oracle adatbázis egy tábláját beilleszti(lemásolja) a memóriába és aktiválja az Autorefresh Cache Group funkciót, ami figyeli az Oracle adatbázisban lévő erre a táblára vonatkozó változásokat. Ha történt ilyen, akkor azt közli a TimesTen Cache Group-pal és ott is végrehajtja a változtatást. Ez egyenlőre csak egyirányú kapcsolat. Mivel a Cache Group-unk csak olvasható, ezért a TimesTen Cache Group-unkhoz nem fordulhatunk csak olvasással járó SQL queryvel. Lehetőség van azonban írással járó kéréssel is fordulni a TimesTen Cache Group-hoz. Ezt a funkciót Passthrough-nak hívják. Ez egy "ál írás" funkció, ettől nem lesz írható közvetlenül a Cache Group-unk. A technika lényege, hogy a közvetlenül a TimesTen Cache Group-hoz intézett SQL query, ami módosítási, létrehozási parancsot tartalmaz (pl.: UPDATE, INSERT), azokat a query-ket átirányitja az Oracle adatbázishoz,hogy ott hajtsák végre őket, majd ezután az Autorefresh funkció automatikusan visszaküldi a táblában lévő változásokat. Külső szemlélőként azonban úgy tűnik, mintha közvetlenül hajtotta volna végre a queryt.

Sárecz Lajos hívta fel a figyelmemet, hogy az Oracle SQL Developerhez kiadtak egy TimesTen Extension -t. Természetesen letöltöttem és feltelepítettem a programot és a kiegészítést is. Nem bántam meg. Miután beállítottam a Cache Connect-et ezzel egyszerűen le tudtam ellenőrizni, hogy valóban jól működik-e. Amit a leghasznosabbnak találtam benne, az az SQL-t értelmező és futtató környezet volt. Ez számomra kiváltotta az SQL PLus-t, melyben szerintem jóval nehézkesebb a query-k szerkesztése.

A Cache Connect to Oracle technológiáról ebben a doksiban olvashatunk: Cache Connect to Oracle

AZ általam használt OracleDB verziók:
- Oracle Database 10g 10.2.0.1.0
- TimesTen 7.0.3 32-bit

Kiegészítés a telepítéshez

2007-11-08T16:57:00.000+01:00

A TimesTen telepítésekor nem magyaráztam meg mindent, hogy az egyes funkciók pontosan mire szolgálnak. Ennek a hiányosságnak a pótlására írom ezt a bejegyzést.

Egy TimesTen rendszer telepítését többféleképpen is el lehet végezni. Megtehetjük ROOT felhasználóként, de lehetőség van NON-ROOT -ként is telepíteni, így csökkentve a kockázatot. Nagyobb biztonságban futtathatjuk a telepítési processzeket, ha csak a szükségeseket indítjuk ROOT felhasználóként. Hozzáteszem, erre Windows platformon nincs lehetőség, de az összes többin igen.
Itt kell megemlítenem, hogy amikor létrehozunk egy Data Store-t, azt megtehetjük GroupRestrict módban is. Ami korlátozott hozzáférést tesz lehetővé a fájlokhoz és a műveleti memóriához egy felhasználói csoport részére. Ez a funkció csak ROOT –ként való telepítés után érhető el.

Megkülönböztetünk Internal Usert (belső felhasználó) és External Usert (külső felhasználó).
Az Internal User a TimesTen (és az Oracle adatbázis esetében is így van) saját felhasználója, csak azon belül érvényes. Az External User az operációs rendszer felhasználója, de implicit lehetséges az authentikációja az adatbáziskezelőben.

Access Control

A TimesTen telepítésekor eldönthetjük, hogy szükségünk van-e egy belső védelemre. Ennek segítségével lehetőségünk van megadni, hogy mely felhasználóknak és alkalmazásoknak milyen hozzáférésük van a telepített TimesTen példányunkhoz. Ezt természetesen a példány-adminisztrátor felhasználóval tudjuk beállítani. (Az Access Control a Data Store -hoz kapcsolódik, annak hozzáférését szabályozza. Mivel minden TimesTen példányhoz külön Data Store tartozik, ezért minden példányhoz külön Access Control is.)
Ezt a technológiát telepítés után is be tudjuk kapcsolni a „ttmodinstall.exe” segítségével. Arra azonban nincs mód, hogy egy példány telepítése után az Access Control -t kikapcsoljuk.
Ahhoz, hogy a TimesTent cache –ként tudjuk használni, szükség van egy belső TimesTen belső felhasználóra, mely egyeztetve van az Oracle adatbázis egy felhasználójával, melynek van elegendő hozzáférési joga a gyorsítani kívánt adatbázis komponensekhez.
Kliens – szerver módban, ha a szerveren az Access Control be van kapcsolva, akkor a szerveren az authentikációnak engedélyezve kell lennie. Máskülönben nem lehet kapcsolódni hozzá.

Forrás:
TimesTen-Documentation/install.pdf

JAVÍTÁS:
Az Access Control részben írtam, hogy:

- "Ennek segítségével lehetőségünk van megadni, hogy mely felhasználóknak és alkalmazásoknak milyen hozzáférésük van a telepített TimesTen példányunkhoz."
Itt természetesen az alkalmazások hozzáférési jogain, az általuk a kapcsolódáshoz használt felhasználók jogait értem.

- "Az Access Control a Data Store -hoz kapcsolódik, annak hozzáférését szabályozza."
Ez nem igaz, mert az Access Control nem a Data Store -hoz kapcsolódik, hanem a TimesTen példányhoz, és a példányhoz való hozááférést szabályozza.

Forrás:
TimesTen-Documentation/install.pdf

TimesTen telepítés

2007-11-04T16:29:00.000+01:00

TimesTen In-memory database installation

Letöltöttem a TimesTen legfrissebb verzióját a hivatalos oldalról:
http://www.oracle.com/technology/software/products/timesten/index.html

- TimesTen 7.0.3 32bit Windows Platform

A telepítést Windows 32-bites platformra próbáltam meg. Ehhez az automatikus telepítő nyújtott segítséget. A tömörített állomány kicsomagolása után a Setup.exe-t futtattam. Miután kitömörítette a telepítési fájlokat, elindul a telepítő, mely végigvezet a telepítési lépéseken.

Első lépésként a telepítési útvonalat adhatjuk meg. Az alapértelmezett beállítást választottam, vagyis: C:\TimesTen\tt70_32\ .

A telepítést háromféleképpen végezhetjük el.
- Kompakt (Compact) : Csak TimesTen kliens és ODBC driverek telepítése, valamint néhány példa hozzá
- Egyedi (Custom) : Egyedi igényeknek megfelelő telepítés Debug funkciókkal.
- Tipikus (Typical) : TimesTen Kliens/Szerver, dokumentációk és példák telepítése.

Ezek közül az egyedit választottam.

A következő képen megadhatjuk, hogy mely komponenseket szeretnénk telepíteni. Ezek a következők:
- Cache Connect to Oracle
- TimesTen Data Manager
- TimesTen Data Manager Debug Libraries
- TimesTen Documentation
- TimesTen Server
- TimesTen Client

Természetesen mindenre szükségem lesz, hogy próbálgatni tudjam a rendszert. A teljes programcsomag 114.13 MB-ot foglal a merevlemezen.

Ha ezzel megvagyunk, akkor utána meg kell adni az adattár elérési útját. Itt sem adtam meg speciális útvonalat, így maradt az alapértelmezett.

A TimesTen környezeti beállításainál lehetőség van regisztrálni a környezeti változókat, valamint itt dönthetjük el, hogy alkalmazzuk-e az Access Control-t. Én mind a kettőt kiválasztottam, hogy megvizsgálhassam a későbbiekben ezek lehetőségeit.

Ezek után meg kell adni, hogy mely Java verzió áll rendelkezésünkre a gépünkön. Nekem a JDK 1.5 van telepítve, ezért a JDK 5.0 –át választottam ki.

Végezetül még egyszer megtekinthetjük, hogy a telepítő miket, milyen beállításokkal fog telepíteni a rendszerünkre.

Elindul a fájlok másolása, de időközben egy ablak ugrik fel, és arra kér, hogy adjam meg a szerver beállításait, melyek a következők:
- Server Hostname (Localhost)
- TCP Port Number (17002)
- Stack Size (20480)
- Log Connects/Disconnects (true/true)

Úgy gondolom, hogy minden megfelelő az alapértelmezett beállításokkal.

A fájlok felmásolása végén még egy kérést szegez nekem a telepítő: Adjam meg a Daemon Webszerver Listen portját(természetesen van alapértelmezett beállítás). Itt is az alapértelmezett értéket választom: 17004.

A telepítés kész. Ezzel és a programmal kapcsolatos további információk a C:\TimesTen\tt70_32\README.HTML fájlban olvashatók.

A TimesTen In-memory Database telepítéséhez szükséges minden információ megkapunk a telepítési dokumentációban:
http://download.oracle.com/otn_hosted_doc/timesten/703/TimesTen-Documentation/install.pdf

Bevezetés

2007-10-29T20:00:00.000+01:00

Már sok idő eltelt a legutóbbi bejegyzésem óta, de nem telt ez idő semmittevéssel. Próbáltam minél többet megtudni a TimesTen technológiáról. Elsődleges forrásnak a hivatalos dokumentációkat tekintettem. Ezek közül is az Introduction -t.
Írtam egy rövid összefoglalót a technológiáról. Ez csak egy rövid áttekintést ad róla, nem részletez semmit fölöslegesen. Viszont törekedtem arra, hogy bárki megértse alapjaiban a működést és ennek előnyeit.
A továbbiakban speciálisabban fogom közelíteni a témát, mégpedig az adatbázis cache-ként való működését szeretném vizsgálni.
TimesTen leírás:
TimesTen intro

Önálló Labor téma

2007-10-10T23:03:00.000+02:00

Ez a blog azért jött létre, hogy figyelemmel kísérhesse és kommentálhassa bárki a kutatási tevékenységemet a memória-adatbázisok témakörében. Ezen belül is a TimesTen Oracle technológiával fogok foglalkozni, mely számomra jelenleg még csak egy nagy feket folt, de remélhetőleg a jövőben nagyon sok mindent fogok megtudni róla. Ez a kutatás a 7-ik féléves Önálló labor című tárgy keretein belül zajlik, amely úgy működik, hogy egy általam kidolgozott ütemterv alapján haladva a konzulenseimmel folyton egyeztetve tárom fel a technolóia lehetőségeit. A félév zárásaként elő kell állnom egy közepes terjedelmű tanulmánnyal, egy írásbeli és egy szóbeli bemutatóval. Jelenleg a konzulenseim Kardkovács Zsolt(TMIT) és Marton József(DB) segítik a munkámat.

Az általam kidolgozott ütemterv:

Feladat/téma címe: Oracle 10g és 11g technológiák

Tervezett munkafázisok a félév során:
2-4. oktatási hét: Ismerkedés a technológiákkal, megbeszélések. Édeklődési kör feltárása. Személyre szabott feladat kiválasztása: Memória adatbázisok, TimesTen rendszer.
5-6. oktatási hét: Irodalom gyűjtése, megfelelő dokumentációk kiválasztása. Ismerkedés a témával.
7-8. oktatási hét: A téme megismerése. Feltárni, hogy milyen lehetőségeket rejt magában a technológia.
9-10. oktatási hét: A feltárt lehetőségek részletesebb vizsgálata.
11-12. oktatási hét: Tesztesetek készítése egy példa adatbázishoz, mellyel igazolom állításaimat.
12. oktatási hét: Írásbeli összefoglaló elkészítése és bedása a konzulensemnek.
13. oktatási hét: Tanulmány véglegesítése, utolsó konzultáció.
14. oktatási hét: Szóbeli beszámoló a tárgyfelelősnek.

A félév első négy hetében azért nem tudtam érdemleges munkát vállalni, mert a 3. és 4. héten Japánban voltam kiküldetésen. Viszont innentől kezdve kész vagyok a témámba beleásni magam.