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:
- 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.
- A CJQ0 dinamikusan létrehoz Job Queue szolga processzeket (J000..J999) a feladatok futtatására.
- A Job Queue processz lefuttatja az egyik CJQ0 által kiválasztott feladatot.
- 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
Nincsenek megjegyzések:
Megjegyzés küldése