A relációs adatbázisok hatékonysága, hangolása &
SQL optimalizálás

Ahhoz, hogy egy hatékonyan működő adatbázisrendszerrel rendelkezzünk, már a tervezési folyamatok kezdetétől szem előtt kell tartanunk a performanciát, hiszen ha a gyengén megvalósított rendszer a probléma okozója, akkor semmiféle hangolás nem segít a teljesítmény javításában.

Az adatbáziskezelő-rendszer egy nagyobb környezetben működik, amely környezet hardver-és szoftverelemekből tevődik össze. Fontos ezeknek az elemeknek a pontos konfigurálása, valamint telepítése, hiszen ezek akár drámai hatással is lehetnek az adatbázis teljesítményére, ha nem megfelelően járunk el a rendszer architektúra megtervezésének folyamatában.------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

Az adatbázis-alkalmazásokhoz szükséges optimális hardverkörnyezet biztosítása az adatbázis-adminisztrátor feladata. Olyan fontos szempontokat kell figyelembe vennie például, hogy:Megfelelőek-e a hardver képességeiFizikai kapcsolatok teljesen kapcsolódtak-e és működőképesek-eRendelkezik-e a gép megfelelő mennyiségű memóriávalstb..------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

Meghatározó tényező tud lenni a teljesítmény tekintetében a processzoroknak a száma és típusa is, ugyanis egyértelmű, hogy több nagyobb teljesítményű CPU hatékonyabban tud működni.

Az input/output műveletek végrehajtásának a fizikai költségét tekinthetjük az adatbázis-teljesítmény legszűkebb keresztmetszetének. A kódolt adatok kiolvasása a lemezről sok időt vesz igénybe, épp ezért minden, ami az I/O műveleteknek az idejét csökkenti, az növelheti a teljesítményt.Ha magas teljesítményszintet akarunk elérni, akkor célszerű lehet az adatbázis-objektumokat SSD-n tárolni fizikai lemezmeghajtó vagy RAID helyett.------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

Az Oracle RAC esetében szintén fontos a fürtözött számítógépeknek a száma, ugyanis ez is befolyásolja a rendszer hatékonyságát, performanciáját.

A szolgáltatás szállítását a végfelhasználóhoz azáltal lehet biztosítani, hogy az adatbáziskezelő-rendszer más szoftverkomponensekkel is kapcsolatban áll. Ilyenek például az üzenetsorba-állító szoftverek, a tranzakció feldolgozók, a hálózati és a web kapcsolódási és -fejlesztő szoftverek vagy akár a tűzfalak, messaging rendszerek.------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

Az alkalmazás általános architektúrája is lényeges tényező, hogy például melyik műveletből mennyi lesz és ezek alapján a várható hatékonysági problémák konkretizálása.Erre az esetre egy egyszerű példa a nem olyan rég bevezetett NAV által ellenőrzött online pénztárgépek. Nem mérték föl jól a műveletek gyakoriságát, ezért túlterhelt lett a rendszer és összeomlott.

A skálázhatóság esetében arra a kérdésre kell tudni válaszolni az adatbázis-adminisztrátornak, hogy tud-e az adatbáziskezelő-rendszer annyi felhasználót és akkora adatbázisméretet támogatni, amelyet meg szeretnénk valósítani? Ugyanis, ha nem, akkor nem kell túlzott hatékonyságra számítani.------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

A realisztikus terheléses tesztek végzése fontos egy rendszer bevezetését megelőzően, hogy elkerülhető legyen a rendszer összeomlása. Erre a korábban írt NAV-os példát említeném meg újra, ahol nem végeztek ilyen terheléses tesztet, hiszen akkor elkerülhető lett volna a teljes rendszerösszeomlás.De erre a terheléses tesztek végzésére pozitív példaként szolgál annak az olasz cégnek a története, aki a rendszer bevezetése előtt rengeteg (kb. 2000) ügyintézőt hívott össze, hogy a számítógépeken kattintgassanak "össze-vissza" annak érdekében, hogy kiderüljön mennyit bír a rendszer az élesbe állítása előtt.

Kulcskérdés a hatékonyság terén a performancia-adatok viszonyítási szintje, vagy más néven a baseline.

A performancia-elvárásokat illetően van néhány tulajdonság, aminek teljesülnie kell. Fontos, hogy az elvárások számszerűsíthetőek, mérhetőek és konkrétak legyenek. Ez azt jelenti, hogy határozottan ki kell tűzni egy célt. Például tudom, hogy a válaszidő 13 mp, a cél, hogy ezt leszorítsam 8 mp-re. De azért fontos az is, hogy elérhetőek legyenek ezek kitűzött célok, azaz ne 2mp-re akarjam lecsökkenteni a jelenleg 13mp-es reakcióidőt.

SLA (Service Level Agreement): szolgáltatási szintről szóló megállapodás.A szolgáltatási szintnek a kezelése egy proaktív módszertannak számít.Ilyen megállapodás lehet például az, hogy:a tranzakciók 99%-át COMMIT-tal kell befejezni, vagyaz időnek legalább a 95%-ában működnie kell az adatbázis-alkalmazásnak, stb.Minél szigorúbb a szolgáltatási szint, amiről szól a megállapodás, annál nehezebbé válik az adatbázis-adminisztrátoroknak a szolgáltatás teljesítése.Például ha a megállapodás a tranzakcióktól másodperc töredéknyi idejű válaszidőt követel, akkor ennek teljesítése sokkal bonyolultabb, mint ha három másodpercnyi válaszidőt követelnének. ------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

