Recenzija knjige: Troubleshooting Oracle Performance

Wednesday, 24.06.2009 – Dejan

─îuo sam ve─ç od nekoliko osoba, da je knjiga “Troubleshooting Oracle Performance” od Christiana Antogninija odli─Źna, pa sam se i sam odlu─Źio uvjeriti u to.

 

Knjiga je zahtjevna i nije namijenjena po─Źetnicima, nego naprednijim Oracle stru─Źnjacima, koji ┼żele jo┼í vi┼íe pro┼íiriti svoje znanje. U mnogim slu─Źajevima autor opisuje materiju, podrazumijevaju─çi da ─Źitalac vlada doti─Źnom tematikom i stru─Źnim pojmovima, tako da se ne tro┼íi prostor na osnovne stvari, nego se fokus stavlja ba┼í na komplikovane i skrivene (tj. malo poznate) mogu─çnosti Oracle baze.

Christian ve─ç na po─Źetku postavlja pitanje – kada treba tro┼íiti vrijeme na pobolj┼íanje performansi? Odgovor je jednostavan – prvenstveno onda kada se korisnici po─Źnu ┼żaliti ili kada se povrijedi neka ta─Źka ugovora (Service Level Agreement). Pri obja┼ínjavanju na─Źina nadgledanja performansi kompletnog sistema, upozorava da mnogi administratori┬áboluju od tzv.┬á “compulsive tuning disorder“, tj. od pretjeranog provjeravanja statisti─Źkih podataka vezanih za performanse baze┬ái poku┼íavanja konstantnog pobolj┼íanja rada baze, pri ─Źemu se “gubi” mnogo vremena, a to vrijeme je skupo.┬áNekad je svejedno da li neki SQL upit vra─ça rezultat za 5 sekundi ili za 50,┬áa pri ─Źemu┬ágazdi nije svejedno da mu DBA potro┼íi dan-dva na optimizaciju tog upita. Dakle, bitan je “feedback” i od korisnika, i od naru─Źioca aplikacije, kako biste mogli ustanoviti kada trebate tro┼íiti vrijeme na pobolj┼íanje performansi.

Nakon uvodnog opisa pristupu problemima i kada ih pravovremeno uo─Źiti, po─Źinju poglavlja sa prete┼żno tehni─Źkom pozadinom.

U drugom poglavlju mo┼żete saznati npr. ┼íta┬ásu selektivnost i kardinalnost (moram priznati da su ova dva pojma bolje i detaljnije opisana u knjizi “Cost Based Optimizer” od Jonathana Lewisa). Potom slijedi odli─Źan opis ┼żivotnog ciklusa jednog cursora, popra─çen detaljnim obja┼ínjenjem┬á parsovanja nekog SQL upita, te prednostima i manama kori┼ítenja bind varijabli. Na kraju ovog poglavlja su navedeni tipovi I/O operacija u bazi (logical reads, physical reads, physical writes, direct reads i direct writes).

Tre─çe poglavlje sadr┼żi informacije o ispravnoj identifikaciji problema. Kada vam korisnik ka┼że:”Jooooj, jest’ ovo generisanje izvje┼ítaja traje dugo… daj pogledaj, mo┼że┼í li imalo ubrzati…“, morate se odlu─Źiti gdje i kako po─Źeti sa tra┼żenjem uzroka tog usporenja. Pronala┼żenje pravog uzroka ovog problema mo┼że nekad biti dugotrajan i zahtjevan proces, a autor u ovom poglavlju daje savjete, koje metode i alate koristiti u tu svrhu. Tako mo┼żete pro─Źitati o instrumentalizaciji i profilisanju neke aplikacije, tj. o dvije metode skupljanja informacija potrebnih za pronala┼żenje problemati─Źne komponente doti─Źne aplikacije. Zatim mo┼żete saznati ─Źemu slu┼żi “tracing” i kako protuma─Źiti rezultat dobijenih podataka u trace datotekama. Za analizu tih podataka autor je ─Źak napravio vlastiti alat pod nazivom TVD$XTAT, a usput je opisao i kori┼ítenje TKProf alata, kao i Profilera (DBMS_PROFILER).

