Mi alapján választunk a relációs adatbázisok közül?

Az adatbáziskezelő rendszer költségei alatt értjük a licenszköltségeket, a support díját, a hardver, valamint az üzemeltető személyzet költségeit is.

A licensz használati jogot jelent, amit meg kell vásárolni, azaz amikor licenszköltséget fizetünk, akkor azért fizetünk, hogy használhassuk a különböző dolgokat.Jelen esetben, a licenszköltségekre többet fogunk költeni, mint akármi másra (hardverekre, szoftverekre).A licenszköltségek esetén több milliós nagyságrendekről beszélhetünk, amely függ egyrészt a hardver méretétől, valamint a felhasználók számától is.A licenszben különböző szoftverkiszerelések és opcionális elemek vannak. Ilyen szoftverkiszerelés például az Oracle Enterprise is.Az opcionális elemek alatt olyan további elemeket értünk, amelyek plusz "szolgáltatást" nyújtanak számunkra. Ilyen például a Diagnostic Pack is, amely a monitorozást teszi lehetővé, valamint a Tuning Pack is, amely pedig az automatikus hangolást biztosítja a felhasználó számára.Ha úgy döntünk, hogy ezekre a plusz elemekre szükségünk van, akkor ezekért külön-külön fizetni kell. Továbbá ha a felhőből szeretnénk szolgáltatást bérelni, vagy csak szimplán a saját gépünkön szeretnénk igénybe venni a szolgáltatást, akkor is licensz díjat kell fizetni.

A licneszköltség mellett, olyan egyéb költségekkel is számolni kell, mint például a szoftveres támogatás éves díja. Első évben még nem kell ezért fizetni, ugyanis ezt a support díjat tartalmazza a licenszdíj, de azután minden évben külön kell fizetni érte. Ha a licensz díja kb. 10 millió forint, akkor a szoftvertámogatásra kb. 2-3 millióval kell számolnunk.

Azokkal a költségekkel is számolni kell, amelyek az esetleges adatvesztésből fakadnak. Az adatvesztésből fakadó károk alatt olyan károkat lehet érteni, mint például:lemezmeghibásodás,esetleges bizonytalanságok azzal kapcsolatban, hogy az információáramlás megtörtént-e az egyik gépről a másikra,valamint hálózati kapcsolat megszakadások.Ezeknek az esélye csekély, viszont ha ténylegesen bekövetkezik akkor hatalmas, akár visszafordíthatatlan üzleti károkat is okozhat. Például az OTP Bank esetében néhány tranzakciónak az elvesztése az adatbázisból akár több milliárdos károkat is okozhatna.Az is lehetséges, hogy nem keletezik adatvesztés, csak egyszerűen nem működik megfelelően a szoftver, tehát számolni kell a tervezett, vagy tervezetlen leállásokkal is.

A licensz díjak és egyéb költségek mellett szükséges hardver költségek is vannak, amelyek leginkább szoftver-specifikusak, azaz a szoftverektől függ, hogy milyen hardvert igényelnek.

Fontos megemlíteni az adatbáziskezelő rendszerek üzemeltető személyzetének a költségeit is, gondolok itt a bérekre, valamint a különféle képzésekre. Egy 5 napos oktatás ma már kb. fél millió forintba kerül. Ezekre a képzésekre a béreken, valamint esetleg a más dolgokra elköltötteken lehet spórolni.TCO (Total Cost of Ownership): egy olyan költségkalkulátor, amely egy eszköz birtoklásának a valós költségeit mutatja. Ez a mutató felhívja a figyelmet arra, hogy egy döntéskor ne csak az adott termék/szolgáltatás árát figyeljük, hanem fontos azoknak a költségeknek a figyelembevétele is, amelyek majd a termék/szolgáltatás teljes élettartama alatt jelentkeznek.Ezt a TCO mutatót használja az Oracle is, mely segítségével mindig levezeti azt, hogy az Oracle a legolcsóbb, de természetesen nem szabad megfeledkezni arról, hogy ez a mérés amerikai viszonylatban zajlik.------------------------------------------------------------------Forrás: Online irodalom: TCO költség kalkulátorhttp://www.autostars.hu/tcoteszt/bemutatkozas------------------------------------------------------------------

Sajnálatos módon minden szoftver bug-os, tehát a számítógépes programhibák elkerülhetetlenek, ezért számolni kell a szoftveres támogatás (support) díjával.Ha a licensz díja kb. 10 millió forint, akkor a szoftvertámogatásra kb. 2-3 millióval kell számolnunk. A supportnak a díja már tartalmazza az új verziókat is a hibajavítások mellett. Ha már léteznek programhibák, akkor a kérdés az, hogy van-e olyan ember, aki ezt kijavítsa? Ha van, akkor is számos tényezőt kell ezen kívül figyelembe venni, amelyek befolyásolhatják a support minőségét:problémák megoldásának a száma,a problémamegoldás ideje,megoldási módszer,hozzáférhetőség,kiterjedtség.