A szoftverberuházást illetően érdemes jól megfontolni, hogy melyik adatbáziskezelő rendszert választjuk. Ha az Oracle RDBMS-t választjuk, akkor több típus közül választhatunk, amelyek más-más kondíciókkal bírnak. Enterprise Edition vagy Standard Edition: az Enterprise Edition óval drágább, de több funkcióval van ellátva és gyorsabb is, illetve ha az Enterprise-t választjuk, akkor partícionálási opciót is választhatunkRAC vagy egységes "single instance" változat: a RAC változat a drágább, mivel az a több gépes változat, de hatékonyabb is Diagnostic Pack vagy Diagnostic+Tuning Pack: a Diagnostic Tuning Pack esetében már megjelennek az automatizálások isVálaszthatunk Advanced Compression Option-t is, azaz eldönthetjük, hogy szeretnénk-e tömöríteni vagy sem, ugyanis ez az opció maximalizálja a tárhely használatot, valamint költséghatékony megoldás a teljesítménynövelés terén.

Az adatbázis hangolás azt írja le, hogy az adatbázis tervezésével hogyan tudunk a legeredményesebben teljesítménynövekedést elérni. Ez az adatbázis terv magába foglalja a logikai sémát (táblák, egyéb megszorítások), valamint a fizikai sajátosságokat (indexek, lemezrendszer, objektumelhelyezés).Az adatbázisok performancia növelésének a céljai:a lekérdezések válaszidejének a minimalizálásaaz adatbázisszerver áteresztőképességének a maximalizálásamindez a lemez I/O műveletek és a processzoridő csökkentésével.------------------------------------------------------------------Forrás: Online irodalom: Adatbázisok teljesítményének optimalizálásahttp://softwareonline.animare.hu/cikk.aspx?id=3853------------------------------------------------------------------Az itteni információkon felül a teljes dokumentáció a témához megtalálható az Oracle weboldalán a csatolt linken.

Az adatbázis hangolásához szorosan kapcsolódik az adatbáziskezelő rendszernek a hangolása is. Az ORACLE adatbáziskezelő rendszer esetén "Instance and Database Tuning"-ról beszélhetünk, mely hangolási folyamat tartalmazza az adatbázis hangolása mellett az Oracle példány hangolását is, amelyhez csatlakozik a felhasználó.

Az adatbáziskezelő-rendszerek nagyon összetettek. Ahhoz, hogy az adatbázis-adminisztrátor megfelelően tudja biztosítani az optimalizált környezetét az adatbázis-alkalmazásoknak, nélkülözhetetlen az adatbázis-kezelő rendszer belső működésének a hiánytalan ismerete. Éppen ezért vannak olyan kezdeti adatbázis és példány konfigurálások, amelyeket érdemes figyelembe venni.

Az adatbáziskezelő-rendszerek rendelkeznek olyan paraméterekkel, amelyek módosításával lehetővé válik az adatbázis-környezet módosítása. A paraméterek változtatása adatbáziskezelő-rendszer specifikus.Az Oracle esetében ez a módosítás az init.ora paraméterállományok megfelelő beállításával történhet.A csatolt képen láthatjuk az Oracle-nek az inicializációs paraméterállományát. Az Oracle-nek ez az egyik eszköze ahhoz, hogy a paramétereket módosítani tudja.------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

Az adatok konzisztenciáját az adatbáziskezelő-rendszer naplóbejegyzések által tudja biztosítani. Ebből kifolyólag rengeteg naplóállomány tárolódhat, melynek száma és mérete is nagy mértékben befolyásolhatja az adatbázis teljesítményét. Ezért fontos kérdés az, hogy az adatbázisnapló-állományokat hogyan kezeljük, ha betelnek. Ez a tényező is adatbáziskezelő-rendszer specifikus, de az Oracle esetében automatikus naplókimentésről (offloading) beszélhetünk. Ez egy archiválási folyamat, melynek során a naplózás egy új aktív naplóba történik, míg a régi aktív napló tartalma pedig egy archív naplóba mentődik.------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

Ha az adatbáziskezelő-rendszer automatikus archiválást hajt végre, akkor a teljesítményt azzal lehetne növelni, hogy a mentés nem szalagon történne, hanem lemezen. A lemezre való archiválással a folyamatok gyorsabban futnak le és a mentési, helyreállítási folyamatok, valamint az I/O műveletek is gyorsabbak lesznek. ------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

A táblaterek az adatbázisnak az objektumai. Az adatbáziskezelő-rendszertől függ az, hogy egy tábla adatai több táblatérbe is bekerülhet-e. Az adatbázis-adminisztrátor dönti el, hogy a táblákat hogy rendeli a táblaterekhez. Ezeknek a táblatereknek a megfelelő beállítása nagyon fontos szempont a teljesítményt illetően, ugyanis többféle beállítás létezik: lokálisan karbantartott, automatikus szegmens karbantartású, fix méretű,automatikusan növekvő. Továbbá az UNDO táblaterek pontos konfigurálása és megfelelő használata is fontos tényező. Az UNDO táblaterek a módosított értékek tárolására hivatottak. ------------------------------------------------------------------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ázisok imádják a memóriát. Annál jobb lesz az adatbáziskezelő-rendszer teljesítménye, minél több memóriát biztosítunk neki. Éppen ezért fontos a memóriaterületeknek a helyes méretezése.Minden adatbáziskezelő-rendszer különböző dolgokra, különböző mennyiségű memóriát használ.Az Oracle bizonyos "granule"-ökben gondolkozik. A granule a virtuális memóriának az egysége. Ha az SGA mérete kevesebb, mint 1 GB, akkor a granule mérete általában 4MB. Azonban ha az SGA mérete nagyobb, mint 1 GB, akkor a granule mérete megnő 16 MB-ra.Ha szeretnénk megtudni a saját példányunk pontos granule méretét, akkor az alábbi kóddal kérdezhetjük le:SELECT * FROM v$sgainfo WHERE name = 'Granule Size'; Az eredmény: (minta)NAME BYTES RES -------------------------------- ---------- --- Granule Size 4194304 No ------------------------------------------------------------------Forrás: 1. Online irodalom: Oracle instance, Granulehttp://www.orafaq.com/wiki/Granule2. Online irodalom: Oracle dokumentáció, Dynamically Changing Cache Sizeshttps://docs.oracle.com/cd/B19306_01/server.102/b14211/memory.htm#i60086------------------------------------------------------------------