U narednim poglavljima (4. i 5. poglavlje), autor obja┼ínjava kako funkcioni┼íe “query optimizer“, te nagla┼íava veliki zna─Źaj redovnog prikupljanja i odr┼żavanja┬ásistemskih i objektnih statistika, koje bitno uti─Źu na rad “cost based optimizera“. Mo┼żete saznati, koji sistemski parametri se mogu konfigurisati, da bi performanse odgovarale va┼íim potrebama, npr. pode┼íavanje parametra db_file_multiblock_count – tako u OLTP sistemu ovaj parametar treba biti ┼íto manji, dok u Datawarehouse sistemu ovaj parametar treba biti ┼íto ve─çi.

Iz 6. poglavlja pod nazivom “Execution plans” sam li─Źno nau─Źio dosta novih stvari od kojih bih izdvojio obja┼ínjenje operacija NESTED LOOPS i CONNECT BY WITH FILTERING, a vama ─çe vjerovatno biti interesantan opis kori┼ítenja komande EXPLAIN PLAN i paketa DBMS_XPLAN, koji je popra─çen odli─Źnim tuma─Źenjem pravilne interpretacije “execution plana”. Za sve “tjunere” je ovo jako bitno poglavlje, tako da ga pa┼żljivo ─Źitajte.

Na red dolazi poglavlje o tehnikama SQL “tjuniranja”, odnosno pobolj┼íanja performansi nekog SQL upita. Navedene tehnike obuhvataju hintove, pode┼íavanje okru┼żenja u kojem se SQL izvr┼íava, zatim SQL profile, “Stored outlines“, te kori┼ítenje SQL Tuning Advisora. Ja li─Źno rijetko kad koristim hintove, a stored outline sam koristio za jednu third-party aplikaciju, ─Źiji source code nisam mogao mijenjati. SQL Tuning Advisor koristim tu i tamo u Grid Controlu, kada po┼żelim vidjeti prijedloge, koje taj “savjetnik” generi┼íe.

Da biste mogli uspje┼íno optimizovati neki SQL upit, morate znati kako neke stvari “interno” funkcioni┼íu. Osmo poglavlje govori o parsovanju SQL upita. Parsovanje SQL upita se mo┼że najjednostavnije nazvati internom analizom SQL upita, sa ciljem pronalaska najboljeg execution plana za taj upit, pri ─Źemu se pored ostalog provjeravaju prava pristupa ciljanim objektima, kao i postojanje odgovaraju─çih sistemskih i objektnih statistika. Prekomjerno parsovanje upita se mo┼że sprije─Źiti ispravnim pode┼íavanjem parametara open_cursors i session_cached_cursors (kod mene u bazi sam ovu vrijednost podesio na 200). Tako─Ĺe bitan uticaj ima i parametar cursor_sharing .

Deveto poglavlje “Optimizing Data Access” govori o odabiru pravilnog “pristupa” podacima.┬áUspore─Ĺeni su┬áFull table scan i kori┼ítenje particija u tabeli, sa napomenama ┼íta je kad i kako bolje koristiti. Potom dolazi pore─Ĺenje B-Tree i Bitmap indeksa, tako─Ĺe sa primjerima i savjetima, npr. koji indeks se u kojoj situaciji treba koristiti. Jako zanimljivo poglavlje, sa odli─Źnim primjerima particionisanja i kori┼ítenja indeksa. Jedina zamjerka u ovom poglavlju je nedovoljno detaljno opisano funkcionisanje “hash clustera“, po┼íto autor na vi┼íe mjesta u knjizi spominje kako je┬á“hash cluster” jako performantan u odnosu na┬áneke druge┬áopcije.┬á Sve u svemu, ako radite sa velikim tabelama, onda ovo poglavlje nudi pregr┼ít korisnih informacija.

Optimizing Joins“, odnosno optimizacija pridu┼żivanja tabela u SQL upitima, prili─Źno detaljno je obuhva─çena u 10. poglavlju. Pored osnovnih vrsta join-a (self-join, equi-join, cross-join, outer join), tu su jo┼í opisani “nested loop join“, “merge join“, “hash join“, “partition-wise join” i td. Mo┼żete saznati kako pojedine join metode interno funkcioni┼íu i kako mo┼żete da uti─Źete na odabir prave join metode. Datawarehouse specijaliste ─çe sigurno zanimati optimizacija “star transformation” upita.

