1

6. UPRAVLJANJE PERFORMANSOM

Kada pitate nekoga šta spada u zaduženja administratora baza podataka (ABP), aktivnosti koje im prve padaju na pamet su praćenje performansi i fino podešavanje, što nije iznenađujuće. Bilo ko, ko je ikada koristio računare, je iskusio neki problem sa performansama. Šta više, sisteme relacionih baza podataka prati ozloglašena reputacija (uglavnom nezaslužena) da su loših performansi.

Većina organizacija prati i fino podešava performanse svoje IT infrastrukture koja obuhvata servere, mreže, aplikacije, desktop računare i baze podataka. Ipak, mnogi od navodno preduzetih proaktivnih koraka su u suštini reaktivni: korisnik se javlja sa problemom vremena odziva; nema dovoljno mesta na disku za skladištenje baze podataka; vreme paketne obrade se produžava unedogled; neko je uneo „upit iz pakla“ koji nikako da se izvrši do kraja. Priznajmo, ABP su često suviše zauzeti svakodnevnim aktivnostima administracije baze podataka na taktičkom nivou da bi proaktivno pratili i fino podešavali svoje sisteme u meri u kojoj bi to želeli.

Performans menadžment je najčešće reaktivan.

Rešavanje problema performanse zaista zahteva zajedničko zalaganje svih zaposlenih u preduzeću. Ipak, zadatak upravljanja performansom preduzeća često postaje posao grupe ABP. Svi koji su ikada radili kao ABP znaju da je sistem za upravljanje bazom podataka (SUBP) najčešće „kriv dok se ne dokaže suprotno“. Za svaki problem performanse se okrivljuje baza, bez obzira na pravi uzrok. ABP moraju biti sposobni da istraže i utvrde uzroke svakog pogoršanja performanse, makar samo da bi dokazali da to nije krivica baze podataka. Iz tih razloga, ABP moraju poznavati barem osnove cele IT infrastrukture, ali moraju poznavati i mnogo eksperata iz drugih srodnih oblasti (npr. mreže, operativni sistemi, komunikacioni protokoli). Posedovanje solidnog razumevanja IT infrastrukture omogućava ABP stručnjacima da efektivno odgovore na probleme performanse koji se javljaju. Na tržištu postoje alati za specifične probleme koji olakšavaju performans menadžment automatskim pokretanjem predefinisanih aktivnosti kada se ti problemi jave. Na primer, sistem za obaveštavanje može biti podešen da proaktivno prepozna bazu podataka koja je dosegla svoj maksimalni skladišni kapacitet ili da alocira više memorije kada SUBP dosegne svoja ograničenja. Šta više, postoje i drugi alati koji olakšavaju upravljanje i analizu performanse.

6.1. Definisanje performanse

Nameće se pitanje: šta se tačno podrazumeva pod performansom baze podataka? Neophodna je čvrsta definicija performanse baze podataka da bi se mogla planirati efikasnost. Možemo posmatrati performansu baze podataka sa sa stanovišta ponude i tražnje: korisnici zahtevaju informacije iz baze, a SUBP obezbeđuje informacije korisnicima. „Performansa BP“ se može definisati kao brzina kojom SUBP obezbeđuje informacije korisnicima, ali ovakva definicija obuhvata samo osnovni nivo performansi BP.

Neophodna je sveobuhvatnija definicija. Pet faktora utiču na performansu BP: obim posla, protok, resursi, optimizacija i nadmetanje.

Obim posla je kombinacija online transakcija, batch poslova, ad hoc upita, data warehouse analize i sistemskih komandi koje sistem obrađuje u datom trenutku. Obim posla se drastično menja u zavisnosti od dana, sata, čak i minuta. Nekad se obim posla može predvideti (kao što je velika obrada zarada na kraju meseca ili veoma malo ativnosti posle 19h, kad većina korisnika ode sa radnog mesta), a nekad je veoma nepredvidiv. Ukupni obim posla ima značajan uticaj na performansu BP.

2

Protok određuje ukupnu mogućnost računara da obradi podatke. Obuhvata brzinu inputa/outputa, brzinu procesora, paralelne mogućnosti mašine i efikasnost operativnog sistema i sistemskog softvera.

Hardverski i softverski alati koji su na raspolaganju sistemu su resursi sistema. Neki od resursa su kernel BP, memorijski diskovi, RAM čipovi, cache kontroleri i mikrokod.

Sve vrste sistema se mogu optimizovati, ali relacione BP su jedinstvene po svojoj osobini da se optimizacija upita primarno obavlja u okviru SUBP-a. Međutim, potrebno je optimizovati i mnoge druge faktore (kao što su SQL formulacije i parametri BP) da bi optimizator BP kreirao najefikasnije pristupne putanje.

Kada je potražnja za određenim resursom velika (veliki obim posla) dolazi do nadmetanja. Nadmetanje je situacija u kojoj dva ili više elemenata datog obima posla pokušavaju da koriste isti resurs u istom trenutku na konfliktan način (npr. dvostruko osvežavanje istog podatka). Sa porastom nadmetanja smanjuje se protok.

Na osnovu ovih pet faktora, performansu BP možemo definisati kao optimizaciju upotrebe resursa kako bi se povećao protok i minimiziralo nadmetanje i time obezbedila obrada maksimalno mogućeg obima posla.

Naravno, ne može se upravljati performansom BP a da se ne uzme u obzir njeno okruženje. Aplikacije redovno komuniciraju sa drugim podsistemima i komponentama IT infrastrukture, što takođe treba uračunati pri planiranju ukupne performanse organizacije. Ipak, treba ograničiti stvarnu odgovornost ABP za fino podešavanje performanse izvan područja koje pokriva ova definicija. Ako neki zadatak nije obuhvaćen gore navedenom definicijom, njegovo izvršavanje verovatno zahteva ekspertsko znanje izvan oblasti administracije BP. Samim tim, zadatke upravljanja performansom koji nisu pokriveni gore navedenim opisom bi trebalo da izvršava neko ko nije ABP, ili bi ih bar ABP trebali deliti sa drugim tehničarima.

Performansa BP podrazumeva optimizaciju upotrebe resursa kako bi se povećao protok i minimiziralo nadmetanje i time obezbedila obrada maksimalno mogućeg obima posla.

Osnovna mapa performanse BP

Neizostavni deo svake implementacije aplikacije je planiranje upravljanja performansom BP. Zato ABP mora sastaviti osnovni plan kojim će osigurati da se upravljanje i analiza performanse BP vrši za sve aplikacije BP širom organizacije. Celovit plan upravljanja BP uključuje alate za praćenje performanse aplikacije i fino podešavanje BP i SQL koda. U skladu sa pravilom 80/20 prvi korak je identifikovanje najproblematičnijih područja, što nije uvek jednostavno.

Najverovatniji krivac za većinu problema sa performansom aplikacija BP je neefikasan

SQL i aplikativni kod.

Iz iskustva, 75% do 80% svih problema performanse BP se mogu vezati za loše kodiran SQL ili aplikativnu logiku. To ne znači da je SQL u aplikacijama obavezno loš od početka. Iako aplikacija može biti 100% podešena za brzi relacioni pristup u momentu kad se počne koristiti, može doći do pogoršanja performanse tokom vremena. Razlozi degradacije su raznovrsni, kao što su rast BP, nove putanje pristupa podacima, dodatni korisnici, promene u poslovanju itd.

Naravno, SQL i aplikativni kod mogu i od početka biti loši. Bilo koji problem može biti uzrok lošeg SQL koda, uključujući:

• skeniranje tabela • nedostatak odgovarajućih indeksa • neodgovarajući izbori indeksiranja • ako se ne upotrebljavaju raspoloživi indeksi • zastarele statističke informacije BP

3

• neoptimalno spojene tabele • spajanje putem aplikacija umesto (najčešće) efikasnijeg SQL spajanja • neodgovarajući metod spajanja (ugneždene petlje, merge scan) • efikasni SQL kod unutar neefikasnog aplikativnog koda (petje) • neefikasna formulacija podupita (exists, not exists) • nepotrebno sortiranje (group by, order by, union).

Pronalaženje najskupljih SQL iskaza u velikom preduzeću je veoma teško. SQL iskazi koji prisvajaju resurse se mogu kriti u jednom od više stotina, čak i hiljada programa. Interaktivni korisnici koji kreiraju dinamičke, ad hoc SQL iskaze mogu biti bilo gde i svako ko kreira ad hoc upite može značajno uticati na ukupnu performansu.

Dobar pristup je upotreba SQL monitora koji prati sve SQL kodove pokrenute bio gde u okruženju. Ovi alati najčešće rangiraju SQL iskaze na osnovu resursa koje angažuju i otkrivaju ko je kreirao dati iskaz i u kom programu. Pošto se identifikuju iskazi koji angažuju najviše resursa, podešavanje se fokusira na najskuplje iskaze.

Ipak, nije uvek očigledno kako treba podesiti loše kodiran SQL iskaz.

Naravno, drugi faktori mogu negativno uticati na performansu BP. Preporučuje se periodična provera ukupne performanse instance BP i operativnog sistema servera. Trebalo bi proveriti i:

• alokaciju memorije (buffer/cache za podatke, SQL, autorizaciju) • opcije kreiranja log-a (cache i veličina log-a, Oracle rollback segmenti) • I/O efikasnost (razdvajanje tabela i indeksa na disku, veličina BP, fragmentisani i

prošireni fajlovi) • ukupni obim posla aplikacije i BP na serveru • definicije šeme BP

Da bi se postigla optimalna performansa BP treba planirati kombinaciju dobro definisane performanse BP sa detaljnim planom performanse specifičnim za dato preduzeće.

Praćenje nasuprot upravljanju

Nažalost, ABP se bave performansom na reaktivan način. Korisnik se javlja sa problemom vremena odziva. Nema dovoljno mesta na disku za skladištenje baze podataka. Vreme paketne obrade se produžava unedogled. Nastao je neki problem i neophodno je da se reši. Takve aktivnosti su u potpunosti reaktivne.

Čak se i mnogi od navodno proaktivnih koraka preduzetih u razvoju aplikacija smatraju za reaktivne. Izmena već završene aplikacije koja zahteva prepravku koda se ne može smatrati proaktivnom. Proaktivan pristup uključuje ispravku problema pre nego što se završi aplikacija.

Upravljanje performansom se može olakšati upotrebom nekih alata za specifične probleme koji automatski pokreću predefinisane aktivnosti kada se ti problemi jave. To je prvi korak ka upravljanju performansom. Proces upravljanja performansom se razlikuje od praćenja performanse jer kombinuje praćenje sa detaljnim planom rešavanja problema po njihovom nastanku.

Upravljanje performansom se sastoji iz tri koraka: praćenje, analiza i korekcija.

Ove tri komkonente se moraju sprovoditi povezano, kao što je prikazano na Slici 6-1. Praćenje je prva komponenta i sastoji se od skeniranja okruženja, provere funkcionalnosti neophodne infrastrukture i uopštenog posmatranja sistema tokom rada. Praćenje je proces identifikovanja problema.

Druga komponenta je analiza. Aktivnost praćenja može generisati stotine ili hiljade poruka ili veliki broj izveštaja. Alat za praćenje prikuplja informacije neophodne za podešavanje

4

performanse i donošenje odluka o optimizaciji, ali u suštini nema sposobnosti da samostalno donosi odluke na osnovu prikupljenih informacija. Zato je neophodna analiza – i analizu najčešće sprovode stručne osobe kao što su ABP.

Slika 6-1. Komponente upravljanja performansom

Optimizacija – korektivna aktivnost – je treća komponenta upravljanja performansom. Neki alati za upravljanje performansom omogućavaju tehničarima da, kada se jave određeni uslovi, automatizuju određene aspekte procesa upravljanja, automatskim pokretanjem korektivnih aktivnosti. Ipak, mnogi od ovih alata imaju ograničeno delovanje. Šta više, stručni tehničar mora podesiti automatizaciju kako bi bio siguran da će odgovarajući koraci optimizacije biti sprovedeni pravovremeno. U budućnosti će rešenja i alati za upravljanje performansom biti inteligentni – sa ugrađenim znanjem kako optimizovati SUBP, sa sposobnošću da vežbanjem podešavanja nauči šta najbolje funkcioniše.

Upravljanje performansom se može ostvariti jedino uz upotrebu proaktivnog plana performanse. Mnogi problemi se unapred mogu otkriti i definisati rešenja pre nego što ih postane neophodno hitno rešiti. Uz odgovarajući plan, korekcija problema performanse postaje lakša, i zaista, neki problemi performanse se mogu u potpunosti izbeći, ako se situacije koje potencijalno mogu izazvati problem isprave pre nego što problem nastane.

Upravljanje performansom se može ostvariti jedino uz upotrebu proaktivnog plana performanse.

Da bi se postiglo zaista proaktivno upravljanje performanse ABP mora planirati performansu aplikacije pre nego što se njen razvoj završi. To zahteva da ABP bude uključen u razvojni ciklus aplikacije i da osigura da performansa bude sastavni deo dizajna aplikacije. Postići tako visok nivo učešća ABP u procesu razvoja aplikacije može biti problematično. ABP nikad nema vremena i uvek se čini da će posle biti vremena da se pozabavi performansom aplikacije, umesto da se to odmah obavi kako treba.

Reaktivno naspram proaktivnog

Reaktivno upravljanje performansom će uvek biti potrebno jer će uvek nastajati neplanirani problemi. Nemoguće je predvideti svaki tip problema performanse, na kraju, i sistemi i aplikacije se menjaju tokom vremena. Reaktivno upravljanje performansom nije, samo po sebi, loše, ali je to manuelni, dugotrajni proces.

Identifikovanje problema

PRONAĆI PROBLEM

Praćenje

Definisanje rešenja

Optimiziranje okruženja

ANALIZA PROBLEMA

REŠAVANJE PROBLEMA

5

Proaktivno upravljanje performansom kombinuje predviđanje, planiranje i

automatizaciju kako bi se minimizovalo reaktivno praćenje i podešavanje.

Drugim rečima, proaktivno upravljanje performansom smanjuje trajanje, napor i ljudske greške nastale u implementaciji i održavanju efikasnih sistema BP.

Prethodna procena performanse (pre razvoja aplikacije)

U idealnim uslovima, ABP i osobe zadužene za razvoj aplikacije bi trebalo da uključe zahtev za visokom performansom u dizajn i konstrukciju aplikacija koristeći odgovarajuću metodologiju. Takva metodologija se mora odnositi na ADLC (Aplication Development Life Cycle – životni ciklus razvoja aplikacije) i mora uključiti taktiku za postizanje visoke performanse u kreiranje BP i koda aplikacije. Strogo definisan proces koji se fokusira na sigurne rezultate može obezbediti ugradnju performanse u aplikacije i BP, eliminišući time skupo redizajniranje i ponovo kodiranje – barem što se tiče većine problema performanse.

Probleme koji se uoče ranije u toku ADLC je lakše i jevtinije rešiti od kasnije uočenih problema, kao što je prikazano na Slici 6-2. Proaktivno upravljanje performansom može smanjiti troškove razvoja aplikacije, jer se odvija pre uvođenja aplikacije u proces poslovanja. Ispravljanje problema pošto se aplikacija pusti u rad je najskuplji metod upravljanja performansom, jer korisnici računaju na datu aplikaciju kako bi obavljali svoj posao. Problemi performanse u aplikaciji koja je u upotrebi mogu produžiti vreme neophodno za obavljanje ključnih aktivnosti, kao što je usluživanje klijenata. Šta više, ozbilji problemi performanse mogu izazvati i nedostatak proizvoda ili nemogućnost obavljanja posla.

Slika 6-2. Troškovi problema performanse tokom životnog ciklusa razvoja aplikacije

Procenjivanje performanse aplikacija se razlikuje od analize i optimizacije pojedinih upita u BP. Performansa bi trebalo da se definiše modelom koji se odnosi na celu aplikaciju, jer se pojedinačni upiti mogu optimizovati na štetu drugih upita. Model će pokazati ukupne efekte svih upita i kako svaki upit utiče na performanse ostalih. Takav model oogućava ABP da optimizuje ukupnu performansu.

Performansa bi trebalo da se definiše modelom koji se odnosi na celu aplikaciju.

Prikupljanje zahteva

Analiza Dizajn Razvoj Testiranje Upotreba Održavanje

ADLC faze

Tro

škov

i uvođen

ja iz

men

a

6

Kreiranje tačnog modela performanse je iterativni proces. Svaka promena se mora proveriti i ažurirati i izmeriti efektivnost njenog dejstva. Administratori BP, sistem administratori, osobe zadužene za razvoj aplikacije i osobe zadužene za planiranje moraju sarađivati i razmenjivati informacije, kako bi rešili svaki problem koji se može javiti u poslovanju i uticati na performansu.

Kreiranje trenda na osnovu podataka iz prošlosti

Jedna od značajnih aktivnosti upravljanja performansom je beleženje i analiziranje trenda upotrebe resursa i statističkih podataka o performansi u prošlosti. Kreiranje trenda performanse i resursa na osnovu podataka iz prošlosti omogućava ABP da predvidi potrebu za unapređenjem hardvera nedeljama, čak i mesecima unapred. Administratori mogu beležiti ključne statističke podatke performanse i skladištiti te informacije u tracker tabele u BP. Time se obezbeđuju vredne informacije iz prošlog perioda koje se mogu prikazati i analizirati. ABP može pratiti performansu i potrošnju resursa i predvideti kada će hardverski resursi biti potrošeni usled povećane upotrebe. Definisani trend u prošlosti može otkriti i periode niže performanse BP od uobičajene, uzrokovane povećanom upotrebom korisnika. Na primer, aplikacije BP često sporije funkcionišu prva tri dana u mesecu zahvaljujući zahtevima obrade na kraju meseca. Održavanje ključnih indikatora performanse iz prošlosti može biti veoma korisno za ABP pri pokušaju definisanja karakteristika performanse aplikacija, BP i sistema.

Održavanje ključnih indikatora performanse iz prošlosti može biti veoma korisno za ABP.

Upravljanje nivoom usluga

Upravljanje nivoom usluga (Service-level management – SLM) je „disciplinovana, proaktivna metodologija i procedure koje obezbeđuju pružanje odgovarajućeg nivoa usluge svim IT korisnicima u skladu sa prioritetima poslovanja i uz prihvatljive troškove“. Za efektivno upravljanje nivoom usluga, preduzeće mora pridavati odgovarajući značaj aplikacijama koje koristi i definisati za svaku aplikaciju vreme, napore i kapital koji se mogu upotrebiti za pružanje usluga.

Nivo usluge je mera funkcionisanja aplikacija. SLM osigurava odgovarajući rad aplikacija dodeljujući resurse aplikacijama na osnovu njihovog značaja za organizaciju. U zavisnosti od potreba organizacije, SLM se može usredsrediti na raspoloživost, performansu ili oboje. U smislu raspoloživosti, nivo usluge se može definisati kao "99,95% raspoloživosti od 9 do 20 časova radnim danima". Naravno, nivo usluge može biti određeniji, na primer "prosečno vreme odgovora za transakcije je dve sekunde ili manje pri obimu posla od 500 ili manje korisnika".

SLM osigurava dodelu resursa aplikacijama na osnovu njihovog značaja za organizaciju.

Da bi sporazum o novou usluga (SLA – service-level agreement) bio uspešan, svi učesnici moraju prihvatiti postavljene ciljeve raspoloživosti i performanse. Krajnji korisnici moraju biti zadovoljni performansom svojih aplikacija, a ABP i tehničko osoblje moraju imati mogućnost da upravljaju sistemom ka ispunjenju ciljeva. Kompromis je ključan da bi se postigao koristan SLA.

U praksi, mnoge organizacije nisu institucionalizovale SLM. Uz nove aplikacije stiže i mnogo nejasnih zahteva i obećanja o vremenu odziva ispod jedne sekunde, ali retko kad se sprovede određivanje prioriteta i budžetiranje neophodno da bi se osigurao taj nivo usluge, osim ako se obavljanje IT funkcije ne prepusti stručnjacima van organizacije. IT funkcije u okviru organizacije ne žele da potpišu SLA, jer ako je dobar, teško ga je ostvariti. Šta više, kad se teškoće oko ugovaranja SLA završe, preduzeće bi ipak moglo da prepusti sprovođenje SLA stručnjacima van organizacije umesto internoj IT grupi, zbog nižih troškova.

7

Ne treba pogrešno shvatiti. Za neuspeh SLM u većini preduzeća krivi su podjednako i IT stručnjaci i ostali zaposleni u preduzeću. Korisnici često žele bolju uslugu, ali nisu voljni da ulože napor i odrede prioritete svojih potreba ili da dodatno plate za bolju uslugu.

Dodatni potencijalni problem sa SLM je kontekst usluge koja se posmatra. Većina IT stručnjaka sagledava nivo usluge na osnovu pojedinih elemenata. Drugim rečima, ABP posmatra performansu na osnovu SUBP, sistem administrator na osnovu operativnog sistema ili sistema obrade transakcija itd. SLM posmatra uslugu na nivou cele aplikacije. Ipak, nekad je teško dodeliti odgovornost u okviru tipične IT infrastrukture. IT obično funkcioniše kao grupa silosa koji ne rade dobro zajedno. Često timovi zaduženi za aplikacije rade nezavisno od ABP, koji opet radi nezavisno od sistem administratora, kao što je prikazano na slici 6-3. Ako funkciju ABP aplikacije obavlja član tima zaduženog za aplikaciju, taj tim možda neće efektivno komunicirati sa silosom ABP preduzeća. Ovi odvojeni silosi otežavaju saradnju ka zajedničkom nivou usluge aplikacije.

Slika 6-3. IT silos u fragmentisanom okruženju

Da bi se ostvario sveobuhvatni SLM, ovi silosi se moraju rastaviti. Različita odeljenja u okviru IT infrastrukture moraju efektivno komunicirati i sarađivati međusobno. Bez toga je teško, ako ne i nemoguće ostvariti sveobuhvatni SLM.

Robustni SLM čini upravljanje performansom predvidivim. SLM upravlja očekivanjima svih učesnika. Kako bi ABP i krajnji korisnici bez SLA znali da li su performanse aplikacije na odgovarajućem nivou? Ne može, i ne treba, svaka aplikacija da ima vreme odziva manje od sekunde. Bez SLA korisnici i ABP mogu imati različita očekivanja, što dovodi do nezadovoljnih menadžera i frustriranih ABP.

Robustni SLM čini upravljanje performansom predvidivim.

Ako se primenjuje SLM, ABP mogu prilagoditi resurse dodeljujući ih aplikacijama koje su u SLA definisane kao najvažnije za ostvarenje ciljeva. Time se kontrolišu troškovi i kapital se upotrebljava u preduzeću najbitnijim segmentima poslovanja.