A felhasználói igények az idő elteltével folyamatosan változnak és bővülnek, éppen ezért fontos, hogy olyan adatbáziskezelő rendszert válasszunk, amelyet folyamatosan fejlesztenek.A fejlesztést számos probléma gátolhatja:kezdeti gyenge szoftverfelépítés,szoftver kódolása.Fontos, hogy milyen programozási nyelvet használtak egy szoftver létrehozásakor, ugyanis ha a kód ősrégi, akkor az már kevésbé fejleszthető.Ez történt az Oracle esetében is, ami C-ben íródott, ezért a kód jelentős része régi. Ezt a hibát próbálják azzal ellensúlyozni, hogy rengetegen fejlesztik a szoftvert.

Az a jó, hogyha egy adatbáziskezelő rendszer sok architektúrát támogat, mint például az Intel, SUN SPARC, HP, PA-RISC és IBM.

Fontos szempont az is, hogy az adatbáziskezelő támogassa a virtualizációt. Az Oracle nem igazán jeleskedik ebben, a VMWare nagyon komoly vetélytársának számít. Jelentős mértékben érdekellentétben is vannak az Oracle-ös technológiákkal, de együtt tudnak működni. Azonban ez az együttműködés fáj az Oracle-nek, ezért gyakran jelentkeznek licenszelési problémák. A virtualizációt a gyakorlatban is támogatni kell, azaz az árazásban.

Ha egy szoftver működik a Windowson, Linuxon, Solarison, AIX-en, valamint HP-UX és esetleg VMS platformokon is, akkor nagy előnnyel indul. Az a jó szoftver, ahol a szoftver nem külön van megírva a Linux és a Windows operációs rendszerekre, hanem ahol egy szoftver van és "portolták", azaz átköltöztették az egyik platformról a másikra. Ez százszor jobb megoldás annál, hogy ha mindkettőre lenne külön-külön két szoftverem. Az Oracle esetében minden fejlesztés egy platformon folyik, aztán ezt portolják. Ez a lehető legjobb technika, hiszen megkönnyíti a későbbi platformváltoztatásokat.

Embedded Database: olyan szoftver, amely nem kliens szerver alapon működik, hanem egy alkalmazás össze van ötvözve az adatbáziskezelővel, az egész egy nagy .EXE program és kívülről nem is látszik ez az adatbázis. Továbbá nem is szükséges külön rendszergazda. Ez a szoftver rendelkezik olyan felülettel, ahol a kommunikáció zajlik, ezek átköltöztethetőek egyik gépről a másikra. Általában a kisebb rendszereket látják el ilyen megoldással.

Az Embedded Database-nek valamilyen válfaja a Mobile Database, amely okostelefon és PDA alapú. Ezek nagyon gyakran omlanak össze, ezért távoli replikációkkal próbálják elkerülni az adatvesztést.

A mai világban az adatbázisokban már nem csak egyszerű adattípusú fájlokat tárolunk, mint például szöveg, dátum vagy számokat, hanem sokkal bonyolultabbakat is. Már elterjedté vált a térinformatikai adatok, képek és tetszőleges szövegeknek a tárolása is. Mint például:XMLType: egy rendszer által definiált adattípus az XML fájlok kezelésére, az XML adattípusú dokumentumok a SELECT nyelvet bővítik ki,User Defined Data Type: a felhasználó definiálni tud olyan adattípusokat, amelyek az adatstruktúrát modellezik az alkalmazásokban.Az adatbáziskezelő rendszerek esetén az objektumorientáltság egyre fontosabb szerepet tölt be.------------------------------------------------------------------Forrás: Online irodalom: https://docs.oracle.com/cd/B10501_01/appdev.920/a96616/arxml24.htmhttps://docs.oracle.com/cd/A91202_01/901_doc/server.901/a88856/c14ordb.htm------------------------------------------------------------------

Egy adatbáziskezelő rendszer annál jobb, minél több programozási nyelvet támogat.

JDBC (Java Database Connectivity): egy API a Java programozási nyelvhez, amely támogatja bármely relációs adatbázishoz a hozzáférést.A JDBC segít a felhasználóknak olyan Java applikációk megírásában, amelyek az alábbi három programozási tevékenységet segítik:Adatforráshoz való csatlakozás (pl. adatbázishoz)Lekérdezések küldése és feltöltése az adatbázisbaA lekérdezések eredményeinek a feldolgozása.További információ a témához megtalálható a csatolt linken. ------------------------------------------------------------------Forrás: Online irodalom: Lesson: JDBC Introductionhttps://docs.oracle.com/javase/tutorial/jdbc/overview/------------------------------------------------------------------