Egy másik értékes teljesítményhez kapcsolódó feladat az erőforrás használati információk és a teljesítménystatisztikák összegyűjtése és elemzése. Az adminisztrátorok nyomon tudják követni a kulcsfontosságú teljesítménystatisztikákat, mint például az input/output műveleteket, naplóváltásokat, pufferek használatát és ezeket a történeti információkkal együtt nyomkövetési táblákban tárolhatják az adatbázisban. Ezek a folyamatok is a performancia adatok begyűjtésére szolgálnak.A feltérképezés során az első lépés, amely egyben a legnehezebb lépés is, a legproblémásabb területek azonosítása. Ez a lépés a 80/20-as szabályt, vagy más néven Pareto-elvet követi, amely egy régi alapelv. Ez az alapelv azt állítja, hogy 80%-a az eredménynek 20% erőfeszítésből származik.------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

A performancia adatok feltérképezése történhet közvetlen lekérdezésekkel is a V$ nézetekből, ahogyan azt az Adabázis statisztikák, monitorozás résznél már megemlítettem.

Az Oracle rendelkezik egy úgynevezett "önmonitorozó motorral", azaz ADDM-el (Automatic Database Diagnostic Monitor), amely lehetővé teszi az Oracle számára, hogy diagnosztizálja az saját adatbázisának a teljesítményét és segít megfogalmazni az azonosított problémákra szolgáló megoldásokat.Az ADDM az általa végrehajtott probléma analíziseket az AWR-ben ("Automatic Workload Repository") tárolja.------------------------------------------------------------------Forrás: Online irodalom: Oracle documentation, Performance Self-Diagnostics: Automatic Database Diagnostic Monitorhttp://docs.oracle.com/database/122/ADMQS/monitoring-and-tuning-the-database.htm#ADMQS1012------------------------------------------------------------------Az itteni információkon felül a teljes dokumentáció a témához megtalálható az Oracle weboldalán a csatolt linken.

A valós idejű ADDM az adatbázis automatikusan a valós időben monitorozza. A real-time ADDM kinyomozza és diagnosztizálja a nagy hatású problémákat mielőtt fenyegetést jelenthetnének az alkalmazás teljesítményre. Ilyenek például:magas CPUmemória problémákszorosan összefüggő problémákfennakadások és kidolgozhatatlan helyzetekCsatoltam egy képet, amely leírja a sima ADDM és a valós idejű ADDM reportok közötti különbségeket.------------------------------------------------------------------Forrás: Online irodalom: Oracle documentation, Performance Self-Diagnostics: Automatic Database Diagnostic Monitorhttp://docs.oracle.com/database/122/ADMQS/monitoring-and-tuning-the-database.htm#ADMQS1012------------------------------------------------------------------

Az Oracle periodikusan AWR pillanatfelvételeket gyűjt az adatbázis állományokról, valamint a munkaterhelésről, megkönnyítve ezzel az ADDM teljesítmény monitorozását. Ezeket a pillanatfelvételeket az ADDM teljesítmény összehasonlításra használja föl, ugyanis ezek a pillanatfelvételek folyamatos készenlétben remek statisztikai összefoglalót nyújtanak a rendszer állományokról. Ezek a felvételek az Automatic Workload Repository-ban tárolódnak, SYSAUX táblatérben. Ezek a pillanatfelvételek egy meghatározott idei tárolódnak csak az AWR-ben. Általában 8 nap az alap tárolási idő, ez után törlésre kerülnek helyet csinálva az új felvételeknek.A csatolt videóban látható az AWR pillanatfelvételek olvasása, elemzése.------------------------------------------------------------------Forrás: Online irodalom: Oracle documentation, Performance Self-Diagnostics: Automatic Database Diagnostic Monitorhttp://docs.oracle.com/database/122/ADMQS/monitoring-and-tuning-the-database.htm#ADMQS1012------------------------------------------------------------------

A teljesítmény adatok monitorozás GUI felületen keresztül is történhet az Oracle Enterprise Manager segítségével. Az Oracle Enterprise Manager egy olyan előrebocsátott menedzsment platform, amely egyedülálló felületet nyújt egy felhasználó minden Oracle telepítésének menedzselésére, legyen az adatbázis akár az Oracle felhőben, vagy pedig az ő adatközpontjukban.A csatolt videóban láthatjuk a GUI felületen történő monitorozás folyamatát az Enterprise Manager használatával.------------------------------------------------------------------Forrás: Online irodalom:http://www.oracle.com/technetwork/oem/enterprise-manager/overview/index.html------------------------------------------------------------------

Az Active Session History statisztikák az adatbázisban található session-ök aktivitását elemzik. Az adatbázis minden másodpercben mintát vesz az aktív session-ökről, majd tárolja azokat kör alakú pufferekbe az SGA-ba (System Global Area).Az alábbi linken található egy példa az Oracle dokumentációból az ASH-ra.https://www.dropbox.com/s/u4lsieausteeyz4/ASH.png?dl=0Továbbá a csatolt linken található egy videó, amiben az ASH használata kerül bemutatásra.------------------------------------------------------------------Forrás: Online irodalom: Oracle documentation, Active Session History Statisticshttp://docs.oracle.com/database/122/TDPPT/oracle-database-performance-method.htm#TDPPT011------------------------------------------------------------------

