Architektúra part #8 – Processz architektúra

Ez a fejezet az Oracle adatbázis processzeivel (folyamataival), illetve az adatbázis különböző konfigurációival foglalkozik.
Minden Oracle adatbázishoz csatlakozott felhasználónak két kód-modult kell futtatnia ahhoz, hogy hozzáférhessen egy adatbázis példányhoz. Ezek:

• Valamilyen adatbázis alkalmazás (pl. előfordító program) vagy Oracle eszköz (pl. SQL*Plus) amely SQL utasításokat továbbít egy Oracle adatbázishoz.


• Adatbázis szerver kód, amely értelmezi és végrehajtja az SQL utasításokat.

Ezeket a kód-modulokat futtatják a processzek. Ennek megfelelően a processzeket is két fő csoportra oszthatjuk: felhasználói processzek, melyek az alkalmazás kódját futtatják, illetve Oracle adatbázis processzek, ahová a szerver- és háttérfolyamatok tartoznak.
A processzek struktúrája függ az operációs rendszertől és az adatbázis beállításaitól is. Dedikált vagy osztott szerveres megoldások közül választhatunk. Dedikált szerveres kapcsolat esetén minden felhasználóhoz tartozik egy felhasználói (user) és egy dedikált szerver processz, míg osztott szerveres kapcsolatnál egy szerver processz akár több felhasználót is kiszolgálhat egyszerre.

Felhasználói processzek (User Processes):
Ha egy felhasználó valamilyen adatbázishoz csatlakozó alkalmazást vagy Oracle eszközt (pl. Enterprise Manager vagy SQL*Plus) futtat, akkor az adatbázis automatikusan létrehoz számára egy felhasználói processzt, mely a felhasználó alkalmazását fogja kezelni. Néhány fogalom:
Kapcsolat (Connection): kommunikációs csatorna a felhasználói processz és az adatbázis példány között. Használhat interprocessz kommunikációt, ha a felhasználói processz és az adatbázis egy gépen helyezkedik el, illetve csatlakozhat hálózaton keresztül, ha különbözőn.
Session: egy adott felhasználóhoz tartozó kapcsolat (a felhasználói processzen keresztül az adatbázishoz).

Szerverfolyamatok (Server Processes):
Az Oracle adatbázis szerver processzek segítségével kezeli le a felhasználói processzek kéréseit. Bizonyos esetekben, ha a felhasználói- és a szerver processz egy gépen fut, akkor lehetőség van a két processzt összevonni, hogy csökkentsük az interprocessz kommunikációból származó overheadet. Hálózaton keresztül történő kommunikáció esetén azonban mindenképpen szükség van két külön processzre.
Az egyes felhasználói alkalmazásokhoz rendelt szerver processzek a következő feladatokat láthatják el:

• elemzi és futtatja az alkalmazás által kiadott SQL utasításokat


• beolvassa a szükséges adatblokkokat az SGA osztott adatbázis bufferjeibe, ha azok még nincsenek bent


• olyan formában adja vissza az eredményeket, amiket az alkalmazás képes feldolgozni

Háttérfolyamatok (Background Processes):
A teljesítmény maximalizálása és a felhasználók kezelése érdekében az Oracle adatbázis számos háttérfolyamatot (background process) futtat. Ezekről információkat a V$BGPROCESS nézetből nyerhetünk ki (ábra).
Archiver Processes (ARCn): a rendszerben két redo log fájl található, egyszerre csak az egyiket írjuk. A két fájl cseréje után az éppen nem írás alatt álló fájlt ez a folyamat írja ki egy merevlemezre. Továbbá tranzakciókhoz kapcsolódó redo információk gyűjtésére is alkalmas, melyeket egy készenléti helyen tárol. A LOG_ARCHIVE_MAX_PROCESSES inicializálási paraméter segítségével korlátozhatjuk az archiváló folyamatok számát (aminek segítségével például nagy mennyiségű adat feltöltésekor keletkező jelentős archiválási munkát tudjuk szabályozni).
Checkpoint Process (CKPT): checkpointok előfordulásánál frissíti az adatfájlok (datafiles) fejlécét.
Database Writer Process (DBWn): a bufferek tartalmának merevlemezekre írását végzi. Pontosabban a bufferekben található régen használt (cold) és módosított (piszkos - dirty) adatokat írja ki a merevlemezekre, illetve biztosítja, hogy a felhasználói processzek számára mindig legyen üres buffer, ahova adatblokkokat olvashatnak be. Alapvetően egy ilyen processz (DBW0) is elegendő, azonban többprocesszoros rendszerek esetén létrehozhatunk továbbiakat (maximum 20-t) DB_WRITER_PROCESSES inicializálási paraméter segítségével – de ezt egyébként is elvégzi az adatbázis a processzorok száma és processzorcsoportok alapján.
A piszkos buffereket a következő esetekben írjuk ki a merevlemezre:

• ha a szerver processz egy bizonyos számú buffer átvizsgálása után sem talált üreset, akkor jelez a DBWn-nek, aki aszinkron módon kiír néhány piszkos buffert a lemezre


• periodikusan ír ki buffereket, hogy újabb checkpointokat (az a pont a redo logban, ahonnan hiba esetén a visszaállítást kezdeni kell) érjen el. A checkpoint helyét a redo logban a buffer cache legöregebb piszkos bufferje határozza meg.

A jobb teljesítmény érdekében a DBWn kötegelve (multiblock) írja ki a blokkokat a merevlemezre.
Job Queue Processes: kötegelt feldolgozás esetén használatosak. Gyakorlatilag egy ütemezőnek tekinthető, ami a megadott kezdeti idő és intervallum alapján megpróbálja végrehajtani a feladatot a megadott időintervallum előfordulásaikor. Egyszerre számos felhasználói feladatot képesek ütemezni. Működésük:

1. A koordinátor processz (CJQ0) periodikusan kiválasztja a rendszer JOB$ táblájából a futtatandó feladatokat. Az újonnan kiválasztott feladatokat idő szerinti sorrendbe helyezi.


2. A CJQ0 dinamikusan létrehoz Job Queue szolga processzeket (J000..J999) a feladatok futtatására.


3. A Job Queue processz lefuttatja az egyik CJQ0 által kiválasztott feladatot.


4. A végrehajtott feladat után a processz újabb feladatért jelentkezik (polling). Ha nincs más végrehajtandó feladat, akkor átmegy alvó üzemmódba, ahonnan periodikus időközönként felébred és kér újabb feladatokat. Ha bizonyos ideig nem talál új feladatot, akkor a processz leáll.

A Job Queue processzek maximális számát a JOB_QUEUE_PROCESSES inicializálási paraméter segítségével állíthatjuk be.
Log Writer Process (LGWR): ez a folyamat végzi a redo log bufferek tartalmának kiírását a redo log fájlokba. A redo log buffer egy körkörös buffer, azaz amint az LGWR kiírta a redo bejegyzéseket a redo log fájlokra, a szerver processzek felülírhatják a már kiírt bejegyzéseket az újakkal. Az LGWR általában elég gyors ahhoz, hogy még nagy terhelés esetén is mindig biztosítson szabad buffereket az új bejegyzések számára.
Ír a redo log fájlokba, ha:

• egy felhasználói processz jóváhagy (commit) egy tranzakciót, egy commit bejegyzést.


• redo log buffereket: 3 másodpercenként; ha 1/3ig megteltek; mielőtt a DBWn kiírja a piszkos buffereket.

