12. heti gondolattérkép

Больше похоже на это

Sample Mind Map

от Ádám Ádám

A számítógépes munka összetevői

от Beáta Hintz

Belső motiváció

от Timea Pap

Számítógépek

от Gábor Nagy

Példa indexes végrehajtási tervre

Példa:

Kifejezetten a rendelési időre explicit módon létrehozott nem-egyedi index használatával a rendelés sorszámának, a rendelés idejének és az ügyfél azonosítójának lekérdezése egy adott rendelési időpontban már csak 2 egység költséggel (cost, CPU használat is része) jár, mivel a where feltétel teljesüléséhez nem kell bejárni a teljes táblát, csupán annak az oszlop értékeinek sorazonosítóit, amelyikre az indexet létrehoztuk. Erre, az index olvasási műveletre utal az "INDEX (RANGE SCAN)" kifejezés a végrehajtási tervben, amely mellett megtalálható a frissen általunk létrehozott és használatban lévő "ind_rendido" indexünk neve.

Forrás: 11. heti gyakorlat

Példa index nélküli végrehajtási tervre

Példa:

Index használata nélkül a rendelés sorszámának, a rendelés idejének és az ügyfél azonosítójának lekérdezése egy adott rendelési időpontban 68 egység költséggel (cost, CPU használat is része) jár, mivel a where feltétel teljesüléséhez a teljes táblát át kell fésülni. Erre, a teljes tábla beolvasására utal a "TABLE ACCESS (FULL)" kifejezés a végrehajtási tervben.

Forrás: 11. heti gyakorlat

Performancia adatok gyűjtése

Performancia adatokat gyűjtünk ezekről a „nagy” SQL-ekről (SQL-ek futási statisztikáit).

Forrás: előadás dia

Megpróbáljuk megállapítani, hogy van-e bármi baj ezekkel az utasításokkal (azok futásával)

Definiáljuk a probléma típusát és okát

Megpróbáljuk javítani a szuboptimális futási jellemzőket (leginkább megpróbáljuk felgyorsítani)

Ha már feljavult, megpróbáljuk megakadályozni a későbbi regressziókat (visszalassulásokat)

Statisztikák gyűjtése

Adatbázis statisztikákat és operációs rendszer statisztikákat gyűjtünk.

Forrás: előadás dia

Szűk keresztmetszet keresése

Megvizsgáljuk az adatokat, és keressük a szűk keresztmetszetet. Elméletet gyártunk, hogy mi a baj, és ötletet, hogyan lehetne ezt megszüntetni/enyhíteni.

Forrás: előadás dia

Ötlet implementálása

Implementáljuk az előbb gyártott ötletet.

Forrás: előadás dia

Iteráció befejezése

Újra mérés

Újra mérünk (megismételjük a 2. lépést) és leellenőrizzük, hogy a probléma megoldódott-e. Ha nem: visszatérünk újabb ötletet keresni. Ha igen, megnézzük, hogy elértük-e már a célunkat. Ha igen: abbahagyjuk. Ha nem, keressük a következő szűk keresztmetszetet és azzal megismételjük a fenti folyamatot.

Forrás: előadás dia

Befejezés

SQL optimalizálás

Adatbázishangolás Oracle rendszer esetén

Befolyásolási módszerei

A lekérdezés átfogalmazása

Párhuzamosítás

Optimalizáló statisztikák frissítése

A helyes indexelés

Stored Outlines

Lassan eltűnik.

Forrás: előadás dia

SQL Tuning direktívák

SQL profilok elfogadása

SQL Tuning Advisor

Forrás: előadás dia

Verifikált tervek elfogadása

SQL Plan Management

Forrás: előadás dia

Optimalizálási HINT-ek beállítása

Egyes init.ora paraméterek beállításai

Grafikus eszközök

SQL*Developer

SQL*Plus

Megjelenítése

Egyéb módszerek

• SQL*Plus és SQL*Developer Autotrace
• SQL trace állomány és tkprof segítségével
• SQL Tuning Set-ből
• AWR vagy STATSPACK mérésekből
• 10053-as szintű trace-elésből 