6.2. Vrste podešavanja performanse

Aplikacija BP zahteva neprekidnu interakciju između neusklađenih resursa obrade da bi funkcionisala efikasno i u skladu sa specifikacijama. U stvarnosti, podešavanje aplikacije BP se

Razvojni tim 3

ABP

ABP razv. tima

Razvojni tim 4

Sis. ad. mreže

Sis. ad. op. sis.

Sis. ad. TP

Razvojni tim 2

Razvojni tim 1

8

može razdvojiti na tri dela: podešavanje sistema, podešavanje BP i podešavanje aplikacije. Sva tri dela su povezana i određeni aspekti podešavanja zahtevaju integrisani pristup, ali se u nastavku razmatraju zasebno. Podešavanje sistema

Podešavanje sistema se vrši na najvišem nivou i ima najveći uticaj na ukupnu ispravnost aplikacije BP jer svaka aplikacija zavisi od sistema. Sistem se može definisati kao sam SUBP i sve njegove povezane komponente od kojih zavisi. Nikakvo podešavanje ne može pomoći BP ili aplikaciji kada server na kom je postavljena nema resursa ili je nepravilno instaliran.

SUBP se može i mora podesiti da bi se postigla optimalna performansa.

Način na koji se SUBP softver instalira, njegova memorija, disk, CPU, drugi resursi i bilo koja od opcija konfiguracije može uticati na performansu aplikacije BP.

Drugi sistemski softveri sa kojima SUBP stupa u interakciju su operativni sistem, mrežni softver, message queueing sisteme, middleware i procesori transakcija. Podešavanje sistema obuhvata instalaciju, konfiguraciju i probleme integracije, kao i obezbeđenje povezanosti softvera sa SUBP i aplikacijom BP. Podešavanje BP

Na performansu može uticati fizički dizajn BP, uključujući normalizaciju, pohranjivanje na disk, broj tabela, dizajn indeksa i upotreba DDL-a i povezanih parametara.

Fizička lokacija fajlova BP na disku utiče na performansu aplikacija koje pristupaju

podacima.

Što se više podataka skladišti na istom disku, više raste verovatnoća opadanja performanse.

Dizajn nije jedina komponenta performanse BP. Organizacija BP se vremenom menja. Sa unosom, ažuriranjem i brisanjem podataka iz baze opada efikasnost BP. Možda se fajlovi u kojima su podaci moraju uvećati da bi se u njih uneli novi podaci. Možda treba i dodatne fajlove, ili proširenja fajlova, rasporediti. I dezorganizacija i rast fajlova mogu smanjiti performansu.

I indeksi se moraju pratiti, analizirati i podešavati kako bi se optimizovao pristup podacima i da se osigura da oni nemaju negativan uticaj na izmenu podataka. Podešavanje aplikacije

Sama aplikacija mora biti odgovarajućeg dizajna i mora se pratiti njena efikasnost. Većina eksperata se slaže da je skoro 75% problema perfromanse izazvano neodgovarajućim kodom aplikacije. Primarni krivac je SQL; kodiranje efikasnih SQL iskaza može biti komplikovano. Osobe zadužene za razvoj moraju biti obučeni da formulišu, prate i podešavaju SQL iskaze.

Nisu svi problemi aplikacije uzrokovani neodgovarajućim SQL kodom.

Probleme može izazvati i jezik koda aplikacije u koji je upisan SQL kod. Na primer, Java, COBOL, C++ ili Visual Basic kod može biti neefikasan i time smanjiti performansu aplikacije.

6.3. Alati za podešavanje performanse

Alati BP pomažu efektivno upravljanje performansom. Neki SUBP prodavci obezbeđuju ugrađene opcije i grupisane alate za upravljanje performanse BP. Ti alati su često nedovoljni za velike ili aplikacije BP sa velikom frekvencijom upotrebe.

Mnogi drugi alati prisutni na tržištu mogu efektivno upravljati performansom ključnih

aplikacija BP.

9

Alati koji omogućavaju ABP da podešava performansu BP se dele u dve kategorije: upravljanje performansom i optimizacija performanse.

Postoji puno različitih vrsta alata za upravljanje performansom. • Monitori performanse omogućavaju ABP i analitičaru performanse da izmere

performansu aplikacija koje pristupaju BP na jedan (ili više) od tri načina: realno vreme, približno vreme (intervali) ili na osnovu trenda u prošlosti. Napredniji monitori performanse su bazirani na agentima.

• Alati za procenu performanse obezbeđuju predviđanje procene performanse za programe ucelo i SQL iskaze, na osnovu pristupnih putanja, radnog okruženja i mehanizma za kreiranje pravila i zaključivanje

• Alati za planiranje kapaciteta omogućuju ABP da analizira tekuće okruženje i dizajn BP i da i za jedno i drugo izvrši "what-if" scenario.

• Alati za SQL analizu i podešavanje obezbeđuju grafički i/ili tekstualni opis pristupnih putanja koje su određene relacionim optimizatorom. Ovi alati se mogu primeniti na pojedine SQL iskaze ili cele programe.

• Savetodavni alati poboljšavaju alate za SQL analizu i podešavanje obezbeđujući bazu znanja, koja pruža predloge kako reformulisati SQL za optimalnu performansu. Napredni alati mogu automatski promeniti SQL (po zahtevu) na osnovu predloga kodiranja iz baze znanja.

• Alati analize i podešavanja sistema omogućuju ABP da pregleda i menja parametre BP i sistema, uz upotrebu grafičkog interfejsa (npr. cache i/ili bufferpool podešavanje, određivanje veličine log fajla).

U kategoriji optimizacije performanse nekoliko alata se može upotrebiti za podešavanje BP. • Alati reorganizacije automatizuju proces ponovne izgradnje optimalno organizovane BP.

BP mogu izazvati probleme performanse svojom internom organizacijom (npr. fragmentacijom, redosledom redova, alokacijom skladištenja).

• Alati kompresije omogućuju ABP da minimizuju deo diska potreban za skladištenje BP i time smanjuju ukupnu upotrebu diska, a možda i vreme za izvršenje upita/programa, jer je potrebno manje inputa/outputa. (Upozorenje: alati kompresije mogu i povećati upotrebu CPU zbog svojih dodatnih algoritama kompresije/dekompresije)

• Alati sortiranja se mogu koristiti za sortiranje podataka pre unosa u BP da bi se obezbedilo da su redovi u unapred određenom redosledu. Dodatno, alati sortiranja se mogu koristiti umesto ORDER BY ili GROUP BY SQL. Dobijanje redova iz relacione BP je nekad efikasnije upotrebom SQL i ORDER BY nego samo SQL upitom a zatim samostalnim sortiranjem rezultata SQL upita.

ABP će često morati da koristi ove alate zajedno – integrisane i dostupne sa centralne konzole za upravljanje. Time ABP može da obavlja suštinske zadatke usmerene na performansu i zadatke administracije BP, sa jedinstvene platforme.

Mnogi SUBP prodavci obezbeđuju rešenja za upravljanje samo njihovim BP; na primer, Oracle obezbeđuje Oracle Enterprise Manager a Sybase obezbeđuje SQL Central. Ostali prodavci obezbeđuju robustnije opcije koje funkcionišu u heterogenim okruženjima, kao što su višestruki različiti serveri BP ili operativni sistemi.

Uopšteno, preporučljivo je koristiti rešenje SUBP prodavca samo ako preduzeće ima samo jedan SUBP. Preduzeća sa više SUBP-a koji rade u više operativnih sistema bi trebalo da istraže ostale prodavce alata.

6.4. Osnove performanse SUBP-a

Neka od pravila za postizanje ciljeva performanse vezanih za SUBP su:

10

• Ne preterivati sa podešavanjem. Većina ABP je više nego spremna da se bavi sitnim tehničkim pojedinostima SUBP-a. Nekad je ovo neophodno, ali ABP bi trebao uvek da ima u vidu ciljeve poslovanja BP i aplikacija kojima upravlja. Mudro je upravljati performansom na osnovu očekivanja i budžeta korisnika. Čak i ako je intelektualno izazovno fino podešavati upit do savršenstva, to može zahtevati suviše vremena i umanjiti raspoloživvo vreme za druge obaveze. Najbolje je prestati sa podešavanjem kada performansa dosegne predefinisani nivo usluge, koji su korisnici spremni da plate.

• Ostati fokusiran. ABP bi trebao da shvati cilj svakog zadatka koji obavlja i da ostane fokusiran na taj cilj. Ovo je značajno jer je SUBP složen, i kada se podešava jedno područje može se otkriti problem u drugom. U tom slučaju, najbolje je dokumentovati otkriveno i kasnije se vratiti, a trenutno nastaviti sa započetim podešavanjem. Šta više, pokušajem da se istovremeno podesi više stvari, ne može se steći uvid u uticaj bilo koje od njih na okruženje.

• Ne paničiti. Od ABP se očekuje da zna sve o SUBP kojim upravlja, što je nerealno. "Ne znam, ali saznaću." je jedna od najbitnijih fraza koju mora znati svaki ABP. Dobar ABP zna gde da traži odgovore i koga da zove u pomoć.

• Jasno komunicirati.Komunikacija je ključ za obezbeđenje odgovarajuće podešenog sistema BP visoke performanse. ABP se mora nalaziti u centru te komunikacije, usklađivati diskusiju i obim posla između korisnika, programera, menadžera i sistem administratora. Svet IT uopšte, a posebno tehnologije BP nekad koriste sopstveni jezik. Javljaju se mnogi slični i zbunjujući termini i od svih se očekuje da ih razumeju. Zato treba jasno definisati svaki, pa i osnovni iskaz kako bi svi govorili istim jezikom.

• Prihvatiti stvarnost. Mnoge organizacije se hvale svojom proaktivnošću, a u starnosti preduzimaju malo šta da zaustave probleme performanse pre nego što se jave. Ipak, svaka organizacija je zainteresovana za rešavanje problema performanse kada nastanu. Ovakvo okruženje može biti frustrirajuće za ABP, koji bi rađe podesio preventivno održavanje za SUBP okruženje. Međutim, to zahteva sredstva, vreme i napor – sve čega nikad nema dovoljno u skromnim IT organizacijama. Zato ABP mora nekad da se pomiri sa stvarnošću i rešava probleme kad nastanu – iako zna da postoji bolji način za upravljanje performansom.

6.5. Performansa sistema

Sistem loših performansi može narušiti performanse svih BP i aplikacija pokrenutih u tom sistemu. U tom slučaju nikakvo podešavanje BP, aplikacija ili SQL koda ne može poboljšati performansu. Na slici 6-4. je prikazan odnos aplikacije, BP i sistema: aplikacija pristupa BP, a oboje su implementirani u datom sistemskom okruženju. Iz tih razloga sistemski problem može izazvati loše performanse svih BP i aplikacija, kao što i problem BP može izazvati loše performanse svih aplikacija koje pristupaju BP.

Sistem

Baza podataka

Aplikacija

11

Slika 6-4. Oblasti podešavanja

Sistem obuhvata hardver i softver potreban za funkcionisanje SUBP-a i za pristup aplikacije bazi preko SUBP-a. Zato je neophodno da ABP razume sistem i operativno okruženje gde će BP biti pokrenuta. ABP mora imati sposobnosti da podrži promene bilo koje komponente sistema zarad podešavanja okruženja BP. Naravno, ne može se očekivati od ABP da bude stručnjak za svaki deo sistema i zato mora sarađivati sa drugim timovima u organizaciji kako bi pokrenuo sistemske promene. U nastavku su predstavljene taktike podešavanja i performanse sistema.

Šire okruženje

SUBP funkcioniše u okviru puno šireg okruženja koje obuhvata mnoge hardverske i softverske komponente. Da bi SUBP funkcionisao kako treba, svaka od ovih komponenti mora da se instalira, konfiguriše i da se njome efektivno upravlja. ABP mora razumeti interakciju SUBP-a sa hardverom servera, operativnim sistemom i bilo kojim drugim neophodnim softverom. Odgovarajuće podešavanje i konfigurisanje tih komponenti može značajno uticati na performanse sistema.

Interakcija sa operativnim sistemom

Kada se javi problem performanse operativnog sistema, svaki softver koji je pokrenut u tom operativnom sistemu može imati problem sa performansom. Da bi obezbedio optimalni operativni sistem za aplikacije BP, ABP treba da postavi sledeća pitanja:

• Da li je dodeljeno dovoljno memorije za obavljanje aktivnosti operativnog sistema (OS)? • Većina operativnih sistema može da odvoji određeni deo prostora na disku kao područje

zamene (swap area). To područje se koristi ako OS nestane memorije. Da li je deo diska određen kao područje zamene dovoljan?

• Kako su raspoređeni fajlovi BP kada je implementirana BP? Interakcija sa sistemom za upravljanje fajlovima može izazvati kod nekih OS dodatne troškove, što se može eliminisati izmenom fajlova BP tako da koriste deo diska na kom nema OS niti sistema za upravljanje fajlova.

• Neki OS omogućavaju da ABP odredi prioritete za sve aktivnosti koje se obavljaju pod tim OS. Da li je svakoj aktivnosti vezanoj za BP određen nivo prioriteta i da li je taj nivo prioriteta odgovarajući za datu aktivnost?

• Da li je instalirana verzija i izdanje OS koju je preporučio prodavac SUBP-a? Da li su nabavljeni bilo kakvi dodaci za OS koji se mogu primeniti za specifičnu marku servera BP koja se koristi?

• Da li su izmenjeni parametri konfiguracije OS pri instalaciji SUBP-a? Ako jesu, da li je dovoljno testirana izmena parametara kako bi se utvrdilo da ne utiču ni na jedan drugi proces na serveru BP?

Agenti usklađivanja

SUBP mora da se uskladi sa mnogim drugim softverskim komponentama kako bi

obezbedio usluge krajnjim korisnicima.

Primeri softverskih agenata za usklađivanje uključuju: • Transkcione procesore, kao što su CICS i Microsoft Transaction Server • Mrežni softver, kao što je TCP/IP i SNA • Message queueing softver, kao što je MQSeries i MSMQ • Softver za mrežno povezivanje i razvoj, kao što je ColdFuzion • Programski jezici, kao Java, COBOL i C.

12

Svaki od ovih agenata za usklađivanje mora adekvatno da se konfiguriše za interakciju sa SUBP i odgovornost je na ABP da razume zahteve za postavljanje. U većim preduzećima ABP neće sam konfigurisati agente, već će to prepustiti stručnjacima za upravljanje softverom, ali u manjim preduzećima će ABP morati sam da konfiguriše sav softver.

Konfiguracija hardvera

Za rad SUBP-a neophodan je kompjuterski hardver. Bilo da je u pitanju veliki mainfraime računar, srednji računar pod Unix sistemom ili PC pod Windows sistemom, hardver mora biti podesno instaliran i podešen da bi SUBP efikasno funkcionisao.

Navedena su neka od pitanja koje ABP treba da postavi da bi obezbedio optimalno hardeversko okruženje za aplikaciju BP.

• Da li je kompjuterski hardver i kapacitet odgovarajući za SUBP okruženje? Drugim rečima, da li prodavac SUBP-a preporučuje implementaciju na ovaj hardver?

• Da li je kompjuterski firmware (npr. ROM BIOS) ažuran? • Da li postoji dovoljno memorije za instaliranje svog sistemskog softvera (OS, SUBP i

drugih agenata usklađivanja)? • a li je dovoljno mesta na disku ostavljeno i konfigurisano za SUBP? • Koja vrsta memorijskog diska se koristi i da li je podesna za velike količine podataka i

brze upite u BP? • Da li su svi mrežni kablovi povezani i funkcionišu? • Da li su sve fizičke veze (npr. kablovi, priključci) uspostavljene i funkcionišu? • Da li je hardver povezan na neprekidni izvor energije? • Da li je hardver povezan na uređaj za zaštitu od strujnog udara?

Eksterne memorije i I/O

Jedno od najvećih uskih grla performanse BP je fizički trošak obavljanja I/O operacija (unosa podataka/prikaza rezultata obrade). Podaci se nalaze na disku, a disk je mehanička sprava. Ta sprava sadrži mašinske delove, koji se kreću i čitaju kodirane podatke sa ploče koja se vrti. Ove aktivnosti traju određeno vreme i sve što može skratiti to vreme može unaprediti performansu.

Način na koji se može optimizovati pristup disku je upotreba solid state memorijskih

uređaja (SSD).

Solid state uređaj je ustvari kompjuterska memorija koja je konfigurisana da radi kao hard disk. Kada se podaci učitaju sa SSD-a ne postoji fizička komponenta I/O operacija – podaci se nalaze u memoriji i prebacuju se iz memorije u SUBP, a zatim tamo gde su traženi.

Objekte BP sa zahtevima za visokom performansom bi trebalo smeštati na SSD umesto na fizičke hard diskove, RAID uređaje ili mreže skladišta podataka.

Ipak, upotreba SSD-a ima neke moguće probleme. Prvi su troškovi. Tek od skora su početni troškovi SSD-a opali. Drugi je postojanost. Neki SSD zahtevaju stalni izvor energije da bi se sprečilo brisanje podataka. U takvim slučajevima treba pripremiti planove kopiranja i povrata podataka za objekte BP.

Komponente SUBP-a

SUBP je veoma složen sistem koji zahteva stotine, pa i hiljade redova računarskog koda. Toliko je složen da je neophodno više programa da bi se postigla zahtevana funkcionalnost upravljanja podacima; svaki program sarađuje sa ostalima u kreiranju sistema za upravljanje podacima.

13

Svaki SUBP prodavac deli funkcije SUBP-a na različite komponente. ABP mora proučiti sastav SUBP-a i poznavati svaku komponentu i kako se ona integriše sa drugim komponentama SUBP-a.

ABP mora postati stručnjak za funkcionisanje SUBP-a da bi obezbedio optimizovano okruženje za aplikacije BP. Nedostatak ili problem sa bilo kojom komponentom SUBP-a može biti uzrok značajnog opadanja performanse svake aplikacije koja pristupa BP.

Problemi SUBP instalacije i konfiguracije

Svaki sistem upravljanja BP obezbeđuje parametre kojima ABP konfiguriše razne aspekte okruženja BP i utiče na način na koji SUBP funkcioniše. Konfiguracija se vrši na više načina, u zavisnosti od SUBP-a. Neke od popularnih metoda konfiguracije su izvršavanje sistemskih procedura za podešavanje i resetovanje vrednosti, izmena fajlova sa vrednostima parametara, izdavanje komande SUBP promptu i definisanje specifikacija parametara preko opcije u okviru SUBP-a.

Većina SUBP-a stiže od prodavca sa default vrednostima. Ipak, one najčešće nisu dovoljne da podrže razvoj robustnih aplikacija. U nastavku su opisani neki od uobičajenih parametara konfiguracije i kako ih treba podesiti.

Default vrednosti najčešće nisu dovoljne da podrže razvoj robustnih aplikacija.

Vrste konfiguracija

SUBP se može konfigurisati pri instaliranju ili pošto se pusti u rad. Tokom instalacije, ABP ili sistem administrator mogu promeniti parametre konfiguracije ili ih ostaviti na default vrednostima. Default vrednosti su skoro uvek neodgovarajuće i bolje je podesiti parametre na osnovu poznavanja podataka i aplikacija koje će koristiti SUBP.

Kad je SUBP instaliran i pušten u rad, sam SUBP omogućuje promenu parametara konfiguracije.

U zavisnosti od SUBP-a, parametri se mogu menjati dinamički, nedinamički ili na oba načina.

Dinamički parametri se menjaju odmah, bez potrebe da se restartuje SQL server. Izvršavanje naredbe RECONFIGURE rezultuje trenutnom promenom vrednosti parametara, a u skladu sa tim se menja i funkcionisanje SUBP-a. Za nedinamičke parametre, da bi promena vrednosti bila primenjena neophodno je restartovati SUBP.

Upotreba memorije

Relacione BP obožavaju memoriju.

Najveći zadatak podešavanja performanse sistema sa kojim će se suočiti ABP je konfigurisanje upotrebe memorije od strane RSUBP-a. SUBP koristi RAM da privremeno smesti podatke i druge resurse koji su mu neophodni, jer su puno niži troškovi učitavanja podataka iz memorije nego sa diska. Može se zaključiti da što je više memorije obezbeđeno SUBP-u to je njegova performansa bolja. Naravno, SUBP mora pri tom biti odgovarajuće konfigurisan da efikasno koristi memoriju.

SUBP čuva u memoriji stranice podataka, planove upita i druge resurse BP. Tipični SUBP će koristiti cache da duže čuva resurse u memoriji, jer što su oni duže u cache memoriji, to je veća verovatnoća da dodatni zahtevi za resursima neće izazvati troškove skupih I/O operacija, kao što je prikazano na slici 6-5.

14

Slika 6-5. Vrednost čuvanja resursa u cache memoriji

SUBP koristi veći broj cache ili buffer memorija za smanjenje I/O troškova. Svaki SUBP koristi drugu terminologiju, ali generalno čuva iste resurse u cache memoriji.

Data cache se koristi da se izbegnu I/O opreacije kad se konkretni podaci uzimaju iz BP.

Tada se svim podacima iz relacione BP pristupa preko cache memorije (slika 6-6). Pristup memoriji se najčešće meri u mikrosekundama, a pristup disku I/O u milisekundama. Kada programu treba red iz tabele, SUBP uzima stranicu sa diska i pohranjuje je u data cache. Ako se red promeni, promena se unosi na stranicu u data cache-u. Na kraju će SUBP uneti stranicu iz data cache-a na disk, ali ako neka aplikacija traži podatke sa stranice koja je već u data cache, neće morati da čeka da se stranica učita sa diska. U zavisnosti od SUBP-a ova memorijska struktura se može zvati i buffer pool.

Slika 6-6. Data cache (ili buffer pool)

Cache za procedure se koristi za pohranjivanje SQL i programskih struktura. Pre nego što se izvrši SQL komanda za uzimanje ili promenu podataka, SUBP je mora optimizovati. Proces optimizacije kreira internu strukturu koja predstavlja putanju pristupa koju će koristiti SUBP da pročita podatke. SUBP može skladištiti ove putanje pristupa u cache-u za procedure i ponovo ih koristiti svaki put kad se program ili SQL komanda pokrenu. Time se optimizuje performansa

Treba mi “A“

Treba mi “A“ opet

“A“ “A“

“A“ “A“

Memorija

DBMS

DBMS

Naslovi, izd.

Naslovi

Izdavači

Naslovi, izd. PODACI

15

aplikacije, jer ne mora svaki put da se vrši optimizacija SQL komande. Svaki SUBP ima sličnu sposobnost, samo pod drugim imenom i sa drugim karakteristikama.

Još jedna memorijska struktura koju često koristi SUBP je cache za sortiranje.

