av Andrea Horváth för 7 årar sedan
399
Mer av detta
Ezeket az elemeket "el kell helyezni" a számítógép merevlemezén, ez könyvtárakba és állományokba szervezéssel valósul meg.
Ez tulajdonképpen a fizikai szerkezet, azaz a fájlok halmaza.
Forrás: Előadás
https://www.youtube.com/watch?v=Jm1rM533L1I
Forrás: https://www.youtube.com
Biztonsági okokból csak a rendszergazdai jogosultságok birtokában tudjuk ezeket elolvasni. Forrás: Előadás
Érdekesség: A teljesítménymonitorozás a rendszerkörnyezetre is vonatkozik, nem csak az adatbázis-kezelő rendszerre. Monitorozni kell az operációs rendszert, a hálózatot, a tranzakciós szervert stb. Az adatbázis-adminisztrátornak tudnia kell kezelni és meg kell tudnia érteni a monitorozás outputját.
Forrás: https://gyires.inf.unideb.hu/KMITT/b03/ch13s09.html
Ezeket egy „jó” adatbáziskezelő rendszer SELECT-ek formájában mutatja magáról – ezen az „API”-n keresztül bárki monitorozhat
Forrás: Előadás
Sajnos az adatbázis-adminisztrátorok általában a teljesítményproblémákat reaktív módon kezelik. A probléma már fellépett, amikor a felhasználó válaszidőproblémával hívja az adatbázis-adminisztrátort vagy amikor egy adatbázis kifutott a helyből. A probléma bekövetkezte után kell orvosolni azt. Az ilyen tevékenység tisztán reaktív.
Sok proaktív lépést is reaktívként kell tekinteni. Egy kész alkalmazás kódjának az átírása nem tekinthető proaktívnak. Proaktív szemlélet az lenne, ha a problémát javították volna, mielőtt az alkalmazást befejezik, azaz a kódot hatékonyan írták volna meg.
Sok eseményvezérelt eszközt lehet használni a teljesítményhangolás egyszerűbbé tételére. Azaz amikor előredefiniált események történnek, akkor az eseményvezérelt eszköz automatikusan előredefiniált műveletek indít el. Ez az első lépés a teljesítménykezelés felé. A teljesítmény kezelése különbözik a teljesítmény monitorozásától, mert a kezelés kombinálja a monitorozást egy részletes tervvel, amely a fellépő problémát feloldja.
A teljesítménykezelés 3 különböző komponenst tartalmaz: monitorozás, elemzés és javítás.
Forrás: https://gyires.inf.unideb.hu/KMITT/b03/ch12s03.html
Másnéven „Data Dictionary”
Forrás: Előadás
5.Most a végső lekérdezést írhatjuk megt:
SELECT INDEX_NAME, TABLE_NAME FROM USER_INDEXES
Nagyon sokszor finomítjuk ezt pl. egy WHERE feltétellel, vagy a SELECT bármelyik más elemével
Forrás: Előadás
4.Fenti parancs eredménye mutatja, hogy a USER_INDEXES nagyon sok oszlopból áll, de nekünk talán csak néhány érdekes első körben: INDEX_NAME, TABLE_NAME
Forrás: Előadás
3.Most az előzőekben megtalált nézet szerkezetét kell megismernünk. Oracle:
DESCRIBE USER_INDEXES
Forrás: Előadás
2.Fenti lekérdezés sok-sok eredménye közül a számunkra leginkább ígéretes a USER_INDEXES nézet.
Forrás: Előadás
1.Meg kell tudnunk, mi annak a nézetnek a neve, amelyben azok az információk vannak, amelyeket keresünk:
Oracle: DICTIONARY nézetből
Ha pl. a saját indexeinkre vagyunk kíváncsiak, akkor valami ilyesmi az első lépés:
SELECT * FROM DICTIONARY WHERE TABLE_NAME LIKE ’%INDEX%’;
Forrás: Előadás
A szótártáblák könnyű olvasása érdekében fontosak.
Nézetek, a saját objektumokról: pl. USER_TABLES, USER_INDEXES, USER_VIEWS, stb.
Nézetek, amelyben látjuk a saját objektumainkat IS, meg mások sémájában lévőket is, amennyiben hozzáférésünk van azokhoz: ALL_TABLES, ALL_INDEXES, ALL_VIEWS, stb
Nézetek, amelyekben az adatbázis minden ilyen típisú objektuma látható: DBA_TABLES, DBA_INDEXES, DBA_VIEWS, stb.
• A DBA_ nézetek csak a rendszergazdai jogosultságok birtokában olvashatók
• A DICTIONARY nézet: a szótárnézetek leírása (ebből kezdünk keresni). Ennek rövidítése a DICT
Forrás: Előadás
Mit nyújt a vállalatok számára a egy jól felépített adatszótár?
Az adatszótár a vállalati adatbázisokban, elektronikus kommunikáció során használt adatelemek rendszerezett gyűjteménye, amely egyúttal tartalmazza az adatok egymáshoz fűződő viszonyának ismertetését is. Célja az, hogy egységes, összevont képet mutasson az összes vállalati adatbázisban előforduló adatokról.
Az adatszótár kialakításakor egy fontos kérdést figyelembe kell venni. Mivel az adatszótár tartalma folyamatosan bővülni, változik, fontos a verziókezelés használata. A korábbi projektek adatbázisai az adatszótár akkori állapota alapján készültek el, ezért ha rendelkezünk az adatszótár előző verzióival, pontosan megmondhatjuk, hogy mik az eltérések, és egy integráció vagy BI transzformáció során hogyan kell az adatokat egységes, az adatszótárban leírt aktuális formára hozni. A vállalati meta-adat Repository megléte nagyban segíti a verziók és modellkonfigurációk menedzselését, mivel megőrzi a modellbe épített referenciákat.
Az adatszótárak a vállalati adatelemeket könnyen újrahasznosíthatóvá teszik. A folyamatos változás során célszerű betartani három alapvető szabályt:
1) az adatelemeket nem szabad felülbírálni, más célra használni, így az adatelemek újrahasznosíthatóak maradnak;
2) az érvényüket vesztett adatelemeket kezeljük szeparáltan, és ne használjuk fel őket többet;
3) az adatelemek és attribútumaik között átlátható, tiszta kapcsolatot kell kialakítani, az adatstruktúrák normalizálás útján juttathatóak el a kívánt formába.
Másik lényeges dolog, hogy a vállalaton belül egy-egy adatelem neve függően annak felhasználási helyétől (telephely, részleg, üzleti szerepkör stb.) eltérhet. Ezért az adatszótárnak támogatnia kell egy-egy adatelem, entitás esetében alias-ok kezelését is.
Forrás: http://www.sybase.hu
Alapvetően táblákból áll.
Indexekkel biztosítják az egyediségét és gyorsítják fel a keresést.
Forrás: Előadás
Oracle specifikus
Az adatmodell (séma) létrehozása során tartalmi és formai előírásokat rendelünk a tárolandó adatokhoz. Ennek megfogalmazására szolgál az Adatleíró nyelv, ami valójában nem más, mint program utasítások csoportja, amelyekkel definiáljuk az adatok nevét, adattípusát, méretét, formátumát, hozzáférhetőségét. Azt a "listát", amely a használt adatok jellemzőit tartalmazza, Adatszótár – nak nevezzük.
Példa:
ilyen utasítások például a CREAT<objektum> , ALTER <objektum>
Forrás:
http://www.inczedy.hu/
Az adatbázisok két fajtáját szokás megkülönböztetni: a logikai és fizikai adatbázist.
Forrás: Wikipédia
„mit tárolunk” (mit és hogyan akarunk látni az adatokból)
Forrás: Wikipédia
Egy magasabb, úgymond „logikai” szinten az adatbázis táblákat, kényszereket, nézeteket, indexeket, tárolt kódot, és sok egyebet tartalmaz.
Forrás: Előadás
„hogyan tároljuk” (mit és hogyan érünk el a fizikai háttértáron)
Forrás: Wikipédia
Fontos: 1 tábla NEM EGYENLŐ 1 állománnyal!
Forrás: Előadás
SAP
Az SAP rendszerek háromrétegű kliens-szerver architektúrát használnak, a középpontban az alkalmazás-szerverrel. Az SAP kétféle alkalmazás-szervert szolgáltat, SAP NetWeaver Application Server ABAP illetve SAP NetWeaver Application Server Java néven.
A három-rétegű tagolás célja a skálázhatóság. Üzleti környezetben hatalmas adatmennyiség, több terra-byte kerül tárolásra és átdolgozásra napról napra, ezért egy nagy előnye az SAP-nak a szinte korlátlan számú, többször több 100 applikációs szerver használata, mely így tetszőlegesen skálázhatóvá teszi a rendszert.
A 3 réteg:
prezentációs réteg:
az interfész a felhasználók felé, a megjelenítésért felelős. Fogadja a felhasználók inputjait, továbbítja az applikációs szervernek. Megjeleníti az összeállított adatokat és képernyőket. Az üzleti környezetben legelterjedtebb képernyőfajtákat, SAP környezeten Dynpro-nak hívjuk.
alkalmazási réteg:
A kernel és a bázis modulok alkotják. Az a része az applikációs szervernek, amelyek mind az adatbázis mind a prezentációs réteget érintik. Felelősek a felhasználók kezelésért, a munkafolyamatok kezelésért, más rendszerekkel való összeköttetésekért, mindamellett rendszer adminisztrációs folyamatokat is futtatnak. A kernel-ben futnak azok a folyamatok, vagy más néven virtual machine-ek amelyek értelmezik a byte kódot, ezáltal platform függetlenné téve a rendszert. Az alkalmazás-szerver hajtja végre a programokat.
Az alkalmazás-szerver többek között az alábbiakat biztosítja számunkra:
adatbázis réteg:
A rendszer lelke, minden itt tárolódik. Törzsadatok, mozgásadagok, a programunk kódjai, a használt képernyőink és még maga az fejlesztő környezet is.
Az architektúra egyik előnye, hogy az alkalmazás-szerverek és az adatbázis-szerverek tetszőlegesen skálázhatóak, nem terhelik a kliens erőforrásait csak a szükséges mértékben. Az adatbázis- illetve operációs rendszer szolgáltatásait pedig úgynevezett work processzeken keresztül érhetjük el, illetve éri el a szerver. ABAP programozási szempontból úgy, hogy nem kell azzal foglalkoznunk, hogy az alkalmazás-szerver milyen operációs rendszeren fut, illetve milyen adatbáziskezelő-rendszerben tárolja az adatokat, ezeket ugyanis a környezet elfedi előlünk.
Források:
http://people.inf.elte.hu/falsaai/2.felev/Bevezetes%20az%20SAP%20vilagaba/sap_ea03.pdf
http://www.tankonyvtar.hu/hu/tartalom/tamop412A/2010-0011_sapabap/lecke1_lap1.html
Videó
Videó magyarázatokkal a könnyebb megértéshez:
https://www.youtube.com/watch?v=aCre-0WYhTg
Forrás: https://www.youtube.com
A SAP adatbázis architektúrája vizuálisan ábrázolva:
https://drive.google.com/file/d/0B6Cvxg7-SFJcT3htdWNOZmh4VGs/view?usp=sharing
Forrás: http://www.gotothings.com
Oracle
Az Oracle adatbázis állományok halmaza, amelyet egy egységként kezel az adatbáziskezelő rendszer (a szoftver).
3 fájlból áll:
adatállomány:
Amelyekben az összes tárolt adat szerepel
naplóállomány:
•Az adatbázis változtatásait rögzíti
•Konzisztens állapot visszaállításhoz szükséges rendszerhiba, áramszünet, lemezhiba, stb. esetén
•Adatvédelmi okokból különböző lemezeken többszörös másolatokat kell belőle szinkronizáltan kezelni.
vezérlőállomány:
•Adatbázis konfigurációját tárolja
•A példány indításakor az adatbázis rákapcsolásához (mount) be kell olvasni a vezérlő fájlokat.
•Az adatbázist alkotó fizikai fájlokat határozza meg.
•Ha új fájlt adunk az adatbázishoz, akkor automatikusan módosulnak.
•A vezérlő fájlok helyét az inicializálási paraméterben adjuk meg.
•Adatvédelmi szempontból legalább három különböző fizikai eszközön legyen másolata (multiplex the control files). Ez is inicializálási paraméterrel adható meg. Az Oracle szerver elvégzi a többszörös másolatok szinkronizációját.
•Az operációs rendszer, a fájlkezelő rendszer illetve a számítógép rendszergazdája állományokat lát, amelyek elfoglalnak valamennyi helyet a merevlemezen.
Forrás: people.inf.elte.hu/kiss/14ab2/Oracle.ppt
Szintaxis
egyes elemek létrehozási sorrendje Oracle adatbázis esetén
• A DBA létrehozza a „fizikai” adatbázist:
CREATE DATABASE dbpelda
…
…
…
• A DBA létrehozza a táblateret:
CREATE TABLESPACE tspelda
DATAFILE ’D:\db\tspelda.dbf’ SIZE 10G;
• Valaki létrehozza a táblát:
CREATE TABLE tablapelda ( oszlop1 NUMBER)
TABLESPACE tspelda;
Forrás: Előadás
Kép
Az Oracle adatbázis architektúrája vizuálisan ábrázolva:
https://drive.google.com/file/d/0B6Cvxg7-SFJcZkk1dHlWV2tFUEk/view?usp=sharing
/Forrás: https://media.licdn.com/
Magyarázat a képhez:
–System Global Area (SGA): Az összes szerverfolyamat és háttérfolyamat osztozik rajta
–Program Global Area (PGA): Minden szerverfolyamatnak és háttérfolyamatnak saját memóriaterülete (PGA-ja) is van.
Az SGA a következő adatszerkezetből áll:
1.Database buffer cache: A beolvasott adatblokkok pufferterülete
2.Redo log buffer: A helyreállításhoz szükséges redo napló pufferterülete, innen íródik ki a napló a lemezen tárolt redo naplófájlokba
3.Shared pool: A felhasználók által használható közös puffer
4.Large pool: A nagyon nagy Input/Output igények kielégítéséhez használható puffer
5.Java pool: A Java Virtuális Gép (JVM) Java kódjaihoz és adataihoz használható puffer
6.Streams pool: Az Oracle Stream-ek pufferterülete