Forrás: előadás dia

AWR adatokból

DBMS_XPLAN.DISPLAY_AWR 

Forrás: előadás dia

Shared Poolból

DBMS_XPLAN.DISPLAY_CURSOR 

Forrás: előadás dia

PLAN_TABLE segítségével

DBMS_XPLAN.DISPLAY 

Használata:

• EXPLAIN PLAN FOR select salary from employees where employee_id =15;
• SELECT * FROM  TABLE(DBMS_XPLAN.DISPLAY)

Forrás: előadás dia

Főbb elemei

A JOIN metódusok

HASH JOIN

SORT MERGE JOIN

NESTED LOOPS JOIN

A JOIN-ok sorrendje

Hozzáférési „útvonalak” (ACCESS PATH)

...

TABLE ACCESS BY INDEX ROWID

INDEX ACCESS: RANGE SCAN

INDEX ACCESS: UNIQUE

FULL TABLE SCAN

Végrehajtási terv

A végrehajtási terv fa szerkezetű.

Létezik soros és parallel terv. A soros (szekvenciális) terv olyan alaplépések sorozata, amelyet a gép elvégez annak érdekében, hogy előállítsa az eredményt.

Bind változók használatával csökkentjük a Hard Parse-ok számát („Sharing the cursors”).

A PARSE során vagy már a gyorsítóban megtalálja a tervet az adatbáziskezelő szoftver (Soft Parse), vagy akkor készíti el (Hard Parse) és beteszi a gyorsítóba.

Feldolgozás lépései

7. CLOSE

A munkaterület (kurzor) lezárása.

Forrás: előadás dia

6. FETCH

Adatok „kinyerése”.

Forrás: előadás dia

5. EXECUTE

Az SQL végrehajtása.

Forrás: előadás dia

4. BIND

A változók „bekötése”.

Forrás: előadás dia

3. DESCRIBE

Az eredmény leírása.

Forrás: előadás dia

2. PARSE

 Az SQL parszolása a munkaterületben.

Forrás: előadás dia

1. OPEN

Munkaterület nyitása a programban.

Forrás: előadás dia

Hangolás eszközei

Automatikus eszközök

Az automatikus hangolási eszközök 20 múlva kiszorítják az ember általit.

Forrás: előadáson elhangzottak

Automatic SPM Evolve Task

Automatic SQL Tuning Task

Database Replay

SQL Performance Analyzer

SQL Plan Management (SPM)

A regresszió megakadályozásáért felel.

Forrás: előadáson elhangzottak

Adaptív végrehajtási tervek

Csak Oracle 12-ben működik.

Forrás: előadás dia

SQL Access Advisor

Indexeléseket javasol.

Forrás: előadáson elhangzottak

SQL Tuning Advisor (Automatic Tuning Optimizer)

SQL utasítások hangolása.

Forrás: előadáson elhangzottak

Automatic Database Diagnostic Monitor (ADDM)

Adatbázis-hangoló szoftver, tanácsokat ad. Továbbküldhet a Tuning Advisor-hoz.

Forrás: előadáson elhangzottak

Általunk végzett hangolás eszközei

Harmadik fél által gyártott Oracle SQL hangolási eszközök

Például: TOAD (Tool for Oracle Application Developers) vagy egyebek.

Forrás: előadás dia

A TOAD funkciói:

• Leegyszerűsített adatbázis fejlesztés
• Minőségi kód biztosítása
• Automatizált kódtesztelés
• Automatikus kódanalízis
• Adatbázis teljesítmény tesztelés
• Stabilitás és állapotfelmérés
• Csoportmunka
• Kockázatcsökkentés és automatizálás

Forrás: http://szoftver.hu/szoftver/quest/toad-oracle

Az Oracle Enterprise Manager, esetleg valamelyest az SQL Developer használata

Real Time Database Operation Monitoring

SQL Monitoring használata

STATSPACK reportok az AWR reportok helyett

