Informatika | Adatbázisok » Adatbázis-adminisztráció

Adatbázis adminisztráció 2009/2010 rész I Mi a DBA Az alkalmazások adatokkal dolgoznak. A DBA a fejlesztési folyamat középpontjában áll, biztosítja, hogy az alkalmazások hatékonyan és pontosan érhessék el a cég adatait. A DBA-k sokféle emberrel kerülnek kapcsolatba: szakértőkkel, programozókkal, végfelhasználókkal, vásárlókkal, igazgatókkal Ennek ellenére gyakran szenvednek hiányt kommunikációs képességekben. Röviden: A DBA biztosítja a szervezet adatbázisainak és alkalmazásainak folyamatos, hatékony és zavartalan működését. Egy jó DBA-nak élveznie kell a kihívásokat, és jó problémamegoldó képességgel kell rendelkeznie. Az adatbázis adminisztráció nonstop munka, de jól fizetik 1. Adatbázis technológia Az adatbázis (DB) azonos minőségű (jellemzőjű), többnyire strukturált adatok összessége. Az adatbázis-kezelő (DBMS) az adatbázis működtetésére, rendszerszintű és felhasználó folyamatainak

szervezésére szolgál. Az adatbázisok két fajtáját szokás megkülönböztetni, a logikai és a fizikai adatbázist. Előbbi lényegében a „mit tárolunk” (mit és hogyan akarunk látni az adatokból), míg utóbbi a „hogyan tároljuk” (mit és hogyan érünk el a fizikai háttértáron) kérdésre keresi a leghatékonyabb választ. 2. Adatbázis adminisztráció vezetési alapelve / vezetési diszciplínája Az adatbázis adminisztráció ritkán jelenik meg vezetési alapelvként. A diszciplína fogalma magában foglal egy tervet, és a terv megvalósítását. Az adatbázis adminisztráció vezetési alapelvként kezelése fejleszti az adatok kezelését. Ez a különbség a reaktív és proaktív kezelésmód között A reaktív DBA inkább úgy viselkedik, mint egy tűzoltó a problémák előfordulása után oldja meg azokat. Ezt okozhatja a túlzott leterheltség, költségvetési hiány. Ezzel szemben a proaktív DBA olyan gyakorlatokat és eljárásokat

dolgoz ki, amivel megelőzheti a problémák előfordulását. Egy adatspecialista, aki általában a DBA, részt kell vegyen a fejlesztési ciklus minden állomásában, ahogy az 1-1 ábrán is látszik Az inicializálás és követelmény feltárás fázisban a DBA azonosítja a projekt adat komponenseit. Segíthet meghatározni, hogy a szükséges adat létezik-e már valahol a szervezeten belül, vagy teljesen új. Az elemzés és tervezés fázisban, az alapvető adat követelményeket át kell alakítani fogalmi (koncepcionális) és logikai adatmodellé. A fejlesztés megkezdése előtt a logikai adatmodellt át kell alakítani fizikai adatbázis tervvé, ami implementálható valamilyen DBMS felhasználásával, mint mondjuk Oracle. Tesztadatokkal fel kell tölteni az adatbázist az alkalmazás tesztekhez Továbbá a DBA-nak ki kell fejlesztenie egy módszert a tesztadatok frissítésére az ismétlődő tesztek végrehajtásához. Amikor az alkalmazás fejlesztési

státuszból működési státuszba lép, a DBA felkészíti a DBMS-t az új terhelésre. Ez a felkészítés magában foglalja a szükséges biztonsági lépéseket, az alkalmazás memória és tárolókapacitás igényének felmérését, és az új terhelésnek a már meglévő adatbázisokra és alkalmazásokra kifejtett hatásának megbecslését. A DBA felelős továbbá az új adatbázis teszt környezetből termelési környezetbe való migrálásáért Mialatt az alkalmazás működik a DBA rengeteg feladatot lát el úgy, mint rendelkezésre állás biztosítása, teljesítménymonitorozás, hangolás, mentés és helyreállítás, és jogosultság kezelés. Nincs adatbázis vagy alkalmazás ami sokáig maradna változatlan, mert az üzleti igények változnak idővel, így az üzletet támogató IT rendszerek is változni fognak. Ha karbantartásra van szükség, akkor a DBA újra bevonásra kerül az egész folyamatba, a követelmény feltárástól az

implementációig. Végül, amikor az alkalmazás élete végére ér, a DBA-na kell segíteni meghatározni mi legyen az alkalmazás által használt adatokkal. Nincs már szükség az adatokra vagy más alkalmazások és folyamatok is használják? Vannak szabályok, amik szerint az adatokat az alkalmazás vége után is tárolni kell? Vannak az üzletnek bármilyen adatvédelmi irányelvei amelyek meghatározzák az adatok kezelését? 1 1. ábra Alkalmazásfejlesztés életciklusa Ezeken felül, a DBA köteles: – egy ad hoc (alkalmi) lekérdezés környezetet létrehozni ami magában foglalja lekérdezés értékelő és jelentés készítő eszközök beépítését; – olyan irányelveket és eljárásokat kidolgozni amelyek növelik az ad hoc lekérdezések hatékonyságát; – és megfigyelni hangolni az ad hoc lekérdezéseket. 3. 3.1 Adatbázis-, adat-, és rendszer adminisztráció Adat adminisztráció Az adatadminisztrátor (DA) felelős az üzleti zsargon

megértéséért és logikai adatmodellbe fordításáért. Az alkalmazásfejlesztés életciklusra visszautalva, a DA leginkább a követelményfeltárás, elemzés és tervezés fázisában, míg a DBA a tervezés, fejlesztés, tesztelés és működtetés fázisában kerül bevonásra. Másik különbség a DA és DBA között az erőfeszítésük célja. A DA a következő feladatokért felelős: – Az üzleti felhasználóknak szükséges adatok azonosítása és katalogizálása. – Fogalmi és logikai adatmodellek előállítása, hogy pontosan látni lehessen a kapcsolatokat az üzleti folyamatokat kiszolgáló adatelemek között. – Olyan vállalati adatmodell készítése, ami magában foglalja a szervezet minden üzleti folyamata által használt összes adatot. – Adatpolitika készítése a szervezetnek. 2 – Adattulajdonosok és gondnokok azonosítása. – Szabványok felállítása az adatok kontrollálásához és használatához. A DA az

adattárházra, míg a DBA a fizikai adatbázisra és DBMS-re fókuszál. Továbbá a DA kezeli a metaadatokat, a DBA az adatokat A metaadat biztosítja a kontextust, ami által az adat megérthető és ennek következtében információvá válik. Egy koncepcionális (fogalmi) adatmodell az adatkövetelményeket egy nagyon magas szintre emeli. Egy logikai adatmodell mélyrehatóbb részleteket mutat az adatok típusáról, hosszáról, kapcsolatáról és számáról. 3.2 Adatbázis adminisztráció A DBA első feladata megérteni a DA által készített adatmodellt és kommunikálni azt az alkalmazásfejlesztőknek és a további szakértőknek. A logikai adatmodell segítségével készíti a DBA a fizikai adatbázist 3.3 Rendszer adminisztráció A rendszeradminisztrátor biztosítja az adatbázis-fejlesztéshez szükséges IT infrastruktúra működését azáltal, hogy megfelelően beállítja a DBMS-t, alkalmazza a DBMS gyártótól jövő folyamatos javításokat,

és koordinálja a DBMS új verzióra és kiadásra történő migrálását. Az 1-2 ábra leírja a DA, SA, DBA feladatköreit 2. ábra Alkalmazásfejlesztés életciklusa 4. DBA feladatok Biztosítani, hogy a szervezet adatai és adatbázisai hasznosak, használhatóak, elérhetőek, és helyesek legyenek a DBA-t különböző feladatok elvégzésére kényszeríti különböző területeken. Ilyen területek például adatbázis tervezés, teljesítménymonitorozás és hangolás, adatbázis elérhetőség, biztonság, mentés és helyreállítás, adat 3 integritás, kiadás migrálás, tényleg minden, ami csak a cég adatbázisai körül előfordulhat. Vegyük sorba ezeket a témákat. 4.1 Adatbázis tervezés A DBA képes kell legyen egy logikai adatbázis fizikai adatbázisba történő átalakítására. Habár optimális adatbázisok tervezése fontos, viszonylag kevés részét teszi ki a DBA munkájának 4.2 Teljesítménymonitorozás és hangolás Öt

tényező van hatással az adatbázis teljesítményére: 1) terhelés, 2) áteresztőképesség, 3) erőforrások 4) optimalizáció, 5) versengés. A DBMS felé irányuló igények jelentik a terhelést. Ez online tranzakciók, batch (kötegelt) feladatok, ad hoc (eseti, alkalmi) lekérdezések, adattárház kérdések, analitikus (elemző) lekérdezések, és a rendszer felől bármikor jövő parancsok. A terhelés naponta ingadozhat Az áteresztőképesség a számítógép teljes hardverének és szoftverének az adatfeldolgozó képességét definiálja. Ez a következőkből áll: I/O sebesség, CPU sebesség, a gép párhuzamos kapacitása, és az operációs rendszer és rendszerszoftver hatékonysága. Az optimalizáció folyamata lekérdezésekhez rendelt költségértékek segítségével generál hatékony elérési utakat az adatokhoz. Amikor egy bizonyos erőforrás felé nagy az igény (terhelés), versengés alakulhat ki. Versengés esetén kettő vagy

több komponense a terhelésnek megpróbál egyazon erőforrást használni egymást hátráltató módon (pl. kettős frissítése ugyanannak az adatnak). Ahogy a versengés nő, az áteresztőképesség csökken Adatbázis teljesítmény úgy is definiálható, mint az erőforrás-használat optimalizációja az áteresztőképesség növelése és a versengés csökkentése érdekében. Sok feladat és képesség szükséges a DBA-nak ahhoz, hogy biztosítsa az adatbázis hatékony elérését. Néhány képesség ezek közül megfelelő indexek építése, elegendően nagy puffer és gyorsítótár beállítása, az adatbázis implementáció IT infrastruktúrához igazítása, adatbázisok átszervezése, üzleti változások adaptálása (több felhasználó, több adat), további feldolgozás, követelmények és szabályok átdolgozása. 4.3 Rendelkezésre állás A rendelkezésre állás első komponense a DBMS folyamatos futásának biztosítása. További

komponense az elérhetőségnek az adminisztratív feladatok ellátáshoz szükséges állásidő csökkentése. Minél gyorsabban végzi el a DBA az adminisztratív teendőit, annál kevesebb lesz az állási idő, és lesz elérhetőbb az adatbázis. 4.4 Adatbázis védelem és authorizáció (engedélyezés) Általában a DBA a DBMS beépített biztonsági funkcióit használja SQL GRANT és REVOKE utasítások formájában, és még egyéb csoport feljogosító tulajdonságait a DBMS-nek. Adatbázis-biztonság egyéb módszerekkel is kikényszeríthető. Például nézetek segítségével „elfedhetőek” az érzékeny adatok a végfelhasználók és a programozók elől 4.5 Mentés és helyreállítás (lásd Adatbázis megvalósítás c. tárgy) A DBA-nak képesnek kell lenni az adatok visszaállítására egy használható pontig, függetlenül attól mi az oka, és olyan gyorsan kell csinálnia amennyire csak lehet. Az első típusa a helyreállításnak az

adatok legutolsó konzisztens állapotra visszaállítása. A helyreállítás eredményeként az adatbázis a hibát megelőző állapotába kerül vissza A helyreállítás alatt az alkalmazások nem 4 használhatóak. Másik típusa a hagyományos helyreállításnak az adott időpillanatra történő helyreállítás. Ez a fajta helyreállítás általában alkalmazás szintű problémákat kezel. A hagyományos adott időpontra történő helyreállítás eltávolítja egy adott időpillanat óta végzett tranzakciók összes hatását. Ez gondot jelenthet, mert adatvesztéssel járhat Tranzakció helyreállítás a harmadik típus. A hagyományos megoldások hátrányait próbálja kiküszöbölni: állásidő és adatvesztés Ezért a tranzakció helyreállítás egy alkalmazás helyreállítás, ami során meghatározott tranzakciók egy adott időkereten belüli hatása kitörlődik az adatbázisból. 4.6 Adatintegritás (sértetlenség) Az adatbázist arra

tervezték, hogy helyes adatokat tároljon helyes módon anélkül, hogy azok megsérülnének. Ennek biztosítása érdekében a DBA integritási megszorításokat alkalmaz a DBMS segítségével. Az adatbázis szempontjából lényeges integritási megszorítások: fizikai, szemantikai, és belső. Fizikai integritás a DBMS eszközeivel, mint például tartományok és adattípusok biztosítható. A DBA megfelelő adattípusokat választ az oszlopoknak. Ezzel biztosítja, hogy csak a kívánt adattípusba tartozó adatok tárolhatóak az oszlopokban. Ezeken felül további megszorításokkal kényszerítheti ki a DBA, hogy a megfelelő típusú adatok kerüljenek az oszlopokba. Ezek közül néhány: – Hivatkozási megszorítások (REFERENCES) – Egyediségre vonatkozó megszorítások (UNIQUE) – Feltételes megszorítások (CHECK) Szemantikus integritást nehezebb elérni és meghatározni. Egy példa a szemantikus integritásra az adatok minősége az adatbázisban

Például, egy alkalmazotti adatbázis, ami a rekordok 25%-ban rossz cím vagy telefonszámadatokat tárol jó példa a gyenge minőségre Minőségi adatok elérhetőek helyes alkalmazás kódok, megfontolt üzleti gyakorlatok és meghatározott adatpolitika segítségével. Redundancia (feleslegesen többször tárolt adatok) egy másik szemantikai probléma. A redundáns adatok karbantartása több feladatot jelent a DBA számára Az integritás utolsó aspektusa magában foglalja a DBMS belső problémáit. A DBMS belső szerkezetektől és kódoktól függ, amelyek kezelik a kapcsolatokat, mutatókat és azonosítókat. A DBMS általában jól végzi ezen szerkezetek kezelését, de a DBA-nak néha be kell avatkoznia főleg DBMS hibák esetén. Belső integritás a következő területeken fontos: – Index konzisztencia. Egy index nem más mint mutatók rendezett listája, amelyek adatbázis táblák adataira mutatnak. Ha az indexek elcsúsznak valami miatt, akkor rossz

adatra fognak mutatni – Mutató konzisztencia. Néha nagy multimédiás objektumok nem tárolódnak ugyanazon fizikai fájlban más adatokkal. Ezért a DBMS-nek mutató struktúrákra van szüksége ahhoz, hogy ezeket az adatokat szinkronban tartsa a fő tábla adataival. Ezek is elcsúszhatnak – Mentési konzisztencia. Néhány DBMS termék alkalmanként nem készít olyan biztonsági mentést, amelyet később helyreállítás során fel lehetne használni. Ennek felderítése és javítása a DBA feladata 4.7 DBMS migrálás Az adatbázis folyamatos futásának és korszerűen tartásának feladata sok idejébe kerül a DBA-nak. 5 5. DBA fajták 5.1 Rendszer DBA 5.2 Adatbázis architekt 5.3 Adatbázis elemző 5.4 Adatmodellező 5.5 Alkalmazás DBA 5.6 Feladat orientált DBA 5.61 Teljesítményelemző 5.7 Adattárház adminisztrátor 6. 6.1 Munkaerő alkalmazásbeli megfontolások Hány DBA szükséges? Meghatározni mennyi DBA-ra van szükség

nem egy precíz tudomány. Sok tényezőtől függ: – – – – – – – – – – – – – – – Adatbázisok száma. Adatbázisok mérete. Felhasználók száma, felkészültsége. Alkalmazások száma. Szolgáltatás szintű megállapodás (Service-level aggreement). Az SLA egy megállapodás a végfelhasználók, fejlesztők és DBA-k között a követelményekről, teljesítményről, eltehetőségről Minél megszorítóbb az SLA, annál nehezebb a DBA dolga. Elérhetőségi követelmények. Röviden mennyi állásidő engedélyezett Leállás hatása. Minél nagyobb hatása van pénzügyi értelemben a leállásnak, annál nagyobb a DBA-n a nyomás, hogy biztosítsa a z elérhetőséget Teljesítmény követelmények Alkalmazások fajtái: – Küldetéskritikus alkalmazások állandó megfigyelést igényelnek, hogy az elérhetőség biztosítva legyen. – OLTP (Online Transaction Processing) általában rövidebb, mint az OLAP. Ezek a klasszikus

banki rendszerek – OLAP (Online Analytical Processing). Főként adattárházakban használják: a cégnél lévő OLTP rendszerek adatait gyűjtik össze és elemzik OLTP írási és olvasási műveleteket is tartalmaz, míg az OLAP főként olvasásit. Illékonyság. Adatbázis változtatási kérések gyakorisága határozza meg DBA csapat tapasztalata Programozó csapat tapasztalata. A tagoknak vannak-e SQL vagy PL/SQL ismeretei? Végfelhasználók tapasztalata. A végfelhasználók által kiadott ad hoc SQL lekérdezések DBMS terhelő képessége függ a felhasználók képességeitől DBMS rendszerek változatossága. DBA eszközök. Minél több olyan eszköz van, ami automatizál, annál kevesebb a DBA feladata 6 rész II Az adatbázis környezet létrehozása 7. A szervezet DBMS stratégiájának meghatározása Még kis- és középvállalatok is többféle DBMS-t használnak, jellemzően 2 és 10 közötti különféle terméket. Az okok hogy miért