Ennek a három programozási nyelvnek a támogatása szinte kötelező az adatbáziskezelő rendszerek számára. A C# a Microsoft által a .NET keretrendszer részeként kifejlesztett objektumorientált programozási nyelv.

A PHP (Hypertext Preprocessor) támogatása szintén előny, amely egy erőteljes szerver-oldali szkriptnyelv, jól alkalmazható dinamikus és interaktív weboldalak elkészítéséhez.------------------------------------------------------------------Forrás: Online irodalom: PHP alapokhttp://web.progtanulo.hu/web-programozas-alapismeretek/3-szerver-oldali-mukodes/32-php-alapok------------------------------------------------------------------

A klasszikus programozási nyelvek támogatása beágyazott ("embedded") SQL technológiával történik.

A COBOL magas szintűprogramozási nyelv, a COmmon Business Oriented Language elnevezés rövidítése.

A Fortran egy olyan programozási nyelv, amelyet elsõsorban matematikai számítások (pl. mérnöki alkalmazások) megkönnyítésére fejlesztettek ki.------------------------------------------------------------------Forrás: Online irodalom: http://nimbus.elte.hu/oktatasi_anyagok/fortran/02_miajo.html------------------------------------------------------------------

Először elég rémisztőnek hangzik az a dolog, hogy a cégem adatait vagy akár a saját adataimat a felhőben tároljam és ne a saját gépemen, de manapság már egyre elterjedtebb dolog. Erre szolgál a PaaS.

A platformszolgáltatás (PaaS) teljes körű fejlesztési és üzembe helyezési környezetet biztosít a felhőben, mindazon erőforrásokkal együtt, amelyek lehetővé teszik, hogy az egyszerű felhőalapú alkalmazásoktól a kifinomult, felhőszolgáltatásokat használó nagyvállalati alkalmazásokig bármit elkészíthessen. Azaz a 'Platform as a Service' egy olyan felhőalapú szolgáltatás, amely Oracle adatbázis környezetet tud biztosítani.De fontos, hogy ennek a gyakorlatban is nagyon működnie kell, ugyanis régebben voltak ezzel kapcsolatosan gondok. Például resetelődött magától a felhasználó jelszava, ami azt jelenti, hogy nem adták ki jól a rendszert, ugyanis ha resetelődött a jelszó, erre még nem volt kidolgozott megoldásuk. Idővel már ezt is kiküszöbölték, de még tavaly is volt példa egy hasonló problémára az egyik szolgáltatónál.A felhő alapú adatbázisoknak azonban számos előnyei vannak:gyorsabb programozásfejlesztési funkciók bővítése a személyzet bővítése nélkülkönnyebb fejlesztés a mobil- és egyéb platformokrakifinomult eszközök költséghatékony használataa földrajzilag elosztott fejlesztőcsapatok támogatásaaz alkalmazás-életciklus hatékony kezelése.A felhő alapú adatbázisokra nagyon jó példa a Microsoft Azure szolgáltatása, amelyet már saját magam is használtam.Az csatolt videóban az Azure rövid bemutatása látható:------------------------------------------------------------------Forrás: Online irodalom: Mi a PaaS?https://azure.microsoft.com/hu-hu/overview/what-is-paas/------------------------------------------------------------------

Régebben a Latin2 kódolás volt. Ma már az Unicode támogatása de-facto szabvánnyá vált.

Az Unicode-nak a legújabb szabványa a 9.0. Ennek a repertoárja 128.000 karakterből áll. A kódolás UTF-8 vagy pedig UTF-16 kódolásban történik. A kettő közül a z UTF-8 kódolást szeretik jobban. A két kódolási fajta abban tér el, hogy egy karakter hány bájtot foglal. UTF-8Az amerikai karakterek 1 bájtosak, a magyar karakterek 2 bájtosak, az angol betűk 1 bájtosak, arabok 1 bájtosak, de a kínaiak és más ázsiai nyelveknél egy karakter 4 bájtos. Egy jó adatbáziskezelőnek UTF-8 kódolásúnak kell lennie. Ha le szeretnénk írni azt, hogy Tamás, az 5 bájtot fog elfoglalni a memóriában. UTF-16Normál karakterek 2 bájt hosszúságúak, tehát a leggyakoriabbak 2 bájtosak, a többi pedig 4 bájtos. Ha le szeretnénk írni azt, hogy Tamás, UTF-16-os kódolással már 10 bájt helyet foglalna a memóriában, ami sokkal több. Ezért is jobb az UTF-8.

A jó adatbáziskezelőnek fontos, hogy át tudjon állni Unicode-ra. Ez a konverzió állásidő nélkül vagy pedig rövid állásidővel elvégezhető. A kódkonverzió azért fontos, ha például egy cég sok nemzetközi kapcsolattal rendelkezik és megérkezik egy holland vevő, akkor valahogy muszáj átállni más kódolásra.

