Az adatbázis fizikai szerkezete, az adatszótár, és az adatbáziskezelő rendszer monitorozása

Az adatbázis fizikai szerkezete nem más, mint fájlok halmaza. Ezek tartalmazzák a logikai szinten tárgyalt adatbázis elemeket (táblákat, kényszereket, indexeket, nézeteket, tárolt kódokat, és egyéb objektumokat) könyvtárakba és állományokba szerveződve a merevlemezen. Ki kell emelni viszont, hogy a komolyabb adatbáziskezelőknél nincs 1:1 megfeleltetés a tábla és a fájlok között, lehet egy tábla több fájl, de akár több tábla egy fájl is.

Az Oracle adatbázis fizikailag nem más, mint állományok halmaza, melyet az adatbáziskezező rendszer egységként kezel. Ezeket az állományokat látja az operációs rendszer, a fájlkezelő rendszer, és a számítógép rendszergazdája.Három féle fő állománytípust (fájltípust) tudunk elkülöníteni:datafile-okkontroll file-okredo log file-ok

Az adatállomány az adatbázis hasznos adatatait tartalmazó fájlok összesége, ez teszi ki az adatbázis túlnyomó részét, nagy helyet foglal a merevlemezen. Az adatfájlok számát a DBA (database admisnistrator) definiálja, egy-kettőtől akár több száz is lehet.Kép mellékelve a DBA_DATA_FILES nézetről, mely az adatfájlokról tartalmaz információkat. Elérési útvonala: connections ablak->other users->sys->views

A redo log fájlok a naplóállomány szerepét töltik be az Oracle adatbázisoknál. Minimum kettő van belőlük általában. A legfontosabb szerepük az adatbázis visszaállíthatóságának biztosítása egy esetleges adatvesztés esetén.Ha egy tranzakciót végrehajtunk, akkor az először csak a memóriában hajtódik végre (cachelés), ez azért hátrányos, mert például egy áramszünet esetén ezek a fizikai rekordok a bennük tárolt változásokkal együtt elvesznek. Ezért szükséges ezeket a rekordokat a memóriából kiírni a merevlemezre (ez történik commitáláskor). Ilyenkor a lemezen ezek az adatok az redo log fájlokba íródnak ki. Fontos még megjegyezni, hogy ezek a módosítások a naplóállományból nem rögtön, hanem némi késleltetéssel kerülnek csak átvezetésre a datafájlokba. Ami viszont elengedhetetlenül fontos, hogy ezek a tranzakciók megismételhetőek legyenek, ha bármilyen okból erre szükség lenne, ezt a redo log fájlok biztosítják is (redo=megismétlés).

A vezérlőállomány (kontroll fájlok) az adatbázis alapvető adatait, tulajdonságait tartalmazza. Ide tartozik például az adatbázis neve, kódolása, szerkezeti tulajdonságai... Ezen kívül még pointerek is vannak benne, amelyek a data fájlokra mutatnak, ezáltal egyfajta kiinduló pontként szolgálva. Kb. 10-50 Mb területet foglal a merevlemezen. Az Oracle alapú adatbázisoknál általában 2 pédány található ezekből a kontroll fájlokból tükrözve, ezzel biztonsági mentést biztosítva egy esetleges adatvesztés esetére.

A három fő fájltípuson kívül vannak még fontos állományok, de ezek nem képezik szervesen az adatbázis részét.

A paraméter fájl egy nélkülözhetetlen működési fájl, amit az adatbázis rendszergazdája hoz létre. Ez nem más mint egy szöveges állomány, amiből a szoftver olvassa ki induláskor a működési paramétereket, pl: SGA memóriarészeinek méretét.forrás: http://people.inf.elte.hu/kiss/08bir/HApp_d.pdf

A password fájl azért szükséges, mert a felhasználók jelszavai az adatszótárban kerülnek tárolásra, ami értelemszerűen nem elérhető, ha a rendszer kikapcsolt állapotban van. Viszont a rendszergazdáknak már startup parancs kiadásához is be kell írniuk a jelszavukat. Erre szolgál ez a jelszó fájl, eltárolja a rendszergazdai jelszavakat a rendszer elindításához.

