Második alkalommal kerül megrendezésre az Oracle Blogger Dinner (2008. június 9 17:00, Oracle irodaház), melynek nem titkolt szándéka, hogy lehetőséget teremtsen a magyarországi Oracle bloggereknek a személyes találkozásra. Kaptunk meghívást szép számmal, remélem mindenki el tud jönni. Ez csak egy rövid találkozás lesz, de nem esemény nélküli. A végleges program még nem hivatalos, de elöljáróban annyit elfecsegek, hogy lesz egy előadás Application Express témakörben, valamint többen fogunk a nemrég megrendezett HOUG2008-ról élménybeszámolót tartani.
Izgalmas eseménynek ígérkezik. Aki kapott meghívást de nem szeretne eljönni, az is gondolja meg, mert a kötetlen beszélgetések közben némi pizza és üdítő is található majd a teremben...
2008. május 29., csütörtök
2008. május 18., vasárnap
Félév végi hajtás
Mint minden félévben, ebben is a szorgalmi időszak vége a leghúzosabb, mert minden munkának ekkor van a határideje. Ilyenkorra kell befejezni a házikat, összeállítáani a prezentációt, és a pótzh-kat is ekkor lehet csak megírni. Ezek közül számomra most mind kijutott, így nem tudtam a blogommal foglalkozni.
Most azonban sok mindenről kell beszámolnom, mert Önlab II-ből is elkészültek anyagok, amiket megosztok veletek.
Először is egy rendszerterv elkészítése volt a feladat ebben a félévben, ami még most sem készült el teljesen. A tárgyfelelősnek ezt írásban és szóban is be kellett mutatni. Az írásbelivel sajnos késtem pár napot, mert elnéztem a beadási határidőt a Pünkösd hétfő miatt. Na jó, nem néztem el, csak lusta dög voltam időre megcsinálni :). Meg is lett az eredménye :(. Be kell valljam, kicsit későn kaptam észhez, hogy egy rendszertervvel még adós vagyok. Nyárády Petivel összefogtunk, mivel hasonló a témánk - optimalizálás- , ezért az alapkoncepció lehetne közös. Marton Józsival gyorsan le is ültünk konzultálni, az első ötletünket lefújta, ami egy számlázó rendszer volt. Jogosan, teszem hozzá, mert nem tudjuk, milyen folyamatok zajlanak pontosan egy ilyen rendszerben. Aztán egy kézenfekvő dolog jutott eszünkbe. Hallgatói információs rendszer, vagyis Neptun, de mégsem az. Ez már jónak bizonyult. Petivel gyorsan össze is dobtuk az adatbázis sémát, amihez a szkriptet utána megcsinálta PLSQL és TSQL nyelven is. Ez volt a kiindulási alap. Innentől ő az SQL optimalizálással foglalkozott nagyrészt, én pedig a helyes rendszer konfiguráció - értem itt ezalatt az adatbázis memória kiosztását (SGA) - megalkotásával töltöttem az időmet. Azonban rossz stratégiát választottam. Úgy gondoltam, hogy először megcsinálom a teljes koncepciót, aminek nincsenek formai, csak tartalmi követelményei, és majd ebből kiemelem a lényeget és beadom azt a tárgyfelelősnek. Na emiatt kicsúsztam a határidőből és későn változtattam az elképzelésemen. A tanulmány megírásának a felénél belekezdtem a kiírt formai követelményekbe tuszkolni az irományt, ami nem volt túl egyszerű, és időm sem maradt elég, ráadásul nem sikerült mindent belerakni, amit szerettem volna. Végül leadtam 27 óra késéssel, ami 2 munkanapnak felelt meg, így 9% levonásra számíthattam a végleges jegyemből.
Szóbeli.
Egyéb házi feladatok írása közben összeállítottam a szóbeli prezentációmat, amit természetesen nem töltöttem fel a kívánt határidőre, mert elfelejtettem. Csak a beszámoló napján délben jutott eszembe, hogy van egy ilyen feltétele is a szóbelinek. Nem történt nagy baj, bevittem magammal pendrive-on. Elég kalandos volt Marton Józsit előkerítenem a szóbelire, mert legutoljára a szóbelimről 1 hónappal előtte beszéltünk, de nem elékeztettem közvetlenül előtte. Két beszámoló után kijöttem a teremből és elindultam megkeresni. Először a termében (IL109), aztán meg mindenféle kollégáját leszólítva a folyosón, meg más laborokba bekukkantva. Végül Erős Levente oldotta meg a problémámat, aki tudta a mobil számát és felhívta, hogy meg kell jelennie konzulens minőségben egy szóbeli beszámolón. Minden a helyén volt, jöhetett a prezentációm. Megtartottam. 10 és fél perc lett körülbelül, ami fél perccel volt több a megengedettnél. Marosits Tamás volt a hallgatóság és értékelő egyben. A szóbelimben és írásbelimben egyetlen kivetnivalója volt. Az, hogy nem különült el egyértelműen, hogy mi az, amit én csináltam, és mi az, amit közösen Péterrel. Ezt szóban meg is cáfoltam neki, de úgy tűnik valamiért mindenképp rosszabb jegyet akart nekem adni. Talán a két nap késés miatt, nem tudom. A lényeg az, hogy, a késés önmagában még nem rontott volna a jegyemen, de sajnos nem értékelte tökéletesre a beszámolóimat, így a végén csak 4-est kaptam a tárgyra.
A végleges, konzulensnek szánt beszámolómat csak később tudom befejezni, de nem maradok vele adós. Most a változatosság kedvéért Adatbázisok szerveroldali programozása vizsgám lesz, de utána befejezem a művem :D.
Anyagok
Írásbeli beszámoló a tárgyfelelősnek: link
Szóbeli prezentáció: link
Most azonban sok mindenről kell beszámolnom, mert Önlab II-ből is elkészültek anyagok, amiket megosztok veletek.
Először is egy rendszerterv elkészítése volt a feladat ebben a félévben, ami még most sem készült el teljesen. A tárgyfelelősnek ezt írásban és szóban is be kellett mutatni. Az írásbelivel sajnos késtem pár napot, mert elnéztem a beadási határidőt a Pünkösd hétfő miatt. Na jó, nem néztem el, csak lusta dög voltam időre megcsinálni :). Meg is lett az eredménye :(. Be kell valljam, kicsit későn kaptam észhez, hogy egy rendszertervvel még adós vagyok. Nyárády Petivel összefogtunk, mivel hasonló a témánk - optimalizálás- , ezért az alapkoncepció lehetne közös. Marton Józsival gyorsan le is ültünk konzultálni, az első ötletünket lefújta, ami egy számlázó rendszer volt. Jogosan, teszem hozzá, mert nem tudjuk, milyen folyamatok zajlanak pontosan egy ilyen rendszerben. Aztán egy kézenfekvő dolog jutott eszünkbe. Hallgatói információs rendszer, vagyis Neptun, de mégsem az. Ez már jónak bizonyult. Petivel gyorsan össze is dobtuk az adatbázis sémát, amihez a szkriptet utána megcsinálta PLSQL és TSQL nyelven is. Ez volt a kiindulási alap. Innentől ő az SQL optimalizálással foglalkozott nagyrészt, én pedig a helyes rendszer konfiguráció - értem itt ezalatt az adatbázis memória kiosztását (SGA) - megalkotásával töltöttem az időmet. Azonban rossz stratégiát választottam. Úgy gondoltam, hogy először megcsinálom a teljes koncepciót, aminek nincsenek formai, csak tartalmi követelményei, és majd ebből kiemelem a lényeget és beadom azt a tárgyfelelősnek. Na emiatt kicsúsztam a határidőből és későn változtattam az elképzelésemen. A tanulmány megírásának a felénél belekezdtem a kiírt formai követelményekbe tuszkolni az irományt, ami nem volt túl egyszerű, és időm sem maradt elég, ráadásul nem sikerült mindent belerakni, amit szerettem volna. Végül leadtam 27 óra késéssel, ami 2 munkanapnak felelt meg, így 9% levonásra számíthattam a végleges jegyemből.
Szóbeli.
Egyéb házi feladatok írása közben összeállítottam a szóbeli prezentációmat, amit természetesen nem töltöttem fel a kívánt határidőre, mert elfelejtettem. Csak a beszámoló napján délben jutott eszembe, hogy van egy ilyen feltétele is a szóbelinek. Nem történt nagy baj, bevittem magammal pendrive-on. Elég kalandos volt Marton Józsit előkerítenem a szóbelire, mert legutoljára a szóbelimről 1 hónappal előtte beszéltünk, de nem elékeztettem közvetlenül előtte. Két beszámoló után kijöttem a teremből és elindultam megkeresni. Először a termében (IL109), aztán meg mindenféle kollégáját leszólítva a folyosón, meg más laborokba bekukkantva. Végül Erős Levente oldotta meg a problémámat, aki tudta a mobil számát és felhívta, hogy meg kell jelennie konzulens minőségben egy szóbeli beszámolón. Minden a helyén volt, jöhetett a prezentációm. Megtartottam. 10 és fél perc lett körülbelül, ami fél perccel volt több a megengedettnél. Marosits Tamás volt a hallgatóság és értékelő egyben. A szóbelimben és írásbelimben egyetlen kivetnivalója volt. Az, hogy nem különült el egyértelműen, hogy mi az, amit én csináltam, és mi az, amit közösen Péterrel. Ezt szóban meg is cáfoltam neki, de úgy tűnik valamiért mindenképp rosszabb jegyet akart nekem adni. Talán a két nap késés miatt, nem tudom. A lényeg az, hogy, a késés önmagában még nem rontott volna a jegyemen, de sajnos nem értékelte tökéletesre a beszámolóimat, így a végén csak 4-est kaptam a tárgyra.
A végleges, konzulensnek szánt beszámolómat csak később tudom befejezni, de nem maradok vele adós. Most a változatosság kedvéért Adatbázisok szerveroldali programozása vizsgám lesz, de utána befejezem a művem :D.
Anyagok
Írásbeli beszámoló a tárgyfelelősnek: link
Szóbeli prezentáció: link
2008. május 1., csütörtök
HOUG 2008 anyagok
Izsák Tamás jelezte egy hozzászólásban, hogy felkerültek a HOUG honlapjára a konferencia előadás anyagai. Akit érdekelnek a részletek, az nyugodtan válogathat közülük.
Kellemes olvasgatást!
Kellemes olvasgatást!
2008. április 19., szombat
Memória konfiguráció - Alapelvek
Az Oracle adatbázis alapvetően memóriában tárol minden információt. Azonban, ha nincs elegendő erőforrás, akkor az operációs rendszer kénytelen átmenetileg kitenni egy részét a merevlemezre, amíg ismét szükség lesz rá. Ez sajnos elkerülhetetlen elegendő memóriával nem rendelkező rendszerek esetében. (Ugye a memória olvasási és írási sebessége nagyságrendekkel gyorsabb, mint a lemezé.) Egy másik probléma pedig, hogy csak a működéshez elengedhetetlen információk vannak a memóriában, az adatok viszont a merevlemezen pihennek(a TimesTen az adatokat is a memóriában tárolja). Ezeket be kell olvasni, ha szükség van rájuk. A gyakran használt adatokat pedig valamilyen stratégia szerint minél tovább a memóriában kell marasztalni, hogy elkerüljük a felesleges I/O műveleteket.
A cél tehát kirajzolódni látszik. Csökkenteni a fizikai írás/olvasás műveleteket amennyire csak lehet akár cache-eléssel, vagy akár az adatblokkok behozásának hatékonyabbá tételével.
Az alapvető memória részek, melyek hatással vannak a teljesítményre:
Automatikus memória kezelés
Alapesetben a telepített Oracle példányunk automatikusan kezeli a rendelkezésére álló memóriát. Ebbe csak nagyon kevés beleszólásunk van. Mindössze a felhasznált memória célméretét (MEMORY_TARGET) és maximumát (MEMORY_MAX_TARGET) szabhatjuk meg, minden más az adatbázis dolga. Elvégzi a területek kiosztását és méretezését az SGA-nak és PGA-nak. Törekszik a legoptimálisabb megoldásra.
Ha mégis úgy döntünk, hogy magunk szeretnénk kezelni a kiosztott memória területeket, akkor érdemes használni a beépített Memory Advisort.
Automatikus osztott memória kezelés
Ha a szerverpéldányunk SGA-ját szeretnénk egyszerűsítve kezelni, akkor ezt megtehetjük egyszerűen. Csupán az SGA_TARGET paramétert kell nullánál nagyobb értékre állítani (ezzel foglalhatjuk le az SGA-nak szükséges területet), utána pedig a STATISTICS_LEVEL-t TYPICAL vagy ALL módba kapcsolni. Ezekkel a beállításokkal az SGA automatikusan szétosztja a rendelkezésére álló memóriát az alábbi területek között: buffer cache, shared pool, large pool, java pool, streams pool. Ha az ezekhez tartozó memóriaterületeket nullánál nagyobb értékekre állítjuk, akkor ezzel a számukra szükséges minimum területet állítottuk be. Ezt figyelembe veszi az adatbáziskezelő a területek szétosztásánál.
Az SGA_TARGET változót dinamikusan is állíthatjuk, ezzel hozzá hangolva az éppen aktuális rendszerműködéshez. Ha az SGA_TARGET-et nullára állítjuk szerver induláskor, akkor a legutolsó beállítások fognak vonatkozni az SGA területeire(buffer cache, shared pool,...). Ezeket azonban személyesen is átállíthatjuk a megfelelő változókkal: DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE, STREAMS_POOL_SIZE. Erről azonban majd később.
Vannak azonban olyan memóriaterületek is, melyekre az automatikus osztott memória kezelésnek nincsen hatása(log buffer, más cache-ek, belső SGA foglalások), azonban az SGA-ból területet vonnak el. Érdemes odafigyelni rájuk.
Memóriaterületek dinamikus változtatása
Ha magunk szeretnénk a memóriaterületeinket kezelni, akkor ezt megtehetjük, de ekkor körültekintően kell eljárnunk. A területek méretének beállítását az alábbi paraméterekkel tehetjük meg: DB_CACHE_ADVICE, JAVA_POOL_SIZE, LARGE_POOL_SIZE, LOG_BUFFER, SHARED_POOL_SIZE. Ezek közül a Log buffer beállítása indítás után nem változtatható meg, a többi viszont dinamikusan kezelhető. A memória foglalás alapegysége az SGA-nak 4MB, amíg 1GB alatt van, felette viszont 16MB. Ezt menet közben nem lehet megváltoztatni. (Egyébként a V$SGA_DYNAMIC_COMPONENTS nézet tartalmazza az aktuális alapegységet.)
Azzal, hogy beállítjuk induláskor az SGA maximális méretét (SGA_MAX_SIZE) korlátot szabunk a teljes memóriahasználatnak. Az ide tartozó komponenseknek nem adhatunk több operatív tárak, mint amennyit kezdetben allokáltunk. Ezért amikor kiszámoljuk, hogy mennyi hely fog kelleni a szerverünk működéséhez, mindig becsüljük kissé túl, hogy ha valamilyen váratlan okból meg kell növelnünk egyes komponensek rendelkezésére álló memória területet, akkor ne kelljen feltétlenül elvennünk valamely máséból, hogy beleférjünk a keretbe.
Segítség a dinamikus újraméretezéshez
Ahhoz, hogy olyan döntéseket hozzunk meg, melyek eredményeként át kelljen méretezni memória területeket, információra van szükségünk az adatbázisunk állapotáról, teljesítményéről, elvégzett műveleteiről. Ebben segítenek nekünk előre definiált nézetek, melyek az alábbiak:
Megfontolások alkalmazás oldalon
A memória konfigurációját természetesen az alkalmazáshoz kell igazítani, azonban ha a memóriahasználatot megfelelően hangoljuk, akkor nagyban csökkenthetjük az erőforrás szükségleteket. Ha hatékonyan használjuk az adatbázis erőforrásait, akkor jobb teljesítményt érhetünk el, mintha ezzel nem foglalkoznánk.
A legjobb teljesítmény elérése érdekében tehát az alkalmazás memóriahasználatát optimálisan kell kezelni, valamint az adatbázis memória struktúráját az alkalmazás igényeihez kell teljesen igazítani. Ha változtatunk az alkalmazáson, akkor újra kell gondolni az adatbázis memória használatát is.
Ha Java kódot használunk, akkor ezzel külön kell foglalkozni, mert az Oracle adatbáziskezelő külön erre a célra fenntart egy memória területet (Java pool).
Az operációs rendszer memóriahasználata
A legtöbb operációs rendszer használja a lapozási technikát. Vagyis ha nincs elegendő memória, akkor valamilyen stratégia szerint kiválaszt egy memóriaterületet és azt a merevlemezre mozgatja, hogy a helyére az éppen aktuálisan futó processz adatai kerüljenek. Ez teljesítmény csökkenést eredményez az operációs rendszer szintjén. Ebből a megközelítésből tehát a teljesítmény növelése csak a rendelkezésre álló memória növelésével érhető el. Vagy a felesleges processzek leállítása, így szabad memóriaterülethez juthatunk.
Az SGA szemszögéből nézve nagyban rontaná a hatékonyságot, ha egy szerverpéldány egy része nem férne el a memóriába (pl. sok más folyamat miatt) és így folyton használni kéne a lapozást. Ezért ajánlatos valamilyen módon az SGA-t mindig a memóriában tartani. Ennek egy módja, ha van elég hely ugyan a memóriában, hogy megparancsoljuk az operációs rendszernek, hogy nem nyúlhat az SGA-hoz. Ezt az adatbázis LOCK_SGA paraméterével állíthatjuk be. Azonban ha ezt beállítjuk, akkor nem használhatjuk a MEMORY_TARGET és MEMORY_MAX_TARGET paramétereket.
Ha megalkottuk a helyes SGA beállításokat az alkalmazásunkhoz, akkor sem szabad megfeledkeznünk a kapcsolódó felhasználókról, mert nekik is szükségük lesz szabad memóriára, hogy elvégezhessék a műveleteket.
Az SGA aktuális állapotáról a SHOW SGA PL/SQL parancs kiadásával tájékozódhatunk.
Forrás: Oracle Database Performance Tuning Guide 11g Release 1 (11.1) - 7 Memory Configuration and Use - 7.1 Understanding Memory Allocation Issues
A cél tehát kirajzolódni látszik. Csökkenteni a fizikai írás/olvasás műveleteket amennyire csak lehet akár cache-eléssel, vagy akár az adatblokkok behozásának hatékonyabbá tételével.
Az alapvető memória részek, melyek hatással vannak a teljesítményre:
- Shared pool
- Large pool
- Java pool
- Buffer cache
- Streams pool size
- Log buffer
- Rendezéshez és hasheléshez szükséges memória(saját processz memória)
Automatikus memória kezelés
Alapesetben a telepített Oracle példányunk automatikusan kezeli a rendelkezésére álló memóriát. Ebbe csak nagyon kevés beleszólásunk van. Mindössze a felhasznált memória célméretét (MEMORY_TARGET) és maximumát (MEMORY_MAX_TARGET) szabhatjuk meg, minden más az adatbázis dolga. Elvégzi a területek kiosztását és méretezését az SGA-nak és PGA-nak. Törekszik a legoptimálisabb megoldásra.
Ha mégis úgy döntünk, hogy magunk szeretnénk kezelni a kiosztott memória területeket, akkor érdemes használni a beépített Memory Advisort.
Automatikus osztott memória kezelés
Ha a szerverpéldányunk SGA-ját szeretnénk egyszerűsítve kezelni, akkor ezt megtehetjük egyszerűen. Csupán az SGA_TARGET paramétert kell nullánál nagyobb értékre állítani (ezzel foglalhatjuk le az SGA-nak szükséges területet), utána pedig a STATISTICS_LEVEL-t TYPICAL vagy ALL módba kapcsolni. Ezekkel a beállításokkal az SGA automatikusan szétosztja a rendelkezésére álló memóriát az alábbi területek között: buffer cache, shared pool, large pool, java pool, streams pool. Ha az ezekhez tartozó memóriaterületeket nullánál nagyobb értékekre állítjuk, akkor ezzel a számukra szükséges minimum területet állítottuk be. Ezt figyelembe veszi az adatbáziskezelő a területek szétosztásánál.
Az SGA_TARGET változót dinamikusan is állíthatjuk, ezzel hozzá hangolva az éppen aktuális rendszerműködéshez. Ha az SGA_TARGET-et nullára állítjuk szerver induláskor, akkor a legutolsó beállítások fognak vonatkozni az SGA területeire(buffer cache, shared pool,...). Ezeket azonban személyesen is átállíthatjuk a megfelelő változókkal: DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE, STREAMS_POOL_SIZE. Erről azonban majd később.
Vannak azonban olyan memóriaterületek is, melyekre az automatikus osztott memória kezelésnek nincsen hatása(log buffer, más cache-ek, belső SGA foglalások), azonban az SGA-ból területet vonnak el. Érdemes odafigyelni rájuk.
Memóriaterületek dinamikus változtatása
Ha magunk szeretnénk a memóriaterületeinket kezelni, akkor ezt megtehetjük, de ekkor körültekintően kell eljárnunk. A területek méretének beállítását az alábbi paraméterekkel tehetjük meg: DB_CACHE_ADVICE, JAVA_POOL_SIZE, LARGE_POOL_SIZE, LOG_BUFFER, SHARED_POOL_SIZE. Ezek közül a Log buffer beállítása indítás után nem változtatható meg, a többi viszont dinamikusan kezelhető. A memória foglalás alapegysége az SGA-nak 4MB, amíg 1GB alatt van, felette viszont 16MB. Ezt menet közben nem lehet megváltoztatni. (Egyébként a V$SGA_DYNAMIC_COMPONENTS nézet tartalmazza az aktuális alapegységet.)
Azzal, hogy beállítjuk induláskor az SGA maximális méretét (SGA_MAX_SIZE) korlátot szabunk a teljes memóriahasználatnak. Az ide tartozó komponenseknek nem adhatunk több operatív tárak, mint amennyit kezdetben allokáltunk. Ezért amikor kiszámoljuk, hogy mennyi hely fog kelleni a szerverünk működéséhez, mindig becsüljük kissé túl, hogy ha valamilyen váratlan okból meg kell növelnünk egyes komponensek rendelkezésére álló memória területet, akkor ne kelljen feltétlenül elvennünk valamely máséból, hogy beleférjünk a keretbe.
Segítség a dinamikus újraméretezéshez
Ahhoz, hogy olyan döntéseket hozzunk meg, melyek eredményeként át kelljen méretezni memória területeket, információra van szükségünk az adatbázisunk állapotáról, teljesítményéről, elvégzett műveleteiről. Ebben segítenek nekünk előre definiált nézetek, melyek az alábbiak:
- V$MEMORY_CURRENT_RESIZE_OPS - A jelenleg is futó átméretezési műveletek listáját tartalmazó nézet.
- V$MEMORY_DYNAMIC_COMPONENTS - Az összes dinamikusan állítható paraméter aktuális értéke, beleértve az SGA és PGA méretét is.
- V$MEMORY_RESIZE_OPS - A legutóbbi 800 végrehajtott átméretezési művelet (csak a befejezettek).
- V$MEMORY_TARGET_ADVICE - Hangolási tanácsokat tartalmaz a MEMORY_TARGET paraméter állítására.
- V$SGA_CURRENT_RESIZE_OPS - Az éppen futó SGA átméretezési műveletek listáját jeleníti meg.
- V$SGA_RESIZE_OPS - A legutóbbi 800 végrehajtott SGA átméretezési művelet (csak a befejezettek).
- V$SGA_DYNAMIC_COMPONENTS - Az SGA dinamikus komponenseiről tárol információt. Tartalmazza az indítástól számított összes SGA átméretezési műveletet.
- V$SGA_DYNAMIC_FREE_MEMORY - Az SGA számára fennálló szabad memória mennyiségét tárolja, ha a jövőben át szeretnénk méretezni.
Megfontolások alkalmazás oldalon
A memória konfigurációját természetesen az alkalmazáshoz kell igazítani, azonban ha a memóriahasználatot megfelelően hangoljuk, akkor nagyban csökkenthetjük az erőforrás szükségleteket. Ha hatékonyan használjuk az adatbázis erőforrásait, akkor jobb teljesítményt érhetünk el, mintha ezzel nem foglalkoznánk.
A legjobb teljesítmény elérése érdekében tehát az alkalmazás memóriahasználatát optimálisan kell kezelni, valamint az adatbázis memória struktúráját az alkalmazás igényeihez kell teljesen igazítani. Ha változtatunk az alkalmazáson, akkor újra kell gondolni az adatbázis memória használatát is.
Ha Java kódot használunk, akkor ezzel külön kell foglalkozni, mert az Oracle adatbáziskezelő külön erre a célra fenntart egy memória területet (Java pool).
Az operációs rendszer memóriahasználata
A legtöbb operációs rendszer használja a lapozási technikát. Vagyis ha nincs elegendő memória, akkor valamilyen stratégia szerint kiválaszt egy memóriaterületet és azt a merevlemezre mozgatja, hogy a helyére az éppen aktuálisan futó processz adatai kerüljenek. Ez teljesítmény csökkenést eredményez az operációs rendszer szintjén. Ebből a megközelítésből tehát a teljesítmény növelése csak a rendelkezésre álló memória növelésével érhető el. Vagy a felesleges processzek leállítása, így szabad memóriaterülethez juthatunk.
Az SGA szemszögéből nézve nagyban rontaná a hatékonyságot, ha egy szerverpéldány egy része nem férne el a memóriába (pl. sok más folyamat miatt) és így folyton használni kéne a lapozást. Ezért ajánlatos valamilyen módon az SGA-t mindig a memóriában tartani. Ennek egy módja, ha van elég hely ugyan a memóriában, hogy megparancsoljuk az operációs rendszernek, hogy nem nyúlhat az SGA-hoz. Ezt az adatbázis LOCK_SGA paraméterével állíthatjuk be. Azonban ha ezt beállítjuk, akkor nem használhatjuk a MEMORY_TARGET és MEMORY_MAX_TARGET paramétereket.
Ha megalkottuk a helyes SGA beállításokat az alkalmazásunkhoz, akkor sem szabad megfeledkeznünk a kapcsolódó felhasználókról, mert nekik is szükségük lesz szabad memóriára, hogy elvégezhessék a műveleteket.
Az SGA aktuális állapotáról a SHOW SGA PL/SQL parancs kiadásával tájékozódhatunk.
Forrás: Oracle Database Performance Tuning Guide 11g Release 1 (11.1) - 7 Memory Configuration and Use - 7.1 Understanding Memory Allocation Issues
Memória konfiguráció
A most következő néhány bejegyzésben szeretném bemutatni, hogy adatbázisunk teljesítményét miként befolyásolja a rendelkezésre álló memória mennyisége és kiosztása. Először csak az alapelveket tisztázom, majd belemegyek az SGA részletes konfigurálási lehetőségeibe. Itt a Buffer Cache, Shared Pool, Large Pool és Redo Log Buffer tárgyalásáról lesz szó, majd kitérek a PGA beállítási lehetőségeire és használatára is.
Ahhoz, hogy adatbázisunk teljesítménye a lehető legjobb legyen, szükséges a konkrét feladathoz hangolni a rendszer memóriahasználatát. Olvasva ehhez kapcsolódó dokumentációkat mindig feltűnt egy mondat: "Oracle recommends using automatic memory management to manage the memory on your system." Ha szót fogadnék neki, akkor mondhatnám, hogy kész is vagyunk, mert alap esetben így működik adatbázisunk, és nekikezdhetünk a rendszer tervnek. De nem hiszek neki, ezért tovább olvasom ezeket a dokumentumokat. Rájövök, hogy jól tettem, hogy nem fordultam vissza rögtön az elején, mert rengeteg lehetőségünk van finomhangolni rendszerünket, amitől a rejtett teljesítmény növekedést várom.
Ahhoz, hogy adatbázisunk teljesítménye a lehető legjobb legyen, szükséges a konkrét feladathoz hangolni a rendszer memóriahasználatát. Olvasva ehhez kapcsolódó dokumentációkat mindig feltűnt egy mondat: "Oracle recommends using automatic memory management to manage the memory on your system." Ha szót fogadnék neki, akkor mondhatnám, hogy kész is vagyunk, mert alap esetben így működik adatbázisunk, és nekikezdhetünk a rendszer tervnek. De nem hiszek neki, ezért tovább olvasom ezeket a dokumentumokat. Rájövök, hogy jól tettem, hogy nem fordultam vissza rögtön az elején, mert rengeteg lehetőségünk van finomhangolni rendszerünket, amitől a rejtett teljesítmény növekedést várom.
2008. április 12., szombat
HOUG 2008
Lezajlott az idei HOUG konferencia, melyen idén először én is részt vehettem 3 "sorstársam" társaságában. Köszönet érte az Oracle Hungary Kft. -nek és természetesen Sárecz Lajosnak a meghívásért.
A rendezvény ideje alatt plenáris és szekció előadások voltak, de esténként a szórakozás sem maradt el. Minden nap a plenáris előadásokkal kezdődött a nap, de arra az első napot kivéve nem sikerült odaérni, mert az ébredés és reggeli eléggé elhúzódott. Rendszerint az első kávé szünetre, vagy az azelőtti előadásra értünk a helyszínre. Mentségünkre legyen, hogy minket nem a Konferencia helyszínén, a Hotel Azúrban szállásoltak el, hanem 10 percre onnan, a siófoki móló legvégén a Hotel Yacht Klubban.
Visszatérve a konferenciára sok pihenésre nem maradt időnk, mert mindig akadt érdekes előadás, amit nem lehetett kihagyni, így reggeltől(délelőtt) délután 5-6-ig elfoglaltuk magunkat. Utána akadt egy kis pihenő, majd vacsora, ami után rendszerint érdekes programokkal kedveskedtek a szervezők. Itt kiemelném az esténként díjmentesen fogyasztható csapolt Heinekent :) Persze más ital is ingyen volt a résztvevőknek, de én csak ezt próbáltam ki.
Az előadások közül legjobban Hoppán Gergely (Alpha Consulting 1996 Kft.) Blogoljunk és prosperáljunk című előadása tetszett, aki arról beszélt, hogy mi értelme egy szakmai blognak és azt hogyan kell írni ahhoz, hogy minél többen olvassák. A legjobban az a rész tetszett, amikor egy blogot egy nőhöz hasonlított kiemelve a két végletet. Egy céges honlap unalmas, lassan frissülő, száraz. Egy személyes blog szubjektív, abszolút szórakoztató és érdekes. Ennek a kettőnek az ötvözete adja a szakmai blogot, mely szórakoztató céges weboldal. És akkor a hasonlat: "Amikor feleséget választunk, akkor az a célunk, hogy a hölgy legyen egyszerre úrinő is, meg szexistennő is." Ez vitte a pálmát.
Volt még érdekes előadás bőven, de talán Papp Péter (Kancellár.hu) Oracle Hacking háziasszonyoknak című előadását érdemes kiemelni. Az előadás egy demóból állt, ahol megmutatta, hogy kell eltéríteni egy Oracle 10g patchek nélküli rendszert egy távoli gépről. Azt hiszem a hallgatóság majd lefordult a székről amikor már azt is elérte, hogy minden jogot megkapjon az egyszerű felhasználónk. Ültek a teremben sokan, akik ebben a pillanatban legszívesebben felhívták volna céges adatbázisuk adminisztrátorát, hogy azonnal telepítse fel a patcheket... :) Én mindenesetre jól szórakoztam.
Kardkovács Zsolt (BME TMIT) és Benkő Borbála (BME TMIT) közös előadását is volt alkalmam meghallgatni, melyben arról számoltak be, hogy milyen eredményeket értek el a saját magyar szótövesítő rendszerük fejlesztésében. Ennek alapja az Oracle Text technológia, mely lehetőséget ad arra, hogy szövegeket kezeljünk, rendszerezzünk OracleDB alapokon. Az általuk elkészített rendszer a HunLexer, amit egy rövid demón keresztül prezentáltak.
Nagy örömömre szolgált, hogy két előadás is volt TimesTen témakörben, így egy kis betekintést kaphattam a TT ipari környezetben lévő használatáról.
Az első előadást Ökrös Péter (Astron Informatikai Kft.) tartotta Oracle TimesTen for Real Time Business címmel. Az előadás első része a TimesTen technológia ismertetéséről szólt, majd két megvalósítást hozott fel példának, ami Magyarországon egyedülállónak mondható.
Az első példa egy Applikációs adatbázis felgyorsítása a Mavir Zrt.-nél, mely az első magyar TT prodzsekt volt. Ez nem volt egyszerű feladat, mert egy valós idejű vezérlőrendszerből kellett valós idejű konvertálást végezni az alkalmazások számára. Ezt a TimseTen Cache Connect funkciójával valósították meg.
A megoldandó problémák a következők voltak: gyorsabbnak kell lennie (10x, ha már Times<->Ten), tárolt eljárásokat pótolni kellett (mivel a TT nem támogatja), nagy rendelkezésre állás biztosítása Oracle adatbázis tárolt eljárásaival, TT csak valós (materializált) adatokat kezel. A feladatokat sikerrel oldották meg és a rendszert tényleg sikerült felgyorsítani, ha nem is tízszeres sebességre. Tanulságként annyi vonható le, hogy a TimesTen nem minden esetben gyorsít fel egy már meglévő rendszert, főleg akkor nem, ha ehhez nincs megfelelő szakértelem. Viszont, ha hozzáértő szakember készíti el a terveket, akkor jelentős gyorsulásra tehetünk szert.
A második példa egy Ügyviteli Jelentési Rendszer felgyorsítása volt, ahol a fő gondot az okozta, hogy az alkalmazásokhoz nem lehetett nyúlni, tehát egy olyan integrációs megoldást kellett kitalálni, ahol a beillesztett TimesTen réteg transzparensen tudja ellátni a feladatát. Ezt ugyancsak a Cache Connect funkcióval valósították meg. Érdekessége a dolognak, hogy összesen 10 mérnöknap ráfordítással értek el átlagosan 3x sebesség növekedést. Természetesen további ráfordítással és fejlesztéssel a sebesség tovább növelhető.
Az előadás végén még megemlítésre kerültek a TimesTen további alkalmazási területei, mint például a Call Center-ek (azonnali hibafeloldás), telekommunikáció (sms nyugtázás), banki alkalmazások (gyorsabb adathozzáférés).
A másik TimesTen előadást Mészáros András (Allround Informatikai Kft.) tartotta A TimesTen lehetőségei a Magyar Telekom mobil árazó rendszerében címmel. Az előadó arról számolt be, hogy a TimesTennel milyen eredményeket lehet elérni ezen területen. Ez egy tanulmány ismertetése volt, a megvalósítás még várat magára. Szó volt a számlázó rendszer architektúrájáról, komponenseiről és hogy mihez érdemes hozzányúlni ahhoz, hogy teljesítmény növekedést érjenek el. Megemlítette a tervezési döntéseket is, valamint az elvárásokat a fejlesztéssel kapcsolatban. Az előadás végén összefoglalta a vizsgálat menetét és a mérések eredményeit. Természetesen megéri elvégezni az átalakítást a TT felhasználásával. Az előadó megemlítette, hogy a várt eredményeken túl egy pozitív észrevételük is volt, mégpedig, hogy még kedvezőtlen helyzetben is nagyon gyors volt ez megoldás. A mérések alapján jó választás.
Ezeken kívül természetesen még sok előadást meghallgattam a három nap alatt, azonban nem sikerült megszerettetnem magammal a Business Intelligence témát. Pedig én megpróbáltam. Összesen három ilyen témájú előadást hallgattam végig, de kivétel nélkül mindnek a vége felé már kapartam a falat. Volt amelyikről ki kellett jönnöm. Na de mindegy.
Összességében nagyon hasznos volt a konferencia és örülök, hogy elmehettem. Remélem jövőre is részt vehetek, talán már a másik oldalon...
A rendezvény ideje alatt plenáris és szekció előadások voltak, de esténként a szórakozás sem maradt el. Minden nap a plenáris előadásokkal kezdődött a nap, de arra az első napot kivéve nem sikerült odaérni, mert az ébredés és reggeli eléggé elhúzódott. Rendszerint az első kávé szünetre, vagy az azelőtti előadásra értünk a helyszínre. Mentségünkre legyen, hogy minket nem a Konferencia helyszínén, a Hotel Azúrban szállásoltak el, hanem 10 percre onnan, a siófoki móló legvégén a Hotel Yacht Klubban.
Visszatérve a konferenciára sok pihenésre nem maradt időnk, mert mindig akadt érdekes előadás, amit nem lehetett kihagyni, így reggeltől(délelőtt) délután 5-6-ig elfoglaltuk magunkat. Utána akadt egy kis pihenő, majd vacsora, ami után rendszerint érdekes programokkal kedveskedtek a szervezők. Itt kiemelném az esténként díjmentesen fogyasztható csapolt Heinekent :) Persze más ital is ingyen volt a résztvevőknek, de én csak ezt próbáltam ki.
Az előadások közül legjobban Hoppán Gergely (Alpha Consulting 1996 Kft.) Blogoljunk és prosperáljunk című előadása tetszett, aki arról beszélt, hogy mi értelme egy szakmai blognak és azt hogyan kell írni ahhoz, hogy minél többen olvassák. A legjobban az a rész tetszett, amikor egy blogot egy nőhöz hasonlított kiemelve a két végletet. Egy céges honlap unalmas, lassan frissülő, száraz. Egy személyes blog szubjektív, abszolút szórakoztató és érdekes. Ennek a kettőnek az ötvözete adja a szakmai blogot, mely szórakoztató céges weboldal. És akkor a hasonlat: "Amikor feleséget választunk, akkor az a célunk, hogy a hölgy legyen egyszerre úrinő is, meg szexistennő is." Ez vitte a pálmát.
Volt még érdekes előadás bőven, de talán Papp Péter (Kancellár.hu) Oracle Hacking háziasszonyoknak című előadását érdemes kiemelni. Az előadás egy demóból állt, ahol megmutatta, hogy kell eltéríteni egy Oracle 10g patchek nélküli rendszert egy távoli gépről. Azt hiszem a hallgatóság majd lefordult a székről amikor már azt is elérte, hogy minden jogot megkapjon az egyszerű felhasználónk. Ültek a teremben sokan, akik ebben a pillanatban legszívesebben felhívták volna céges adatbázisuk adminisztrátorát, hogy azonnal telepítse fel a patcheket... :) Én mindenesetre jól szórakoztam.
Kardkovács Zsolt (BME TMIT) és Benkő Borbála (BME TMIT) közös előadását is volt alkalmam meghallgatni, melyben arról számoltak be, hogy milyen eredményeket értek el a saját magyar szótövesítő rendszerük fejlesztésében. Ennek alapja az Oracle Text technológia, mely lehetőséget ad arra, hogy szövegeket kezeljünk, rendszerezzünk OracleDB alapokon. Az általuk elkészített rendszer a HunLexer, amit egy rövid demón keresztül prezentáltak.
Nagy örömömre szolgált, hogy két előadás is volt TimesTen témakörben, így egy kis betekintést kaphattam a TT ipari környezetben lévő használatáról.
Az első előadást Ökrös Péter (Astron Informatikai Kft.) tartotta Oracle TimesTen for Real Time Business címmel. Az előadás első része a TimesTen technológia ismertetéséről szólt, majd két megvalósítást hozott fel példának, ami Magyarországon egyedülállónak mondható.
Az első példa egy Applikációs adatbázis felgyorsítása a Mavir Zrt.-nél, mely az első magyar TT prodzsekt volt. Ez nem volt egyszerű feladat, mert egy valós idejű vezérlőrendszerből kellett valós idejű konvertálást végezni az alkalmazások számára. Ezt a TimseTen Cache Connect funkciójával valósították meg.
A megoldandó problémák a következők voltak: gyorsabbnak kell lennie (10x, ha már Times<->Ten), tárolt eljárásokat pótolni kellett (mivel a TT nem támogatja), nagy rendelkezésre állás biztosítása Oracle adatbázis tárolt eljárásaival, TT csak valós (materializált) adatokat kezel. A feladatokat sikerrel oldották meg és a rendszert tényleg sikerült felgyorsítani, ha nem is tízszeres sebességre. Tanulságként annyi vonható le, hogy a TimesTen nem minden esetben gyorsít fel egy már meglévő rendszert, főleg akkor nem, ha ehhez nincs megfelelő szakértelem. Viszont, ha hozzáértő szakember készíti el a terveket, akkor jelentős gyorsulásra tehetünk szert.
A második példa egy Ügyviteli Jelentési Rendszer felgyorsítása volt, ahol a fő gondot az okozta, hogy az alkalmazásokhoz nem lehetett nyúlni, tehát egy olyan integrációs megoldást kellett kitalálni, ahol a beillesztett TimesTen réteg transzparensen tudja ellátni a feladatát. Ezt ugyancsak a Cache Connect funkcióval valósították meg. Érdekessége a dolognak, hogy összesen 10 mérnöknap ráfordítással értek el átlagosan 3x sebesség növekedést. Természetesen további ráfordítással és fejlesztéssel a sebesség tovább növelhető.
Az előadás végén még megemlítésre kerültek a TimesTen további alkalmazási területei, mint például a Call Center-ek (azonnali hibafeloldás), telekommunikáció (sms nyugtázás), banki alkalmazások (gyorsabb adathozzáférés).
A másik TimesTen előadást Mészáros András (Allround Informatikai Kft.) tartotta A TimesTen lehetőségei a Magyar Telekom mobil árazó rendszerében címmel. Az előadó arról számolt be, hogy a TimesTennel milyen eredményeket lehet elérni ezen területen. Ez egy tanulmány ismertetése volt, a megvalósítás még várat magára. Szó volt a számlázó rendszer architektúrájáról, komponenseiről és hogy mihez érdemes hozzányúlni ahhoz, hogy teljesítmény növekedést érjenek el. Megemlítette a tervezési döntéseket is, valamint az elvárásokat a fejlesztéssel kapcsolatban. Az előadás végén összefoglalta a vizsgálat menetét és a mérések eredményeit. Természetesen megéri elvégezni az átalakítást a TT felhasználásával. Az előadó megemlítette, hogy a várt eredményeken túl egy pozitív észrevételük is volt, mégpedig, hogy még kedvezőtlen helyzetben is nagyon gyors volt ez megoldás. A mérések alapján jó választás.
Ezeken kívül természetesen még sok előadást meghallgattam a három nap alatt, azonban nem sikerült megszerettetnem magammal a Business Intelligence témát. Pedig én megpróbáltam. Összesen három ilyen témájú előadást hallgattam végig, de kivétel nélkül mindnek a vége felé már kapartam a falat. Volt amelyikről ki kellett jönnöm. Na de mindegy.
Összességében nagyon hasznos volt a konferencia és örülök, hogy elmehettem. Remélem jövőre is részt vehetek, talán már a másik oldalon...
2008. április 2., szerda
Tervezés és fejlesztés a teljesítmény nevében - Rendszer architektúra
Rendszer architektúra
Hardver és szoftver komponensek
Hardver
Egy rendszer hardver elemeit érdemes úgy méretezni, mint ahogy egy hídépítő mérnök tervezi a hidat. Mivel a költségekkel mindig számolni kell, ezért nem érdemes bizonyos részeit a legjobb és legdrágább anyagokból építeni, míg más részeit olcsóbb, és így gyengébb elemekből. A híd teherbírása a leggyengébb rész teherbírása lesz. Sokkal erősebb hidat lehet építeni, ha valamiféle egyensúlyt keresünk az egyes részek minősége között, és próbáljuk ezt egymáshoz közel tartani és a költségeket ennek megfelelően minimalizálni.
Egy számítógépes rendszer tervezésénél is pontosan ez a helyzet. Törekedni kell tehát az egyensúlyra és úgy méretezni leendő rendszerünket.
Az alapvető hardver komponensek:
- Processzor
- Memória
- I/O alrendszer
- Hálózat
Szoftver
Úgy, mint a számítógépeknek is vannak közös hardver elemei a szoftvereknek is vannak funkcionálisan közös elemeik. Ha az alkalmazásokat szétválasztjuk funkcionális elemekre, jobban megértjük ezek működését.
A legtöbb alkalmazás tartalmazza az alábbi komponenseket:
- Felhasználói felület
- Üzleti logika
- Felhasználói kérések és erőforrás foglalás
- Adat és tranzakció kezelés
Felhasználói felület
A felhasználó ezen a felületen keresztül kommunikál a programmal.
Feladatai:
- Kép megjelenítése
- Adatgyűjtés és kézbesítés az üzleti logikai rétegnek
- Bejegyzéseket érvényesíti
- Navigál az alkalmazás állapotai között
Üzleti logika
Az alapvető logikai egység. Ettől függ, hogy az alkalmazás milyen feladatot lát el. Ha ebben hiba van, annak helyreállítása nagyon költséges is lehet. Procedurális és deklaratív részek alkotják.
Feladatai:
- Adatmodell átültetése relációs sémába
- Kényszerek definiálása a relációs sémában
- Az üzleti logika megvalósítása függvények segítségével
Felhasználó kérések és erőforrás foglalás
Ez a komponens minden alkalmazásban szerepel. Egy több felhasználós rendszerben az erőforrás foglalást elvégzi az adatbázis szerver, vagy az operációs rendszer. Azonban nagyon nagy alkalmazás esetén a rendszer tervezőjének meg kell bizonyosodnia, hogy nagy terhelés esetén is garantálható a normális működés.
Az ide tartozó feladatok:
- Adatbázis-kapcsolat kezelése
- Lekérdezések végrehajtása
- Kliensek kezelése
- Egyensúlyban tartani a felhasználói kéréseket a hardver erőforrások függvényében
Adat és alkalmazás kezelés
Ezért főleg az adatbázis szerver és az operációs rendszer felelős.
Feladatok:
- Egyidejű adathozzáférés garantálása zárak és tranzakciók segítségével
- Optimalizált adathozzáférés indexek és cache segítségével
- Gondoskodni az adatmódosítások logolásáról
- Érvényesíteni az adatokra vonatkozó szabályokat
A szükségleteknek megfelelő helyes rendszer-architektúra beállítása
Meghatározni a helyes rendszer architektúrát nem egyszerű feladat. Sokszor többször át kell gondolni a tervezés különböző fázisaiban. Alapvetően megkülönböztetünk interaktív (pl. árusító rendszerek, email szerverek, web alapú alkalmazások…) és processz alapú (pl. csalás detektáló rendszer, direct mail) rendszert. A legtöbb esetben ez utóbbit könnyebb fejleszteni, mert itt hiányzik a felhasználói felület. Azonban itt a feladat is nehezebb, mert a célok nem annyira tiszták, mint egy felhasználói igényeket kielégítő rendszerben. A tervező mérnökök nincsenek hozzászokva nagy adatmennyiségek kezeléséhez.
A rendszer architektúra meghatározása nem tartozik a determinisztikus dolgok közé. Ahhoz, hogy valaki jó tervező mérnökké váljon, rengeteg tapasztalatra van szükség. Azonban álljon most itt néhány kérdés, melyek megválaszolása elősegítheti a helyes architektúra kialakítását.
Elsődleges kérdések:
- Hány felhasználó fogja használni a rendszert?
Majdnem minden alkalmazás besorolható az alábbi kategóriák egyikébe.
· Nagyon kevés felhasználó egy keveset használt számítógépen
Ez általában egy felhasználót jelent. A tervezésnél a fő szempont az, hogy ez az egy felhasználó a lehető legjobb hatékonysággal tudja használni az alkalmazást, minimális válaszidővel. Ezeknek az alkalmazásoknak a felhasználói ritkán zavarják egymást és az erőforrás ütközések is minimálisak.
· Közepesen sok és sok felhasználó egy vállalati, osztott alkalmazásban
Ebben az esetben a felhasználók száma limitált és megjósolható, például egy vállalat alkalmazottai. Azonban a megbízhatóság döntő szempont a tervezésnél. A felhasználók közös erőforrást használnak, így nagy terhelésnél is fontos a válaszidő kordában tartása.
· Megszámolhatatlan felhasználó fér a rendszerhez az interneten keresztül
Ennél az alkalmazástípusnál fontos a mérnöki hozzáértés, mert gondosan meg kell tervezni az erőforrások elosztását. Ha elfogy valamelyik hardverkomponens tartaléka, akkor könnyen kialakulhat ’bottleneck’, ami a rendszer instabilitásához vezethet. Az ilyen alkalmazásokhoz szükséges terhelés kiegyenlítés, állapotmentes alkalmazás szerver, és hatékony adatbázis kapcsolat menedzsment.
- Milyen lesz a felhasználói hozzáférés?
A felhasználói felület megválasztása a web-alapú technológiáktól egészen a saját kliens programig. - Hol vannak a felhasználók?
A felhasználók közötti távolság szabja meg bizonyos esetekben, hogy mennyi lehet a késleltetési idő. De a felhasználók helye még azt is befolyásolhatja, hogy melyik napszakban legyen a karbantartás, és mikor legyen feltétlenül elérhető. - Mekkora a hálózati sebesség?
A hálózati sebesség nagyban befolyásolja azt, hogy mennyi adatot célszerű küldeni egyszerre a felhasználói felület és az adatbázis szerver között. Ha lassú a sebesség, akkor nem érdemes minden egyes új információt átküldeni, hanem csak tömbösítve, mert akkor nem lesz szétdarabolt a bevitel. Ha pedig gyors a hálózati elérés, amit használunk, akkor megoldható az, hogy a szerver gyorsan reagáljon minden bevitelre. - Mennyi adathoz férhet hozzá egy felhasználó és ebből mennyi csak olvasható?
A lekérdezett adatmennyiség kihat a tervezési döntésekre. A tervezőnek meg kell bizonyosodni róla, hogy a válaszidő az adatbázis méretétől nem függ. Ha az alkalmazás jórészt csak lekér adatokat, akkor az adatreplikáció és adat elosztás egy jó megoldás a fő szerver tehermentesítésére (terhelés megosztás). - Mekkora a maximális megengedhető válaszidő?
Ezt felhasználója válogatja. El kell döntenünk, hogy aki használni fogja a rendszert, annak milliszekundumos válaszidőre van szüksége, vagy elegendő akár másodperces nagyságrend is. - Szükség van-e napi 24 órás elérésre?
Az internetről is elérhető rendszerek számára ez kötelező. Azonban a vállalati rendszerek, melyek csak egy időzónában működnek, elegendőek csak a munkaidő alatt elérhetőnek lenniük. A maradék időben pedig el lehet rajtuk végezni a karbantartási munkákat és átkonfigurálásokat. - Minden változtatást valós időben kell elvégezni?
Fontos a tervezéskor eldöntenünk, hogy a felhasználó által kért változtatásokat azonnal végre kell hajtanunk, vagy ráér esetleg később is, aszinkron módon.
Másodlagos kérdések:
- Mekkora lesz az adatbázis?
Az adatbázis mérete határozza meg a szerver gép erőforrásait. Az olyan szerver, amin nagy adatbázist használunk egy kicsivel nagyobb gépet igényel, mint amekkorára feltétlenül szüksége lenne. Ez azért van, mert az adminisztrációs folyamatok végrehajtási ideje nagyban függ az adatbázis méretétől. Ha nincs elegendő plusz erőforrás, akkor ezek a műveletek nagyon hosszúra is nyúlhatnak. - Mennyi a szükséges teljesítmény egy művelethez?
- Mik a rendelkezésre állási szükségletek?
- Milyen kompromisszumokat tudunk kötni, ha finanszírozási megszorítások lennének?
Feliratkozás:
Bejegyzések (Atom)