Sajnálatos módon minden szoftver bug-os, ami azt jelenti, hogy sokszor állhat fent számítógépes programhiba. Amikor ez előfordul, akkor a szoftver hibás eredményt ad és a tervezettől eltérően működik. Ezzel a ténnyel minden adatbáziskezelő rendszer esetében meg kell barátkozni.

Amikor döntés előtt állunk és el szeretnénk kerülni a kockázatot, akkor fontos, hogy olyan adatbáziskezelőt válasszunk, amit már több ezren, százezren használtak, hogy az esetleges problémákat, amivel mi is szembesülhetnénk már valaki más észrevegye előttünk és tudjunk belőle okulni. Az a jó adatbáziskezelő szoftver, amit már nagyon sokan alkalmaztak. Fontos, hogy tájékozottak legyünk ezen a területen, tudjuk, hogy melyek a legjobb, legtöbb ember által használt szoftverek. Ha például internet bankingot akarok működtetni, akkor ezen a területen kell nézelődnöm. A telekommunikációs szektorban egyértelműen az Oracle adatbáziskezelő rendszere dominál, szinte "tarol" ebben a mezőnyben. Az olaj iparban pedig az IBM rendszerei dominálnak. Tehát elmondhatjuk, hogy minden ágazatnak van egy domináló szoftvere.Ha valamilyen kételyünk támad a szoftvert illetően, akkor az interneten mindent megtalálunk. Ha például kapunk egy hibaüzenetet és begépeljük a Google-be, akkor találhatunk rá rengeteg megoldást.Manapság azt szokták mondani, hogy a jó adatbáziskezelő rendszer olyan, mint a jó bor: minél öregebb, annál jobb. Azonban annak, hogy egy adatbáziskezelő idős, természetesen vannak hátrányai is, de általában jellemzőbbek az előnyök.

A jó adatbáziskezelő rendszert mindenhol megtaláljuk szerte a világban, ugyanis nagyon sok munkahelyen ugyanazt használják.Az adatbáziskezelő kiválasztásakor nem az a lényeg, hogy a divatos rendszert válasszam, hanem az, hogy olyan rendszert használjak, ami elterjedt, rengeteg helyen használják már, ugyanis ez az elterjedtség számos előnnyel jár:Ha szükségem van egy új alkalmazottra vagy konzultánsra, akkor könnyen találok az alapján, ha olyan rendszert használok, amit például a konkurens cég is, hiszen így könnyen átcsábíthatom a munkaerőt. (Például arra a feladatra, ha IBM-ből kell adatokat átvinni az Oracle-be alig találnánk embert, ugyanis csak 1-2 van, ezért nagyon borsos árat fizetnek is értük.)Szinte állandó a tapasztalatcsere és hogyha valamilyen szakmai jellegű segítségre vagy tanácsra van szükségünk, akkor több helyről is megkaphatjuk. ( Az Oracle például a Balatonnál szokott szervezni nyáron olyan összejöveteleket, ahol ilyen jellegű tapasztalatcsere, valamint szakmai tanácsadás folyik.)

Manapság már egyre fontosabbá válik a 'High Availability', azaz a rendszer magas szintű rendelkezésre állásának a biztosítása. Azonban még most is lennie kell valamiféle állásidőnek, ugyanis néhány szoftvernek, mint például az operációs rendszernek, az adatbáziskezelő rendszernek vagy az adatszótárnak a frissítése eléggé problémás tud lenni.Az elérhetőséget alapvetően a teljes idő azon százalékában fejezik ki, mely alatt egy szolgáltatásnak működnie kell. Például: ha egy rendszer 99%-os elérhetőséggel rendelkezik, akkor az az idő 99%-ban elérhető lesz, míg a maradandó 1%-ban lesz csak elérhetetlen.Az elérhetőség meghatározására a MTBF (mean time between failure) mutató nyújt segítséget, amely kiszámolja a meghibásodások közötti átlagos időtartamot.A internet korában már azt várnák el az adatbázisoktól, hogy az év minden napján leállás nélkül működjenek, de sajnos ez lehetetlen.------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

A leállás minden cég számára nyomot hagy az üzleti tevékenységén és ez bármilyen méretű állásidő költséget is jelenthet. Ez a költség cégenként természetesen változik, de mindenki magának becsüli meg az állásidő költségét. Amikor ezt becsüljük, akkor érdemes három tényezőt figyelembe venni:a leállás során elvesztett üzletek számát,bármilyen per jogi költségeit,a csökkenő részvényértékeket.Az állásidőnek alapvetően két fajtáját ismerjük: a betervezettet, amelyet általában előre bejelentenek, illetve a nem betervezettet, amelyet valamilyen hiba okoz. Természetesen a betervezett leállásnak kisebb állásidő költségei lehetnek, mint a hiba általinak.------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