Predzadnje poglavlje pod nazivom “Beyond Data Access and Join Optimization” govori o kori┼ítenju┬áslijede─çih “tehnika”:┬á“materialized views“, ke┼íiranje rezultata SQL upita (“result caching“), paralelno izvr┼íavanje upita, “direct-path insert“, “row prefetching” i “array interface“. Pro─Źitajte ┼íta autor ka┼że o doti─Źnim tehnikama u tom poglavlju, a ja ─çu prokomentarisati svaku od njih na osnovu li─Źnog iskustva:

materialized views: koristim ih u velikom broju i zaista doprinose br┼żem izvr┼íavanju pojedinih SQL upita. Ako vam je parametar query_rewrite_enabled pode┼íen na TRUE, onda mo┼żete jo┼í vi┼íe da uo─Źite korisnost, koju oni nude. Dodatak pod nazivom “materialized view log” je ┼ílag na tortu. Me─Ĺutim, nisu uvijek idealni, npr. ako imate ogromnu tabelu u koju ─Źesto unosite velike koli─Źine podataka (10-20 GB dnevno) i ako ┼żelite za tu tabelu kreirati jedan materialized view plus materialized view log, onda ─çete se iznenaditi suprotnim u─Źinkom. U tom slu─Źaju unos podataka traje prili─Źno du┼że, a znalo se desiti da ─Źitav proces jednostavno pukne. Ja sam tu pojavu prijavio Oracle Supportu i rekli su da je bug, zbog ─Źega sam ─Źak neko vrijeme morao deaktivirati parametar query_rewrite_enabled sve dok nije iza┼íao odgovaraju─çi patch za taj bug.

result caching: po┼íto ova opcija postoji tek od verzije 11g, nemam s njom nikakvog iskustva, ali ─Źitaju─çi u dokumentaciji i po komentarima drugih, izgleda da ke┼íiranje rezultata u odre─Ĺenim slu─Źajevima znatno pobolj┼íava performanse nekog SQL upita

paralelno izvr┼íavanje upita: eee, koje sam muke imao sa ovim ─Źudom… Nekad su pojedini upiti stvarno bili tako brzi, da se ─Źovjek odu┼íevi, ali previ┼íe puta su se znali zablokirati sa wait eventima “PX Deq Credit: send blkd” i┬á“px – waiting on query coordinator” (ili tako nekako, ne znam sad napamet), da sam morao prakti─Źno odustati od te metode pobolj┼íavanja performansi. Pisao sam o tome u par navrata(“ORA-00600: internal error code, arguments: [pxTmpAlo_pkey]” i “Oracle: paralelno izvrsavanje upita (Parallel Query Execution) “).

direct-path insert: uuuuu brale,┬ákako unos podataka ovom metodom LETI!!! Jako korisna metoda za unos velikih koli─Źina podataka, pogotovo uz NOLOGGING opciju.Ali avaj… sve ima svoje vrline i mane. Problem je ┼íto se na ovaj na─Źin zauzima samo novi prostor iznad high watermarka, pa se eventualno slobodni prostor ispod high watermarka ignori┼íe. Ako bri┼íete puno podataka iz te tabele u koju ih unosite “direct-path insert” metodom, onda ─çete biti suo─Źeni sa konstantnim pove─çanjem prostora, koju ta tabela zauzima. Mo┼że da se dogodi kontraefekat pri selektovanju podataka iz te tabele, jer se moraju “pro─Źitati” i prazni blokovi iz kojih su podaci obrisani, a nisu naknadno popunjeni zbog “direct-path insert” metode. Osim toga, ako koristite NOLOGGING opciju, onda ne─çe biti generisani Redo podaci, pa se u slu─Źaju havarije mo┼że desiti da izgubite te podatke. Zna─Źi oprezno sa ovom metodom!!!! Koristite ju npr. za “batch” prebacivanje ogromne koli─Źine podataka iz eksterne tabele u neku permanentnu tabelu u bazi.

