Önlab III

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

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

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ő

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

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

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

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

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

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

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

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

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ó

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

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

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

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

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

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

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

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

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

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/