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