AWR reportok megfelelő részeinek a tanulmányozása

Az alkalmazások „SQL trace”-elése, „tkprof” és „trcsess” segédeszközök

Végrehajtási terv tanulmányozása

Tanulmányozzuk a végrehajtási tervet és megpróbáljuk megváltoztatni.

Forrás: előadás dia

SQL hangolás lépései

Megkeressük a „nagy terhelést” okozó SQL-eket (Big SQL)

SQL hangolás körülményei, menete

Felgyorsítás, vagy csupán a lelassulás megakadályozása

Preventív regresszió: arra való törekedés, hogy ma ne legyen rosszabb, mint tegnap volt.

Forrás: előadáson elhangzottak

Kézi módszerek vagy automatikus hangolás

Hozzáállás

Reaktív

A hiba beállta után való reagálás, hibaelhárítás. A munkavállaló számára előnyös több dicséretért és pénzért.

Forrás: előadáson elhangzottak

Proaktív

Mielőtt elromlik javítok, a baj megelőzése. A cég számára ez az előnyös.

Forrás: előadáson elhangzottak

Előfeltételei

Forrás: előadás dia

Az adatok természetének az ismerete

Az alkalmazás logikájának az ismerete

A különböző hangolási eszközök és lehetséges módszerek ismerete

Az SQL nyelv alapos ismerete

Oracle adatbázis architektúrális ismeretek

Iteratív folyamat

Egy iteratív folyamat az SQL-ek „javítása” annak érdekében, hogy lecsökkenjen a futásidejük, illetve hogy lecsökkenjen az erőforrás-használatuk. 

Forrás: előadás dia

I/O és egyéb erőforrások hatékony használata

Op. rendszer, diszk, hálózat hangolása

Instance Caging

Erőforrásokkal gazdálkodik, hogy egy instance se sajátítsa ki teljes mértékben erőforrásokat. A virtuális gépek elterjedése óta aktualitását vesztette.

Forrás: előadáson elhangzottak

Oracle Database Resource Manager

A feladatok priorizálására képes, „önmegtartóztatás” a hatékonyság érdekében.

Forrás: előadáson elhangzottak/előadás dia

Biztonság vagy performancia

Katasztrófa, áramszünet után működőképes legyen-e a rendszer vagy magas teljesítményű?

Forrás: előadáson elhangzottak

Karbantarthatóság vagy performancia

I/O kalibráció

El kell dönteni, hogy mekkora "falatonként" olvassuk a fájlokat.

Forrás: előadáson elhangzottak

SAME vagy RAID-5

A S.A.M.E. (Stripe and Mirror Everything) módszertant azt Oracle kezdte ajánlani sok évvel ezelőtt a magas szintű rendelkezésre állás, teljesítmény, kezelhetőség optimalizálásának megközelítéséből a jövőbeli konfiguráció leegyszerűsítése céljából. Egy 1 MB-os fix méretű sáv szélessége (stripe size) ajánlott a S.A.M.E. módszertanban, amely megfelel mind az OLTP és az adattárház-rendszerek számára. Az ASM implementálja a S.A.M.E. módszertant, ráadásul automatikus működést biztosít neki.

Forrás: https://docs.oracle.com/cd/B28359_01/server.111/b32024/vldb_storage.htm

A RAID-5 3 vagy több lemezen tárolja a paritás adatokat. A paritás adatok a saját lemezüktől különböző lemezekre vannak rendezve, hogy az elveszett blokk adatai ne vesszen el. A RAID-5 írás overhead-je jelentős, ami lassabbá teszi a többi RAID metódusnál különösen akkor, amikor lemezhiba történik, de jóval kevesebb lemezt igényel, így költséghatékonyabb. Régen az emberek elkerülték a RAID-5-t adatbázis alkalmazások esetén, de a lemezsebesség és a vezérlő teljesítmény fejlődésével egy életképes megoldássá vált adatfájlokhoz, ha nem a teljesítményt tartjuk szem előtt.

