Sveučilište u Zagrebu Fakultet prometnih znanosti Zavod za inteligentne transportne sustave Katedra za primijenjeno računarstvo

Transcription

1 Sveučilište u Zagrebu Fakultet prometnih znanosti Zavod za inteligentne transportne sustave Katedra za primijenjeno računarstvo Vježba: #12 Kolegij: Baze podataka Tema: Indeksiranje upita Vježbu pripremili: Mario Buntić, mag. ing. Upute za izradu vježbi/zadataka Vježbu je potrebno izraditi pomoću SQL Servera. Prije dolaska na vježbu potrebno je proučiti temu putem Internet izvora koja je na rasporedu. Vrijeme za izradu zadanih zadataka iznosi 90 minuta. Cilj vježbe Naučiti ubrzati vrijeme izvršavanja upita postavljanjem indeksa 1 stranica

2 Uvod Pristup SQL Serveru Podaci za pristup SQL Serveru su sljedeći: Authentication: [SQL Server Authentification] Login: sa Password: Baze123 Ubrzanje izvršavanja upita U nastavku slijedi kratki uvod što je optimizator upita, te što najčešće uzrokuje loše performanse upita. Optimizator upita Na slici je prikazano uobičajen slijed procesiranja SQL naredbe. Nama bitan dio je Optimizator upita i plan izvršavanja, na osnovu kojeg se kasnije i dohvaćaju podaci. Klikom na gumb unutar crvenog pravokutnika generira se procijenjeni plan izvršavanja za odabrani upit. Zelenom je prikazana opcija u kojoj se mogu podešavati opcije upita. Primjerice u postavkama upita moguće je uključiti statistiku upita pa je moguće saznati broj fizičkih i broj logičkih čitanja. Ljubičastom se uključuje/isključuje opcija uz pomoću koje je moguće nakon izvršavanja prikazati njen plan izvršavanja. Predefinirano je isključeno. 2 stranica