szükséges a sokféle termék, lehetnek üzleti, vagy valamilyen alkalmazás által támasztott követelmények. Egy-egy új DBMS telepítését igényelheti ha a cég egy olyan dobozos szoftvert vásárol ami nem működik együtt a jelenlegi egyik DBMS platformmal sem, vagy éppen a legújabb technológiákat kívánja követni. Alapos körültekintést igényel egy új DBMS telepítése abból a szempontból is, hogy a későbbi esetleges eltávolítási procedúra minél zökkenőmentesebb lehessen, ugyanis ha a meglévő alkalmazásokat, adatbázisokat nem lehet maradéktalanul migrálni az új rendszerbe, az nélkülözhetetlenné válik és kényszerűségből kell tovább támogatni ami plusz feladatokat ró a DBA-ra. Fontos tehát, hogy a DBA csapatnak beleszólása legyen ezekbe a döntésekbe. 7.1 DBMS választása A lehető legkevesebb különböző DBMS-t használjuk. A következő termékek közül ajánlott választani: – – – – – Oracle MS SQL DB2

PostgreSQL MySQL Szükség van egy stratégiára és egy tervre, hogy kiválasszuk a sajátos helyzethez illő DBMS-t. Amikor adatbázist választunk, ajánlott figyelembe venni a következő tényezőket: – Operációs rendszer támogatás. Támogatja a DBMS azt az operációs rendszert amit a cég használ, vagy használni fog? – Szervezet típusa. Figyelembe kell venni a szervezet filozófiáját DBMS választáskor Pénzügyi, állami szervezetek általában konzervatívak – Benchmark-ok. Milyen teljesítmény értékelések elérhetőek a DBMS-ről? – Skálázhatóság. Támogatja a kívánt felhasználó számot és adatbázis méretet a DBMS? Mennyire támogatja a nagy adatbázisok építését, üzemeltetését? Vannak független felhasználók akik bizonyosságot adhatnak a skálázhatóságáról a DBMS-nek? – Támogató szoftvereszközök elérhetősége. Ezek lehetnek lekérdezést segítő és elemző, adattárház támogató, adatbázis

adminisztrációs, mentés/helyreállítás, teljesítmény monitorozás, kapacitás tervező, adatbázis segédprogramok és programozási nyelveket támogató szoftvereszközök. – Szakemberek. Van elegendő szakképzett profi a DBMS-hez? – Tulajdonjog költsége. Licenc, támogató szoftverek, szakemberek, DBMS-hez szükséges erőforrások költsége – Kiadások ütemezése. Milyen gyakran ad ki a DBMS gyártó új verziót? – Ügyfél referencia. A jelenlegi DBMS tulajdonos véleménye a termékről – DBMS összetettsége. 7.2 DBMS architektúrák A DBMS-t támogató környezet nagyon fontos az adatbázis alkalmazások sikerének szempontjából. Négy szintje elérhető a DBMS architektúrának: vállalati, ágazati, személyi és mobil. Egy vállalati (enterprise) DBMS skálázhatóságra és nagy teljesítményre van tervezve. Egy vállalati DBMS-nek támogatnia kell nagyon nagy adatbázisokat, nagyszámú konkurens felhasználót, és különböző fajtájú

alkalmazásokat. A vállalati DBMS nagyszámítógépeken (mainframe) fut Továbbá az vállalati DBMS kínálja a legtöbb szolgáltatást: több processzor támogatása, párhuzamos lekérdezések támogatása, és hasonlók. 7 Egy ágazati (departmental) DBMS, néha úgy is hivatkozzák, hogy munkacsoport DBMS. Az ágazati DBMS kis és közepes mérető munkacsoportokat támogat; általában UNIX, Linux, vagy Windows NT szervereken fut. A választóvonal az ágazati és vállalati adatbázis szerver között elég halvány. Hardver és szoftver fejlesztések segítségével egy ágazati DBMS is el tudja látni azokat a feladatokat, amelyeket korábban csak vállalati DBMSek tudtak. Egy személyi DBMS egy felhasználóra, és tipikusan kis és közepes teljesítményű PC-re van tervezve. Ilyenek például a Microsoft Access and Visual dBase. Gyakran megpróbálnak egy ilyen DMS-t felhasználni vállalati célokra az alacsony költsége miatt, de mivel csak nagyon kicsi

projektekhez tervezték, nem szokott beválni. Végül a mobil (mobile) DBMS egy speciális változata az ágazati vagy vállalati DBMS-nek. Távoli felhasználóknak tervezték, akik általában nincsenek a hálózatra csatlakozva A mobil DBMS lehetővé teszi a helyi adatbázis elérését egy laptopon vagy kézi számítógépen. Továbbá a mobile DBMS képes szinkronizálni a távoli adatbázis változásait a központi vállalati vagy ágazati adatbázis szerverrel. Ha a vállalatnak különböző szintű DBMS megoldásokra van szüksége ajánlott egy gyártótól vásárolni azokat. 7.3 DBMS fürtözés (klaszterezés) Klaszterezés sok különálló számítási rendszer egyként való együttműködését jelenti, magas rendelkezésre állás érdekében. A két túlsúlyban lévő architektúra fürtözéshez az osztott lemez (shared-disk) és a megosztás nélküli (shared-nothing). Egy shared-nothing architektúrában minden rendszernek meg vannak a saját

erőforrásai (memória, lemez stb.) A fürtözött processzorok a gépeket összekötő hálózaton keresztül kommunikálnak. Ezen felül a kliensek felől érkező kérések automatikusan ahhoz a rendszerhez irányítódnak amely birtokolja a kért erőforrást. A fürtben lévő rendszerek közül egy időben csak egy „birtokolhat” és férhet hozzá bizonyos erőforrásokhoz. Hiba esetén az erőforrás tulajdonjoga dinamikusan átruházódik egy másik rendszerre a fürtben. A fő előnye a shared-nothing rendszernek a skálázhatóság. 3. ábra Shared-nothing architektúra Egy shared-disk környezetben, minden összekapcsolt rendszer ugyanazon lemezes egységen osztozik, ahogy az a 2-2. ábrán is látszik Minden processzornak van saját memóriája, de mindegyik processzor közvetlenül címezheti az összes lemezt. Általában a shared-disk fürtözés nem biztosít olyan fokú skálázhatóságot kis gépekkel mint a shared-nothing. Shared-disk fürtözés

jobban illik nagyvállalati feladatokhoz nagyszámítógépeken (mainframe) Nagyszámítógépek a nagy processzorkapacitásuknak köszönhetően hatalmas feladatokat képesek végrehajtani. Néhány nagyszámítógép teljesítménye már elég, míg ugyanezt csak sok kisgéppel lehetne talán elérni. 8 4. ábra Shared-disk architektúra Shared-disk és shared-nothing összehasonlítása Shared-disk Shared-nothing Gyors alkalmazkodás a változó terheléshez Képes kihasználni az olcsóbb és egyszerűbb hardvert Magas rendelkezésre állás Majdnem végtelen skálázhatóság Leginkább olvasás intenzív környezetben teljesít jól Jól teljesít olvasás-írás intenzív környezetben Az adatot nem kell szétszórni Az adat szét van osztva a fürtben Néhány esetben a fürtözés 99,99%-os elérhetőséget tesz lehetővé a cégek számára. A sokféle DBMS termék támogatása nehéz lehet. Ajánlott számításba venni a hardver platform és operációs

rendszer megszorításait is DBMS választáskor. 8. DBMS telepítése Egy DBMS összetett szoftver ami előretervezést igényel a sikeres telepítés érdekében. Meg kell érteni a DBMS igényeit és fel kell készíteni a környezetet az új DBMS-nek. 8.1 DBMS telepítési alapok Minden DBMS telepítési kézikönyvvel érkezik ami leírja milyen követelményeket kell kielégíteni a DBMS megfelelő működéséhez. A telepítési útmutató mindig el kell olvasni elejétől a végéig! 8.2 Hardver követelmények Az igényeinknek megfelelő DBMS-t kell választani, és hozzá kell igazítani a hardvert. 8.3 Tárolási követelmények Egy DBMS lemezes tárolót fog használni az indexek és a következő elemek tárolására: – A rendszerkatalógus vagy adatszótár. A DBMS ezeket használja az adatbázisok és a hozzájuk tartozó információk kezelésére és nyomon követésére 9 – Bármilyen más rendszer adatbázisok melyek a DBMS működéséhez

kellenek, például osztott kapcsolatok támogatása vagy kezelő eszközök. – Naplóállományok melyek minden változtatást rögzítenek minden adatbázison. Ezek lehetnek aktív naplók, archív naplók, rollback szegmensek, és minden más változtatást rögzítő naplók. – Indító és vezérlő állományok amelyek a DBMS indításakor szükségesek. – A DBMS által rendezésre használt munkaállományok vagy egyéb feldolgozáshoz szükséges munkaállományok. – A DBMS által használt alapértelmezett adatbázisok rendszer struktúrákhoz vagy gyűjtőhelynek az újonnan létrehozott adatbázis objektumok számára. – A DBMS (vagy az adatbázishoz kapcsolódó alkalmazások) által használt ideiglenes adatbázis struktúrák átmeneti adatok tárolására míg az adott művelet folyik. – Rendszer dump és hiba feldolgozó állományok. – Adminisztrálásra, monitorozásra, hangolásra használt DBA adatbázisok. Ezeket használják új kiadások,

migráló szkriptek és hasonlók tesztelésére Számításba kell venni minden tárolási követelményt és lefoglalni a megfelelő mennyiségű tárhelyet a DBMSnek. 8.4 Memória követelmények A 2-3. ábra bemutatja hogyan használ a DBMS egy buffer pool-nak vagy adatgyorsító tárnak nevezett memória szerkezetet a fizikai I/O kérések csökkentésére. 5. ábra Buffer pool (vagy adatgyorsító tár) Az adatokon kívül a DBMS egyéb struktúrákat is fog gyorsítótárazni a memóriában. A legtöbb DBMS memóriát tartalékol azért, hogy tárolni tudja az adatbázis kérések kiszolgálásához tartozó program struktúrákat. A program gyorsítótár mondjuk lefordított SQL utasításokat, adatbázis authorizációkat, és olyan adatbázis struktúra blokkokat fog tárolni melyeket a programok használtak a futásuk során. 10 8.5 DBMS konfigurálása A rendszerparaméterek beállítása szabályozza azt a módot, ahogyan a DBMS elérheti a DBMS funkciókat

és erőforrásokat. A telepítési folyamat alatt, a telepítő szkriptnek adott bemenetek felhasználásával kerülnek beállításra a rendszerparaméterek kezdeti értékei Minden DBMS biztosít lehetőséget a rendszerparaméterek állítására a DBMS működése után is. Mit szabályoznak a rendszerparaméterek? Irányítják például a DBA authorizációt, az aktív naplók számát, meghatározzák a programok és adatok gyorsítótárazására használható memória mennyiségét, és ki be kapcsolják a DBMS különböző funkcióit. 8.6 A DBMS támogató infrastruktúra szoftverekhez csatlakoztatása Általában a következő infrastrukturális szoftvereket kell a DBMS-sel való együttműködéshez konfigurálni: hálózatok, tranzakciófeldolgozó monitorok, üzenetsorok, különböző típusú middleware-ek (köztes szoftver), programozási nyelvek, rendszerkezelő szoftver, művelet és feladat irányító szoftver, Web szerverek és

alkalmazásszerverek. Konfiguráló eljárások magukban foglalhatják DLL fájlok telepítését, új paraméter fájlok létrehozását kapcsolatok létrehozásához, és a DBMS-sel való kommunikáció biztosításához szükséges szoftver komponensek telepítését. 8.7 Telepítés felülvizsgálata A DBMS telepítése után egy halom tesztet kell futtatni azért, hogy megbizonyosodhassunk a DBMS telepítésének és beállításának helyességéről. A legtöbb DBMS gyártó mintaprogramokat biztosít ehhez Ezen felül a DBMS alapvető interfészeinek mint például az interaktív SQL interfész tesztelésével is megbizonyosodhatunk a telepítés helyességéről. Továbbá tesztelni kell, hogy minden szükséges kapcsolat a támogató szoftverekkel helyesen működik-e. 8.8 DBMS környezetek Az adatbázis fejlesztés érdekében a DBA-nak több DBMS környezetet kell létrehoznia például a tesztelési, minőség ellenőrzési, integrációs és termelési munka

támogatása érdekében. Ez csökkenti a migrációs problémákat és nem igényli bonyolult adatbázis elnevezési konvenciók támogatását. Továbbá az adatbázis példányok elválasztása könnyebbé teszi a tesztelést, hangolást, és monitorozást 9. DBMS kiadások és verziók frissítése A DBA-nak ki kell dolgoznia egy olyan megoldást amivel, úgy frissítheti a DBMS-t, hogy a legkevésbé zavarja meg az üzletet a leállással és az adatbázis elérhetetlenséggel. Egy új DBMS kiadásra frissítés előnyökkel és hátrányokkal is jár. Következzen néhány előny: – Új funkciók és tulajdonságok. Ha a fejlesztéshez szükség van egy új funkcióra, vagy csak profitálhat belőle az csökkentheti a fejlesztési időt és pénzt takarít meg. – Az új alkalmazások igényelhetik az új DBMS verzió funkcióit a teljes működéshez. – Az új DBMS kiadások gyakran hoznak megnövelt teljesítményt és elérhetőséget. – A DBMS gyártók

gyakran szívesebben támogatják az új szoftvereiket. – A termelés új DBMS kiadásra költöztetése a teszt és termelési adatbázis környezet frissítését is maga után vonja, így biztosítva egy konzisztens környezetet a fejlesztéshez és kivitelezéshez. Egy új DBMS kiadásra frissítés hátrányai, kockázatai a következőek: – A DBMS frissítése gyakran megzavarja valamilyen szinten az üzletet. Esetleg le kell állítani az adatbázisrendszert A leállásból fakadóan elveszhetnek üzleti lehetőségek – Egyéb zavart jelenthet az is ha kiderül az új DBMS-ből hiányzik néhány korábbi funkció ami az alkalmazások működésképtelenségéhez vezethet vagy konvertálni kell az adatbázis struktúrákat. 11 – A frissítés magas költsége akadályt jelenthet a DBMS migrációnak. Az új kiadás általában drágább, aztán ott van a DBMS és a hozzá kapcsolódó alkalmazások tervezése, telepítése, tesztelése, a hardver költségek.

– Ha változik az SQL optimalizációs technika az új DBMS-ben előfordulhat, hogy rosszabb teljesítményű SQL elérési utakat fog generálni. Ennek kiderítése rengeteg teszteléssel jár a DBA számára – Hogy kihasználhassa az új DBMS kiadás előnyeit a DBA-nak néhány kellemetlen változtatást is végre kell hajtania. – A támogató szoftverek hiányosak lehetnek az új DBMS kiadásokhoz, amikor azt kiadják. 12 rész III Adatok elérhetősége Ha az adat nem elérhető, az alkalmazások nem képesek futni. Ha az alkalmazások nem tudnak futni, a cég üzletet veszít. Ezért a DBA-nak minden tőle telhetőt meg kell tenni annak érdekében, hogy az adatbázisokat online és működésben tartsa. Egy e-biznisznek elérhetőnek kell lennie a nap 24 órájában, a hét 7 napján és az év 365 napján (366 szökőévekben). 10. Elérhetőség definíciója Egyszerűen fogalmazva az elérhetőség az az állapot amikor megadott erőforráshoz

hozzáférhetnek a fogyasztók. Másik definíció az elérhetőségre: Az időtartam azon százaléka, mely során a rendszer produktív munkára használható. Az adatbázis teljesítmény nem egyenlő az elérhetőséggel. Egy adatbázis akkor is elérhető, ha gyenge a teljesítménye, de egy elérhetetlenhez képtelenség hozzáférni Akkor mikor fordul a gyenge teljesítmény elérhetetlenségbe? Ha a DBMS teljesítménye olyan szinten alacsony, hogy a felhasználó semmilyen célból sem tudja elérni az adatbázist. Az elérhetőség négy különböző komponensből tevődik össze: – Kezelhetőség. A hatékony környezet létrehozásának és fenntartásának képessége, amely szolgáltatásokat nyújt a felhasználóknak. – Helyreállíthatóság. A szolgáltatás helyreállításának képessége – Megbízhatóság. A szolgáltatás nyújtásának képessége meghatározott szinten egy adott időtartamra vonatkozóan – Szervizelhetőség. A fennálló

problémák meghatározásának képessége, azok okainak megállapítása, és a problémák helyreállítása 10.1 Megnövekedett elérhetőségi követelmények Ahogy egyre több üzlet kényszerül teljes elérhetőség biztosítására, és az állásidők költsége nő, az üzlet szempontjából kritikus rendszereken és szoftvereken végezhető teljesítmény optimalizálás ideje csökken. 10.11 Csökkenő karbantartási idő Sok tranzakciót bonyolító adatbázisok folyamatos karbantartást és átszervezést igényelnek. Állandó használat mellett az adatbázisok töredezetté (fragmentált) válnak, az adat elérési utak hatékonysága csökken, és a teljesítmény is csökken. Az adatokat vissza kell rakni szabályos sorozatba; a törlések okozta lyukakat ki kell törölni 10.12 Döntéstámogatás Sok cégnél használják az adatokat üzleti döntések meghozatalára. A DBA-nak ezért nagy adathalmazokat kell bányásznia, szétosztania különböző