A metrika a változások arányát, mértékét jelenti a kumulatív statisztikában. Például egy metrikának számít az egy másodperc alatt történő adatbázis lekérdezések száma.A teljesítmény riasztások ezeken a metrikákon alapszanak. Ezek szerver által generált teljesítmény riasztások nagy mértékben alkalmazás- és környezetfüggők.------------------------------------------------------------------Forrás: Online irodalom: Oracle documentation, Setting Metric Thresholds for Performance Alertshttp://docs.oracle.com/database/122/TDPPT/monitoring-performance-alerts.htm#TDPPT046------------------------------------------------------------------

A teljesítményproblémák, valamint a teljesítménycsökkenés miatt állandóan figyelni kell az adatbázis-kezelő rendszernek a környezetét.Azonban a teljesítménymonitorozás nem csak az adatbáziskezelő-rendszerre vonatkozik, hanem a rendszerkörnyezetre is. Monitorozni kell az operációs rendszert, a hálózatot, valamint a tranzakciós szervert is és stb.. Minden típusú hangolásnak a monitorozás és a statisztikák készítése az alapja, ezért fontos, hogy az adatbázis-adminisztrátorok megértsék és tudják megfelelően kezelni a monitorozás outputját. A diagnosztizálásban és a statisztikák elkészítésében a dinamikus performancia táblák (X$ táblák, V$ nézetek) nyújtanak segítséget. A dinamikus performancia nézetek abból a szempontból hasznosak, hogy segítenek az instance-szintű teljesítményproblémák azonosítására. Az X$ táblák belső adatszerkezetek reprezentálásai, amelyek SQL utasítások által kerülhetnek feldolgozásra. Ezekről a táblákról nézetek készülnek, amelyekről pedig további publikus nézetek (V$), amelyek már egy átlag felhasználó számára is elérhetőek. Ezek a nézetek segítséget nyújtanak a teljesítmény hangolásban.------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------Az itteni információkon felül a teljes dokumentáció a témához megtalálható az Oracle weboldalán a csatolt linken.

Egyes adatbázis-statisztikák mintavételezésen alapulnak és többnyire kumulatívak, azaz összegyűjtő jellegűek. Sok közülük "Time Model" típusú, ami azt jelenti, hogy olyan statisztikák amik egymást közti arányokat mérnek. Például azt mérheti, hogy mennyi volt a bejelentkezési és kijelentkezési időarány. Rendelkezhetünk olyan statisztikai adatokkal is a közelmúltról, amik a memóriában és az adatbázisban tárolódnak, de ez csak akkor elérhető számunkra, ha rendelkezünk Diagnostic Packkal.

A példány központi sikerszámai.

A munkamenetek adatai.

A szegmensek használata.

SQL utasítások terhelése.

Statisztikai adatok a közelmúltról.

Általában a teljesítmény problémák elfogadhatatlan válaszidőt eredményeznek. A tipikus ilyen teljesítmény problémák:CPU -hoz kapcsolódó szűk keresztmetszetek, fennakadásokAlulméretezett memória struktúraAdatbázis konfigurációs problémákVersengési problémák fellépése az erőforrásokértVáratlan teljesítmény csökkenés az SQL lekérdezések hangolását követőenI/O erőforrások nem megfelelő kihasználásaEredménytelen és magas munkaterhelésű SQL lekérdezések.------------------------------------------------------------------Forrás: Online irodalom: Oracle documentation, Performance and Tuninghttp://docs.oracle.com/database/122/CNCPT/concepts-for-database-administrators.htm#CNCPT1379------------------------------------------------------------------

Az adatbázis-adminisztrátornak a teljesítmény optimalizáláshoz az adatbáziskezelő-rendszer eszközei közül a legmegfelelőbb technikát kell alkalmazniuk. A legtöbb adatbáziskezelő-rendszer támogatja a következő technikákat, legfeljebb más-más néven.------------------------------------------------------------------Az adatbázisok optimalizálási technikáinak rövid ismertetőjének a forrása: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

A particionálás során az adatbázistáblákat több részre osztjuk, amelyek külön állományba fognak torlódni.

Az adatbázis-adminisztrátor feladata, hogy válasszon a raw partíció, vagy az állományrendszer között az adatok tárolására. Állományrendszer esetén az írásokat az operációs rendszer puffereli, míg ha raw partíciót használunk, akkor az adat az adatbázis-gyorsítóból közvetlenül a lemezre kerül, nincs köztes állomány-rendszerbeli, vagy operációs rendszerbeli gyorsítótár.

Amikor új adatot akarunk tárolni, akkor fontos, hogy a táblatér adatlapjainak egy része üres és elérhető legyen. Ha az egyes adatbázis-objektumokhoz megfelelő mennyiségű szabad helyet biztosítunk, akkor a beszúrás gyorsabb lesz. Hátránynak számít azonban az, hogy a keresés elhúzódhat, illetve a tárolási követelmények nagyobb lesznek.

Az adatbázis méretek csökkentésére szolgál a tömörítés, ami által az adatbázisnak kevesebb lemezterületre lesz szüksége.

Fontos, hogy az adatokat a fizikai lemezeszközön úgy kell elhelyezni, hogy a teljesítmény a legoptimálisabb legyen. Ha betartunk néhány szabályt, akkor eredményes lehet az állományelhelyezés a performanciát illetően.Ha lehetséges, akkor az indexeket és adatokat tartalmazó állományok elkülönítése.Alkalmazások adatkéréseinek az elemzése.Particionált táblák esetén: az egyes állományok külön lemezre való helyezése.

Megfelelő adatlap méret a hatékony adattároláshoz és az I/O műveletekhez.

Az adatbázis-adminisztrátor adatbázis vagy táblatér újraszervező segédprogramot (REORG) tud futtatni az adatbázis-objektumok újrastrukturálása érdekében, ugyanis az adatstruktúrák egy idő után szétszórttá válhatnak.