Az öt kilences kifejezést szokták gyakran használni a magas elérhetőségű rendszerek leírására, ami 99,999%-os működést jelent. Az öt kilences olyan rendszereket ír le, amelyekek alapvetően 100%-osan elérhetőek, de természetesen néhány leállás elkerülhetetlen. Az 99,999%-os elérhetőség évi 5-6 perc leállást jelent, míg a 99%-os már évi 87,6 órát, azaz több mint 3 napot.Oracle esetén a legjobb opció, ami magas rendelkezésre állási képességgel bír az a RAC, ami a fürtözött számítógépeket jelenti. ------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

A relációs adatbázisoknak a de facto szabványa az SQL, de ettől függetlenül még nem szabványosak annyira, hogy egyik szoftverből a másikba könnyen tudjanak a felhasználók adatot átvinni. Ezen a szabványosításon belül, előnynek számít, ha a gyártó betartja az SQL szabványt és annak részleteit. Ha a szabványtól eltérő utasításokat használnak, abból származhat előny is, de egyaránt kockázatosak is. Azért kockázatosak, mert idő múltával, ha adatbáziskezelő váltásáról gondolkodunk, akkor nehéz lesz az adatokat átmásolni az egyik adatbáziskezelőből a másikba. Továbbá megszűnhet akár a szabványokon túlmutató utasításokra vonatkozó támogatás is.

A skálázhatóság esetében arra a kérdésre kell tudni válaszolni, hogy ha növekszik a terhelés, akkor ezzel párhuzamosan lehetséges-e a teljesítmény növelése.

A terhelés vs. teljesítmény problémára, a lineáris skálázhatóság lenne egy jó megoldás. Ez a linearitás azt jelenti, hogy kétszer annyi hardverrel, kétszer annyi munka lenne elvégezve (egyre több számítógép a fürtben, ezeknek működése skálázható-e). De sajnos ez csak egy álom.Az Oracle esetén a skálázhatóságra a RAC (fürtözött számítógépek) lenne a megoldás, ugyanúgy mint a magas rendelkezésre állásnál is.

A ténylegesen várható veszélyeken kívül, illik felkészülni olyan szituációkra is, amelyet az ember egyáltalán nem gondolna: -tűzvész-árvíz-földrengés-terrortámadás -stb.Ezek ellene egyre többen a távoli adatbázis másolatokkal próbálnak védekezni.

Az adatbázis másolatok megoldhatják a hardverek és szoftverek közötti távoli tükrözést is, amely akár extra képességnek is számíthat az adatbázisoknál.Oracle esetén a DataGuard tekinthető katasztrófatűrő megoldásnak. Az Oracle Data Guard magas rendelkezésre állást, adatvédelmet és katasztrófa okozta teljes helyreállítást biztosít.A DataGuardról további információt a csatolt linken olvashattok.

Az idő elteltével nem csak összeomlásról vagy leállásról beszélhetünk a rendszert illetően, hanem akár adatvesztésről is (pl. lemezhiba miatt).Ennek az adatvesztésnek a helyreállítási ideje kritikus is lehet, ugyanis jobb esetben egy néhány perc alatt megvan, de lehet olyan is, hogy több órába telik a teljes visszaállítás. Éppen ezért fontos szempont a helyreállítási módszer egyszerűsége, illetve fontos, hogy legyen megoldásunk arra is, ha valami kellemetlenebb meghibásodás, vagy akár többszörös hiba lép fel. Az adatok könnyebb helyreállítása érdekében pillanatfelvételeket (snapshot-kat) szokott készíteni az adatbázisrendszer adott táblákról és nézetekről. De sajnálatos módon olyan megoldás, ami minden esetben abszolút biztosan működik, olyan nincs.A legoptimálisabb mentési mechanizmus olyan, hogy biztosítja egyszerre a restore-t és a recovery-t is.

Régi mentésre való visszaállás.

Legfrissebb állapotba való helyreállás.

A teljes, azaz a 100%-os adatbiztonság biztosítása az adatbáziskezelőknél lehetetlen. De mégis ajánlatos a szoftver kiválasztása előtt néhány dolognak után nézni, annak érdekében, hogy ha nem is 100%-osan, de biztonságosabban érezhessünk magunkat, hiszen az adatlopások, feltörések nagyon veszélyesek tudnak lenni akár egy cég, akár egy magánszemély számára is.Fontos utánanézni a alábbi dolgoknak:Milyen gyakran törték már fel az adott szoftvert? Hány incidens került erről nyilvánosságra?Ha kiderül egy sebezhetőség, hogyan reagál erre a gyártó?Megtesz-e eleget a gyártó annak érdekében, hogy az újabb sebezhetőségek kialakulását megfékezze?