Az adatbázisoknál az egyik legfontosabb probléma egy esetleges adatvesztés. Ez akár lehet egy kisebb áramszünet miatti fennakadás, de egy nagyobb adatállomány elvesztése is egy lemezhiba folytán. Ennek a kiküszöbölésére szolgálnak az archived log fájlok, melyek biztonsági mentésket tartalmaznak a redo log fájlokról, mivel ezek a fájlok ha az egyik megtelik, folyamatosan felülírják egymást, így a régebbi változtatások nyomon követésére már nem adnak lehetőséget. Viszont a bennük tárolt infromációk egy háttérprocessz keretében átíródnak az archived log fájlokba, ahol ezek az adatok már tárolásra kerülnek, nem írják felül egymást. Ez a biztonsági megoldás viszont nem egy alapértelmezett dolog az adatbázisoknál, csak egy opció, de erősen ajánlott a kihasználása.

Az Oracle adatbázis architektúráját (szerkezetét) a csatolt kép szemlélteti.

Egy szemléltető videó csatolva az Oracle adatbázis architektúra szerkezetéről a linken.

Az Instance nem más mint egy Oracle példány, ehhez kapcsolódik a felhasználó. Memória struktúrák és folyamatok rendszeréből épül fel. Konkrétan a memóriában lefoglalt System Global Area (SGA) terület és azok a szerverfolyamatok, amelyek az adatbázis-műveletek végrehajtásáért felelősek tartoznak ide.forrás: http://people.inf.elte.hu/kiss/08bir/HApp_d.pdf

Az SGA (System Global Area) az Instancehez tartozó memóriaszerkezet egyik rész. Az összes szerverfolyamat és háttérfolyamat osztozik rajta. Az SGA a példányhoz tartozó adatokat és vezérlő információkat is tartalmazhat. Memóriaszerkezetének legfontosabb részei a database buffer cache és a redo log buffer cache. Továbbá itt helyezkedik el rengeteg számláló, melyek az adatbázis eseményeit számolják. Ennek az adatbázis monitorozásánál van kiemelt szerepe.forrás:http://people.inf.elte.hu/kiss/08bir/HApp_d.pdf

A database buffer cache nem más mint egy gyorsító, nagyon kicsi része a tényleges adatbázisnak, azok az adatok tárolódnak itt, amiket a leggyakrabban használunk, így a selectek, és egyéb műveletek itt lefutva sokkal gyorsabbak.

Ide kerülnek beírásra az adatokon végzett módosítások, hogy szükség esetén vissza lehessen állítani őket egy korábbi állapotba.forrás: http://people.inf.elte.hu/kiss/08bir/HApp_d.pdf

A shared pool sok fajta adatot cachel. A cachelt adatok közé tartoznak a szöveg szerinti, valamint a végrehajtható formájú PL/SQL blokkok és SQL utasítások, szótár cache adatok, eredmény cache adatok, és más adatok is.forrás: http://docs.oracle.com/database/122/TGDBA/tuning-shared-pool-and-large-pool.htm#TGDBA558

A library cache raktározza a végrehajtható formáját az előzőleg hivatkozott SQL és PL/SQL kódnak.forrás: http://docs.oracle.com/database/122/TGDBA/tuning-shared-pool-and-large-pool.htm#TGDBA558

A data dictionary cache az adatszótárból hivatkozott adatokat raktározza.forrás: http://docs.oracle.com/database/122/TGDBA/tuning-shared-pool-and-large-pool.htm#TGDBA558

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.forrás: http://oraoptimization.blogspot.hu/2008_03_01_archive.html

A database writer (DBWR) feladata, hogy a cacheből kiírja az információkat a lemezre (de csak késleltetve), ez a folyamat egy background processz formájában megy végbe.

Checkpointok előfordulásánál frissíti az adatfájlok (datafiles) fejlécét.forrás: http://oraoptimization.blogspot.hu/2008_03_01_archive.html

Ez a folyamat végzi a redo log bufferek tartalmának kiírását a redo log fájlokba.forrás: http://oraoptimization.blogspot.hu/2008_03_01_archive.html

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.forrás: http://oraoptimization.blogspot.hu/2008_03_01_archive.html

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 caché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.forrás:http://oraoptimization.blogspot.hu/2008_03_01_archive.html

A felsoroltakon kívül egyéb háttérfolymatok is működnek, a csatolt linken további információk találhatók ezzel kapcsolatban az Oracle dokumentációjában.