adatbázis környezetekbe, és kezelhetővé tennie. Ettől csökkenhet a feldolgozott adatok elérhetősége, hiszen ez alatt azokat nem lehet frissíteni vagy módosítani 10.13 Adattárházak Az adattárházakba való nagy mennyiségű adatmozgatás csökkenti ezen adatok elérhetőségi idejét mindkét oldalon. 13 10.14 Állandó elérhetőség A 24/24 elérhetőség kifejezés a 24/7 helyett kezd elterjedni, mivel a globális elérhetőség miatt az adatokat minden időzónában elérhetik, nem csak abban ahol a DBMS működik. 10.15 Az informatika egyre növekvő összetettsége Nehéz bármilyen méretű céget találni ahol ne heterogén környezetben dolgoznának, amiben van nagyszámítógéptől az asztali rendszerekig minden. A DBMS szoftver maga is hozzájárul a komplexitás növekedéséhez, az új kiadások és fejlesztések nyaktörő sebességgel kerülnek kiadásra. A létszámleépítések miatt az IT specialistának mindenhez kell érteni

kicsit, és így természetesen nem tudják olyan gyorsan és hatékonyan elvégezni a feladataikat. 11. Állásidő költsége Az állásidő megbecslése kapcsán érdemes a költségeket befolyásoló alábbi tényezőket számításba venni: – – – – – Leállás során elvesztett üzlet Annak a költsége, amíg a rendszerben helyreáll a rend miután a rendszerek ismét elérhetőek Perek jogi költsége Csökkent részvényérték hatása A leállás miatt a cégről kialakult negatív sajtóvisszhangból felépülés 11.1 Mennyi elérhetőség elegendő? Elérhetőség hagyományosan a szolgáltatások elérhetőségi idejének a százalékos kifejezése. Gyakran a 99%os elérhetőség is kevés egy rendszernél mivel ez éves szinten 87,6 óra állást jelent Az öt kilences kifejezést gyakran használják a magas rendelkezésre állású rendszerek leírására, ami 99,999%-os elérhetőséget jelent. Másik definíció az elérhetőségre az MTBF

(Mean Time Between Failure - meghibásodások között várható átlagos üzemidő). Egészen pontosan az MTBF jobban jellemzi a megbízhatóságot, mint az elérhetőséget 12. Elérhetőségi problémák Vegyük sorba az elérhetőségi problémák lehetséges okait. 12.1 Adatközpont elvesztése Még azután is, hogy az a adatbázist helyreállítódott, lehetnek elérhetőségi problémák. Például, valószínűleg nem lesz minden adat a legfrissebb, ezért esetleg a DBA-nak és a felhasználóknak újra létre kell hozniuk az adatokat mielőtt mindenkinek engednék a hozzáférést az adatbázisokhoz. A tervezés katasztrófára és egy jó katasztrófaterv kidolgozása csökkentheti az ilyen problémák előfordulását. 12.2 Hálózati problémák Hálózati problémák is okozhatnak adatbázis kimaradást. Ajánlott raktáron tartani hálózati hardverelemeket a hiba gyors kijavításának érdekében. A DBA nem hálózati szakértő ezért nem várható

el, hogy minden hálózati problémát maga oldjon meg. 14 12.3 A szerver hardver elvesztése CPU hibák miatti leállás kiküszöbölésére ajánlott a fürtözést használni. Másik megoldás tartalék rendszer alkalmazása. Az elsődleges szerveren keletkezett adatbázis naplókat vagy adatokat átszállítják/átmásolják a másodlagos szerverre. Alternatív megoldásként szóba jöhet egy az elsődleges szerverrel megegyező konfigurációjú gép fenntartása, hogy hardver hiba esetén fel lehessen használni az alkatrészeit Ha az egész adatbázisszerver elvész vagy megsérül, akkor az adatbázis fájlokat helyre kell állítani a biztonsági másolatokból és az adatbázis naplóban leírt változásokat újra végre kell hajtani. 12.4 Lemezzel összefüggő leállások Lemezhibát sok minden okozhat: A fizikai meghajtó mechanizmus elromolhat, a vezérlő elromolhat, kilazulhat a csatlakozó kábel vagy megsérül. RAID rendszerek segíthetnek, mivel

így sok lemeznek kellene megsérülnie ahhoz, hogy leállást idézzen elő. Másik megoldás az adatbázis SAN-on (Storage Area Network) tárolása. A SAN hálózatba kapcsolt lemezes eszközök csoportja. Egy hibatűrő rendszer mint például egy tartalék adatbázis segíthet csökkenteni a lemezhibákból eredő leállási időt. Egy tartalék adatbázissal csak azok az adatok vesznek el amelyeket nem commit-álták még a hiba bekövetkeztének időpontjában 12.5 Operációs rendszer meghibásodása Az operációs rendszer meghibásodása miatti leállások tipikusan az operációs rendszer instabilitásából adódnak: bugok, verzió frissítés miatti problémák, patch-ek, kisebb javítások okozta problémák. A hiba megoldására kétféle kétféleképpen járhatunk el: az operációs rendszer probléma kijavítása, vagy az adatbázis helyreállítása egy másik, működő szerverre. 12.6 DBMS szoftverhiba 12.7 Alkalmazási problémák Szoftver bugok,

elveszett modulok és függvény könyvtárak a külső programok leállását okozhatják, ennek következtében a felhasználók ugyanúgy nem tudják elérni az adatbázist. Átfogó tesztekkel és minőségbiztosítási eljárások alkalmazásával ezek felmerülése minimalizálható. 12.8 Biztonsági és engedélyezési problémák Biztonsági problémák általában egy program közvetlenül a termelési környezetbe állítása után merülnek fel, engedélyezési problémák pedig mikor egy új felhasználó próbál hozzáférni a rendszerhez aki még nem kapott megfelelő jogosultságokat DBA hibák is okozhatnak biztonsági problémát. 12.9 Sérült adatok Sérült adatok különböző forrásokból kerülhetnek az adatbázisba: külső programok bugjai miatt, rossz adatbázis tervezés, vagy felhasználói hibák. Nagy mennyiségű összegyűlt hiba esetén a DBA-nak le kell állítania az adatbázist, meg kell keresnie a hiba forrását, és megszüntetni

azt. 15 12.10 Adatbázis objektumok elvesztése Figyelmetlenségből drop-olt adatbázis objektumok is okozhatnak elérhetetlenséget. A DBA-nak scriptekből újra el kell készítenie az objektumot, az esetlegesen hozzá kapcsolódó töröltekkel együtt, újra alkalmazni a szükséges megszorításokat, authorizációt és visszatölteni az adatokat ami még fizikailag a lemezeken maradhattak. Index elvesztése esetén az elérhetőség megmarad, viszont általában teljesítmény csökkenést okoz. Nézet elvesztésével az azt használó felhasználók számára elérhetetlen lesz az adat 12.11 Adatvesztés Véletlen törlések, bugok, rosszindulatú támadások stb. okozhatnak adatvesztést A DBA a napló átnézésével a hiba előtti állapotra visszaállíthatja az adatbázist. 12.12 Adatreplikálási és propagálási (terjesztési) hibák Replikálásnál és propagálásnál egy adatbázis Publisher vagy Subscriber szerepet tölthet be. A Subscriber fogadja

a replikált vagy propagált adatokat a Publishertől. Kétféle hiba merülhet fel: – A Subscriber nem kerül konzisztens állapotba mert a Publisher hibásan vagy egyáltalán nem továbbítja az adatokat. – Az adatátviteli folyamat hibásodik meg, a hiba javítása és a szolgáltatás újraindulása után a Publishernek nagy mennyiségű adatot kell küldenie ami lerontja a teljesítményét. 12.13 Súlyos teljesítménybeli problémák A következők közül bármi okozhatja az adatbázis teljesítményének romlását: sérült index, rosszul definiált/megválasztott index, adat növekedés, felhasználók számának növekedése, nem megfelelő adatbázis statisztika, zárolási problémák 12.14 Helyreállítási kérdések Egy cég adatmentési és helyreállítási stratégiája nagy hatással van az adatbázis elérhetőségére. A helyreállíthatóságot befolyásoló tényezők: operációs rendszer konfiguráció, hardver architektúra, adatbázis

szolgáltatások, backup gyakoriság, tapasztalat és jó helyreállítási minták. 12.15 DBA hibák A leállások legnagyobb részét emberi hiba okozza. Nincs olyan módszer ami garantálhatná ezeknek az elkerülését viszont megfelelő DBA tréning és megfelelő eszközök használatával minimalizálható a hibázás kockázata 12.16 Tervezett és nem tervezett leállások Ha leállásról van szó sok szakember egyből nem tervezett leállásokra gondol. Emberi, szoftver és hardver hibák okozta leállásokra. Ám a leállások 70%-a tervezett, csupán 30% ami nem tervezett és tanulmányok szerint a nem tervezett leállási idő 50%-a a tervezett leállások folyamán felmerülő problémákból jön. Mivel a nem tervezett leállások nagy része a tervezett tevékenységekből adódnak, a DBA fontos feladata olyan technikák kifejlesztése amivel a tervezett adatbázis karbantartási műveletek közben minél kevesebb nem tervezett leállást okoz. 13.

Elérhetőség biztosítása IT szervezeteknek szükséges meghatározniuk a kritikus szükségleteiket és implementálni egy sor olyan kulcsfontosságú stratégiai lépést, ami biztosítja az elérhetőséget. A jó stratégia a következőket foglalja magában: 16 – – – – Rutinkarbantartás végzése, mialatt a rendszerek működnek. DBA feladatok automatizálása. A magas elérhetőséget biztosító DBMS eszközök kihasználása. Hardver technológiák kihasználása. 13.1 Rutinkarbantartás végzése, mialatt a rendszerek működnek Vannak olyan segédprogramok amelyek az adatbázis karbantartása alatt is zavartalan hozzáférést engednek az adatbázishoz, és teszik ezt az adatintegritás megőrzése mellett. Azért ne felejtsük el, hogy a legtöbb adatbázis karbantartó művelet kihat az elérhetőségre A következő feladatokra szánt segédprogramok szükségesek a leginkább: – Adatbázis újraszervezése, a teljesítmény fenntartása

végett. – Adatbázis mentése, hogy legyen miből helyreállítani az adatbázist alkalmazás vagy hardver hiba bekövetkezte után. – Adatbázis helyreállítási megoldások, melyek a helyreállított adatokat képesek használni leállás nélkül. – Adatmentési és betöltési folyamatok döntéstámogatási rendszerek és adattárházak számára. – Statisztika gyűjtő segédprogramok az adatbázis-optimalizáló számára. – Integritást ellenőrző segédprogramok a hivatkozási és szerkezeti adatintegritáshoz. 13.2 DBA feladatok automatizálása Az automatizált feladat kevésbé fog tévedni, mintha egy ember csinálja ugyanazt. Minél összetettebb a feladat, annál hasznosabb az automatizáció. Kevesebb idő szükséges a feladat végrehajtásához Biztonsági mentésekhez és helyreállításhoz a legfontosabb eszköz. 13.3 A magas elérhetőséget biztosító eszközök kihasználása Ha a DBMS támogatja a klaszterezést és párhuzamos

technológiákat, akkor érdemes úgy tervezni az adatbázist, hogy képes legyen ezekkel együttműködni. Egyre több DBMS gyártó alakítja úgy a szoftverét, hogy kihasználja a modern operációs rendszerek és hardverek képességeit. A régi rendszereknél a rendszerparaméterek átállításához le kellett állítani az adatbázist 13.4 Klaszter technológia hasznosítása Nagy előnye a fürtözésnek (klaszterezés), hogy növelhető a számítási kapacitás egy új szerver vagy csomópont klaszterbe kapcsolásával. Jól skálázható a rendszer Másik nagy előnye az elérhetőség, mert a hibás csomópontok feladatát a még ép csomópontok automatikusan átveszik és leállás nélkül javítható a hibás csomópont, majd visszakapcsolható a klaszterbe. 17 rész IV Teljesítménykezelés Monitorozni és hangolni kell a teljesítményt. Proaktívan kell hozzáállni Legtöbbször ez nem csak a DBA feladata, hanem a programozóé illetve a többi

rendszeradminisztrátoré is. 14. Teljesítmény definíciója A felhasználók információt kérnek az adatbázistól és a DBMS kielégíti a kérésüket. Azt a sebességet, amellyel a DBMS kielégíti az információkérést nevezzük adatbázis teljesítménynek. Egy sokkal átfogóbb definícióra van szükségünk az adatbázis teljesítmény leírására. Öt tényező befolyásolja az adatbázis teljesítményt: 1) munkaterhelés, 2) áteresztőképesség, 3) optimalizálás, és 4) versengés . – A munkaterhelés online tranzakciók, kötegelt (batch) feladatok, ad hoc (eseti) lekérdezések, adattárház elemzések és rendszerparancsok kombinációja egy időben futtatva a rendszeren – Áteresztőképesség határozza meg a számítógép teljes adatfeldolgozó képességét. Az alábbiakból tevődik össze: I/O sebesség, CPU sebesség, a gép párhuzamos képességei és az operációs rendszer és rendszerszoftver hatékonysága. – A rendelkezésre álló

hardver- és szoftvereszközök adják a rendszer erőforrásait. Ilyen például az adatbázis mag, lemezes tároló egységek, memóriakártyák, gyorsítótár vezérlők, és mikrokód. Minden rendszert lehet optimalizálni, de a relációs adatbázisok különlegessége, hogy főként a DBMS-en belül hajtódik végre a lekérdezések optimalizációja. – Ha egy bizonyos erőforrás iránt nagy az igény, az versengést eredményezhet. Versengés az az állapot amikor két vagy több komponense a munkaterhelésnek ugyanazt az erőforrást próbálja használni egymást hátráltató (konfliktusos) módon. Például ugyanazon adat frissítése két helyről Ahogy a versengés nő, az áteresztőképesség csökken Az adatbázis-teljesítmény az erőforrás használat optimalizáció az áteresztőképesség növelése és a versengés csökkentése érdekében, lehetővé téve a lehető legnagyobb munkaterhelés elbírását. 14.1 Egy alapvető adatbázis

teljesítmény térkép A Pareto-elv szerint az eredmények 80%-a 20% erőfeszítésből származik. Ez adatbázis teljesítmény szempontjából azt jelenti egy okos DBA számára, hogy csak a legnagyobb teljesítmény csökkenést okozó problémára fog koncentrálni. A legtöbb adatbázis alkalmazás teljesítmény problémáját a szakszerűtlen SQL és alkalmazás kód jelenti. Sokféle probléma okozhatja az SQL gyenge teljesítményét és vele az adatbázisét is: – – – – – – – – Tábla átfutások. Amikor a teljes táblát végig kell keresni Megfelelő indexek hiánya. Nem megfelelő indexelés választás. A rendelkezésre álló indexek kihasználatlansága. Elavult adatbázis statisztikák. A táblák összekapcsolása nem optimális sorrendben. Alkalmazás összekapcsolások a hatékonyabb SQL összekapcsolások helyett. Nem megfelelő összekapcsolási metódusok (beágyazott ciklus, összefésülő join (merge scan join) stb.) Hatékony SQL

beágyazva egy nem hatékony alkalmazáskódba. – Nem hatékony allekérdezési formulák (exists, not exists, stb.) – Szükségtelen rendezés (group by, order by, union). Megtalálni a legkevésbé hatékony és így a legköltségesebb SQL utasításokat egy nagy cégnél nagyon nehéz. Erre találták ki az SQL monitorokat, amelyek minden futó SQL utasítást azonosítanak az egész rendszerben. Általában ezek az eszközök osztályozzák az SQL utasításokat erőforrásfelhasználásuk alapján, és visszakeresik ki adta ki és melyik programból. Természetesen egyéb tényezők is befolyásolhatják az adatbázis teljesítményt. Érdemes ezeket is ellenőrizni: 18 – – – – – Memória allokáció (puffer/gyorsítótár az adatnak, SQL, hitelesítés). Naplózási lehetőségek (napló gyorsítótár, napló méret, Oracle rollback szegmens). I/O hatékonyság (külön lemezen a táblák és indexek, adatbázis méret, töredezett és megnövekedett

fájlok). Teljes alkalmazás és adatbázis munkaterhelés a szerveren. Adatbázis séma definíciók. 15. Monitorozás vs. kezelés A teljesítménykezelés különbözik a teljesítménymonitorozástól, mert magában egyesíti a monitorozást egy részletes tervvel a felbukkanó hibák megoldására. Teljesítménykezelés három együttműködő komponensből áll: monitorozás, elemzés és javítás. 6. ábra A teljesítménykezelés komponensei A monitorozás az első komponense a teljesítménykezelésnek. Az alábbi lépésekből áll: a környezet átvizsgálása, eszközök kimenetének áttekintése, és a rendszer futás közbeni megfigyelése A monitorozás a problémák azonosításának folyamata. Elemzés a második komponense a teljesítménykezelésnek. A monitor összegyűjti a megfelelő információkat a teljesítményhangolás és optimalizációs döntésekhez, de alapvetően csak információhalmaz. A monitor nem tud egyedül döntést hozni az