A merevlemez-alapú adatbázisok esetében az adatok a fájlokban tárolódnak a merevlemezen. Ez a tárolás komoly veszéllyel fenyeget, ugyanis így könnyebb hozzájutni az adatokhoz például eltulajdonítás által. Fontos tehát megfontolni az adattitkosító szoftverek használatát az adatbázis-állományokra. Az adattitkosítás egy olyan biztonsági technika, amely kódolja az olvasható adatokat az állományban. Tehát az adatbáziskezelők a korábban említett veszély ellen adattitkosítással védekeznek. Ilyenkor az történik, hogy maga az INSERT utasítás már titkosítva ír, és ezt a titkosítást a SELECT utasítás tudja visszafejteni.Oracle esetén ezeket az adattitkosító szoftvereket Transparent Data Encryption-nak és Oracle *Net Encryption-nak nevezik.

A csatolt videón a Transparent Data Encryption szoftver felépítését és jellemzőit láthatjuk az Oracle Standard Edition esetén:

A különböző cégeknél gyakran felmerül az a kérdés, hogy vajon kell-e félniük a rendszergazdáktól az adatbiztonságot illetően. Ha félünk a DBA-k, valamint más rendszerek rendszergazdáinak a jogosultságaitól, akkor létezhet olyan megoldás, ahol semmilyen rendszergazda nem férhet hozzá az adatokhoz. Az Oracle adatbázis esetén ezt a fajta megoldást, Oracle Database Vaultnak nevezzük és az Orace Enterprise Edition-ben található meg.Az Oracle Database Vaultról további információk a csatolt linken találhatók.

A csatolt linken három kép található az Oracle Database Vault kinézetéről.

Akkor jó egy adatbáziskezelő rendszer, ha saját mentési programmal rendelkezik, amivel nem csak a mentés valósítható meg, hanem egyúttal a lementett adatok logikai ellenőrzése is. További előny az, hogyha ez a mentési program az adatbázis belsejébe van beépítve. Fontos továbbá az is, hogy a mentési program biztosítsa az alábbi lehetőségeket:online mentés,teljes vagy inkrementális mentési lehetőség,mentési katalógus,lemezre és szalagos egységre történő mentés,mások eszközeivel történő mentés.

A teljes mentés azt jelenti, hogy az adatbázis minden objektumát, és azoknak a teljes adattartalmát képmásolati állományba vagy állományokba menti az adatbáziskezelő-rendszer.

A teljes mentéssel szemben, az inkrementális mentés esetén csak azokat az adatváltoztatásokat menti le a rendszer, amelyek az utolsó mentés óta történtek.

Hatalmas jelentősége van annak, hogyha egy rendszer szakember által monitorozható, ugyanis így kideríthető, hol vannak "dugulási", "elakadási" problémák a rendszerben, amelyeket aztán hangolással ki lehet küszöbölni. Ha a működés még át is paraméterezhető úgy, hogy a szűk keresztmetszetek eltűnjenek vagy csupán enyhüljenek, akkor ebből már rengeteg előnyünk származhat. Azonban fontos, hogy nyílt rendszerekről beszéljünk, azaz a monitorozhatóság SELECT utasításokkal kell, hogy történjen, annak érdekében, hogy a későbbiekben egyre több szakember tudja monitorozni a rendszert.

Mivel manapság már egyre több adatbáziskezelő rendszert működtetünk, a szakembereknek nehéz folyamatosan odafigyelni rájuk, épp ezért nő az automatikus monitorozás jelentősége.Az automatikus monitorozás azt jelenti, hogy a rendszerek saját magukat belülről is figyelik az szakemberek kívülről történő monitorozása mellett, és ha valami probléma, hiba lép föl a rendszer működésében, akkor az automatikusan riasztást küld. Azok a rendszerek a legjobbak, amik a riasztás után nemcsak megoldást javasolnak a probléma kiküszöbölésére, hanem meg is oldják azt automatikusan.Az Oracle esetében ezért az automatikus monitorozásért külön fizetni kell.

Az audit egy olyan adatbáziskezelő rendszerbeli eszköz, amely lehetővé teszi az adatbázis-adminisztrátornak, hogy kövesse az adatbázis erőforrásainak a használatát biztonsági célokból. Mivel az audit opcionálisan eldönthető, ezért ha úgy döntünk, hogy legyen audit, akkor fontos, hogy az auditsor részletessége konfigurálható legyen. Ez az auditsor magában foglalja azt, hogy a művelet milyen adatbázis-objektumokra volt hatással, ki hajtotta végre a műveletet és mikor. Fontos, hogy az audit működtetése nem lassíthatja számottevően a rendszert, de az auditeszközök legnagyobb hibája általában a teljesítménydegradáció.Ha az auditálás mellett döntünk, akkor azt úgy kell csinálnunk, hogy hasznunk származzon belőle!