Az LGWR egyidejűleg ír több aktív redo log fájlba. Ha az egyik fájl sérül, vagy elérhetetlenné válik, akkor folytatja a többi fájlba történő írást, s logolja a hibát az LGWR trace fájljában és a system alert logban. Ha minden fájl sérült, vagy elérhetetlen, mert még nem archiválták, akkor az LGWR nem tud tovább működni.
Ha egy felhasználó kiad egy COMMIT utasítást, akkor az LGWR egy commit bejegyzést tesz a redo log bufferbe, s azt a tranzakció redo bejegyzéseivel együtt azonnal a merevlemezre írja. Az adatblokkok kiírása azonban nem feltétlen azonnal – jellemzően egy másik, hatékonyabb időpontban történik. Ezt az eljárást hívjuk fast commit-nak, mivel az adatbázis ugyan visszajelzi a tranzakció jóváhagyásának sikerességét, de az új adatokat még nem rögzítettük a merevlemezen. A jóváhagyást követően a tranzakcióhoz rendelünk egy system change number (SCN)-t is, amely RAC-ok és elosztott adatbázisok esetén a szinkronizált visszaállításnál elengedhetetlen.
Nagy terhelés esetén az I/O műveletek csökkentése és a teljesítmény növelése érdekében az LGWR több commitot egyszerre, úgynevezett group commit-ként is ki tud írni.
Process Monitor Process (PMON): amikor egy felhasználói processz sikertelenül ér véget, ő végzi a processz helyreállítását: kitakarítja az adatbázis buffer cacheét, s felszabadítja a felhasználói processz által használt erőforrásokat. Periodikusan ellenőrzi az ütemező és a szerver processzek állapotát is, s újraindítja őket, ha szükséges. Ezen kívül információkat az adatbázis példányról, valamint a hálózati listenerek ütemező processzeiről.
Működése hasonló az SMON-éhoz: periodikusan ellenőrzi, hogy szükség van-e rá, s működésbe lép, ha egy másik processz igényli.
Queue Monitor Processes (QMNn): opcionális háttérfolyamat az Oracle Streams Advanced Queuing számára, mely az üzenetsorokat monitorozza. Maximálisan 10 ilyen sorfelügyelő processzt állíthatunk be. Hasonlóan a job queue processzekhez, ő is különbözik abban a többi háttérfolyamattól, hogy meghibásodása nem okozza az adatbázis példány meghibásodását.
Recoverer Process (RECO): elosztott adatbázisok esetén használatos háttérfolyamat, mely az elosztott tranzakciók hibáit kezeli. Bizonytalan elosztott tranzakció esetén a RECO automatikusan csatlakozik a másik adatbázishoz, s miután helyreállította a kapcsolatot az adatbázis szerverek között, eltávolítja az adott tranzakcióknak megfelelő sorokat mindegyik adatbázis várakozó (pending) tranzakciós táblájából.
Ha nem sikerül a RECO-nak helyreállítania a kapcsolatot a másik adatbázissal, exponenciálisan növő időközönként újra próbálkozik.
System Monitor Process (SMON): az adatbázis példány indítását követő helyreállításokat végzi, ha erre szükség van. Feladatai köze tartozik még az ideiglenes szegmensek használat utáni kitakarítása, valamint a könyvtár vezérelt táblaterek (dictionary managed tablespaces) összefüggő üres extentjeinek összeolvasztása. Ha a példány helyreállítása során fájlolvasási vagy offline hiba miatt bármely lefutott tranzakciót ki kellett hagyni, akkor az SMON ezt később azonnal újra próbálja, ha az adott táblatér (tablespace) vagy fájl ismét elérhető (online) lesz.
Hasonlóan a PMON-hoz, periodikusan ellenőrzi, hogy szükség van-e rá, meghívta-e egy másik processz.
Egyéb Oracle adatbázis háttérfolyamatok (röviden):
ACMS (automatic controlfile to memory service): Oracle RAC környezetben használatos. Biztosítja az elosztott SGA frissítését globális commit/abort esetén.
ASMB: a kommunikációt látja el az Automatic Storage Management példánnyal.
DBRM (database resource manager): erőforrás tervezést vagy más erőforrás menedzser taszkok létrehozását végzi.
DIA0 (diagnosability process 0): holtpont detektálás és feloldás a feladata.
DIAG (diagnosability): diagnosztikai memóriakiíratás és globális „oradebug” parancsok futtatása.
EMNC (event monitor coordinator): adatbázis eseménykezelés és értesítések.
FBDA (flashback data archiver process): flashback adatarchívumok menedzselése.
GMON: karbantartja az ASM diszkcsoportjainak taglistáját.
GTX0-j (global transaction): Oracle RAC környezetben használatos XA globális tranzakcióknak nyújt transzparens támogatást.
KATE: ASM háttérfolyamat, amely végrehajtja a proxy I/O-t egy ASM metafájlon, ha egy merevlemez offline lesz.
MARK: megjelöli az ASM allokációs egységeit egy offline lemezre történő sikertelen írási kísérletet követően.
MMAN: belső adatbázis taszkok számára.
MMNL: a gyakori és jelentéktelenebb menedzseléssel kapcsolatos feladatokat látja el.
MMON: különböző menedzseléssel kapcsolatos háttérfeladatok végrehajtása.
ARBn: egy ASM példányon belüli aktuális kiegyenlítő extent mozgatásokat végzi.
PSP0 (process spawner): Oracle processzek létrehozása.
RBAL: egy ASM példányon belül a diszkcsoportok közötti kiegyenlítést koordinálja.
SMCO (space management coordinator): tárhely kezeléssel kapcsolatos taszkok koordinálása. Dinamikus létrehoz szolga processzeket (Wnnn) a taszkok implementálására.
VKTM (virtual keeper of time): felel a falióra idejének (másodpercenkénti frissítés) és a referenciaidő számlálónak (20ms-enkénti frissítés) a karbantartásáért.

Trace fájlok és Alert log:
Az Oracle 11g újdonságaként a problémák megelőzésére, észlelésére, diagnosztizálására és megoldására egy fejlett hibadiagnosztizáló infrastruktúra lett a rendszerbe beépítve. Főként a kritikus hibák észlelése volt a cél, amiket például adatbázis programhibák, meta- vagy ügyféladat sérülések okozhatnak.
Kritikus hiba fellépése esetén egy incidens számot rendelünk a hibához és a hozzá tartozó diagnosztikai adatokat (pl. trace fájlok) azonnal begyűjtjük és megjelöljük ezzel az incidens számmal. Az adatokat az Automatic Diagnostic Repositoryban (ADR) – adatbázison kívüli, fájl alapú tárhely – mentjük el, ahonnan később az incidens szám alapján visszakereshető és analizálható a hiba.
Minden szerver- és háttérfolyamat belső hiba észlelése esetén kiírja a hibához kapcsolódó információkat a saját trace fájljába. Továbbá a háttérfolyamatok kiegészítő információkat is írhatnak a trace fájlba, ami segítheti az alkalmazás vagy az adatbázis példány hangolását.
Minden adatbázishoz tartozik egy alert.log fájl is, mely időrendi sorrendben tartalmazza a következő üzeneteket és hibákat:

• Minden belső hiba (ORA-600), blokk meghibásodás hiba (ORA-1578) és holtpont hiba (ORA-60).


• Adminisztratív műveletek, úgy mint CREATE/ALTER/DROP DATABASE/TABLESPACE SQL utasítások, valamint az Enterprise Manager/SQL*Plus STARTUP/SHUTDOWN/ARCHIVE LOG/RECOVER utasításai.


• Különböző elosztott szerver és ütemező folyamatok működéséhez kapcsolódó üzenetek és hibák.


• Materializált nézeteket automatikus frissítése során fellépő hibák.

Elosztott szerveres architektúra (Shared Server Architecture):
Az elosztott szerveres architektúrában nem szükséges minden kapcsolathoz dedikálnunk egy-egy külön szerver processzt. Az ütemező a bejövő kéréseket az elosztott szerverfolyamatok készletéhez irányítja, ahonnan egy éppen tétlen folyamat fogja a kérést lekezelni. Így tulajdonképpen néhány elosztottan működő szerverrel tudjuk ugyanazt a teljesítményt produkálni, mint sok dedikált szerverrel együtt. Ezen felül mivel így az egy felhasználó számára szükséges memória is relatív kicsi, kevesebb memória és processz menedzsment szükséges, s egyidejűleg több felhasználót tudunk kiszolgálni.
Elosztott szerveres rendszerek esetén a következő processzekre van szükség:

• egy hálózati listener processz, amely létrehozza a kapcsolatot a felhasználói processzek és az ütemezők vagy a dedikált szerverek között.


• egy vagy több ütemező processz


• egy vagy több elosztott szerver processz

Az adatbázispéldány indulását követően a listener processz létrehozza a kommunikációs portot, amin keresztül a felhasználók csatlakozhatnak az adatbázishoz, majd minden ütemező processz megadja a listernek azt a címet, amin várja a kapcsolat-felépítési kérelmeket. Használt hálózati protokollonként szükség van legalább egy megfelelően konfigurált ütemező processzre.
A felhasználói processz kapcsolat-felépítési kérelme után a listener megvizsgálja, hogy a felhasználó processze használhat-e elosztott szerver processzt. Amennyiben igen, úgy a listener visszaadja számára a legkevésbé terhelt ütemező címét, amihez aztán a felhasználói processz közvetlenül csatlakozhat. Néhány felhasználói processz azonban nem képes az ütemezővel kommunikálni, dedikált szerverre van szüksége. Ebben az esetben a listener létrehozza a dedikált szervert és felépíti a megfelelő kapcsolatot.
Ütemező kérés- és válaszsorai: egy felhasználói hívást követően az ütemező a kérést a kéréssorba (request queue) helyezi, ahonnan a következő rendelkezésre álló elosztott szerver processz azt kiveszi. A kéréssort az SGA-ban tároljuk. Minden adott adatbázispéldányhoz tartozó ütemezőnek egy közös kéréssora van, ahonnan a szabad elosztott szerver processzek a kéréseket FIFO módon szedik ki. A kérés kiszolgálását követően a kiszolgálást végző elosztott szerver processz a választ a hívást kezdeményező ütemező saját válaszsorába helyezi el (response queue). Minden ütemező saját válaszsort tart fenn az SGA-ban, s innen továbbítja a teljesített kérésekre kapott választ a megfelelő felhasználói processznek.
A kérés kiszolgálását követően tehát a felhasználó kapcsolatban maradhat, azonban nem kell számára egy külön processzt továbbra is fenntartani. A kérést kiszolgáló processz miután a választ elhelyezte a megfelelő válaszsorban, hozzáfoghat új, akár más felhasználóktól származó kérések kiszolgálásához is (ábra).
Ütemező folyamatok (Dnnn): az ütemező folyamatok teszik lehetővé az elosztott szerveres konfiguráció számára, hogy a felhasználói folyamatok néhány limitált számú szerverfolyamaton osztozzanak. Ezáltal mivel kevesebb szerverfolyamatra van szükség, mint felhasználói folyamatra, egyidejűleg jóval több felhasználó szolgálható ki.
Egy adatbázis példányhoz akár több ütemező folyamatot is létrehozhatunk, az adatbázis által használt hálózati protokollonként egy azonban mindenképpen szükséges. Ütemező folyamatokat akár az adatbázis futása közben is létrehozhatunk vagy eltávolíthatunk.
Elosztott szerveres beállítások esetén a listener processz fogadja a felhasználói alkalmazásoktól beérkező kapcsolat-felépítési kérelmeket, s irányítja őket az ütemezőkhöz. Ha az alkalmazás nem képes ütemezőhöz csatlakozni, akkor a listener létrehoz számára egy dedikált szerver processzt. A listener processz nem az Oracle adatbázispéldány része, hanem az adatbázissal együttműködő hálózati processzekhez tartozik.
Elosztott szerverfolyamatok (Snnn): elosztott szerveres architektúra esetén minden szerverfolyamat több klienst szolgálhat ki (de nem egyidejűleg). Funkcionalitását tekintve nincs különbség dedikált és elosztott szerverfolyamatok között, csupán annyiban térnek el, hogy az elosztott szerverfolyamatok nincsenek egy megadott felhasználói folyamathoz hozzárendelve, hanem bármelyik kliens kéréseit kiszolgálhatják. Ebből kifolyólag az elosztott szerverfolyamatok PGA-ja nem is tartalmaz semmilyen felhasználói információt, csak egy veremet és processz-specifikus változókat. A sessionökhöz tartozó információkat az SGA-ban tároljuk, így minden szerverfolyamat által hozzáférhetőek. Adott sessionökhöz tartozó terület méretét a PRIVATE_SGA paraméter beállításával limitálhatjuk.
A szerverfolyamatok számát az adatbázis dinamikusan állítja egy, a SHARED_SERVERS és MAX_SHARED_SERVERS inicializálási paraméterek között megadott értékre a kéréssor hosszának függvényében.
Az elosztott szerver korlátozott műveletei: bizonyos adminisztratív feladatok (pl. adatbázis leállítása, indítása, adathordozó helyreállítás) nem hajthatóak végre, ha ütemező folyamathoz csatlakozunk – hibaüzenetet fogunk kapni. Ezért ha adminisztrátorként csatlakozunk egy adatbázishoz, célszerű a connection stringben explicit megadni, hogy dedikált szerverfolyamatot (SERVER=DEDICATED) szeretnénk használni.