Az Oracle adatbázishoz kapcsolódó folyamatok két részre oszthatók: felhasználói folyamatok, és szerver folyamatokforrás: http://oraoptimization.blogspot.hu/2008/03/architektra-part-8-processz-architektra.html

Ha egy felhasználó egy adatbázishoz csatlakozó alkalmazást vagy Oracle eszközt futtat, automatikusan létrejön számára egy felhasználói processz a user alkalmazásának kezelésére (az alkalmazás kódjának futtatására).források:http://people.inf.elte.hu/kiss/08bir/HApp_d.pdfhttp://oraoptimization.blogspot.hu/2008/03/architektra-part-8-processz-architektra.html

A szerver processzek segítségével kerülnek lekezelésre a felhasználói processzek kérései. Lényegében nem más, mint amikor a user küld egy utasítást (select, insert,...), és a szerver visszaküldi az eredményt.Minden userhez külön-külön szerver processz létezik adatbázis oldalon.forrás:http://oraoptimization.blogspot.hu/2008/03/architektra-part-8-processz-architektra.html

Ide maga a fizikai adatbázis tartozik az előbb bemutatott állományaival.

Az Oracle adatbázis architektúrája, két végpontú (user, adatbázis), az-az két rétegű kliens-szerver architektúráról beszélhetünk. Azonban célszerű megemlíteni, hogy cégeknél létezik egy harmadik, application szerver réteg is.

A user maga a felhasználó, aki lekérdezést, vagy módosítást akar végrahajtani az adatbázison.

A szerver azt a számítógépet jelöli, aminek merevlemezén maga az adatbázis tárolódik.

Logikai megközelítésben az adatbázis táblaterekből épül fel. Ezek elkülönített részek az adatbázisban, felhasználási típusuk szerint több fajtáját különítjük el. Külön táblatér van például az indexeknek, amelyek nem annyira értékesek mint az adatbázis valós adatai, ezért egy kevésbé védett táblatérben vannak, maga a tábla viszont egy jobban védett táblatérben helyezkedik el.A táblaterek szemléltetésére jó példa a tantermek egy egyetemen, vagy mondjuk egy lakás szobái.Kép mellékelve a DBA_TABLESPACES nézetről, mely a táblaterekről szolgáltat információkat. Elérési útvonala: connections ablak->other users->sys->views

A táblaterek további egységekre, úgynevezett szegmensekre bonthatók. A helyet igénylő objektumok egy-egy saját szegmenst kapnak, így az előző példánkhoz visszatérve külön szegmensben helyezkedik el egy tába és egy index.

A szegmenseket még kisebb darabok, extent-ek építik fel. Egy táblatér extentek ezreit vagy akár millióit is tartalmazhatja.

Fizikai megközelítés esetén az adatbázis és a hozzá tartozó táblaterek állományok halmazai, fájlokból épülnek fel.

Database administrator hozza létre a fizikai adatbázist SQL utasítással:CREATE DATABASE database1...;Ha a parancs lefutott, létrejön az adatbázis, ami előredefiniált táblaterekből áll, és a megfelelő datafájlból (fájlokból) implementálódik.

Táblatér létrehozása Database Administartor által, meg kell adni a hivatkozás útvonalát is:CREATE TABLESPACE tablespace1DATAFILE 'C:\folder1\tablespace1.dbf' SIZE 7G;(G=Gb)

A tábla létrehozását már nem kell a DBA-nak végeznie, megfelelő jogosultsággal bárki elvégezheti. Itt kell megadni melyik táblatérben helyezkedjen el:CREATE TABLE table1 (o1 number...)TABLESPACE tablespace1;

Következő lényeges pontunk az adatszótár bemutatása, az itteni információkon felül a teljes dokumentáció a témához megtalálható az Oracle weboldalán a csatolt linken.

A metaadatok összességét relációs adatbázisoknál Adatszótárnak (Data Dictionary) hívjuk. Metaadat nem más, mint adat az adatról, az adatbázisban található táblák, indexek, nézetek, és egyéb objektum típusok információi tartoznak ide. Például indexek típussal rendelkeznek, és vannak táblaoszlopaik, amelyeket indexelnek, a nézetekhez az őket meghatározó SELECT-definíció tartozik,...stb. Ezek az információk az adatbázisról központi, csak olvasható referencia táblákban (szótártáblák) tárolódnak, de a szótárnézetek is az adatszótár részei.forrás: http://oraoptimization.blogspot.hu/2008/03/architektra-part-6-adatsztr.html