Forrás: https://oracle-base.com/articles/misc/oracle-and-raid

ASM vagy hagyományos fájlrendszer

A képen az ASM alkalmazásának egy gyakorlati példája van illusztrálva. Az ábra alapján van két diszkekből álló csoportunk: az egyik diszk csoport 4 db, a másik 2 db lemezt foglal magába. Az adatbázisnak mindkét csoporthoz van hozzáférése. Az ábra konfigurációja alapján több instance (az adatbázist kezelő szoftver) van, azonban csupán egy Oracle ASM instance szükséges ahhoz, hogy kiszolgálja a többi adatbázis szoftvert.

Forrás: https://docs.oracle.com/cd/E11882_01/server.112/e18951/asmcon.htm#OSTMG03601

Forrás: http://www.adp-gmbh.ch/ora/misc/database_vs_instance.html

Aszinkron I/O

Az aszinkron I/O helyes használata. Általában a DBA felel érte.

Forrás: előadáson elhangzottak/előadás dia

Példány hangolásának a menete

Probléma definiálása

Megfogalmazzuk a célkitűzéseket, amelyek számszerűek, definiáljuk a problémát.

Forrás: előadás dia

Adatok begyűjtése

Metrika „baseline”-ok

V$-nézetekből lekérdezés

AWR snapshots

Az Automatic Workload Repository infrastruktúra használata: AWR pillanatfelvételek. Diagnostic Pack tartalmazza, amellyel az elmúlt napok adatai nézhetők vissza.

A mellékelt kép az AWR architektúrát hivatott bemutatni.

Forrás: előadáson elhangzottak/előadás dia

Forrás: http://dbakevlar.com/wp-content/uploads/2015/01/pt5-1024x529.png

STATSPACK snapshots

Az AWR előfutára, csupán ez ingyenes.

Forrás: előadáson elhangzottak

Riasztások

Adatbázis metrikák és szerver generálta riasztások (Server Generated Alerts): anomáliák esetén figyelmeztet. Például egy adott időpontban több a tranzakció a szokásosnál.

Forrás: előadáson elhangzottak/előadás dia

Compare Period ADDM report

Összehasonlítja a korábbi reportokkal és tanácsokat ad.

Forrás: előadáson elhangzottak/előadás dia

ASH analitika

Active Session History Report, ASH analitika.

Forrás: előadás dia

Oracle Enterprise Manager

Monitorozás a GUI felületeken keresztül.

Forrás: előadás dia

(valós idejű) ADDM report

Automatikus adatbázis-hangolás, azaz Automatic Database Diagnostic Monitor. Adatbázis-hangoló szoftver, tanácsokat ad. (Nem minden javaslata ér aranyat.)

Forrás: előadáson elhangzottak/előadás dia

Adatbázis statisztikák

Minden hangolás alapja a mérés, diagnosztizálás. Ez X$-táblák, V$-nézetek (Dynamic Performance Tables) használatával történik.

Jellemzői:

• Többnyire kumulatívak;
• Egyesek mintavételezésen alapulnak;
• Van egy olyan process, ami másodpercenként mintát vesz. Statisztikai alapon jól működik, mivel a nagyobb folyamatok továbbtartanak 1 másodpercnél, nem bújhatnak el. 
• „Time Model” típusú statisztikák;
• Egymás közti arányok. A Diagnostic Pack szükséges hozzá.

Forrás: előadáson elhangzottak/előadás dia

stb.

V$SEGSTAT

A szegmensek használata.

Forrás: előadás dia

A szegmens szintek statisztikai adatait tartalmazza a nézet.

Bővebben a V$SEGSTAT-ról:

https://docs.oracle.com/database/121/REFRN/GUID-097DB23C-7BA5-4C02-B595-90F1D3337AA2.htm#REFRN30221

V$SESSTAT

 A munkamenetek adatai külön-külön.

Forrás: előadás dia

A session-ök statisztikai adatait tartalmazza a nézet. Ahhoz, hogy a "STATISTIC#" oszlopban szereplő számok alapján beazonosíthassuk a statisztikák megnevezéseit, szükségünk van a V$STATNAME nevű táblára.