összegyűjtött információk alapján. Ez elemzést kíván, amit többnyire egy jól képzett DBA hajt végre. Optimalizáció vagy javítás a harmadik komponens. Néhány teljesítménykezelő eszköz lehetőséget ad a szakembernek arra, hogy automatizálja egy részét a feladatnak úgy, hogy megadhatja milyen javítást hajtson végre az eszköz, ha egy meghatározott monitor egység valamilyen feltételeket azonosít. Igazi megelőző (proaktív) teljesítmény kezelés eléréséhez a DBA-nak meg kell terveznie a teljesítményét az alkalmazásnak mielőtt az befejezné futását. 15.1 Reaktív vs. proaktív Reaktív teljesítménykezelésre mindig szükség lesz, hiszen nem tervezett teljesítményproblémák mindig elő fognak fordulni. A reaktív teljesítménykezelés magában nem rossz dolog, de kézi és sok időt igénylő folyamat 19 A proaktív teljesítménykezelés egyesíti az előrelátást, tervezés és automatizálást a reaktív

monitorozás és hangolás csökkentése érdekében. 15.2 Teljesítmény becslése a termelésbe kerülés előtt A fejlesztés alatt lesz valamilyen teljesítmény, de a tesztszerveren nincs annyi adat és nem olyanok az erőforrások, mint a termelésin, ennek ellenére a DBA-nak meg kell becsülnie a teljesítményt a termelési rendszeren. Az alkalmazások teljesítményének megbecslése nem csak egyes adatbázis lekérdezések elemzéséből és hangolásából áll. Az egész alkalmazásra ki kell terjedjen, mivel előfordulhat, hogy egy lekérdezés optimalizálása a másik teljesítményét rontja. 15.3 Történeti trendek Erőforrás-használati trendek és teljesítmény statisztikák készítése és elemzése a teljesítménykezelés egyik hasznos eszköze. Történeti teljesítmény és erőforrás trendek lehetővé teszi a DBA-k számára a szükséges hardver fejlesztések megjóslásának idejét jó előre, és segít megérteni az adatbázis,

alkalmazások és rendszerek használatának karakterisztikáját. 16. Szolgáltatás szintű kezelés Szolgáltatás szintű kezelés (Service-level management - SLM) az fegyelmezett, proaktív metodikák (módszerek) és eljárások alkalmazását jelenti, megfelelő szintű szolgáltatások szállításának érdekében az összes IT felhasználó számára, az üzleti érdekeket is figyelembe véve és elérhető áron. A szolgáltatás szintű megállapodás (Service-level agreement - SLA) sikerességéhez, minden résztvevőnek el kell fogadnia az elérhetőségre és teljesítményre megállapított célokat. A végfelhasználók elégedetteknek kell lenniük az alkalmazásaik teljesítményével, és a DBA-k és szakértők lehetőségeikhez mérten biztosítaniuk kell a kitűzött célok megvalósulását. A gyakorlatban sok üzlet nem intézményesíti az SLM-et. Az üzleti felhasználók gyakran szeretnének jobb szolgáltatásokat, de nem veszik a

fáradtságot, hogy priorizálják (fontossági sorrendbe állítsák) a kívánságaikat vagy fizessenek a jobb szolgáltatásért. Ennek okán az IT részleg nehezen tudja teljesíteni az SLA-ban leírtakat, és ez gyakran SLA kihelyezéshez (outsource) vezet. Másik probléma lehet az SLM-mel, hogy milyen kontextusban beszélnek a szolgáltatásról. A legtöbb IT szakember a szolgáltatás rétegeket elemről-elemre alapon szemléli Egy átfogó SLM kialakításához, az IT infrastruktúra különböző részlegeinek hatékony kommunikációra és kooperációra van szüksége. 17. Teljesítményhangolás típusai Az adatbázis alkalmazások hangolása három komponensre bontható: 1) rendszer hangolás, 2) adatbázis hangolás, 3) alkalmazás hangolás . 17.1 Rendszer hangolás A DBMS szoftver telepítésének módja, a memóriája, a lemeze, CPU-ja, egyéb erőforrásai és minden konfigurációs beállítása hatással van az adatbázis alkalmazás teljesítményére. A

többi rendszerszoftver amivel a DBMS kapcsolatban van úgy mint operációs rendszer, hálózati szoftver, üzenet sorbaállítási rendszerek, middleware és tranzakció feldolgozók. Rendszerhangolás magában foglalja a telepítési, beállítási és integrációs (beillesztési) problémák kezelését, és a szoftverek DBMS-hez és adatbázis alkalmazások kapcsolódásának biztosítását. 20 17.2 Adatbázis hangolás A teljesítményt befolyásolhatja az adatbázis fizikai tervezése, úgy mint normalizálás, lemezes tároló, táblák száma, index tervezés, és a DDL (Data Deifnition Language) utasítások és hozzájuk tartozó paraméterek használata. Az adatbázis fájlok fizikai helye a lemezeken az adatokkal dolgozó alkalmazások teljesítményére lesz hatással. Ahogy egyre több adat tárolódik ugyanazon a lemezen, a teljesítmény csökkenés esélye nő 17.3 Alkalmazás hangolás A legtöbb szakértő egyet ért abban, hogy a teljesítmény

problémák 75%-át helytelenül kódolt alkalmazások okozzák. SQL az elsődleges vádlott; hatékony SQL utasítások írása komplikált lehet Azért nem minden alkalmazás problémáért a helytelenül kódolt SQL a felelős. A nyelv, amelyben az alkalmazást írták, és amelybe az SQL-t beágyazták is okozhatja a problémát. 18. Teljesítményhangoló eszközök Adatbázis-hangoló eszközök két nagy kategóriáját különböztetjük meg: teljesítménykezelő és teljesítményoptimalizáló. Sokféle teljesítménykezelő eszköz áll rendelkezésre – Teljesítmény monitorok lehetővé teszik a DBA-k és teljesítményelemzők számára az adatbázissal dolgozó alkalmazások teljesítményének mérését. Három fajta teljesítmény monitor közül választhatnak: – Valós idejű. – Near time (közeli idejű), valamilyen intervallumokra vonatkozhat. – Történeti trendekre alapuló. – A fejlettebb monitorok ügynök alapúak (agent-based). –

Teljesítménybecslő eszközök teljesítménybecslést adnak egész programokra és SQL utasításokra; elérési utakra, műveleti környezetre és szabály vagy következtető motorra alapozva. – Kapacitástervező eszközök lehetővé teszik a DBA-k számára, hogy elemezzék az aktuális környezetet és adatbázis dizájnt és kipróbálhassák a változtatásaik hatását. – SQL elemző és hangoló eszközök grafikus és/vagy szöveges leírást adnak a relációs optimalizáló által meghatározott lekérdezés elérési utakról. Ezekkel az eszközökkel önálló SQL kifejezéseket vagy egész programokat is lehet vizsgálni. – Tanácsadó eszközök növelik az SQL elemző és hangoló eszközök teljesítményét azáltal, hogy tudásbázist szolgáltatnak, ami tippeket ad az SQL utasítások újraformálásához az optimális teljesítmény elérésének érdekében. Fejlettebb eszközök ezt akár automatikusan is (ha igény van rá) elvégezhetik –

Rendszerelemző és hangoló eszközök lehetővé teszik a DBA számára, hogy grafikus felületen változtassák az adatbázis és rendszer paramétereket. Teljesítményoptimalizáló eszközök: – Újraszervező eszközök automatizálják az optimálisan rendezett adatbázisok újraépítésének folyamatát. Az adatbázisok okozhatnak teljesítmény problémákat a belső szervezésük miatt (pl.: töredezettség, sor elrendezés, helyfoglalás). – Tömörítő eszközök lehetővé teszik a DBA számára az adatbázisok által használt tárhelye csökkentését így csökkentve a lemezhasználatot és talán a lekérdezés/programfutási időt is, mivel kevesebb I/O szükséges. (Vigyázat: A tömörítő eszközök megnövelhetik a CPU használatot!) – Rendező eszközök segítségével az adatok adatbázisba való betöltésük előtt rendezhetőek, hogy a sorok előre meghatározott sorrendje biztosítva legyen. Ezen felül a rendező eszközök

használhatóak az ORDER BY és GROUP BY SQl utasítások helyett. 21 rész V Rendszerteljesítmény A poorly performing system can degrade the performance of all databases and applications deployed on that system. The system comprises the hardware and software required for the DBMS to operate and for applications to access databases using the DBMS. 19. A nagyobb környezet A DBMS operates within the context of a much larger environment that consists of other software and hardware components. Each of these components must be installed, configured, and managed effectively for the DBMS to function as required. 19.1 Interaction with the Operating System To help ensure an optimal operating system for your database applications, the DBA should ask the following questions. – Has a sufficient amount of memory been allocated for operating system tasks? – Most operating systems have the capability of allocating a specific amount of disk space as a swap area. The swap area is

used when the OS runs out of memory. Has a sufficient amount of disk space been allocated to the swap area? – How were the database files allocated when the database was implemented? Interaction with the file system can cause some operating systems to create additional overhead. By changing the database files to use raw disk, OS and file system overhead can be eliminated. (Additional information on raw disk usage can be found in Chapter 17.) – Some operating systems allow the administrator to set the priority of tasks that run under the auspices of the OS. Has each database-related task been assigned a priority? Is the priority appropriate for that specific task? – Is the operating system at the version and release level recommended by the DBMS vendor? Have any bug fixes been shipped for the OS that are applicable for the particular brand of database server you are running? – Have the operating system configuration parameters been modified when installing the DBMS? If so, has

sufficient testing been done to ensure that the parameters were modified correctly and do not impact any other processes that run on the database server? 19.2 Allied Agents The DBMS has to ally itself with many other software components to deliver service to the end user. Examples of allied agent software include – – – – – Transaction processors like CICS and Microsoft Transaction Server Networking software such as TCP/IP and SNA Message queueing software such as MQSeries and MSMQ Web connectivity and development software such as ColdFusion Programming languages such as Java, COBOL, and C Each of these allied agents needs to be configured properly to interact with the DBMS. 19.3 Hardware Configuration The hardware must be installed and set up properly for the DBMS to operate efficiently. Again, here are some questions the DBA should ask to assure an optimal hardware environment for the database applications. 22 – Is the computer hardware and capacity

appropriate for the DBMS environment? In other words, does the DBMS vendor recommend this particular hardware implementation? – Is the computer firmware (e.g, ROM BIOS) up-to-date? – Has a sufficient amount of memory been installed for all of the system software to be installed (OS, DBMS, and other allied agents)? – Has an appropriate amount of disk storage space been allocated and configured for use by the DBMS? • What type of disk storage is being used and is it appropriate for large data volumes and high-speed database queries? – Are all the network cables connected and functioning properly? – Are all physical connections (e.g, cables, plugs, and board sockets) fully connected and operational? – Is the hardware connected to an uninterruptible power supply? – Is the hardware connected to a surge protection device? 19.31 Disk Storage and I/O One of the biggest bottlenecks for database performance is the physical cost of performing I/O operations. Anything that can be

done to reduce I/O time can enhance performance. A consideration for optimizing disk access is to utilize solid state devices. Consider placing database objects with high performance requirements on solid state devices instead of physical disk drives, RAID devices, or storage area networks. However, implementing solid state devices has some potential problems. The first is cost The second potential problem is that some solid state devices require a constant supply of power to prevent the data from being erased. 19.4 Components of the DBMS The DBA must become an expert on the inner workings of the DBMS in order to ensure an optimized environment for database applications. A failure or problem in any single component of the DBMS can cause severe performance degradation for every application accessing the database. 20. DBMS telepítési és beállítási problémák Every database management system provides parameters that allow the DBA to configure various aspects of the database

environment. Default values are usually not sufficient to support the development of robust, production applications. 20.1 Types of Configuration The DBMS can be configured when the DBMS is installed or after the DBMS is operational. Once the DBMS is installed and operational, the DBMS will provide a method of changing the configuration parameters. Depending on the DBMS, parameters may be changed dynamically, nondynamically, or both Dynamic parameters can take effect without the need to restart SQL Server. Executing the RECONFIGURE command causes dynamic parameters to immediately take effect. After issuing the appropriate commands, the parameter value changes and the DBMS will behave accordingly. In order for nondynamic parameters to take effect, the DBMS must be shut down and restarted. Of course, the parameter value must be changedusually in the same or a similar manner as a dynamic parameter. However, a nondynamic parameter will not take effect until the DBMS is restarted. 20.2

Memory Usage A DBMS-ek imádják a memóriát. Minden féle gyorsítótárat (puffer) használnak, hogy az adatbázis erőforrások (data pages, query plans etc) minél tovább a memóriában maradjanak Ezzel csökken az I/O és javul a 23 teljesítmény. A data cache is used to avoid I/O operations when actual data is being read from the database. When a program needs a row from a table, the DBMS retrieves the page from disk and stores the page in the data cache. Basically, the DBMS uses the cache as a staging area. If the row changes, the change is written to the page in the data cache Eventually, the DBMS will write the page in the data cache back to disk. When data needed by an application is on a page already in the data cache, the application will not have to wait for the page to be retrieved from disk. A procedure cache stores SQL and program-related structures. Before SQL statements can be issued to retrieve or modify data, the statement must first be optimized by the

DBMS. The optimization process creates an internal structure representing the access path that will be used by the DBMS to read the data. The DBMS can store these access paths in the procedure cache and reuse them each time the program or SQL statement is run. This optimizes application performance because optimization occurs the first time the SQL is issued, and subsequent executions retrieve the access path from the procedure cache. The sort cache is used instead of temporary disk storage to store intermediate sort results in memory. The more sorting functionality that can be performed in memory, the better a sort will perform. The DBMS may also use other internal structure caches. To accomplish relational operations, the DBMS may need to create internal structures that are not necessarily visible to the end user. However, DBAs, and sometimes programmers, will need to know about the internal structures. The DBMS also may buffer log records to a separate database log cache.

Furthermore, the DBMS may implement two log caches, one for log writes and one for log reads The database log keeps a record of all changes made to the database. The log write cache is used to speed up database modifications The changed data is written to the log cache, and over time the cache is written asynchronously to disk. By buffering log writes in this way, the database log becomes less of a bottleneck to system and application performance. The log read cache is used for ROLLBACK and RECOVER operations. 20.21 Additional Areas of Memory Consumption Some of the more common areas of DBMS memory consumption include – User connections. Each concurrent user connection to the DBMS, regardless of the type of client connection, requires memory for the DBMS to maintain and manage the connection. – Devices. The devices used by databases may require system memory to maintain and use – Open databases. Most DBMSs provide a parameter to specify the maximum number of databases that can

be open at any one time. Each open database requires DBMS memory – Open objects. Another parameter may exist to identify the maximum number of database objects that can be open at any one time, including tables, indexes, and any other database object in use. Each open database object requires memory. – Locks. Each concurrently held lock will require memory The DBMS should provide a configuration parameter for the number of concurrent locks that can be held at one time – Caches. The various caches are discussed in the previous section 20.3 Data Cache Details At any given point in time, the data cache will consist of three different types of pages: – In-use pages pages that are currently being read and updated by the DBMS. These pages are not available to be used for other database processing. – Updated pages pages where data has been modified in some way, but the data has not yet been written to disk. These pages are not available to be used for other database processing

– Available pages pages not being used. These pages are available to be used for other database processing New data can be written to available pages in the data cache. If unavailable pages dominate the data cache, the DBMS may trigger synchronous writes to increase the space in the data cache. Synchronous writes can slow down database processing because each write request has to wait for the data to be actually physically written to disk. 24 20.31 Monitoring and Tuning the Data Cache Ensuring the cache is the proper size is one of the most critical aspects of having an efficient data cache. A data cache that is too large wastes memory and can cause pages in the cache to be moved out to auxiliary storage. A data cache that is too small forces frequent writes to disk and, in the most severe cases, results in swapping the data cache pages back and forth from disk. The read efficiency of the data cache is a percentage that tracks how well the cache is performing its primary

dutyto avoid physical disk I/O operations. The read efficiency of each data cache is calculated as In other words, read efficiency shows the percentage of times a data page is found in the data cache (or buffer pool). As a rule of thumb, an 80% or better read efficiency is good for a data cache. Of course, the read efficiency value will depend on the type of processing. Many sequential processes can cause the data cache to be overrun and the efficiency to drop. When read efficiency is consistently below 80%, consider tuning by increasing the size of the data cache or reducing the number of tables and indexes assigned to the data cache. Depending on the DBMS, the DBA may be able to configure the data cache better by changing the amount of cache reserved for sequential and parallel operations. Large table scans can quickly monopolize a data cache By reserving only a subset of the entire cache for sequential scans, the overall performance of the data cache may be improved. Additional

possibilities for tuning the data cache include creating an additional cache to back up the data, pegging specific pages in memory, and automatically growing the size of the data cache as throughput increases. 20.32 Monitoring and Tuning the Procedure Cache The purpose of procedure cache generaly is to keep optimized SQL structures in memory so that they can be reused by subsequent tasks instead of being reformulated or reread from disk. To ensure optimal performance, the procedure cache must be sized properly to accommodate all the SQL that may be run concurrently. The read-efficiency calculation we used for gauging the effectiveness of the data cache can be used for the procedure cache also. In the case of the procedure cache, the read efficiency calculates how often the DBMS needs to reoptimize SQL. Procedure cache read efficiency usually ranges from 60% to 80% 20.4 "Open" Database Objects As database applications process, the DBMS will need to open database objects