Cache za sortiranje se koristi umesto privremenog smeštanja na disk, za smeštanje

međurezultata sortiranja u memoriju.

Što se veći deo operacije sortiranja može obaviti u memoriji to će performanse sortiranja biti bolje. Mnoge operacije sa relacionim BP zahtevaju sortiranje, npr. grupisanje, ordering operacije, UNION operacije i neke vrste join operacija.

SUBP može koristiti i druge tipove cache-a interne strukture. Implementacija svakog SUBP-a je jedinstvena. Da bi se izvršile relacione operacije, SUBP će možda morati da kreira interne strukture koje ne moraju biti vidljive krajnjem korisniku, ali ABP i programeri moraju znati za njih. Primer je interna DBD (database descriptor) struktura koju koristi DB2 za upravljanje BP. DBD nikad nije vidljiv korisnicima, ali svaki put kad neka aplikacija pristupi bilo kom objektu u BP DB2 mora učitati DBD u deo memorije pod nazivom EDM pool. DB2 koristi EDM pool kao cache za dinamičke SQL putanje pristupa i druge interne strukture. ABP za DB2 mora dodeliti dovoljno memorije za EDM pool i pratiti efekte promene zahteva obrade i šema upotrebe na efikasnost EDM pool-a.

SUBP može smeštati log zapise u buffer skladištenjem u posebni log cache baze podataka.

Šta više, može koristiti dva log cache-a, jedan za pisanje log-a, drugi za čitanje. Log baze podataka čuva zapis o svim izmenama BP. Log za pisanje se koristi da se ubrzaju izmene BP. Izmenjeni podaci se unose u log cache i vremenom se asinhrono upisuju na disk, čime log BP postaje manje usko grlo performanse aplikacije i sistema. Log cache za čitanje se koristi za operacije ROOLBACK i RECOVER. Za roolback i recovery je neophodno pristupiti log-u da bi se poništile ili ponovo primenile promene BP, a one se već nalaze u log cache-u za čitanje. Dodatna područja upotrebe memorije

Osim različitih cache i buffer pool memorija koje se koriste u relacionim BP, memorija je potrebna i za druge namene. Uopšteno, SUBP instalacione i konfiguracione rutine omogućavaju administratoru da dodeli i podesi SUBP upotrebu memorije. Neke od češćih oblasti SUBP upotrebe memorije su:

• Konekcija sa korisnikom. Upravljanje i održavanje svake istovremene konekcije sa SUBP-om zahteva memoriju.

• Uređaji. Upravljanje i održavanje uređaja koje koristi BP zahteva sistemsku memoriju. • Otvorena BP. Većina SUBP-a ima određeni broj BP koje mogu biti otvorene u istom

trenutku, a svaka zahteva memoriju. • Otvoreni objekti. I objekata koje koristi BP (tabela, indeksa) i mogu biti otvoreni

istovremeno ima ograničen broj, a svaki zahteva memoriju. • Zaključavanje. Svako tekuće zaključavanje zahteva memoriju i njih može biti ograničen

broj istovremeno. • Cache memorija.

Koliko memorije je dovoljno?

ABP mora dodeliti odgovarajuću veličinu memorije na odgovarajuće mesto.

Svaki SUBP koristi memoriju, ali različite veličine i za različite namene.

16

Najbolje je iz priručnika SUBP prodavca utvrditi koliko memorije zahteva svaki od resursa SUBP-a i na osnovu toga proceniti ukupnu neophodnu memoriju. Na primer, SQL server zahteva 75 bajta memorije po zaključavanju. Za određivanje ukupne memorije potrebne za zaključavanja, treba utvrditi ukupan broj paralelnih transakcija i broj zaključavanja po transakciji:

Uk. memorija za paralelna zaključavanja = (# paralelnih transakcija) x (# zaključavanja po transakciji) x 75

Broj paralelnih transakcija nije uvek lako odrediti, pa se može umesto toga uzeti SUBP konfiguraciona vrednost za ukupan broj korisničkih konekcija. Ako se ne zna tačan broj zaključavanja po transakciji, treba izvršiti procenu na osnovu nekoliko tipičnih programa. Isto se može uraditi za svaki resurs BP koji zahteva memoriju i time doći do ukupne veličine memorije koja treba da se instalira za server BP. Dobro je ostaviti malo više memorije za slučaj dodatnih nepredviđenih aplikativnih programa, unapređenja SUBP-a i operativnog sistema koji zahtevaju dodatnu memoriju i drugih nepredviđenih zahteva, ali ne suviše. Detalji data cache-a

U bilo kom trenutku data cache se sastoji od tri različita tipa stranica: • stranice u uporebi – trenutno ih čita i ažurira SUBP i nisu raspoložive za drugi vid

obrade • ažurirane stranice – podaci na njima su nekako izmenjeni, ali još nisu upisani na disk i

nisu raspoložive za drugi vid obrade

• raspoložive stranice – nisu trenutno u upotrebi i raspoložive su za drugi vid obrade, na njima mogu biti upisani novi podaci u data cache-u.

Performansa data cache-a zavisi od toga koliko efikasno je raspoređena memorija za njegovu upotrebu. Ako data cache-om dominiraju neraspoložive stranice, SUBP može pokrenuti sinhrono upisivanje da bi povećao prostor u data cache-u, što može usporiti obradu u BP, jer svaki zahtev za upisom mora čekati da podaci budu fizički upisani na disk. Praćenje i podešavanje data cache-a

Za efikasni data cache najbitnije je da bude odgovarajuće veličine.

Ako je suviše velik, rasipa memoriju i može dovesti do toga da se stranice iz cache-a premeštaju u drugo pomoćno skladište. Ako je suviše mali, uzrokuje često upisivanje podataka na disk i, u najgorem slučaju, stalno premeštanje stranica koje su u data cache-u na disk i uzimanje sa diska.

Složenost podešavanja data cache-a zavisi od SUBP-a i raspoloživih parametara konfiguracije i podešavanja. DB2 obezbeđuje veći broj buffer pool-a koji se mogu konfigurisati i podesiti nezavisno, sa više parametara. SQL server je jednostavniji i ima jedan data cache po bazi podataka. U svakom slučaju, ABP bi trebao da prati efikasnost čitanja (read efficiency) svakog data cache-a ili buffer pool-a.

Efikasnost čitanja data cache-a je procenat koji pokazuje koliko dobro cache obavlja svoj primarni zadatak – izbegavanje fizičkih I/O operacija na disku. Izračunava se kao razlika ukupnog broja zahteva za podacima i broja fizičkih I/O operacija , u odnosu na ukupan broj zahteva za podacima:

Efikasnost čitanja = [(broj I/O zahteva BP) – (broj fizičkih I/O)] / (broj I/O zahteva BP)

17

Drugim rečima, pokazuje procenat slučajeva kada se stranica podataka može naći u data cache-u (ili buffer pool-u) i ne zahteva fizičku operaciju I/O. Što je taj procenat viši, veća je efikasnost, a tim je bolja i performansa.

Stvarni broj zahteva za podacima i I/O fizičkih operacija se može naći pregledanjem SUBP zapisa ili upotrebom monitora performanse BP.

Po pravilu, 80% ili veća efikasnost data cache-a je dobra.

Naravno, efikasnost čitanja će zavisiti od tipa obrade, pa i to treba uzeti u obzir pri merenju. Mnoge sekvencijalne obrade će izazvati prepisivanje podataka u data cache-u i pad efikasnosti. Takođe, sistemi sa puno procesa koji pristupaju podacima samo jednom nedeljno ili mesečno imaju nižu efikasnost čitanja jer se manje podataka ponovo koristi.

Ako je efikasnost čitanja stalno ispod 80%, trebalo bi izvršiti podešavanje povećanjem data cache-a ili smanjenjem broja tabela i indeksa dodeljenih data cache-u. To može uticati na raspoloživost, jer se SUBP mora restartovati da bi promene bile prihvaćene. U zavisnosti od SUBP-a ABP može bolje konfigurisati data cache promenom veličine cache-a rezervisanog za sekvencijalne i paralelne operacije.

Skeniranje velikih tabela može brzo monopolizovati data cache.

Rezervisanjem samo dela cache-a za sekvencijalna skeniranja poboljšava se ukupna performansa data cache-a.

Dodatne mogućnosti za podešavanje data cache-a uključuju kreiranje dodatnog cache-a za kopiranje data cache-a, označavanje određenih stranica u memoriji i automatsko povećanje data cache-a sa povećanjem protoka.

Praćenje i podešavanje cache-a za procedure

ABP mora pratiti efektivnost cache-a za procedure kako bi poboljšao efikasnost aplikacija BP i upita. Iako se cache za procedure razlikuje od SUBP-a do SUBP-a, smisao je isti: zadržati optimizovane SQL strukture u memoriji, da bi ih mogle iskoristiti i naredne operacije, i time izbeći ponovnu reformulaciju ili čitanje sa diska.

Da bi se obezbedila optimalna performansa, cache za procedure mora biti odgovarajuće veličine da stanu sve SQL procedure koje se mogu izvršavati paralelno. Za to su neophodne informacije o aplikativnim programima koji će biti pokrenuti. Efikasnost čitanja se može definisati i za cache za procedure i ona pokazuje koliko često SUBP mora ponovo da optimizuje SQL kod. Najčešće se kreće od 60% do 80%, što zavisi i od tipa SUBP-a, aplikacija i koliko često se pokreću iste SQL procedure i programi. „Otvoreni“ objekti baze podataka

Za rad aplikacija sa bazom podataka SUBP mora otvoriti objekte BP i održavati ih otvorenim. Koliko takvih objekata može biti otvoreno istovremeno podešava se konfigurisanjem SUBP-a. Ovaj broj je teško tačno odrediti na početku, ali tokom vremena se može bolje definisati praćenjem sistema BP. Najčešće se počinje sa brojem koji je jednak broju svih baza podataka i njihovih objekata, ali svaki otvoreni objekat BP zauzima memoriju. Zato je dobro ograničiti broj otvorenih objekata, uzimajući u obzir veličinu implementacije BP, tip aplikativne obrade i raspoloživu memoriju. Logovi BP

Log BP je još jedan elemenat konfiguracije sistema BP koji može uticati na performansu. Log BP, koji se naziva i transakcioni log, je osnovna komponenta SUBP-a.

18

Sve izmene podataka koje aplikacija koristi u BP se serijski beleže u log-u BP.

Slika 6-7. Beleženje transakcija u log BP

Na osnovu log-a SUBP prati koja je transakcija napravila koje izmene u BP, a operacije ROLLBACK i RECOVER koriste log za vraćanje BP na stanje u kom je bila u određenom trenutku.

Tokom uobičajene obrade podataka SQL operacijama INSERT, UPDATE I DELETE stalno se menjaju podaci u BP. Pošto se svaka promena beleži u log-u, i transakcioni log BP se stalno uvećava, pa ABP mora pratiti veličinu transakcionog log-a.

Transakcioni log je write-ahead log.

To znači da se izmene unose u transakcioni log pre neg što se izvrše nad podacima u BP. Ako se izmene BP u potpunosti zabeleže u log-u, mgućnost ispravke transakcije je zagarantovana.

Najčešće se u log BP beleže sledeće informacije: • vreme početka i završetka svake transakcije • konkretne izmene podataka i dovoljno informacija (uz upotrebu snimka podataka „pre“ i

„posle“) za ispravku promena izvršenih tokom svake transakcije • alokacija i dealokacija stranica BP • konkretne operacije COMMIT i ROLLBACK za svaku transakciju

Na osnovu ovih informacija SUBP može ostvariti integritet i konzistentnost podataka. Transakcioni log se koristi i kad se SUBP restartuje, kad se izvrši rollback nad transakcijom i da bi se vratila BP u pređašnje stanje.

Elementi konfiguracije log-a BP

Konfigurisanje transakcionog log-a obuhvata definisanje input buffer-a i output buffer-a, podešavanje log offloading-a i definisanje konkretnih log fajlova.

Definisanje output buffer-a za log BP optimizuje operacije unosa log zapisa i omogućuje efikasniju obradu podataka jer se log zapisi unose u memoriju umesto direktno na disk, a kasnije ih SUBP može asinhrono uneti iz output buffer-a u fizički log fajl.

Definisanje input buffer-a optimizuje operacije koje čitaju log BP, kao što su ROLLBACK i RECOVER.

Smešteno u cache

Smešteno u cache

PODACI

UNOS

UNOS

AŽURIRANJE

AŽURIRANJE

BRISANJE

BRISANJE

19

Kod konfigurisanja log-a BP dobro je podesiti dvostruke log-ove. Tada se promene zapisuju u dva odvojena i nezavisna log fajla, što je veoma korisno ako se jedan od log fajlova ošteti. Kod dvostrukih log fajlova svaki mora biti na posebnom uređaju i sa posebnim kontrolerima da se minimizuje mogućnost oštećenja oba fajla istovremeno.

Kada se popune log fajlovi, neophodno je izvršiti log offloading, proces arhiviranja aktivnog log fajla u arhivski log i unošenje log zapisa u novi aktivni log. Ako SUBP izvršava automatski log offloading, performansa će biti bolja ako se arhiviranje obavlja na disku, a ne na magnetnoj traci, jer su brže I/O operacije i nema čekanja na postavljanje trake. ABP može preko sistema za upravljanje skladištenjem da podesi automatsko premeštanje log arhiva na traku nakon nekog vremena.

Neki SUBP zahtevaju kreiranje backup kopije transakcionog log-a BP i ABP mora znati kako se ova operacija obavlja u SUBP-u koji koristi. Na primer, DB2 automatski arhivira transakcioni log, a Microsoft SQL Server zahteva da administrator kreira backup kopiju.

Da li se zapisuju sve operacije BP?

U zavisnosti od SUBP-a neke situacije i komande se ne zapisuju, a da bi se izbegla situacija "nedostatka prostora" izazvana brzim rastom transakcionih log fajlova SUBP može isključiti zapisivanje u log. Na primer, neke DDL operacije i aktivnosti održavanja BP ne moraju biti zabeležene. Treba ovakve situacije imati u vidu pri kreiranju plana za vraćanje podataka.

U toku nekih velikih operacija, kao što je CREATE INDEX, SUBP verovatno neće zabeležiti svaku novu stranicu. Dodatno, neki SUBP pruža opciju konfiguracije na nivou BP kojom se za neke tipove obrade isključuje zapisivanje u log fajl, jer izazivaju promene velike količine podataka u BP i zapisivanje u log može usporiti ove procese. U tom slučaju neophodno je napraviti backup kopiju podataka i pre i posle procesa koji se ne beleži u log, da bi bilo moguće povratiti podatke. Zaključavanje i nadmetanje

Paralelne operacije kao što su otkrivanje deadlock-a i podešavanja menadžera zaključavanja mogu značajno uticati na performansu BP. Obrada podataka u BP se oslanja na zaključavanje da bi se održala konzistentnosti podataka na osnovu zahteva korisnika i da bi se izbegao gubitak podataka tokom ažuriranja. Treba uskladiti potrebu za istovremenim izvođenjem sa potrebom za visokom performansom minimiziranjem javljanja sledećih situacija:

• Suspenzije zaključavanja se dešavaju kad neki proces zahteva zaključavanje resursa koje već drži drugi proces i koji se ne mogu deliti. Suspendovani proces privremeno prestaje sa radom dok traženo zaključavanje ne postane dostupno.

• Tajmauti se dešavaju kada se proces završi, jer je suspendovan duže od predefinisanog vremena.

• Deadlocks se dešavaju kad dva ili više procesa drže zaključane resurse koji trebaju drugima i bez kojih ne mogu da nastave.

Sistemski katalog

Fizička lokacija i postavljanje sistemskog kataloga će imati uticaj na performansu sistema. ABP mora, obično u tenutku instalacije sistemskog kataloga, odlučiti gde će biti instaliran, na kojoj vrsti diska, i koliko prostora će mu biti dodeljeno.

Sistemski katalog treba smestiti na zaseban disk.

Ovo je preporučljivo kako bi se moglo njime upravljati i podešavati nezavisno od drugih podataka. Ako je moguće, potpuno posvetiti ceo disk ili dva sistemskom katalogu i smestiti

20

indekse i tabele na zasebne diskove. Ako SUBP ne obezbeđuje poseban data cache za sistemski katalog, trebalo bi izolovati sistemski katalog u sopstveni data cache, za lakše praćenje efikasnosti I/O sistema u odnosu na I/O aplikacija.

Kad treba da se izmeni BP sistemskog kataloga koriste se alati kao što su REORG, COPY i RECOVER ili komande fajl sistema. Promene mogu biti povećanje veličine sistemskog kataloga, dodavanje novih indeksa ili premeštanje u novu verziju SUBP-a.

ABP bi trebao da koristi sistemski katalog za aktivno upravljanje okruženjem BP. Potrebno je aktivno pratiti objekte BP u sistemskom katalogu i izbrisati nepotrebne objekte. Svi objekti koji se više ne koriste zauzimaju vredne resurse, koji se mogu osloboditi njihovim uklanjanjem. Ostale opcije konfiguracije

Svaki SUBP ima neke specifične opcije konfiguracije i podešavanja. ABP mora postati stručnjak za te opcije i znati uticaj svake mogućnosti podešavanja. Neki primeri opcija konfiguracije koji se mogu sresti su:

• Nested trigger calls. Neki SUBP imaju opciju za omogućavanje i onemogućavanje nested trigger calls-a – kad jedan triger izaziva okidanje drugog trigera – ili za podešavanje maksimalnog broja nivoa ugneždenih trigera.

• Sigurnosne opcije. Opcije konfiguracije SUBP-a mogu kontrolisati sigurnost i autorizaciju ili njihovu kontrolu mogu prepustiti eksternom softveru za sigurnost i kontrolu.

• Vrednosti identiteta. Koloni se može dodeliti takva osobina identiteta da SUBP automatski dodeljuje numeričke sekvencijalne vrednosti kada se podaci unose u tabelu. SUBP može omogućiti konfiguraciju veličine skupa iz kojeg se vrednosti identiteta uzimaju.

• Distribuirane BP. SUBP obezbeđuje opcije za povezivanje BP na različitim lokacijama. Uopšteni saveti

Pri konfigurisanju okruženja BP treba izbegavati default vrednosti, jer one najčešće ne odgovaraju konkretnom okruženju. Zato je uvek dobro podesiti vrednost svakog parametra konfiguracije iako je default vrednost ona koju želite izabrati.

Treba obratiti pažnju i na opcije konfiguracije koje menjaju funkcionisanje SUBP-a, jer pogrešno podešavanje samo jednog parametra konfiguracije može izazvati puno štete.

Praćenje sistema

SUBP okruženje bi trebalo neprekidno pratiti, da bi se uočili problemi i opadanje performanse. Neki SUBP imaju ugrađene monitore kojima se obavlja osnovno posmatranje. Za napredno praćenje, kao što je dinamičko upozoravanje i proaktivno upravljanje problemima performanse, mogu se instalirati dodatni monitori performanse, kao što su BMC Software PATROL ili Omegamon Candle korporacije.

Monitori performanse su raspoloživi za svaki aspekt sistemskog okruženja, ne samo za SUBP, već i za operativni sistem, mrežu, transakcioni server i bilo koji drugi sistemski middleware. ABP mora znati da koristi i razume rezultat sredstava za praćenje performanse koji su mu na raspolaganju. Monitor performanse je prozor u efikasnost sistema BP (ili nedostatak iste).

6.6. Performansa baze podataka

Performansa BP se fokusira na podešavanje i optimizovanje dizajna, parametara i fizičke konstrukcije objekata BP, posebno tabela i indeksa i fajlova u kojima su podaci smešteni.

21

Konkretni sastav i struktura objekata BP se moraju neprekidno pratiti i menjati ako BP postane neefikasna.

Nikakvo podešavanje SQL koda i sistema ne može optimizovati performansu upita koji se

izvršavaju nad loše dizajniranom ili neorganizovanom BP.

Tehnike za optimizaciju BP

ABP mora poznavati mogućnosti SUBP-a da bi primenio odgovarajuće tehnike optimizacije performanse struktura BP. Većina SUBP-a podržava sledeće tehnike, iako možda pod drugim imenima:

• Particionisanje – deljenje jedne tabele BP na delove pohranjene u više fajlova. • Grubo particionisanje u odnosu na sistem fajlova – izbor da li skladištiti BP u fajl pod

kontrolom OS ili ne. • Indeksiranje – izbor odgovarajućih indeksa i opcija kako bi se obezbedili efikasni upiti. • Denormalizacija – odstupanje od logičkog dizajna zarad postizanja bolje performanse

upita. • Klasterizacija – nametanje fizičke sekvence podataka na disku. • Interleaving podataka - kombinovanje podataka iz više tabela u jedan sekvencijalni fajl. • Slobodan prostor – ostavljanje mesta za uvećanje podataka. • Kompresija – smanjivanje zahtevane veličine memorije za skladištenje pomoću

algoritama. • Smeštanje i alokacija fajlova – smeštanje pravih fajlova na pravo mesto. • Veličina stranice – upotreba odgovarajuće veličine stranice za efikasno skladištenje

podataka i I/O. • Reorganizacija – uklanjanje neefikasnosti iz BP ponovnim podešavanjem i

restruktuiranjem objekata BP. Particionisanje

Tabela BP je logička manifestacija seta podataka koja je fizički pozicionirana na kompjuterizovanom memorijskom skladištu. Svaki SUBP pruža različite mehanizme za skladištenje tih podataka – mapiranje fizičkih fajlova u tabele BP, a ABP mora odlučiti koji od metoda mapiranja će se koristiti za svaku od tabela:

• Jedna tabela u jedan fajl. Najčešći izbor. Podaci u fajlu su formatirani tako da SUBP razume strukturu tabele i svaki red unet u tabelu se smešta u isti fajl, što ne mora uvek biti najefikasnije.

• Jedna tabela u više fajlova. Najčešće se koristi za veoma velike tabele ili za tabele koje zahtevaju fizičko odvajanje podataka na nivou skladištenja. Mapiranje u više fajlova se postiže upotrebom particioniranog prostora za tabele ili segmentiranog diska.

• Više tabela u isti fajl. Koristi se za male tabele kao što su lookup tabele i tabele kodova i može biti efikasnije sa stanovišta upotrebe prostora na disku.

Velika tabela se može particionisati na više particija na osnovu bilo koje kolone. Izabrana kolona je particioni ključ i preporučljivo je da ta kolona sadrži podatke koji se ne menjaju, kao što je npr. vreme kupovine. Particionisanje se može vršiti na više načina:

• na osnovu intervala vrednosti podataka (range partitioning) • na osnovu hash funkcije (hash partitioning) • upotrebom diskretnih vrednosti (list partitioning) • upotrebom kombinacije nekoliko metoda (composite partitioning)

Particionisanje omogućava paralelizam, proces upotrebe više aktivnosti za paralelno (istovremeno) pristupanje BP. Paralelnim zahtevom se poziva više simultanih mehanizama za

22

čitanje jednog SQL iskaza i poželjan je, jer može značajno smanjiti proteklo vreme za upite u BP. Zasniva se na resursima koji se mogu istovremeno koristiti. Na primer, jedan upit se može razbiti na više zahteva od kojih svaki koristi različit CPU istovremeno. Paralelizam se može dodatno poboljšati podelom posla na više instanci BP. Svaki ABP mora poznavati mogućnosti svog SUBP da bi optimalno iskoristio mogućnosti paralelnih upita. Grubo particionisanje u odnosu na sistem fajlova Za skladištenje podataka u SUBP okruženju baziranom na UNIX-u ABP mora izabrati između grubog particionisanja i upotrebe UNIX sistema za fajlove. Preporučljivo je grubo particionisanje, jer kod sistema fajlova operativni sistem smešta zapise u cache memoriju i SUBP ne zna da li su podaci fizički upisani na disk. Ako SUBP cache menadžer pokuša da ih upiše na disk, operativni sistem može odložiti upis jer se podaci još uvek nalaze u cache-u sistema fajlova. Ako dođe do oštećenja, podatke BP koja koristi sistem fajlova za smeštanje podataka možda neće biti moguće vratiti u potpunosti. Kod grubog particionisanja podaci se upisuju direktno iz cache-a BP na disk (slika 6-8), a SUBP obezbeđuje dovoljno slobodnog prostora i beleži stranice na kojima su podaci upisani.

Slika 6-8. Upotreba grubog particionisanja za izbegavanje smeštanje podataka u cache sistema fajova

Sa stanovišta performanse ne postoji prednost upotrebe sekundarnog sloja cache memorije na nivou sistema fajlova ili operativnog sistema, čak se troši više resursa za smeštanje podataka u cache po drugi put, što negativno utiče na ukupnu performansu operacija BP. Ne treba dopunjavati SUBP cache sa bilo kojim tipom dodatnog cache-a. Indeksiranje Kreiranje odgovarajućih indeksa nad tabelama BP je možda najbolja tehnika podešavanja performanse BP. Indeksima se poboljšava performansa. Posebno su korisni za:

• Pronalaženje redova po vrednosti(ma) u koloni(ma) • Povećanje efikasnosti spajanja (JOIN) – kada je indeks definisan nad spojenim

kolonama • Koleraciju podataka iz više tabela • Agregaciju podataka • Sortiranje podataka za neki upit

Bez indeksa svako pristupanje u bazi bi se moralo vršiti skeniranjem svih redova, što je veoma neefikasno za veoma velike tabele.

23

Dizajniranje i kreiranje indeksa je negde između podešavanja performanse BP i aplikacije. Indeksi su objekti BP koje kreira ABP sa DDL-om BP, ali su napravljeni da osiguraju brže izvršavanje SQL iskaza u programskim aplikacijama. Indeksiranje povećava efikasnost aplikacija kada se šeme pristupa aplikacije podacima BP razlikuju od planiranih pri dizajniranju BP. Pre podešavanja BP kreiranjem indeksa, ABP mora razumeti šeme pristupa datoj tabeli i uticaj dodavanja indeksa nad tom tabelom. Korisne su informacije o procentu upita koji pristupaju tabeli a ne ažuriraju je, o ugovorenim graničnim performansama upita nad tabelom i uticaju dodavanja novog indeksa nad BP u upotrebi, kao što je učitavanje, reorganizacija i povraćaj. ABP mora na osnovu svoje stručnosti za svaku tabelu utvrditi odgovarajući broj indeksa tako da se optimizuju upiti u BP a perforamansa unosa, ažuriranja i brisanja u BP ne opadne. Opšti cilj analize indeksa je upotreba manje I/O u BP za izvršavanje upita. Indeks može pomoći neke upite, a ometati druge, pa ABP mora oceniti uticaj dodavanja indeksa na sve aplikacije. S druge strane, indeks negativno utiče na performansu kada se podaci ažuriraju, pa se moraju promeniti i indeksi. Efektivna strategija indeksiranja teži da obezbedi najveće smanjenje I/O uz prihvatljiv nivo napora za održavanje indeksa ažurnim. Kreiranje indeksa za podršku samo jednog upita je prihvatljivo, ako taj upit ima dovoljno velik značaj za ROI preduzeća (ili ako ga zahteva šef ili direktor). Obavezno je detaljno testiranje performanse upita koje indeksi podržavaju. Treba pregledati vreme upotrebe CPU, vreme izvršenja i zahteve za I/O da bi se utvrdilo da li indeksi pomažu. Takođe treba izmeriti dodatne utroške resursa za ažuriranje novih indeksa. Kreiranje indeksa je iterativan posao i verovatno će biti neophodno nekoliko podešavanja indeksa, da bi se ostvario pomak u unapređenju performanse. Kada izbeći indeksiranje Indeksiranje nije preporučljivo kod veoma malih tabela, npr. manje od 10 strana, jer može biti manje efikasno nego jednostavno skeniranje svih redova, zbog dodathnih I/O zahteva za čitanje indeksa. Trebalo bi izbegavati indeksiranje kolona promenjive dužine, za slučaj da SUBP proširi promenljivu kolonu u okviru indeksa na maksimalu dužinu. Tada indeksi mogu zauzeti prevelik prostor na disku i postaju neefikasni. Ako se kolone promenljive dužine koriste u SQL WHERE klauzulama, treba uporediti troškove smeštanja na disk sa troškovima skeniranja, jer je najčešće jevtinije obezbediti dodatni prostor na disku, od rasipanja resursa CPU na skeniranje redova. Moguće je i da SQL upit sadrži alternativne predikate koji se mogu indeksirati umesto kolona promenljive dužine. Treba izbegavati indeksiranje bilo koje tabele kojoj se uvek pristupa skeniranjem. Overloading indeksa

24

Performansa upita se u nekim slučajevima može unaprediti overloading-om indeksa dodatnim kolonama. Indeksi se najčešće zasnivaju na WHERE klauzulama SQL SELECT iskaza. Kao primer se može uzeti sledeći SQL iskaz: select emp_no, last_name, salary from employee where salary > 15000.00 ; Kreiranje indeksa nad kolonom salary može poboljšati performansu ovog upita. ABP može i dodatno poboljšati performansu upita overloading-om indeksa kolonama emp_no i last_name. Tada se može zadovoljiti upit samo upotrebom indeksa i SUBP ne mora dodatno pristupati podacima u tabeli, jer se svaki zahtevani podatak već nalazi u overload-ovanom indeksu. Overloading indeksa bi trebalo podržavati kad više upita ima koristi od tog indeksa ili kada su pojedini upiti veoma značajni. Denormalizacija Još jedan način da se poboljša performansa pristupa BP je da se denormalizuju tabele. Denormalizacija, suprotno od normalizacije, je proces stavljanja jedne činjenice na više mesta, čime se ubrzava uzimanje podataka na račun izmene podataka. Preporučuje se kada potpuno normalizovani dizajn ne pruža optimalnu performansu. Jedini razlog da se denormalizuje relaciona BP je da se unapredi performansa. Neke od opcija su:

• Prejoined tabele – kada su troškovi spajanja ograničavajući. • Tabela izveštaja – kad je kreiranje specijalizovanih ključnih izveštaja suviše skupo. • Mirror tabela – kada su tabele istovremeno potrebne u dva tipa okruženja. • Podeljenje tabele – kad različite grupe koriste različite delove tabele. • Kombinovane tabele – za konsolidaciju odnosa jedan prema jedan ili jedan prema više

u jedinstvenu tabelu • Brza tabela – za podršku hierarhija, kao što su potrebni materijal i strukture izveštavanja • Fizička denormalizacija – da bi se iskoristile prednosti konkretnih SUBP karakteristika.

Može se uzeti u obzir i:

• skladištenje redundantnih podataka u tabele da bi se smanjio broj potrebnog spajanja tabela

• skladištenje grupa koje se ponavljaju u red da bi se smanjio broj I/O, a možda i prostor na disku

• skladištenje izračunatih podataka da bi se izbacili proračuni i skupi algoritmi. Klasterizacija Klasterizaciju najčešće vrši SUBP primenom klaster indeksa. Pri klasterizaciji se podaci u tabeli fizički ređaju u skladu sa formulacijom indeksa: redovi u tabeli se smeštaju rastućim redosledom, na osnovu indeksiranih kolona. Redosled kolona s leva na desno kako je definisan u indeksu, definiše redoslednu sekvencu klasterizacije. Može postojati samo jedna sekvenca klasterizacije tj. jedan klaster indeks po tabeli, jer podaci mogu fizički imati samo jedan redosled sortiranja. Slika 4-2. prikazuje razliku između klasterizovanih i neklasterizovanih podataka i indeksa. Kao što se vidi, unosi na stranice listova indeksa u gornjoj polovini slike su u sekvencijalnom redosledu tj. klasterizovani su.

25

Klasterizovana tabela će skladištiti redove fizički na disk po redosledu u određenoj koloni ili kolonama. Kod običnih indeksa se koriste odvojene strukture za smeštanje podataka i indeksa, tako da se podaci smeštaju u jednu strukturu, a jedan ili više indeksa u zasebnu strukturu sa pokazivačima ka odgovarajućem redu u tabeli podataka. U klasterizovanoj tabeli se podaci i indeksi smeštaju u istu strukturu. Prednost je što nije potreban dodatni korak čitanja podataka u tabeli kad se pronađe odgovarajuća vrednost indeksa, jer su podaci deo strukture indeksa. U MS SQL Server verziji 6.5 i novijim primenom klaster indeksa se redovi podataka smeštaju na stranice listova indeksa. Po definiciji klaster indeksa podaci se nalaze na nivou listova, a pošto se stranice nivoa listova uvek sortiraju, sortirani su i podaci klaster indeksa. Klasterizacija tabela kojima se pristupa sekvencijalno je preporučljiva. Klaster indeksi se koriste za kolone koje se često sortiraju ili pretražuju u intervalima, pošto se podaci grupišu prema indeksiranim kolonama i time se smanjuje broj pristupanja disku. U zavisnosti od SUBP-a postoji dva načina za održavanje sekvence klasterizacije podataka:

1. Pri ubacivanju novih redova, SUBP će fizički razmestiti redove i stranice podataka da bi novi redovi stali.

2. Ako pri ubacivanju novih redova ne postoji dovoljno mesta da se na određenoj stranici ubace u sekvenci klasterizacije, novi podaci će biti smašteni na drugo mesto. To može izazvati tokom vremena neklasterizovanost podataka i tada je neophodna reorganizacija.

Slika 6-9. Klaster i obični indeksi Posebnu pažnju treba obratiti kod izbora kolona klasterizacije. Klaster indekse treba koristiti u sledećim situacijama:

Klaster indeks

Običan indeks

Stranica korena stabla

Stranica lista indeksa

Stranica lista indeksa Stranica lista indeksa

Stranica lista indeksa

Stranica korena stabla

Stranica podataka Stranica podataka Stranica podataka

Stranica podataka Stranica podataka Stranica podataka

26

• kolone spajanja, da se optimizuje SQL spajanje ako se podudara više redova jedne ili obe tabele koje učestvuju u spajanju

• kolone stranih ključeva, jer često učestvuju u spajanju i SUBP pristupa vrednostima stranih ključeva tokom provere referencijalnog integriteta

• predikati u WHERE klauzuli • kolone intervala • kolone koje se ne menjaju često (fizički smanjuje ponovnu klasterizaciju) • kolone koje se često grupišu ili sortiraju u SQL iskazima

Klasterizacija se ne preporučuje za kolone primarnih ključeva jer je primarni ključ, po definiciji, jedinstven. Ipak, ako se određeni intervali redova često selektuju i ređaju po vrednostima primarnog ključa, klaster indeks može biti od koristi. Deljenje stranica Kada SUBP mora uneti nove podatke na stranice na kojima nema mesta vrši se deljenje stranica. Deljenje stranica je proces kreiranja novih stranica za smeštanje novih unetih podataka . SUBP može vršiti deljenje stranica na dva načina: normalno i monotono deljenje stranica. ABP mora znati kako SUBP obavlja deljenje da bi mogao optimizovati BP. Slika 6-10. prikazuje normalno deljenje stranica, koje obuhvata korake:

1. kreiranje nove prazne stranice između pune i sledeće stranice 2. prebacivanje pola unosa sa pune na praznu stranicu 3. prilagođavanje svih internih pokazivača na obe stranice i unošenje reda u skladu sa

pravilima

Slika 6-10. Normalno deljenje stranice Monotono deljenje je puno jednostavniji proces u kom SUBP kreira novu stranicu između pune i sledeće stranice i unese nove vrednosti na novu stranicu. Korisno je kada se redovi unose u strogo rastućem redosledu, a SUBP će ga upotrebiti kada se novi red dodaje na kraj stranice, pri čemu je poslednje dodavanje takođe bilo na kraj stranice. Ako se pri unosu novih redova u rastućem redosledu koristi normalno deljenje stranica, SUBP će kreirati polu-pune stranice koje se nikada neće popuniti i prostor će se trošiti uzalud. Interleaving podataka Kada se podaci iz dve tabele često spajaju, ima smisla uraditi fizički interleaving podataka u jednu fizičku strukturu za smeštanje. Može se posmatrati kao posebna vrsta klasterizacije (Oracle u stvari koristi termin cluster za definisanje interleavinga).

UNOS (nema mesta na stranici)

Puna stranica Deljenje stranice

Nova polupuna stranica

Nova polupuna stranica

27

Slobodan prostor Slobodan prostor, koji se nekad naziva i faktor popunjavanja, se može koristiti da se ostavi deo prostora u tabeli ili indeksu prazan i slobodan za smeštanje novounetih podataka. Ovo smanjuje potrebu za reorganizacijom, smanjuje nadmetanje i povećava efikasnost unošenja. Svaki SUBP obezbeđuje metod za određivanje slobodnog prostora za objekte BP u CREATE i ALTER iskazima. Standardni parametar je PCTFREE kojim ABP određuje procenat od svake stranice podataka koji treba da ostane slobodan za budući unos. Parametrom FREEPAGE ABP definiše broj stranica posle kog je raspoloživa potpuno prazna stranica. Prednosti koje se ostvaruju ako se osigura odgovarajuća veličina slobodnog prostora za svaki objekat BP:

• unošenje je brže • novi redovi koji se unose se mogu adekvatno klasterizovati • redovi promenljive dužine i promenjeni redovi imaju mesta da se prošire, i time

potencijalno smanjuju broj premeštenih redova • manje redova na stranici dovodi do bolje paralelne aktivnosti, jer je manje podataka

nedostupno drugim korisnicima kada je stranica zaključana Slobodni prostor ima i nekoliko nedostataka:

• potreban je veći prostor na disku • skeniranje duže traje • manje redova na stranici može zahtevati više I/O operacija da bi se pristupilo traženim

informacijama • sa smanjenjem broja redova po stranici može opasti i efikasnost smeštanja podataka u

data cache, jer se manje redova učita po I/O operaciji. Definisanje odgovarajuće količine slobodnog prostora za svaki objekat BP se mora zasnivati na:

• koliko često se vrše unosi i promene • odnosu sekvencijalnih i random pristupa • uticaju pristupa neklasterizovanim podacima • tipu obrade • verovatnoći ulančavanja redova, mitigacije redova i deljenja stranica

Ne treba definisati statičnu tabelu sa slobodnim prostorom – neće joj biti potreban prostor da se širi. Kompresija Kompresija se koristi za smanjivanje veličine BP kako bi zauzela manje prostora na disku. Neki SUBP pruža interne DDL opcije za kompresovanje fajlova BP, a postoje na tržištu i softveri specijalizovani za tu namenu. Pri kompresiji, podaci se algoritmički kompresuju pri unosu u BP i dekompresuju pri čitanju. Pošto SUBP mora pri unosu, ažuriranju i čitanju podataka da izvrši kod za kompresiju i dekompresiju, kompresovani podaci koriste više resursa CPU. Sa druge strane, na jednu stranicu stane više kompresovanih podataka. Pošto se operacije I/O vrše na nivou stranice, jedna I/O operacija će obezbediti više podataka, što će optimizovati performansu sekvencijalnog skeniranja podataka i uvećati verovatnoću da se traženi podaci nalaze u cache-u. Zato ABP mora uvek oceniti odnos prednosti – ušteda u prostoru na disku i mogućnosti smanjenja I/O troškova – i nedostataka – dodatnih CPU troškova.

28

Za manje količine podataka moguće je čak da će kompresija izazvati povećanje fajla. Ovo se dešava jer neki SUBP i algoritmi zahtevaju sopstvene rečnike za upravljanje kompresijom, koji sadrže statističke karakteristike podataka koji se kompresuju. Ako je količina podataka trivijalna, veličina rečnika može nadmašiti prostor koji se uštedi kompresijom. Smeštanje i alokacija fajlova Lokacija fajlova koji sadrže podatke BP može značajno uticati na performansu, jer smanjenjem broja I/O operacija ABP minimizira troškove fizičkog pisanja i čitanja. Za to je neophodno:

• razumevanje putanja pristupa svakom od podataka u sistemu • smeštanje podataka na disk na način koji optimizuje performansu

Prvo što treba uzeti u obzir kod smeštanja fajlova na disk je mogućnost odvajanja indeksa od podataka na dva fizički odvojena diska. Upiti u BP često zahtevaju istovremeni pristup podacima iz tabele i iz indeksa nad tom tabelom. Ako se oba ova fajla nalaze na istom disku javlja se latentnost, jer učitavanje podataka iz jednog fajla mora čekati da podaci iz drugog fajla budu učitani. Naravno, ova mogućnost nije izvodljiva ako SUBP kombinuje indekse sa podacima u jedan fajl. Druga opcija je analiza putanja pristupa aplikacija i odvajanje fajlova tabela kojima se često zajedno pristupa, iz istog razloga iz kog se odvajaju indeksi od podataka. Poslednje je smeštanje na zasebne diskove više fajlova koji sadrže jednu (particionisanu) tabelu. Time se podstiču i optimizuju paralelne operacije BP, ako SUBP može razložiti upit da se paralelno izvršava. Smeštanje log-a BP Smeštanje transakcionog log-a na zaseban disk omogućava ABP da napravi back up kopiju transakcionog log-a nezavisno od BP i minimizuje dvostruke zapise na isti disk. Takođe, pisanje podataka u dva fajla na istom disku u isto vreme umanjuje performansu čak više nego čitanje podataka iz dva fajla na istom disku u isto vreme. Smeštanje distribuiranih podataka Cilj smeštanja podataka je optimizovanje pristupa smanjenim nadmetanjem za fizička sredstva. U klijent/server okruženju ovaj cilj se može proširiti i na optimizaciju performanse aplikacija smanjenjem troškova komunikacije preko mreže. Podaci bi trebali biti smešteni na serveru BP na kom će najverovatnije, ili najčešće, biti pristupano tim podacima ili, ako na toj lokaciji ne postoji server BP, na geografski najbliži server BP. Pri tom treba uzeti u obzir i fragmentaciju, replikaciju i snapshot tabele. Alokacija diska Diskove koje koriste BP je neophodno prvo alocirati. SUBP obezbeđuje komande za inicijalizaciju fizičkih diskova, koje vezuju logičko ime za fizičku particiju diska ili fajl operativnog sistema. Po inicijalizaciji, disk se smešta u sistemski katalog i može se koristiti za smeštanje podataka u tabelama. Pre inicijalizacije diska, treba proveriti da je na fizičkom disku raspoloživa dovoljno prostora i da disk već nije inicijalizovan.

29

Preporučljivo je koristiti smislena imena zarad efikasnije upotrebe i upravljanja diskovima. Teško je loše protumačiti upotrebu diska pod imenom DUMP_DEV1 ili TEST_DEV7, a imena kao što su XYZ i A193 nisu baš korisna. Potrebno je i čuvati dokumentaciju o inicijalizovanim diskovima snimanjem script fajlova u kojima su konkretne komande inicijalizacije i dijagrami alociranog prostora na disku. Veličina stranice (bloka) Kod većine SUBP-a se može podesiti veličina stranice ili bloka. Veličina stranice određuje veličinu prostora na disku u koji se smeštaju redovi tabele (ili tačnije, zapisi sadržaja reda plus rezervni prostor). Veličina stranice se izračunava na sledeći način: na veličinu reda se doda rezervni prostor po redu, pa se pomnoži sa brojem redova po stranici i na to se doda rezervni prostor po stranici. Izbor odgovarajuće veličine stranice je važan zadatak ABP. U praksi, većina tabela zahteva neku količinu slobodnog prostora za smeštaj novih podataka, pa se određeni procenat slobodnog prostora mora uračunati u gore navedenu formulu. Takođe, mnogi SUBP ograničavaju veličinu stranice koja se može podesiti, kao npr. DB2 koji za OS/390 ograničava veličinu stranice na 4K, 8K, 16K i 32K. U tom slučaju, ABP mora izračunati najbolju veličinu stranice na osnovu veličine reda, broja redova po stranici i zahtevima za slobodnim prostorom. Na osnovu tog iznosa, bira se ponuđena veličina stranice koja obezbeđuje najmanji ostatak: ako je potrebna veličina stranice 2500 bita, u slučaju DB2 treba izabrati veličinu stranice od 8K. Ona obazbeđuje efikasniji I/O, jer čitanjem stranice od 8K biće učitana tri zapisa od 2500 bita, a čitanjem dve stranice od 4K biće učitana samo dva zapisa od 2500 bita. Reorganizacija BP Relaciona tehnologija i SQL olakšavaju izmenu podataka. Jednostavnim izdavanjem INSERT, UPDATE ili DELETE iskaza uz odgovarajuću WHERE klauzulu SUBP sprovodi samo pronalaženje i izmenu podataka. Da bi se obezbedio ovaj nivo apstrakcije, SUBP vrši fizičko smeštanje i pomeranje podataka na disku. Time se pojednostavljuje interfejs programera, a RSUBP manipuliše samim smeštanje podataka. Sa druge strane, način na koji SUBP fizički upravlja podacima može izazvati naknadne probleme performanse. Svaki ABP se susreo sa situacijom kad upit ili aplikacija, koji su do tada dobro funkcionisali, uspori posle nekog vremena upotrebe. Razlozi mogu biti raznovrsni – broj izdatih transakcija se povećao, uvećala se količina podataka ili je problem u dezorganizaciji BP. Dezorganizacija se dešava kada fizičke i logičke alokacije memorijskog prostora BP sadrže mnogo rasutih oblasti koje su suviše male, nisu fizički povezane ili su suviše neorganizovane da bi se produktivno koristile. Primarni krivci su:

• Neklasterizovani podaci. Ako SUBP ne primenjuje strogo klasterizaciju, kod klaster tabela i indeksa se može unosom novih i izmenom podataka narušiti sekvenca klasterizacije i optimizovani upiti tada ne mogu iskoristiti prednosti klasterizacije i opada im performansa.

• Fragmentacija. Ako postoji mnogo rasutih područja u memorijskom prostoru BP koja su suviše mala da se produktivno koriste. Rezultat je neiskorišteni prostor, koji umanjuje performansu zbog dodatnih I/O neophodnih za učitavanje podataka.

• Ulančavanje redova i mitigacija redova. U slučaju da se ažurirani podaci ne mogu uneti u prostor u kom su bili smešteni i SUBP mora naći mesta za red: kod ulančavanja, deo novog, većeg reda se premešta u slobodan prostor u okviru prostora tabele; kod

30

mitigacije, ceo novoformirani red se premešta u slobodan prostor. U svakom slučaju, pokazivačem se locira bilo ostatak ili ceo red, a rezultat je povećan broj I/O neophodan za čitanje jednog reda i opadanje performanse.

• Deljenje stranica. Ako SUBP vrši momotono deljenje stranica umesto normalog, ili obrnuto, uzalud se troši prostor, mali je broj redova po stranici, a time veći broj neophodnih I/O i lošija performansa.

• Proširenja fajlova. Proširenje fajla je dodatni fajl koji se vezuje za originalni fajl i može se koristiti samo zajedno sa njim, a kreira se ako originalnom fajlu ponestane prostora za smeštaj. Međutim, proširenje fajla se ne smešta pored originalnog fajla, pa što je veći broj proširenja fajla, to će zahtevi za podacima morati pristupiti većem broju lokacija. Proširenja fajlova se mogu ukloniti ponovnim podešavanjem karakteristika i reorganizacijom memorijskog prostora BP.

Organizovani i neorganizovani memorijski prostor tabela se mogu uporediti na slikama 6-11 i 6-12.

Slika 6-11. Organizovani memorijski prostor tabela

Slika 6-12. Neorganizovani memorijski prostor tabela Dodatni razlog dezorganizacije može biti brisanje jedne od višestrukih tabela definisanih u prostoru jedne tabele, kada treba reorganizovati ostale tabele da zauzmu ceo prostor. Za ispravljanje dezorganizacije ABP može pokrenuti REORG operaciju kojom SUBP restruktuira objekat BP i time ukloni probleme koji su izazivali dezorganizaciju. Može se

Tabela 1

Tabela 2

Tabela 3

Slobodno

Slobodno

Tabela 3

Tabela 2

Tabela 1

Prostor tabele

Prostor tabele

31

reorganizovati i memorijski prostor tabela i indeksi. Alat za reorganizaciju je uključen u neke SUBP, a nekad se mora i nabaviti na tržištu zasebno. ABP može i ručno reorganizovati BP, tako što će je u potpunosti iznova izgraditi. Složeni koraci ručne reorganizacije su predstavljeni na slici 6-13.

Slika 6-13. Tipični koraci ručne reorganizacije Tradicionalna reorganizacija zahteva da BP bude neaktivna, što izaziva visoke troškove i istovremeni pritisak i na sprovođenje i na odlaganje preventivnog održavanja. Raspoloživi su i neki online REORG alati koji sprovode reorganizaciju dok je BP pristupačna preko mreže. Prvo kreira kopiju BP i reorganizaciju vrši na kopiji, dok originalni podaci ostaju pristupačni preko mreže. Kada su kopirani podaci reorganizovani, online REORG koristi transakcioni log BP da u kopirane podatke unese izmene originalnih podataka nastale tokom reorganizacije. Na kraju online REORG zamenjuje original kopiranim reorganizovanim i ažuriranim podacima. Online reorganizacija zahteva dodatni prostor na disku i spori transakcioni prozor, jer ako se suviše transakcija obavi tokom procesa reorganizacije, REORG će imati poteškoća pri ažuriranju kopije. Određivanje termina reorganizacije Statističke informacije iz sistemskog kataloga mogu pomoći u određivanju kada treba reorganizovati objekt BP. Jedna od njih je odnos klasterizacije. Odnos klasterizacije je procenat redova u tabeli koji su smešteni u sekvenci klasterizacije. Nizak odnos klasterizacije ukazuje na lošu klasterizaciju i može biti neophodna reorganizacija, osim ako većina upita vrši random pristup podacima, a ne sekvencijalni. I indeksi mogu imati koristi od reorganizacije. Kod indeksa značajan pokazatelj je broj nivoa. Većina indeksa imaju strukturu b-drveta. Sa dodavanjem podataka indeksu, broj nivoa b-drveta će rasti, a time i broj I/O zahteva potrebnih da se od vrha indeksa dođe do traženih podataka. Još jedan pokazatelj indeksa koji može ukazati na potrebu za reorganizacijom je razmak između stranica listova indeksa ili leaf razmak. Leaf razmak je procenjeni prosečan broj strana između uzastopnih stranica listova u indeksu, koje mogu nastati brisanjem podataka iz indeksa ili usled deljenja stranice. Što leaf razmak ima manju vrednost, to je bolje, a ako suviše naraste, ukazuje na potrebu za reorganizacijom.

Napraviti backup kopiju prostora tabele

Izvesti objekte prostora tabele

Izbrisati objekte prostora tabele

Uvesti objekte prostora tabele

Ponovo kreirati objekte prostora

tabele

32

Automatizacija Ako je moguće, ABP bi trebalo da koristi alate BP ili druga sredstva dostupna na tržištu da automatizuje reorganizaciju. Ovakvi alati mogu pregledati statističke informacije BP i pokrenuti reorganizaciju samo za one objekte BP kod kojih su pokazatelji prešli predefinisane nivoe.

6.7. Performansa aplikacije Upravljanje performansom aplikacije podrazumeva podešavanje i optimizovanje koda aplikacije i SQL iskaza, kao i obezbeđenje odgovarajuće i efikasne interakcije aplikacije sa SUBP-om. Loše konstruisan i formulisan kod aplikacije izaziva većinu problema performanse relacionih BP.

Dizajniranje aplikacija za relacioni pristup Ako je uzrok loše performanse aplikacije neodgovarajući dizajn, moraće cela, ili bar delovi, biti ponovo napisani. Aplikacija mora biti dizajnirana za performansu od početka – promena dizajna kasnije je ili nemoguća ili nepraktična ili suviše skupa. Problemi dizajna na koje treba obratiti pažnju ako je performansa aplikacije loša:

• Tip SQL-a. Da li se odgovarajući tip (planiran ili neplaniran, dinamički ili statički, embedded ili stand-alone) koristi za ovu konkretnu aplikaciju?

• Programski jezik. Da li može postići traženu performansu i da li je jezičko okruženje optimizovano za pristup BP?

• Dizajn i procesiranje transakcije. Da li dizajn transakcija u programu osigurava ACID osobine i da li program koristi adekvatno i efikasno izabrani transakcioni procesor?

• Strategija zaključavanja. Da li aplikacija koristi pogrešan tip zaključavanja ili pravi tip suviše dugo?

• COMMIT strategija. Da li svaki aplikativni program izdaje SQL COMMIT iskaz da minimizuje uticaj zaključavanja?

• Paketna obrada. Da li su paketni programi dizajnirani da iskoriste prednost opcija sekvencijalne obrade koje pruža SUBP?

• Online obrada. Da li su online aplikacije dizajnirane da pruže korisne informacije i minimizuju količinu informacija koja se vraća na ekran korisnika, pri jednom pozivanju programa?

Relaciona optimizacija ABP mora dobro poznavati tehnike optimizacije koje koristi svaki SUBP u organizaciji. Razvojni tim aplikacije mora kodirati efikasan SQL kod i razumeti kako se on optimizuje, ali na kraju je ABP odgovoran za performansu aplikacije BP. iz tih razloga ABP mora biti i stručan u SQL kodiranju i podešavanju SQL koda za performansu. Optimizator je srce sistema za upravljanje relacionom BP. Optimizator je mehanizam instance za određivanje navigacione strategije BP. Razvojni tim aplikacije kodiranjem SQL iskaza određuje koji podaci su potrebni, SUBP obezbeđuje informacije gde se podaci nalaze, a relacioni optimizator odlučuje kako efikasno

33

sprovesti navigaciju kroz BP. Krajnji korisnik ne mora znati gde i kako su traženi podaci smešteni, optimizator ima ovu informaciju. Za optimizaciju SQL koda, relacioni optimizator mora analizirati svaki SQL iskaz obrađujući deo po deo iskaza da bi utvrdio kojim tabelama i kolonama treba pristupiti. Takođe će pristupiti statističkim informacijama koje RSUBP smešta u sistemski katalog ili u same objekte BP. Statističke informacije se koriste za određivanje najboljeg metoda za izvršavanje neophodnih aktivnosti za zadovoljenje SQL zahteva. Ovaj proces se naziva relaciona optimizacija i prikazana je na slici 6-14.

Slika 6-14. Relaciona optimizacija Relaciona optimizacija je veoma moćna, jer omogućava upitima da se prilagode promenljivom okruženju BP. Optimizator može reagovati na promene formulisanjem novih pristupnih putanja bez potrebe za promenama aplikacionog koda. Time aplikacija postaje fleksibilna pri povećanju i smanjenju veličine tabela, dodavanju i uklanjanju indeksa, dezorganizaciji i reorganizaciji BP. Bez obzira kako su podaci fizički smešteni i manipulisani, SQL kod se može koristiti za pristupanje podacima, a SUBP uzima u obzir trenutno stanje BP da bi optimizovao taj pristup podacima. Odvajanje kriterijuma pristupa od karakteristika fizičkog skladištenja podataka se naziva fizička nezavisnost podataka. Svaki RSUBP ima ugrađeni relacioni optimizator koji pretvara SQL iskaze u egzekutabilne pristupne putanje. Relacioni optimizator svakog prodavca malo drugačije funkcioniše, sa različitim koracima i koristeći različite informacije, ali je suština svakog ista – obrađuje deo po deo SQL iskaza kroz razne faze optimizacije. Faze najčešće obuhvataju verifikaciju sintaksičke i semantičke tačnosti, a zatim analizu upita i formulaciju pristupnih putanja za zadovoljenje upita.

Predlozi optimizacije

SQL zahtev

Određivanje optimalnog

pristupa

Sistemski katalog

Druge sistemske informacije

Pokrenuti SQL? Izlaz ili snimanje

pristupne putanje

NE

DA

Izvršavanje optimizovanog

SQL upita

Tabele BP

Rezultati upita

Višestruki redovi

34

Postoji mnogo strategija optimizacije koje može upotrebiti relacioni optimizator, a interne operacije i instrukcije koje koristi su strogo čuvana tajna. Moderni optimizatori se baziraju na troškovima – pokušavaju da formulišu pristupnu putanju za svaki upit, kojom će smanjiti ukupne troškove, pri čemu analiziraju i procenjene troškove CPU i I/O, statističke informacije BP i same SQL iskaze. Troškovi CPU i I/O Na osnovu informacija o CPU, optimizator dobija grubu ocenu vremena koje je potrebno CPU da izvrši upit koristeći svaku optimizovanu putanju pristupa koju analizira. Troškovi samog pisanja i uzimanja podataka tj. I/O po upitu, izračunavaju se na osnovu statističkih informacija BP, efikasnosti data cache-a i troškova I/O za radne međufajlove. Rezultat je filter faktor, koji određuje relativne I/O troškove upita. Statističke informacije BP Relacioni optimizator je beskoristan bez tačnih statističkih informacija. Relacioni SUBP pruža komandu ili alat za prikupljanje statističkih informacija o objektima BP: u DB2 administrator mora izvršiti RUNSTATS operaciju, a u SQL serveru operaciju UPDATE STATISTIC, i pri tome definiše i koje informacije se prikupljaju. Statističke informacije treba prikupljati posle svakog unosa ili izmene značajne količine podataka, inače će optimizator zasnivati svoje procene troškova na netačnim informacijama, što će umanjiti performansu upita. SUBP prikuplja statističke informacije kao što su:

• broj redova u memorijskom prostoru tabele, tabeli ili indeksu • broj jedinstvenih vrednosti u koloni • najčešće vrednosti u kolonama • gustina indeksnog ključa • detalje odnosa klasterizacije za klaster tabele • korelacija kolona sa drugim kolonama • strukturno stanje indeksa ili memorijskog prostora tabele • veličinu memorijskog prostora koji koristi objekat BP

Kad se razvija aplikacija nad test BP, statističke informacije test podataka neće tačno oslikati statističke informacije osnovne BP. Zato bi ABP, kad god je moguće, trebao da sarađuje sa razvojnim timom aplikacije na ubacivanju statističkih informacija osnovne BP u test sistem. Inače će SUBP izabrati drugačije pristupne putanje u test okruženju nego u radu sa osnovnom BP, što može izazvati probleme performanse aplikacije. Analiza upita Analizom upita se vrši pregled SQL izraza da bi se utvrdila njegova ukupna složenost. Formulacija SQL iskaza je značajan faktor u određivanju pristupne putanje koju bira optimizator – složenost upita, broj i tip predikata, funkcije i klauzule naredbi ulaze u procenu troškova koje izračunava optimizator. Što je složeniji SQL iskaz, to se opširnija analiza upita mora vršiti da bi se razjasnio SQL iskaz. Aspekti SQL iskaza koji se analiziraju su:

• Koje tabele iz koje BP su potrebne • Da li je potrebno neke nivoe prelomiti na tabele nižeg nivoa • Da li je potrebno spajanje tabela ili podselekcija • Koji indeksi, ako uopšte, se mogu koristiti

35

• Koliko predikata (WHERE klauzula) se mora zadovoljiti • Koje funkcije se moraju izvršiti • Da li SQL iskaz sadrži OR ili AND • Kako SUBP obrađuje svaki elemenat SQL iskaza • Koliko memorije je dodeljeno data cache-u (ili za više njih) koji koriste tabele u SQL

iskazu • Koliko memorije je dostupno za sortiranje ako upit zahteva sortiranje.

Veliki deo analize upita je selekcija indeksa. Pošto optimizator definiše koji su indeksi raspoloživi za koji predikat, odlućiće da li da koristi jedan, više ili ni jedan indeks. Spajanje Kada se pristupa većem broju tabela, optimizator pronalazi najefikasniji način za kombinovanje informacija iz tih tabela, odnosno za spajanje. Pri određivanju pristupne putanje za neko spajanje optimizator utvrđuje redosled kojim će tabele biti spojene, izračunava procenu ukupnih troškova svake pristupne putanje i bira metod spajanja za dati upit. SUBP može koristiti više različitih metoda spajanja tabela, ali u svakom mora doneti nekoliko odluka i izvršiti neke operacije. Prvo se bira tabela koja se prva obrađuje – spoljna tabela, a zatim se ona priprema za spajanje. Sledeće je kombinovanje redova iz spoljne tabele sa redovima iz sledeće tabele – unutrašnje tabele, koja se isto priprema za spajanje pre samog spajanja, u toku ili i pre i u toku spajanja. Spajanje je prikazano na slici 6-15.

Slika 6-15. Spajanje tabela Dva najčešća metoda spajanja su: putem ugneždene petlje i putem merge-skeniranja. Spajanje putem ugneždene petlje se vrši upoređivanjem potencijalnih redova spoljašnje tabele sa redovima unutrašnje tabele, pri čemu se traži poklapanje. Potencijalni red je onaj kod kog se poklapaju predikati za kolone u tabeli. Kad se izvrši skeniranje unutrašnje tabele za prvi potencijalni red, bira se sledeći potencijalni red i proces se ponavlja. Ponavljanje skeniranja unutrašnje tabele se ostvaruje indeksom, da bi se izbegli nepotrebni I/O troškovi. Što je manja unutrašnja tabela, bolje su performanse spajanja putem ugneždene petlje, jer je manje redova neophodno skenirati za svaki potencijalni red spoljašnje tabele. Kod spajanja putem merge-skeniranja redovi u tabelama koje se spajaju se uređuju po ključevima, što se može postići sortiranjem ili pristupom preko indeksa. Pošto su i spoljašnja i unutrašnja tabela sortirane, svaka se sekvencijalno čita i traži se poklapanje kolona. Tokom

Spoljašnja tabela Unutrašnja tabela

Spoljašnja tabela

Spoljašnja tabela

Unutrašnja tabela

TABELA 1

SPAJANJE

TABELA 2

TABELA 3 MEĐUTABELA

SPAJANJE

REZULTAT

36

spajanja putem merge-skeniranja, ni jedan red iz ijedne od dve tabele se ne čita više od jednog puta. Ovaj tip spajanja je koristan kada nije dostupan odgovarajući indeks nad jednom (ili obe tabele) koje se spajaju. Redosled spajanja Optimizator razmatra svako spajanje u upitu i pomoću ugrađenih algoritama analizira predikate spajanja, statističke informacije BP i raspoložive indekse da bi definisao optimalni redosled pristupa tabelama koje treba spojiti. U suštini, algoritam optimizatora minimizuje broj pristupa unutrašnjoj tabeli za upoređenje sa potencijalnim redovima spoljašnje tabele. Moguće pristupne putanje Relacioni optimizator ima više mogućnosti za kreiranje SQL pristupnih putanja, od kojih su neke opisane u nastavku. Skeniranje tabela Skeniranje tabela je najjednostavniji vid pristupa podacima. Vrši se jednostavnim čitanjem svakog reda u tabeli. U zavisnosti od SUBP-a može postojati i alternativni tip skeniranja, skeniranje memorijskog prostora tabele, pri kom se čita svaka stranica u okviru memorijskog prostora tabele, a koja može sadržati više od jedne tabele. Naravno, skeniranje memorijskog prostora tabele je sporije zbog dodatnih I/O čitanja podataka koji nisu relevantni. Drugi vid skeniranja je skeniranje particija. Ako SUBP može utvrditi da se podaci kojima je potrebno pristupiti nalaze u određenim particijama višeparticione tabele (ili memorijskog prostora tabele), može ograničiti skeniranje podataka na odgovarajuće particije, pri čemu se smanjuje broj potrebnih I/O. Načešće će optimizator izabrati skeniranje podataka iz jednog od sledećih razloga:

• Upit se ne može izvršiti upotrebom indeksa jer verovatno nije dostupan nijedan indeks, ni jedan predikat se ne poklapa sa indeksom ili predikat isključuje upotrebu undeksa.

• Visok je procenat potencijalnih redova u tabeli, što znači da će upotreba indeksa biti manje efikasna jer se većina redova podataka mora svakako pročitati.

• Indeksi kojima se predikati poklapaju imaju nizak odnos klasterizacije i efikasni su samo za male količine podataka.

• Tabela je tako mala da bi upotreba indeksa ustvari bila štetna, jer izaziva dodatne I/O. Kao podršku skeniranju optimizator može upotrebiti prefetch podataka, kojim SUBP učitava stranice podataka sekvencijalno u cache podataka, čak i pre nego što su podaci zahtevani. Kada operacija skeniranja zahteva podatke, oni se već nalaze u memoriji. Prefetch podataka je posebno koristan za skeniranje tabela i memorijskog prostora tabela, ali može pomoći bilo koji sekvencijalni pristup podacima. Da li je prefetch podataka dostupan i da li se i kako koristi zavisi od SUBP-a. Pristup preko indeksa Jedna od najznačajnijih odluka optimizatora koja utiče na performansu upita je da li izvršiti upit upotrebom indeksa. Prvo treba ispitati da li postoji indeks, jer se može napisati SQL upit koji pristupa koloni i ako indeks ne postoji. Dodatno, barem jedna indeksirana kolona mora biti referencirana u predikatu SQL iskaza koji može biti indeksiran. SUBP ne može koristiti indeks za svaku WHERE klauzulu, pa treba znati koji tipovi predikata mogu koristiti indekse da bi

37

odgovarajući indeksi bili kreirani za upite. Svaki SUBP ima različitu grupu elemenata koji se mogu i koji se ne mogu indeksirati, što se takođe menja od jedne do druge verzije. Relacioni optimizator može koristiti indeks na više načina. Prvi, i najjednostavniji vid indeksiranog pristupa je direktni indeksirani lookup, koji sadrži sledeće korake:

1. Vrednost u predikatu SQL iskaza se upoređuje sa vrednostima skladištenim na stranici korena indeksa i na osnovu toga SUBP će preći na sledeći niži set stranica indeksa.

2. Ako postoje središnje stranice koje nisu listovi, odgovarajuća stranica se čita i upoređuje se vrednost da bi se odredila stranica kojoj treba pristupiti.

3. Čita se odgovarajuća stranica lista, koja sadrži pokazivač(e) do samih podataka potencijalnih redova.

4. Na osnovu pokazivača SUBP čita odgovarajuće podatke sa stranica tabela. Da bi SUBP izvršio direktni indeksirani lookup moraju se definisati vrednosti za svaku kolonu u indeksu. Ako upit na primer glasi: SELECT last_name, first_name, middle_initial, empno FROM employee WHERE position = 'MANAGER' AND work_code = 1 AND dept = '001000'; i ako je definisan indeks nad kolonama position, work_code i dept, SUBP može izvršiti direktni indeksirani lookup uz upotrebu indeksa i vrednosti navedenih u predikatu za svaku od kolona. Za direktni indeksirani lookup neophodno je da se sve tri kolone iz indeksa nalaze i u SQL iskazu kao predikati, jer inače SUBP ne može naći podudarne vrednosti celog ključa indeksa. Tada bi trebalo koristiti indeksirano skeniranje, pri kom se stranice listova indeksa čitaju sekvencijalno, jedna posle druge. Postoji dve osnovne vrste indeksiranog skeniranja: matching indeksirano skeniranje (ili apsolutno pozicioniranje) i nonmatching indeksirano skeniranje. Matching indeksirano skeniranje kreće od stranice korena indeksa i nastavlja do stranica listova indeksa vrlo slično direktnom indeksiranom skeniranju. Pošto nije dostupan kompletni ključ indeksa, SUBP mora skenirati stranice listova indeksa tražeći vrednosti koje su dostupne sve dok se ne pronađu sve podudarne vrednosti. Ako se razmotri gore navedeni primer upita, u ovom slučaju upit ne bi sadržao predikat za dept kolonu.Proces je prikazan na slici 6-16. Da bi matching indeksirano skeniranje bilo izvodljivo, mora se odrediti vrednost kolone najvišeg reda tj. prve kolone definisane u ključu indeksa – u gornjem primeru position kolona. Ona za SUBP predstavlja početnu tačku za prolazak kroz strukturu indeksa. Ako njena vrednost nije definisana primenjuje se nonmatching indeksirano skeniranje (relativno pozicioniranje). U navedenom primeru, dakle, ne bi postojao predikat za position kolonu. Pošto se ne može odrediti početna tačka, SUBP ne može koristiti strukturu stabla indeksa, ali može koristiti stranice listova indeksa, kao što je prikazano na slici 6-17. Nonmatching indeksirano skeniranje počinje od prve stranice lista indeksa i skenira sledeće stranice listove sekvencijalno, primenjujući dostupne predikate.

38

Slika 6-16. Matching indeksirano skeniranje

Slika 6-17. Nonmatching indeksirano skeniranje Nonmatching indeksirano skeniranje može biti efikasnije od skeniranja tabele ili memorijskog prostora tabele, posebno ako su stranice podataka kojima se treba pristupiti u klasterisanom redosledu. Bilo koji od pomenutih metoda indeksiranog pristupa se može primeniti i na klaster i na obične indekse, ali je primena na neklaster indeksima manje efikasna – svaka stranica podataka će biti pročitana više puta jer su podaci rasuti kroz tabelu. Još jedna tehnika indeksiranog pristupa je indeksirani screening, pri kojoj se vrši podudarno indeksirano skeniranje za prve kolone indeksa nad više kolona (eng. composite, multikey, concatenated indexes), a tokom skeniranja se primenjuju dodatni predikati. Ova tehnika je korisna ako vrednosti za neke kolone indeksa sa više kolona nisu određene u upitu. Na primer, upit može glasiti: SELECT last_name, empno FROM employee WHERE position = 'MANAGER' AND work_code = 1 AND salary > 50000.00;

39

Ako je indeks kreiran nad kolonama position, work_code, dept i salary, primenjuje se indeksirani screening. Jedan od najefikasnijih tipova indeksiranog pristupa je pristup samo preko indeksa, koji se nekad naziva pokrivanje indeksom. U gornjem primeru je moguće kreirati indeks nad kolonama: position, work_code, dept, salary, last_name, i empno.Tada SUBP može zadovoljiti upit koristeći samo indeks, jer svi podaci traženi u SELECT listi i predikatima postoje u indeksu, skeniraju se samo stranice listovi indeksa i nisu potrebne dodatne I/O operacije. Nonmatching skeniranje samo preko indeksa može biti puno brže od skeniranja memorijskog prostora tabele ili tabele jer su unosi indeksa puno manji od redova u tabeli i svaki I/O čita više podataka. Da bi se ohrabrilo pristupanje samo preko indeksa ABP može prepuniti indeks dodavanjem kolona koje se pojavljuju na SELECT listi ili u SQL iskazima, što poboljšava performansu, ali i zahteva dodatni prostor na disku zbog novih kolona koje se indeksiraju. Poslednji tip indeksiranog pristupa je pristup preko više indeksa, kada SUBP koristi više od jednog indeksa za jednu pristupnu putanju. Ako upit, na primer, glasi: SELECT last_name, empno FROM employee WHERE position = 'MANAGER' AND work_code = 1; definišu se dva indeksa, jedan nad position kolonom, a drugi nad work_code kolonom, koje relacioni optiizator kombinuje da bi efikasno pristupio pravim podacima. Postoje dve vrste pristupa preko više indeksa, u zavisnosti da li su predikati vezani sa AND ili OR. ABP može minimizovati broj indeksa kreiranih zbog primene više indeksa nad jednom kolonom, zamenom sa više indeksa nad više kolona. Upotreba indeksa za izbegavanje sortiranja Sortiranje stvara prilično velike troškove i trebalo bi ga izbegavati kad god je to moguće. ABP i relacioni optimizator koriste indekse da izbegnu sortiranje, kreiranjem indeksa nad kolonama koje treba sortirati. Sortiranje je potrebno u sledećim uslovima:

• DISTINCT: kada se koristi ova klauzula, SUBP zahteva da svaka kolona podataka koji su rezultat obrade ima redosled podataka koji omogućava uklanjanje dupliciranih redova.

• UNION: zahteva da kolone na svakoj SELECT listi budu sortirane, jer podaci koji su rezultat obrade ne smeju imati duplicirane redove.

• GROUP BY: kada se koristi ova klauzula, SUBP zahteva da podaci budu sortirani po određenim kolonama kako bi bili agregirani.

• ORDER BY: ovom klauzulom SUBP će osigurati da podaci koji su rezultat obrade budu sortirani po određenim kolonama.

Primer je sledeći SQL iskaz: SELECT last_name, first_name, middle_initial, empno, position FROM employee WHERE position in ('MANAGER', 'DIRECTOR', 'VICE PRESIDENT') ORDER BY last_name; Ako postoji indeks nad kolonom last_name upit može iskoristiti ovaj indeks i izbeći sortiranje, što izaziva dodatne I/O troškove za pristup indeksu, ali eliminiše troškove CPU za sortiranje. Naravno, ako će indeks svakako biti korišten, ne treba ni razmišljati o upotrebi umesto sortiranja. Da li će upotreba indeksa zaista biti brža od skeniranja i sortiranja podataka zavisi od:

40

• broja potencijalnih redova • brzine sortiranja • osobina indeksa (npr. klaster ili ne).

Zašto indeks nije izabran? Ponekad se javljaju situacije kada se očekuje da optimizator izabere indeks, ali se to ne dešava. Postoji dosta razloga koji mogu navesti optimizator da izbegne upotrebu indeksa. Sledi lista načina za ohrabrivanje upotrebe indeksa:

• Da li upit sadrži argument pretrage? Ako ni jedan predikat ne koristi argument pretrage, optimizator ne može upotrebiti indekse da zadovolji upit.

• Da li se spaja veliki broj tabela? Optimizator u okviru SUBP-a može proizvesti nepredvidive rezultate plana upita kada se spaja veliki broj tabela.

• Da li su statističke informacije ažurirane? Ako su velike količine podataka unete, ažurirane i/ili brisane, statističke informacije BP treba ponovo prikupiti da bi osigurali da optimizator zasniva planove upita na osnovu najsvežijih podataka.

• Da li se koriste uskladištene procedure? Ponekad SUBP nudi opciju da uskladištene procedure, jednom kompajlirane, ne preformulišu plan upita za predstojeće izvršavanje. Trebalo bi rekompajlirati ili ponovo optimizovati uskladištene procedure ako se žele iskoristiti ažururane statističke informacije, novi indeksi ili druge značajne promene u bazi podataka.

• Da li su potrebni dodatni predikati? Možda je moguće da drukčije formulisana WHERE klauzula omogući optimizatoru da koristi drugačiji indeks.

Hashed pristup Optimizator će uzeti u razmatranje i korišćenje postojeće hashing stukture kada formuliše pristupne puteve. Hash je operacija slična direktnom indeksiranom lookup-u. Hash-evi su najpogodniji za slučajan I/O malih količina podataka. Za pristupanje podacima bazirano na hashing algoritmu, SUBP koristi rutinu slučajnog izbora za prevođenje vrednosti hash ključa u fizičku lokaciju. Paralelni pristup Relacioni optimizator može izabrati da paralelno izvršava upite. Kada se paralelizam upita pokrene od strane SUBP-a, pokreću se istovremene mnogostruke aktivnosti pristupa podacima. SUBP podržava tri osnovna tipa paralelizama:

• I/O paralelizam omogućava istovremene I/O tokove za jedan upit. Pokretanje paralelnih I/O aktivnosti može značajno uvećati performansu upita vezanih za I/O. Deljenjem neophodnih operacija za pristup podacima na istovremene I/O tokove izvršene paralelno, može se smanjiti ukupno vreme upita.

• CPU paralelizam omogućava multitasking CPU obrade u okviru upita. Upotreba CPU paralelizma povlači za sobom upotrebu I/O paralelizma, jer svaki CPU zahteva svoj tok I/O. Sastoji se od dekompozicije upita na veći broj manjih upita koji se mogu izvršavati istovremeno na više procesora, što dodatno smanjuje vreme obrade.

• SUBP može pokrenuti sistemski paralelizam za dodatno poboljšanje paralelnih operacija upita. Sistemski paralelizam omogućava da jedan upit bude razložen i pokrenut na više SUBP instanci.

41

Dodatni faktori optimizacije Pristupanje pogledu Jedna od dodatnih odluka tokom optimizacije upita je kako pristupiti podacima u pogledu. Pogled je logička reprezentacija tabele koja se definiše SQL iskazom, pa je upit koji pristupa pogledu u suštini SQL iskaz uključen u drugi SQL iskaz. Kada optimizator određuje pristupnu putanju upita koji sadrži pogled, mora isto uraditi i za SQL iskaz za pogled. I pogled i SQL iskaz koji pristupa pogledu mogu referencirati više tabela. Postoje dva načina za optimizaciju SQL iskaza koji pristupa pogledu: materijalizacija pogleda i spajanje pogleda. Efikasnije je spajanje pogleda, pri kom se SQL iskaz u DLL kodu pogleda spaja sa SQL iskazom koji referencira pogled. Spojeni SQL kod se zatim koristi za formulisanje pristupne putanje tabelama BP prikazanim u pogledu. Druga tehnika je materijalizacija pogleda. Kada optimizator ne može kombinovati SQL iskaz u pogledu sa SQL iskazom koji pristupa pogledu, kreira privremeni radni fajl u koji se smeštaju rezultati pogleda. Svaki SUBP ima set pravila kojim se određuje kada se materijalizacija pogleda koristi umesto spajanja pogleda, najčešće kod funkcija nad kolonama ili operacija koje zahtevaju sortiranje. Prepravka upita Neki relacioni optimizatori su dovoljno inteligentni da tokom procesa optimizacije preprave SQL iskaze u efikasnije. Na primer, optimizator može pretvoriti podupit u ekvivalentno spajanje (join). Ili može testirati ekvivalentne, ali različite formulacije predikata da bi utvrdio koji kreira bolju pristupnu putanju. Pri tom, optimizator prepravlja upit na oba načina: WHERE column1 >= 1 AND column1 <= 100 WHERE column1 BETWEEN 1 AND 100 Dodatno, optimizator može prepraviti upite kreiranjem predikata koji se podrazumevaju. Primer je tranzitivno zatvaranje predikata, pri kom optimizator dodaje predikat u upit da bi unapredio performansu. Sledeći upit: SELECT d.dept_name, e.last_name, e.empno FROM employee e, department d WHERE e.deptno = d.deptno AND d.deptno d.deptno d.deptno d.deptno = '808'; je funkcionalno ekvivalentan upitu: SELECT d.dept_name, e.last_name, e.empno FROM employee e, department d WHERE e.deptno = d.deptno AND e.deptno e.deptno e.deptno e.deptno = '808'; Jedina razlika je drugi predikat, ali pošto je deptno isto u obe tabele (na osnovu prvog predikata), nema značaja da li se proverava deptno iz e.deptno kolone ili d.deptno kolone. Ipak, moglo bi uticati na performansu upita ako postoji indeks samo nad jednom od kolona ili ako je jedna od tabela značajno veća od druge. Upit je najčešće efikasniji ako se predikat primeni na veću od dve tabele, jer će biti manji broj potencijalnih redova. Ako optimizator može izvršiti tranzitivno zatvaranje predikata, SQL razvojni tim ne mora brinuti, optimizator će uzeti u obzir pristupnu putanju za obe kolone bez obzira koja je kodirana u

42

predikatu. U suštini, prepraviće upit dodavanjem redundantnog predikata. ABP mora znati da li relacioni optimizator koji se koristi može obavljati bilo koji vid prepravke upita, a ako može, koje upite može prepravljati. Optimizacija zasnovana na pravilima Do sada je predstavljena optimizacija zasnovana na troškovima. Neki SUBP podržavaju drugi tip optimizacije zasnovane na heuristikama, ili pravilima. Oracle obezbeđuje i optimizaciju zasnovanu na troškovima i zasnovanu na pravilima. Optimizator zasnovan na pravilima zasniva odluke optimizacije na SQL sintaksi i strukturi, pozicioniranju predikata, redosledu tabela u SELECT iskazu i raspoloživosti indeksa. Sa optimizatorom zasnovanim na pravilima SQL razvojni tim mora biti svestan pravila dok piše SQL kod. Performansa upita se može smanjiti i ako se samo izvrši reorganizacija kolona u SELECT listi, ili tabela u FROM klauzuli. Ipak, trend je upotreba optimizatora zasnovanih na troškovima, posebno jer je pouzdaniji.

Procena pristupnih putanja Programer ili ABP mogu ispitati pristupne putanje koje je relacioni optimizator izabrao, za šta se koriste različite komande i procesi u zavisnosti od SUBP-a. Najčešća komanda za eksternalizaciju pristupnih putanja je EXPLAIN ili SHOWPLAN. Sam proces je predstavljen na slici 6-18.

Slika 6-18. EXPLAIN proces

Oracle i DB2 koriste EXPLAIN iskaz. Stavljanjem EXPLAIN komande ispred SQL iskaza se informacije o pristupnoj putanji, koju je definisao optimizator, upisuju u tabelu PLAN_TABLE, pa ABP ili programer mogu izvršiti upit nad tom tabelom i tumačiti definisane pristupne putanje. Na primer, SQL iskaz može glasiti: EXPLAIN plan SET STATEMENT_ID = 'emptest' FOR SELECT position, last_name, first_name, middle_initial, empno FROM employee WHERE position IN ('MANAGER', 'DIRECTOR', 'VICE PRESIDENT') ORDER BY position; gde STATEMENT_ID klauzula obezbeđuje identifikator za lociranje pristupne putanje SQL iskaza u tabeli PLAN_TABLE.Ova tabela sadrži kodirane kolone podataka, koji opisuju prirodu pristupnih putanja upita koji se koriste, kao na primer:

• Da li se koristi indeks, i ako da, koliko indeksa

Kako EXPLAIN funkcioniše Tabela PLAN

Optimizator SQL tekst BIND ili

EXPLAIN naredba

Statistike kataloga

Pristupna putanja

43

• Koliko kolona indeksa se poklapa sa upitom • Da li se koristi pristup samo putem indeksa • Koji metod join-a se koristi • Da li se koristi paralelni pristup • Da li je potrebno sortiranje

Microsoft SQL Server i Sybase koriste komandu SHOWPLAN. Slika 6-19. prikazuje tekstualni opis pristupne putanje, a slika 6-20 grafički opis.

Slika 6-19. Tekstualni opis SHOWPLAN primera

Slika 6-20. Grafički opis SHOWPLAN primera

44

Za Oracle i DB2 postoje alati za analizu pristupnih putanja koji interpretiraju tabelu PLAN_TABLE i prikazuju engleski tekst i grafičke prikaze, kao što je za DB2 Visual Explain alat prikazan na slici 6-21. Takvi alati često pružaju stručnjacima preporuke podešavanja za ispravku neefikasnih SQL iskaza.

Slika 6-21. DB2 Visual Explain alat Forsiranje pristupnih putanja Neki SUBP omogućavaju forsiranje upotrebe određenih putanja pristupa ili redosleda spajanja (join) tabela. Na primer, Microsoft SQL Server obezbeđuje FORCEPLAN opciju, pri kojoj optimizator spaja tabele redosledom koji je naveden u SQL iskazu. Oracle pruža naznake koje se mogu koristiti za usmeravanje relacionog optimizatora na izbor određenih pristupnih putanja. Naznake se unose direktno u SQL upit između /*+ i */, na primer: SELECT /*+ USE_NL */ e.position, e.last_name, e.empno, d.manager FROM employee e, department d WHERE d.dept_id = e.dept_id AND position IN ('MANAGER', 'DIRECTOR', 'VICE PRESIDENT') ORDER BY position; Ovaj upit koristi Oracle naznaku USE_NL za forsiranje spajanja ugneždenom petljom, a postoje naznake koje mogu forsirati izbor indeksa, upotrebu paralelizma ili druge optimizacione ciljeve. Tehnike koje forsiraju kriterijume izbora pristupnih putanja treba koristiti sa oprezom, osim ako ABP:

• detaljno poznaje količinu i tip podataka smeštenih u tabelama koje se spajaju, • je razumno siguran da može odrediti optimalni redosled spajanja bolje nego optimizator, • statističke informacije nisu ažurne, pa optimizator ne donosi odluke na osnovu svih

informacija o okruženju BP. Najčešći metod forsiranja izbora putanje pristupa je izmena SQL iskaza na osnovu detaljnog poznavanja relaciong optimizatora, što se naziva i tweaking SQL-a. Jedan uobičajen metod tweaking-a je promena upita kojom upit daje iste rezultate, ali je optimizator sprečen da koristi neke pristupne putanje. Ako, na primer, upit glasi:

45

SELECT last_name, first_name, empno, deptno FROM employee WHERE empno BETWEEN '001000' AND '009999' AND (salary > 50000.00 OR 0 = 1) ORDER by last_name; rezultati upita će biti potpuno isti sa ili bez OR 0 = 1 komponente poslednjeg predikata, ali kod nekih SUBP se neće moći koristiti indeks za definisanje pristupne putanje, uz takvu formulaciju upita. Kada se koristi tweaking SQL-a, mora se dokumentovati razlog, inače se može lako desiti da programer održavanja ukloni tweaking jer nije potreban.

SQL kodiranje i podešavanje za postizanje efikasnosti Kodiranje i podešavanje SQL koda je jedan od najzahtevnijih zadataka ABP. On je odgovoran za sprovođenje sledećih koraka za svaki SQL iskaz u organizaciji:

1. Definisati informacione zahteve procesa poslovanja. 2. Osigurati da su potrebni podaci dostupni u postojećim BP. 3. Prevesti informacione zahteve u SQL kod. 4. Testirati tačnost i rezultate SQL koda. 5. Razmotriti performansu pristupnih putanja. 6. Izvršiti tweaking SQL koda za poboljšane pristupne putanje. 7. Uneti u kod naznake za optimizaciju. 8. Ponoviti korake od 4 do 7 dok performansa ne dostigne zadovoljavajući nivo. 9. Ponoviti korak 8 kad god nastanu problemi sa performansom ili je instalirana nova

verzija SUBP-a. 10. Ponoviti ceo proces kad god poslovanje zahteva promenu.

Podešavanje SQL koda je složen, dugotrajan proces sklon greškama. Zahteva saradnju i komunikaciju poslovnih korisnika i programera aplikacija za sprovođenje prva tri koraka, a programera aplikacija i ABP za ostale korake. SQL uopštena pravila Neka od uopštenih pravila, nezavisna od tipa SUBP-a koji se koristi, su:

• Sve zavisi – svaka situacija je specifična, nema univerzalnog rešenja. • Pazi šta želiš – raspored elemenata u upitu može promeniti performansu upita, npr.

najrestriktivniji predikat treba staviti tamo gde će ga optimizator prvog pročitati. • Radi stvari jednostavno – jednostavni SQL kod je lakše napisati i održavati, ali složeni

kod može imati bolje performanse i biti jednostavan za optimizaciju. • Uzmi samo ono što je potrebno – treba odrediti samo neophodni minimum kolona na listi

SELECT operacije i što preciznije definisati WHERE klauzulu. • Izbegavaj Kartezijanski proizvod – moraju se u svakom SQL iskazu definisati predikati

koji odgovaraju kolonama svake od tabela koje se spajaju (join). Inače se primenjuje Kartuzijanski proizvod, koji je jako teško tumačiti.

• Oprezno upotrebljavaj logički operator OR – ako se u SQL iskazu može logički operator OR zameniti sa IN, verovatno će se unaprediti performansa.

• Oprezno upotrebljavaj logički operator LIKE – često otežava upotrebu indeksa i time smanjuje performansu.

• Moraš znati šta najbolje funkciniše – ABP mora znati koji je najbolji način kodiranja SQL iskaza za SUBP koji koristi.

• Pokreni iskaz COMMIT dovoljno često – ovaj iskaz završava promene BP, otključava resurse i drži rollback segmente pod kontrolom.

• Čuvaj se generatora koda – mnogi kreiraju SQL iskaze koji se moraju ponovo kompajlirati i optimizovati svaki put kad se koriste.

46

• Imaj na umu skladištene procedure – skladištenom procedurom se veliki broj SQL iskaza izvršava, rezultati se obrađuju i šalju korisniku na osnovu samo jednog zahteva.

Dodatni saveti za podešavanje SQL-a Podešavanje SQL-a je komplikovana aktivnost koja zahteva više knjiga samo o toj temi. Ali dodatne savete, koji slede, mogu primenjivati svi ABP bez obzira na tip SUBP-a:

• Koristite indekse da bi izbegli sortiranje. • Kreirajte indekse kao podršku problematičnim upitima. • Uvek kada je to moguće treba izbegavati aritmetička izračunavanja u okviru SQL

predikata. Za aritmetiku treba koristiti programski jezik (Java, COBOL, C). • Koristite SQL funkcije radi olakšavanja procesa programiranja. • Izgradnjom pravilnih uslova ograničenja i njihovom ugradnjom u bazu podataka se

minimizuju česte provere i ispravke koda. • Ne treba zaboraviti na "skriven" uticaj okidača. Operacija brisanja iz jedne tabele može

biti okidač za mnogo drugih operacija. Zato se za sporu operaciju brisanja može okriviti DELETE klauzula umesto pravog krivca – skrivenog efekta okidača.

Identifikovanje SQL koda loših performansi Veliki deo aktivnosti podešavanja SQL koda je identifikovanje lošeg koda. SQL monitor performansi je najbolji pristup identifikovanju iskaza sa lošim performansama. Ovakav alat konstantno nadzire okolinu DMBS-a i izveštava o količini resursa utrošenih od strane SQL iskaza. Neki SUBP-ovi u sebi već sadrže podršku za nadzor SQL koda, ali na tržištu postoje i samostalni alati za SQL nadzor. Ovakvi alati pružaju detaljnu analizu, kao što je mogućnost identifikovanja SQL-a sa najgorim performansama, integraciju sa SQL alatima za podešavanje i kodiranje, kao i grafičku prezentaciju trigera i dijagrama.

6.8. Zaključak Ako okruženje u kojem funkcioniše SUBP nije efikasno, nemoguće je ni za SUBP, a ni bilo koju aplikaciju koja pristupa BP, da bude efikasna. ABP mora razumeti svaku konfiguracionu vrednost i njen uticaj na ukupnu performansu sistema. Takođe, ABP mora kontrolisati integraciju SUBP-a sa hardverom na kojem funkcioniše i sa svim softverskim agentima usklađivanja. Aplikacije i podaci se konstantno menjaju. Korisnici zahtevaju trenutne odgovore i dostupnost 24/7. Strukture BP koje podržavaju ove aplikacije se moraju odgovarajuće održavati da bi se osigurala optimalna performansa aplikacija. Odgovarajući dizajn BP, izbor klasterizacije i reorganizacija BP zasnovana na statističkim informacijama potpomaže obezbeđenje efikasne BP. Šta više, ABP može osigurati visoku performansu BP automatizacijom ovih procesa, kako bi se smanjio rizik i greške povezane sa ručnim održavanjem BP. Upravljanje performansom aplikacije i podešavanje SQL koda su kompleksne oblasti koje zahtevaju aktivno učestvovanje programera i ABP. Svaki SUBP funkcioniše drugačije, stoga ABP, kao i programeri, treba da u potpunosti razumeju do najsitnijih detalja upravljanje performansom SQL koda i aplikacija za svoj SUBP.

47

Relacioni optimizator kombinuje strategije pristupnih puteva radi formiranja efikasnih pristupnih puteva za svaki SQL zahtev. Međutim, optimizator je veoma složen deo softvera i kompanije koje prodaju SUBP ne dele sa svojim kupcima baš sve detalje o funkcionisanju optimizatora. Zbog toga, veoma često, podešavanje performase SQL koda, umesto nauke, postaje umetničko – iterativni proces.

48

7. Integritet podataka

bezbeđenje integriteta baze podataka u firmi ključna je komponenta posla administratora baze podataka. Baza podataka je od male koristi ako su njeni podaci neažurni i ako im se ne može pristupiti zbog problema integriteta. Administrator baze podataka poseduje mnoge alate koji će obezbediti integritet podataka.

Tipovi integriteta

U odnosu na bazu podataka razmatraćemo dva aspekta integriteta:

• Strukturni integritet baze podataka

• Semantički integritet podataka.

Praćenje svakog objekta baze podataka radi odgovarajućeg kreiranja, formatiranja i održavanja cilj je strukturnog integriteta baze podataka. Svaki SUBP koristi svoj format i strukture da bi održao baze podataka, prostore tabela, tabele i indekse pod svojom kontrolom. Sistemske i aplikativne greške mogu uzrokovati pogrešan rad sa tim internim strukturama, a posao odministratora baze podataka je da takve probleme otkrijei otkloni pre nego što oni postanu nepremostivi. Drugi tip integriteta je semantički integritet podataka. On se odnosi na značenje podataka i veze medju njima koje se moraju održavati. SUBP obezbedjuje opcije, kontrole i procedure da bi se obezbedio semntički integritet podataka koji se nalazi u bazi. Administratori moraju znatti kako sisitem obezbeđuje automatsku proveru integriteta podataka. I najzad, kao najvažniji deo posal, administratori moraju ugraditi semantički integritet podataka u dizajn baze , kao i da iniciraju proces provere i korekcije problema integriteta koji stalno prete bazi podataka.

Strukturni integritet baze podataka

Strukturni integritet i konzistetnost baze podataka je od najveće važnosti u obavljanju poslova administracije baze podataka. SUBP koristi interne strukture i pokazivače da bi održao objekte baze podataka u odgovarajućem stanju. Ako sete strukture oštete na bilo koji način, pristup bazi podataka će biti onemogućen. Tipovi problema u internim strukturama baze podataka

Jedan od najčešćih problema koji se javljaju u relacionim bazama podataka je oštećenje indeksa. Podsetite se iz predhodnih poglavlja da indeks obezbeđuje alternativne putanje do podataka u bazi korišćenjem uređenog B-stabla. Stranice na listovima indeksa sadrže pokazivače ka fizičkim lokacijama podataka u baznoj tabeli. Ako ti pokazivači ne pokazuju na ispravne podatke, indeksi su beskorisni. Ideksi se mogu oštetiti na različite načine, u zavisnosti od sistema koji se koristi i operacija koje se izvršavaju nad indeksom i pripadajućom tabelom. Na primer, ako je tabela oporavljena sa zaštitnih kopija, a indeksi nisu ažurirani , onda oni neće tačno odslikavati trenutno stanje podataka. Medjutim, indeksi nisu jedini objekti baze podataka koji koriste pokazivače. Pri korišćenju određenih tipova podataka, sisitem može zahtevati pokazivače. Na primer, veliki objekti, kao što su kod DB2 LOB kolone ili kod SQL Servera Text ili Image kolone, ne smeštaju se u tabelu sa ostalim podacima. Moguće je da ovi pokazivači izgube sihronizaciju sa podacima, uzrokujući nemogućnost prustupanja,

O

49

Još jedan, ali dosta ređi problem strukturnog integriteta baze podataka je oštećenje zaglavlja

stranice. Svaka fizička stranica (ili blok ) u datoteci baze podatakasadrži interne podatke poznate kao zaglavlje, koji se nalaze u njenom početku. Zaglavlje omogućava da se sadržaj stranice lako i brzo pročita. Ukoliko se zaglavlje ošteti, SUBP neće moći da interpretira podatke koji se nalaze na toj stranici. Takve situacije obično zahtevaju da se podaci oporave sa zaštitinih kopija . Podaci na zaštitnim kopijama su još jedan potencijalni izvor problema strukturnog integriteta. Svaki SUBP formatira i primenjuje specifične strukture tih kopija. Ako one nisu pravilno formatirane , ili su podaci na pogrešnoj lokaciji unutar kopija , ne mogu se koristiti u svrhu oporavka podataka. Rešavanje problema strukturnog integriteta

Svaki sistem obezbeđuje različite uslužne programe za proveru mnogi aspekata strukturnog integriteta baze podataka. Ovi uslužni programi omogućuju ispitivanje integriteta baze podataka. Na primer, Sybase i Microsoft SQL Server obezbedjuje DBCC alat, DB2 ima CHECK i REPAIR, a Informix nudi TBCHECK. Da bi smo obrazložili funkcionisanje ovih uslužnih programa, fokusiraćemo se na DBCC. Slika pokazuje neke situacije u kojima se ovaj nprogram može da koristi.

Opcije za proveru konzistetnosti

Uslužni program DBCC obezbedjuje sve opcije za osnovnu proveru konzistetnosti:

• DBCC CHECKTABLE (ime_table) provera konzistetnosti podataka i indeksnih stranica

tabele. Kada se DBCC startuje sa ovom opcijom , on će prijaviti ukupan broj stranica sa

podacima, broj slogova, broj kolona tekstualnog ili binarnog tipa , kao i narušavanje bilo

kog tipa integriteta.

• DBCC REINDEX (ime_table) proverava konzistetnost indeksa i njegov oporavak ukoliko

naiđe na oštećenje strukture.

50

Provera baze podataka

Dodatne opcije DBCC-a koje su na raspologanju služe za proveru integritetabaze podataka:

• DBCC CHECKDB ( ime_baze_podataka) izvršava prvo CHECKTABLE nad svakom tabelom

navedene baze podataka

• DBCC CHECKKCATALOG (ime_baze_podataka) proverava konzistetnost sistemskog

kataloga navedene baze podataka.

• DBCC CHECKALLOC (ime_baze_podataka) proverava konzistetnost navedene baze

podataka i izveštava o trenutnoj strukturi proširenja datoteke.

Korišćenje memorije

Program DBCC se može koristiti za nadgledanje dodeljivanja memorije i njenog korišćenja. Navodjenjem opcije MEMUSAGE ( DBCC MEMUSAGE ) će se dobiti izveštaj o dodeljivanju memorije za 20 najzahtevnijih korisnika. Izveštaj sadrži sledeće iformacije:

• KONFIGURISANJE MEMORIJE količina memorije koja je dodeljena SUBP-a .

• VELIČINA PROGRAMSKOG KODA Količina memorije koja je upotrebljena za programski

kod

• JEZGRO SISTEMA I INTERNE STRUKTURE količina memorije iskorišćena za jezgro i za

server.

• KEŠ STANICA količina memorije koja je iskorišćena za keš podatke

• BAFERI I ZAGLAVLJA PROCEDURA količina memorije iskorišćena za keš podatke

• DETALJNE INFORMACIJE O KEŠU PODATAKA Spisak 20 korisnika koji najviše koriste keš

podatke, zajedno sa spiskom objekata kojima pristupaju, i koliko je bafera od 2K

iskorišćeno

• DETALJNE INFORMACIJE O KEŠU PROCEDURA Spisak 20 korisnika koji najviše koriste keš

procedure, navodeći tip pristupa i raspodelu memorije

Semantički integritet podataka

Semantički integritet baze podataka se odnosi na mogućnosti i procese sistema koji se mogu koristiti da bi obezbedili tačnost i funkcionalnost sadržaja baze podataka. Dok se strukturni integritet baze podataka odnosi na stukture koje sadrže podatke (objekte baze podataka ) , semantički integritet ukazuje na konzistetnost samih podataka. Administratori baze podataka se konstantsno bore sa pitanjem kako najbolje održati semantički integritet podataka –korišćenjem opcija sisitema ili aplikativnim kodom. Ovo je veoma važno pitanje o kome se stalno vodi rasprava. Obično se smatra da je korišćenje SUBP-a za održavanje integriteta podataka najbolje rešenje i to iz nekoliko razloga. Lakše je kreirati i održavati pravila semantičkog integriteta korišćenjem SUBP-a neko kreirati i održavti programski kod za te namene.

Integritet entiteta Integritet entiteta je najosnovniji nivo integriteta podataka koji SUBP može da izvršava. Integritet entiteta znači da svako pojavljivanje entiteta mora biti jedinstveno indetifikovano. Drugim rečima , zahteva se definisanje primarnog ključa za svaki entitet, kao i da ni jedna komponenta primarnog ključa ne može biti Null.

51

U praksi ni jedan SUBP ne forsira primenu integriteta entiteta zato što se entiteti ili tabele mogu kreirati bez definisanje primarnog ključa.Osim toga, veoma je loša praksa kreirati tabele bez primarnog ključa zato što to otežava indetifikaciju slogova. Primarni ključ je potreban da bi se postavila pravila referencijalnog integriteta između tabela. Ograničenje primarnog ključa se može sastojati od jedne ili više kolona iste tabele koje su jedinstvene unutar nje.Tabela može imati samo jedan primarni ključ koji ne može biti Null. Sledi primer kreiranja primarnog ključa: CREATE TABLE RADNIK ( SifRad INTEGER PRIMARY KEY, AdresaRad VARCHAR (70), TipRad CHAR (10), If0rgRad CHAR (3) NOT NULL WITH DEFAULT, Zarada DECIMAL (7,2) NOT NULL, Procenat0dProfita DECIMAL (7,2) Dodatak DECIMAL (7,2), ) IN db.ts; Ovaj primer ukazuje na specifičnosti ograničenja primarnog ključa na nivou kolone: ono se primenjuje na koloni SifRad, koji je definisan kao primarni ključ za ovu tabelu. Medjutim u praksi je vrlo često da se primarni ključ sastoji od više kolona. Iz tog razloga ograničenja primarnog kluča se mogu postaviti na nivou tabele. Na primer ako se primarni ključ ove tabele definiše kao kombinacija kolona SifRad i TipRad, možete zadati ovakvu specifikaciju na kraju definicije tabele, odmah posle navodjenja poslednje kolone: PRIMARY KEY PK_RAD ( SifRad, TipRad ) Ograničenje jedinstvene vrednosti

Ograničenje jedinstvene vrednosti je slično ograničenju primarnog ključa. Svaka tabela može imati nula, jednu ili više takvih ograničenja koja se sastoji od jedne ili više kolona. Vrednosti tih kolona ili njihove kombinacije mora biti jedinstvena unutar tabele – što znači da ni jedan drugi slog ne može sadržati iste vrednosti tih kolona. Ova ograničenja se razlikuju od primarnog ključa u tome što se ne mogu koristiti za podršku referencijalnim ograničenjima. Kao i u slučaju ograničenja primarnog ključa, SUBP će zahtevati kreiranje jedinstvenog indeksa nad kolonama ovog ograničenja da bi se zabranila pojava duplih vrednosti tih kolona. Ograničenje jedinstvene vrednosti

Tipovi podataka i dužina podataka su najosnovnija ograničenja integriteta koja se primenjuju nad podacima u bazi. Jednostavno navođenje tipa podataka za svaku kolonu prilikom kreiranja tabele omogućiće sistemu da obezbedi smeštanje koreknih podataka u kolonu. Procesi koji pokušavaju da upišu vrednost pogrešnog tipa biće odbijeni. Osim toga, maksimalna dužina dodeljenenoj koloni zabranjuje unošenje većih vrednosti od onih koje su definisane. Administrator baze podataka mora pažljivo da izabere tip i dužinu za svaku kolonu tabele. Bajbolje je napraviti izbor tipa podataka koji će se najbolje poklopiti sa domenom korektnih vrednosti te kolone. Korisnički tipovi podataka

52

Korisnički tipovi podataka ( „user defined data type“ –UDT ), obezbeđuju mehanizam za proširenje tipova podataka koji se mogu definisati u bazi, kao i način na koji se podacima može upravljati. Drugim rečima, administrator baze podataka može kreirati korisničke tipove podataka radi dodatne definicije ispravnih vrednosti kolone . Kada se korisnički tipovi podataka jednom definišu, proširuje se funkcionalnost SUBP-a tako što se omogućava administratoru da ih navede u CREATE TABLE DDL-u baš kao i ugrađene tipove podataka. Korisnički tipovi podataka su korisni kada želite modelirati podatke koji su specijalno prilagođeni zahtevima firme. Na primer, oni se mogu koristiti kada baratate različitim valutama. Možda firma koristi monetarne vrednosti Kanade, SAD-a, Evropske unije i Japana. Administrator baze podataka može kreirati četiri korisnička tipa podataka kao što su: CREATE DISTINCT TYPE Kanadski_Dolar AS DECIMAL ( 11,2) ; CREATE DISTINCT TYPE Americki_Dolar AS DECIMAL ( 11,2 ) ; CREATE DISTINCT TYPE Euro AS DECIMAL ( 11,2) ; CREATE DISTINCT TYPE Japanski_Jen AS DECIMAL (15,2) ; Nakon kreiranja ovih tipova podataka,oni se mogu koristiti na isti način kao i ugrađeni tipovi. Naravno, tačna sintaksa kreiranja korisničkih tipova razlikuje se od sistema do sistema. Kreiranje odvojenih tipova podataka, sistem primenjuje strogo odvajanje tipova ; drugim rečima, sistem će zabraniti izvođenje nedefinisanih operacija između različitih tipova. Na primer, sledeća operacija se neće dozvoliti zbog pomenutog strogog odvajanja tipova: UKUPAN_ISNOS = AMERIČKI_DOLAR + KANADSKI_DOLAR Podrazumevane vrednosti

Kada se kreiraju kolone u tabelama , može im se dodeliti podrazumevana vrednost koja će biti upotrebljena kada se u SQL INSERT naredbi eksplicitno ne navede vrednost te kolone. Ovo omogućava programerima da izostave tu kolonu i ostave sistemu da joj automatski dodeli podrazumevanu vrednost. Svaka kolona može imati samo jednu podrazumevanu vrednost. Tip kolone, dužina i njena svostva moraju podržati podrazumevanu vrednost koja je definisana. Ograničenja provere vrednosti

Ograničenja provere vrednosti je restrikcija koja se postavlja na vrednost podataka koji se mogu uneti u kolone tabele. Kada se definiše ovo ograničenje , ona postavlja restrikcije na sadržaj kolone kao logičke izraze. Logički izraz je esplicitno definisan u DDL-u tabele i formulisan je na isti način kao i SQL WHERE izraz. Bilo koji pokušaj promene sadržaja kolona naredbom INSERT ili UPDATE uzrokovaće izračunavanje logičkog izraza.Ako izmene zadovoljavaju uslove logičkog izraza, dozvoljava se izvršenje izmene. Ograničenje provere vrednosti se može definisati prilikom kreiranja tabele,ili se dodati kasnije naredbom ALTER TABLE. Ime ograničenja indetifikuje ograničenje u bazi podataka. Isto ime ograničenja se ne može definisati više od jednom za istu tabelu. Ako ime ograničenja nije navedeno, sistem će automatski generisti jedintsveno ime za njega. Svaki SUBP koristi različite algoritme za definisanje imena ograničenja ,ali se ono obično izvodi iz imena prve kolone u uslovu provere. Uslov provere definiše konkretnu logiku ograničenja. On se može definisati korišćenjem bilo kojih osnovnih operacija (>,<,=,<>,<=, >=) kao i BETWEEN, IN, LIKE i NULL. Osim njih se mogu i koristiti i OR ili AND da bi se logički spojili zadati uslovi u ograničenju.

53

Ipak postoje određene restrikcije u korišćenju provere vrednosti:

• Ograničenje provere vrednosti se može jedino pozivati na kolone tabele u kojoj se ono

kreira

• Unutar provere vrednosti, dozvoljen je ograničen podskup SQL konstrukcija. Obično su

zabranjeni podupiti, funkcije nad kolonama, globalne prominjive i negacija ( NOT ).

• Prvi operand ograničenja provere vrednosti je kolona tabele, a drugi je ili kolona ili

konstanta

• Ako je drugi operand konstanta, ona mora biti kompatibilna sa tipom podataka prvog

operanda.

Koristi od ograničenja provere vrednosti

Glavna korist je direktna mogućnost primene poslovnih pravila u bazi podataka bez potrebe za definisanjem dodatne aplikativne logike. Kada se poslovno pravilo definiše i fizički implementira, ono se ne može zaobići. Zbog toga što nije potrebno dodatno programiranje , administrator baze podataka može implementirati ograničenja provere vrednosti bez uključenja programera aplikacije. Na ovaj način se efikasno smanjuje količina koda koju programeri moraju napisati. Ona obezbeđuje bolje održavanje integriteta podataka. Pošto se izvršavaju uvek kada su podaci u koloni na kojom su definisane promene, poslovna pravila koja su definisana ograničenjem se poštuju i tokom ad hac obrade i izvršavanja dinamičkih SQL-a . Provere vrednosti obezbeđuju konzistetnost podataka. Zbog toga što se definišu jednom – u DDL-u tabele – svako od njih uvek primenjuje. Primeri ograničenja provere vrednosti

Ograničenja provere vrednosti omogućavaju administratoru ili dizajneru baze podataka da primene robusnija pravila integriteta podataka direktno u bazu. Sledeći primer CREATE TABLE RADNIK ( SifRad INTEGER PRIMARY KEY CONSTRAINT provera_sifre Check ( sifRad BETWEEN 100 AND 25000 ), AdresaRad VARCHAR (70), Tiprad CHAR (10) CHECK (TipRad IN ( ’odredjeno’,’neodredjeno’,’ugovor’)), Sif0rgRad CHAR /3) NOT NULL WITH DEFAULT, Zarada DECIMAL (7,2) NOT NULL CONSTRAINT provera_zarada Check ( zarada <50000.00) Procenat0dProfita DECIMAL (7,2), Dodatak DECIMAL (7,2), ) in db.ts ; Naredba CREATE za tabelu RADNIK sadrži tri različita ograničenja provere vrednosti:

• Ime prvog ograničenja je provera_šifre. Ono se definiše nad kolonom SifRad i osigurava

da se unete vrednosti mogu kretati u rasponu od 100 do 25000 (umesto domena svih

celih brojeva)

54

• Drzgo ograničenje u ovoj tabeli je nad kolonom TipRad. Ovo je primer neimenovanog

ograničenja što. Iako je dozvoljeno , ipak nije preporučljivo.najbolje je da uvek zadate

ime ograničenju da bi se ono lakše održavala i adminisrirala. Tačno određene vrednosti

se mogu upisati u ovu kolonu:’odredjeno’,’neodređeno’ i ’ugovori’; ni jedna druga

vrednost neće biti prihvaćena

• Poslednje definisano ograničenje je nazvano proevra?zarade. Njime se efikasno

obezbeđuje da se ni jednom radniku ne može uspisati veća zarada od 50 000.

Vrlo često poslovna pravila nalažu pristup u više kolona istovremeno u jednoj tabeli. U takvoj situaciji je potrebno kreirati poslovno pravilo kao ograničenje provere vrednosti na nivou tabele, umesto na nivou kolone. Naravno, istovremeno mogu postojati i provere vrednosti nad kolonama. U smislu funkcionalnosti, nema razlike ako se ograničenje proere vrednosti zada na nivou tabele ili kolone. Proširimo gornji primer sa nekoliko provera vrednosti na nivou tabele:

CREATE TABLE RADNIK ( SifRad INTEGER PRIMARY KEY CONSTRAINT provera_sifre CHECK (SifRad BETWEEN 100 AND 25000), AdresaRad VARCHAR (70), TipRad (CHAR) CHECK (TipRad IN (’određeno’,’neodređeno’,’ugovor’)), Sif0rgRad CHAR(3) NOT NULL WITH DEFAULT, Zarada DECIMAL (7,2) NOT NULL CONSTRAINT proevra_zarade CHECK ( Zarada <50000.00) Procenat0fProfita DECIMAL (7,2), Dodatak DECIMAL (7,2), CONSTRAINT zarada_proc Check ( Zarada > Procenat0dProfita ), CONSTRAINT proc_dodatak CHECK ( Procenat0Profita=0 OR Dodatak=0 ) ) IN db.ts ; Sad se naredbom CREATE promenila tako da sadrži dve provere vrednosti na nivou tabele sa sledećim značenjem:

• Prva provera vrednosti za tabelu RADNIK ima naziv zarada_proc. Ona obezbeđuje da ni

jedan radnik ne može od procenta profita zaraditi više nego što mu je zarada.

• Druga provera vrednosti ima naziv proc_dodatak. Ovo ograničenje obezbeđuje da radnik

ne može istovremeno imati procenat od profita i dodatak na zaradu.