Bővebben a V$SESSTAT-ról:

https://docs.oracle.com/database/121/REFRN/GUID-80CE202B-D7D4-4949-8CA6-935FD61DA2E1.htm#REFRN30232

V$SYSSTAT

A példány központi „sikerszámai”. Például mennyi commit, rollback történt.

Forrás: előadáson elhangzottak/előadás dia

A rendszerről készült statisztikai adatokat tartalmazza a nézet. A "NAME" oszlopban a rendszerről készült statisztikák megnevezése, a "VALUE" oszlopban a statisztikák értékei, a "STAT_ID" oszlopban pedig a statisztikák azonosítói láthatók.

Bővebben a V$SYSSTAT-ról:

https://docs.oracle.com/database/121/REFRN/GUID-250136E5-E07E-4A78-9F67-28C0D3C6E922.htm#REFRN30272

V$SQLSTATS

 Az SQL utasítások terhelése.

Forrás: előadás dia

Az SQL utasítások teljesítményének statisztikai adatait tartalmazza a nézet, mint például az utasítások végrehajtásához, parse-olásához és fetch-eléséhez szükséges processzoridőt ("CPU_TIME"), vagy a végrehajtás, parse-olás és fetch-elés közben eltelt időt ("ELAPSED_TIME", párhuzamos műveletek esetén ez egy kumulált érték) mikroszekundumban mérve, stb. Az "SQL_TEXT" oszlop tartalmazza az SQL szövegek első 1000 karakterét.

Bővebben a V$SQLSTATS-ról:

https://docs.oracle.com/database/121/REFRN/GUID-495DD17D-6741-433F-871D-C965EB221DA9.htm#REFRN30396

V$ACTIVE_SESSION_HISTORY

Statisztikai adatok a közelmúltról a memóriában és az adatbázisban. A Diagnostic Pack tartalmazza.

Forrás: előadáson elhangzottak/előadás dia

A session-ök aktivitásából vett mintát mutatja meg a nézet. A nézet 1 másodpercenkénti pillanatfelvételeket tartalmaz az aktív session-ökről. A "SAMPLE_TIME" oszlopban látható, hogy milyen időpontokban készültek a pillanatfelvételek. Azok számítanak aktívaknak, amelyek a processzorban vannak, vagy egy olyan eseményre várnak, amelyek nem tartoznak az "Idle" várakozási osztályhoz.

Bővebben a V$ACTIVE_SESSION_HISTORY-ról:

https://docs.oracle.com/database/121/REFRN/GUID-69CEA3A1-6C5E-43D6-982C-F353CD4B984C.htm#REFRN30299

Monitorozás , mérés

Minden hangolás alapja a mérés, diagnosztizálás.

Forrás: előadás dia

Kezdeti adatbázis és példány konfigurálás

Az UNDO táblatér helyes konfigurálása, ideiglenes UNDO használata

Az archiválás konfigurálása

A rossz archiválás jobban fékezi a rendszert.

Forrás: előadáson elhangzottak

A naplóállományok megfelelő száma és mérete

A nagy red log fájlok jók.

Forrás: előadáson elhangzottak

init.ora paraméterek helyes beállítása

Táblaterek megfelelő beállítása

A táblaterek megfelelő beállítása: lokálisan karbantartott, automatikus szegmens karbantartású, fix méretű, vagy automatikusan növekvő. A növekmény mérete is fontos lehet. A kicsi növekmény nem jó.

Forrás: előadáson elhangzottak/előadás dia

Ideiglenes táblatér helyes konfigurálása

A temporális táblatérben tárolódnak a részeredmények, ha egy művelet kifut a tárhelyből.

Forrás: előadáson elhangzottak

Flash Cache használata

Háromrétegű cache-elést eredményez, amely a memória és a merevlemez között áll. A közepes fontosságú fájlokat tárolja.

Forrás: előadáson elhangzottak