Az egyik tipikus probléma az adatbázisok esetében az különböző erőforrások nem megfelelő kihasználása, ami nagy hatással van a teljesítményre.

Fontos tisztában lenni az aszinkron I/O helyes használatával. Az aszinkron I/O során azt történik, hogy az I/O műveletek várakozási sorba kerülnek, és végrehajtásuk független lesz a műveleteket kérő szálaktól. Ez a végrehajtás lehetővé teszi, hogy amíg az I/O művelet végrehajtásra kerül, addig a műveletet kérő szál folytathassa a feladatát.------------------------------------------------------------------Forrás: Online irodalom: IBM, Aszinkron I/Ohttps://www.ibm.com/support/knowledgecenter/hu/SSGU8G_11.50.0/com.ibm.admin.doc/ids_admin_0300.htm------------------------------------------------------------------

Ha egy lemeznek az I/O teljesítményproblémája definiálva van, akkor erre megoldásként szolgálhat az ASM (Automatic Storage Management), amely az adatbázis háttértárjának menedzselésével foglalkozik. Ez a eljárás sokkal hatékonyabb, mint a hagyományos fájlrendszer.

A S.A.M.E. (Stripe and Mirorr Everything) egy néhány éve az Oracle által kifejlesztett módszertan, ami segít optimalizálni a magas elérhetőséget, teljesítményt és megvalósíthatóságot. Azért, hogy leegyszerűsödjön a konfiguráció, egy fix 1 MB lemezméret az ajánlott a S.A.M.E. eljárásban. Az ASM implementálta ezt a módszertant és mindennek tetejében még automatizálta is.------------------------------------------------------------------Forrás Online irodalom: Oracle documentation: Stripe and Mirror Everything (S.A.M.E.)https://docs.oracle.com/cd/B28359_01/server.111/b32024/vldb_storage.htm------------------------------------------------------------------

A teljesítmény és a karbantarthatóság a rendszernek két olyan jellemzője, amelyek egymás ellen hatnak. A karbantarthatóság alatt olyan dolgokra kell gondolni, hogy például a rendszer monitorozható legyen, valamint automatikus mentést végezzen.

Az adatbáziskezelő-rendszereknél konfigurációs opció vezérelheti a jogosultságok és a biztonság funkcionalitását. Néhány adatbáziskezelő-rendszer engedélyezi azt, hogy külső szoftver vezérelje az adatbiztonságot.------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

Az Oracle Database Resource Manager lehetővé teszi az erőforrás allokáció optimalizálását az együttműködő adatbázis session-ök között, azaz garantált az erőforrás allokáció, tehát úgymond mindenkinek fog jutni az erőforrásokból. Az Instance Caging pedig egy egyszerű módja annak, hogy korlátozni lehessen a CPU-nak a "fogyasztását".------------------------------------------------------------------Forrás: Online irodalom: Oracle Documentation: Managing Multiple Database Instances on a Single Serverhttps://docs.oracle.com/html/E25494_01/dbrm008.htm------------------------------------------------------------------

Az operációs rendszer és a különböző alrendszerek hangolása fontos dolog, hiszen ha valamiféle teljesítményproblémát tapasztalunk az operációs rendszerben, akkor minden szoftvernek, ami ezen az operációs rendszeren fut teljesítmény problémája lesz.

Első lépésként definiálni kell a problémát és ezáltal számszerű célokat kell kitűznünk.

Második lépésként az adatbázisról és az operációs rendszerről statisztikákat kell gyűjteni. Az adatbázis statisztikák elkészítéséhez a dinamikus performancia táblák (X$-táblák, V$-nézetek) szolgálnak segítségül. A V$-nézetekből információt kapunk a munkamenetekről, az SQL utasítások terheléséről, valamint a szegmensek használatáról is.

Harmadik lépésként az adatok megvizsgálása után a szűk keresztmetszet keresése következik. Ezt úgy is elképzelhetjük mintha csövekről beszélnénk, és azt szeretnénk, hogy a csövekben ne legyenek dugulások, hogy minél több víz juthasson át. A dugulások jelenti az elakadásokat, problémákat, amelyeket meg szeretnénk oldani. Miután az egyik dugulást elhárítottuk, jöhet a következő.. és így tovább. A szűk keresztmetszetek megoldására olyan ötleteket gyártunk, amelyekkel lehetne enyhíteni vagy akár meg is szüntetni a problémát.

Negyedik lépésként azt az ötletet, amit az előző lépésben kiötlöttünk, implementáljuk a hatékony problémamegoldás érdekében.

Végül pedig újra felmérjük az adatokat, újabb elemzéseke végzünk és leellenőrizzük, hogy megoldódott-e a probléma.Ha nem oldódott meg, akkor visszatérünk a 3. lépéshez újabb ötletet keresni. Ha megoldódott, akkor pedig feltesszük azt a kérdést magunknak, hogy elértük-e a célunkat. Ha nem értük még el, akkor ugyanúgy visszatérünk a 3. lépéshez, és keressük a következő problémát. Ha megoldódott, akkor pedig szerencsések vagyunk, hiszen abbahagyhatjuk a folyamatot.

A hangolási folyamatnak a célja az, hogy a létező problémákat, amelyek elakadást, valamint lassabb teljesítményt és hatékonyságot okoznak feltárják, aztán pedig minél nagyobb sikerrel kiküszöböljék ezeket a problémákat. A célt, azaz a performancia növekedést leginkább az alrendszerek minél hatékonyabb kihasználásával lehet elérni. Gondolok itt az input/output alrendszerre, valamint a diszk alrendszerre, azaz a RAM-ra ("caching"). A teljesítménynövekedéshez akár horizontális skálázhatóság által is el lehet jutni.