Null i ostali potencijalni problemi .Sledeće razmatranje ograničenja provere vrednosti je relacioni Null.Bilo koja kolona koja može biti Null i za koju postoje provera vrednosti može se postaviti na Null. Korišćenjem uslužnih programa može uzrokovati probleme sa ograničenjima provere vrednosti. Na primer, u zavisnosti od sistema, LOAD može ili ne mora izvršavati definisane provere vrednosti dok se podaci učitavaju u tabelu.

55

Još jedan potencijalni problem koji se javlja kod provere vrednosti je njihovo kodiranje u više tabela. Moguće je da slične kolone istog tipa podataka i dužine mogu postojati u različitim tabelama baze podataka. Kao i provere vrednosti pravila definišu parametre za proveru podataka. Kad god se podaci ubacuju ili ažuriraju, pravila se proveravaju da bi se utvrdilo da li se izmene podataka poklapaju sa zadatim pravilima. Ona se mogu definisati i na korisničkim tipovima podataka i na kolonama. Nakon kreiranja, pravila moraju biti dodeljena kolonama ili korisničkim tipovima podataka pre nego što budu upotrebljena u bazi podataka. Povezivanje se vrši sistemskom procedurom SP_BINDRULE. Na primer, sledeće naredbe se mogu koristiti za kreiranje pravila koje proverava skraćenice američkih država Ilinois, Viskonsis i Indijana, a zatim povezuje pravilo sa kolonama u dve različite tabele:

