af Viktoria Kovacs 7 år siden
443
Mere som dette
Manapság a legtöbb cég már nyomon követi és hangolja az IT infrastruktúrájának a teljesítményét, ami magába foglalja az adatbázisoknak a teljesítményét is. Egy adatbázis teljesítménye alatt azt a sebességet/válaszidőt értjük, amellyel az adatbázis-kezelő rendszer ki tudja elégíteni a felhasználó információ kérését. Azonban egy adatbázisnak a teljesítményét öt különböző tényező is befolyásolhatja egyszerre:
A teljesítmény javítására szolgáló lépésekért általában az adatbázis-adminisztrátorok felelősek.
Az adatbázisok hangolását három részre oszthatjuk:
Éppen ezért elmondhatjuk, hogy az adatbázisoknak a hangolása egy igen nehéz, összetett feladat, hiszen nem elég önmagában csak az alkalmazásokat hangolni, hanem egyszerre hangolni kell az adatbázist és a rendszert is.
------------------------------------------------------------------
Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
A gondolattérképet az előadás diák és a saját jegyzeteim felhasználásával készítettem. Ahol nincs megjelölve külön forrás, ott az ezekből származó információkat használtam fel.
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álata
http://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.
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.
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 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:
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
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
------------------------------------------------------------------
CLOSE
A munkaterület lezárása.
FETCH
Adatok kinyerése.
EXECUTE
SQL végrehajtása.
BIND
Változók bekötése.
DESCRIBE
Az eredmény leírása.
PARSE
A munkaterületben lévő utasítás parszolása.
OPEN
Munkaterület megnyitása a programban.
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
------------------------------------------------------------------
Automatikus
Automatic Tasks
Mindkét folyamat automatizált és az éjszaka folyamán szokott futni.
SPA
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.
SPM
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.
SQL Access Advisor
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 Tuning Advisor
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.
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.
Kézi
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.
TOAD
A TOAD (Tool for Oracle Application Developers) egy harmadik fél által gyárott Oracle SQL hangolási eszköz.
Alkalmazások "trace"-elése
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 file
trcsesstrace outputok egyesítése
A 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.
Oracle Enterprise Manager
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_PLANReal Time Monitoring
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.
Végrehajtási terv
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:
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.
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
------------------------------------------------------------------
Befolyásolási módszerei
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.
Grafikus eszközök
A végrehajtási terv megjelenítésére szolgáló grafikus eszközök:
Megjelenítése
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
------------------------------------------------------------------
Egyéb
Egyéb megjelenítési módszerei a végrehajtási tervnek:
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
Shared Pool
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
PLAN_TABLE
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
Elemei
Access Path
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 SCAN
Ez 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: UNIQUE
A 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 SCAN
Az INDEX RANGE SCAN az értékek rendezettt scan-je.
-TABLE ACCESS BY INDEX ROWID
Egy 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
------------------------------------------------------------------
Join method
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:
SORT JOIN operátorok.------------------------------------------------------------------
Forrás: Online irodalom: Oracle dokumentáció
http://docs.oracle.com/database/122/TGSQL/joins.htm#TGSQL95
------------------------------------------------------------------
Join order
A joinok összekapcsolódásának a sorrendje.
Az itteni információkon felül a teljes dokumentáció a témához megtalálható az Oracle weboldalán a csatolt linken.
6. Regressziók megakadályozása
5. Szuboptimális futási jellemzők gyorsítása
4. Probléma típusának és okozójának meghatározása
3. Probléma megállapítása
2. Performancia adatok feltérképezés (statisztikák)
1. Nagy terhelést okozó SQL-ek felkutatása
Az SQL hangolás egy iteratív folyamat annak érdekében, hogy:
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
------------------------------------------------------------------
Hozzáállás
------------------------------------------------------------------
Forrás: Online irodalom: Oracle dokumentáció
http://docs.oracle.com/database/122/TGSQL/introduction-to-sql-tuning.htm#TGSQL115
Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
Reaktív
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.
Proaktív
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.
Előfeltételek
Ha SQL-t szeretnénk hangolni, nélkülözhetetlen néhány készség, valamint tudás ezzel kapcsolatban:
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.
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:
mindez 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ása
http://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.
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.
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.
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ó.
Példány hangolása
Lépései
5. Ellenőrzés
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.
4. Ötlet implementálása
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.
3. Szűk keresztmetszet keresése
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.
2. Statisztikák gyűjtése
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.
1. Probléma definiálása
Első lépésként definiálni kell a problémát és ezáltal számszerű célokat kell kitűznünk.
Erőforrások hatékony kihasználása
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.
Operációs rendszer
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.
Önmegtartóztatás és Instance Caging
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 Server
https://docs.oracle.com/html/E25494_01/dbrm008.htm
------------------------------------------------------------------
Biztonság
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
Karbantarthatóság
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.
I/O kalibráció
SAME
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
------------------------------------------------------------------
ASM
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.
Aszinkron I/O
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/O
https://www.ibm.com/support/knowledgecenter/hu/SSGU8G_11.50.0/com.ibm.admin.doc/ids_admin_0300.htm
------------------------------------------------------------------
Tipikus problémák
Általában a teljesítmény problémák elfogadhatatlan válaszidőt eredményeznek. A tipikus ilyen teljesítmény problémák:
------------------------------------------------------------------
Forrás: Online irodalom: Oracle documentation, Performance and Tuning
http://docs.oracle.com/database/122/CNCPT/concepts-for-database-administrators.htm#CNCPT1379
------------------------------------------------------------------
Főbb optimalizálási technikák
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
Újraszervezés
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.
Adatlap méretezés
Megfelelő adatlap méret a hatékony adattároláshoz és az I/O műveletekhez.
Megfelelő állományelhelyezés
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.
Tömörítés
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.
Szabad hely
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.
Raw partíció/állományrendszer
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.
Particionálás
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.
Teljesítmény-adatok begyűjtése
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
Monitorozás, statisztikák
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ó, 2011
http://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.
Adatbázis statisztikák
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.
V$ACTIVE_SESSION_HISTORY
Statisztikai adatok a közelmúltról.
V$SQLSTAT
SQL utasítások terhelése.
V$SEGSTAT
A szegmensek használata.
V$SESSTAT
A munkamenetek adatai.
V$SYSSAT
A példány központi sikerszámai.
Adatbázis metrikák
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 Alerts
http://docs.oracle.com/database/122/TDPPT/monitoring-performance-alerts.htm#TDPPT046
------------------------------------------------------------------
ASH analtika
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=0
Tová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 Statistics
http://docs.oracle.com/database/122/TDPPT/oracle-database-performance-method.htm#TDPPT011
------------------------------------------------------------------
GUI felület
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
------------------------------------------------------------------
AWR
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 Monitor
http://docs.oracle.com/database/122/ADMQS/monitoring-and-tuning-the-database.htm#ADMQS1012
------------------------------------------------------------------
ADDM
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 Monitor
http://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.
Real-Time ADDM
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:
Csatoltam 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 Monitor
http://docs.oracle.com/database/122/ADMQS/monitoring-and-tuning-the-database.htm#ADMQS1012
------------------------------------------------------------------
V$ nézetek
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.
Kezdeti konfigurálások
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.
Szerver típusú kapcsolatok
Flash Cache
Memóriaterületek
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, Granule
http://www.orafaq.com/wiki/Granule
2. Online irodalom: Oracle dokumentáció, Dynamically Changing Cache Sizes
https://docs.oracle.com/cd/B19306_01/server.102/b14211/memory.htm#i60086
------------------------------------------------------------------
Táblaterek
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:
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
Archiválás
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
Naplóállományok
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
init.ora
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
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.
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.
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:
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
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.
Kulcskérdés a hatékonyság terén a performancia-adatok viszonyítási szintje, vagy más néven a baseline.
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.
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ó, 2011
http://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.
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
Egyéb szoftverkomponensek konfigurációja
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
Oracle RAC
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.
Háttértár és I/O műveletek
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ó, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
CPU hangolása
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.
Hardverkonfiguráció
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:
------------------------------------------------------------------
Forrás: Online irodalom: Vágner Anikó, Juhász István: Adatbázis-adminisztráció, 2011
http://progmat.hu/tananyagok/adatbazis_adminisztracio/book.html
------------------------------------------------------------------