A hangolási folyamat legfontosabb szereplője a DBA, de nagyon fontos az operációs rendszer, valamint a diszk alrendszer rendszergazdájának a hozzájárulása is. Hatalmas segítség lehet a megfelelő kommunikáció és együttműködés is a fejlesztő csapattal.Fontos megjegyezni, hogy az adatbázishangolás, minden adatbáziskezelő-rendszer esetén más és más, ugyanis ezek a hangolási folyamatok általában az adatbáziskezelő-rendszerekre vannak specifikálva.A statisztikák szerint átlagosan kb. 10%-os teljesítménynövekedésre számíthatunk egy-egy hangolási folyamat elvégeztével.Jelen esetben mi az Oracle adatbázis-kezelő rendszer esetén vizsgáljuk meg az adatbázis és a példány hangolási menetét.

Ha szeretnénk javítani az SQL adatbázisunknak a performanciáját, valamint szeretnénk gyorsítani a lekérdezéseket is, akkor az adatbázis logikai és fizikai struktúráján és elhelyezkedésén kívül, meg kell vizsgálnunk a lekérdezéseket is, ugyanis nagy mértékben függ tőlük az adatok rendelkezésünkre bocsátásának a gyorsasága és hatékonysága is.Azonban néha nem az SQL a gond, hanem azoknak a beillesztése az alkalmazásba, ekkor már az alkalmazásnak a hangolásáról beszélhetünk. ------------------------------------------------------------------Forrás: Online irodalom: Lekérdezések vizsgálatahttp://softwareonline.animare.hu/cikk.aspx?id=3976------------------------------------------------------------------Az itteni információkon felül a teljes dokumentáció a témához megtalálható az Oracle weboldalán a csatolt linken.

Az alkalmazások és az SQL hangolását leginkább a fejlesztők végzik, de gyakran a DBA-kal együttműködve. Jobb híján néha a DBA végzi a hangolást, mert nincs fejlesztő a közelben. Ugyanis manapság gyakoriak a külső fejlesztések, aztán mire a lényegi részhez érnek elfogy a támogatás és a DBA-ra marad a feladat. Gyakran nagyságrendekkel tudunk felgyorsítani egy SQL-t , nem úgy mint az adatbázis hangolásnál, azonban ez csak egy SQL, ami egy kicsiny része csak a nagy egésznek. Gyakran előfordul az is, hogy az adatbáziskezelő-rendszer miatt kell hangolni SQL-eket, azért mert nem éppen a legoptimálisabb terv készül el, mivel az SQL nem egy procedurális nyelv, azaz a gép készíti el a végrehajtási tervet. A jövőre nézve mindenféleképpen az a cél, hogy ne kelljen SQL-t hangolni.

A tapasztalatok azt mutatják, hogy az adatbázisok teljesítményproblémáinak a a 75-80%-a a szegényesen kódolt SQL utasításokra vagy alkalmazás logikára vezethető vissza. Ez nem azt jelenti, hogy az SQL utasítások rosszak, hanem hogy idővel ezeknek a teljesítménye csökkenhet. Sok probléma okozhatja az SQL-ek gyenge teljesítményét: megfelelő indexek hiányanem optimális sorrendű tábla összekapcsoláselavult adatbázis-statisztikaallekérdezési formulák hatékonysága nem megfelelő, stb..Nagyon nehéz feladat tud lenni a legköltségesebb SQL utasítások megtalálása, de ezután a megfelelő hangolás és kódolás is nagyon bonyolult feladat. ------------------------------------------------------------------Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

Az SQL hangolás egy iteratív folyamat annak érdekében, hogy:a lekérdezéseknek csökkenjen a válaszidejük, illetveaz átmenő teljesítmény fejlődjön, amit az erőforrás használat csökkenésével lehet elérni.Fontos a célkitűzésnél annak meghatározása is, hogy a hangolással a célunk egyfajta felgyorsítás, vagy csupán a lelassulás folyamatának a megakadályozása. ------------------------------------------------------------------Forrás: Online irodalom: Oracle dokumentációhttp://docs.oracle.com/database/122/TGSQL/introduction-to-sql-tuning.htm#TGSQL114------------------------------------------------------------------

Ha SQL-t szeretnénk hangolni, nélkülözhetetlen néhány készség, valamint tudás ezzel kapcsolatban: megfelelő jártasság az Oracle adatbázis architektúráját illetőenSQL és a PL/SQL nyelv ismeretemegfelelő jártasság az adatbázist támogató SQL hangolási eszközök terénaz alkalmazás logikájának és az adatok természetének az ismerete.

------------------------------------------------------------------Forrás: Online irodalom: Oracle dokumentációhttp://docs.oracle.com/database/122/TGSQL/introduction-to-sql-tuning.htm#TGSQL115Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html------------------------------------------------------------------

A proaktív hangolás során rendszeresen az SQL Tuning Advisor, mint automatikus hangolási eszköz kerül használatra annak érdekében, hogy megoldást találjunk arra, hogyan lehetnének jobbak a lekérdezéseink. A proaktív teljesítménykezelés előre kigondolt, tervezett és automatizált folyamat, amely csökkenti a reaktív monitorozást és hangolást. Így ez a proaktív hozzáállás csökkenti a ráfordított időt, erőfeszítést és az emberi hibát is.

A reaktív SQL hangolás során azokat a lekérdezésekkel kapcsolatos problémákat javítjuk ki, amelyeket a felhasználó tapasztalt. A teljesítményproblémák reaktív kezelése nem egy rossz dolog, de ez kézi hangolási módszernek számít, ezért nagyon időigényes feladat.

Az itteni információkon felül a teljes dokumentáció a témához megtalálható az Oracle weboldalán a csatolt linken.