Dedikált szerveres architektúra (Dedicated Server Configuration):
Dedikált szerveres architektúra esetén minden felhasználói folyamathoz külön szerverfolyamatot rendelünk (ábra). Ezeket a processzeket hívjuk dedikált szerverfolyamatoknak, mivel csak a hozzá tartozó felhasználói folyamat nevében cselekszenek. Mindig ugyanannyi szerverfolyamatunk lesz, mint amennyi felhasználói – a szerverfolyamat akkor is megmarad inaktívként, ha a hozzá tartozó felhasználói folyamat éppen nem intéz kérést az adatbázis felé.
Bizonyos operációsrendszerek esetén (pl. UNIX) akkor is szükség van külön szerverfolyamatokra, ha a kliensalkalmazás és a szerver ugyanazon a gépen fut, ugyanis ezek az operációsrendszerek nem lennének képesek külön kezelni a két programot, ha egy közös processz tartozna csak hozzájuk.

Database Resident Connection Pooling (DRCP):
A DRCP egy connection pool-t (Connection pool) nyújt tipikusan web alkalmazások számára. Különösen hasznos olyan többprocesszes, egyszálas alkalmazásszerverek (pl. PHP és Apache szerverek) skálázhatóságának javításában, melyek nem képesek középső rétegbeli connection poolingra. A webes alkalmazások egy szálon, általában csak rövid ideig használják az adatbázis-kapcsolatot. Ennek támogatására a DRCP tulajdonképpen azt teszi lehetővé, hogy az egyes processzek közösen osztozzanak a dedikált szervereken, azaz nem kell minden egyes kapcsolatot újra kiépíteni, aminek következményeként nagyszámú klienskapcsolatot tudunk kiszolgálni jóval szerényebb erőforrásokkal is (csökkenti a szükséges memóriát, növeli az adatbázisszerver és a középső réteg skálázhatóságát, valamint csökkenti újbóli kapcsolat-felépítésekhez szükséges időt).
A pooled szerver modell nagyban hasonlít az Oraclenél alapértelmezésben használt dedikált modellhez. A különbség csupán annyi, hogy csökkenti a szervert csak rövid ideig igénylő kapcsolatoknál a szerverdedikálásból fakadó overheadet. A kliensek a „connection broker”-hez csatlakoznak, ami a pool működését implementálja és multiplexálja a pooled szervereket a kliens processzektől bejövő kapcsolatok között (ábra). Ha egy kliens adatbázis-műveleteket szeretne végrehajtani, akkor a connection broker kiszed a poolból egy pooled szervert, s hozzárendeli a klienshez. Innentől a kliens már közvetlenül csatlakozik a pooled szerverhez, melynek a működése teljesen azonos lesz egy dedikált szerverével. A kérés kiszolgálását követően azonban a szerver visszakerül a pool-ba, s a kliens is visszacsatlakozik a connection brokerhez.
DRCP használatához az adatbázis adminisztrátorának explicit el kell indítania a pool-t. Az alapértelmezett connection pool-t SYS_DEFAULT_CONNECTION_POOL-nak nevezik, így ennek elindítása SYSDBA-ként bejelentkezve a következő paranccsal hajtható végre:

EXECUTE DBMS_CONNECTION_POOL.START_POOL(‘SYS_DEFAULT_CONNECTION_POOL’);

A megosztott pool-hoz történő csatlakozáshoz továbbá a server típusát is POOLED-ra kell állítani a connection stringben. Erre egy példa:

ServerPool = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=somehost)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=testdb)(SERVER=POOLED)))

Vagy egyszerű connect parancs használatával:

CONNECT joeuser@myhost.mydomain.com:1521/mydb:POOLED

Kapcsolatosztályok: logikai neveket definiálnak különböző alkalmazások által igényelt kapcsolattípusokra. Két különböző felhasználó nem oszthat meg egymás között kapcsolatot vagy sessiont. Továbbá lehetőség van egy felhasználón belül az alkalmazások közötti elkülönítésre is. A DRCP biztosítja, hogy egy kapcsolatosztályhoz tartozó session nem osztozkodik a kapcsolatosztályon kívüli sessionökkel.
Session Purity: meghatározza, hogy az alkalmazás egy teljesen új sessiont igényel-e (PURITY=NEW), vagy pooled sessiont kívánja használni (PURITY=SELF). Utóbbi esetben az alkalmazás egy igényelt kapcsolatosztályú szabad sessiont kap.
A kapcsolatosztályokat és a session purityt a kliens a DRCP kapcsolat attribútumaiban határozhatja meg. Alapértelmezésben a kapcsolatosztály értéke username.SHARED, illetve a purity értéke NEW. Ezek azonban alkalmazások esetén eltérhetnek, ezért célszerű az alkalmazás manualjében utánanézni.

Program interfész (Program interface):
A program interfész egy szoftver réteg az alkalmazás és az Oracle adatbázis között, mely a következőket végzi:

• biztonsági falat képez, amely megakadályozza a felhasználói processzek destruktív hozzáférését az SGA-hoz.


• kommunikációs mechanizmusként viselkedik: formázza az információkéréseket, továbbítja az adatokat, valamint elkapja és visszaadja a hibákat.


• konvertálja és lefordítja az adatot, különösen különböző típusú számítógépek között, vagy külső felhasználói adattípusok számára.

Bővebben: link



Kapcsolódó Link
Oracle® Database Concepts – Process Architecture

Önlab megbeszélés #2

A mai napon lezajlott az idei második önálló laboros megbeszélés, amelyen néhány felmerülő kérdés után négyünknek nyílt lehetősége arra, hogy bemutassa röviden mivel foglalkozott az eddigiek során.
Az általam készített prezentáció, mely tulajdonképpen egy architektúra gyorstalpaló szeretett volna lenni, innen tölthető le.
A megbeszéléssel kapcsolatos tapasztalataim/észrevételeim:

• szerintem a beszámóló jellegű előadások főleg a konzulensek számára érdekesek. A többi hallgatót úgy gondolom jobban érdekelnék a szakmai jellegű bemutatók, azokra viszont 15 perc édeskevés... legalább 30 percet, de inkább egy órát kéne rászánni.
• máskor nem próbálok meg 10 percbe belesűríteni egy minimum 10 órás anyagot, illetve ha mégis, akkor arra nem 1-2 óra felkészülést kell szánni, hisz ellentétben a másfél órás előadásokkal, itt nincs lehetőség arra, hogy közben átgondolja az ember, hogy mit fog mondani a következő percekben:)
• nem iszom meg előre a vizemet, mert mint mindig, most is annyira kiszáradt a szám, hogy alig tudtam beszélni:)

Ha később eszembe jut még más is, akkor frissítem a bejegyzést.

Architektúra part #7 – Memória architektúra

Az Oracle adatbázis memóriájában a következő komponenseket tároljuk:

• programkód


• információ a csatlakozott active és inactive sessionökről


• programvégrehajtás közben szükséges információk, állapotok


• az adatbázis processzei között megosztott információk (pl. zárak)


• cachelt adatok, mint pl. adatblokkok és redo log bejegyzések, amik ugyanakkor természetesen tárolva vannak a merevlemezeken is

A memória struktúrája ábra alapvetően három része osztható:

• szoftver kód területek: az éppen futó vagy futtatható kódokat tartalmazza. Általában a felhasználói programoktól eltérő helyen van.


• System Global Area (SGA): az összes szerver- és háttérfolyamat (processz) között megosztott memória struktúrák (SGA komponensek – lásd fenti ábra) csoportja. Adat és vezérlési információkat tartalmaz.


• Program Global Area (PGA): egy bizonyos szerver processzhez tartozó adat és vezérlési információkat tartalmazó memóriaterület, mely a szerverprocessz indításakor jön létre, s csak ő fér hozzá. Minden egyes szerverprocesszhez (és háttérfolyamathoz) tartozik egy-egy PGA. Az adatbázis inicializálási paramétereinél megadott PGA méret az összes PGA együttes méretére, s nem az egyes példányokra vonatkozik.

System Global Area (SGA):
Az adatbázis processzeinek halmaza az SGA-val együtt alkot egy adatbázis példányt (instance). Minden egyes adatbázis példány létrehozásakor az Oracle adatbázis automatikusan lefoglal memóriát az SGA számára, s visszaadja az operációs rendszernek a példány a leállításakor.
Az SGA egy írható és olvasható memóriaterület. Minden szerverprocessz és háttérfolyamat olvashatja, s néhány processz adatbázis műveletek során írhatja is.
Az SGA egy része a háttérfolyamatok számára tartalmaz általános információkat az adatbázis és a példány állapotáról. Ezt a területet hívjuk fixed SGA-nak. A változó rész elsősorban a processzek között kommunikált információt (pl. zárolási információk), illetve osztott szerver-architektúra esetén a kérés/válasz sorokat és a PGA tartalmának egy részét tárolja.

A legfontosabb SGA komponensek:

Database Buffer Cache: az adatfájlokból (datafiles) beolvasott adatblokkok (data blocks) másolatait tartalmazza. Minden felhasználó konkurensen hozzáfér.
A cache bufferjei két listát tartalmaznak:
1. A write list tartalmazza a piszkos (dirty) buffereket, melyekben a módosított, de a diszkre még nem kiírt adatok vannak.
2. Az LRU (Least Recently Used) list tartalmazza az üres buffereket, a pinned (éppen hozzáférés alatt álló) buffereket és az olyan piszkos buffereket, amelyeket még nem tettünk át a write listbe.
Egy bufferhez történő hozzáférést követően a buffert az LRU lista MRU végére mozgatjuk. Minél több buffert helyezünk folyamatosan az LRU lista MRU végére, annál gyorsabban öregednek a dirty bufferek, s kerülnek az LRU lista LRU végére.
Ha az adatbázisnak szüksége van egy konkrét adatra, akkor először a buffer cacheben kezdi el keresni. Ha megtalálja az adatot a cacheben (cache hit), akkor közvetlenül a memóriából be tudja olvasni. Ha nincs bent az adat a cacheben (cache miss), akkor először be kell olvasni a merevlemezről az adatblokkot a memóriába, s csak utána lehet hozzáférni. Ebből következik az LRU lista előnye, hogy a gyakran használt adatokat bent tartja a memóriában, s ezáltal hozzájuk sokkal gyorsabb hozzáférést biztosít.
Az adatblokk cachebe történő beolvasásához először keresni kell egy üres (free) buffert az LRU listában. A keresést a lista LRU végéről kezdi. Ha keresés közben piszkos buffert találunk, akkor azt a buffert áthelyezzük a write listába, majd folytatjuk a keresést. Ha találtunk egy üres (free) buffert, akkor beolvassuk oda az adatblokkot, s a buffert az LRU lista MRU végére mozgatjuk. Ha elértük a keresési limitet, s nem sikerült üres (free) buffert találni, akkor leállítjuk a keresést, és jelzünk a DBW0 háttérfolyamatnak, hogy írjon ki néhány piszkos buffert a merevlemezre.
Full table scan esetén – mivel a beolvasott adatok általában csak rövid ideig kellenek – az adatokkal feltöltött buffereket az LRU lista LRU végére tesszük (a hagyományos adatbeolvasásnál ugyebár a lista MRU végére pakoljuk a buffereket, hogy ne egyből őket dobjuk majd ki). Ha a buffereket mégis a lista MRU végére szeretnénk pakolni, akkor a CREATE/ALTER parancs CACHE klózával tudjuk ezt megadni.

Redo Log Buffer: itt tároljuk az adatbázison végrehajtott változtatásokat. Egy körkörös, fix méretű buffer, melynek merevlemezre írását az LGWR processz végzi. A Redo bejegyzések az adatbázis esetleges helyreállításához szükségesek. Mivel minden INSERT, UPDATE, DELETE, CREATE, ALTER és DROP művelet által végrehajtott módosítást tartalmaznak, így remélhetőleg könnyedén vissza tudunk állítani egy korábbi, konzisztens állapotot.

Shared Pool: a Shared Pool három cache területből áll:

1. Library Cache: tartalmazza a megosztott (shared) és privát (private – csak shared server konfiguráció esetén) SQL területeket (areas), PL/SQL eljárásokat és csomagokat, valamint vezérlési struktúrákat.
A shared(/private) SQL areak tartalmazzák a futtatott és éppen futás alatt álló SQL utasítások elemzési fáját és végrehajtási tervét. Az Oracle adatbázis automatikusan felismeri, hogyha két felhasználó ugyanazt az SQL utasítást futtatja, ezáltal sokfelhasználós rendszerek esetén, amikor egy utasítást gyakran és sokszor futtatnak le a felhasználók, jelentős memóriát takaríthatunk meg, mivel elegendő az utasítás elemzési fáját és végrehajtási tervét csak egy példányban tárolnunk, s ahhoz minden felhasználó egyaránt hozzáfér. A shared pool memóriájának menedzselésére szintén az LRU algoritmust használjuk (részletesebben lásd „Buffer Cache” vagy „Kapcsolódó Linkek”).
PL/SQL programok kezelése majdnem teljesen hasonlóan történik a sima SQL utasításokéhoz. A lefordított programnak ugyanúgy foglalunk helyet a shared SQL areaban, de a session specifikus változókat a private SQL areaban tároljuk.
Néhány, az alap LRU algoritmustól eltérő esetben is kiteszünk egy shared SQL areat a Shared Poolból. Ezek:

• Az ANALYZE statisztikagyűjtő utasítás használata esetén minden olyan shared SQL areat kidobunk a shared poolból, ami tartalmaz hivatkozást az analizált séma objektumra.


• Ha egy SQL utasítás által hivatkozott objektum az utasítás shared poolba kerülését követően módosul, akkor az utasítás shared SQL areajá invaliddá válik, s az utasítást újra le kell fordítani a következő futtatása előtt.


• Ha az adatbázis globális nevét megváltoztatjuk, minden információt kiürít az adatbázis a shared poolból.


• Az ALTER SYSTEM FLUSH SHARED_POOL utasítással az adminisztrátor manuálisan kiürítheti az egész shared poolt. Ezzel az adatbázis újraindítása nélkül tud a shared pool adatbázispéldány indítása utáni teljesítményéről információkat gyűjteni.

2. Dictionary Cache: az adatszótár (data dictionary) cacheelésére szolgál. Két részből áll: a data dictionary cache (másik nevén row cache) az adatokat sorok (rows) formájában, s nem blokkokban (bufferekben) tárolja. A másik rész, a library cache buffereket használ.

3. Result Cache: a SQL query result cacheből és a PL/SQL query cacheből áll, melyekben a lekérdezések/függvények eredményét cacheeljük. A DBMS_RESULT_CACHE csomag, illetve a V$RESULT_CACHE_* nézetek segíthetnek az adminisztrátornak a karbantartásában. A RESULT_CACHE_MODE-ban állíthatjuk be, hogy minden SQL lekérdezés eredményét szeretnénk-e cacheelni, vagy csak bizonyos megjelölt lekérdezéseket. Természetesen, ha egy tranzakció egy olyan objektum bármely adatát vagy metaadatát módosítja, amit a lekérdezés eredményének kiszámításához használtunk, akkor a cacheelt eredmény azonnal invaliddá válik.

Large Pool: az adatbázis adminisztrátor által konfigurálható opcionális memóriaterület, mely a következők számára biztosít extra, nagyméretű memóriát:

• session memória az osztott szervernek és az Oracle XA interfésznek (több adatbázissal kommunikáló tranzakciók használják), hogy ne a shared SQL cachet pakolják tele


• I/O szerver processzek


• Oracle adatbázis biztonsági mentési és visszaállítási műveletei

Ellentétben a Shared Pool–lal, a Large Pool nem használ LRU listákat.

Java Pool: a session-specifikus Java kódok és adatok használják. A Java Pool Advisor segítségével statisztikát gyűjthetünk, amely segítségével információt kapunk arról, hogy hogyan változtassuk a Java Pool méretét a hatékonyabb működés érdekében. Az Advisor a statistics_level legalább TYPICAL–ra állításával van bekapcsolva.

Streams Pool: az Oracle Folyamok (Streams) használják. Mérete nulláról indul, és dinamikusan növekszik, amikor a Folyamoknak szüksége van memóriára.


Program Global Area (PGA):
Az Oracle adatbázis minden szerverfolyamat számára automatikusan lefoglal egy PGA-t. SQL utasítások végrehajtására, illetve session-specifikus (pl. bejelentkezési) információk tárolására használják. Két részből áll:

Session Memória: session specifikus információkat tárol. Shared szerver konfiguráció esetén megosztottan működik, amúgy privát.

Privát SQL terület (Private SQL Area): bind variable értékeket, lekérdezések végrehajtásának állapotinformációit és munkaterületeit tartalmazza. Minden sessionhöz tartozik egy külön privát SQL terület, így ha két felhasználó ugyanazt a lekérdezést futtatja, mindegyiknek külön privát SQL területük van, de egy osztott SQL területet használnak. A privát SQL területek elhelyezkedése kapcsolatfüggő. Ha dedikált szerveren keresztül csatlakozunk, akkor a szerverfolyamat PGA-jában kap helyet. Azonban ha osztott szerveren keresztül kapcsolódunk, akkor a privát SQL terület egy része az SGA-ban tárolódik.
Implicit kurzorok számára osztott SQL területeket használ az adatbázis, de az explicit kurzoroknak külön privát SQL területet foglal le. Az OPEN_CURSORS inicializálási paraméterben adhatjuk meg, hogy egy felhasználói processz maximum hány privát SQL területet foglalhat le magának. A paraméter alapértéke 50.
Memóriafoglalás alapján a különbségek dedikált és osztott szerver esetén: táblázat


Memóriakezelési eljárások (Memory Management Methods - táblázat): inicializálási paraméterben adható meg. Az Oracle az automatic management method-t ajánlja. Instance PGA = az adatbázispéldányhoz tartozó összes egyedi PGA-k halmaza.

• Automatic Memory Management – SGA & Instance PGA: 11g újdonság. Csak a teljes memóriaterületet kell megadnunk, s onnantól az Oracle adatbázis mindent automatikusan elvégez. Dinamikusan elosztja a memóriát az SGA és az Instance PGA között, valamint külön-külön az egyes SGA komponensek és egyedi PGA-k méretét is meghatározza.


• Automatic Shared Memory Management – SGA: az Automatic Memory Managementtel szemben ebben az üzemmódban meg tudjuk adni az SGA célzott és maximális méretét. Ebben az esetben a rendszer megpróbálja az SGA méretét a célméreten tartani, és dinamikusan állítja az egyes SGA komponensek méretét.


• Manual Shared Memory Management - SGA: ebben az üzemmódban nem csak az SGA méretét állíthatjuk be, hanem szabályozhatjuk az egyes SGA komponensek rendelkezésére álló memóriát is.


