V ideálnom svete by koncový zákazník o ladení výkonu databázy nikdy nepočul. Databáza by ostala neviditeľným komponentom tak, ako v stave, keď všetko funguje.
Žiadne dlhé odozvy systému, žiadne chybové hlášky, žiadne výpadky. Skrátka idylka. V realite tieto stavy poznáme. Príčiny bývajú rôzne.
Od momentu, kedy v analýze požiadaviek nebolo pokryté celé portfólio činností nového systému vrátane najčastejšie používaných funkcionalít, cez zlý dátový model, zlú konfiguráciu databázy, nevhodne použité softwarové komponenty, neaplikované záplaty až po zle naprogramovanú aplikáciu.
Veľkým problémom býva použitie nedostatočnej vzorky dát pri testovaní. Programátori si spravia vzorku dát s pár stovkami v lepšom prípade tisíckami riadkov (obec, mesto) napríklad v exceli, na tej to funguje nádherne a potom príde drsný stret s realitou (celoštátne nasadenie), kedy sa ukáže nevhodnosť dátového modelu pre požadovanú funkcionalitu.
Problémov s nedostatkom výkonu v databáze môže byť viac než sa na tento “papier“ zmestí. Ako z takýchto problémov von? Niekedy sú riešenia jednoduché. Zmena nastavení databázy, aplikovanie najnovších záplat, prípadne vytvorenie indexu pre zrýchlenie vyhľadávania. Zložitejšie riešenia bývajú spojené so zmenou dátového modelu. Zjednodušene povedané – dáta nie sú uložené v takej forme, aby ich systém mohol rýchlo načítať a odoslať na zobrazenie. Tu bývajú dosť často nutné úpravy aplikácie, prípadne nasadenie vyšších verzií databázy napríklad s partitioningom.
Ďalší okruh riešenia býva spojený so zmenou myslenia používateľov. Typický príklad je vyhľadávanie ľudí podľa mena. V prípade, že je meno používateľa frekventované ako napríklad Jozef Kováč a používateľ zadá do vyhľadávania len priezvisko, dostane od systému zoznam desiatok, stoviek ľudí s týmto priezviskom. Ak pridá do vyhľadávania aj krstné meno, zoznam sa podstatne zúži. Pridaním dátumu narodenia alebo bydliska sa výsledky vyhľadávania už zmestia na jednu obrazovku. Takisto používateľ väčšinou nepotrebuje výsledky za posledný mesiac k danému okamihu, postačia výsledky z nočného spracovania.
S čím všetkým sme sa stretli? Od aplikácií, ktoré po vytvorení pár indexov vstali z popola cez aplikáciu, kde sa používatelia navzájom blokovali a malou úpravou v databáze tento problém zmizol (použili sme základný princíp – nerobiť čo robiť netreba), až po skutočné databázové horory. Venujeme sa databázam Oracle, MS SQL Server, DB2.
Čo dodať na záver? Nepovažujte na svojich projektoch databázu za kontajner, do ktorého dáta len tak nasypete bez ladu a skladu. Ťažko sa potom vyberajú. Už od začiatku uvažujte, ako budete aplikáciu používať. Ako dlho budete dáta držať v systéme, ako ich budete archivovať. Aké reporty budete potrebovať. Požadujte testy nad reálnymi objemami dát. Vykonajte nárazové testovanie – ako sa bude Váš systém správať v špičke. Tlačte na používateľov, aby zadávali čo najpresnejšie požiadavky. Administrátori Vašich systémov nech aplikujú záplaty na bezpečnosť a výkonnosť systému. Potom máte veľkú šancu, že nebudete potrebovať ladenie systému, ktorý sa nachádza v havarijnom stave.
Ak ste počas čítania článku našli podobnosť s Vašou situáciou databázových aplikácií, kontaktujte www.unicore.sk