Az adatszótár is táblákban tárolja az adatokat, Oracle szakkifejezéssel Base Table-nek hívják ezeket a szótártáblákat. Ugyanúgy indexekkel biztosítja az egyediséget és gyorsítja fel a keresést. Csak maga a rendszer módosíthatja őket. A szótártáblák normalizáltak és a legtöbb adat kódolt bennük, ezért közvetlenül szinte olvashatatlanok a felhasználó számára.Egy DDL utasítás akár 20 DML-ből is összetevődhet. Például CREATE TABLE utasítás lebomlik rekurzív SQL utasításokra: INSERT INTO TAB$.(a következőkben felsorolt szótártábláknál sokkal több van egy adatbázisban, de csak a leglényegesebbeket akartam kiemelni...)forrás: http://docs.oracle.com/database/122/CNCPT/data-dictionary-and-dynamic-performance-views.htm#CNCPT002

Táblákról tárolt adatok táblája (TAB$). Úgy tudjuk elérni SQL Developerben, hogy a Connections ablakban a saját kapcsolatunkra kattintunk, ott legörgetve megnyitjuk az Other Users mappát, és kiválasztjuk a SYS felhasználót, majd itt a Tables mappában megtaláljuk a TAB$ táblát.(A tábláról kép csatolva)

Oszlopokról tárolt adatok táblája (COL$). Elérése ugyanúgy ahogy a TAB$ táblát, csak most a COL$ táblát választjuk ki az utolsó lépésben.(Tábláról kép mellékelve)

Indexekről tárolt adatok táblája (IND$). Elérése hasonló módon mint TAB$ táblánál.(Tábláról kép mellékelve)

Nézetekről tárolt adatok táblája (VIEW$). Elérése hasonló módon mint TAB$ táblánál.(Tábláról kép mellékelve)

Táblaterekről tárolt adatok táblája -Oracle specifikus

Datafájlokról tárolt adatok táblája -Oracle specifikus

A normalizált szótártáblák olvasását könnyítik meg a szótárnézetek.Az adatszótár nézetek információit a DICTIONARY nézetből, vagyis a szótárnézetek leírásából tudhatjuk meg. A DICTIONARY nézet visszaadja az összes adatszótár nézet listáját olyan megjegyzésekkel, melyek leírják az egyes nézetek tartalmát. A DICT_COLUMNS nézet az összes adatszótár nézetben lévő összes oszlop listáját adja vissza. Ezzel a két nézettel megállapítható, hogy milyen információk állnak rendelkezésre, és miként férhetünk hozzájuk.forrás: http://www.ibm.com/support/knowledgecenter/hu/SSEPGG_9.7.0/com.ibm.db2.luw.wn.doc/doc/c0054497.html

Ez a nézet a saját objektumaink adatait jeleníti meg.pl.: USER_TABLES, USER_IDENTIFIERS, USER_INDEXES, USER_VIEWS...stb.A USER_TABLES nézet szemléltető képként csatolva. Elérési útvonala: connections ablak->other users->sys->views

Ebben a nézetben látjuk saját objektumainkat is, és a mások sémáiban lévőket is, ha rendelkezünk hozzá megfelelő jogosultsággal.pl.: ALL_TABLES, ALL_IDENTIFIERS, ALL_INDEXES, ALL_VIEWS...stb.Az ALL_TABLES nézet szemléltető képként csatolva. Elérési útvonala: connections ablak->other users->sys->views

A DBA nézetekben az adatbázis minden keresett típusú objektuma látható. Ezek a fajta nézetek csak rendszergazdai jogosultságokkal ovashatók.pl.: DBA_TABLES, DBA_IDENTIFIERS, DBA_VIEWS, DBA_INDEXES...stb.A DBA_TABLES nézet szemléltetésként kép formájában csatolva. Elérési útvonala: connections ablak->other users->sys->views

Nézzünk egy példát, és az előadás anyagában szereplő önálló feladatot kidolgozva!

A példa feladat: A keresett objektumaink legyenek a saját nézeteink, azon belül is azok amik nevei 'n' betűvel kezdődnek.

Első lépés kideríteni annak a nézetnek a nevét amiben a számunkra releváns információk vannak. Itt kell használnunk a DICTIONARY nézetet.SELECT * FROM DICTIONARY WHERE upper(TABLE_NAME) LIKE '%VIEW%';A lekérdezés eredményei közül számunkra a USER_VIEWS nézet a megfelelő, így ezzel dolgozunk tovább.