• Automatic PGA Memory Management – Instance PGA: Az Automatic Memory Management kikapcsolásával, s az Automatic Shared Memory Management vagy a Manual Shared Memory Management bekapcsolásával implicit bekapcsoljuk ezt az üzemmódot is. Beállíthatjuk az Instance PGA célzott méretét, és az egyedi PGA-k méretet a rendszer dinamikusan szabályozza majd. Ha nem adunk meg célzott méretet, akkor az adatbázis automatikus kiszámol és beállít egy értelmes alapértéket.


• Manual PGA Memory Management – Instance PGA: az Oracle adatbázis korábbi verzióiban a DBA-nak manuálisan kellett definiálnia a maximális munkaterületet (work area) minden SQL operátor számára, ez azonban nagyon körülményes és nehéz feladat, hiszen a munkaterület mérete állandóan változik. Az Oracle erősen ajánlja, hogy ne használjuk ezt az üzemmódot!

Ha az adatbázist a Database Configuration Assistant (DBCA) segítségével hozzuk létre, akkor „basic” installálási opciót választva automatic memory management lesz beállítva. „Advanced” installálást választva az alábbi három konfiguráció közül választhatunk:
1. automatic memory management
2. automatic shared memory management + automatic PGA memory management
3. manual shared memory management + automatic PGA memory management
Ha kézzel, a CREATE DATABASE SQL paranccsal akarunk adatbázist létrehozni, akkor a 3. konfiguráció az alapértelmezett.


Szoftver kód területek (Software Code Areas):
Olyan memóriaterületek, amiket az Oracle adatbázis futó vagy futtatható kódjainak tárolására használunk. Általában statikus méretű, csak szoftverfrissítéskor vagy újratelepítéskor változik. Az igényelt terület mérete operációs rendszertől függ. Csak olvasható, megosztottan (shared) és nem megosztottan (nonshared) installálhatjuk. Ajánlott az előbbit használni, mivel így a felhasználóknak nem kell többszörös másolatokat a memóriában tartaniuk, ami amúgy az általános teljesítményt rontaná.


Kapcsolódó Link
Oracle® Database Concepts – Memory Architecture
http://en.wikipedia.org/wiki/Cache_algorithms

Blog szépítgetése

Kicsit kipofoztam a blogot. Az alábbi módosítások történtek:

• tettem fel képet, hogy nagyjából beazonosítható legyek előben is
• jobb oldali sávba kitettem a többi magyar Oracle blogger oldalára mutató linkeket (forrásként Éberhardt Peti oldalát használtam)
• kikerült egy Hírek oldalelem is, ami a Google News között Oracle kulcsszóra keres
• az alsó sávba elrejtettem egy hirdetést, melynek fő célja, hogy legyenek statisztikáim az oldalról
• lényegretörőbbé tettem a bemutatkozás részt
  
• html kódot szerkesztgettem, amennyire engedte magát, illetve egyéb menüből elérhető apróbb változtatásokat eszközöltem
  

Architektúra part #6 – Adatszótár

Az adatszótár (data dictionary) az Oracle adatbázis egyik legfontosabb részét képezi. A központi, csak olvasható referencia táblák és nézetek tartoznak hozzá, melyekben az adatbázisról tároljuk a következő lényeges információkat:

1. séma objektumok definíciója


2. séma objektumok számára allokált és felhasznált területek


3. oszlopok alapértelmezett értékei


4. integritás kényszerekről információk


5. az adatbázis felhasználóinak nevei


6. az egyes felhasználókhoz tartozó jogok és szerepek


7. naplózási információk


8. egyéb általános adatbázis információk

A SYSTEM tablespaceben tároljuk, ami mindig online, ezért ezek az információk mindig elérhetőek. Szerkezetileg kétféle objektumot tartalmaz:
1. Alap táblák (Base tables): az adatbázisról tartalmaznak információkat. Csak az Oracle adatbázis írhatja és olvashatja őket. Az adatokat titkosított formában tárolják.
2. Felhasználói nézetek (User-Accessible Views): nézetek, melyek összegzik és a felhasználók számára emészthető formában megjelenítik az Alap táblákban tárolt információkat. A legtöbb felhasználó ezekhez a nézetekhez férhet hozzá.

Minden Base table és User-Accessible View a SYS felhasználó sémájában van, így egyetlen felhasználó sem módosíthatja őket, mivel az súlyos veszélyeket jelentene az adatintegritásra. Éppen ezért célszerű nagy biztonságban tartani ezt a központi accountot!

Felhasználás: az adatszótár használatának három fő területe van:

1. az adatbázis lekérdez információkat felhasználókról, séma objektumokról és tárolási struktúrákról


2. az adatbázis módosítja az adatszótárt minden DDL utasítás végrehajtása esetén


3. bármely felhasználó lekérdezhet információkat az adatbázisról

Az adatbázis a legtöbb nézethez létrehoz Publikus Szinonimákat, hogy azok kényelmesen elérhetőek legyenek, de a SYS felhasználóval további publikus szinonimákat is létre lehet hozni manuális. Fontos, hogy a séma objektumok elnevezései lehetőleg ne keveredjenek a publikus szinonimák nevével.
Az adatszótár lehetőleg minél nagyobb részét az SGA (System Global Area) dictionary cache részében tároljuk a gyors hozzáférés érdekében. Nyilván az egész adatszótárt nehéz lenne cacheelni, ezért a least recently used (LRU) algoritmus alapján a legrégebben használt adatokat dobjuk ki először.
Más Oracle adatbázis termékek is hivatkozhatnak, illetve létrehozhatnak objektumokat maguknak az adatszótárban. Célszerű az alkalmazásfejlesztőknek a hivatkozásoknál a publikus szinonimákat használni, mivel azok a legtöbb verzióban azonosak.

Az adatszótár nézetei általában három különböző prefixszel vannak ellátva, melyek jelentése:

1. USER: felhasználói nézet - a felhasználó sémájában lévő nézet: főként az adott felhasználóhoz tartozó információkat tartalmazzák. Így például a
   SELECT object_name, object_type FROM USER_OBJECTS;
   lekérdezés a sémánkban lévő objektumokat adja vissza.


2. ALL: kiterjesztett felhasználói nézet - a felhasználó által hozzáférhető nézet: az adott felhasználó által elérhető „információkat” tartalmazzák. Így például a
   SELECT owner, object_name, object_type FROM ALL_OBJECTS;
   lekérdezés az általunk hozzáférhető objektumát adja vissza.


3. DBA: adatbázis adminisztrátori nézet – minden felhasználó sémájában megtalálható nézet: globális információkat tartalmaznak az adatbázisról. Így például a
   SELECT owner, object_name, object_type FROM SYS.DBA_OBJECTS;
   az adatbázis összes objektumat adja vissza.
   Az „O7_DICTIONARY_ACCESSIBILITY is false” beállítással a felhasználóknak megtilthatjuk a SYS sémán belüli objektumokhoz való hozzáférésüket.

Dinamikus Teljesítmény táblák (Dynamic Performance Tables): virtuális táblák halmaza, melyek az adatbázis tevékenységeket rögzítik. Nem valós táblák, de az adminisztrátor létrehozhat rájuk nézeteket a felhasználók számára. Ezeket a nézeteket fix nézeteknek hívjak, mivel az adminisztrátor nem tudja módosítani vagy törölni őket.
A SYS felhasználóhoz tartoznak, s V_$ karakterekkel kezdődik a nevük. Ezekre a táblákra hozhatunk létre nézetek, majd a nézetekre publikus szinonimákat, melyek neve V$ karakterekkel kezdődik. Pl. V$DATAFILE tartalmaz információkat az adatbázis adatfájljairól, míg V$FIXED_TABLE magukról a dinamikus teljesítmény táblákról.


Kapcsolódó Link
Oracle® Database Concepts – The Data Dictionary

Architektúra part #5 – Séma objektum függőségek

Vegyünk két objektumok, és nevezzük őket A-nek és B-nek. Ha A objektum a definíciójában hivatkozik B objektumra, akkor azt mondjuk, hogy A függ B-től. Ez a fejezet a séma objektumok között létrehozható függőségeket, illetve azt taglalja, hogy ezeket a függőségeket az Oracle adatbázis miként követi nyomon és menedzseli automatikusan.

Általánosságban: egy objektum a definíciójában hivatkozhat egy másik objektumra. Például egy nézet hivatkozik a master tábláira és/vagy nézeteire, illetve egy esetleges alprogram törzsében más objektumokra is. Ha módosítunk egy hivatkozott objektumot, akkor a tőle függőségben lévő objektumok esetlegesen nem fognak működni – ez nyilván csak akkor fordul elő, ha a hivatkozott objektum olyan attribútumát változtatjuk meg, amire a tőle függőségben lévő objektum hivatkozik.
A DBA_DEPENDENCIES, USER_DEPENDENCIES és ALL_DEPENDENCIES táblák írják le az adatbázis objektumai között fennálló függőségeket.

Állapotok: a séma objektumok az alábbi állapotok valamelyikében lehetnek:

1. VALID: sikeresen lefordult az adatszótárban (data dictionary) található aktuális definíció alapján.


2. Compiled with Errors: legutóbbi fordítási kísérlet során hiba lépett fel.


3. INVALID: egy hivatkozott objektum megváltozott (csak a függőségben lévő objektum tud INVALID állapotba kerülni, a hivatkozott nem).


4. UNAUTHORIZED: egy hivatkozott objektumról visszavonták (REVOKE) a hozzáférési jogosultságát a hivatkozó objektumnak (csak a függőségben lévő objektum tud UNAUTHORIZED állapotba kerülni, a hivatkozott nem).

INVALID állapotba kerülés okai: megkülönböztethetünk közvetlen (direct) és közvetett (indirect) függéseket az alapján, hogy A objektum a közvetlenül hivatkozott B objektumtól is függhet, illetve közvetetten a B objektum által hivatkozott C objektumtól is. A objektum mind a B, mind a C objektum megváltoztatása esetén INVALID állapotba kerülhet. A műveletekről, melyek hatással lehetnek egy objektum állapotára itt található egy összefoglaló táblázat.

INVALID állapotba jutás elkerülése:

