Kontinuirani i eksponencijalni rast baze: negativne nuspojave i posljedice

Monday, 16.03.2009 – Dejan

Svakim danom u svakom pogledu Oracle baza sve vi┼íe┬áraste. Jedan od velikih razloga za brigu svakog administratora Oracle baza podataka… “Za┼íto!?” – pitate se…
Paaaa… krenimo prvo sa malom retrospektivom:

2005. veli─Źina┬ána┼íe glavne┬áOracle baze je iznosila oko 170 GB
2006. je porasla na 280 GB
2007. se veli─Źina baze popela na 410 GB
2008. je premašila 650 GB
2009. trenutna veli─Źina baze iznosi oko 970 GB i nezaustavljivo se bli┼żi granici od 1 TB.

─îinjenica je da veli─Źina baze kontinuirano i eksponencijalno raste. Tokom vremena se pri pove─çanju baze de┼íavaju┬ápromjene, koje dovode do negativnih i ne┼żeljenih nuspojava, ─Źije posljedice korisnici itekako osjete u svakodnevnom radu sa raznim aplikacijama.

Neke od tih karakteristi─Źnih promjena su:
– SQL upiti se izvr┼íavaju sporije/du┼że
– backup baze traje du┼że
– export/import podataka traje du┼że
– nedostatak┬ákapaciteta za skladi┼ítenje podataka
– prikupljanje statistika za CBO optimizer traje du┼że
itd.

Zbog tih nuspojava, koje dovode u pitanje normalno i pravovremeno ispunjavanje svih zadanih poslovnih┬áprocesa┬ádefinisanih uslovima┬áu sklopu SLA (“Service Level Agreement”) ugovora, svaki administrator Oracle baze podataka mora revidirati pode┼íavanja i odre─Ĺene korake u administraciji doti─Źne baze.

Mnoge od tih promjena uzrokuju i┬áglavobolju menad┼żerima, kada vide koliko su tro┼íkovi za odr┼żavanje ─Źitave baze eksplodirali. Npr. u 2009. godini je potrebno izdvojiti 5-6 puta vi┼íe sredstava za smje┼ítajni kapacitet (SAN storage ili dodavanje novih hard diskova lokalno na serveru), nego ┼íto je bilo potrebno u 2005. godini.┬á─îesto se mora dodati i jo┼í par procesora, a ukoliko se kupuje Oracle licenca po procesoru, onda tek┬ázamislite zabrinuto i smrknuto lice va┼íeg direktora ili menad┼żera.

Uo─Źljiva promjena je i ta, da backup baze traje du┼że nego ranije. Dok je u 2005. godini full backup bio gotov za manje od sat vremena, sada ─Źitav proces┬átraje oko 3-4 sata i to sa tendencijom rasta. No─çu se izvr┼íavaju razni automatski┬áprocesi (batch jobs), kojima je tako─Ĺe potrebno sve vi┼íe vremena za izvr┼íavanje.┬áAko imate unaprijed definisan “maintenance window” za backup (npr. svake no─çi od 02 od 06 sati ujutro), bi─çete prinu─Ĺeni da provjerite da li je to vrijeme dovoljno za uspje┼íno obavljanje te operacije, kako ne bi bilo ugro┼żeno normalno dnevno poslovanje. Jedno od rje┼íenja, koje se name─çe u slu─Źaju predugog backupa, je kori┼ítenje “block change tracking” tehnologije uz inkrementalni full backup na nivou┬á0 i inkrementalni backup na nivou 1.
Time se trajanje backup operacije svodi sa 3-4 sata na 10-15 minuta (iz dosada┼ínje prakse bih mogao re─çi da je za svaki GB promijenjenih blokova u bazi, potreban 1 minut za backup). Napomena: “block change tracking” tehnologija smanjuje peformanse baze za par procenata (max. 5% u slu─Źaju velikog broja DML operacija – unos, obrada ili brisanje podataka).