for access and maintain the open objects. However, each open database object consumes memory Therefore, it is a good idea to temper this value, taking into account the size of the database implementation, the type of application processing, and the amount of memory available. 20.5 Database Logs All changes to application data in the database are recorded serially in the database log (or transaction log). Using this information, the DBMS can track which transaction made which changes to the database. Furthermore, ROLLBACK and RECOVER operations utilize the database log to reset the database to a particular point in time. Some DBMSs provide a parameter to enable and disable logging, but it is not recommended. Because each database change is logged, the DBA will need to monitor actively the size of the transaction log files. And since data is constantly changing, the log will be continually growing The database transaction log is a write-ahead log. This means that changes are made to

the transaction log before they are made to the data in the database tables. When the database modification has been fully recorded on the log, recovery of the transaction is guaranteed. 25 Typically, the DBMS takes a system checkpoint to guarantee that all log records and all modified database pages are written safely to disk. The frequency of database system checkpoints can be set up by the DBA using database configuration parameters. Checkpoint frequency is usually set as either a predetermined time interval or a preset number of log records written. The transaction log is used when the DBMS is restarted, when transactions are rolled back, and to restore a database to a prior state. Let’s examine each of these scenarios During restart processing, the DBMS will check to determine which transactions must be rolled forward. This occurs for transactions where it is unknown if all the modifications were actually written from the cache to disk. When a transaction is rolled back,

the DBMS copies "before" images to the database of every modification made since the transaction began. During a recovery scenario, the DBA can use the transaction log to restore a database. First, a backup copy of the database is restored and then subsequent transaction log backups can be restored. This causes a roll forward of the transaction log. 20.51 Database Log Configuration Considerations Defining output buffers for the database log can optimize log write operations. Writing log records to memory instead of directly to disk creates more efficient database processing. The DBMS can write log records asynchronously from the output buffer to the physical log file later Defining input buffers for the database log can optimize operationssuch as ROLLBACK and RECOVERthat read the database log. When configuring the database log, it is a good idea to set up dual logs. With dual logs, the DBMS will log changes to two separate and independent log files. Implementing dual

logging provides a redundant log for use in case one of the logs fails. Be sure to define each log on separate devices and on separate controllers to minimize the possibility of both logs failing at the same time. Another log configuration detail is deciding how database logs are to be handled when they fill up. Log offloading is the process of archiving an active log to an archival log and switching log writes to a new active log. Napló kimentést definiálni. Archiválás: Az aktív naplót archív naplóba menti Az aktív naplót csak úgy tudom kimenteni, ha nem használja senki, így át kell kapcsolnom a naplózást egy új aktív naplóba. 20.52 Are All Database Operations Logged? Depending on the DBMS, certain situations and commands may not be logged. To avoid "out of space" conditions caused by rapid growth in transaction log files, the DBMS may turn off logging During some large operations, such as CREATE INDEX, the DBMS will probably not log every new page.

Instead, the DBMS will record enough information in the database log to determine that a CREATE INDEX happened, so that it can either be recreated during a roll forward, or removed during a rollback. Keep in mind that whenever logging is turned off, the data must be backed up both before and after the nonlogged process to ensure point-in-time recoverability. 20.6 Locking and Contention Database processing relies on locking to ensure consistent data based on user requirements and to avoid losing data during updates. You must balance the need for concurrency with the need for performance If at all possible, seek to minimize the following situations. – Lock suspensions occur when an application process requests a lock that is already held by another application process and cannot be shared. The suspended process temporarily stops running until the requested lock becomes available. – Timeouts occur when an application process is terminated because it has been suspended for longer

than a preset interval. This interval can usually be set by using a configuration parameter 26 – Deadlocks occur when two or more application processes hold locks on resources that the others need and without which they cannot proceed. The deadlock detection cyclethat is the time interval between checking for deadlockscan also be set by using a configuration parameter. 20.7 The System Catalog The physical location and setup of the system catalog will have an impact on system performance. The DBA must decide where it will be installed, on what type of disk, and how much space to allocate. These decisions typically are made at installation time. As a rule of thumb, place the system catalog on a separate disk device so that it can be managed and tuned independently from other application data. 20.8 Other Configuration Options Every DBMS will have many configuration and tuning options that are particular to that DBMS. Some example configuration options that may be encountered

include – Nested trigger calls. Some DBMSs can enable and disable nested trigger calls A nested trigger call is when one trigger causes another trigger to fire. Some DBMSs may provide additional control over trigger nesting by providing a maximum value for it. By setting this value, the DBA can control how many levels of nested trigger calls are allowable. Control over triggers can have an enormous impact on performance For example, if an application hits the maximum number of nested triggers, all of the changes caused by all previous triggers need to be rolled backpotentially causing considerable performance degradation. – Security options. The functionality of security and authorization can be controlled by DBMS configuration options. Some DBMSs allow database security to be turned over to external security and control software – Identity values. The identity property can be assigned to a column such that the DBMS automatically assigns numerically sequential values when data is

inserted into the table. The DBMS can allow the configuration of the pool size from which identity values are obtained. – Distributed database. To configure a distributed database implementation, the DBMS most likely will provide options for connecting databases at various locations. 21. Rendszermonitorozás A DBMS environment should be continually monitored for performance degradation and problems. Performance monitors are available for every aspect of the system environment, not just the DBMS. So you may be able to monitor the operating system, network, transaction server, and any other system middleware for performance problems. A DBA must be able to operate and understand the output of the monitoring solutions available to him. 27 rész VI Adatbázis-teljesítmény Az adatbázis teljesítmény az adatbázis objektumok, különösen a táblák és indexek és persze az állományok melyekben ezek adatai tárolódnak tervezésének, paramétereinek és fizikai

szerkezetének hangolására és optimalizálására koncentrál. Semennyi SQL hangolás sem képes optimalizálni egy rosszul tervezett adatbázison végrehajtott lekérdezések teljesítményét. 22. Adatbázis optimalizáló technikák A következő technikák mindegyike használható adatbázis teljesítményhangolásra és bővebb tárgyalásra kerül a következő fejezetekben: – Particionálás, szétszedni egy adatbázis táblát több fájlban tárolt darabokra. – Raw partíció vagy állományrendszer, eldönteni az adatbázis adatok OS vezérelt állományokban tárolódjanak vagy nem. – Indexelés, kiválasztani a megfelelő indexeket és beállításokat hatékony lekérdezések lehetővé tételéhez. – Denormalizáció, eltérni a logikai tervtől jobb lekérdezés teljesítmény elérésének érdekében. – Klaszterezés, adatok fizikai sorrendjének kikényszerítése a lemezen. – Illesztett (interleaving) adatok, különböző táblákból

származó adatok egy sorba rendezett fájlba rendezése. – Szabad hely, elég hely hagyása a növekvő adatoknak. – Tömörítés, algoritmikusan csökkenteni a tárhely igényeket. – Állomány elhelyezés és allokáció, a megfelelő fájlok megfelelő helyre rakása. – Lapméret, megfelelő lapméret használata a hatékony adattárolás és I/O érdekében. – Újraszervezés, eredménytelenség eltávolítása az adatbázisból az adatbázis objektumok átszerkesztésével és átrendezésével. 22.1 Particionálás Egy adatbázis tábla egy logikai manifesztációja egy csoport adatnak melyek fizikailag külön tárolón helyezkednek el. A döntések egyike melyet a DBA-nak minden táblánál meg kell hoznia, hogyan tárolja azok adatait A DBA a következő leképezési lehetőségek közül választhat: – Egy tábla egy fájlba. Ez a leggyakoribb választás Az adat a fájlban formázott így a DBMS érti a tábla szerkezetet és minden a táblába

beszúrt sor ugyanabban a fájlban tárolódik. Ennek ellenére ez a beállítás nem feltétlenül a leghatékonyabb. – Egy tábla több fájlba. Ez a megoldás leggyakrabban nagyon nagy táblák vagy tárolási szinten fizikailag szétválasztani kívánt tábla adatok esetén használatos. A több fájlba leképezés partíciós táblák vagy lemez eszköz szegmensek segítségével valósítható meg. – Több tábla egy fájlba. Ez a fajta leképezés kis tábláknál használatos úgy, mint indextáblák, kódtáblák és lemezfelhasználás szempontjából lehet hatékony. A particionálás elősegíti a párhuzamosítás megvalósítását. Párhuzamosítás több az adatbázist párhuzamos módon elérő feladat felhasználását jelenti 22.2 Raw Partition vs. File System A raw partíció a kedveltebb fajta adatbázis tárolás céljából, mert az operációs rendszer gyorsítótárazza az írási műveleteket és így a DBMS nem tudja, hogy az adat ténylegesen a

lemezre íródott-e. Ha a DBMS gyorsítótár kezelő megpróbál adatot írni a lemezre, az operációs rendszer késleltetheti az írást, mert az adat még mindig a fájlrendszer gyorsítótárban lehet. 28 Ha nyers partíciót használunk, az adat az adatbázis gyorsítótárból közvetlenül a lemezre íródik fájlrendszer vagy operációs rendszer gyorsítótár közbeiktatása nélkül. Továbbá, ha nyers partíciót használunk a DBMS elég helyet fog biztosítani és kiírja az allokációs lapokat. 22.3 Indexing 22.31 When to Avoid Indexing 22.32 Index Overloading 22.4 Denormalizáció A normalizáció ellentéte. Egy adatot redundánsan tárol Ez gyorsítja az adat visszakeresést az adatmódosítás terhére. Érdemes figyelembe venni az alábbi lehetőségeket: – – – – – – – – – – Előre összekapcsolt táblák, ha az összekapcsolás költséges. Jelentés (riport) tábla, ha specializált kritikus jelentések generálása túl

költséges Tükör tábla, ha a táblákra két különböző típusú környezetnek konkurens módon van szüksége. Osztott táblák, ha különálló csoportok különböző részeit használják a táblának. Kombinált tábla, 1-1 vagy 1-N kapcsolatokat egy táblába egyessít. Gyorsító tábla, a hierarchiák támogatására, mint pl. hierarchikus alkatrészlisták Fizikai denormalizáció, kihasználni a speciális DBMS jellemzőket. Redundáns adatok tárolása táblákban, hogy csökkentsük a szükséges tábla összekapcsolások számát. Az ismétlődő csoportok egy sorba tárolása, hogy csökkentsük az I/O-t és a szükséges lemezterületet. Származtatott adatok tárolása, a számítások, és a költséges algoritmusok elkerülésére. 22.5 Klaszterezés Egy klaszterezett tábla a sorait fizikailag a lemezen egy megadott oszlop vagy oszlopok szerinti sorrendben fogja tárolni. A klaszterező index az indexelt oszlopok szerinti növekvő sorrendbe

kényszeríti a táblasorok tárolását Csak egy klaszterező index lehet táblánként (mivel fizikailag az adat csak egyféle sorrendben tárolható). A klaszterezés megnöveli azon lekérdezések teljesítményét, melyek szekvenciálisan (egymást követően) férnek az adatokhoz, mert így kevesebb I/O művelet kell ugyanazon adat bekéréséhez. DBMS-től függően az adatok nem mindig kezelhetőek fizikailag pontos klaszterező sorozatban. Ha egy klasztert definiálunk egy táblához, a DBMS a következő két mód közül valamelyikkel fogja a klaszterezést kikényszeríteni: – Ha új sorokat szúrunk be, a DBMS fizikailag áthelyezi az adatsorokat és lapokat, hogy az új sorokat a meghatározott klaszterbe illeszthesse; vagy – A DBMS megpróbálja a meghatározott klaszterbe tenni az adatot, de ha nincs hely a kívánt lapon, akkor elteszi máshova. Ha a DBMS a második forgatókönyv szerint működik, akkor az adatok nem lesznek klaszterezettek idővel és

újraszervezést igényelnek. Klaszterezett indexek jól támogatják a terjedelmes hozzáféréseket, míg a nem klaszterezett indexek jobban támogatják a véletlen hozzáféréseket. A klaszterezés nem ajánlott elsődleges kulcsú oszlopoknak, mert az elsődleges kulcs definíció szerint egyedi. 22.51 Laposztás Ha a beszúrásoknak nincs hely, akkor a DBMS-nek új lapot kell létrehoznia az adatbázison belül, hogy tárolni tudja az új adatokat. Azt az eljárást, ami új lapokat hoz létre a beszúrni kívánt adatok tárolásának érdekében laposztásnak nevezik. A DBMS kétféle laposztást tud végrehajtani: normál laposztást és monoton laposztást 29 7. ábra Klaszterezett és nem klaszterezett indexek Néhány DBMS támogatja mindkettőt, néhány csak az egyiket. A DBA-nak tudnia kell a DBMS melyik laposztást használja, hogy megfelelően optimalizálni tudja az adatbázist. A 6-2. ábra bemutatja a normál laposztást Ennek megvalósításához a DBMS

a következő feladatokat hajtja végre sorban: – Létrehoz egy új üres lapot a megtelt lap és a következő lap között. – A megtelt lap bejegyzéseinek felét átmozgatja az üres lapra. – Beállít minden belső mutatót mindkét lapra és megfelelően beszúrja a sorokat. 8. ábra Normál laposztás A monoton laposztás jóval egyszerűbb folyamat. A DBMS – Létrehoz egy új, üres lapot a megtelt lap és a következő lap között. – Beszúrja az új értékeket az új lapba. A monoton laposztás akkor hasznos, ha a sorok szigorúan sorban kerülnek beszúrásra. Általában egy DBMS amelyik támogatja a monoton laposztást akkor fogja segítségül hívni ha egy új sort adnak a lap végéhez és az utolsó hozzáadás is a lap végéhez történt. 30 Ha növekvő sorrendű sorokat szúrunk be, akkor sok hely mehet kárba, mert félig telt oldalakat hoz létre a DBMS. 22.6 Illesztett (interleaving) adatok Ha két tábla adatait gyakran

összekapcsoljuk, akkor fizikailag érdemes egy helyre rakni őket. Illesztést a klaszterezés egy speciális formájának is tekinthetjük 22.7 Szabad hely A szabad hely felhasználható arra, hogy egy táblatér vagy index egy részét üresen hagyjuk újabb adatok tárolásának céljából. Minden DBMS kínál módszert szabad hely meghatározására CREATE és ALTER utasításokban Egy tipikus paraméter a PCTFREE, ahol a DBA meghatározhatja hány százaléka maradjon üresen az egyes adatlapoknak jövőbeni beszúrások számára. Elegendő hely hagyása minden adatbázis objektum számára a következő előnyökkel jár: – A beszúrások gyorsabbak, ha van szabad hely. – Az újonnan beszúrt sorok megfelelően klaszterezhetőek. – Változó hosszúságú sorok és megváltoztatott sorok növekedhetnek, így csökken az újrafoglalások (re-allokációk) száma. – Kevesebb sor egy lapon jobb konkurenciát eredményez, mert kevesebb adat elérhetetlen más

felhasználók számára, ha a lap zárolva van. Azért a szabad helynek van néhány hátránya is: – – – – Lemeztárolási követelmények nagyobbak. Keresések tovább tartanak. Ha a lapon kevesebb sor van, akkor több I/O műveletre lehet szükség, hogy megkapjuk a kért információt. Mivel a sorok száma laponként kevesebb, az adat gyorsítótárazás hatékonysága csökkenhet, mert kevesebb sor töltődik be I/O-nként. A DBA-nak monitoroznia kell a szabad helyet és biztosítani elegendő szabad helyet minden adatbázis objektum számára. A szabad hely megfelelő mennyisége a következőkre kell alapuljon: – – – – – Beszúrások és változtatások gyakorisága. A soros elérések száma a véletlenekkel szemben. A nem klaszterezett adatok elérésének hatása. A folyamat típusa. Sorláncolás, sorköltöztetés és sortörés valószínűsége. 22.8 Tömörítés A tömörítéssel csökkenthető az adatbázis mérete, így az kevesebb

lemezterületet foglal, de nő a CPU terhelés a csomagoló algoritmusok miatt. Miért használják mégis? Mert az I/O lap szinten megy végbe, és egy I/O így több adatot képes kinyerni, ami optimalizálja a soros adateléréseket és növeli az esélyét annak, hogy a kívánt adat a gyorsítótárban lesz. 22.9 Állományelhelyezés és allokáció A DBA-nak mindent meg kell tennie a fizikai lemez olvasás és írás költségének csökkentése érdekében. Az első tényező, amit figyelembe vehet az állomány elhelyezéskor, hogy külön tárolja az indexeket az adatoktól, ha lehetséges. Ha egy utasítás egyazon lemezen lévő fájlokból olvas adatokat, lappangás léphet fel; egy fájlból olvasásnak várnia kell, míg a másik fájlból olvasás be nem fejeződik. A fájl elhelyezés másik szabálya, hogy elemezni kell az alkalmazások hozzáférési mintáit és a gyakran lekérdezett táblák fájljait külön lemezre kell tenni. 31 Az utolsó