CREATE RULE Pravilo_Drzava AS @drzava IN (’IL’,’WI’,’IN’)

EXEC SP_BINDRULE “Pravilo_Država”, „izdavac.drzava“ EXEC SP_BINDRULE „Pravilo_Država“, „autor.drzava“

Kada se pravilo pridruži koloni ili korisničkom tipu podataka, ono će funkcionisati kao ograničenje provere vrednosti. Pravila mogu biti mnogo pouzdanija jer se kreiraju samo jednom, nakon čega se povezuju sa odgovarajućim kolonama i tipovima podataka. Osim toga, moguće je definisati neprimenjivo pravilo provere vrednosti nad tabelom. Relacioni SUBP obezbeđuje dodatnu mogućnost definisanja podrazumevane vrednosti. Kada se slog ubacuje ili učitava u tabelu a za kolonu nije data vrednost, kolona će dobiti onu vrednost koja je definisana kao podrazumevana vrednost za TipRad naše tabele RADNIK kao što sledi:

TipRad CHAR(10) DEFAULT ’neodređeno’ CHECK ( TipRad IN ( ’odredjeno’,’neodređeno’,’ugovor’)),

Ako se ubaci slog bez navedene vrednosti za TipRad ,kolona će dobiti podrazumevanu vrednost ’neodređeno’. Međutim, neki sistemi nisu dizajnirani za izvođenje semantičke provere ograničenja i podrazumevanih vrednosti.

Okidači

Okidači su specijalizovane procedure koje se izvršavaju pojavom određenog događaja. To je programski kod koji se izvršava kao odgovor na naredbe za izmenu podataka, kao što su INSERT, UPDATE ili DELETE. Da budemo malo precizniji, okidači su specijalizovane procedure zasnovane na događajima koji su smešteni u sistemu i kojima sistem upravlja. Svaki okidač se dodeljuje samo jednoj određenoj tabeli. Okidači se mogu zamiliti kao napredni oblik pravila koji se kodira korišćenjem priširene forme SQL-a. Oni se ne mogu direktno pozvati ili izvršiti; oni se automatski izvršavaju ( ili okidaju ) oda strane sistema kao rezultat neke akcije – izmenom podataka u određenoj tabeli. Kada se okidač kreira, onse uvek izvršava kada se pojavi „okidajući“ događaj ( UPDATE, INSER ili DELETE ). Osim toga, okidači su automatski, implicitni i nezaobilazni. Baza podataka sa definisanim okidačimase naziva aktivna baza podataka zato što jednostavne izmene podataka uzrokuje dodatne akcije koje se izvršavaju –one koje su definisane u kodu okidača. Oni su slični uskladištenim procedurama. I jedni i drugi sadrže proceduralnu logiku koja se smešta u bazi i kojom ona upravlja. Međutim, uskladištene procedure nisu vođene događajimai nisu pridružene ni jednoj tabeli.

56

Okidači su korisni za implementaciju koda koji se mora izvršiti svaki put kad se određeni događaj pojavi. Okidači se mogu koristiti u mnoge praktične svrhe. Vrlo često je nemoguće isprogramirati poslovno pravilo u bazi podataka korišćenjem DDL-a. Okidači su vrlo fleksibilni i mogu se kodirati za razne svrhe. Na primer, oni mogu:

• Pristupiti drugim tabelama i izmeniti podatke u njima

• Prikazati informativne poruke

• Ozvoditi složena ograničenja

Kako se okidači izvršavaju

Okidači se mogu programirati da se startuju na dva različita načina: pre okidajuće aktivnosti ili posle nje. Okidači „pre“ ( before) se izvršavaju pre ne što se okidajući događaj pojavi ; okidači „posle“ (after) se izvršavaju nakon završetka okidajućeg događaja. Neki sistemi podržavaju oba tipa okidača, dok neki samo jedan. Poznavanje rada okidača u sistemu koji koristite je obavezan. Bez njihovog poznavanja oni se ne mogu ispravno kodirati i održavati. Na primer, prepostavite slučaj gde se okidajući događaj pojavljuje pre nego što okidač startuje. Drugim rečima , UPDATE, INSERT ili DELETE se pojavljuju prvi, a kao rezultat tih akcija se izvršava programska logika okidača. Ako je potrebno, okidači mogu poništiti načinjene izmene podataka. A šta ako se okidač startuje pre okidajućeg događaja ? U ovakvoj situaciji poništene izmene podataka nije potrebno zato što se okidajući događaj još nije desio. Međutim, mogu se poništiti ostale promene podataka koje su se pojavile pre izvršenja okidača unutar iste transakcije. Ugnježdeni okidači

Kao što smo već načuli , okidači se startuju akcijama INSERT, UPDATE ili DELETE. Međutim, okidači u sebi mogu sadržati iste te naredbe. To znači da izmene podatakauzrokuju startovanje okidača, koji uzrokuju nove izmene podataka, a one startuju nove okidače. Kada okidač sadrži u sebi naredbe INSERT, UPDATE ili DELETE , kaže se da su to ugnježdeni okidači. Međutim, mnogi sistemi postavljaju limit broja ugnježdenih okidača koji se mogu izvršiti jednim okidajućim događajem. Ako se to ne bi uradilo, vrlo verovatno bi okidači mogli da se startuju u beskonačnosti sve dok se svi podaci ne izbrišu iz baze podataka. Ako se pravila referencijalnog integriteta (RI) kombinuju sa okidačima, mogu se javiti dodatno kaskadno ažuriranje ili brisanje podataka. Ako UPDATE ili DELETE inicira dodatno ažuriranje ili brisanje koja se moraju izvršiti na drugim tabelama, mogu se aktivirati i okidači vezani za UPDATE ili DELETE tih tabela. Ovakva kombinacija okidača i pravila referencijalnih integriteta može uzrokovati višestruke izmene u bazi podataka. Mogućnost kreiranja ugnježdenih okidača obezbeđuje efikasan metod za primenu automatskog održavanja integriteta podataka. Pošto se okidači generalno ne mogu zaobići, oni obezbeđuju elegatni metod prisiljavanja aplikacija da poštuje poslovna pravila. Korišćenje okidača za primenu referencijalnog integriteta

Jedna od najčešćih upotreba okidača je podrška pravilima referencijalnog integriteta. Okidači se mogu kodirati na mestima deklarativnih pravila referencijalnog integriteta da bi podržali referencijalna ograničenja koja želite postaviti na bazu. Prelazne promenljive i tabele

57

Da biste uspešno koristili okidače za podršku pravilima referencijalnog integriteta, ponekad je važno da znate vrednosti na koje su iticala izvršena pravila. Slog i sve njegove vrednosti su već obrisani zbog toga što se okidač izvršava nakon pojave okidajućeg događaja. Svaki SUBP ima različite metode pristupa podacima iz okidača pre i posle izvršene izmene.

Svaki okidač ima dve tabele –jednu sa slikom podataka „pre“ i drugi sa slikom podataka „posle“ Njima mogu pristupiti samo okidači. Sybase i Microsoft SQL Server koristi te tabele na sledeći način:

• Kada se pojavi INSERT, table INSERTED sadrži upisane slogove tabele za koju je definisan

okidač.

• Kada se pojavi DELETED , tabela DELETED sadrži slogove koji su upravo izbrisani iz tabele

za koju je definisan okidač

• Kada se pojavi UPDATE , on se tretira kao DELETE, praćen akcijom INSERT, tako da tabela

INSERTED sadži nove vrednosti za slogove koji su upravo ažurirani , a tabela DELETED

sadrži stare vrednosti tih slogova ( pre ažuriranja )

Kod Oraclea i DB2 je implementacija polaznih tabela ( ili promenjivih) jednostavnija, i radi na sledeći način:

• Kada se pojavi INSERT, vrednostima koje su dodate se može pristupiti preko

promenjive NEW.

• Kada se pojavi DELETE, obrisanim vrednostima se može pristupiti preko promenjive

OLD

• Kada se pojave UPDATE , novim podacima se može pristupiti preko promenjive NEW

a starim preko OLD

Primer okidača

Ponekad analiza dela koda može pomoći u razjašnjenju nekih koncepata. Zbog toga pogledajte sledeći primer ( DB2 ) okidača: CREATE TRIGGER azuriranje_zarade BEFORE UPDATE OF Zarada ON Radnik FOR EACH ROW MODE DB2SQL WHEN ( new.Zarada > ( old.Zarada *1.5)) BEGIN atomic SIGNAL SQLSTATE ’75001’ ( ’Uvećanje zarade prelazi 50%’); END;

58

Ovaj okidač obezbeđuje da vrednost kolone Zarada ne može biti povećana više od 50% za svako pojedinačno ažuriranje. Osetljivost okidača

Zbog toga što je SQL jezik baziran na skupovima podataka, svaka SQL naredba ima uticaj na više slogova. Na primer, jedna naredba DELETE može u stvari obrisati nula, jedan ili više slogova.Prilikom kodiranja okidača morate uzeti u obzir. Samim tim, postoje dva nivoa osetljivosti okidača. Okidači na nivou naredbe se izvršavaju jedamput nakon okidanja, bez obzira na stvari broj slogova koje je izmenjen, dodat ili obrisan. Okidači na nivou sloga se, nakon okidanja, izvršavaju po jednom za svaki slog koji se menja, dodaje ili briše.

Referencijalni integritet

Referencijalni integritet je metod obezbeđivanja korektnosti podataka unutar SUBP-a. Obično se radi pojednostavljenja, kaže da je to indetifikacija veza među relacionim tabelama. U stvari, on je mnogo više od toga. Međutim, indetifikacija primarnih i stranih ključeva između tabela jeste komponenta definisanja referencijalnog integriteta. Referencijalni integritet objedinjuje integritet i mogućnosti korišćenja veza uspostavljanjem pravila koja će upravljati tim vezama. Kombinacija kolona primarnih i stranih ključeva i pravila koja diktiraju kako će se podacima rukovati u tim kolonama početak su procesa razumevanja i korišćenja RI da bi se obezbedile korektne i korisne baze podataka. Pravila referencijalnog integriteta se primenjuju na svaku vezu i određuju status kolone stranih ključeva prilikom upisivanja ili ažuriranja , ili zavisnih slogova kada se slog primarnog ključa obriše ili ažurira.. Koncept referencijalnog integriteta se može sažeti u brzoj i jednostavnoj definiciji : on garantuje da su prihvatljive vrednosti uvek u kolonama stranog ključa. Termin „prihvatljive“ se definiše u odnosu na vrednosti u odgovarajućoj koloni primarnog ključa,ili Null. Dva važna termina referencijalnog integriteta su nadređena tabela („parent table“) i podređena

tabela („child table“). Za bilo koje zadato referencijalno ograničenje , nadređena je ona tabela koja sadži primarni ključ, a podređena tabela je ona koja sadrži strani ključ. Tako, primarni ključ (recimo, Sif0org) postoji u tabeli ORG, a odgovarajući strani ključ istog tipa podataka i dužine, ali ne nužno i u koloni istog imena, postoji u tabeli RADNIK.

ORG

RADNIK

zapošljava

Je_zaposlen_u

Pravilo dodavanja

Pravilo dodavanja ( INSERT rule ) kazuje šta će se dogo diti ako pokušavate dodavanje vrednosti u strani ključ bez odgovarajuće vrednosti za primarni ključ u nadređenoj tabeli. Postoje sva aspekta ovog pravila:

• Nikada se ne dozvoljava dodavanje sloga u zavisnoj tabeli sa vrednošću stranog ključa

koji se ne poklapa sa vrednošću primarnog ključa. Ovo je poznato kao restriktivo pravilo

dodavanja

• Da li se strvarne vrednosti moraju biti zadate umesto Null ?

59

Administrator baze podataka mora da za svaku vezu odluči da li se vrednost(i)stranog ključa moraju navesti kada se slog upisuje u tabelu. Da bi to utvrdio, treba da postavi sledeće pitanje: „Da li u poslovnom procesu ima smisla poznavati vrednosti primarnog ključa u nadređenoj tabeli kada dodajem slog u podređenoj tabeli.?“ Pravilo ažuriranja

Glavna svrha pravila ažuriranja je kontrola izmena u bazi ,kao što je zabrana ažuriranja vrednosti stranog ključa na vrednost koja se ne poklapa sa vrednošću primarnog ključa u nadređenoj tabeli. Ovo pravilo se može sagledati iz dva ugla: iz perspektive primarnog ključa i perspektive stranog ključa. Perspektiva stranog ključa Kada slogu dodelite vrednosti staranog kluča, bilo prilikom dodeljivanja ili kasnije , morate odlučiti da li se ta vrednost može menjati. Ali, da napomenemo još jednom, to je određeno poslovnom definicijom veze i tabela koja su njome spojene. Perspektive primarnog kluča Kada se vrednost primarnog ključa promeni, posto tri načina ožuriranja odgovarajućeg stranog ključa:

• RESTRIKTIVNO AŽURIRANJE (UPDATE RESTRICT) Izmena podataka u kolonama

primarnog ključa kada postoji odgovarajući strani ključ nije dozvoljena.

• NEUTRALIZACIJA AŽURIRANJA (UPDATE NEUTRALIZE) Sve vrednosti stranog ključa koje

su jednake promenivoj vrednosti primarnog ključa se postavljaju na Null. Naravno,ovo

zahteva da Null bude dozvoljen za kolone stranog ključa.

• KASKADNO AŽURIRANJE (UPDATE CASCADE) Sve vrednosti stranog ključa koje su

jednake promenjivoj vrednosti primarnog ključa ažuriraju se na novu vrednost

primarnog ključa.

Pravilo brisanja

Pravilo referencijalnog integriteta za brisanje definiše šta se dešava kada se pokuša brisanje sloga iz neodređene tabele. Slično perspektivi primarnog ključa za ažuriranje za ažuriranje, postoje tri opcije kada se briše slog iz nadređene tabele:

• RESTRIKTIVNO BRISANJE (DELETE RESTRICT) Brisanje sloga primarnog ključa nije

dozvoljeno ako postoje iste vrednosti stranog ključa.

• NEUTRALIZACIJA BRISANJA (DELETE NEUTRALIZE) Sve vrednosti stranog ključa jednake

primarnom ključu se postavljaju na Null kada se primarni ključ obriše.

• KASKADNO BRISANJE (DELETE CASCADE) Svi slogovi sa vrednošću stranog ključa

jednakom primarnom ključu brišu se zajedno sa slogovima primarnog ključa.

Uslovno brisanje

Ovo je poslednji tip referencijalnog ograničenja. Ovaj specijalni slučaj se odnosi na rukovanje slogovima u nadređenoj tabeli kada u podređenoj tabeli ne postoje slogovi sa odgovarajućom vrednošću stranog ključa. Uslovljeno brisanje nalaže da se slog u nadređenoj tabeli obriše nakon što se obriše poslednja vrednost stranog ključa za određeni primarni ključ. Pogledajte tabelu 13.1. za sumarne karakteristike referencijalnog integriteta i pravila koja se primenjuju u aplikacijama koje ih održavaju.

Tabela 5.1: Pravila referencijalnog integriteta

60

Restriktivno brisanje Ako postoje slogovi u podređenoj tabeli, slog primarnog ključa u nadređenoj tabeli se ne može brisati

Kaskadno brisanje Ako postoje slogovi u podređenoj tabeli , slog primarnog ključa se briše, kao i svi zavisni slogovi u podređenoj tabeli.

Neutralizacija brisanja Ako postoje slogovi u podređenoj tabeli, slog primarnog ključa se briše, a kolone stranih ključeva za sve zavisne slogove se postavljaju na Null

Restriktivno ažuriranje Ako potoje slogovi u podređenoj tabeli, kolone primarnog ključa nadređene tabele se ne mogu ažurirati.

Kaskadno ažuriranje Ako postoje slogovi u podređenoj tabeli , kolone primarnog ključa nadređene tabele se ažuriraju, a sve vrednosti stranog ključa u podređenoj tabeli se ažuriraju na istu vrednost.

Neutralizacija ažuriranja Ako postoje slogovi u podređenoj tabeli, kolone primarnog ključa nadređene tabele se ažuriraju, a sve vrednosti stranog ključa u podređenoj tabeli se postavljaju na Null.

Restriktivno upisivanje vrednost stranog ključa se ne može upisati u podređenu tabelu sve dok ta vrednost primarnog ključa ne postoji u nadređenoj tabeli.

Postavljanje relacija

Deklarativno referencijalno ograničenje se dodaje kodiranjem primarnog ključa u nadređenoj tabeli i jednog od stranih ključeva u podređenim tabelama. Ograničenja se mogu zadati korišćenjem naredbi CREATE TABLE i AFTER TABLE. Kada primenjujemo deklarativni referencijalni integritet između nadređene i podređene tabele, moraju se poštovati određena pravila. Za nadređenu tabelu :

• Mora se definisati primarni ključ u naredbama CREATE TABLE ili ALTER TABLE.

• SQL Server automatski definiše jedinstveni grupisani indeks za primarni ključ kada se on

pojavi u naredbama CREATE TABLE ili ALTER TABLE. Ostali SUBP, na primer DB2

zahtevaju da administrator baze podataka ručno kreira jedinstveni indeks da bi podržao

primarni ključ

Za podređenu tabelu

• Strani ključ koji se odnosi na neodređenu tabelu se mora definisati u naredbama

CREATE TABLE ili ALTER TABLE.

• Iako obično nije potrebno , vrlo je preporučljivo da se kreira indeks i za strane ključeve.

On neće biti jedinstven sve dok ne definiše vezu jedan-prema-jedan za njega.

Ostala pitanja primene referencijalnog integriteta

Ponekad se referencijalni integritet mora definisati nad jednom tabelom. Na primer, tabela organizacionih jedinica firme možda mora obezbediti informacije o tome koja jedinica je podređena drugoj. Kolona Nadređena_Sif0rg može biti strani ključ primarnog ključa Sif0rg-i sve to unutar jedne tabele. Tabela je sposobna da ukazuje sama na sebe u deklarativnom referencijalnom ograničenju. To se naziva referencijalno ograničenje prema sebi. Zadata ograničenja se proveravaju pre nego što se okidači izvrše. Ako deklarativna ograničenja referencijalnog integriteta postoje nad istim tabelama, pazite da su kompatibilna jedna prema drugima.

61

Podrška SUBP-a referencijalnom integritetu

Imajte na umu da različiti sistemi podržavaju različite nivoe deklarativnog referencijalnog integriteta i različite opcije za njegovo korišćenje. Administrator baze podataka mora znati koje opcije su podržane od strane sistema da bi ukazao programerima aplikacija na to šta je podržano od strane sistema , a šta mora kodirati u aplikaciji. Korišćenje okidača za održavanje referencijalnog integriteta

Ako SUBP koji koristite ne podržavaju dovoljno opcija deklarativnog referencijalnog integriteta koji se zahteva, umesto njega se moraju kreirati okidači. Korišćenjem okidača moguće je podržati sva poslovna pravila referencijalnog integriteta. Naravno, njihovo korišćenje zahteva pisanje proceduralnog koda za svako pravilo svakog ograničenja . Kompletan referencijalni integritet se može podržati sa četiri tipa okidača za svako ograničenje:

1. DELETE okidač se može koristiti za kodiranje

• Restriktivnog brisanja,

• Kaskadnog brisanja

• Neutralizacije brisanja.

2. UPDATE okidačse može koristiti za kodiranje

• Restriktivnog ažuriranja

• Kaskadnog ažuriranja

• Neutralizacije ažuriranja

3. INSERT OKIDAČ se može koristiti u podređenoj tabeli za kodiranje

• Restriktivnog dodavanja

4. UPDATE okidači se može koristiti na podređenoj tabeli da zabrani ažuriranje stranog

ključa na vrednost koja ne postoji u koloni primarnog ključa nadređene tabele.

Ugnježdeni i rekurzivni okidači se zaista mogu koristiti za robusnu implementaciju referencijalnog integriteta. Osim toga, okidači mogu biti i jedini automatski metod za implementaciju integriteta kojom upravlja sam sistem, pod određenim okolnostima:

• Kada se obrisanim, ažuriranim ili dodatnim informacijama treba pristupiti da bi se na

osnovu toga odredila dalja akcija. Okidači obezbeđuju metode za to,

• Kada je potrebna primena referencijalnog integriteta koji nije podržan od strane

sistema. Na primer, Sybase podržava samo deklarativni referencijalni integritet

restriktivnog brisanja i restriktivnog ažuriranja; DB2 podržava restriktivno brisanje,

restriktivno ažuriranje, neutralizaciju brisanja i ažuriranja, kaskadno brisanje ,ali ne i

kaskadno ažuriranje.

• Kada se zahteva uslovljeno brisanje .To se ponekad i naziva „reverzni“ referencijalni

integritet, a podrazumeva da se nadređeni slog mora obriati kada se poslednji zavisni

slog iz podređene tabele obriše.

Pogledajmo neke primere okidača da bisno razjasnili kako se pravilno koriste prelazne tabele i promenjive. Sledeći ( SQL Server ) okidač obezbeđuje pravila kaskadnog brisanja: CREATE TRIGGER brisanje_naslova ON Naslovi FOR DELETE AS IF @@ROWCOUNT=0 RETURN

62

DELETE AutorNaslova FROM AutorNaslova, Deleted, Naslov WHERE Naslov.ID_Naslov=Deleted.ID_Naslova RETURN Kada se slog u nadređenoj tabeli ( Naslov ) obriše, kaskadno se brišu slogovi u podređenoj tabeli ( AutorNaslova). Drugi primer pokazuje pravilo restriktivnog upisivanja. Kada se upiše slog u podređenu tabelu ( AutorNaslova ), prvo se mora proveriti da li ta vrednost postoji kao primarni ključ u nadređenoj tabeli ( Naslov ): CREATE TRIGGER upis_naslova ON AutorNaslova FOR INSERT AS DECLARE @rc int SELECT @rc = @@rowcount IF @rc=0 RETURN IF ( SELECT count (*) FROM Naslov, Inserted WHERE Naslov.Id_Naslov=Inserted.ID_Naslova) != @rc BEGIN RAISERROR 20001 “Neispravan naslov:ID_Naslova ne postoji u tabeli Naslovi !” ROLLBACK TRANSACTION RETURN END RETURN Poslednji primer ( SQL Server ) prikazuje neutralizaciju ažuriranja: CREATE TRIGGER Naslov_Azurir ON Naslovi FOR UPDATE AS IF UPDATE ( ID_Naslovi ) IF (SELECT count (*) FROM Deleted, Naslov WHERE Deleted.ID_Naslova =Naslov.ID_Naslova)=0 BEGIN UPDATE AutorNaslova SET AutorNaslova.IDNaslova=Null FROM AutorNaslova, Deleted WHERE AutorNaslova.ID_Naslova=Deleted.ID_Naslova END RETURN.