Kontinuirani i eksponencijalni rast baze: negativne nuspojave i posljedice
Monday, 16.03.2009 – DejanSvakim 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.