megfontolás, amit érdemes figyelembe venni, hogy a több fájlban tárolt táblák állományait külön lemezekre helyezzük, ezzel elősegítve a párhuzamos hozzáférést. 22.91 Adatbázis napló elhelyezése A tranzakciós napló külön lemezen tárolása a tényleges adatoktól lehetővé teszi a DBA számára, hogy a tranzakciós naplókat az adatbázistól függetlenül mentse. Ez csökkenti a kettős lemezre írást egyazon lemezre 22.92 Megosztott adat elhelyezése A megosztott adat elhelyezés célja az alkalmazás teljesítmény optimalizálása a hálózati továbbítás költségének csökkentésével. Az adatot azon az adatbázis szerveren érdemes tárolni ahová a leginkább való vagy ahonnan a leggyakrabban hozzáférnek. 22.93 Lemezfoglalás A DBMS-nek lemezek foglalására lehet szüksége. Erre az esetre a DBMS a lemezek inicializálására szolgáló parancsokat kínál. A lemezinicializáló parancs logikai nevet fog rendelni egy lemez partícióhoz

vagy OS állományhoz Azután hogy a lemez inicializálásra került, a rendszerkatalógusba kerül és felhasználható táblaadat tárolásra. Érdemes beszédes eszközneveket használni a lemez eszközök hatékony kezelése érdekében. 22.10 Lapméret (Blokkméret) A legtöbb DBMS lehetőséget biztosít a lap- vagy blokkméret beállítására. A lapméretet táblasorok (vagy még pontosabban, rekordok, amik a sor tartalmát és némi többletinformációt tartalmaznak) lemezen tárolására használják. A megfelelő lapméret kiválasztása fontos DBA feladat az adatbázis I/O optimalizáció szempontjából. 23. Adatbázis újraszervezés Ha a fizikai allokáció szétszórttá válik, akkor újraszervezésre van szükség. Lehet csak táblateret vagy indexet újraszervezni. 32 rész VII Alkalmazásteljesítmény 24. Alkalmazások tervezése relációs eléréshez 25. Relációs optimalizáció 26. Egyéb optimalizációs nézőpontok 27. Elérési utak

áttekintése 28. SQL kódolás és hangolás a hatékonyságért 33 rész VIII Adatbázis biztonság Minden erőforrást a DBMS kezel. Ezért egy felhasználó, aki bármilyen DBMS feladatot vagy műveletet végrehajthat, arra a következő állítások közül valamelyiknek teljesülnie kell: – A felhasználó fel lett jogosítva arra, hogy elvégezhesse azt a feladatot vagy műveletet. – Az a művelet vagy feladat minden felhasználó számára engedélyezett. Azt hogy kinek milyen joga van repository-ban érdemes tárolni. 29. Adatbázis biztonság alapok Biztonsági politika kell egy cégnél! A jelszót bizonyos időközönként meg kell változtatni, ezt ki lehet kényszeríteni. Azokat a felhasználókat akik nem cserélik le a jelszavukat, ki lehet zárni a rendszerből míg nem szólnak Ha egy DBMS felhasználónak nincs szüksége többé hozzáférésre a DBMS-hez, vagy elhagyja a céget, a DBAnak ki kell törölnie a belépési azonosítóját amilyen

gyorsan csak lehet. A DBA-kra kell korlátozni azon adatbázis felhasználók számát, akik létrehozhatnak adatbázis objektumokat. Egy bejelentkezési azonosító zárolása meggátolja a felhasználó hozzáférését a DBMS-hez, de nem törli a rendszerből. Néhány DBMS a jelszavakhoz beállítható paramétereket biztosít a következők korlátozására: – – – – Hibás bejelentkezési próbálkozások száma, mielőtt a fiók zárolásra kerül. Napok száma amíg a jelszó érvényes, türelmi idő egy lejárt jelszó megváltoztatására. Napok száma, amíg az account zárolva marad, ha a jelszó lejárt. jelszó újrahasználhatósága (napok száma mielőtt a jelszó újra felhasználható és a maximális száma az újrafelhasználhatóságnak). – Minimális hosszúság, ill. alfanumerikus követelmények 30. Jogok adása és visszavonása DCL (Data Control Language) utasításokat használnak arra, hogy szabályozzák melyik felhasználónak mely

objektumokhoz és parancsokhoz van hozzáférési joga. DCL utasítások két alaptípusból állnak: – GRANT engedélyt rendel egy adatbázis felhasználóhoz. – REVOKE elvesz egy engedélyt egy adatbázis felhasználótól. Ahhoz, hogy egy felhasználó használhassa a GRANT utasítást az adatbázis objektum tulajdonosának kell lennie, vagy WITH GRANT OPTION-nel kellett jogot kapjon. A WITH GRANT OPTION lehetővé teszi a felhasználók számára, hogy továbbadják a jogaikat más felhasználóknak. Általában ezen záradék használata attól függ, hogy központi vagy nem központi a jogok adminisztrációja – Nem központi adminisztrációt általában könnyebb létrehozni, de nehezebb kézben tartani. Ahogy egyre több felhasználó kap jogosultságot ahhoz, hogy jogokat osszon, a jogosultság hatóköre úgy szélesedik és válik kezelhetetlenné. – Központi adminisztrációt könnyebb kezelni, de nagyon leterheli a központi adminisztrátort, mint egyedüli jog

osztót a környezetben. Kerülni kell a GRANT és REVOKE utasítások alkalmazásbeli használatát. 30.1 Jogok típusai Általában a következő jogokat biztosítják a modern DBMS-ek: 34 – – – – – Tábla: szabályozni ki férhet hozzá és módosíthat adatokat a táblákon belül. Adatbázis objektum: szabályozni ki hozhat létre új adatbázis objektumokat és törölhet meglévőket. Rendszer: szabályozni ki hajthat végre rendszerszintű tevékenységeket. Program: szabályozni ki hozhat létre, módosíthat és használhat adatbázis programokat. Tárolt eljárások: szabályozni ki futtathat meghatározott függvényeket és tárolt eljárásokat. 30.11 Tábla jogok adása Tábla jogok képessé teszik a felhasználókat táblák, nézetek és táblákon és nézeteken belüli oszlopok elérésére. A következő jogokat lehet kiosztani táblákra és nézetekre: – – – – – SELECT: lehetővé tenni a felhasználónak, hogy

táblából/nézetből lekérdezhessen. INSERT: lehetővé tenni a felhasználónak, hogy táblába/nézetbe beszúrhasson sorokat. UPDATE: lehetővé tenni a felhasználónak, hogy táblát/nézetet frissítsen. DELETE: lehetővé tenni a felhasználónak, hogy táblából/nézetből sorokat töröljön. ALL: lehetővé tenni a felhasználónak, hogy táblát/nézetet használjon lekérdezéshez, beszúráshoz, frissítéshez és törléshez. Például, hogy megengedjük a user7-es felhasználónak, hogy töröljön sorokat a Titles táblából, a következő parancsot kell kiadni: GRANT DELETE on Titles to user7; Ahhoz, hogy a Titles táblából csak az au id oszlopot frissíthesse a user7 nevű felhasználó a következő parancsot kell kiadni: GRANT UPDATE on Titles (au id) to user7; 30.12 Adatbázis objektum jogok adása Adatbázis objektum jogok szabályozzák, melyik felhasználónak van joga adatbázis struktúrák létrehozására. Általában a DBMS

lehetőséget ad CREATE jogok adására mindenféle adatbázis objektumra úgy mint adatbázisok, táblaterek, táblák, indexek, triggerek, felhasználó által definiált adattípusok, eljárások függvények. Például, hogy megengedjük user5-nek és user9-nek táblák és indexek létrehozását a következő parancsot kell kiadni: GRANT CREATE table, CREATE index TO user5, user9; Adatbázis objektumok létrehozásának a joga általában a DBA-knak van fenntartva Ha ezt a jogot mások is megkapják, nehézkessé válhat az adatbázis objektumok kezelése. Tipikusan a DBA fog tábla jogokat adni a programozóknak a teszt környezetben fejlesztési célokra. Termelési rendszerhez ajánlott program és tárolt eljárás jogokon keresztül kezelni a hozzáférést, közvetlen tábla jogok helyett. 30.13 Rendszer jogok adása Rendszer jogok szabályozzák melyik felhasználó használhat bizonyos DBMS tulajdonságokat és hajthat végre bizonyos DBMS parancsokat. A

rendelkezésre álló rendszer jogok DBMS-ről DBMS-re változnak, de tartalmazhatnak képességeket archiválni adatbázis naplókat, lekapcsolni és újraindítani az adatbázis szervert, nyomkövetőket indítani monitorozás céljából, tárhelyet kezelni és adatbázis gyorsítótárakat kezelni Rendszer jogok nem adhatóak adatbázis szinten. Rendszer jogokat rendszerszinten adnak a DBMS-en keresztül Például, hogy megengedjük user6-nak teljesítmény nyomkövetők indítását, a következő parancsot kell kiadni: GRANT TRACE TO user6; A rendszer jogokat gondosan kell kezelni és az osztás joga általában a DBA és SA számára van fenntartva. 35 30.14 Program- és eljárásjogok adása Az EXECUTE jog megengedi a felhasználónak, hogy programot vagy tárolt eljárást futtasson Például, hogy megengedjük a user1-nek és user9-nek a proc1 nevű eljárás futtatását, a következő parancsot kell kiadni: GRANT EXECUTE on proc1 TO user1, user9; Programokra

és eljárásokra adni jogokat könnyebben kezelhető, mint egyéni táblákra és oszlopokra adni. 30.2 Jogok adása PUBLIC-nak Ha egy jogosultság PUBLIC-nak engedélyezve van, akkor a DBMS bárkinek, aki be tud lépni a DBMS-be meg fogja adni azt a jogosultságot. A PUBLIC-nak adott jogokat nem lehet WITH GRANT OPTION-nel kiadni, mivel mindenki PUBLIC-ban van. Például, hogy megengedjük mindenkinek a sorok törlését a titles táblából, a következő parancsot kell kiadni: GRANT DELETE on titles to PUBLIC; Nagy rendszernél nem érdemes használni, mert nehéz a biztonság adminisztrálása. 30.3 Jogok visszavonása A REVOKE utasítással a korábban kiadott jogokat lehet visszavonni. A jogok automatikusan visszavonódnak a DBMS által, ha az adatbázis objektum törlődik. Például, hogy visszavonjuk user7-től a titles tábla au id oszlopáról a frissítés lehetőségét, a következő parancsot kell kiadni: REVOKE UPDATE on titles (au id) from user7; A

PUBLIC jog visszavonása nem fogja elvenni az adott jogot azoktól a felhasználóktól, akik külön GRANT utasításban kapták azt. 30.31 Kaszkádolt visszavonás Ha WITH GRANT OPTION-nel adnak jogot valakinek és visszavonják tőle, akkor azoktól is visszavonják, akiknek ő adott. Hogy minimalizáljuk a kaszkádolt REVOKE-ok hatását, kerülni kell a WITH GRANT OPTION-nel való jogosultság osztást. Minél kevesebb felhasználó tud további jogokat osztani, annál egyszerűbb azokat kezelni a DBMS biztonsági infrastruktúráján keresztül. 30.32 Időrend és visszavonás A GRANT és REVOKE kiadásának sorrendje ütközést okozhat a hatásukban. Például, néhány DBMS-ben lehetőség van jogosultság adására minden felhasználónak kivéve egyet, a következő utasítások kiadásával: GRANT DELETE on titles to public; COMMIT; REVOKE DELETE on titles from userx; 30.4 Biztonsági jelentések Miután kiosztották, a DBA-nak monitoroznia és jelentenie kell

a felhasználók által birtokolt jogokat. Az adatbázis biztonság a rendszerkatalógusban tárolódik A DBA használhat SQL-t a szükséges információk lekérésére a megfelelő rendszer katalógus táblákból. 36 31. Szerepkörök és csoportok feljogosítása Egyéni felhasználóknak jogosultság osztásán felül, a DBMS lehetőséget adhat: – meghatározott jogok egy szerepkörnek adására, ami aztán másoknak adható; – meghatározott beépített jogok csoportjának felhasználóknak adására. Néhány DBMS a csoportokat szerepköröknek nevezi és fordítva. 31.1 Szerepkörök Azután hogy definiálták, egy szerepkör felhasználható arra, hogy előre meghatározott jogokat adjanak a segítségével egy felhasználónak. A szerepkör lényegében jogok gyűjteménye Például: CREATE role MANAGER; COMMIT; GRANT select, insert, update, delete on employee to MANAGER; GRANT select, insert, update, delete on job title to MANAGER; GRANT execute on

payroll to MANAGER; COMMIT; GRANT MANAGER to user1; 31.2 Csoportok A csoport szintű jogosultság hasonlít a szerepkörökhöz. Habár minden DBMS ad beépített csoportokat, amelyeket nem lehet megváltoztatni A következő csoportok közösek a fő DBMS-ek között: – Műveletek (üzemeltetés) felügyelője. Úgy is hivatkozzák mint OPER vagy SYSOPER A művelet felügyelő szerepkörnek joga van olyan adatbázis feladatok végrehajtására mint mentés és helyreállítás, vagy futó feladatok megszakítása. – Rendszer adminisztrátor. Röviden SA vagy SYSADMIN Ez a leghatalmasabb csoport a DBMS-en belül Az SA szintű jogosultságokkal rendelkező felhasználó minden adatbázis parancsot végrehajthat és minden adatbázishoz és objektumhoz hozzáférhet. Az SA felelős általában a DBSM telepítéséért és a rendszer erőforrások és rendszer katalógus táblák tulajdonosának tekinthető – Adatbázis adminisztrátor. Röviden DBADM vagy DBA Az

adatbázis adminisztrátor csoport ad minden jogot egy adatbázisra, plusz hozzáférhet az adatbázis tábláihoz, de nem módosíthatja azokat. DBA szintű jogosultságokkal rendelkező felhasználók eldobhatnak és módosíthatnak bármilyen adatbázis objektumot az adatbázison belül (táblatereket, táblákat és indexeket). – Adatbázis karbantartó. Röviden DBMAINT Az adatbázis karbantartó csoport magában foglalja az adatbázis objektum karbantartására szolgáló jogokat úgy mint lehetőség segédprogramok futtatására és parancsok kiadására Ahogyan a DBA csoport a DBMAINT szintű jogok is adatbázisokra vonatkoznak. – Biztonsági adminisztrátor. Röviden SSO A biztonsági adminisztrátor szerepkörnek meg van a jogkészlete az adatbázis biztonság adásának és visszavonásának engedélyezésére. A biztonsági adminisztrátor bármilyen adatbázis biztonsággal kapcsolatos tevékenységeket végre hajthat beleértve belépés és jelszó

adminisztráció, auditálás, biztonsági konfiguráció valamint GRANT és REVOKE. 31.21 Csoport szintű biztonság és kaszkádolt REVOKE A csoporttól függően néhány felhasználó, akik csoport szintű jogokat kaptak, képesek jogokat adni másoknak. Ha a csoport szintű jogosultság visszavonásra kerül ettől a felhasználótól, akkor minden olyan jog, amit ez a felhasználó kiadott visszavonásra kerül. 37 32. 32.1 Egyéb adatbázis biztonsági mechanizmusok Nézetek használata biztonsághoz Képzeljük el, hogy van egy employee tábla a következő oszlopokkal: first name, last name, middle initial, address, telephone, salary, street address, state, zip code stb. ami érzékeny információkat tárol a szervezet dolgozóiról SELECT jog adása az egész táblára biztonsági problémákat vet fel. Egy olyan nézet létrehozásával melyből kimaradnak az érzékeny oszlopok a felhasználók SELECT jogot kaphatnak erre a nézetre és elérhetik a

szükséges dolgozói információkat. Például: CREATE view emp all AS SELECT first name, last name, middle initial, street address, state, zip code FROM employee; Amikor egy nézet oszlopokat zár ki az alap táblából azt függőleges megszorításnak nevezik. Nézetek használhatóak arra, hogy az adatok tartalma alapján sor-szint-biztonságot nyújtsanak Ezt nevezik vízszintes megszorításnak és a nézetbe írt megfelelő WHERE záradékok segítségével hajtják végre Például CREATE view emp dept20 AS SELECT first name, last name, middle initial, street address, state, zip code FROM employee WHERE deptno = 20; Amikor a felhasználók lekérdeznek a nézetből, csak a feltételeknek megfelelő sorokat kapják vissza. Ha a felhasználók módosítják a nézet sorait, a feltételek biztosítják, hogy értékek ne legyenek frissíthetőek, beszúrhatóak vagy törölhetőek a tartományból. 32.2 Tárolt eljárások használata a biztonsághoz Tárolt

eljárásokat meg lehet úgy írni, hogy csak adatok sorainak és oszlopaink egy részhalmazához férjenek hozzá. Ezután ezen tárolt eljárások futtatási jogát ki lehet osztani felhasználóknak Ha nincs joga a felhasználónak a mögöttes táblákhoz, akkor csak a tárolt eljárásokon keresztül férhet hozzá az adatokhoz, így biztosítva a szükséges biztonságot. 33. Auditálás Az auditálás egy DBMS nyújtotta eszköz ami lehetővé teszi a DBA-k számára az adatbázis erőforrások és jogok használatának nyomon követését. Amikor az auditálás be van kapcsolva a DBMS elő állít egy ellenőrzési nyomvonalat az adatbázis műveltekről Minden auditált adatbázis művelet elő állít egy ellenőrzési nyomvonalat amiben a következők szerepelnek: melyik adatbázis objektumra volt hatással a művelet, ki hajtotta végre a műveletet, és mikor. Egy tipikus auditáló eszköz különböző szintű ellenőrzést tesz lehetővé a DBMS-en