1. az új elemeket a csomag végére illesszük be, hogy az többi objektumra történő hivatkozások ne invalidálódjanak. Pl.: assert_var beillesztésével a set_var-ra hivatkozó objektumok invalidálódnak.
   

   
   CREATE OR REPLACE PACKAGE pkg1 IS
      FUNCTION get_var RETURN VARCHAR2;
      PROCEDURE assert_var (v VARCHAR2);
      PROCEDURE set_var (v VARCHAR2);
   END;




2. a táblákra indirekt, nézeteken keresztül hivatkozzunk. Ezzel azt érjük el, hogy a táblába új sor felvételekor, illetve nem hivatkozott oszlopok módosításakor vagy törlésekor a függőségben lévő objektumok nem válnak INVALID-dá.

Objektumok „ReVALID”-álása: egy objektum nem VALID (azaz nem érvényes/hivatkozható), ha a három másik állapot (Compiled with Errors, UNAUTHORIZED, INVALID) valamelyikében tartózkodik. Ha egy nem VALID objektumra hivatkozás történik, akkor a használat előtt ReVALID-álni kell, különben nem lehet majd használni. Ez a ReVALID-álási kísérlet automatikusan végbemegy.

1. Compiled with Errors objektum revalidálása: a fordító automatikusan nem tudja revalidálni az objektumot. Megpróbálja újrafordítani azt. Ha sikerül VALID állapotba kerül, egyébként marad Compiled with Errors.


2. UNAUTHORIZED objektum revalidálása: a fordító ellenőrzi a hozzáférési jogokat. Ha időközben megkaptuk őket, akkor VALID állapotra vált, egyébként hibaüzenetet ír ki.


3. INVALID SQL objektum revalidálása: lásd Compiled with Errors revalidálás.


4. INVALID PL/SQL objektum revalidálása: a PL/SQL fordító megnézi, hogy a hivatkozott objektumokban történt-e az INVALID objektumot érintő változás. Ha igen, akkor a fordító újrafordítja az INVALID objektumot, s siker esetén VALID állapotba helyezi. Ha nem történt az INVALID objektumot érintő változás, akkor újrafordítás nélkül próbálja meg a fordító revalidálni az objektumot (lásd fast revalidálás).


5. INVALID PL/SQL objektum „fast” revalidálása: a fordító újrafordítás nélkül revalidálja az objektumot. Főként indirect függőségből származó invalidálódás esetén szokott sikerrel járni.

Remote Procedure Call (RPC) Függőség Menedzsment: elosztott adatbázis esetén fordul elő, amikor egy helyi eljárás távoli eljáráshívást hajt végre.

1. Időbélyeg ellenőrzés: az eljárások létrehozásakor, módosításkor és felülírásukkor mindig feljegyezzük a műveletek időbélyegét az adatszótárba (data dictionary). Ha egy olyan eljárást hívunk meg, amit tartalmaz távoli eljáráshívást is, akkor az adatbázis összehasonítja a fordítás időbélyegét a távoli eljárás éppen aktuális időbélyegével. A következő két eset fordulhat elő:
   1. a helyi és a távoli eljárás időbélyegei egyeznek, az eljárás gond nélkül lefut.
   2. ha a távoli eljárás bármely időbélyege nem egyezik, a helyi eljárás invalidálódik, s nem hibaüzenettel tér vissza az eljáráshívás. Továbbá invalidálódik az összes többi, arra a távoli eljárásra hivatkozó helyi eljárásunk is. Célszerű tehát a hálózaton keresztül hivatkozott objektumokat ritkán újrafordítani, hogy jelentős teljesítménycsökkenést tudnak okozni!


2. Aláírás ellenőrzés: a távoli függőségekre egy alternatív lehetőséget jelentenek az RPC aláírások. Egy eljárás aláírása tartalmazza a nevét (csomag, eljárás vagy függvény neve), a paraméterek típusát, üzemmódját (IN­/OUT/IN OUT) és számát, illetve függvény esetén a visszatérési érték típusát. Az aláírások használata enyhít néhány, az időbélyeg alapú modell esetén jelentkező problémát, melyek kritikusak lehetnek a teljesítményre nézve (pl. újrafordított távoli eljárás esetén, ha az aláírás nem változott, akkor gond nélkül lefut a helyi eljárásunk). Az aláírás adattípusok (ábra) közötti váltáskor következik be (az adattípus osztályán belüli váltáskor nem).


3. Vezérlés: a fenti két módot a REMOTE_DEPENDENCIES_MODE inicializáló paraméter segítségével állíthatjuk be (= {SIGNATURE | TIMESTAMP})

Kapcsolódó Link
Oracle® Database Concepts – Schema Object Dependencies

Architektúra part #4 – Séma objektumok (2/2)

Dimenziók (Dimensions):
A dimenziók hierarchikus (gyermek/szülő) viszonyt határoznak meg oszloppárok vagy oszlophalmazok között. Minden gyermek pontosan egy szülőhöz van társítva. Mivel a dimenzió csak logikai kapcsolatok gyűjteménye, nincs tárolási terület hozzárendelve. A dimenziót létrehozó CREATE DIMENSION parancs meghatározza a hierarchia szinteket (LEVEL), a köztük lévő viszonyt (HIERARCHY), illetve opcionálisan az ATTRIBUTE ágban kiegészítő oszlopot vagy oszlop halmazt az adott szinthez. Az oszlopok származhatnak egy táblából (denormalized) vagy több táblából (normalized). Utóbbi esetén illesztést kell alkalmazni a HIERARCHY ágban.

Szekvencia Generátor (Sequence Generator):
A szekvencia generátor segítségével számok szekvenciális sorozatát állíthatjuk elő (pl. egyedi elsődleges kulcsoknak). Segítségével többfelhasználós rendszerek esetén elkerülhetünk felesleges zárolásokat (pl. egyszerre két felhasználó is tud adatokat bevinni egy táblába). Méretük maximum 38 számjegy lehet, definíciójukat az adatszótárban (data dictionary) tároljuk. A számok generálása független az egyes tábláktól, így egy szekvencia generátort akár több táblánál is használhatunk.

Szinonimák (Synonyms):
A szinonima egy alternatív név bármely táblára, nézetre, materializált nézetre, szekvenciára, eljárásra, függvényre, csomagra, típusra, Java osztályra, felhasználó által definiált objektum-típusra vagy egy másik szinonimára. Mivel adatot a szinonima sem tárol, így számára sem szükséges területeket lefoglalni…a definícióját az adatszótárban (data dictionary) tároljuk. Használatának két fő célja a biztonság és a kényelem, valamint az, hogyha a master táblájának megváltozik a neve, akkor csak magát a szinonimát kell átírni, s utána a szinonimát használó alkalmazások probléma nélkül futnak majd. A szinonima lehet public vagy private. Előbbi minden felhasználó számára elérhető, míg utóbbi egy bizonyos felhasználó sémájában található, s mások számára a hozzáférhetőséget ő határozhatja meg.

Indexek (Indexes):
Az indexek opcionális, táblákhoz és klaszterekhez rendelhető struktúrák. Indexeket lehet egy vagy több oszlophoz rendelni, melyek segítségével egy SQL utasítás esetén gyorsabban megtalálja a keresett információt az adatbázis – ezáltal a helyesen használt indexek jelentik az I/O műveletek csökkentésének fő forrását. A következő index-sémák használhatóak: B-fa index, B-fa klaszter index, Hash klaszter index, Reverse key (inverz kulcs) index, Bitmap index, Bitmap join index. Az indexek használata automatikus, csak a létrehozásukkal és az esetleges törlésükkel kell foglalkozni. Továbbá az optimalizáló (optimizer) akár felhasználhat egy már létező indexet egy új index létrehozására, ami jóval gyorsabb index-építést eredményezhet.
Unique/Nonunique: az egyedi (unique) indexek garantálják, hogy a hivatkozott oszlopban nem szerepelhet duplikált érték. Ajánlott ezt explicit megadni mindig a CREATE UNIQUE INDEX használatával, ugyanis nem garantált, hogy egy primary key vagy unique constraint automatikusan létrehoz egy új indexet, s ha létre is hozott, arra sincs garancia, hogy az az index unique lesz.
Visible/Invisible: a láthatatlan (invisible) indexeket csak a DML műveletek kezelik, s nem használhatja őket az optimalizáló (optimizer).
Összetett indexek (Composite/Concatenated Indexes): több oszlopra definiált indexek. Az oszlopok megadásának sorrendjét nem befolyásolja az, hogy az adott oszlopok milyen sorrendben szerepelnek a táblában, azonban maga a sorrend nagyon is fontos. Célszerű a gyakran hivatkozott oszlopokat a sorrendben előre helyezni. Összetett indexekkel lényeges javulást akkor tudunk elérni, ha sikerül olyan oszlopokat találni, melyek (mind, vagy legalább nagyobb részük) gyakran szerepel(nek) egyszerre a WHERE feltételében. Maximum 32 (bitmap indexek esetén 30) oszlopot adhatunk meg.
Indexek és kulcsok (Keys): két különböző dologról van szó. Az indexek az adatbázisban tárolt, felhasználók által létrehozott struktúrák, melyek célja az adatok elérésének meggyorsítása. A kulcsok azonban szigorúan csak logikailag léteznek, s az integritás kényszerekért felelnek.
NULL értékek: különböző értékként vannak számon tartva, kivéve, hogyha az index legalább két sorában lévő nem NULL érték azonos. Tehát az UNIQUE indexekkel – mivel ott minden nem NULL érték különböző – lehet biztosítani, hogy a NULL értéket tartalmazó sorok is különbözőként legyenek kezelve (kivétel, ha minden érték NULL).
Függvény-alapú indexek (Function-Based Indexes): létrehozhatunk indexeket olyan függvényekre és kifejezésekre is, melyek tartalmaznak legalább egy oszlopot egy indexelt táblából. Ezek a függvény-alapú indexek kiszámolják a függvény vagy kifejezés értékét, s azt tárolják az indexben. Típusát tekintve B-fa vagy bitmap indexek lehetnek. A függvény maga lehet aritmetikai kifejezés, vagy olyan kifejezés, ami tartalmaz PL/SQL függvényt, csomag függvényt, C hívást vagy SQL függvényt. Nem tartalmazhat azonban aggregátum függvényeket, DETERMINISTIC-usnak kell lennie, s nem vonatkozhat LOB típusú, REF vagy beágyazott tábla oszlopára sem.
1. Használat: példák

