Sajnos nem ismerem az ORACLE-t, és más konkrét RDBMS lelkébe sem látok bele, de olvastam könyveket arról, hogy úgy általánosságban hogyan tervezzünk ilyen holmit, ha időnk engedi. Az ördög természetesen azokban a részletekben lak, amik nem publikusak, üzleti titkok, esetleg házon belül sem triviális a hozzáférés. Bár gondolom a kód komplexitása önmagában elegendő titkosítás. :) Szóval a magam ecccerű kis agyával gondolkozva azt képzelem, hogy egy SELECT belső adminisztrációja messze több erőforrást igényel, mint egy WNDS, RNDS, WNPS függvény hívás. És a méréseim is ezt sugalják. Gondolj csak arra, hogy először ki kell nyomozni a winchestered melyik fizikai blokkján van a vágyott cucc, aztán ki kell deríteni ennek a hollétét, és ez lesz az a pont, amikor kiderül, hogy ÖRÖ, BODOTTÁ, bent csücsül a memóriában. Annyi energiám persze nincs, hogy egy valódi alkalmazást terheléses teszt üzemmódban kipróbáljam mindkét verzióval.
Nem tudom, de nekem nehézkesnek tűnik ez a package alapú szótárkezelő módszer.
Ha a szótártáblák IOT-nak vannak definiálva, plusz gondoskodsz arról, hogy memóriában legyenek tartva egy megfelelő keep pool beállítással, akkor lekérdezéskor jó sebességet kellene kapnod.
Főleg, hogy megspórolod a context switch-eket. SQL Select-ből kihívni PL/SQL-be elég költséges még mindig.
Persze ezek csak általános szabályok, a szóban forgó rendszer lehet egy speciális eset.
Ha úgy csinálod, hogy minden vonatkozó érintett select elé teszel dirty-flag olvasást (és feltételezve, hogy ez jó adatkonzisztenciailag az üzleti logikának !!!!), akkor elvben bármikor válthatsz szerintem szótár-verziót és kényelmesen. Ha ennél ritkábban van szükséged szótárváltásra, akkor más módszer is bőven lehetséges.
A honnan-ra is van pár lehetőség: egy soros és egy mezős tábla select, file-ból olvasás: mivel az én elképzelésem szerint nem kéne ezt az infót folyamatosan monitorozni, ezért összeségében nem szabad sok erőforrást zabáljon, egyik változat sem.
Ez elég drasztikus értesítés-fajta. ;) Ráadásul nem-determinisztikus, futás közben _bármikor_ eldobhatja magát a package: a forgácsokat meg konzisztensen összelapátolni nem feltétlen kicsi kihívás. A további függőségekről és általuk generált invalidálódásokról már nem is beszélve. Meg arról, hogy mivel nem a user kódja fog újrafordítani, figyelni kell a validdá-válást stb., ami megint nem feltétlen nagyon kis futásidejű folyamat. STB.
Lehet hogy hulyeseg, de ha ilyenkor ujraforditod a package-t, es a connection pool adott sessionjenek elso hasznaloja kap egy "ORA-04068: existing state of packages has been discarded" hibat, az nem jo megoldas?
Természetesen teszteltem insert-re, select-re. Táblánként több szótárazandó oszloppal. A konzisztenciát
ALTER TABLE adat ADD ( CONSTRAINT chk_status CHECK ( status IN (1,2,3) ) ) /
módon biztosítva
ALTER TABLE adat ADD ( CONSTRAINT fk_adat_status FOREIGN KEY ( status ) REFERENCES status_table ( status_id ) ) /
helyett a karbantartás is gyorsabb. De az igazi hozadék ott van, amikor mékű nagy SELECT kotorászik 15 táblából. Na ha ott meg lehet spórolni 5 szótár JOIN-t, az már buli.
A memóri a pazarlásról meg azt gondolom, hogy semmi sincs ingyen, az mese, hogy a kecske is, meg a káposzta is köszöni szépen jól van. Jelen esetben memóriával fizetek a sebesség növekedésért. És az architektúra olyan, hogy a package egy példánya több tucat felhasználót is ki fog szolgálni.
Na lyó, de a select visszaad 1000 sort, és soronként van 5 szótár hívás, színre, szagra, tudomisén. :) Mikor olvasunk dirty_flag-et, és honnan ?
Tartok tőle, hogy az Általad említett okokból kifolyólag nincs olyan alter, vagy SYS.DBMS_xy hívás, amivel másik felhasználó példányosult package-ének a státuszát befolyásolhatnám.
Akkor csak saját hatáskörben dönthet a futó package a frissítésről, mondjuk óránként ki kell olvasni a dirty_flag-et, és annak megfelően cselekedni.
Utolsó hozzászólás a monológomban :o) Még ha meg is engedhető technikailag én biztos szeretném azt elkerülni, hogy kivülről tudjak manipulálni más usereknek aktív végrehajtás alatt álló változókat. Én mint 'manipulálandó' user szeretném tudni, hogy pontosan ki és mikor manipulálta az adataimat, amit hatékkony, lehetőleg csak a _szükséges_ pillanatban elkövetett explicit rákérdezéssel/tevékenységgel szimpatikus szerintem megejtenem. Összefoglalva - Nem jó út, szvsz, 100%-ban "pusholni" a szótárt a felhasználók felé. - Nem jó út, szvsz, periodikusan folyamatosan monitorozni a szótárváltást (csak amikor kell!) -> erőforrásigény és/vagy nehezen definiálható időtartam miatt. - Egy plusz init-hívás hash-tömb használat elé sem fejlesztésileg nem tragikus feladat, sem performanciában nem tragikus (reális overhead a valamit valamiért elv jegyében). Én ennyit tudtam hozzászólni a kérdéshez első körben.
Ezt még meg lehet fejelni avval, hogy kötelező minden hash-használat elött initet hívni, ami mindösszesen annyi overhead csak pluszban, hogy egy sornyi plsql verzió-összevető if-feltétel (a hash-tömbös package-ben definiálva of course, és nem a hívó package-ben). Ha nincs változás nincs további teendő, ha kell inicializálni, akkor úgy is kell.
A feladat ecccerű, lehet, hogy kicsit elmisztifikáltam. :)
Van egy szótár, kód - érték oszlopokkal. Pl.: 1 - piros ; 2 - kék. A szótár persze egy tényleges táblában lakik. Ez a két pár a package init során bekerül egy hash táblába. Én vagyok a package fejlesztője, tulajdonosa, a nevem "A". Ha "B" nevű felhasználó bejelentkezik, létrejön neki a package-em egy példánya, két sor lesz a tömbjében.
No ekkor jut eszembe, hogy jó lenne a 3 - sárga sor is a szótárba. Én, mint "A" user, vagy "SYS", rá tudom venni "B" user package példányát, hogy futtassa le a szótár frissitő metódusát, hogy az ő létező példányában 3 soros legyen a tömb ?
Azt implicit feltételnek gondolom, hogy a hash-tömbök bármilyen _tárolt eljáráson_ keresztüli elérésével való felhasználása kizárt! (Amivel permanensen és aktuálisan manipulálhatók lennének a bennelévő adatok)
Az én első gondolatom, ha a "felhasználó-kirugdosás" nem opció a túl gyakori szótárváltás és/vagy túl sok egyszerre történő connectálás miatt -> Két package amiből egyik a tényleges package a másik csak aktuális szótár-verziószámot adja vissza (minden kötelező hívásra). És a kicsi, pársoros ám kritikus beékelendő kód annyit csinálna, hogy adott verzió-összevető feltételnél fusson le a tényleges init. Sajnos hátrány, hogy ehhez programozni kell és akár mélyrehatóan is. Azt perpillanat nem látom, hogy hogyan lehetne külső sessionből egy tárolt ejárás változóit konzisztenciát fenntarthatóan direkten manipulálni. Bár lehet, hogy ez a konzisztencia-követelmény extra erős igény jelen esetben.
>...Ezzel meg van egy par problema... Dummy eljárás-hívással szerintem lehet inicializálást 'kézzel' végezni (bár az alapproblémát ez még nem oldja meg) és a package-függőségek is lekérdezhetők. Azt persze nem álíltom, hogy ez a legelegánsabb megoldás, de talán nem lehetetlen.
Ha jol ertettem, akkor a feladat megoldasa annyi, hogy ami most a package init BEGIN...END kozott van, at atteszed egy PROCEDURE init IS BEGIN...END koze, es a package vegi BEGIN-END kozott csak meghivod az init-et. Az init-et publikussa teszed, es igy kivulrol is hivhato lesz.
Ha frissiteni akarsz, akkor siman meg tudod hivni kivulrol az init-et.
A feladat érdekes, jó hogy rákérdeztem. :o) Anélkül, hogy még el tudtam volna gondolkodni, hogy én hogy fognék hozzá, ami eszembejutott: - Szerintem bármely megoldásnál figyelni kell a konzisztens trazakciókezelésre - Az 1 percenkénti lekérdezést én biztos, hogy szeretném elkerülni - Ökölszabály: az Oracle ha _tudja_ figyelembeveszi a _hintet_, még ha azt is hiszi, hogy ő a jobb. Én ezt a tételt még nem bírtam megcáfolni.
Hát igen, ez a megoldás magától értetődő, de pont az a kérdés, meg lehet-e spórolni azt a SELECT-et, ami a dirty_flag-et lekérdezi ? Mert ugye táblát cache-elni nem lehet, bár ráutaló magatartást tanúsíthatsz, de ez gyalog hintón a vészfék, olyan hint szigorúságú, amit akkor vesz figyelembe, ha éppen az ő szándékaival egybe esik. :) OK, ez egy kicsit túlzás, de a lényeget tükrözi.
Persze-persze, az ott van. Csak ha szeretnem a sessionomet kitakaritani, akkor meg kellene minden olyan package inicializalasat hivnom, ami mar inicializalodott a sessionben. Ezzel meg van egy par problema: - nem is tudom hogy meg tudom-e hivni az inicializalast "kezzel" - fogalmam sincs, hogy az altalam hivott package-ok milyen mas package-okat hivtak, amik ugye mind inicializalodtak
Ha netán nincs mód az inicializáció újra lefuttatására, akkor nyugodtan használhatod, hogy egy táblába bejegyzed, hogy mikor volt frissítve a szótár. Ezt a táblát jól becacheled. Minden szótárhoz fordulás azzal kezdődik, hogy megnézi, hogy a saját szótár verziója régebbi-e, mint az aktuális. Ha igen, akkor szépen frissíti magának. Ha túl sok szótárhoz fordulás van, akkor még megfejelheted azzal, hogy max 1 percenként nézze meg a szótár verzióját. Így legfeljebb 1 perc múlva mindenki szépen megfrissíti (gondolom nem kis munkával) a saját szótár-cache-ét.
Connection pool-on keresztül jönnek az applicicók. Az RDBMS oldali kiszolgálás óriási terheket cipel, vannak kikerülhetetlen tisztelet körök, amik nem az alkalmazást szolgálják, de kötelező gyakorlatok. Ezért szótárakat VARCHAR2-vel indexelt VARCHAR2 hash tömbökben tartanék, és a konzisztenciára CHECK CONSTRAINT-ek ügyelnének. Már a szótárakkal kapcsolatban. :) No ha a szótár bövülésének helyzete a fennforgás, akkor kéne a hast tömböket frissíteni. Ezek nyilván feltöltődnek a package indulásakor, az inicializáló rész aktiválja a megfelelő eljárást, de ha bővítem a szótárat, jó lenne, ha nem kellene mindenkinek kilépni-belépni Nyíregyházától Sopronig, hanem megkérném szépen a package-et, hogy tegye, amit szeretnék. Ehhez minden jog rendelkezésre áll, a package-nek tulajdonosa vagyok, de system-ként is tudok scrip-et futtatni, ha ez feltétel.
>...karbantartasi funkcioi egyre lassabbak. Teljesen erthetetlen volt...
Na ilyen sztorim nekem is volt: életem tán legnagyobb botrányát generáltam vele. A helyzetet lehet, hogy sőt megengedem, hogy egyáltalán nem jól kezeltem (botrány-elfajulást illetően), de a szakmai ösztönöm még engem is kellemesen meglepett. Szintén ugyanilyen környezetben az adatrögzítők panaszkodtak, hogy lassulás van és mivel kritikus hózárási időben volt és az OLTP-rendszer együtt lakott a szerveren a DW-vel, ezért felkérték a DW-csapatot, hogy fogják vissza magukat, mondván az szívja le az erőforrásokat. Most eltekintve attól, hogy hózáráskor a DW-csapatnak is vannak éles határidői és egyáltalán miért van egy szerveren és vinyón egy OLTP és egy DW-rendszer, első - saját portán körülnézéses - vizsgálódás után kiderült a DW-csapat semmi durvát nem csinált, de hát ez belátható, hogy így ebben a formában kevés. Viszont titokban rénéztem az ügyintézői formok lassulására (a rögzítők bárhonnan bármilyen ötletet szívesen vettek volna, annyira kétségbe voltak esve) és feltünt, hogy az egyik legördülő box relevánsan lassabb. Na kiderült, hogy mögötte egy durva sql volt, ami addig optimális volt, de egy adott mérethatáron túllépve az Oracle tervet váltott (outline hiányában). Akár hihető akár nem, nem a baj gyökerének megtalálása vezetett a ráadásul gyorsnak tekinthető sikerhez, hanem az utána való hosszú és mély intrika illetve megbánható elkapkodott cselekedetek (a feszült helyzetben aztán már sajnos részemről is) mérgezték a levegőt.
Technológiai értelemben pedig egy tárolt eljárásban sikerült igen csalafinta módon egy delete-t dinamikusan úgy összrakni, hogy a where mindig igazat adott, következésképp futáskor egy komplett egész tábla törlődött. Persze volt mentés, de több ember nagy melója kellett a teljes rekonstrukcióhoz. Beleborzadok per a mai napig is pedig sok-sok éve volt már.
>hogy nem találok másik munkahelyet... ennél nagyobb kudarcom egyelőre nincs.
Mondjuk én technológiai kudarcra gondoltam ;) De ez a felvetett téma is megérne egy misét.
- Ugye Oracle-s informatikusi állás biztos nagyon sok van lásd akár jobmonitor.hu (vagy lásd még akár ezt a topicot is), csak hát az ember szeretne _jól_ választani, és az valóban nem könnyű. - A két legnagyobb nehézség szerintem magyar viszonyok között, hogy egyik mainstream elvárás szerint akár éjszakákba is nyúlóan kilóra kell programozni akár plsql-ben egy örökölt borzalmas rendszeren illetve a minőségibb állásoknál az angol nyelvtudás milyensége. - A harmadik tényező a pénz és annak kifzetési formája. Ez ma Magyarországon közel nem triviális probléma.
Csak ezek együtt már tudnak okozni nagy nehézségeket (akár csak az állások összehasoníltásában is, feltéve, hogy rendelkezésre állnának, ahogy nem állnak hiteles információk), pedig a finom részletek, kapcsolatok, álláskereső-stratégiák, érdekes munkavállalói (teszt)kérdések a munkáltató felé és társai még szóba sem kerültek.
Én azt gondolom aki munkát keres annak nem elég hogy az állásajánlatokra megcsinálja a saját pros-cons tábláját, de bőven kellhet szempont-prioritási lista fix ponttal. Ha ez így van -> csak ennyi alapján is ahány ember szinte annyi lehetőség az optimális megoldás meghatározásában.
Egyszer jó lenne ezt az állásválasztás-témát is egyszer őszintén és részleteiben végigbeszélni akár itt, akár külön topicban. De vannak topicok, amik még nem érettek erre: ilyen topic például a BI, DW & Data Mining. ;)
PS: És a sikersztorik után az milyen lenne; megírni a legnagyobb kudarcokat is tesztelendő az idevonatkozó 'bátorságot' ;)
Kvazi kudarc: Visszajelzest kaptunk, hogy az egyik rendszerben (Forms 6.0, Ora 8.1.7) az egyik legnagyobb tabla karbantartasi funkcioi egyre lassabbak. Teljesen erthetetlen volt, 3man napokig szivtunk, mire valaki nagy nehezen rajott, hogy egy forms trigger minden tranzakcio utan vegrehajt egy updatet a tablan egy (raadasul semmire sem hasznalt) flag atallitasara, ahol nem volt WHERE!!! 2 millio rekordnal mar kicsit elbibelodott vele :-) Persze elotte neztuk adatbazis oldalrol a felh prog altali tranzakciokat, csak nem ertettuk, hogy miert teszi a hossu tranzakciok koze a sima rekord modositast.
Multkor egy 7.3-as rendszert migraltunk 10gR2-re, a hintek nagy reszet ki kellett dobni, csak lassitottak a futason. Egyebkenk 1998 ota nem nyultak hozza a rendszerhez, sem az felh programhoz, sem adatbazis oldalon. Most is csak azert kellett lepni vmit, mert kezdett kinyuvadni a vas a rendszer alatt es valamit lepni kellett :-)