belül, például adatbázis szinten, adatbázis objektum szinten és felhasználói szinten. A legnagyobb baj a DBMS auditálási eszközökkel a teljesítménycsökkenés. Habár minden DBMS különböző auditálási lehetőségeket kínál, íme néhány közös elem amit a DBMS auditálási eszközökkel ellenőrizni lehet: – A be és kijelentkezési próbálkozások (sikeres és sikertelen egyaránt). – Adatbázis szerver újraindítások. – A rendszer adminisztrátori jogosultsággal rendelkező felhasználók által kiadott parancsok. 38 – – – – – – Integritás megsértési próbálkozások (SQL Inject-et is ide soroljuk). SELECT, INSERT, UPDATE, DELETE műveletek. Tárolt eljárás futtatások. Sikertelen próbálkozások egy adatbázis vagy tábla elérése (jogosultság megsértések). Rendszerkatalógus táblák változása. Sor szintű műveletek. Tanácsok ha auditálunk: – Az auditálás nagyon erőforrásigényes lehet. Ha az audit sor

megtelik, az audit rekordokat gyártó feladatok várni fognak míg az auditáló feladat vissza nem tér. Érdeme nagyobb audit sort használni ha a teljesítmény romlik. Ha a teljesítmény elfogadhatatlan abba kell hagyni az auditálást – Egy különálló, tétlen lemezre kell tenni azokat a rendszerkatalógus táblákat, amik biztonsággal kapcsolatos információt tárolnak. – Gondoskodni kell arról, hogy az adattár vagy tábla, amit ellenőrző adatok tárolására használtak ne teljen meg. Amikor az audit adattár tele van, az auditálás kikapcsolódik, az aktuális audit sorban lévő rekordok elvésznek és minden felhasználói feladat ami adatokat próbál az audit sorba küldeni megszakításra kerül. 34. Külső biztonság Amikor külső biztonsági mechanizmusokat használ a DBA, hogy megvédje az adatbázishoz kapcsolódó erőforrásokat, akkor főként a DBMS által használt fájlokra és adat tárakra kell koncentráljon. Adathalmazok melyeket

védeni kell operációs rendszer szinten vagy fájlrendszer szinten: – – – – – – – Rendszer katalógus adatfájlok Aktív és archív napló fájlok Felhasználói adathalmazok a táblaterekhez Felhasználói adathalmazok az indexekhez Auditálási adatállományok Teljesítmény követési állományok Program és szkript állományok (forrás és futtatható kód) Ha rendelkezésre áll adattitkosítási szoftver érdemes használni az adatbázis állományokon belül. További biztonsági lépéseket szükséges eszközölni a DBMS rendszererőforrásain, úgy mint DBMS futtatásához használt fizikai tárolók és címterek, a DBMS konzol, és a DBMS telepítéséhez használt fájlok. 34.1 Feladatütemezés és biztonság A legtöbb szervezet beütemez feladatokat, hogy megadott időben fussanak, és ha ezen feladatok adatbázist is használnak, akkor jogosultságot kell adni az ütemezőnek. Nem túl jó ötlet SYSADMIN jogosultságot adni az

ütemezőnek. Helyette meg kell határozni hogyan lehet jogosultságot adni meghatározott feladatoknak az ütemező csomag és a DBMS szolgáltatásai felhasználásával Másik gyakori biztonsági hiba beágyazni jelszavakat adatbázis segédprogram feladatokba és szkriptekbe. 34.2 Nem DBMS DBA biztonság A DBA-nak elég magas rendszer szintű jogosultságra van szüksége a szervezet adatbázisainak és adatainak adminisztrálásához és kezeléséhez. Van, hogy a DBA nem kapja meg a root jelszót, és ekkor mondjuk a rendszer adminisztrátorhoz fordul. Akárhogy is a DBA-nak és SA-nak együtt kell működnie egy hatékony orációs rendszer szintű biztonsági módszer létrehozásában, ami lehetővé teszi a DBA számára feladatának elvégzését, mialatt megvédi a platform biztonságát és integritását. 39 rész IX Adatbázis mentés és helyreállítás 35. Felkészülés a problémákra Database failures that may require recovery can be divided into

three categories: – Instance failures are the result of an internal exception within the DBMS, an operating system failure, or other software-related database failure. In some cases, an instance failure can result in corruption of data that requires a recovery, but usually such failures do not damage data, so the DBMS simply needs to be restarted to reestablish normal operations. – Application (or transaction) failures occur when programs or scripts are run at the wrong time, using the wrong input, or in the wrong order. An application failure usually results in corrupt data that requires a database restore or recovery. The sooner an application failure is identified and corrected, the smaller the amount of damage to the database will be. • – Media failure is likely to damage data, too. Media failure includes damage to disk storage devices, file system failures, tape degradation or damage, and deleted data files. Although less common in practice, damaged memory chips also can

cause data corruption. After a media failure, the database will likely be in a state where valid data is unreadable, invalid data is readable, or referential integrity is violated. Outages due to media failures can often be avoided by implementing modern disk technologies such as RAID, which is covered in more detail in Chapter 17. 36. Képmásolati mentés Backing up databases involves making consistent copies of your data, usually in the form of image copies, which are the output of a COPY utility. The name of the copy utility will vary from DBMS to DBMS Common names for the backup utility include BACKUP, COPY, DUMP, and EXPORT. 37. Helyreállítás 38. Alternatívák a mentésre és a helyreállításra 40 rész X Terv katasztrófára 39. A tervezés szükségessége Katasztrófa definíciója: bármilyen nem tervezett kiterjedt veszteség a kritikus üzleti alkalmazások területén, mely a számítógép feldolgozó-kapacitásának hiánya miatt történik, és

több mint 48 órán át fennáll. Adatbázis katasztrófa helyreállításnak szerves részét kell képeznie a teljes üzlet helyreállító tervnek. Egy katasztrófa helyreállító tervnek mindenre ki kell terjednie Kezelnie kell olyan üzleti kérdéseket, mint például az üzlet vezetés alternatív helye, kommunikációs módok amivel informálni lehet a dolgozókat az új helyekről és eljárásokról és a vásárlók informálása arról hogyan tudnak üzletet kötni a céggel a katasztrófa után. A tervnek helyre kell állítani az IT infrastruktúrát és persze az adatbázisokat. 39.1 Kockázat és helyreállítás A katasztrófa helyreállítási terv célja katasztrófa esetén előforduló költségek minimalizálása. Bármely adatbázis katasztrófa helyreállító terv sikere azon múlik mennyire voltak képesek megjósolni az adatvesztéssel járó kockázatokat. Jó módszer erre minden adatbázis objektumot úgy értékelni, mintha teljesen elveszne Az

adatokat figyelembe véve három kockázati kategória van: pénzügyi veszteség, üzleti szolgáltatás szünetelés, jogi kötelezettségek. Ajánlott a rendszereket kritikus és nem kritikus alkalmazásokra bontani üzleti megfontolások szerint. Jó ötlet az alkalmazások következő csoportokba sorolása azért, hogy kiderüljön, melyiknek van a legnagyobb hatása, ha elvész: – Nagyon kritikus alkalmazások. A legkritikusabb alkalmazásoknak a helyreállítás során az aktuális adatokra van szüksége. Ezen alkalmazásokra lesz elsőként szükség a helyreállítási oldalon Ilyen például a telefonos rendszer. Üzlet szempontjából kritikus alkalmazások Gyakran igénylik az aktuális adatokat a távoli oldalon, de ezek esetenként nem elérhetőek az első néhány napban. Ilyen például a számlázási rendszer – Kritikus alkalmazások. Abban különböznek az üzlet kritikus alkalmazásoktól, hogy nem kívánnak olyan aktuális adatokat és nem is olyan

sürgősek. Egy két hét elteltével lehet rájuk szükség, és a frisstől egészen a több naposig igényelhetnek adatokat. – Szükséges alkalmazások. Nem kritikusak, de el kell menteni ezeket, hogy helyre lehessen állítani a távoli oldalon, ha szükségesek. A legutolsó elérhető biztonsági mentésből származó adatok általában elégségesek ezen alkalmazások számára. – Nem kritikus alkalmazások. Ezekkel nem kell foglalkozni katasztrófa esetén Akkor miért vannak? 40. Általános katasztrófa helyreállítási irányelvek Csökkenteni kell az adatvesztést és állásidőt. 40.1 A távoli oldal Amikor a katasztrófa tombol, szükség lesz egy távoli helyre ahol elindíthatóak a cég műveletei. Ennek a helynek kellően távol kell lennie a természeti katasztrófa helyétől. Ha elég nagy a cég, akkor több adatközpontot felhasználhat arra, hogy egymás adatait mentsék. Más szervezetek távoli adatközpontokba küldik az adataikat és

katasztrófa esetén csak csatlakoznak ehhez. Másik megoldás lehet, hogy a cég szerződik egy katasztrófa helyreállítás szolgáltató céggel. 41 40.2 Írott terv A tervet minden a helyreállításban kulcsszerepet játszó személynek ki kell osztani. Egy másolatot a helyreállítási tervről a helyreállítási oldalon is kell tartani. Egy helyreállítási terv úgy változik, ahogy a rendszer követelmények és a rendszer használat. Ha a terv változik a régi verziókat meg kell semmisíteni és ki kell cserélni újra. Egy távoli helyreállítás során követendő eljárások és politikák leírása sok előnnyel jár. Bizonyos feltételeknek eleget kell tennie a tervnek: – – – – Katasztrófa esetén végrehajtandó explicit műveleteket kell tartalmazzon. Fontos, hogy megfelelő sorrendben kövessék egymást ezen műveletek. Meg kell határozni milyen eszközöket fogunk használni és a szükséges pontos mentési információkat.

Dokumentálja, hogy a szükséges információk hol vannak tárolva, és a helyreállítás helyéről hogyan lehet elérni őket. – Fontos, hogy ha az, aki ismeri a tervet, nem érhető el, akkor más is eligazodjon a terven. A katasztrófa helyreállítási tervnek a következőket kell tartalmaznia: – Távoli helyszínek. A távoli helyszínek címei, telefonszámmal, fax számmal, és a távoli kapcsolattartók címei Hasznos lehet továbbá a közeli hotelek listája, a távoli helyszínre utazás lehetőségei, a kiadások kezelésének leírása, hasonlók. Személyek A helyreállító csapat tagjainak elérhetőségei – Hitelesítés. A helyreállításhoz szükséges biztonsági hitelesítések listája és a személyek, akikhez rendelve van – Helyreállítási eljárások és szkriptek minden rendszerszoftverhez, alkalmazáshoz és adathoz. Teljes step-bystep eljárások minden rendszerszoftver, alkalmazás, adatbázis objektum helyreállításához és azok

helyreállítási sorrendjéről Ennek részeként érdemes felírni az összes helyreállításhoz használt telepítési szoftver és kazetta listáját. – Jelentések. Listába kell szedni az összes helyreállítási oldalon szükséges jelentést A jelentésekben szerepelnie kell minden biztonsági szalagnak, a tartalmuknak, mikor késíztették, mikor küldték az elsődleges helyszínről, mikor érkezett meg a távoli helyszínre. 40.3 Katasztrófaterv tesztelése Ajánlott évente tesztelni a távoli helyreállítási oldalon a helyreállítási tervet. Ajánlott tesztelni még a következő események bekövetkezte után is: – – – – – – – – Jelentős változás a napi műveletekben. Rendszer hardver konfigurációváltozás. DBMS (vagy hozzátartozó rendszer szoftver) frissítés. Helyreállításért felelős személy megváltozása. Az elsődleges adatközpont más helyre költözése. A napi mentési eljárásokban változás. Új

alkalmazások, vagy meglévő kritikus alkalmazások frissítése esetén. Jelentős adatmennyiségbeli vagy napi tranzakcióbeli növekedés. A tesztelést arra használjuk, hogy megtaláljuk a hibáit és gyengeségeit és javítsuk is ki őket. A rendszeres katasztrófa helyreállítási tesztekkel biztosítható a személyzet ébersége. A tesztelés segít gyakorlatot szerezni a helyreállítás során használt eszközök és eljárások kezelésében. Valójában egy előre bejelentett katasztrófa helyreállítási terv teszt vélhetően rossz ötlet, mert nem lesz életszerű. A katasztrófa helyreállítási tesztnek tartalmaznia kell az írott terv minden lépését. 42 41. 41.1 Az adatbázis mentése a katasztrófa helyreállításhoz Szalagos mentés a képmásolati mentésekről Több kimeneti állományt kell készíteni a képmásolati mentés folyamatából, és el kell küldeni egyet a távoli katasztrófa helyreállítási pontra minél hamarabb.

Helyreállítási célokból nincs szükség az indexek mentésére. Mindig újra létre lehet hozni őket a helyreállított adatokból. Minden nap jelentést kell írni a távoli oldalra küldött biztonsági fájlokról. A jelentésekből egyet az elsődleges helyszínen egyet a távolin kell hagyni. A jelentésnek tartalmaznia kell minden helyreállításhoz szükséges információt, beleértve fájl neveket, mentés típusát (teljes vagy növekményes (inkrementális)), hogyan készült a kép másolat (adatbázis segédprogrammal vagy fájl rendszer paranccsal), mentés készítésének időpontja, a másik helyre küldés ideje, a fogadás ideje. Továbbá el kell menteni az adatbázis naplókat is és a távoli oldalra kell szállítani ezeket. Ennek elmulasztása maga után vonja, hogy az adatokat csak a legutolsó biztonsági mentésig lehet majd visszaállítani Minden adatbázis objektum helyreállítása a távoli oldalon egyenként megy végbe. Az indexek

újraépítése követi a helyreállított adatokból. Ezután a DBA valamilyen eszközökkel felderíti és megoldja az integritási problémákat és megszorítás sértéseket. Legalább három biztonsági szalagot kell tárolni minden adatbázis objektumról a távoli oldalon. 41.2 Tároláskezelő mentések Másik megoldás a helyreállítási mentések készítésére tároláskezelő szoftverek használata, hogy adott időponton másolatot készítsen az egész lemezcsomagról. Ez jelentős rendszer kimaradást igényelhet A tároláskezelővel végzett mentés lépései: – DBMS leállítása. – Minden adatbázis objektum másolása tároláskezelő szoftver segítségével úgy, hogy a a teljes lemezköteteket szalagra mentjük. – Ha sikerült újraindítjuk az adatbázist. – Másolatot készítünk a biztonsági szalagokról és elküldjük a távoli oldalra. 41.3 Egyéb megoldások Ha az elsődleges oldal képes WAN-on keresztül csatlakozni a távoli

oldalhoz, akkor közvetlenül a távoli oldalon lévő mágnesszalag páncélterembe (szalagszéf vagy tape vault) menthetőek az adatok. Másik megoldás a katasztrófa helyreállítás előkészítésére a távoli tükrözése az adatoknak a távoli oldalra hálózaton keresztül. Vagyis minden adatbázis-változtatás változtatás megjelenik mindkét oldalon szinkron (egy művelet akkor tekinthető végrehajtottnak, ha az élesről a tüköradatbázisba is átkerült az adat) vagy aszinkron (a tranzakciók az éles adatbázisban commit-álódnak, a tükör a háttérben szinkronizálódik) módon. Tartalék adatbázis is egy helyreállítási lehetőség Oracle adatbázisok esetén. 41.4 Néhány irányelv 41.41 A helyreállítás sorrendje Bizonyosodjunk meg arról, hogy az operációs rendszer és a DBMS verzió megfelelő legyen, és a megfelelő karbantartási szinten legyenek telepítve mielőtt a helyreállításhoz hozzálátnánk. Pontosan kövessük az

írott tervben leírt lépéseket. 43 41.42 Adatlappangás Milyen régi az adat? Néha a régi adat nem elfogadható, és naponta többször biztonsági másolatokat küldeni a távoli oldalra túl drága. Egyik megoldás lehet az adatok másik helyre juttatásának a log shipping (napló alapú szinkronizálás) vagy replikáció. Minden igyekezetünk ellenére néhány napló nem érhető el a katasztrófa idején és ezért néhány adat nem lesz teljesen helyreállítható. 41.43 Emlékezés más létfontosságú adatokra Távoli másolatok készítése az adatbázis objektumokról nem biztos, hogy elegendőek lesznek a teljes helyreállíthatósághoz. A kapcsolódó adatokat is el kell küldeni a távoli oldalra További adatok, amelyeket érdemes elküldeni: – DDL könyvtárak az adatbázis-objektumokhoz, a mentéshez, és teszt szkriptekhez Alkalmazás program források és futtatható állományok – Tárolt eljárás források és futtatható állományok –

Felhasználó által definiált függvényekhez források és futtatható állományok – Könyvtárak és jelszavak más szállítótól származó DBA eszközökhöz – Alkalmazás által használt kapcsolódó adatok 41.44 Óvatosan a tömörítéssel Meg kell bizonyosodni arról, hogy a távoli oldal ugyanazt a szalagtömörítési szoftvert alkalmazza-e mint az elsődleges. 41.45 Utómentési képmásolatok Lényeges része a helyreállítási folyamatnak képmásolatok készítése minden adatbázis objektumról helyreállításuk után. Ez megkönnyíti az adatok helyreállítását, ha valami balul sülne el a távoli oldal üzembe helyezése után. 42. Katasztrófa megelőzés Először is probléma megelőző eljárásokat és politikákat kell létrehozni. Például használjunk villámvédőt, UPS-t, tartalék generátort áramkimaradás esetére. Másik hasznos dolog megtanítani a végfelhasználóknak a hibaüzenetek jelentését, és hogyan kell azokat