Dedikált vagy osztott szerver típusú kapcsolatok

SQL Tuning, Application Tuning

SQL hangolás, alkalmazáshangolás:

• Leginkább a fejlesztők, de gyakran a DBA-kal együttműködve végzik, mivel a DBA-k több jogosultsággal és az architektúrát illető ismerettel rendelkeznek, olykor előfordul, hogy csak a DBA-ra jut ez a feladat;
• Néha nagyságrendekkel tudunk felgyorsítani 1-1 SQL utasítást. Az más kérdés, hogy ez összességében mennyit nyom a latban.
• Gyakran az adatbáziskezelő rendszer butasága miatt kell SQL-t hangolnunk;
• Azért kell néha hangolni, mert az SQL nem procedurális nyelv, és a gép készíti el az utasítás végrehajtási tervét – néha nem az optimális terv készül el. A relációs adatbázisok tervei 90%+-ban optimálisak;
• Az a távlati cél, hogy „ne kelljen hangolnunk” ;
• Néha nem 1-1 SQL a baj, hanem azok beillesztése az alkalmazásba: ilyenkor alkalmazáshangolás történik.

Forrás: előadáson elhangzottak/előadás dia

Database Tuning (Intance Tuning and Database Tuning)

Egészen más tevékenység, mint az SQL hangolás. Keressük a szűk keresztmetszetet és igyekszünk a feladatok folyásán változtatni. Ez egy ciklikus folyamat, mely során az iterációk végén újabb és újabb szűk keresztmetszetek megszüntetése a feladat.

Céljai:

• Az adatbáziskezelő rendszer különböző „lelassulási”, „elakadási” illetve „bedugulási” problémáinak a kinyomozása és kiiktatása;
• Lelassulás: redo log fájlok írásának lelassulása, lassú az archiválás.
• Elakadás: pl. lock-ra várás, mert valaki nem commit-ál.
• Bedugulás: túl nagy a terhelés, I/O alrendszerek túlterhelése
• Az I/O alrendszer minél hatékonyabb kihasználása;
• Nem feltétlen a RAM a gyorsítás eszköze.
• A gép memóriájának (RAM) a minél hatékonyabb kihasználása (caching);
• Esetleg több gép általi horizontális skálázhatóság;
• Szinte mindig a DBA a főszereplő;
• Sokat segíthet az operációs rendszer rendszergazdája, a diszk alrendszer rendszergazdája, néha a hálózati rendszergazda;
• Sokat segíthet az együttműködés a fejlesztő csapattal;
• Az adatbázishangolás adatbáziskezelő-specifikus ;
• Jellemzően kb. 10%-os javulásban reménykedünk feltéve, hogy jól működik a rendszer;

Forrás: előadáson elhangzottak/előadás dia

Performance Planning

Mérnökök és gazdasági szakemberek végzik a hatékonysági problémák (pl. lassúság) megelőzése céljából már a kezdeti, tervezési fázisban. Ezen metódus alkalmazása mellett nincs feltétlen szükség adatbázis és SQL hangolásra.

Forrás: előadáson elhangzottak/előadás dia

Terheléses tesztek

Ezen eljárás elvégzésére gyakran nincs elegendő idő az üzembe helyezés előtt. 10, 20, 30 évvel ezelőtt sok vállalat behívta az alkalmazottai zömét, hogy teszteljék a rendszert. Manapság ezt szoftverek végzik.

Forrás: előadáson elhangzottak

A mellékelt képen a rendőrség alap ügyviteli rendszerének (Robotzsaru) egyik OLTP adatbázisának terhelési diagramja látható.

Forrás: http://konferenciak.advalorem.hu/uploads/files/Oracle%20technol%C3%B3gia%20alkalmaz%C3%A1sa%20a%20Bel%C3%BCgyminiszt%C3%A9riumban_BM.pdf

Skálázhatóság

A skálázhatóság azt jelenti, hogy nem feltétlen a válaszidő mérvadó, hanem a sok egyidejű felhasználó kiszolgálása, batch jellegűség. Példa: online bankolás.