1. lekérdezések WHERE ágában szereplő feltételek kiszámításának gyorsítására:
   CREATE INDEX idx ON table_1 (a + b * (c - 1), a, b);
   SELECT a FROM table_1 WHERE a + b * (c - 1) <>
   
2. case-insensitive keresések gyorsítása:
   CREATE INDEX uppercase_idx ON employees (UPPER(first_name));
   SELECT * FROM employees WHERE UPPER(first_name) = 'RICHARD';

2. Optimalizálás: az optimalizálónak (optimizer) szüksége van statisztikákra ahhoz, hogy használni tudja a függvény-alapú indexeket. Az optimalizáló a kifejezésfák alapján választ egy SQL utasításhoz hozza illeszkedő függvény-alapú indexet. Nyilván minél kevesebb variáció lehetséges a WHERE klóz alapján, annál hatékonyabb lesz ez a keresés.

Tárolás: az index létrehozását követően az adatbázis automatikusan lefoglal neki egy index szegmenst. A lefoglalt szegmens mérete a tábláknál már ismertetett módon történik. Azaz vagy tárolási paraméterek (storage parameteres) megadásával, vagy a PCTFREE és a PCTUSED paraméterekkel állíthatjuk be. Az index számára a létrehozásakor megadhatunk egy – az ownerjétől különböző - tablespacet is a tárolásra. Ezen túl, ha az indexet még egy külön, a tábláétól különböző diszkre is tesszük, akkor mivel az adatbázis a két diszket párhuzamosan tudja használni, teljesítménynövekedést érhetünk el.
Blokk formátuma: az index létrehozását követően az adatbázis fetcheli és rendezi az indexelt oszlopokat, s eltárolja a rowid-ket minden egyes sor index értékéhez.
Belső struktúra: az Oracle adatbázis B-fákat (ábra) használ az indexek tárolására. Ezáltal a szekvenciális keresés átlagos n/2 idejét lecsökkenti O(log(n))–re.
Unique Scan: az egyik leghatékonyabb adathozzáférési módszer. Az optimalizáló (optimizer) ezt a módszert használja unique index esetén.
Range Scan: kevésbé hatékony adathozzáférési módszer. Az adatot az index oszlopok szerinti növekvő sorrendben adja vissza, duplikált sorok esetén ROWID szerinti növekvő sorrendben.
Kulcstömörítés: lehetővé teszi, hogy az elsődleges kulcs (primary key) értékek csoportjait egy indexbe vagy egy index-szervezett táblába tömörítsük, csökkentve ezáltal az ismételt értékekből származó tárolási overheadet. Általában egy index egy csoportazonosító és egy egyedi részre bontható. A tömörítést a csoport részre végezzük: megadjuk, hogy az index milyen hosszú részét képezi, majd az ezáltal lehetséges csoportazonosítókat csak egyszer tárolunk el.

· Teljesítmény: a kulcstömörítés jelentős helymegtakarítást jelenthet, ezáltal csökkentve az I/O műveleteket és növelve a teljesítményt, azonban a kulcsok újbóli felépítése némi CPU overheadet jelenthet az indexek scanelése közben.
· Használat: az alábbi esetekben célszerű kulcstömörítést használni:

1. nonunique reguláris indexeknél, ugyanis az Oracle adatbázis a duplikált sorokhoz duplikált keyeket használ.


2. olyan unique indexek esetén, ahol a kulcs egyediségét nem az első attribútum generálja. Pl.: egy elemre és az elemhez történt hozzáférések időbélyegére definiáltunk indexet. Ekkor a csoport rész (prefix) lehet az elem, az egyediséget pedig (suffix rész) az időbélyeg fogja garantálni.


3. VARRAY vagy NESTED TABLE –t tartalmazó index-szervezett tábláknál, mivel az objektumazonosító ismételt a kollekciók minden elemére.

Reverse key (inverz kulcs) indexek: a hagyományos indexekkel ellentétben megfordítják minden indexelt oszlop bájtjait (a ROWID kivételével), míg az oszlopsorrendet változatlanul hagyják. Ezáltal kizárjuk az indexen az index range scanning lekérdezéseket, de cserébe RAC-os alkalmazások futását meggyorsíthatjuk, mivel a beillesztés elosztottan mehet végbe az index levelei között.
Bitmap indexek: az Oracle adatbázis által használt B-fa indexeknél a kulcsértéket minden egyes ROWIDhez eltároljuk, így ismétlődés fordulhat elő. Bitmap indexek esetén minden kulcsértékhez egy bitmapet használunk. A bitmap minden egyes bitje egy lehetséges ROWID-t reprezentál, s akkor van beállítva, hogyha a hozzá tartozó ROWID tartalmazza a kulcsértéket.
Kevés különböző kulcsérték esetén a bitmap indexek használata (B-fa indexek helyett) jelentős helymegtakarítást jelent – alkalmazásának adattárházak (Data Warehouses) esetén van számos előnye. Lekérdezések hatékonyságának gyorsítására főként abban az esetben alkalmas, ha a WHERE feltételében ekvivalencia vizsgálatok (illetve azok AND, OR és NOT operátoros kombinációi) szerepelnek.
A legtöbb indexszel ellentétben NULL értéket tartalmazó sorokat is képes felhasználni, ami hasznos lehet a COUNT aggregátum használata esetén.
Bitmap Join indexek: több illesztett táblára is létrehozhatunk bitmap (join) indexet, ami tárolási szempontból jóval előnyösebb a materializált join nézeteknél (mivel ők nem tömörítik a hivatkozott táblák ROWID-jét).

Index-szervezett (Index-Organized) táblák:
A hagyományos táblákkal ellentétben – ahol az adatok rendezetlenül, kupacban (heap) tárolódnak -, az index-szervezett táblák adatait egy elsődleges kulcs szerint rendezett B-fában tároljuk. Ezáltal nem kell külön indexet létrehozni és fenntartani az elsődleges kulcsra (Összehasonlítás).
Előnyök:

1. gyorsabb hozzáférés a tábla soraihoz


2. mivel a többi, nem kulcs értékű információ is megtalálható a fában, nincs szükség további blokkhozzáférésre


3. az elsődleges kulcs szerinti sorrendhelyes tárolás miatt minimális blokkhozzáférésre van szükség


4. a ritkán használt nem kulcs típusú oszlopokat ki lehet pakolni egy külön kupacba, ezáltal csökkentve a B-fa méretét


5. nem kell az elsődleges kulcsra külön indexet fenntartani (kevesebb tárhely igény)


6. a sorrendhelyes kulcstárolás miatt kulcstömörítés alkalmazható

Overflow: mivel az index-szervezett táblákban esetlegesen nagyon sok nem kulcs típusú oszlopot is tárolhatunk, az egyes levelek mérete igencsak megnőhet, s ezáltal elveszítheti a B-fa sűrűn fürtözött tulajdonságát. Ennek elkerülése végett az OVERFLOW klózzal két részre oszthatjuk az oszlopokat: az első részbe tartoznak az index bejegyzések és fizikai ROWID-k, valamint megadhatunk néhány nem kulcs típusú oszlopot, amit szeretnénk a B-fában tartani. A második részbe (overflow rész) kerül a többi nem kulcs típusú oszlop, melyeket külön tárolunk.
Másodlagos indexek: index-szervezett tábláknál is van lehetőség nem kulcs típusú oszlopokra indexeket létrehozni (ún. másodlagos/secondary indexek). Ezek működése azonban általában lassabb a hagyományos táblákra létrehozott indexekénél (azonos működés érhető el, ha helyes sejtésünk van az adat fizikai elhelyezkedéséről).
UROWID: az index-szervezett táblák sorainak azonosítására használható, logikai elsődleges kulcs alapú ROWID-k.
Alkalmazások: az elsődleges kulcs alapú lekérdezéseket használó, valamint a tárhellyel takarékoskodni akaró alkalmazások számára ideális. Pl.: OLTP (Online Transaction Processing), Internet (kereső motorok és portálok), Elektronikus kereskedelem, Adattárházak (Data Warehouses), Analitikus függvények.

Alkalmazás Domain Indexek (Application Domain Indexes):
Az Oracle adatbázis indexelése kiterjeszthető komplex adattípusokra - mint pl. dokumentumok, spatial adatok, képek, videók, stb. – is. Ezeket az indexeket hívjuk domain indexeknek, melyeket a Cartridge szoftverrel lehet szabályozni.

Klaszterek (Clusters):
Klaszternek nevezzük táblák egy csoportját, melyek – mivel közös oszlopokat használnak – ugyanazon az adatblokkokon osztoznak (példa).
Előnyei:

1. kevesebb I/O művelet az egy klaszteren belül lévő illesztett táblákra


2. gyorsabb hozzáférés az egy klaszteren belül lévő illesztett táblákra


3. klaszter kulcsértékek (és indexek) csak egyszer tárolódnak, ezáltal kevesebb tárhelyet fogyasztanak.

Hash klaszterek (Hash Clusters):
A hash klaszterek bizonyos értelemben megfelelnek a klaszterekre definiált hagyományos indexekkel, azzal a különbséggel, hogy a kulcs hash értékét tárolják. Jobb teljesítményt lehet velük elérni olyan tábláknál, melyen gyakran alkalmaznak ekvivalencia vizsgálatos feltételt tartalmazó lekérdezéseket, mivel a hash kulcs közvetlenül a diszken lévő adatra mutat.


Kapcsolódó Link
Oracle® Database Concepts – Schema Objects

Architektúra part #4 – Séma objektumok (1/2)