Nema ni┼íta frustriraju─çe, nego kad vas korisnici cimaju sa pritu┼żbama, kako im mnoge operacije oduzimaju mnogo vi┼íe vremena, nego ranije. “Za┼íto generisanje ovog izvje┼ítaja traje 5 minuta, a ranije je bilo gotovo za minut-dva!?” ili “Ho─çu da eksportujem ove podatke u Excel, ali ko─Źi stalno…” – samo su par primjera iz kolekcije prigovora na usporeno izvr┼íavanje SQL upita. Kako jednom ekonomisti ili knjigovo─Ĺi┬áobjasniti, da sada SQL upiti pretra┼żuje 5-6 puta vi┼íe podataka nego ranije? Mo┼żda nekim┬álai─Źkim analognim pore─Ĺenjem? “Da biste do┼íli do cilja, morali ste ranije pretr─Źati 100 metara. Da biste sada do┼íli do cilja, morate pretr─Źati 500 m, za ┼íto vam treba vi┼íe vremena i energije.

U zadnjim verzijama Oracle baze (prvenstveno po─Źev┼íi┬áod verzije 9i) na izvr┼íavanje svakog SQL upita glavni uticaj ima i CBO (Cost Based Optimizer), koji odre─Ĺuje na─Źin izvr┼íavanja tog upita, a┬áodluke o najbr┼żem i “najjeftinijem” izvr┼íavanju donosi na osnovu sakupljenih statistika svih objekata navedenih u upitu.
Te statistike se odnose na tabele (broj redova u tabeli, broj blokova i prosje─Źna du┼żina svakog reda), kolone (broj razli─Źitih vrijednosti u koloni, histogrami), indekse (broj leaf blokova, nivoa i clustering faktor), kao i na sistem (I/O i CPU karakteristike).
Za sakupljanje tih statistika je zadu┼żen automatski proces (Oracle scheduled job) pod nazivom GATHER_STATS_JOB, koji se standardno izvr┼íava svake no─çi od 22:00 do 06:00, te vikendom. Nemate pojma, koliko sam ja muka imao sa ovim CBO-om i njegovim tuma─Źenjem sakupljenih statistika, na osnovu kojih je dolazilo do sasvim pogre┼ínog izvr┼íavanja nekog SQL upita, ─Źime se vrijeme izvr┼íavanja popelo sa par sekundi na par minuta…┬á

Osim ┼íto je CBO bugovit, sakupljanje statistika zahtjeva puno CPU i I/O resursa, a ukoliko imate ogromnu bazu, onda se za mnoge objekte ne─çe pravovremeno sti─çi sakupiti svje┼że statistike, ┼íto opet dovodi do pogre┼ínog CBO-ovog tuma─Źenja najoptimalnijeg izvr┼íavanja nekog SQL upita. Mi smo morali┬ádodati jo┼í jedan┬áautomatski proces za eksplicitno sakupljanje va┼żnih i ─Źesto kori┼ítenih tabela u bazi, kako ne bismo morali ─Źekati da GATHER_STATS_JOB obradi i te tabele.

U takvim situacijama je potrebno ulo┼żiti dodatni napor za optimizaciju svakog SQL upita, ┼íto automatski zahtjeva i vi┼íe ljudskih resursa, tj. vrijeme jednog iskusnog senior programera ili DBA, a njihovo vrijeme skupo ko┼íta. Moja preporuka u svakom slu─Źaju je da postoje dvojica Oracle DBA, a ukoliko imate zahtjevan biznis (npr. Telekom┬ábaza u pogonu┬á24/7), onda taj broj mo┼że (da ne ka┼żem mora) biti i ve─çi.

Kako god bilo, rast baze je neizbje┼żan, tako da je revidiranje bud┼żeta za tehni─Źke i ljudske resurse neminovan. Moj savjet je da planirate na vrijeme sve tro┼íkove, koji nastaju porastom baze, a pogotovo da provjerite sve stavke ugovora iz SLA, kako ne biste pla─çali penale ili snosili nekakve posljedice za pogor┼íanje poslovnih procesa.

Post a Comment