kezelni. Alkalmazástól függően a rossz felhasználói reakció egy hibaüzenetre, adatvesztéssel is járhat Leírások segíthetik az emberi hibák elkerülését. 44 rész XI Adat-, és tároláskezelés 43. Tároláskezelési alapok Célok a tárolási rendszer kialakításánál: – – – – – – Legfontosabb az adatvesztés megelőzése. Megfelelő tároló kapacitás kialakítása, és a tárolási megoldás skálázhatósága, ha a tárolási igény nő Adatok gyors elérése a szolgáltatás minimális megszakításával vagy megszakítása nélkül Hibatűrő és hiba esetén gyorsan javítható Leállás nélkül lehessen lemezeket cserélni vagy bővíteni Költséghatékonyság 44. Állományok és adathalmazok 9. ábra Táblatér és állomány kapcsolata Az adatoknak táblateret kell biztosítani, egy adatbázisban több táblatér lehet, egy táblatérben több tábla. Az se biztos, hogy egy tábla csak egy táblatérben szerepel. A DBA

bizonyos fájlokat külön lemezre helyezhet az alábbi szempontok szerint: – – – – Összhangban legyen a fájlok teljesítményigénye az eszközök teljesítményével. Az indexek és adatok szétválasztása. A napló egy különálló, gyors eszközön legyen. Az átmeneti- és munkaállományok kerüljenek ugyanarra a különálló eszközre, ennek a sérülése esetén az egész törölhető, nincs szükség a helyreállításukra. – Az adatok több eszközre való szétosztásával a párhuzamos elérés elősegíthető. 45 44.1 Állományok elhelyezése a lemezre Legyen a napló az adatbázisétól különálló eszközön. Egy másik gyakran alkalmazott technika az indexek és adatok szétválasztása. Ha a DBMS olyan tároló eszközt használ amely több fizikailag különálló eszközt egyetlen logikai tárolóvá fog össze (RAID), a fájlok direkt elhelyezése csak időpazarlás. Ebben az esetben hagyjuk a rendszerre a fájlok elhelyezését (System

Managed Storage). A küldetéskritikus adatbázis-objektumok, és a napló elhelyezést viszont érdemes kézzel végezni. 44.2 Raw partíció vs. állományrendszer Raw partíció használatakor az adatok közvetlen íródnak a lemezre, az operációs rendszer beavatkozása nélkül. Ennek a hátránya hogy nehéz a fájlokat nyomon követni. 44.3 Ideiglenes adatbázis állományok Átmeneti adatbázis objektumok csak rövid távon foglalnak helyet, pl. egy tranzakció élettartamára, ezekhez a DBA rendel eszközt és tárterületet. 45. Helykezelés A DBA-nak nyomon kell követnie: – – – – – – – Eszköz töredezettség. Töredezettség használati információ. Elérhető szabad hely. Szegmens vagy partíció méret. Szegmensenként foglalt táblák és indexek. Jelenleg fenntartott, nem használt területek. Objektumok melyek helyhiánnyal küzdenek. 45.1 Adatlap szerkezet Az adatbázis objektumok lapszerkezetének általános felépítése: – Lap

fejléc. Fizikai gazdálkodási információk Tartalmazhat: a) lapazonosítót, b) mutatót a megelőző és következő lapra, c) valamilyen azonosítót ami mutatja melyik táblához tartozik a lap, d) mutatót szabad tárhoz, e) minimum sorhossz a táblához – Adatsorok. A tábla (vagy index) aktuális sorai az adatokkal Az adatsorok általában egy lapon belül vannak, kivéve extra nagy szövegek, képek vagy bináris objektumok. – Offset tábla. Mutatók az adatlap adatsoraira Néhány DBMS esetén mindig van offset tábla, másoknál csak változó méretű adatsorok esetén. 45.11 Allokációs lapok A DBMS használja a lapok felügyeletére. Egy adatbázison belül több is lehet, egy-egy allokációs lap a lapok egy csoportját felügyeli. Ezeket a blokkokat szokás allokációs egységnek nevezni A fizikai lapokat kezelik Minden fizikai lap egy-egy adatbázishoz van rendelve. A fizikai lapok a lemezen általában szétdarabolva helyezkednek el. Az allokációs

egységek a lapokat bitmappel kezelik, egy-egy bit 1-re van állítva ha az általa reprezentált lapban van szabad hely. 46 10. ábra Adatlap szerkezet 45.12 Adatrekord szerkezetek Egy tábla sorokból és oszlopokból áll. Egy sor egy adatlapon kell hogy elhelyezkedjen (néhány extra nagy objektum kivételével bizonyos DBMS-eknél). A sorok tárolási információval kiegészülve rekordot alkotnak A rekordok felépítése: – Sor fejléc. A rekordok néhány bájt fizikai tárolási információval kezdődnek, amik leírják az adat tartalom szerkezetét és összetételét. Tartalmazhatja a sorhosszt, információt változó hosszúságú sorokhoz és egyéb vezérlési szerkezeteket. – Sor adat. Az aktuális adattartalom a definiálás sorrendjében Néhány DBMS-nél az fix és változó hosszúságú oszlopok szét vannak választva. – Offset tábla. Opcionális, a sorok változó hosszúságú mezőit kezeli és felügyeli 45.13 Rekordméret kiszámítása A

rekord hossza a sorhossz és fejléc valamint az offset tábla méretének összege, ahol a sorhossz a tábla oszlopainak hosszának összege. Fix hosszúságú sorok: Sorhossz = Hossz(Oszlop1 ) + · · · + Hossz(Oszlopn ) Változó hosszúságú sorok: Sorhossz = Hossz(FixHOszlop1 ) + · · · + Hossz(FixHOszlopn )+ + Atlag[Hossz(ValtozoHOszlop1 )] + · · · + Atlag[Hossz(ValtozaHOszlopn )] Az oszlop hossza a típusától függ. A rekord teljes hosszának kiszámításához ismerni kell az oszlopok típusából adódó extra terület igényeket és ezeket még hozzá kell adni mindkét számításhoz. 47 45.14 Táblaméret kiszámítása A rekord méretének kiszámítás után ki kell számolni, hány sor fér el egy fizikai lapon. Például: tegyük fel, hogy egy lap mérete 2K, ebből 32 bájt a fejléc. Marad 2016 bájt az adatsoroknak, a következő képlettel kapható meg az adatsorok száma: Sorok szama laponkent = 2016 Sorhossz A következő képlettel

határozható meg a tábla mérete: Tabla merete(K) = Sorok szama · (2K) Sorok szama laponkent Ezen felül a DBA-nak számolnia kell a táblának szánt szabad hellyel valamint a külön tárolt objektumokkal is, mint pl. az SQL Server text-jei, vagy a DB2 LOB-jai 45.2 Indexlap szerkezetek Ha egy táblához nincs index megadva, az új sorok egyszerűen hozzáíródnak a tábla végéhez. Ha nincs hely a sornak az adott lapon, új lap allokálódik a számára. A nem indexelt tábla adatlapjai előre és hátra mutatókkal vannak láncolva, ez szekvenciális bejárást eredményez. Ugyanaz vonatkozik az indexek rekordjaira is mint az adat rekordokra. Egy index sornak teljes egészében el kell férnie az indexlapon. Az indexlap felépítése: – Fejléc információk. Mint az adatlapnál az index lap is fizikai tárolási információkkal kezdődik, leírja a szerkezetét és összetételét a rekordnak. – Sorhossz. Változó hosszúságú kulcsoknál az indexnek szüksége

lehet az indexelt adat pontos hosszára – Index kulcs értékek. Az index kulcshoz tartozó aktuális adatértékek a felírás sorrendjében – Lapmutató. Az indexelt adat adatlapjának fizikai címét mutatja – Offset és adjust táblák. Az index sor változó hosszúságú mezőit mutathatják Az index lapmutató klaszterezett indexnél egy mutató az adatlapra, nem klaszterezettnél az adatlapmutatót és az adatlapon az adatsorra mutatót is tartalmaz. 45.21 Indexméret kiszámítása 45.3 Tranzakció naplók Mentésnél és helyreállításnál kell, hogy konzisztens állapotba hozhassuk az adatbázist. Méretének meghatározása inkább művészet mint tudomány, ugyanis a tranzakciók véletlenszerűségéből fakadóan mérete véletlenszerűen változik Ökölszabály: akkora területet biztosítsunk neki hogy a két archiválás közötti időben, a legforgalmasabb időszakkal számolva is el tudja tárolni az összes változtatást A DBA feladata

meghatározni hány napló legyen és melyik eszközökön, valamint hogy mennyi ideig legyenek megőrizve 48 rész XII Adatmozgatás és elosztás Data is copied and transformed and cleansed and duplicated and stored many times throughout the organization. The DBA uses many techniques and technologies to facilitate data movement and distribution. 46. Loading and Unloading Data One of the simplest ways for the DBA to move data from one place to another is to use the LOAD and UNLOAD utilities that come with the DBMS. The LOAD utility is used to populate tables with new data, and the UNLOAD utility is used to read data from a table and put it into a data file. 46.1 The LOAD Utility 46.11 Describing the Input File 46.12 Efficient Loading 47. Elosztott adatbázisok 47.1 Adat elosztási szabványok 47.2 Elosztott adatok elérése 47.3 Kétfázisú COMMIT 47.4 Eloszott rendszerek teljesítmény problémái 49 rész XIII Adatbázis kapcsolódások Egy

kliens-szerver alkalmazás a következő három rétegből állhat: – Megjelenítési logika azon feladatokat foglalja magában, amik az adatok képernyőn történő megjelenítéséhez szükségesek. Ez általában egy GUI-t jelent, amin lehet kattintgatni – Üzleti logika adja az alkalmazás lényeges elemeit ahhoz, hogy a végfelhasználó manipulálhassa az üzlethez szükséges adatokat. – Adatbázis réteg. Adatbázis kezelő rendszereket használ a legtöbb kliens-szerver alapú rendszer, hogy gyors elérhetőséget biztosítson a rendezett adatokhoz biztonságos módon, és biztosítsa azok módosítását az integritás megőrzése mellett. Kliens-szerver feldolgozás lehetőséget ad arra, hogy fizikailag különböző számítási egységeken és rendszereken legyenek az egyes komponensek. 50 rész XIV Metaadat kezelés 48. Mi az a metaadat? A metaadat adat az adatról. 48.1 Az adattól a tudásig és azon is túl Az adatok nyers tények, kontextus

és kapcsolatok nélkül. Az információ kontextusba helyezi az adatot az adat kapcsolatainak megadásával. Az adat a környezetében a metaadatokkal együtt alkot információt A tudás az információ megértése és elraktározása, a bölcsesség tekinthető alkalmazott tudásnak. 48.2 Metaadat stratégia Egy bölcsen irányított szervezet kifejleszt valamilyen metaadat stratégiát a metaadatok begyűjtésére és kezelésére, valamint valamilyen eszközt ezek elérésére. Egy jól működő metaadat stratégia céljai: – – – – – – – – – Politika, ami szerint a metaadatokat használják. Eljárások az adatok tulajdonosainak és gondnokságának definiálására és azonosítására. Az összegyűjtendő metaadat-típusok azonosítása. Az egyes metaadat-típusok céljának leírása. A metaadatok tárolására és gyűjtésére szolgáló módszerek. Módszerek a metaadat elérésére. Házirend és biztonsági előírások a metaadat

eléréshez, és az adatgondnoksági eljárások használatához. Azonosítani a metaadat forrásokat . Mértékek a metaadat minőségének és használhatóságának mérésére. 49. Metaadat típusai Alapvetően a metaadatokat két csoportba soroljuk: technológiai és üzleti metaadatok. A technológiai metaadatok az adatok tárolását és kezelését írják le a számítógépes környezetben. Az üzleti metaadatok az adat szerepéről tájékoztatnak az üzleti logikában és a cég életében. A rendszerkatalógus tárolja az információkat az adatbázis objektumokról, a DBA és a fejlesztők gyakran használják a rendszerkatalógus metaadatait az adatbázis objektumok, és a bennük tárolt adatok jobb megértéséhez. A legtöbb DBMS a következő metaadatokat tárolja a rendszerkatalógusban: – – – – – – – – Minden adatbázis, tábla, oszlop, index, kapcsolat, tárolt eljárás trigger, stb. neve Elsődleges és külső kulcsok. Melyik tábla

melyik nézetben van. Oszlopok típusai, hosszúságai, megszorítások. A fizikai állományok nevei és információk, melyekben az adatok tárolva vannak. Jogosultságok és biztonsági információk. Az utolsó adatbázis definíciós változtatás dátuma és a felhasználó ID-ja, aki megváltoztatta azt. Adatbázis szervezési információk. A rendszerkatalógus nagyon jó forrása a metaadatoknak mert a) aktív (automatikusan felépül és karbantartott), b) integrált (integrált a DBMS-be, az karban tarja és naprakészen tartja a technológia metaadatokat) és c) védett (csak DBMS műveletek hozhatják létre és módosíthatják) . További hasznos metaadatok a rendszer katalóguson kívülről: – Metaadat a nem adatbázis állományokról. 51 – – – – – – – Módosítási információk, ki módosította legutóbb az állományt. Információk adatbázis programokról. Információk kötegelt feladatokról és tranzakciókról melyek elérik az

adatokat. Infrastruktúrát leíró metaadatok. Az adatmodellt, és az adatmodell fizikai modellé leképzését leíró metaadatok. Adattárház és ETL metaadatok. Adatok tulajdonosát és gondnokságát leíró metaadatok. A metaadatok segítik az adatbázisok és rendszerek megértését. 50. Adattárházak (repository) és adatszótárak A repository tárolja a szervezet adatvagyonát. A megfelelően felépített repository a cég minden vonatkozó metaadatát tárolja. Általában egy repository tud: – Információt tárolni az adatokról, folyamatokról és környezetről. – Támogatja, hogy ugyanazt az adatot többféleképpen tekintsük, pl. az adat megtekinthető koncepcionális, logikai és fizikai szinten. – Alapos dokumentáció és jelentések a dokumentációról. – Támogatja az adatmodell létrehozását és adminisztrációját. Integrálható népszerű ETL, adat modellező és CASE eszközökbe. – Támogatja a verzió-, és változtatáskezelést.

– Végrehajtja a névkonvenciókat. – Feloldja és kivonatolja a több forrásból származó metaadatokat. Pl egy COBOL-ban írt áruházhoz a repository fejlesztőjének szállítania kell eszközöket amik a COBOL forrásból metaadatot nyernek ki – Jegyzetet generál az adatelem definíciókból. Mit várunk el egy repositorytól: – A repository által használt adattárakat a DBMS-ünkben táblákban tárolhassuk. Ez segíti az alkalmazásokat hogy közvetlenül olvashassák az adatszótárat. Vannak repositoryk melyek több DBMS-t is támogatnak – Képesnek kell lennie közvetlen olvasnia a rendszerkatalógusát, vagy rendszerkatalógus nézeteit minden használatban lévő DBMS-nek. – Ha nem tudja közvetlenül olvasni a rendszerkatalógust, interfészt kell biztosítani ehhez. – A repository biztosít egy interfészt minden modellező és tervező eszközhöz amely adatbázis objektumok generálásához használható. 50.1 Repository előnyei Többféle

metaadat egy helyen; segíti a fejlesztőket a különböző rendszerek összefüggéseinek megértésében. Minták felfedezése és használata. Általában a legnagyobb hasznot az adatelemek és az üzleti folyamatok konzisztens dokumentálásában mutatja. Segíti a szervezetet az ősrendszerei kihasználásában; a hozzájuk gyűjtött dokumentációval és metaadatokkal könnyebben integrálhatóak egy új környezetbe. Gyorsan változó környezet támogatása; a repositoryból könnyen hatásanalízis -jelentés készíthető, hogy egy terület változása hogyan hat ki a többi területre. Újrafelhasználhatóság. 50.2 Repository használatának kihívásai A repository használatának legnagyobb kihívása a naprakészen tartása, mivel több forrásból táplálkozik amelyek mindegyike folyamatosan változik. 52 Ezek a források egy szervezeten belül lehetnek: – – – – – – – Programfejlesztési eszközök, kódkönyvtárak. Üzleti

felhasználók. Adatmodellező eszközök. Rendszerkatalógus. Adattárház eszközök, ETL metaadatok. Automatikus műveletek, feladatütemező eszközök, működési metaadat. Adathasználati metaadat a lekérdező eszközökből. Nagyon kevés cég használ központosított metaadat repositoryt, vagy ha igen akkor nem fektetnek elég energiát és pénzt a naprakészen tartásába, de így elveszti az értékét, lényegét. 50.3 Adatszótárak Az adatszótárak voltak a repository előfutárai. Az adatszótárak a ’80-as években voltak népszerűek, céljuk az adatdefiníció kezelése volt, egy kevés automatizmust nyújtottak ezen a területen. 53