A következő lépés a megtalált nézetünk struktúrájának vizsgálata.DESCRIBE USER_VIEWS;Ez a parancs megjeleníti nekünk a USER_VIEWS nézet oszlopait, ebből most nekünk csak a VIEW_NAME kell.

Az utolsó lépés a végső lekérdezés megírása.SELECT VIEW_NAME FROM USER_VIEWS WHERE upper(VIEW_NAME) like 'N%';

Képek mellékelve a linkeken!

Keressék meg az összes táblájukat!SELECT * FROM USER_TABLES;

Állapítsák meg, hogy hány index van a sémájukban!SELECT Count(*) as osszIndex FROM USER_OBJECTS WHERE lower(object_type) = 'index';

Keressék ki egy nézetük definicióját az adatszótárból (ha nincs még nézetük, akkor előbb hozzanak létre egyet)!SELECT text FROM DBA_VIEWS WHERE upper(view_name) = 'NEZETPL' AND upper(owner) = 'GI17_SAJATNEPTUN';

Az adatbáziskezelő rendszer monitorozásán a rendszer ellenőrzését, felügyeletét értjük, az optimális működés és a teljesítményben bekövetkező hibák kiküszöbölése érdekében. A folyamat végrehajtása a DBA feladata. Részletes dokumentáció a témához az Oracle weboldalán. (link csatolva)

fő müködési körülmények, rendszer működését meghatározó tényezők:pillanatnyilag bejelentkezett usererek számafolyamatban lévő SQL műveletekadatbáziskezelő rendszer aktuális sebességeuserek várakozásának fő okai

Egy korszerű adatbázsikezelő rendszer monitoring műveletei SELECT utasításokon keresztül elvégezhetőek, így lényegében bárki monitorozhat (rendszergazdai jogosultság meglétével). A monitorozás effajta struktúrája ezért API-ként fogható fel. Ez egy alkalmazásprogramozási felület (application programming interface), egy program (vagy rendszerprogram) azon eljárásainak és ezek felhasználásának leírása, melyet más progamok készítői szabadon felhasználhatnak. Ez lehetővé teszi, hogy bármelyik gyártó készíthessen monitorozó alkalmazást, az Oracle nem sajátította ki ezt a jogot, ezzel persze erős piaci versenynek tette ki magát, de ennek eredményeképpen a folyamatos fejlődés/fejlesztés is garantált a cégnek, ami viszont hatalmas pozitívum.Egy külső gyártó monitoring alkalmazása megtekinthető az alábbi linken: http://www.myorasql.comforrás és részletes leírás az API-król: http://www.tankonyvtar.hu/hu/tartalom/tamop412A/2011-0103_panem_szoftvertechologia/ch13s02.html

A dinamikus performancia nézetek az instance-szintű teljesítmény problémák azonosítása szempontjából hasznosak. Az X$ táblák belső adatszerkezetek reprezentálásai, amelyek SQL utasítások által kerülhetnek feldolgozásasra, ezekről a táblákról készült nézetek a V_$ előtaggal vannak ellátva. Ezekről a nézetekről további, publikus nézetek léteznek, V$ prefixxel, ezek lehetővé teszik az átlag felhasználónak, hogy ezeket az adatokat elérje. Ezek a nézetek segítséget nyújtanak a teljesítmény hangolásban, és az ad-hoc nyomozásban, ha a felhasználók hirtelen válaszidő romlást (növekedést) tapasztalnak. Legtöbbjük a memóriából olvas, de vannak olyanok amelyek a vezérlőállományból.(Egy szemlétető kép csatolva SQL Developer-ből a V_$BACKUP nézetre,elérési útvonala: connections ablak->other users->sys->views)Példa dinamikus performancia táblákra: X$bh - buffer headerPélda dinamikus performanica nézetekre: V_$BACKUP - megmutatja a backup státuszát az összes online datafájlnakPélda publikus dinamikus performancia nézetekre: V$LOCK - zárakat jeleníti meg, V$BACKUPforrás: http://docs.oracle.com/database/122/REFRN/about-dynamic-performance-views.htm#REFRN-GUID-F66BEE0B-8091-48A3-975B-376D23B8B4E8http://www.dba-oracle.com/t_x$_tables.htm