Szándékosan nem az elsők között került megemlítésre a hatékonyság, mint szempont, ugyanis a relációs adatbázisok választásánál gyakran eshetünk abba a korai hibába, hogy a performancia alapján döntünk.Vannak olyan esetek, amikor ez nem jó, hiszen egy erősebb hardverarchitektúra használata néha több előnnyel jár, mint egy szuper nagy teljesítményűnek gondolt szoftver. Azért mert az adatbáziskezelőket illetően a magas teljesítmény szint a funkcionalitás rovására is mehet. Ha pedig azért gyorsabb egy rendszer, mert nem merevlemez-alapú, hanem a memóriában dolgozik, akkor ennek az a hátránya, hogy magasabb lesz az esélye a sérülékenységnek.A legtöbb rendszer gyártója törekszik arra, hogy optimalizálja a teljesítményt, azaz az adatbáziskezelők hatékonysági mutatóit növeljék. Azt mondják, hogy az újabb szoftverek mindig gyorsabbak, de sajnálatos módon ez 100-nól 99 esetben nem igaz, mert mindig lassabban működnek egy kicsivel, mint a régebbi szoftver.

Az SQL nyelv nagyszerű, de néha lehet nem elég. Az SQL nyelv egy nem procedurális nyelvnek felel meg. Ez azt jelenti, hogy a felhasználó csak azt mondja meg, hogy mit akar. Azt, hogy ez hogyan, és milyen lépések sorozatával valósuljon meg, azt már a nyelvnek az értelmezője fogja meghatározni.Szükségünk lehet bizonyos algoritmusokra és ezek tárolására az adatbázison belül, ezért szükségünk van a funkcionalitás kiterjesztésére.------------------------------------------------------------------Forrás: Online irodalom: Quittner Pál, Baksa-Haskó Gabriella: Adatbázisok, adatbázis-kezelő rendszerekhttp://miau.gau.hu/avir/intranet/debrecen_hallgatoi/tananyagok/jegyzet/25-Adatbazisok.pdf------------------------------------------------------------------

A funkcionalitás kiterjesztése történhet azáltal, hogy maga a gyártó fejleszt ilyen kiterjesztést, vagy pedig a felhasználó is kifejlesztheti a saját kiterjesztéseit (például új függvények bevezetése, amelyek kiszámolják az ÁFá-t vagy az SZJA-t).A funkcionalitás kiterjesztésével a kényszerek halmaza is kibővíthető, továbbá az objektumorientált metódusok is procedurális nyelvben íródnak.Az Oracle esetén két ilyen procedurális nyelv áll rendelkezésünkre.

Nagyon népszerű.

Nem igazán vált be az Oracle adatbázison belül.

Azoknak a cégeknek, illetve embereknek, akik használják az adatbázisokat lehetnek olyan igényeik, amelyek már túlmutatnak az SQL-en, de praktikusak lehetnek.A funkcionalitás kiterjesztése történhet a gyártó által is, ha az adatbázison belül létezik procedurális lehetőség, vagy pedig ha nyílt forráskódú rendszerről beszélünk, akkor maga a felhasználó is kifejlesztheti a saját kiterjesztéseit.

Sokszor felmerülnek különböző igények a gyakorlatban, olyan feladatok hatékony elvégzésére is, amelyek nem SQL-ek.Ilyen nem SQL igénynek számít az adatbetöltés és áthordozás is, melyek megvalósítására a gyakorlatban az Oracle esetén az SQL*Loader és az Oracle Data Dump eszközök nyújtanak segítséget.