Az SQL hangolásra használt eszközök lehetnek automatikusak vagy pedig kézik. Ha az adatbázis saját magának biztosítani tud diagnózisokat, tanácsokat vagy módosító eljárásokat, akkor automatikus hangolási eszközökről beszélhetünk. A kézi hangolási eszközök igénylik magát a felhasználót ezeknek a folyamatoknak a véghezviteléhez.Minden hangolási eszköz függ a dinamikus performancia nézetek alap eszközeitől, valamint a statisztikáktól és a metrikáktól.Az automatikus eszközök elterjedésével az ember, azaz a kézi hangolás egyre jobban kiszorul, és automatizált lesz az SQL hangolás.------------------------------------------------------------------Forrás: Online irodalom: Oracle dokumentációhttp://docs.oracle.com/database/122/TGSQL/introduction-to-sql-tuning.htm#TGSQL118------------------------------------------------------------------

A végrehajtási terv egy fő elemzési eszköze a kézi SQL hangolásnak. A felhasználó meg tudja nézi a terveket, ami alapján eldöntheti, hogy az optimalizáló vajon azt a tervet választotta-e, amit a felhasználó várt.A végrehajtási terv fa szerkezetű, amely a következő dolgokról szolgál információval:optimalizáció,particionálás,parallel végrehajtás.Megkülönböztetünk soros és parallel tervet. A kettő között az a különbség, hogy míg a soros (szekvenciális) terv alaplépéseit a gép egymás után végzi el, annak érdekében, hogy előállítsa az eredményt, míg a parallel terv esetében pedig egymással párhuzamosan futnak az alaplépések.A PARSE során két folyamatot különböztetünk meg.Soft Parse, mely során az adatbáziskezelő-rendszer már a gyorsítóban megtalálja a tervet.Hard Parse, mely akkor készíti el a tervet és majd azután teszi be a gyorsítóba.A bind változók használatával csökkenteni tudjuk a HARD PARSE-ok számát.Erre láthatunk egy példát a csatolt képen, valamint egy videóban további információkat kaphatunk erről: ------------------------------------------------------------------Forrás: Online irodalom: Oracle dokumentációhttp://docs.oracle.com/database/122/TGSQL/generating-and-displaying-execution-plans.htm#TGSQL95114------------------------------------------------------------------

A joinok összekapcsolódásának a sorrendje.

A join metódus egy mechanizmus két "row sources" összekapcsolására. Ez a metódus függ a statisztikáktól, illetve attól hogy az optimalizáló melyik metódust választja a legalacsonyabb költség elérése érdekében.Három féle metódust különböztethetünk meg:Nested Loop Join: egy külső adathalmazt kapcsol össze egy belső adathalmazzal.Hash Join: az adatbázis a hash joint a nagyobb adat halmazok összekapcsolására használja. Az optimalizáló a két adathalmaz közül a kisebbiket használja fel a hash tábla megépítéséhez a memóriába.Sort Merge Join: egy variációja a nested loop join-nak. Ha a join-ban van két adathalmaz, ami még nincs elkülönítve, akkor az adatbázis elkülöníti őket. Ezek lesznek SORT JOIN operátorok.------------------------------------------------------------------Forrás: Online irodalom: Oracle dokumentációhttp://docs.oracle.com/database/122/TGSQL/joins.htm#TGSQL95232------------------------------------------------------------------

Az Access Path, vagy más néven hozzáférési út egy technika, amit a lekérdezés használ annak érdekében, hogy kinyerje a sorokat a 'row source'-ból.Nagyon sok ilyen hozzáférési útvonal létezik, de közülük néhány:-FULL TABLE SCANEz a scan az összes sort kiolvassa a táblából és aztán kiszűri azokat a sorokat, amelyek nem egyeznek meg a szelekciós kritériumoknak.-INDEX ACCESS: UNIQUEA ROWID egy belső reprezentánsa az adatok háttértárban való elhelyezkedésének. Egy INDEX UNIQUE SCAN legföljebb 1 rowid-t ismétel.-INDEX ACCESS: RANGE SCANAz INDEX RANGE SCAN az értékek rendezettt scan-je.-TABLE ACCESS BY INDEX ROWIDEgy sornak a rowid-ja pontosan meghatározza az adatfájlt és az adattömböt, amely tartalmazza a sort és a sor elhelyezkedését a tömbben.------------------------------------------------------------------Forrás: Online irodalom: Oracle dokumentációhttp://docs.oracle.com/database/122/TGSQL/optimizer-access-paths.htm#TGSQL229------------------------------------------------------------------

A végrehajtási terv megjelenítése több módon is történhet. Ezek közül a leggyakrabban használt eszközök az alábbiak.------------------------------------------------------------------Forrás: Online irodalom: Oracle dokumentációhttp://docs.oracle.com/database/122/TGSQL/introduction-to-sql-tuning.htm#TGSQL118------------------------------------------------------------------

A végrehajtási terv leggyakrabban használt megjelenése a PLAN_TABLE segítségével, és az EXPLAIN_PLAN-nel történik. DBMS_XPLAN.DISPLAY használatára hoztam egy példát, ami a csatolt linken található. A példában a kolcsonzo táblára hoztam létre az PLAN-t.A csatolt linken pedig az Oracle dokumentáció által részletezett PLAN_TABLE oszlopai találhatóak:http://docs.oracle.com/database/122/TGSQL/reading-execution-plans.htm#TGSQL94734

V$SQL_PLAN és ehhez kapcsolódó nézetek tartalmaznak információt a futtatott SQL lekérdezésekről, valamint ezek végrehajtási terveikről, amik a Shared Pool-ban találhatóak meg.DBMS_XPLAN.DISPLAY_CURSOR

A végrehajtási terv megjelenítése történhet AWR adatokból is, azaz AWR pillanatfelvételek által gyűjtött reportokból.DBMS_XPLAN.DISPLAY_AWR

Egyéb megjelenítési módszerei a végrehajtási tervnek:SQL*Plus és SQL*Developer Autotrace parancsaSQL trace állomány és tkprof segítségévelSQL Tuning Set általAWR vagy STATPACK reportokból.