Forrás: előadáson elhangzottak/előadás dia

Alkalmazás általános architektúrája

Az alkalmazás általános architektúrája, műveletek gyakorisága és ezek alapján hol várható hatékonysági probléma és milyen jellegű.

Becsülni kell a műveletek előfordulásainak számát, jelezni kell a szűk keresztmetszetet.

Forrás: előadáson elhangzottak/előadás dia

Hardver- és szoftverarchitektúra megtervezése

A számítógépes rendszer hardver és szoftverarchitektúrájának a megtervezésének szempontjai:

• Kliens-szerver, vagy háromrétegű architektúra;
• Egyrétegű: arra a gépre jelentkezünk be, ahol az adatbázis megtalálható.
• Háromrétegű: a felhasználó a böngészőn keresztül éri el az adatbázist kliens-szerver kapcsolat keretében.
• CPU-k száma és típusa, I/O alrendszer, memória;
• Az adatbázisok licenceinek árazása az azt használó CPU-k számától függ, ezáltal a licencek árai nagyon magasra nőhetnek.
• Jelenleg az INTEL alapú technológia a vezető.
• Az I/O alrendszerek árai szintén az egekbe szökhetnek bizonyos "csodadiszkek" vásárlása esetén.
• A mai memóriák kapacitása 100 GB-os nagyságrendű is lehet, a TB még nem reális.
• Oracle RAC esetén a fürtözött gépek száma (A mellékelt videó erre ad bővebb magyarázatot);
• Több gép szimultán használata.
• Milyen egyéb komponensek lesznek: pl. tűzfalak, loadbalancer-ek, alkalmazás-szerverek, messagingrendszerek, IdM-ek, stb;
• Az alkalmazás lehet batch jellegű vagy interaktív (klikkeléses azonnali válasszal).

Forrás: előadáson elhangzottak/előadás dia

Élesbeállítás

Új rendszerek élesbeállítása „zöldmezősen” vagy már másik működő rendszerek mellett.

• Zöldmezős: egy új alkalmazás egy új gépen fut vagy,
• már létező gépen, létező adatbázis mellett létrehozott új adatbázis. (Megelőző terheléses teszt elvégzése javasolt összehasonlítás céljából.)

Forrás: előadáson elhangzottak/előadás dia

Baseline

A performancia-adatok viszonyítási szintje más néven „baseline”. Ezekhez hasonlítjuk majd az új mérések eredményeit.

Forrás: előadáson elhangzottak/előadás dia

Performancia-elvárások

Fontos a performancia-elvárások meghatározása, melyek számszerűsíthetőek, konkrétak, precízek, mérhetőek, elérhetőek.

Forrás: előadás dia

SLA

SLA (Service Level Agreement): elvárások hatékonyságára vonatkozik. Például a felhasználók 99%-a kapjon választ 13 másodpercen belül.

Forrás: előadáson elhangzottak/előadás dia

Szoftverberuházás

Szoftverberuházási megfontolások:

• Melyik adatbáziskezelő rendszer: melyik gyártó termékét éri meg megvásárolni
• Ha pl. Oracle RDBMS, akkor:
• Enterprise Edition vagy Standard Edition (esetleg Express)?
• Az Enterprise Edition esetén létrehozható bittérképes index, az Express ingyenes.
• Ha Enterprise, akkor particionálási opció is?
• RAC vagy egygépes („single instance”) változat?
• Diagnostic Pack vagy Diagnostic+Tuning Pack, vagy semmi?
• Az Oracle Enterprise Manager tartalmazza a Diagnostic Pack-et, amivel könnyebb a monitorozás.
• A kérdés az, hogy a hangolást ember vagy gép végezze. 20 év múlva nagy valószínűséggel már emberi tényező nélkül történik a hangolás automatizáltan.
• Advanced Compression Option kell?

Forrás: előadáson elhangzottak/előadás dia

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

A gondolattérkép a teljes diasor szövegét tartalmazza kiegészítő tartalommal.