3 Uzroci loših performansi upita U nastavku su navedene situacije koje loše utiču na performanse SQL upita, a time i čitave aplikacije (izvor: Loše indeksiranje (eng. Poor indexing) može drastično utjecati na vrijeme izvršavanja upita, jer se prilikom izvršavanja upita pristupa većoj količini podataka što direktno dovodi do povećanog pristupa disku, korištenju memorije i procesora, a što direktno utječe na povećanje vremena izvršavanja upita. Netočna statistika (eng. Inaccurate Statistics) može značajno narušiti performanse upita. Naime, optimizator upita u okviru DBMS, na osnovu netočne statistike o distribuciji podataka, može donijeti pogrešnu procjenu o npr. broju zapisa koje upit treba vratiti, a koji je važan parametar optimizatoru za definiranje efikasnog plana izvršavanja upita. Previše međusobnog blokiranja transakcija i zastoja (eng. Excessive blocking and deadlocks) dovode do značajnog narušavanja performansi upita. Ukoliko dvije transakcije pristupaju istom podatku u tablici sa konfliktom (npr. jedna da čita, a druga transakcija ažurira podatak) dolazi do blokiranja jedne od transakcija i na taj način do čekanja ili vraćanja blokirane transakcije na ponovno izvršenje (eng. rollback). Blokiranje je normalna pojava pri izvršavanju upita, ali previše blokiranja može značajno narušiti performanse. Zastoj se događa kada dvije transakcije istovremeno blokiraju jedna drugu (jedna transakcija čeka završetak druge, a druga čeka završetak prve). Sistemi za upravljanje bazama podataka periodično traže zastoje te jednu od transakcija proglašavaju žrtvom i vraćaju je na početak izvršavanja. Operacije koje nisu zasnovane na radu sa skupovima podataka (eng. Non-Set- Based Operations), nego se zasnivaju na obradi podataka upotrebom kursora i petlji (umjesto join i subquery operacija), značajno mogu narušiti performanse upita, a samim tim i kompletne aplikacije. Loše postavljanje upita (eng. Poor Query Design) je najčešći razlog loših performansi upita, jer se željeni rezultat može dobiti definiranjem upita na više različitih načina, a neki od tih načina onemogućuju optimizator da upotrijebi adekvatan indeks i smanji vrijeme izvršavanja upita. Loša logička organizacija baze podataka (eng. Poor Database Design), odnosno nedovoljna ili prekomjerna normalizacija baze podataka, može negativno utjecati na vrijeme izvršavanja upita zbog nepotrebnog povećanja obujma podataka koje upit obrađuje, povećanja broja blokiranja upita ili povećanja broja join operacija. Naime, tablica koja nije normalizirana sadrži redundanciju podataka, pa se zbog toga povećava broj pristupa disku i broj međusobnog blokiranja transakcija, a prekomjerna normalizacija baze podataka po pravilu rezultira povećanjem broja join operacija u upitima (join operacija u upitu negativno utječu na performanse upita). 3 stranica

4 Plan izvršavanja upita koji se ne kešira (eng. Nonreusable Execution Plan) narušava performanse upita, jer optimizator upita DBMS troši određeno vrijeme za kreiranje plana izvršavanja upita i produžava ukupno vrijeme izvršavanja upita. Česta rekompalacija plana izvršavanja (eng. Frequent Recompilation Execution Plan) povećava vrijeme izvršavanja upita, jer se troši određeno vrijeme za rekompalaciju plana izvršavanja. Za izbjegavanje rekompalacije, plana izvršavanja upita mora biti nezavisan od parametara koji se prosljeđuju upitu prilikom izvršavanja, a to se najčešće postiže upotrebom spremljenih procedura (eng. stored procedures). Nepravilna upotreba kursora (eng. Improper Use of Cursors) povećava vrijeme izvršavanja upita. Upotrebom kursora u okviru upita podaci iz tablice se dohvaćaju red po red, a u DBMS su optimizirani za čitanje i obradu čitavih skupova redova. Ukoliko se kursori ipak moraju koristiti, onda treba voditi računa o tome da postoje različite vrste kursora koje različito utječu na povećanje vremena izvršavanja upita. Uključivanje statistike upita Kako bi mogli pratiti koliko je logičkih/fizičkih čitanja bilo potrebno da se dohvate neki podaci potrebno je uključiti statistiku. To se radi sljedećom naredbom SET STATISTICS IO ON Indeksi U SQL Serveru postoje 3 osnovna tipa indeksa: Klasterirani indeksi (engl. clustered indexes) Neklasterirani indeksi na klasteriranoj tablici (engl. non clustered index onclustered table) Neklasterirani indeksi na hrpi (engl. non clustered index on a heap) Ako tablica ima na sebi postavljen klasterirani indeks, smatramo je klasteriranom tablicom. Ako tablica na sebi nema postavljen klasterirani indeks, smatramo je hrpom. Postavljanje klasteriranog indeksa Svaka tablica može imati samo jedan klasterirani indeks. Reci na stranicama su fizički poslagani po tom indeksu. Ako drukčije nije specificirano, kreiranjem primarnog ključa na nekim stupcima implicitno se kreira i klasterirani indeks na tim stupcima. Pošto se primarni ključevi često koriste pri dohvatu podataka, postavljanjem klasteriranog indeksa njihov dohvat je brz. Preporuka je da svaka tablica ima na sebi klasterirani indeks. Primarni ključ je uvijek dobar kandidat za klasterirani indeks. Popis postavljenih indeksa može se pronaći unutar svake tablice kao što je prikazano na slici ispod. 4 stranica

5 Postavljanje neklasteriranih indeksa Svaka tablica može imati proizvoljan broj neklasteriranih indeksa. Postavljaju se nakon analize najčešćih upita koji koriste tablicu. Postavljaju se na stupce koji se najčešće koriste. Preporuka: obavezno ih staviti na strane ključeve (zbog spajanja) nije dobro da ih bude više od 5 Dobri za dohvaćanje manjeg broja redaka. Za dohvaćanje većeg broja redaka su jako štetni po performanse i optimizator ih neće izabrati. Kreiranje indeksa se radi sljedećom naredbom: CREATE [CLUSTERED NONCLUSTERED] INDEX <naziv_indeksa> ON <naziv_tablice> (<naziv_stupca>,...) [INCLUDE(<naziv_stupca>,...)] ALTER INDEX ne može promijeniti indeks već služi za njegovo održavanje, ali u taj dio nećemo ulaziti. Indeksi se brišu sljedećom naredbom: DROP INDEX <naziv_tablice>.<naziv_indeksa> Optimizacija upita pomoću indeksa Inače vrlo složen postupak, mi ćemo promatrati njegov maleni dio. Postupak je sljedeći: 1. Uključiti statistiku SET STATISTICS IO ON 2. Izvršiti upit i zabilježiti broj pretraženih stranica (engl. logical reads) 3. Optimizacija: a. Osigurati da svaka tablica ima klasterirani indeks b. Identificirati sve stupce koji sudjeluju u WHERE dijelu upita i jednog od njih izabrati za ključ neklasteriranog indeksa c. Sve ostale stupce koji su dio upita uključiti u indeks s INCLUDE. Ne zaboraviti da neklasterirani indeks u sebi automatski sadrži vrijednost klasteriranog indeksa ne ga dodavati ponovno! 4. Izvršiti upit i vidjeti je li došlo do poboljšanja 5 stranica

6 Primjer optimizacije jednog upita Uključivanje statistike SET STATISTICS IO ON Upit koji se optimizira SELECT Ime, Prezime FROM Kupac k WHERE Ime LIKE 'a%' Statistika upita (2014 row(s) affected) Table 'Kupac'. Scan count 1, logical reads 340, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Postavljanje indeksa CREATE NONCLUSTERED INDEX indeximeprezime ON Kupac (Ime) INCLUDE(Prezime) Statistika upita nakon indeksiranja (2014 row(s) affected) Table 'Kupac'. Scan count 1, logical reads 12, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 6 stranica

7 Zadaci 1. Uključite praćenje statistike. 2. Dohvatite imena kupaca čija imena počinju sa slovom 'a' i zapišite logička čitanja. 3. Postavite neklasterirani indeks "i1" na ime od kupca. 4. Dohvatite imena kupaca čija imena počinju sa slovom 'a' i zapišite logička čitanja. 5. Obrišite indeks "i1". 6. Dohvatite broj računa i datum izdavanja za sve račune čiji je datum izdavanja između ' ' i ' ' i zapišite logička čitanja. 7. Kreirajte indeks "i2" na DatumIzdavanja od računa sa uključenim stupcem BrojRacuna. 8. Dohvatite broj računa i datum izdavanja za sve račune čiji je datum izdavanja između ' ' i ' ' i zapišite logička čitanja. 9. Obrišite indeks "i2". 10. Kreirajte indeks "i3" na BrojRacuna od računa sa uključenim stupcem DatumIzdavanja. 11. Dohvatite broj računa i datum izdavanja za sve račune čiji je datum izdavanja između ' ' i ' ' i zapišite logička čitanja. 12. Obrišite indeks "i3". 13. S kojim neklasteriranim indeksom iz zadataka 7 i 10 se dobiva veće ubrzanje? 14. Za svaki KupcaID dohvatite koliko je puta kupovao u razdoblju od ' ' do ' ', sortirajte rezultate padajuće i zapišite logička čitanja. 15. Optimizirajte prethodni upit postavljanjem neklasteriranog indeksa "i4" na način da dobijete najveće ubrzanje. 7 stranica