A végrehajtási terv megjelenítésére szolgáló grafikus eszközök:Oracle Enterprise Manager: teljesítmény adatok monitorozására szolgló grafikus eszközSQL*DeveloperSQL*Plus (táblázatos megjelenítés)

A végrehajtási tervet különböző módszerekkel lehet befolyásolni.Ilyen módszer például a lekérdezések átfogalmazása, a párhuzamosítás vagy az init.ora paraméterállományok beállításai.Továbbá az SQL Plan Management által létrehozott tervek elfogadása is befolyásoló tényező tud lenni, illetve az SQL Tuning Advisor által kreált SQL profilok elfogadása is.

A valós idejű SQL monitorozás lehetővé teszi a felhasználó számára, hogy nyomon követhesse az SQL lekérdezések teljesítményét, mialatt azok épp futnak. Általában az SQL nyomon követése automatikusan akkor indul el, amikor a lekérdezés párhuzamosan fut, vagy amikor a lekérdezés a CPU vagy az I/O idejéből már elhasznált legalább 5 másodpercet egy egyszerű futtatás esetén.

Oracle Enterprise Manager Cloud Control könnyű használatot és elérést biztosít az SQL monitoring oldalakhoz. A felhasználó nyomon tudja követni az SQL-el kapcsolatos statisztikákat V$SQL_MONITOR és a V$SQL_PLAN_MONITOR nézetek által. Valamint használni tudja ezeket a nézeteket az alábbi nézetek eléréséhez, hogy több információt lehessen megkapni a futási folyamatokról:V$ACTIVE_SESSION_HISTORYV$SESSIONV$SESSION_LONGOPSV$SQLV$SQL_PLAN

A SQL trace ("nyomonkövető") fájlok a felhasználó számára teljesítményadatokat szolgáltatnak az egyéni SQL lekérdezéseikről: elemzési számítások, fizikai és logikai olvasások, stb. A felhasználó fel tudja használni ezeket az információkat az SQL teljesítményproblémáinak az azonosításához. Az Oracle adatbázis az alábbi parancssorokat tudja biztosítani a trace fájlok elemzéséhez:TKPROFinput trace files > output filetrcsesstrace outputok egyesítéseA trcsess -ek összeolvadása után a nyomon követési információk bekerülnek egy output fájlba, ahol a felhasználó át tudja formálni ezt az output fájlt a  TKPROF -al. A trcsess  hasznos tud lenni bizonyos session-ök teljesítményének a nyomonkövetéseinek az egyesítésére.

A TOAD (Tool for Oracle Application Developers) egy harmadik fél által gyárott Oracle SQL hangolási eszköz.

Az Oracle periodikusan AWR pillanatfelvételeket gyűjt az adatbázis állományokról, valamint a munkaterhelésről, megkönnyítve ezzel az ADDM teljesítmény monitorozását. A kézi hangolásnak a része ezeknek az AWR reportoknak a tanulmányozása, de ezek helyett már a STATSPACK reportok elemzését is szokták végezni.

Az ADDM (Automatic Database Diagnostic Monitor) az Oracle adatbázisba beépített önmonitorozó szoftver. Az ADDM automatikusan megtudja határozni a performancia problémák okozóját, javaslatokat biztosít a javításokra és számszerűsíti az elvárt célokat. Természetesen a szoftver azokat a területeket is azonosítani tudja, ahol nem szükséges beavatkozni.Az ADDM és más eszközök is használják az Automatic Workload Repository-t (AWR), pillanatfelvételek készítése végett.

SQL Tuning Advisor egy belső elemző szoftver, ami felismeri a problémás SQL lekérdezéseket és javaslatokat tesz a lekérdezések teljesítményének növelésére.

SQL Access Advisor is egy belső elemző szoftver, amely javaslatokat tesz arról, hogy mely materializált nézetet, indexet kell eldobni vagy épp megtartani, illetve milyet kell létrehozni, ha szükséges.

SQL Plan Management egy megelőző mechanizmus, ami lehetővé teszi az optimalizáló számára, hogy automatikusan tudja menedzselni az végrehajtási terveket, valamint biztosítja azt, hogy az adatbázis csak ismert vagy jóváhagyott terveket használhasson.

Az SQL Performance Analyzer meghatározza az SQL munkaterhelésen történő változási hatásokat azáltal, hogy felismeri mindegyik SQL lekérdezés teljesítménybeli különbségeit.

Automatic SQL Tuning TaskAutomatic SPM Evolve TaskMindkét folyamat automatizált és az éjszaka folyamán szokott futni.

A csatolt linken a SQL utasítások feldolgozásának a lépcsőit lehet látni az Oracle dokumentációból. ------------------------------------------------------------------Forrás: Online irodalom: Oracle dokumentációhttp://docs.oracle.com/database/122/TGSQL/sql-processing.htm#TGSQL176------------------------------------------------------------------

Munkaterület megnyitása a programban.

A munkaterületben lévő utasítás parszolása.

Az eredmény leírása.

Változók bekötése.

SQL végrehajtása.

Adatok kinyerése.

A munkaterület lezárása.

Talán az egyik legjobb teljesítmény hangolási technikának számít az, ha az adatbázis-adminisztrátor az adatbázis tábláira indexeket hoz létre, hiszen az indexeket alapvetően a teljesítménynek a növelésére használják. Ezek az indexek különösen hasznosak tudnak lenni a táblák összekapcsolásában, a táblák közötti adatok összehasonlításában, illetve az adatok csoportosításánál és rendezésénél.

A denormalizálás során a táblákban az adatok redundáns módon jelennek meg, ami gyorsítja az adatok kinyerését. Az az egy hátránya van, hogy az adatmódosítás lassabb lesz, mert az adatokat több helyen kell majd karbantartani.