av Richárd Kele för 7 årar sedan
442
Mer av detta
A gondolattérkép az előadás anyaga és saját jegyzetem alapján készült. Ahol nincs megjelölve forrás, ott az ezekből származó információkat használtam fel.
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)
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 header
Példa dinamikus performanica nézetekre: V_$BACKUP - megmutatja a backup státuszát az összes online datafájlnak
Példa publikus dinamikus performancia nézetekre: V$LOCK - zárakat jeleníti meg, V$BACKUP
http://www.dba-oracle.com/t_x$_tables.htm
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.com
forrás és részletes leírás az API-król: http://www.tankonyvtar.hu/hu/tartalom/tamop412A/2011-0103_panem_szoftvertechologia/ch13s02.html
fő müködési körülmények, rendszer működését meghatározó tényezők:
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.
Nézzünk egy példát, és az előadás anyagában szereplő önálló feladatot kidolgozva!
Képek mellékelve a linkeken!
3. feladat
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';
2. feladat
Á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';
1. feladat
Keressék meg az összes táblájukat!
SELECT * FROM USER_TABLES;
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.
3. végső lekérdezés
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%';
2. nézet szerkezete
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.
1. szükséges nézet neve
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 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
DBA_ kezdetű nézetek
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
ALL_ kezdetű nézetek
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
USER_ kezdetű nézetek
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
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
datafile-ok táblája
Datafájlokról tárolt adatok táblája -Oracle specifikus
táblaterek táblája
Táblaterekről tárolt adatok táblája -Oracle specifikus
nézetek táblája
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)
indexek táblája
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)
oszlopok táblája
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)
táblák táblája
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)
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 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.
3. tábla
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;
2. táblatér
Táblatér létrehozása Database Administartor által, meg kell adni a hivatkozás útvonalát is:
CREATE TABLESPACE tablespace1
DATAFILE 'C:\folder1\tablespace1.dbf' SIZE 7G;
(G=Gb)
1. ,,fizikai" adatbázis
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.
fizikailag
adatállományok
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.
logikailag
táblaterek
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
szegmensek
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.
extentek
A szegmenseket még kisebb darabok, extent-ek építik fel. Egy táblatér extentek ezreit vagy akár millióit is tartalmazhatja.
Az Oracle adatbázis architektúráját (szerkezetét) a csatolt kép szemlélteti.
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.
server
A szerver azt a számítógépet jelöli, aminek merevlemezén maga az adatbázis tárolódik.
user
A user maga a felhasználó, aki lekérdezést, vagy módosítást akar végrahajtani az adatbázison.
Egy szemléltető videó csatolva az Oracle adatbázis architektúra szerkezetéről a linken.
adatbázis
Ide maga a fizikai adatbázis tartozik az előbb bemutatott állományaival.
processzek
Az Oracle adatbázishoz kapcsolódó folyamatok két részre oszthatók: felhasználói folyamatok, és szerver folyamatok
forrás: http://oraoptimization.blogspot.hu/2008/03/architektra-part-8-processz-architektra.html
server process
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
user process
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.pdf
http://oraoptimization.blogspot.hu/2008/03/architektra-part-8-processz-architektra.html
Instance
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
főbb elemei
háttérfolyamatok
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
egyéb háttérfolyamatok
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.
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 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
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.
forrás: http://oraoptimization.blogspot.hu/2008_03_01_archive.html
log writer process (LGWR)
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
checkpoint process (CKPT)
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
database writer (DBWR)
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.
SGA
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
shared pool
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
data dictionary cache
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
library cache
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
redo log buffer cache
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
database buffer cache
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.
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:
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.
archived log files
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.
password file
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.
parameter file
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 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 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).
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