Sémának (Schema) nevezzük az egy felhasználóhoz tartozó logikai adatstruktúrák (séma objektumok) összességét. Ezek az objektumok nem feleltethetőek meg egy az egyben fizikai diszken tárolt fájloknak. Logikailag egy objektum egy tablespacen belül helyezkedik el, fizikailag azonban tárolódhat akár több datafileban is. A sémák és tablespacek között nincs semmilyen összefüggés: egy tablespace tartalmazhat objektumokat több különböző sémából, illetve egy séma objektumai is tárolódhatnak különböző tablespacekben (ábra).

Az alábbi objektumok tartoznak a séma objektumok közé:
klaszterek; kényszerek; adatbázis hivatkozások; adatbázis triggerek; dimenziók; külső eljáráskönyvtárak; indexek és indextípusok; Java osztályok; materializált nézetek és a hozzájuk tartozó logok; objektum táblák, objektum típusok és objektum nézetek; operátorok; szekvenciák; tárolt függvények, eljárások és csomagok; szinonimák; táblák és indexelt táblák; nézetek.
Nem tartoznak séma alá a következő objektumok:
kontextusok; könyvtárak; paraméter fájlok (PFILEs) és szerver paraméter fájlok (SPFILEs); profilok; szerepek; rollback szegmensek; tablespacek; felhasználók.

Táblák (Tables):
A táblák jelentik az Oracle adatbázisban az alapvető adattárolási egységet. Alapvető tulajdonságainak részletes ismertetése itt.
Tárolása: a tábla létrehozásakor automatikusan lefoglalunk neki egy adatszegmenst a tablespacen belül. Ennek vezérlésére használhatjuk a már ismertetett PCTFREE és PCTUSED paramétereket, vagy beállíthatjuk az adatszegmens tárolási paramétereit. Klaszter használata esetén nincs lehetőség külön táblánként tárolási paramétereket állítani, hanem csak egységesen, az klaszter összes táblájára vonatkozóan állíthatjuk be őket.
Sorok formátuma és mérete: ha egy sor 256 oszlopnál kevesebbet tartalmaz, s adatai elférnek egy adatblokkban, akkor az adatbázis a sort egy adatblokkon belül, egy darabban tárolja. Azonban ha a sor adatai méretüknél fogva nem tehetőek be egy adatblokkba, vagy a sor legalább 256 oszlopból áll, akkor több adatblokkra van szükség a tároláshoz. Ezt láncolásnak nevezzük -- a további adatblokkok ROWID-jét a sor headerjében tároljuk (ábra).
ROWID: azonosítja az egyes sordarabokat helyük vagy címük alapján. Érdemes hivatkozni rájuk SQL utasításokban, hiszen értékük sosem változik meg.
Oszlopsorrend: tárolási szempontból általában megegyezik a tábla létrehozásakor megadott oszlopsorrenddel (kivétel pl. ha LONG típust használunk, ugyanis azt az adatbázis mindig utolsó oszlopként tárolja -- illetve újonnan felvett oszlopok is mindig hátra kerülnek), ezért célszerű a gyakran NULL értéket felvevő oszlopokat a sorrendben hátulra tenni, mivel így (ha nincs LONG típusunk deklarálva) jelentős mennyiségű helyet takaríthatunk meg.
Táblák tömörítése: az egy blokkon belül többször előforduló adatokat nem tároljuk el külön-külön többször, hanem csak egyszer a blokk elején (egy ún. szimbólum táblában), s a későbbi előfordulások alkalmával csak egy hivatkozást illesztünk be a szimbólum tábla megfelelő elemére. A tömörítés nem jelent semmilyen funkcionalitásbeli hátrányt, s a LOB (Long OBject) típusokon kívül minden más típussal működik. A törlés (DELETE) és beillesztés (INSERT) sem kerül több időbe, mint a tömörítés nélkül tárolt tábláknál. Egyedül az adatok frissítése (UPDATE) esetén fordulhat elő, hogy a végrehajtás lassabb lesz. Célszerű tehát a tömörítést minden csak olvasható, illetve ritkán változtatandó táblánál használni (mivel csökkenti a használt merevlemezt, memóriát –buffer cache- és gyorsítja a lekérdezés végrehajtást – cserébe azonban csak egy csekély CPU-val fizetünk).
Partícionált táblák: által lehetőség van az adatok kisebb részekre bontására, s ezáltal könnyebb managelésére.
Egymásba ágyazott táblák (Nested tables): egy tábla oszloptípusának megadhatunk egy másik táblát is, ezáltal egymásba ágyazott táblákat is létrehozhatunk. A beágyazott táblát az Oracle adatbázis egy külön táblában tárolja.
Ideiglenes táblák (Temporary tables): nem permanens táblák. Tranzakcióhoz vagy sessionhöz tartozhatnak, így csak azok élettartama alatt léteznek. Mivel az adott tranzakció, ill. session kizárólagos joggal rendelkezik felettük, így zárkezelésre sincs szükség. Ellentétben a permanens táblákkal, számukra csak az első INSERT utasítás kiadását követően foglalunk szegmenst.
Külső táblák (External tables): által lehetőség van külső adatbázisokban található adatokhoz történő hozzáférésre úgy, mintha azok a saját adatbázisunk egy táblájában lennének tárolva. A külső táblák nem tartalmazzák, hogy a külső forrásnál hogyan vannak az adatok tárolva (az adatok transzformálását az Access Driver végzi), csupán azok megjelenítéséért felelősek. Természetesen csak olvashatóak, nem rendelhetünk hozzájuk indexeket, s a virtuális oszlopok sem támogatottak.

Nézetek (Views):
A nézetek olyan virtuális táblák, melyek adataikat egy vagy több fizikai táblából, vagy más nézetekből veszik. Fő feladatuk tehát az adatoknak egy előre megszabott formában történő megjelenítése, s ezáltal bizonyos adatok elrejtése. Működésük és a rajtuk végrehajtható műveletek többé-kevésbé megegyeznek a tábláknál megszokottakkal.
Tárolás: mivel a nézetek csak egy lekérdezés által definiáltak, s nem tartalmaznak ténylegesen adatokat, ezért tárolási helyet sem kell biztosítani a számukra. Csupán magát a lekérdezést tároljuk el a data dictionaryben.
Felhasználás: tábla bizonyos sorainak vagy oszlopainak rejtése; adat komplexitás elrejtése; egyszerűbb lekérdezések megfogalmazása; többféle adat megjelenítés; alkalmazások függetlenítése az alap táblákon végrehajtott változtatásoktól.
Működés:

• A nézetre történő hivatkozás helyére behelyettesítődik a nézet által definiált lekérdezés.
• Szintaktikai elemzést hajt végre az így kialakult utasításon.
• Végrehajtja az utasítást.

Updatable Join Views: két vagy több táblából vagy nézetből származtatott nézet, melyen engedélyezettek az UPDATE, INSERT és DELETE műveletek. Az adatszótár (data dictionary) ALL_UPDATABLE_COLUMNS, DBA_UPDATABLE_COLUMNS és USER_UPDATABLE_COLUMNS nézetei tartalmazzák, hogy a nézet mely oszlopai frissíthetőek (UPDATEelhetőek). Ennek feltétele, hogy a nézet ne tartalmazza a következő struktúrák egyikét sem: halmaz operátorok; DISTINCT operátor; aggregátumok és analitikus funkciók; GROUP BY, ORDER BY, CONNECT BY és START WITH klauzulák; kollekciós kifejezés vagy allekérdezés a SELECT után; illesztések (néhány kivételtől eltekintve). A nem frissíthető nézeteket INSTEAD OF triggerek használatával módosíthatjuk.
Object Views: objektum nézetekből kinyerhetjük, frissíthetjük, beilleszthetjük és törölhetjük az adatokat pontosan úgy, mintha objektum típusként lennének tárolva.
Inline Views: nem séma objektum, csak egy allekérdezés egy aliasszal.


Materializált Nézetek (Materialized Views):
A materializált nézeteket adatok összegzésére, számítására, replikázására és szétosztására használhatjuk. Ebből kifolyólag főként adattárházaknál (data warehouse), döntéstámogató rendszereknél és elosztott vagy mobil számításoknál használjuk őket. Az optimalizáló (optimizer) automatikusan felismeri, hogy mikor lehet egy kérést materializált nézet segítségével kielégíteni, s automatikusan behelyettesíti azt a lekérdezésbe. Így nem szükséges közvetlen a táblákból vagy nézetekből kinyerni a kívánt adatokat, amivel növelhetjük a teljesítményt. Néhány szempontból tehát a materializált nézetek hasonlítanak az indexekre:

• tárhelyet fogyasztanak.
• ha változnak az adatok a master táblájában, akkor frissíteni kell őket.
• lekérdezések behelyettesítése által növelik az SQL végrehajtások teljesítményét.
• felhasználók és alkalmazások szempontjából átlátszóak.

Ellentétben azonban az indexekkel, a materializált nézetekhez közvetlenül is hozzáférhetünk egy SELECT utasítással, illetve a frissítés típusának függvényében akár közvetlenül is alkalmazhatunk rajtuk INSERT, UPDATE vagy DELETE műveleteket.
Nézeteken alkalmazott kényszerek: multidimenziós adatok felismerhetősége érdekében lehetőség nézeteken is bizonyos kényszerek megfogalmazására: primary key, unique és referential integrity constrainteket adhatunk meg.
Frissítés: kétféle frissítési eljárás használtható: inkrementális (fast refesh) és teljes. Előbbi esetén a materialized view log vagy a direct loader log tartalmazza a változtatásokat. A frissítés maga történhet azonnal vagy előre meghatározott időközönként.
Materialized View Logs: séma objektumok, melyek az egyes master táblákban történt változásokat jegyzik a materializált nézet számára, ha az inkrementális frissítést használ. Helye a master tábla sémájában van.


Kapcsolódó link:
Oracle® Database Concepts: Schema Objects

Munkatervek

A 2007/2008 2. félévre vonatkozó munkatervek letölthetőek:

2 kredites önlab munkaterve: itt
8 kredites önlab munkaterve: itt