row prefetching: ukoliko SQL upit vra─ça vi┼íe redova odjednom, onda ─çe vam opcija biti od pomo─çi. Ja li─Źno obo┼żavam BULK COLLECT i koristim ju u svakoj situaciji, kada moram u nekoj uskladi┼ítenoj proceduri obraditi stotine, hiljade ili ─Źak milione redova. Ograni─Źenje broja selektovanih redova pomo─çu opcije LIMIT daje vam mogu─çnost da ispravno koristite fizi─Źke resurse (CPU, I/O operacije i network bandwidth). Extra stvar!!

array interface: ova opcija je tako─Ĺe korisna u situacijama kada klijent ┼íalje veliku koli─Źinu podataka bazi i obrnuto. Ako imate neki batch job, koji preko sqlplus-a izvr┼íava neku proceduru, podesite arraysize u sqlplusu na ve─çu vrijednost (set arraysize 100), pa usporedite vrijeme izvr┼íavanja prije i nakon toga. Kod mene svaki batch job ima pode┼íen arraysize na minimalno 100, a neki ─Źak i na 500. Osim toga, u PL/SQL procedurama, pored BULK COLLECT obavezno isprobajte FORALL komandu. Pi─Źi kao zmaj, zar ne?

Zadnje poglavlje, 12. po redu, pod nazivom “Optimizing the Physical Design“, obja┼ínjava o pravilnom odabiru tipa podataka i rasporedu kolona u tabeli, zatim o nus-pojavama “row migration” i “row chaining“, te o “block contention” konfliktu kada vi┼íe transakcija pristupa istom bloku. Veoma korisno poglavlje, kako za administratore, tako i za programere.

 

I tako poglavlje po poglavlje do─Ĺe kraj knjige. ┼áta da vam ka┼żem – iako li─Źno imam dosta iskustva sa Oracle bazom, na┼íao sam prili─Źno dosta korisnih i novih informacija. Ne ka┼że se d┼żabe – ─Źovjek u─Źi dok je ┼żiv. Knjiga je zanimljiva i sadr┼żi dosta detalja, dijagrama i ostalih grafi─Źkih prikaza, koje upotpunjuju tekstualna obja┼ínjenja i primjere. Moja srda─Źna preporuka!

Ocjena: 10/10

  1. 5 Responses to “Recenzija knjige: Troubleshooting Oracle Performance”

  2. Kao ┼íto sam ve─ç napisao u preporuci sada samo mogu potvrditi da je to jedna od 3 knjige koju bi treba pro─Źitati svaki Oracle DBA (a i programer).
    Ne bi ba┼í rekao da nije namijenjena i po─Źetnicima, jer iako ima dosta specifi─Źnih stvari za iskusnije administratore, mnogo je vi┼íe korisnih informacija koje mogu koristiti po─Źetnicima, tj. kako neki problem adresirati, kako analizirati upit, sprovesti optimiziranje, ┼íto je explain plan, ┼íto je trace, itd.

    Osobno sam ─Źak nekim programerima preporu─Źio da pro─Źitaju poglavlja vezana za optimiziranje upita koja su sa grafovima i dijagramima dovoljno jasno i ─Źitko napisana da ih mogu skoro svi razumjeti.

    Meni se osobno najviše svidilo poglavlje di autor govori o sistemskim i objektnim statistikama.

    U svakom slu─Źaju super recenzija ­čśë

    By Marko on Jun 24, 2009

  3. Zaista sjajna recenzija!

    Trenutno vec imam stivo za citanje, pa cim zavrsim sa njim – nadam se da cu se moci posvetiti i ovoj knjizi…

    By Darko on Jun 25, 2009

  4. Hvala, hvala ­čÖé

    @Darko: Sta citas trenutno od literature?

    By Dejan on Jun 25, 2009

  5. da li mozete da mi uradite zadatak er dijagram ?

    ZADATAK GLASi :

    zadatak glasi:

    Korisnik telefona moze imati vise brojeva telefona . ZA svaki broj telefona se pamte razgovori za razgovore se pamti vreme pocetka i zavrsetka, broj telefona sa kojim se razgovor obavio i status (primljeni , pozvani , ili propusteni)

    By Anis on Oct 24, 2011

  6. mogu da ti uradim zadatak, ali necu ­čÖé
    potrudi se sam, a ako zapnes negdje, onda mozes postaviti pitanje sta i kako dalje …

    By Dejan on Oct 24, 2011

Post a Comment