Ilyen igény lehet például az adatok betöltése az adatbázistáblákba, ami történhet különböző adattípusú fájlokból:szöveges fix formátumú állományCSV ("Comma Separated Values"Excel táblábólXML állományból.Az adatbetöltésre szolgáló SQL*Loader eszköz használatáról itt látható egy videó:

Igény lehet az adatok áthordozására is adatbázistáblákból bináris állományokba, majd ezeknek a visszatöltése ugyanabba, vagy egy teljesen másik adatbázisba.

Az adatbázis triggerek olyan képességek, ami által bizonyos programok maguktól végrehajtódnak az egyes események bekövetkeztekor, feltételezve azt, hogy a procedurális nyelv már rendelkezésre áll.

Az adatok beszúrása előtt hajtódnak végre, amelyeket általában a beszúrás ellenőrzésére használunk.

Az adatok beszúrás után hajtódnak végre, amelyeket gyakran a műveletek naplózása érdekében használjuk.

Az INSERT utasítás mellett még ugyanúgy használhatóak ezek a triggerek a DELETE és az UPDATE utasítás esetén is, ahol hasonló funkciókat töltenek be. DML triggereken kívül léteznek még olyanok is, amelyek bejelentkezéskor vagy a teljes rendszer elindulása/leállása esetén hajtódnak végre.

Mivel az adatok vándorolnak egyik helyről a másikra, fontos a megbízható tranzakciókezelés két adatbáziskezelő között.

Két Oracle adatbáziskezelő rendszer között az adatátvitel adatbázis link és kétfázisú jóváhagyási mechanizmus által történik.

Két különböző adatbáziskezelő közötti adatátvitel az XA tranzakciók segítségével történik. Az XA protokoll egy ősrégi protokoll, amit még az IBM dolgozott ki. Jobb az az adatbáziskezelő rendszer, amely támogatja ezt az XA tranzakciót, ugyanis ezáltal elképzelhetővé válik a megbízható elosztott tranzakció.

Tranzakciókezelés egy adatbáziskezelő rendszer, valamint egy másik szoftver között, mint például egy üzenetküldő rendszer.Az üzenetküldő rendszer egy üzenettovábbító rendszer, amely ugyanolyan érdekes szoftver, mint az adatbáziskezelő, csak garantálni kell az adatok továbbítását, valamint azt, hogy az adatot a másik fél meg is kapja. A megbízható tranzakció történhet az illető cég specifikus saját módján történő összeköttetéssel, vagy pedig XA protokollon keresztül.

Vannak olyan képességek, amelyekkel a relációs adatbázisoknak szinte kötelező rendelkezniük a zökkenőmentes működés érdekében.

Az adatbázis logikai szerkezetét tekintve, adatbázisunk táblákat, kényszereket, nézeteket, indexeket, stb.. tartalmaz.

DDL, DML, Query

Tranzakciónak nevezzük az SQL, azaz DML műveleteknek azon sorozatát, amely vagy teljes egészében érvényre jut, vagy pedig annak minden módosítása visszavonásra kerül.A tranzakciók arra szolgálnak, hogy logikailag csoportosíthassuk a módosításainkat.------------------------------------------------------------------Forrás: Korábbi előadás diasorai (4. előadás)------------------------------------------------------------------

Az ACID tulajdonság az adatbázisoktól elvárt képességeknek a halmazát jelenti.------------------------------------------------------------------Forrás: Korábbi előadás diasorai (4. előadás)------------------------------------------------------------------

Az atomicitás azt jelenti, hogy a tranzakció során végbement SQL folyamatok sorozatának vagy teljesen egészében érvényre kell hogy jusson, vagy pedig azoknak minden módosítása visszavonásra kell hogy kerüljön. Tehát nem lehet fele véglegesített, másik fele pedig visszavont.

A konzisztencia az adatbázisoknak az a tulajdonsága, hogy tartalmukat a tranzakciók egyik konzisztens (érvényes) állapotából átvezetik egy másik érvényes állapotba.

Az izoláció azt jelenti, hogy megengedett a tranzakciók egy időben történő végrehajtódása, de az eredmény azonos lesz, mintha sorosan, azaz egymás után történtek volna meg a tranzakciók.

A tartósság azt jelenti, hogy ha egy tranzakció már jóváhagyásra került, akkor az végleges, tehát nem tud elveszni még egy áramszünet hatására sem.

Az adatbázis kényszerek adatintegritási szabályok, amelyek a táblákra és azok oszlopaira vonatkoznak, vagy deklaratív adatintegritási szabályoknak is szokták hívni őket. A kényszerek arra szolgálnak, hogy jellemezhessük, illetve korlátozhassuk az adatbázisaink tartalmát.------------------------------------------------------------------Forrás: Korábbi előadás diasorai (7. előadás)------------------------------------------------------------------

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

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

Elérési útvonal: SQL Developer > Connections > Other users > SYS > Tables > IND$A csatolt linken a tábláról található kép.

Elérési útvonal: SQL Developer > Connections > Other users > SYS > Tables > COL$A csatolt linken a tábláról található kép.

Elérési útvonal: SQL Developer > Connections > Other users > SYS > Tables > VIEW$A csatolt linken a tábláról található kép.

Elérési útvonal: SQL Developer > Connections > Other users > SYS > Views > USER_Lekérdezéssel:SELECT * FROM DICTIONARYWHERE TABLE_NAME LIKE 'USER%';A csatolt linken a tábláról található kép.

Elérési útvonal: SQL Developer > Connections > Other users > SYS > Views > DBA_Lekérdezéssel:SELECT * FROM DICTIONARYWHERE TABLE_NAME LIKE 'DBA%';A csatolt linken a tábláról található kép.

Elérési útvonal: SQL Developer > Connections > Other users > SYS > Views > ALL_Lekérdezéssel:SELECT * FROM DICTIONARYWHERE TABLE_NAME LIKE 'ALL%';A csatolt linken a tábláról található kép.

Automatikus végrehajtási terv generátor.