UZDEVUMA NOSTĀDNE - Web viewIzskatīsim vaicājuma izpildi pa soļiem. Pirmajā rindā redzam, ka pavisam mums ir vairāk nekā 2 miljoni cilvēku datu bāzē. ... tiek vei. kta

Rīgas Tehniskā universitāteDatorzinātnes un Informācijas tehnoloģiju fakultāte

Informācijas tehnoloģijas institūts

„SQL optimizācija”

3.Praktiskais darbsPriekšmetā

Informācijas sistēmas un CASE rīki

Izstrādāja: Viktorija Raizina1DMIO-2 (ITI)

St.Apl.Nr. 051RDB278

Rīga, 2009

ANOTĀCIJA

Darbā ir izmantots pasniedzēja dotais piedāvātās datu bāzes gatavais piemērs MS Access vidē. Ir apskatītas vaicājumu plānu veidošanas un izgūšanas iespējas, kā arī ir sīki izpētīta SQL vaicājumu optimizācijas iespēja.

Praktiskā darba izpildes gaitā, piedāvātā datu bāze tiek nedaudz modificēta un tās dati tiek pārnesti uz *.txt failiem, kuri vēlāk tiek pārdēvēti par *.dat failiem. Pēc tam datu bāzes struktūra tiek izveidota Oracle 10G vidē un ar SQL*loader un izveidoto *.clt failu palīdzību – *.dat faili tiek ielādēti datu bāzē. Pēc tam tiek izveidoti 11 dažāda veida vaicājumi, un pieciem no tiem tiek izskatītas izpildāmās relāciju algebras operācijas. Visbeidzot – būtiskākajiem vaicājumiem (astoņiem) tiek iegūti izpildes plāni, izmantojot gan uz resursu analīzes bāzētu pieeju, gan uz likumiem bāzētu pieeju. Visbeidzot tiek realizēti trīs efektīvi ieteikumi, kā arī ir pārbaudīts tas, ka pastāv iespējamība nekorekti veikt ieteikumu, kas palielinās datora noslogotību, t.i. tiek realizēts viens papildus „neefektīvs” ieteikums. Darbā ir sniegts ieteikums tam, kā pareizi būtu jārealizē ieteikums tam vaicājumam, kuram tika realizēts ieteikums, kā arī ir sniegti paskaidrojumi neefektivitātes cēlonim. Kopumā, darbā tiek pielietoti ORDERED, INDEX, INDEX_COMBINED, USE_HASH, USE_MERGE un USE_NL ieteikumi.

Izpildītais darbs pilnībā apmierina uzdevuma nosacījumus. Visa darba gaita ir detalizēti attēlota, labākai darba gaitas izprašanai.

Darbs izstrādāts izmantojot datoru AMD Athlon 3000+, 1024MB DDR operatīvo atmiņu Windows XP Proffesional vidē.

Darba saturā ir 115 attēli, 2 tabulas, 7 nodaļas, secinājumi, saturs un literatūras avoti. Kopumā darbs ir izklāstīts 92 lappusēs.

2

SATURS1. UZDEVUMA NOSTĀDNE.........................................................................................................52. DATU BĀZEs IZVĒLE................................................................................................................63. DATU BĀZES IZVEIDE ORACLE 10G VIDĒ................................................................................7

3.1. Jaunas darba virsmas izveide..........................................................................................73.2. Tabulu izveide.................................................................................................................8

3.2.1. Tabula VALSTIS.........................................................................................................83.2.2. Tabula NODAĻAS......................................................................................................83.2.3. Tabula ALGAS...........................................................................................................83.2.4. Tabula PERSONAS....................................................................................................93.2.5. Pārbaude..................................................................................................................9

3.3. Datu ievade tabulās ar SQL*Loader palīdzību...............................................................103.3.1. Tabulas VALSTIS aizpilde........................................................................................113.3.2. Tabulas NODAĻAS aizpilde.....................................................................................123.3.3. Tabulas ALGAS aizpilde..........................................................................................143.3.4. Tabulas PERSONAS aizpilde....................................................................................153.3.5. Pārbaude................................................................................................................16

4. VAICĀJUMU REALIZĀCIJA.....................................................................................................194.1. Vaicājums „Select...From T”..........................................................................................194.2. Vaicājums „Select...From T Where...And/Or..”.............................................................194.3. Vaicājums „Select...From T1,T2 Where...”....................................................................214.4. Vaicājums ar „Having”...................................................................................................224.5. Vaicājums ar „Exists”.....................................................................................................224.6. Vaicājums ar „Group By Cube”......................................................................................234.7. Vaicājums ar klona tabulām un „Over”.........................................................................244.8. Vaicājums ar Hierarhiju.................................................................................................254.9. Vaicājums ar pakārtotu vaicājumu „FROM” rindā.........................................................264.10. Vaicājums ar pakārtotu vaicājumu „SELECT” rindā....................................................274.11. Vaicājums ar pakārtotu vaicājumu „HAVING” rindā..................................................27

5. VAICĀJUMIEM IZPILDAMĀS RELĀCIJU ALGEBRAS KOMANDAS...........................................295.1. Izpildāmās RA darbības vaicājumam ar „Having”..........................................................295.2. Izpildāmās RA darbības vaicājumam ar „Exists”............................................................305.3. Izpildāmās RA darbības vaicājumam ar „Group By Cube”.............................................315.4. Izpildamās RA darbības vaicājumam ar klona tabulām un „Over”................................325.5. Izpildamās RA darbības vaicājumam ar apakšvaicājumu „SELECT” rindā......................33

6. IZPILDES PLĀNU IEGŪŠANA UN ANALĪZE.............................................................................366.1. Izpildes plāns, komanda EXPLAIN PLAN un PLAN_TABLE..............................................366.2. Statistikas iegūšana.......................................................................................................396.3. Izpildes plāns vaicājumam ar „Select...From T1,T2 Where...”.......................................41

6.3.1. Statistikas iegūšana................................................................................................416.3.2. Izpildes plāna iegūšana, izmantojot statistiku (ALL_ROWS)...................................426.3.3. Izpildes plāna izgūšana un analīze..........................................................................426.3.4. Izpildes plāna iegūšana, izmantojot uz likumiem balstītu pieeju (RULE)................45

6.4. Izpildes plāns vaicājumam ar „Exists”............................................................................466.4.1. Statistikas iegūšana................................................................................................466.4.2. Izpildes plāna iegūšana, izmantojot statistiku (ALL_ROWS)...................................476.4.3. Izpildes plāna izgūšana un analīze..........................................................................476.4.4. Izpildes plāna iegūšana, izmantojot uz likumiem balstītu pieeju (RULE)................49

6.5. Izpildes plāns vaicājumam ar „Group by Cube”.............................................................513

6.5.1. Statistikas iegūšana................................................................................................516.5.2. Izpildes plāna iegūšana, izmantojot statistiku (ALL_ROWS)...................................516.5.3. Izpildes plāna izgūšana un analīze..........................................................................526.5.4. Izpildes plāna iegūšana, izmantojot uz likumiem balstītu pieeju (RULE)................53

6.6. Izpildes plāns vaicājumam ar „Over”.............................................................................546.6.1. Statistikas iegūšana................................................................................................546.6.2. Izpildes plāna iegūšana, izmantojot statistiku (ALL_ROWS)...................................556.6.3. Izpildes plāna izgūšana un analīze..........................................................................556.6.4. Izpildes plāna iegūšana, izmantojot uz likumiem balstītu pieeju (RULE)................58

6.7. Izpildes plāns vaicājumam ar Hierarhiju........................................................................596.7.1. Statistikas iegūšana................................................................................................596.7.2. Izpildes plāna iegūšana, izmantojot statistiku (ALL_ROWS)...................................596.7.3. Izpildes plāna izgūšana un analīze..........................................................................606.7.4. Izpildes plāna iegūšana, izmantojot uz likumiem balstītu pieeju (RULE)................61

6.8. Izpildes plāns vaicājumam ar pakārtotu vaicājumu „FROM” rindā...............................636.8.1. Statistikas iegūšana................................................................................................636.8.2. Izpildes plāna iegūšana, izmantojot statistiku (ALL_ROWS)...................................636.8.3. Izpildes plāna izgūšana un analīze..........................................................................646.8.4. Izpildes plāna iegūšana, izmantojot uz likumiem balstītu pieeju (RULE)................65

6.9. Izpildes plāns vaicājumam ar pakārtotu vaicājumu „SELECT” rindā..............................676.9.1. Statistikas iegūšana................................................................................................676.9.2. Izpildes plāna iegūšana, izmantojot statistiku (ALL_ROWS)...................................676.9.3. Izpildes plāna izgūšana un analīze..........................................................................686.9.4. Izpildes plāna iegūšana, izmantojot uz likumiem balstītu pieeju (RULE)................69

6.10. Izpildes plāns vaicājumam ar pakārtotu vaicājumu „HAVING” rindā.........................716.10.1. Statistikas iegūšana............................................................................................716.10.2. Izpildes plāna iegūšana, izmantojot statistiku (ALL_ROWS)...............................716.10.3. Izpildes plāna izgūšana un analīze......................................................................726.10.4. Izpildes plāna iegūšana, izmantojot uz likumiem balstītu pieeju (RULE)............73

7. IETEIKUMU REALIZĒŠANA....................................................................................................757.1. Izveidotie indeksi...........................................................................................................757.2. Optimizatora konfigurēšana (CHOOSE).........................................................................767.3. Ieteikumu realizācija vaicājumam ar „Exists”................................................................767.4. Ieteikumu realizācija vaicājumam ar „Over”.................................................................797.5. Ieteikumu realizācija vaicājumam ar pakārtotu vaicājumu „FROM” rindā....................827.6. Ieteikumu realizācija vaicājumam ar „Select...From T1,T2 Where...”...........................85

SECINĀJUMI.................................................................................................................................89IZMANTOTIE AVOTI..................................................................................................................... 92

4

1. UZDEVUMA NOSTĀDNE

Jāizveido datubāze (izmantojot pasniedzēja piedāvāto datu bāzi MS Access vidē): Struktūras izveide Oracle vidē; Datu ievade;

Jāizpilda vaicājumu realizācija: Select ... from T (1 tabula); Select ... from T where.. and/or...; (1 tabula + noteikumi); Select ... from T1, T2 ... (vairākas tabulas); * Vaicājumi, izmantojot:

o Having;o Exists; *o Group by Cube; *o Over (klona tabulas); *

Hierarhiskais vaicājums; * Pakārtotie vaicājumi:

o From rindā; *o Select rindā; *o Having rindā; *

5 vaicājumiem ir jārealizē izpildāmās Relāciju Algebras komandas; Jāiegūst izpildes plāni būtiskākajiem vaicājumiem (atzīmēti ar ‘*’) un tie jāanalizē; Jārealizē vismaz 3 ieteikumi; Jāsniedz secinājumi par izpildītā darba rezultātiem.

5

2. DATU BĀZES IZVĒLE

Pēdējā darba izpildei tika izmantota pasniedzēja piedāvātā datu bāze MS Access vidē, kuras izmēri pārsniedz 800MB. Izmantojot šādu datu bāzi, būs iespējams redzēt, cik lēni strādā liela izmēra datu bāzes, kuru tabulās mēdz būt vairāki desmiti tūkstoši vai pat miljoni ierakstu. Tātad, tiek izmantota datu bāze, kurā ir sekojošas tabulas: Valstis, Personas, Nodaļas un Algas.

Gribētu piebilst to, ka piedāvātā datu bāze tika nedaudz izmainīta sakarā ar to, ka tajā pirms tam nav bijušas saites un tabulu ALGAS nebija iespējams saistīt ne ar vienu no tabulām, jo nedz tajā, nedz arī uz to ir bijušas kādas atsauces vai saites. Līdz ar to, pievienoju tabulā ALGAS ārējo atslēgu no tabulas NODAĻAS, kura veido saites definējumu, atbildot uz jautājumu – kura nodaļa izdod noteikto algu. Protams, varēja veidot datu bāzes zvaigznes struktūru, ievietojot atsauci uz algām tabulā PERSONAS, taču tas būtu, pirmkārt, ļoti neloģiski, jo tā kā tabulā ALGAS ir informācijas par darba sākuma, beigu datumiem, vidējo algo un faktisko algu, tad diez vai vairāki cilvēki varētu vienlaicīgi atbilst vienam ierakstam no ALGU tabulas; otrkārt, tabulas PERSONAS ierakstu skaits pārsniedz divus miljonus, tādējādi, kolonnas aizpildīšana aizņemtu nenormāli daudz laika. Tādējādi, tika izveidota datu bāzes struktūra, ko var apskatīt 2.1.attēlā.

2.1.att. Realizējamās datu bāzes struktūra

SQL optimizācijai, lai novērtētu ātrdarbību, ir nepieciešams daudz datu, līdz ar to, šāda iespēja tagad būs nodrošināta.

Pēc vajadzīgās struktūras izveidošanas, tabulu dati tika eksportēti *.TXT formātā, kuri vēlāk tiks ielādēti tabulās ar SQL*Loader palīdzību. Taču sākumā izveidosim darba virsmu un tabulas ORACLE 10g vidē.

6

3. DATU BĀZES IZVEIDE ORACLE 10G VIDĒ

Jaunas darba virsmas izveide

Strādājot pie trešā praktiskā darba, atkal nolēmu izveidot jaunu darba virsmu un jaunu lietotāju, lai, izgūstot meta datus, datu bāzē neattēlotos iepriekš izveidotās tabulas. Tātad, izveidojam lietotāju „CASE3”, ar paroli „vika”, kā arī piešķiram lietotajam visas privilēģijas un izveidojam darba virsmu.

Vispirms ielogojamies SQL*Plus kā lietotājs SYSTEM ar paroli MANAGER. Tad izveidojam jaunu tabulas telpu ar nosaukumu „SQL_OPT”, izmantojot „CREATE TABLESPACE” (skat. 3.1.1.att.).

3.1.1.att. Jaunas tabulas telpas izveidošana

Tālāk izveidojam lietotāju „CASE3” ar paroli „vika”. Ar šo lietotāja vārdu varēs brīvi rīkoties tabulas telpā „SQL_OPT”. Lai lietotājs būtu lietojams, tam jāpiešķir privilēģijas (PRIVILEGES). Šim lietotājam piešķiram visas privilēģijas, lai nerastos liekas problēmas (skat. 3.1.2.).

3.1.2.att. Jauna lietotāja izveide

Pateicoties tam, ka es izveidoju sev atsevišķu lietotāju, es panākšu tādu rezultātu, ka tad, kad es vēlēšos attēlot visas tabulas, kuras ir datu bāzē, man rastos grūtības, ja es to darītu kā lietotājs „system”. Ja es taisītu savus tabulas kā lietotājs SYSTEM un pēc tam izpildītu komandu SELECT * FROM user_tables, es saņemtu visu tabulu aprakstu, kuras pieder lietotājam SYSTEM

7

un ir atrodamas datu bāzē. Tas radītu zināmas grūtības īsto tabulu atrašanai. Taču tagad man būs iespējams aplūkot tikai tās tabulas, kuras es izveidoju.

Tabulu izveide

Tā kā mums ir eksportēti dati, ko saturēs tabulas, no MS Access, tad mums ir nepieciešams izveidot tabulas, lai tajās varētu ielādēt eksportētos datus.

Tātad secīgi izveidosim visas tabulas.

3.1.1. Tabula VALSTIS

Izveidosim tabulu Valstis, kurā glabāsies informācija par valstu nosaukumiem, to starptautiskajiem apzīmējumiem un arī pilsonības nosaukumu katrā valstī (skat. 3.2.1.1.att.).

3.2.1.1.att. Tabulas Valstis izveide

Tagad pārejam pie nākošās tabulas izveides.

3.1.2. Tabula NODAĻAS

Izveidosim tabulu Nodaļas, kurā glabāsies informācija par dažādām valsts struktūrām (skat. 3.2.2.1.att.).

3.2.2.1.att. Tabulas Nodaļas izveide

Tagad pārejam pie nākošās tabulas izveides.

3.1.3. Tabula ALGAS

Izveidosim tabulu Algas, kurā glabāsies informācija par darba sākšanas datumu, beigšanas datumu, faktisko un vidējo algas summu. Šī tabula atsauksies uz tabulu Nodaļas, norādot to, kura nodaļa izmaksā noteikto algu (skat. 3.2.3.1.att.).

8

3.2.3.1.att. Tabulas Algas izveide

Tagad pārejam pie pēdējās tabulas izveides.

3.1.4. Tabula PERSONAS

Izveidosim tabulu Personas, kura glabās informāciju par dažādām personām, kā arī atsauksies uz tabulām Valstis, norādot personas piederību kādai valstij, kā arī uz tabulu Nodaļas, norādot to, kurai nodaļai konkrētā persona ir piesaistīta (skat. 3.2.4.1.att.).

3.2.4.1.att. Tabulas Nodaļas izveide

3.1.5. Pārbaude

Tagad, kad ir izveidotas visas tabulas, varam mēģināt ar vaicājuma palīdzību pārbaudīt tabulu esamību datubāzē, vēršoties pie meta datiem (skat. 3.2.5.1.att.).

9

3.2.5.1.att. Datu pārbaude datubāzē

Tagad, kad esam pārliecinājušies par to, ka tabulas ir patiesi izveidotas datubāzē, mēģināsim ar SQL*Loader ievadīt eksportētos datus.

Datu ievade tabulās ar SQL*Loader palīdzību

Savā darbā datu ievadei izmantoju īpašu rīku – SQL* Loader (sqlldr), kas ir ļoti noderīgs, kad tabulās jāievada lieli datu apjomi, datubāzē ievadāmā informācija var glabāties jebkurā teksta formāta failā. SQL* Loader struktūra apskatāma 3.3.1.attēlā.

3.3.1.att. SQL*Loader arhitektūra

SQL* Loader vadības fails:Parasti šis fails ir ar paplašinājumu CTL (Control file), un šī datne ir jebkura ielādes

procesa pamatā. Ar vadības faila palīdzību iespējams nodefinēt sekojošu informāciju: Datu faila no kā tiks ņemti dati nosaukumu un atrašanās vietu, Tabulas ierakstu struktūru, Datubāzes tabulas nosaukums, Kļūdu un atcelšanas failu nosaukumus un atrašanās vietas Utt.

Vairākas no iepriekš aplūkotajām īpašībām var arī uzdot palaižot SQL*Loader kā komandrindas parametrus, piemēram, datu faila nosaukums un atrašanās vieta u.tml.

10

Vadības failā arī var atrasties pat datubāzes tabulā ielādējamie ieraksti, tādējādi atkrīt datu failu izveides process, kā arī failu daudzums.

SQL* Loader LOG fails:Parasti šis fails ir ar paplašinājumu LOG un satur informāciju par datu ielādes procesu un

tā rezultātiem, piemēram: Datu, vadības, kļūdu, atcelšanas failu vārdus, Kļūdu ziņojumus, Ziņojumi, kad ieraksti nav tikuši atrasti, Ierakstu ielādes procesa gaita, Datu ielādes laiku, Utt.

Ļoti noderīgs fails, kas palīdz operatīvi atrast darba izpildes gaitā pieļautās kļūdas, kā aplūkot statistikas informāciju.

Kļūdu faili:Pie datu ievades reizēm gadās ka nav iespējams veikt šo operāciju, jo tikušas

pieļautas kaut kādas kļūdas, kļūdainais ieraksts, kas nav ticis ievadīts datubāzes tabulā arī glabājas šajā failā(paplašinājums *.BAD).

Darba tālākajā gaitā veiksim no MS Access eksportēto datu ielādi izveidotajās tabulās.

3.1.6. Tabulas VALSTIS aizpilde

Pirmais solis, kas jāpaveic ir izveidot vadības failu. Darba gaitā tika izveidots vadības fails VALSTIS.CTL (skat. 3.3.1.1.att.).

3.3.1.1.att. Vadības faila VALSTIS.ctl saturs

Kā redzams ar šo vadības failu ir norādīts, ka ir nepieciešams ielādēt datus. Kā datu avots tiks izmantots datu fails VALSTIS.DAT (skat 4.1.1.att.), faili tiks ielādēti datubāzes tabulā VALSTIS, lauki viens no otra tiks atšķirti ar semikola simbolu, pašās beigās norādīta datubāzes tabulas struktūra, kuru esam nodefinējuši pie katras tabulas definējumiem.

Līdz ar to nākamais solis būs izveidot datu failu no kura tiks ņemti dati. No MS Access eksportētos TXT failus vienkārši saglabājam *.DAT formātā. Rezultātā tika iegūts VALSTIS.DAT (skat. 3.3.1.2.att.).

11

3.3.1.2.att. Datu faila VALSTIS.DAT saturs

Tā kā datu apjoms ir liels, tad faila attēlošanai tiek parādīts tikai neliels faila apjoms.Viss ir sagatavots tam, lai palaistu SQL*Loader un sāktu datu ievadi tabulā. Rīks tiks

atvērts, izmantojot komandrindas redaktoru.Tagad veiksim datu ievadi no VALSTIS.DAT uz tabulu VALSTIS.Ierakstīsim komandrindā sekojošu izteiksmi: SQLLDR control=valstis.ctl (skat. 3.3.1.3.att.).Kad tas būs izdarīts, tad mums nāksies pievienoties attiecīgajai datubāzei, proti, tiks

pieprasīts ievadīt lietotāja vārdu un parole. Pēc tam sāksies datu ievade, kā rezultātā lietotājam tiks arī izvadīts attiecīgs paziņojums par tabulai pievienoto ierakstu skaitu.

3.3.1.3.att. Datu ievade tabulā VALSTIS

Diemžēl, kaut kas ir noticis ar komandrindas valodu (iespējams dēļ tā, ka uz mana datora uzstādītā operētājsistēma ir krievu valodā), taču pēc iegūtā attēla var redzēt ielādēto rindu skaitu (43), kas arī ir tāds ierakstu skaits, kāds bija izveidots MS Access vidē. Automātiski arī pēc komandas izpildes ir ticis uzģenerēts VALSTIS.LOG fails, kurā ir iespējams iegūt informāciju par visiem ielādētiem vai neielādētiem ierakstiem, saņemot arī paskaidrojumu kādas rindas neielādēšanas cēlonim.

3.1.7. Tabulas NODAĻAS aizpilde

Tagad jāievada arī dati tabulā NODAĻAS. Šim nolūkam atkal tiek izveidots vadības fails (skat. 3.3.2.1.att.)

12

3.3.2.1.att. Vadības faila NODALAS.ctl saturs

Savā uzbūvē šis fails ir līdzīgs iepriekš apskatītajam CTL failam. Datu fails arī izskatīsies līdzīgs iepriekšējam datu failam (skat. 3.3.2.2.att.).

3.3.2.2.att. Datu faila NODALAS.DAT saturs

Tagad atkal ir jāveic datu ievade ar SQL*Loader, ievadot komandrindā komandu: SQLLDR control=NODALAS.ctl (skat. 3.3.2.3.att.).

3.3.2.3.att. Datu ievade tabulā NODAĻAS

Pēc iegūtā attēla var redzēt ielādēto rindu skaitu (40), kas arī ir tāds ierakstu skaits, kāds bija izveidots MS Access vidē. Automātiski arī pēc komandas izpildes ir ticis uzģenerēts NODALAS.LOG fails, kurā ir iespējams iegūt informāciju par visiem ielādētiem vai neielādētiem ierakstiem, saņemot arī paskaidrojumu kādas rindas neielādēšanas cēlonim.

13

3.1.8. Tabulas ALGAS aizpilde

Tagad jāievada arī dati tabulā ALGAS. Šim nolūkam atkal tiek izveidots vadības fails (skat. 3.3.3.1.att.)

3.3.3.1.att. Vadības faila ALGAS.ctl saturs

Savā uzbūvē šis fails ir līdzīgs iepriekš apskatītajam CTL failam, taču šeit mēs papildus definējam arī datuma formātu, kādā ir jāielādē dati.

Datu fails arī izskatīsies līdzīgs iepriekšējam datu failam (skat. 3.3.3.2.att.).

3.3.3.2.att. Datu faila ALGAS.DAT saturs

Tagad atkal ir jāveic datu ievade ar SQL*Loader, ievadot komandrindā komandu: SQLLDR control=ALGAS.ctl (skat. 3.3.3.3.att.).

3.3.3.3.att. Datu ievade tabulā ALGAS

Pēc iegūtā attēla var redzēt ielādēto rindu skaitu (27459), kas arī ir tāds ierakstu skaits, kāds bija izveidots MS Access vidē. Automātiski arī pēc komandas izpildes ir ticis uzģenerēts

14

ALGAS.LOG fails, kurā ir iespējams iegūt informāciju par visiem ielādētiem vai neielādētiem ierakstiem, saņemot arī paskaidrojumu kādas rindas neielādēšanas cēlonim.

3.1.9. Tabulas PERSONAS aizpilde

Tagad jāievada arī dati tabulā PERSONAS. Šim nolūkam atkal tiek izveidots vadības fails (skat. 3.3.4.1.att.)

3.3.4.1.att. Vadības faila PERSONAS.ctl saturs

Savā uzbūvē šis fails ir līdzīgs iepriekš apskatītajam CTL failam. Datumu šeit nedefinējam, tas paliek kā parastais number tipa ieraksts, jo MS Access Datu bāzē šie datumi bija ģenerēti ar citas papildprogrammatūras palīdzību, līdz ar to, tie neatbilst datumu noteikumiem (mēnešu skaits gadā, dienu skaits mēnesī, u.c.). Datu fails arī izskatīsies līdzīgs iepriekšējam datu failam (skat. 3.3.4.2.att.).

3.3.4.2.att. Datu faila PERSONAS.DAT saturs

Tagad atkal ir jāveic datu ievade ar SQL*Loader, ievadot komandrindā komandu: SQLLDR control=PERSONAS.ctl (skat. 3.3.4.3.att.).

15

3.3.4.3.att. Datu ievade tabulā PERSONAS

Pēc iegūtā attēla var redzēt ielādēto rindu skaitu (2448813), kas arī ir tāds ierakstu skaits, kāds bija izveidots MS Access vidē. Automātiski arī pēc komandas izpildes ir ticis uzģenerēts PERSONAS.LOG fails, kurā ir iespējams iegūt informāciju par visiem ielādētiem vai neielādētiem ierakstiem, saņemot arī paskaidrojumu kādas rindas neielādēšanas cēlonim.

Gribētu arī piebilst to, ka datu ielāde notika vairākas minūtes, lielā apjoma dēļ, tieši tādēļ SQL*Loader ir patiešām noderīgs papildrīks, šāda datu apjoma ielādei, jo tad, ja to darītu ar INSERT palīdzību, tas ilgtu iespējams ja ne vairākas dienas, tad veselu dienu noteikti.

3.1.10. Pārbaude

Kad ir paveikta datu ievade tabulās, tad, lai pārbaudītu ievadīto datu korektumu, būtu jāizpilda daži vaicājumi.

Tagad veiksim pārbaudi tam, vai dati ir ievadīti tabulās. Pēc kārtas apskatīsim visas tabulas.

Izvadītie datu saturs ir diezgan liels, kas, protams, neietilpst viena SQL PLUS ekrāna logā, līdz ar to, to nav vērts atspoguļot. Bez tam šeit tiek veikta pārbaude tam, vai dati patiešām ievadīti tabulās. Un tā tas tiešām ir.

Tabulas VALSTIS saturs ir apskatāms 3.3.5.1.att.

3.3.5.1.att. Tabulas VALSTIS saturs16

Dati ir tabulā. Pārbaudīsim arī tabulu NODAĻAS (skat. 3.3.5.2.att.).

3.3.5.2.att. Tabulas NODAĻAS saturs

Dati ir tabulā. Pārbaudīsim arī tabulu ALGAS (skat. 3.3.5.3.att.).Tā kā datu apjoms ir ļoti liels, ko nevar pilnībā atspoguļot SQL*Plus ekrānā, kā arī ekrāna

buferis neļauj saglabāt visu datu apskati par ar ‘scroll bar’ palīdzību, tad definēsim vaicājumu, ar kuru tiek veikta tabulas satura pārbaude - Select * from ALGAS:

3.3.5.3.att. Tabulas ALGAS saturs

17

Dati ir tabulā. Bez tam, varam redzēt arī to, ka datumi ir atspoguļojušies pareizajā formātā, neskatoties uz to, ka datu failā tie bija ievadīti vienkārši kā ciparu virkne. Tabulas ALGAS vaicājuma izpilde notikusi apmēram 20 minūšu laikā, kamēr visi dati tika attēloti.

Pārbaudīsim arī tabulu PERSONAS (skat. 3.3.5.4.att.).Tā kā datu apjoms ir ļoti liels, ko nevar pilnībā atspoguļot SQL*Plus ekrānā, kā arī ekrāna

buferis neļauj saglabāt visu datu apskati par ar ‘scroll bar’ palīdzību, tad definēsim vaicājumu, ar kuru tiek veikta tabulas satura pārbaude - Select * from PERSONAS:

3.3.5.4.att. Tabulas PERSONAS saturs

Iespējams, šāda datu pārbaudes rīcība nebija „gudra” no manas puses, jo nogaidot 45 minūtes, es pārtraucu vaicājuma izpildi (tādēļ nav izvēlēti visi dati), taču mēs vismaz pārliecinājāmies, ka tabulā dati ir ievadīti.

Tieši šādos gadījumos varam secināt, ka ir nepieciešama SQL vaicājumu optimizācija, ātrdarbības palielināšana, jo ne vienmēr ir tik daudz laika, lai sagaidītu viena vai otra vaicājuma izpildi.

Tātad, tagad, kad datu bāze ir izveidota un dati ievadīti, varam sākt dažādu vaicājumu realizēšanu, lai redzētu, cik tad ilgi tie realizēsies, pāršķirstot vairākus miljonus ierakstu.

18

4. VAICĀJUMU REALIZĀCIJA

Izveidosim vairākus vaicājumus, kurus vēlāk, darba gaitas ietvaros, analizēsim. Izveidotie vaicājumi būs dažādi – gan vieglāki, gan sarežģītāki. Jāņem vērā, ka vairākās tabulās ierakstu skaits ir ne vien vairāki desmiti tūkstoši, bet pat vairāki miljoni, līdz ar to, būs jāveido daudz nosacījumu vaicājumos, lai varētu skaidri redzēt vaicājumu izpildes rezultātus.

Vaicājums „Select...From T”

Pirmais vaicājums tiks veidots tabulai VALSTIS. Vaicājums izvadīs valstu nosaukumus un to kodus, kuri būs apvienoti vienā kolonnā. Bez tam, tiks izvadītas datu bāzē esošās valstis ar kodiem, kuri sākas ar burtu „L” (skat. 4.1.1.att.).

4.1.1.att. Vaicājuma „Select..From T” realizācija

Kā varam redzēt, tad mums tiek izvadīts tieši tas, ko esam pieprasījuši. Pāriesim pie nākošā vaicājuma.

Vaicājums „Select...From T Where...And/Or..”

Otrais vaicājums būs jau nedaudz sarežģītāks, neskatoties uz to, ka tas tiks veidots tikai vienas tabulas (PERSONAS) ietvaros. Tā kā tieši šajā tabulā ierakstu skaits pārsniedz divus miljonus, tad šeit būs jāveido vairāki nosacījumi.

Izveidotais vaicājums izvadīs personas vārdu un uzvārdu (vienā kolonnā, bez tam, tā kā datu bāzē visi ieraksti ir veikti ar lielajiem burtiem, tad šeit mēs, ar INITCAP funkcijas palīdzību, izvadīsim personu vārdus un uzvārdus ar lielajiem sākumburtiem un maziem pārējiem burtiem0, kategoriju, kurā ietilpst konkrētais cilvēks, viņa dzimumu, nodaļu, kurā viņš ir piereģistrēts un personas tipu. Kā nosacījumi tiek definēti – personas kategorija nevarēs būt nedz ‘A’, nedz ‘D’, persona būs sieviešu dzimtas pārstāvis, izvadītās personas ir piereģistrētas nodaļā ar identifikatoru ‘4’ vai ‘39’. Tā pat personas tipam ir jābūt ‘A’ vai ‘B’. Kā arī (vadījos no sava vārda un uzvārda) personas vārdam ir jāsākas ar burtiem ‘VI’, bet uzvārdam - ar burtiem ‘RA’. Tātad vaicājuma realizācija un izpildes rezultāti ir apskatāmi 4.2.1.attēlā.

19

4.2.1.att. Vaicājuma „Select..From T Where...And/Or..” realizācija

Pateicoties tik lielam nosacījumu skaitam, mēs varam redzēt, ka vaicājuma izpildes gaitā tika atrasti 14 ieraksti, kuri atbilst mūsu uzstādītajiem nosacījumiem. Bez kādas daļas no šiem nosacījumiem, mums tiktu izvadīts ļoti liels ierakstu skaits, kas nebūtu pat pārskatāms.

20

Vajadzētu piebilst to, ka šis vaicājums aizņēma nedaudz vairāk laika izpildei (apmēram 30 sekundes), nekā iepriekšējais (2 sekundes), kas arī ir loģiski – jo tabulā VALSTIS ir tikai 43 ieraksti, pret vairākiem miljoniem ierakstu tabulā PERSONAS.

Vaicājums „Select...From T1,T2 Where...”

Šim vaicājumam, līdzīgi kā iepriekšējā vaicājumā, būs daudz nosacījumu. Tas tiks veidots trijām tabulām – VALSTIS, PERSONAS un NODAĻAS.

Vaicājums izvadīs informāciju par noteiktām personām - pašas personas vārdus un uzvārdus (kā iepriekš – vienā rindā un ar lielajiem sākumburtiem), valstis, kuru pilsoņi viņi ir, kā arī nodaļu nosaukumus, kurās viņi ir piereģistrēti. Vaicājuma izvadītie dati tiks sakārtoti pēc nodaļām.

Tā kā ierakstu skaits ir ļoti liels, tad tiks veidoti vairāki nosacījumi – tiks izvadītas personas, kuras ir piereģistrētas tieši Rīgas nodaļās, kā arī šīm personām ir jābūt valstu pilsoņiem, kuru nosaukums sākas ar ‘L’. Bez tam, izvadāmām personām ir jābūt vīriešu dzimuma pārstāvjiem ar vārdu ‘Aleksandrs’ un uzvārdu, kurš sāktos ar burtiem ‘RA’. Tā pat šim personām ir jābūt ‘C’ tipa pārstāvjiem.

Šī vaicājuma realizācija un izpildes rezultāti ir apskatāmi 4.3.1.attēlā.

4.3.1.att. Vaicājuma „Select..From T1, T2 Where...” realizācija

21

Attēlā varam redzēt, ka izvadītie dati pilnībā atbilst vaicājuma nosacījumiem. Šī vaicājuma izpilde arī bija diezgan lēna. Pēc vaicājuma palaišanas, bija jāuzgaida aptuveni 20-30 sekundes, līdz vaicājuma rezultāts tiktu izvadīts.

Vaicājums ar „Having”

Vaicājums ar ‘Having’ tiks veidots tabulai PERSONAS un izvadīs informāciju par to cik sieviešu un vīrieša dzimtes pārstāvju ir valstī ar kodu ‘USA’. Grupēšana notiek pēc cilvēku skaita katrā dzimtē (bez tam, tiek izvadītas tikai tās dzimtes, kurās vismaz viens pārstāvis, bet tā kā mums ir tikai divas dzimtes un nav nevienas citas klasifikācijas, kurā nebūtu neviena ieraksta, tad tiek izvadīti dati par abiem dzimumiem). Vaicājuma realizācija un izpildes rezultāti ir apskatāmi 4.4.1.attēlā.

4.4.1.att. Vaicājuma ar „Having” realizācija

Varam redzēt, ka starp datu bāzē ievadītām personām, kuras ir Amerikas Savienoto Valstu pārstāvji, ir 25731 vīrieši un 5482 sievietes.

Vaicājuma izpilde notika diezgan lēni – kādas 20 sekundes.

Vaicājums ar „Exists”

Nākošais vaicājums tiks izveidots tā, lai tas izvadītu nodaļas numuru un vidējo izmaksāto algu no tām nodaļām, kuras atrodas Saulkrastos (skat. 4.5.1.att.). Vaicājums tiek pielietots, izmantojot tabulas ALGAS un NODAĻAS.

4.5.1.att. Vaicājuma ar „Exists” realizācija

22

Tā kā datu bāzē ir tikai viena nodaļa, kura atrodas Saulkrastos, tad arī mums tiek izvadītas visas algas, kuras izmaksā šī nodaļa.

Vaicājuma izpildes laiks bija īss – tikai dažas sekundes.

Vaicājums ar „Group By Cube”

Kuba vaicājumu pielietosim tabulām VALSTIS un PERSONAS (skat. 4.6.att.).Vaicājums izvadīs datus par to – cik sieviešu un cik vīriešu dzimtas ir kopā, kā arī cik to ir

katrā atsevišķā valstī (dati tiek skaitīti no tabulas PERSONAS, kurā ir ierakstītas valstis katrai konkrētai personai, tādējādi – netiek skaitīti cilvēki pavisam katrai datu bāzes valstij, jo pārējām valstīm pēc datu bāzes datiem, nav ievadīts neviens tās pilsonis).

4.5.1.att. Vaicājuma ar „Group by Cube” realizācija

Izskatīsim vaicājuma izpildi pa soļiem.Pirmajā rindā redzam, ka pavisam mums ir vairāk nekā 2 miljoni cilvēku datu bāzē. No

tiem ‘S’ dzimuma pārstāvji, jeb sievietes ir 1346173, bet vīrieši (‘V’) – 1102640. Tālāk varam apskatīties, ka no tiem pavisam Latvijas pilsoņi ir 726100, no kuriem 401287 ir sievietes, bet

23

324113 – vīrieši. Tādā pašā secībā varam aplūkot informāciju arī par citām valstīm, kurām datu bāzē ir kaut viens pilsonis – Igaunija, Lielbritānija, Lihtenšteina un ASV.

Vaicājuma izpilde aizņēma nedaudz ilgāk laika nekā visi pārējie vaicājumi – aptuveni 40 sekundes.

Vaicājums ar klona tabulām un „Over”

Klona tabulu vaicājums ‘OVER’ tiks pielietots tabulām PERSONAS, NODALAS un ALGAS (skat. 7.4.1.att.).

Ar vaicājuma palīdzību tiks sastādīts vidējais algu rangs 1,6,12,17,21,24,32,39 un 40 nodaļām. Šajā gadījumā ir jāiegūst informācija par nodaļu nosaukumiem un to izmaksātajām algām, pie tam tieši Igaunijas (EST) pilsoņiem. Dati tiks sagrupēti pēc nodaļu nosaukumiem, atrodot algu summu, kuras izmaksā nodaļas Igaunijas pilsoņiem. Ar analītiskās funkcijas RANK() palīdzību tiks izskaitļoti rangi un norādīti kolonnā ‘VIETA’.

4.7.1.att. Vaicājuma ar „Over” realizācija

Pēc iegūtā rezultāta redzam, ka visvairāk Igaunijas pilsoņiem, no pieprasītajām nodaļām, izmaksā Rīgas pilsētas Ziemeļu filiāle, bet vismazāk – Zilupes filiāle.

Šī vaicājuma izpilde notika diezgan ilgi – rezultāti parādījās ekrānā aptuveni pēc vienas minūtes apstrādes.

24

Vaicājums ar Hierarhiju

Vaicājumam ar Hierarhiju mūsu datu bāzē ir sagatavota tabula ‘NODALAS’, kurai ir unārā saite pašai uz sevi, proti kolonnai ID ar kolonnu NOD_KODS. Kolonnā NOD_KODS ir ierakstīts tās nodaļas kods, kura ir atbildīga par katru noteikto nodaļu.

Tātad, vaicājums izvadīs tabulas hierarhijas līmeņus ar papildus kolonnas LEVEL izveidošanas palīdzību, kura parādīs ranga piederības līmeņus, attiecībā pret pašu galveno nodaļu (kuras ID=1). Bez tam, tā kā nodaļas datu bāzē ir daudz, ir jāizpildās nosacījumam, ka izvadāmām nodaļām ir jābūt piereģistrētām Rīgā (skat. 4.8.1.att.). Izvadītie dati tiks sagrupēti pēc līmeņa.

4.8.1.att. Vaicājuma ar hierarhiju realizācija

Komandas START WITH ... norāda uz hierarhijas saknes rindām, un komandas CONNECT BY PRIOR norāda uz attiecībām starp saknes un meitas rakstiem.

Tātad, varam redzēt, ka izvadītais rezultāts atbilst vaicājuma nosacījumiem un mums tika attēloti nodaļu identifikatori, kā arī nodaļu identifikatori, kuras par tām ir atbildīgas. Tā pat varam aplūkot nodaļu nosaukumus un pārliecināties, ka attēlotās nodaļas ir piereģistrētas Rīgā. Un visbeidzot – redzam ranga līmeņu attiecībā pret saknes nodaļu, kura ir pati galvenā nodaļa, kurai visas pārējās pakļaujas, atkarībā no līmeņa.

Vaicājuma izpilde bija ilgāka par visām pārējām un aizņēma aptuveni pusotru minūti, lai vaicājuma rezultāts tiktu attēlots ekrānā.

25

Vaicājums ar pakārtotu vaicājumu „FROM” rindā

Nākošais pakārtotais vaicājums izvadīs informāciju par personām (to izvade tiks noformēta kā iepriekš), valstīm, kurās tie ir pilsoņi, kā arī personu kategorijas (skat. 4.9.1.att.).

Bez tam, ar nosacīju palīdzību tiek definēts, ka izvadāmām personām ir jābūt ‘A’ kategorijas pārstāvjiem, tiem jābūt reģistrētiem 6 nodaļā, kā arī jābūt Lielbritānijas pilsoņiem (GBR). Tā par – viņiem ir jābūt ar vārdu ‘VIKTORIJA’ un uzvārdu, kas sākas ar burtiem ‘RA’.

Tādējādi, vaicājums tiek realizēts divām tabulām – PERSONAS un NODAĻAS.

4.9.1.att. Vaicājuma ar pakārtotu vaicājumu „FROM” rindā realizācija26

Pēc rezultāta redzam, ka visi nosacījumi ir izpildījušies. Datu izvades laiks nepārsniedz 10 sekundes.

Vaicājums ar pakārtotu vaicājumu „SELECT” rindā

Pakārtotais vaicājums ‘SELECT’ rindā tiks veidots, izmantojot divas tabulas – NODAĻAS un ALGAS (skat. 4.10.1.att.).

Vaicājums izvadīs nodaļu nosaukumus, pilsētas, kurās tās atrodas, kā arī tiks aprēķināta summa katrai no nodaļām, ko tā izmaksā. Tā kā nodaļu skaits datu bāzē ir liels, tad tiks pieprasīta informācija tikai par deviņām nodaļām – 1,5,10,15,20,25,30,35 un 40.

4.10.1.att. Vaicājuma ar pakārtotu vaicājumu „SELECT” rindā realizācija

Attēlā varam redzēt, ka stabiņā ‘ALGU_IZMAKSAS’ ir aprēķinātas summas izmaksātajām algām, ko izmaksā katra no deviņām pieprasītajām nodaļām.

Arī šis vaicājums savu izpildi veica diezgan ātri – tikai kādās 5 sekundēs.

Vaicājums ar pakārtotu vaicājumu „HAVING” rindā

Pakārtotais vaicājums ‘HAVING’ rindā tiks veidots tabulai ALGAS (skat. 4.11.1.att.).Vaicājums izvadīs datus par tiem algu identifikatoriem, ko izmaksā 39 nodaļa, kuru vidējās

algas apjoms ir mazāks par starp 39 nodaļā izmaksāto vidējo algu apjomu.

27

4.11.1.att. Vaicājuma ar pakārtotu vaicājumu „HAVING” rindā realizācija

Pēc iegūtā rezultāta redzam, ka mums ir izvadītas 4 algas un to identifikatori no 39 nodaļas izmaksātām algām, kuru apjoms ir mazāks par vidējo 39-tās nodaļas izmaksāto algu apjomu. Ja ielūkojas datu bāzes datos, tad 39 nodaļa pavisam izmaksā 5 algas un viena no tām pārsniedz 10 vienības. Līdz ar to, rēķinot vidējo rezultātu, izvadītie dati ir patiesi.

Vaicājuma izpilde aizņēma apmēram 10 sekundes.Gribētu piebilst to, ka visvairāk laika rezultātu attēlošanai bija nepieciešams

hierarhiskajam vaicājumam, klona tabulu vaicājumam un kuba vaicājumam.

Tagad, kad ir izveidoti visi vaicājumi, varam apskatīt izpildāmās relāciju algebras darbības dažiem no tiem.

28

5. VAICĀJUMIEM IZPILDAMĀS RELĀCIJU ALGEBRAS KOMANDAS

Tagad viss ir sagatavots tam, lai mēs varētu noteikt to, kādas relāciju algebras (turpmāk RA) darbību secības tik izmantotas tam, lai tiktu iegūti vaicājumu rezultāti.

Tā kā pēc uzdevuma nostādnes ir prasīts noteikt izpildāmās relāciju algebras komandas pieciem vaicājumiem, tad daži no 4.nodaļā iepriekš definētajiem vaicājumiem netiks izskatīti.

Izpildāmās RA darbības vaicājumam ar „Having”

Izveidotais vaicājums ar ‘HAVING’ ir realizēts vienai tabulai – PERSONAS.

Vaicājuma teksts:SELECT dzimte, COUNT(dzimte) as personu_skaitsFROM personasWHERE valsts='USA'GROUP BY dzimteHAVING COUNT (dzimte)>0

Apskatīsim šīs tabulas laukus.Tabulas PERSONAS kolonnas var apskatīt 5.1.1.attēlā.

5.1.1.att. Tabulas PERSONAS kolonnas

RA darbības: Projekcija – tiek veikta projekcija, kuras rezultātā, no tabulas PERSONAS tiks

atlasītas tās kolonnas, kuras ir norādītas vaicājuma SELECT rindā (skat. 5.1.2.att.).

5.2.2.att. Projekcija tabulai PERSONAS

Agregātfunkciju pielietošana – tiek pielietota agregātfunkcija COUNT kolonnai ‘dzimte’, kura saskaita nepieciešamos ierakstus, kuri ir atrasti projekcijas rezultātā.

Selekcija – tiek veikta selekcija, kuras rezultātā tiek izpildīti nosacījumi, kuri ir norādīti WHERE rindā, proti – valsts=’USA’.

Selekcija – tiek veikta selekcija pēc nosacījuma COUNT(dzimte)>0, kura atlasa tos ierakstus kuros skaits ir lielāks par 0. Tas palīdzēs tālāk veikt ierakstu grupēšanu.

Grupēšana – tiek veikta grupēšana, kuras rezultātā iegūtie ieraksti tiek sagrupēti pēc dzimtas.

29

Izpildāmās RA darbības vaicājumam ar „Exists”

Izveidotais vaicājums ar ‘EXISTS’ ir realizēts divām tabulām – ALGAS un NODAĻAS.

Vaicājuma teksts:Select a.videja_alga, a.nod_izsniedzfrom algas awhere exists (Select n.nodala, n.idfrom nodalas nwhere ((n.pilseta='Saulkrasti') and (n.id=a.nod_izsniedz)))

Apskatīsim šo tabulu laukus.Tabulas ALGAS kolonnas var apskatīt 5.2.1.attēlā.

5.2.1.att. Tabulas ALGAS kolonnas

Tabulas NODAĻAS kolonnas var apskatīt 5.2.2.attēlā.

5.2.2.att. Tabulas NODAĻAS kolonnas

RA darbības: Projekcija – tiek veikta projekcija, kuras rezultātā, no tabulas NODAĻAS tiek

izvēlētas tās kolonnas, kuras ir norādītas WHERE rindas pakārtotajā vaicājumā (skat. 5.2.3.att.).

5.2.3.att. Projekcija tabulai NODAĻAS

Selekcija – tiek veikta selekcija, kuras rezultātā tiek atrasti ieraksti, kuri atbilst pirmajam nosacījumam, kas norādīti pakārtotā vaicājuma WHERE rindā, proti – n.pilseta=’Saulkrasti’.

Selekcija – tiek veikta selekcija, kuras rezultātā tiek atrasti ieraksti, kuri atbilst otrajam nosacījumam, kas norādīti pakārtotā vaicājuma WHERE rindā, proti – n.id=a.nod_izsniedz.

30

Projekcija – tiek veikta projekcija tabulai ALGAS, kas norādīta vaicājuma galvenajā daļā. Rezultātā tiek paņemtas vaicājuma galvenajā daļā SELECT rindā norādītās kolonnas (skat. 5.2.4.att.).

5.2.4.att. Projekcija tabulai ALGAS

Selekcija – tiek veikta selekcija, kuras rezultātā tiek atlasīti tie vidējo algu ieraksti, kuriem eksistē tie nodaļu identifikatori, kuri ir atlasīti pakārtotajā vaicājumā (proti, tās nodaļas, kuras atrodas Saulkrastos).

Izpildāmās RA darbības vaicājumam ar „Group By Cube”

Izveidotais vaicājums ar ‘Group By Cube’ ir realizēts divām tabulām – PERSONAS un VALSTIS.

Vaicājuma teksts:select v.valsts_nos, p.dzimte, count(p.dzimte) as Personasfrom valstis v, personas pwhere p.valsts=v.valsts_kodsgroup by cube(v.valsts_nos, p.dzimte)

Apskatīsim šo tabulu laukus.Tabulas PERSONAS kolonnas var apskatīt 5.3.1.attēlā.


Tabulas VALSTIS kolonnas var apskatīt 5.3.2.attēlā.

5.3.2.att. Tabulas VALSTIS kolonnas

RA darbības: Dekarta reizinājums – tiek veikts Dekarta reizinājums starp divām tabulām

PERSONAS un VALSTIS, kuras ir norādītas vaicājuma FROM rindā. Projekcija – tiek veikta projekcija, kuras rezultātā no Dekarta reizinājuma gaitā

izveidotās tabulas tiek atlasītas tās kolonnas, kuras ir norādītas vaicājuma SELECT rindā (skat. 5.3.3.att.).

31

5.3.3.att. Projekcija tabulu PERSONAS un VALSTIS Dekarta reizinājumam

Agregātfunkciju pielietošana – tiek pielietota agregātfunkcija COUNT kolonnai ‘dzimte’, kura saskaita nepieciešamos ierakstus, kuri ir atrasti projekcijas rezultātā.

Selekcija – tiek veikta selekcija, kuras rezultātā tiek atlasīti tie ieraksti, kuri atbilst WHERE rindas nosacījumam, proti - p.valsts=v.valsts_kods.

Grupēšana – tiek veikta atlasīto ierakstu grupēšana pēc Group By Cube rindas nosacījumiem – sākumā valsts (p.valsts), pēc tam dzimte, pašās beigās paliek pārējās kolonnas, kas šajā gadījumā ir – cilvēku skaits, kuri pieder katrai dzimtei.

Izpildamās RA darbības vaicājumam ar klona tabulām un „Over”

Izveidotais vaicājums ar ‘Over’ ir realizēts trijām tabulām – PERSONAS, NODAĻAS un ALGAS.

Vaicājuma teksts:select n.nodala, n.pilseta, sum(a.videja_alga) algas,rank() over(order by sum(a.videja_alga) desc) as vietafrom personas p, nodalas n, algas awhere (n.id=p.nodalas_id and n.id=a.nod_izsniedz) and (p.valsts IN ('EST') and n.id in (1,6,12,17,21,24,27,32,36,39,40))group by n.nodala, n.pilseta

Apskatīsim šo tabulu laukus.Tabulas PERSONAS kolonnas var apskatīt 5.4.1.attēlā.


Tabulas ALGAS kolonnas var apskatīt 5.4.2.attēlā.



32


RA darbības: Dekarta reizinājums – tiek veikts Dekarta reizinājums starp trijām tabulām

PERSONAS, ALGAS un NODAĻAS, kuras ir norādītas vaicājuma FROM rindā. Projekcija – tiek veikta projekcija, kuras rezultātā no Dekarta reizinājuma gaitā

izveidotās tabulas tiek atlasītas tās kolonnas, kuras ir norādītas vaicājuma SELECT rindā (skat. 5.4.4.att.).

5.4.4.att. Projekcija tabulu PERSONAS, ALGAS un NODAĻAS Dekarta reizinājumam

Agregātfunkciju pielietošana – tiek pielietota agregātfunkcija SUM kolonnai ‘a.videja_alga’, kura saskaita nepieciešamos ierakstus, kuri ir atrasti projekcijas rezultātā.

Šķirošana – tiek veikta šķirošana, kur šķirošanas atribūts ir ar agregātfunkcijas palīdzību noteiktā vērtība SUM(a.videja_alga), kā rezultātā tiek izpildīta analītiskās funkcijas RANK() izpilde.

Selekcija – tiek veikta selekcija, kuras rezultātā tiek izpildīti nosacījumi, kuri atrodas WHERE rindā, proti – n.id=p.nodalas_id.

Selekcija – tiek veikta selekcija, kuras rezultātā tiek izpildīti nosacījumi, kuri atrodas WHERE rindā, proti – n.id=a.nod_izsniedz.

Selekcija – tiek veikta selekcija, kuras rezultātā tiek izpildīti nosacījumi, kuri atrodas WHERE rindā, proti – p.valsts IN (‘EST’).

Selekcija – tiek veikta selekcija, kuras rezultātā tiek izpildīti nosacījumi, kuri atrodas WHERE rindā, proti – n.id in (1,6,12,17,21,24,27,32,36,39,40)).

Grupēšana – tiek veikta grupēšana, kuras rezultātā iegūtie ieraksti tiek sagrupēti pēc nodaļas (n.nodala), tālāk – pilsētas (n.pilsēta), tālāk – visi pārējie izvadāmie atribūti, proti ‘ALGAS’ un ‘VIETA’.

Izpildamās RA darbības vaicājumam ar apakšvaicājumu „SELECT” rindā

Izveidotais vaicājums ar apakšvaicājumu ‘SELECT’ rindā ir realizēts divām tabulām – NODAĻAS un ALGAS.

Vaicājuma teksts:SELECT n.id, n.nodala, n.pilseta,

33

(SELECT sum(a.videja_alga)from algas awhere n.id=a.nod_izsniedz) as algu_izmaksasfrom nodalas nwhere n.id in (1,5,10,15,20,25,30,35,40)

Apskatīsim šo tabulu laukus.Tabulas ALGAS kolonnas var apskatīt 5.5.1.attēlā.




RA darbības: Projekcija – tiek veikta projekcija, kuras rezultātā tiek atrastas kolonnas no tabulas

ALGAS (norādīta pakārtotā vaicājuma FROM rindā), kuras norādītas pakārtotā vaicājuma SELECT rindā (skat. 5.5.3.att.).

5.5.3.att. Projekcija tabulai ALGAS

Agregātfunkciju pielietošana – tiek pielietota agregātfunkcija SUM kolonnai ‘a.videja_alga’, kura saskaita nepieciešamos ierakstus, kuri ir atrasti projekcijas rezultātā.

Selekcija – tiek veikta selekcija, kuras rezultātā tiek izpildīti nosacījumi, kuri atrodas pakārtotā vaicājuma WHERE rindā, proti – n.id=a.nod_izsniedz.

Dekarta reizinājums – tiek veikts Dekarta reizinājums starp tabulu NODAĻAS (norādīta galvenā vaicājuma FROM rindā) un iepriekšējās selekcijas rezultātā atlasīto kolonnu ‘ALGU IZMAKSAS’.

Projekcija – tiek veikta projekcija, kuras rezultātā no Dekarta reizinājuma gaitā izveidotās tabulas tiek atlasītas tās kolonnas, kuras ir norādītas galvenā vaicājuma SELECT rindā (skat. 5.5.4.att.).

34

5.4.4.att. Projekcija tabulas NODAĻAS un atlasītās kolonnas „ALGU_IZMAKSAS” Dekarta reizinājumam

Selekcija – tiek veikta selekcija, kuras rezultātā tiek izpildīti nosacījumi, kuri atrodas galvenā vaicājuma WHERE rindā, proti – n.id IN (1,5,10,15,20,25,30,35,40).

Tagad, kad ir apskatītas RA izpildāmās darbības dažiem vaicājumiem, mēģināsim iegūt iepildes plānus, kurus arī analizēsim un vēlāk koriģēsim.

35

6. IZPILDES PLĀNU IEGŪŠANA UN ANALĪZE

Izpildes plāns, komanda EXPLAIN PLAN un PLAN_TABLE

Izpildes plāns pēc savas būtības ir to darbību secība, kuras ir nepieciešams izpildīt tam, lai varētu iegūt vajadzīgos datus. Tas iekļauj sevī konkrētu informāciju par to – kādas datu atrašanas metodes; kādus tabulu sasaistes metodes; kādā kārtībā ir jāizpilda – lai izgūtu vaicājuma datus. Lai apskatītu vaicājuma izpildes plānu, ir jārīkojas sekojoši:

1. Jāiegūst izpildes plāns ar komandu EXPLAIN PLAN : EXPLAIN PLAN komanda saglabā iegūto izpildes plānu tabulā PLAN_TABLE (minētā tabula

tiks izveidota turpmākā darba gaitā, izmantojot Oracle piedāvāto skriptu, ko var atrast ultxplan.sql failā, Oracle instalācijas mapē).

EXPLANE PLAN komanda parāda izpildes plānus SELECT, UPDATE, INSERT un DELETE vaicājumiem. Vaicājumu izpildes plāns ir Oracle operāciju secība, ko pielieto Oracle, lai izpildītu vaicājumu.

Izpildes plāns iekļauj sekojošas komponentes: tabulu, uz ko atsaucas vaicājumi, sistematizēšana; pieejas metode katrai tabulai, kas pieminēta vaicājumā; tabulu, ko iespaido saistītas darbības vaicājumā, sasaistes metode.

Explain Plan izvade parāda kā Oracle izpilda operatorus. Explain Plan izpilda rezultātus atsevišķi, bet nevar atšķirt operatorus, kas ir labi noskaņoti un tos, kas slikti darbojas. Piemēram, ja Explain Plan izejas dati parāda, ka vaicājums izmanto indeksus, tas nenozīmē, ka vaicājums izpildās efektīvi. Dažreiz indeksu lietošana var būt ļoti neefektīva. Tāpēc ir labāk izmantot Explain Plan, lai noteiktu plānu un varētu piekļūt tam un vēlāk izmantojot testēšanu pārbaudīt vai plāns ir optimāls.

Kad novērtē plānu vienmēr ir jāpārbauda operatoru patieso resursu patēriņu. Lai iegūtu labākus rezultātus būtu nepieciešams pielietot Oracle trasēšanu (Oracle Trace) vai SQL trasēšanu (SQL trace) un TKPROF, lai pārbaudītu atsevišķu SQL vaicājumu virknes izpildi.

Tātad, komanda EXPLAIN_PLAN tiek lietota vaicājuma izpildes plāna iegūšanai. Darba gaitā tiks izmantota sekojoša sintakse:

EXPLAIN PLAN SET STATEMENT_ID = <plāna identifikācijas numurs>FOR SELECT <Vaicājums, kuras tiek sastādīts izpildes plāns>

Šāda izteiksme saglabā vaicājuma izpildes plānu PLAN_TABLE tabulā un dod iespēju uzdot identifikācijas nosaukumu plānam, lai vēlāk būtu iespējams izgūt šo plānu, vēršoties pie tā ID.

2. Jāizvada izpildes plāns labi pārskatāmā formā: Kā jau tika minēts iepriekš, izpildes plānu var izgūt no PLAN_TABLE, izmantojot triviālu un

vienkāršu vaicājumu, kurā tiek norādīts plāna ID (STATEMENT_ID). Iespējami vienkāršākais vaicājums izskatās sekojoši:

Select id, operations, options, object_name, object_typeFrom plan_tableWhere statement_id= <plāna identifikācijas numurs>,

Jebkurai tabulai, ko izmanto Explain Plan operatora izejas datu uzkrāšanai, ir jāsatur tādi kolonnu nosaukumi un datu tipi, kādi ir PLAN_TABLE. 1. tabulā dots plāna tabulas lauku skaidrojums.

36

1. tabulaPlāna tabulas lauku skaidrojums

Lauks Paskaidrojums

Statement_ID Izpildāmā vaicājuma identifikators

Timestamp Explane Plan palaišanas datums un laiks

Remarks

Jebkurš komentārs (līdz 80 baitiem) kas iekļauts katrā izpildes plāna solī. ja ir nepieciešams izmainīt vai atzīmēt kādu no Plan_Table rindiņām, var izmantot operatoru UPDATE, lai veiktu vajadzīgās izmaiņas.

Operation

Vaicājuma izpildes solī izpildītās darbību nosaukums. Pirmajā rindiņā, ko ģenerē vaicājums, lauks satur vienu no sekojošām vērtībām: DELETE STATEMENT, INSERT STATEMENT, SELECT STATEMENT, UPDATE STATEMENT.

Options Vaicājuma darbības, kas izskaidrota laukā Operation iespējamā vērtība.Object_Node

Datu bāzes atsauces nosaukums, kas izmantota, lai piekļūtu objektam (tabulas nosaukumu vai skata nosaukumu)

Object_Owner Lietotāja vārds, kam pieder shēma, kas satur tabulu vai indeksuObject_Name Tabulas vai indeksa nosaukums

Object_Instance Objekta, kas atrodas vaicājumā, pozīcijas numurs. Numerācija tiek uzsākta no kreisās uz labo pusi, ievērojot oriģinālo vaicājuma tekstu.

Object_Type

Modifikators, kas nodrošina aprakstošu informāciju par objektu. Piemēram, indeksiem – NON-UNIQUE.

Optimizer “Otimizātora” esošais režīms (atbild par Explain Plan izveidošanu)

Search_Columns Šo lauku neizmantoId Explain Plan katra soļa identifikatora numursParent_Id

Nākošā izpildes soļa identifikators, kas izmanto pašreizējā soļa rezultātu

Position Darbību, kam ir vienāds PARENT_ID, izpildes kārtības numurs.

Cost

Darbības izmaksas, kas novērtētas ar izmaksu bāzētu pieeju. Vaicājumiem, kas izmanto noteikumu bāzētu pieeju šajā laukā būs nulles vērtību. Izmaksas netiek noteiktas tabulu piekļuves darbībām. Tā ir vērtība, ko izmanto, lai salīdzinātu izpildes plāna izmaksas.

Cardinality Rindiņu skaita, ko izmato darbība, novērtējums ar izmaksu bāzētu pieeju.

Bytes Baitu skaits, ko izmato darbība, novērtējums ar izmaksu bāzētu pieeju.

Other Cita informācija, kas ir specifiska izpildes soļiem, kas lietotājam varētu būtu noderīgaOther_Tag

Apraksta OTHER kolonnu saturu.

Partition_Start

Izmantoto partīciju diapazona sākuma partīcija. Šim laukam var būt sekojošas vērtības:- n norāda, ka sākuma partīciju ir identificējis SQL kompilators, un tās partīcijas numuru parāda dotais n.- KEY parāda, ka sākuma partīciju identificēs izpildes laikā no sadalošās vadošās vērtības;- ROW LOCATION parāda, ka sākuma partīcija ( tāpat kā beigu partīcijai) tiks aprēķināta izpildes laikā no katra izgūtā ieraksta atrašanās vietas. Ieraksta atrašanās vietu nosaka lietotājs vai arī izmantojot globālo indeksu.- INVALID parāda, ka izmantoto partīciju diapazons ir tukšs

Partition_Stop

Izmantoto partīciju diapazona beigu partīcija. Laukam var būt sekojošas vērtības:- ‘n’ norāda, ka beigu partīciju ir identificējis SQL kompilators, un tās partīcijas numuru parāda dotais n.- KEY parāda, ka beigu partīciju identificēs izpildes laikā no sadalošās vadošās vērtības;- ROW LOCATION parāda, ka beigu partīcija ( tāpat kā sākuma partīcijai) tiks aprēķināta izpildes laikā no katra izgūtā ieraksta atrašanās vietas. Ieraksta atrašanās vietu nosaka lietotājs vai arī izmantojot globālo indeksu.- INVALID parāda, ka izmantoto partīciju diapazons ir tukšs

Partition_Id Solis, kas aprēķina sākuma partīcijas un beigu partīcijas lauku pāra vērtības.

PLĀNA IZGŪŠANAS PAŅĒMIENIIzpildes plāna izgūšanai var izmantot vairākus paņēmienus:

37

a) Var lietot parasto SELECT vaicājumu, lai izgūtu interesējošos datus no PLAN TABLE:select id, parent_id, operation, options, object_name, object_typefrom plan_table where statement_ID='<vaicājuma identifikators>'b) Var lietot gatavo SQL skriptu, ko var atrast Oracle instalācijas mapē, SQL*Plus logā

izsaucot sekojošo skriptu: @D:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\UTLXPLS.c) Var lietot hierarhisko vaicājumu, ar kura palīdzību var izgūt tieši to, ko vēlas redzēt,

bez tam, informācija var tikt attēlota ļoti koncentrēti un skaidri, līdz ar to plāna analizēšana ir diezgan viegla:

Select ID, Parent_id as vecaku_id, Position as pozicija, Optimizer as optimizators,Lpad('', 4*(Level-1))||Operation||' '||Options||' '||Object_name Vaic_izp_plansfrom plan_tablestart with ID=0 and statement_id='<vaicājuma identifikators>'connect by prior ID=Parent_ID and Statement_ID='<vaicājuma identifikators>'d) Lai izpildes plāns būtu labi pārlūkojams un saprotams, var izmantot komandu SET

AUTOTRACE TRACEONLY EXPLAIN plāna tabulas iegūšanai. Palaižot komandu AUTOTRACE, automātiski ir iespējams iegūt vaicājuma izpildes plānu un komandu izpildes statistiku. Komandas parametrs TRACEONLY EXPLAIN norāda to, ka uz ekrāna jāizvada tikai vaicājuma izpildes plāns. Līdz ar to, pēc katras darbības ar EXPLAIN PLAN un vaicājumu, uzreiz automātiski tiek izvadīts tikai vaicājuma izpildes plāns, kurš arī ir ļoti pārskatāms.

e) Var izmantot SELECT * FROM TABLE vaicājumu, kopā ar funkciju, kas izskatīsies sekojoši: SELECT * FROM table(DBMS_XPLAN.DISPLAY). Šāds paņēmiens attēlos tādu pašu rezultātu kā ‘b)’ plāna izgūšanas veids.

Protams, vēl ir daudzi citi veidi, kā izgūt plānu no PLAN TABLE.3. Jāveic optimizātora konfigurēšana: Veicot vaicājumu optimizāciju, ir jāizvēlas arī optimizātora veids. Oracle optimizātors var

sastādīt vaicājuma izpildes plānu, balstoties uz resursu analīzi vai likumiem (kaut gan plašāk tiek izmantots resursu analīzes optimizātors). Uzsākot vaicājuma izpildi, ir jāuzstāda optimizācijas veida: ALTER SESSION SER OPTIMIZER = <optimizatora veids (balstīts uz resursiem vai likumiem)>

Tiek piedāvāti sekojoši optimizatora veidi:CHOOSE – optimizātors pats izvēlas starp resursu analīzes un uz likumiem balstīto

pieejām. Ja ir iespējams iegūt statistiku par vaicājuma tabulām, tad optimizātors izvēlas resursu analīzes pieeju, pretējā gadījumā – uz likumiem balstīto.

ALL_ROWS – optimizātors izmanto uz resursu analīzes balstīto pieeju un veic visu rezultātu iegūšanas laika minimizēšanu.

FIRST_ROWS_n (n=1,10,100,1000) – optimizātors izmanto uz resursu analīzes balstītu pieeju un veic pirmā ‘n’ rezultāta iegūšanas laika minimizēšanu.

FIRST_ROWS – optimizātors izmanto uz resursu analīzes balstītu pieeju un veic pirmā rezultāta iegūšanas laika minimizēšanu.

RULE – optimizātors izmanto uz likumiem balstītu pieeju SQL vaicājumu optimizācijai, attiecībā uz visiem SQL vaicājumiem.

Protams, var izmantot arī citus izpildes plāna iegūšanas iespējas (piemēram, ENTERPRISE MANAGEMENT pakotnes programma – SQL Analyze. Taču tam, lai mēs izpētītu patiešām sarežģītus plānus, mēs to neizmantosim (kaut arī tas piedāvā grafisko lietotāja saskarni un rīkus, kuri atvieglo plāna iegūšanu un analīzi).

Tagad, pirms sāksim darbu pie izpildes plāniem, izveidosim PLAN_TABLE tabulu, kurā glabāsies mūsu izpildes plāni. Kā jau tika minēts, šīs tabulas izveides skripts ir atrodams Oracle instalācijas mapes utlxplan.sql failā (precīzāk, manā gadījumā - D:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\utlxplan.sql) (skat. 6.1.att.).

38

6.1.att. PLAN_TABLE izveidošana no utlxplan.sql skripta

Statistikas iegūšana

Lai nodrošinātu optimizētāju ar informāciju par shēmas objektiem, ir nepieciešams regulāri savākt statistikas datus. Ja shēmas objektu dati vai struktūra tiek mainīta, jāveic jauna statistikas datu savākšana.

Statistika tiek ģenerēta izmantojot ANALYZE komandu vai arī izmantojot pakotni DBMS_STATS. Savā darbā statistikas ģenerēšanai izmantošu komandu ANALYZE.

Ja tiek vākta statistika visai tabulai, kā arī tad, ja ir nepieciešams savākt statistiku vienai vai vairākām kolonnām, tad tabulai vispirms ir jāģenerē statistika pēc kolonnām, citādi kolonnu statistika tiks izdzēsta. Piemēram, šādi:

ANALYZE TABLE < objekta_nosaukums > ESTIMATE STATISTICS; ANALYZE TABLE < objekta_nosaukums > ESTIMATE STATISTICS FOR ALL COLUMNS; Ģenerējot statistiku tabulai, kolonnai vai indeksam, Oracle atjauno eksistējošo statistiku,

ja datu vārdnīcā jau eksistē statistika konkrētajam objektam. Lai ģenerētu statistiku pilnīgi visam objektam, raksta komandu:ANALYZE INDEX <objekta_nosaukums> COMPUTE STATISTICS.

39

Dažu ANALYZE komandas rindā iespējamo parametru skaidrojums ir dots 2. tabulā.2. tabula.

Daļa no ANALYZE komandas rindā iespējamiem parametriem

INDEX (indekss)

Identificē indeksu, kas tiks analizēts.

Oracle apkopo sekojošu statistiku par indeksu: - Indeksa dziļums no apakšējā bloka jeb saknes bloka līdz augšējam blokam.- Augšējo (leaf) bloku skaits.- Atšķirīgo indeksa vērtību skaits.- Vidējais augšējo bloku skaits katrai indeksa vērtībai.- Vidējais datu bloku skaits katrai indeksa vērtībai. - Klasteru faktors (cik labi pie indeksētām vērtībām ir sakārtotas rindas.) Indeksu statistika parādās datu vārdnīcas skatos USER_INDEXES, ALL_INDEXES un DBA_INDEXES.

TABLE (tabula)

Identificē tabulu, kas tiks analizēta. Kad vāc statistiku tabulai, Oracle arī automātiski apkopo statistiku tabulas indeksiem.

Oracle apkopo sekojošu tabulas statistiku: - Rindu skaits. - Datu bloku skaits, kas ir formatēti, lai saņemtu datus, neatkarīgi no tā, vai tie dotajā momentā satur datus vai arī tie ir tukši. - Datu bloku skaits, kas piešķirti tabulai, kura nekad nav bijusi izmantota. - Vidējais brīvo vietu skaits datu blokā (baitos). - Saistīto rindu skaits. - Vidējais rindu garums (baitos). Tabulu statistika parādās datu vārdnīcas skatos USER_TABLES, ALL_TABLES un DBA_TABLES.

COMPUTE STATISTICS

Aprēķina precīzu statistiku par analizēto objektu un saglabā to datu vārdnīcā. Kad analizē tabulu, tiek vākta gan tabulas, gan kolonnu statistika.

ESTIMATE STATISTICS

Novērtē statistiku par analizēto objektu un saglabā to datu vārdnīcā.

SAMPLE Nosaka datu apjomu no analizētā objekta Oracle parauga, lai novērtētu statistiku. Ja dotais parametrs tiek izlaists, Oracle kā paraugu izmanto 1064 rindas.

ROWS Uzliek Oracle, kā paraugu izmantot tabulas vai klastera veselas rindas vai arī vesela tipa ievades no indeksiem. Parametra vērtībai jābūt vismaz 1.

PERCENT Uzliek Oracle, kā paraugu izmantot noteiktu procentu rindu no tabulas vai klastera vai arī no indeksa ievažu procenta. Vērtība var būt no 1 līdz 99.

for_clause Specificē to, vai tiks analizēta visa tabula vai indekss vai arī analizētas tiks noteiktas kolonnas.

- FOR TABLE statistika tiks vākta tikai tabulai, nekā tabulai un kolonnai. - FOR COLUMNS statistika tiks vākta tikai kolonnai. . - FOR ALL COLUMNS tiks vākta statistika visām kolonnām. - FOR ALL INDEXED COLUMNS statistika tiks vākta visām indeksētajām kolonnām tabulā. - FOR ALL INDEXES – nosaka, ka visi indeksi, kas saistīti ar tabulu tiks analizētiOracle apkopo sekojošu kolonnas statistiku: - Atšķirīgo vērtību skaits kolonnā, kā vienā veselumā. -Maksimālais un minimālais vērtību skaits katrā grupā. Kolonu statistika parādās datu vārdnīcas skatos USER_TAB_COLUMNS, ALL_TAB_COLUMNS un DBA_TAB_COLUMNS.

Tagad, kad esam iepazinušies ar statistikas ģenerēšanas pamatdarbībām, plāna iegūšanas iespējām, kā arī esam izveidojuši plāna tabulu, - varam pāriet pie izpildes plānu iegūšanu vaicājumiem, izmantojot statistiku, kā arī uzreiz veikt plānu analīzi.

40

Plānus iegūsim dažādos veidos - dažviet izmantojot statistiku, dažviet arī izmantojot likumus.

Izpildes plāns vaicājumam ar „Select...From T1,T2 Where...”

6.1.1. Statistikas iegūšana

Veiksim analīzi jeb ģenerēsim statistiku visām tabulām, kuras piedalās katra noteiktā vaicājuma realizācijā.

Vaicājuma kods:

Select p.id as id, INITCAP(p.vards||' '||p.uzvards) as Persona, v.valsts_kods as valsts, n.nodala as nodalafrom valstis v, personas p, nodalas nwhere ((v.valsts_kods=p.valsts) and (p.nodalas_id=n.id))and (((n.pilseta IN ('Riga')) and (v.valsts_kods LIKE 'L%')) and ((p.vards IN ('ALEKSANDRS')) and ((p.dzimte in ('V')) and ((p.tips IN ('C')) and (p.uzvards LIKE 'RA%')))))ORDER by nodala

Vaicājuma realizācijā piedalās trīs tabulas – VALSTIS, PERSONAS un NODAĻAS. Tātad, ģenerēsim statistiku šīm tabulām (skat. 6.3.1.1.att.).

6.3.1.1.att. Statistikas ģenerēšana vaicājumam “Select...From T1,T2 Where...”

Vēlētos piebilst, ka jau pēc pirmā ANALYZE vaicājuma ievades SQL*Plus, man nācās gaidīt apmēram minūti, līdz parādījās uzraksts, ka tabula ir analizēta. Tas arī būtu loģiski, jo tabula PERSONAS ir vislielākā pēc datu apjoma tajā. Pārējās divas tabulas tika izanalizētas ļoti ātri.

41

6.1.2. Izpildes plāna iegūšana, izmantojot statistiku (ALL_ROWS)

Pirms mēs veidojam izpildes plānu, konfigurēsim optimizātoru uz resursu analīzei balstīto pieeju, kura izmanto statistiku (skat. 6.3.2.1.att.).

6.3.2.1.att. Optimizatora konfigurēšana vaicājumam “Select...From T1,T2 Where...”

Iegūsim izpildes plānu, iepriekš norādītajam vaicājumam, izmantojot EXPLAIN PLAN komandu un izveidoto vaicājuma kodu (skat. 6.3.2.2.att.). Nosauksim mūsu pirmo vaicājumu kā ‘1VAIC’, jo vēlāk mums šis vaicājums būs arī jāizgūst no PLAN_TABLE.

6.3.2.2.att. Izpildes plāna iegūšana vaicājumam “Select...From T1,T2 Where...”

6.1.3. Izpildes plāna izgūšana un analīze

Tagad izgūsim vaicājuma izpildes plānu no PLAN_TABLE un pamēģināsim to izanalizēt.Šoreiz plāna izgūšanai izmantosim hierarhisko vaicājumu, ar kura palīdzību mēs redzēsim

tikai to informāciju, kuru vēlamies, bez tam – tā būs ļoti korekti un skaidri attēlota un vieglāk izprotama (skat. 6.3.3.1.att.).

No izejas datu PLAN_TABLE tabulas tiek izvēlēti sekojošie lauki: OPERATIONS (vaicājuma izpildes solī izpildītās darbību nosaukums), OPTIONS (vaicājuma darbība, kas izskaidrota laukā Operation, iespējamā vērtība), OBJECT_NAME (tabulas vai indeksa nosaukums), ID (Explain Plan katra soļa identifikatora numurs), PARENT_ID (nākošā izpildes soļa identifikators, kas

42

izmanto pašreizējā soļa rezultātu), POSITION (izpildes kārtības numurs darbībām, kam ir vienāds PARENT_ID), OPTIMIZER (norāda optimizētāja esošo režīmu).

6.3.3.1.att. Izpildes plāna izgūšana vaicājumam “Select...From T1,T2 Where...” (1)

Attēlojums ir labs, tomēr tādā veidā mēs neredzam patērētos resursus un mums ir grūti saprast darbību izpildes secību. Aplūkosim to, kāds būs attēlojums, ja izsauksim Oracle instalācija mapes piedāvāto skriptu (skat. 6.3.3.2.att.).

43

6.3.3.2.att. Izpildes plāna izgūšana vaicājumam “Select...From T1,T2 Where...” (2)

Tagad, kad varam redzēt vaicājuma izpildes plānu, mēģināsim to izanalizēt.

PLĀNA ANALĪZE:Pamēģināsim izanalizēt pēc otrā izpildes plāna attēla (skat. 6.3.3.2.att.), jo esam

pārliecinājušies, ka pēc būtības rezultāts ir tāds pats, vienīgi otrajā gadījumā mēs papildus redzēsim arī patērētos resursus, ko esam izguvuši ar statistikas palīdzību.

Kā redzams - tiek attēlotas pēc kārtas veiktās darbības vaicājuma izpildē, izpildāmās darbības identifikators, tiek parādīts ari tas, kāda soļa izejas rezultātus izmanto katra atsevišķa darbība un izpildes kārtība soļiem. Pirmā darbība ir tā, kas ir pēdējā tabulas rindā. Ja divas darbības atrodas vienā līmenī, tad izpildes kārtību norāda lauka POSITION (POZICIJA) vērtība.

OPTIMIZATORS (Optimizer) kolonnā parādās informācija, ka optimizātora režīms ir uz resursu analīzi bāzēts. Atcerēsimies, ka darbības ir jālasa no koka dziļākajiem zariem.

Tātad, attēlā ir redzams, ka pirmās darbības ir TABLE ACCESS FULL PERSONAS, kas nozīmē, ka tiek atgrieztas visas rindiņas no šīs tabulas; tālāk redzam, ka seko rindiņa INDEX UNIQUE SCAN VK_PK, kas atkal ir darbība ar indeksu, nevis ar tabulu; INDEX UNIQUE SCAN NOD_PK (šī darbība nozīmē – viena ROWID izgūšana no indeksa), kas ir darbība ar indeksu, nevis ar tabulu.

Tā kā visas šīs darbības atrodas vienā līmenī, tad ir jāatceras arī to, ka viens no galvenajiem nosacījumiem darbību secības noteikšanā ir – pirmā darbība ir tā, kura ir augstāk (tajā pašā līmenī). Līdz ar to, pirmā darbība ir TABLE ACCESS FULL PERSONAS.

44

Mēģināsim apskatīt visu kopumā. Tātad, vaicājuma darbību izpildes secībai, izejot no tā izpildes plāna, ir jābūt sekojošai:

TABLE ACCESS FULL PERSONAS - tiek izgūtas visas rindas no tabulas PERSONAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan) - tiek izpildīta filtrēšana pēc definētajiem nosacījumiem: filter("P"."VARDS"='ALEKSANDRS' AND "P"."TIPS"='C' AND "P"."DZIMTE"='V' AND "P"."UZVARDS" LIKE 'RA%' AND "P"."VALSTS" LIKE 'L%').

INDEX UNIQUE SCAN VK_PK - viena ROWID izgūšana no indeksa - tiek izpildīta piekļuve tabulai, pēc identifikatoriem: access("V"."VALSTS_KODS"="P"."VALSTS"), kā arī tiek izpildīta filtrēšana pēc definētajiem nosacījumiem: filter("V"."VALSTS_KODS" LIKE 'L%').

INDEX UNIQUE SCAN NOD_PK - viena ROWID izgūšana no indeksa – tiek izpildīta piekļuve tabulai, pēc identifikatoriem: access("P"."NODALAS_ID"="N"."ID").

NESTED LOOPS – savienošanas darbības, kas akceptē divas rindu kopas, ārējo kopu un iekšējo kopu. Oracle salīdzina katru ārējās kopas rindu ar katru iekšējās kopas rindu un atgriež rindas, kas apmierina nosacījumu. Pēc būtības tās ir tabulu savienošanas (šajā gadījumā tiek savienotas tabulas pēc atlasītajiem indeksiem tabulās NODAĻAS un PERSONAS) darbības.

TABLE ACCESS BY INDEX ROWID NODALAS - tiek izgūtas rindas, kas bāzētas uz to ROWID izgūšanu no tabulas – tiek izpildīta filtrēšana pēc definētajiem nosacījumiem: filter("N"."PILSETA"='Riga').

NESTED LOOPS – savienošanas darbības, kas akceptē divas rindu kopas, ārējo kopu un iekšējo kopu. Oracle salīdzina katru ārējās kopas rindu ar katru iekšējās kopas rindu un atgriež rindas, kas apmierina nosacījumu. Pēc būtības tās ir tabulu savienošanas (šajā gadījumā tiek savienotas atlasītās rindas no tabulas NODAĻAS un atlasītās rindas no iepriekšējiem savienojumiem) darbības.

SORT ORDER BY – atlasītā rindu kopa tiek sašķirota pēc uzdotajām vērtībām - no tabulas NODALAS pēc lauka ‘nodala’.

SELECT STATEMENT – vajadzīgo datu izvade uz ekrāna.

6.1.4. Izpildes plāna iegūšana, izmantojot uz likumiem balstītu pieeju (RULE)

Lai pārbaudītu šī vaicājuma izpildi, izmantojot uz likumiem balstītu pieeju, sākumā mums vajadzētu konfigurēt optimizātoru (skat. 6.3.4.1.att.).

6.3.4.1.att. Optimizatora konfigurēšana vaicājumam “Select...From T1,T2 Where...”

Tādā pašā izpildām darbību izpildes plāna iegūšanai, kā to darījām iepriekš, vienīgi dodam šim plānam identifikatoru (STATEMENT_ID) ‘1VAIC_2’, lai varētu to vieglāk izgūt. Tālāk atkal izpildām tā paša skripta palaišanu un iegūstam izpildes plānu vaicājumam ar “Select...From T1,T2 Where..”. Tikai šoreiz mēs varēsim jau aplūkot to, kādu pieeju izvēlēsies pats optimizātors (skat. 6.4.4.2.att.).

45

6.3.5.2.att. Izpildes plāna izgūšana vaicājumam ar vaicājumam “Select...From T1,T2 Where...” (uz likumiem balstīta pieeja)

To, ka tā ir uz likumiem balstīta pieeja, mēs varam redzēt pašā tabulas apakšā (redzam – RULE BASED OPTIMIZER USED).

Ja salīdzinām šo izpildes plānu ar 6.4.3.2.attēlā attēloto izpildes plānu šim pašam vaicājumam, tad šeit ir izmainījusies vienīgi operāciju secība. Ja pirmajā gadījumā pirmā izpildījās TABLE ACCESS FULL PERSONAS, tad INDEX UNIQUE SCAN VK_PK, tad INDEX UNIQUE SCAN NOD_PK (šīs trīs darbības bija izpildāmas vienā līmenī), un kā nākošā (nākošajā līmenī) bija NESTED LOOPS un TABLE ACCESS BY INDEX DOWID NODALAS, tad otrajā gadījumā par pirmo kļuva jau INDEX UNIQUE SCAN NOD_PK, tad (vienā līmenī) TABLE ACCESS FULL PERSONAS un TABLE ACCESS BY INDEX ROWID NODAĻAS, tad, nākošajā līmenī NESTED LOOPS un INDEX UNIQUE SCAN VK_PK. Šī darbību izmaiņas secība būtībā izmaina tikai to, ka tā sāk atlasi no indeksiem, nevis izvēlās uzreiz visas rindas no tabulas un tad tikai izvēlās nepieciešamās pēc indeksiem.

Izpildes plāns vaicājumam ar „Exists”



46

Vaicājuma kods:

Select a.videja_alga, a.nod_izsniedzfrom algas awhere exists (Select n.nodala, n.idfrom nodalas nwhere ((n.pilseta='Saulkrasti') and (n.id=a.nod_izsniedz)))

Vaicājuma realizācijā piedalās divas tabulas – ALGAS un NODAĻAS. Tātad, ģenerēsim statistiku šīm tabulām (skat. 6.4.1.1.att.).

6.4.1.1.att. Statistikas ģenerēšana vaicājumam ar “Exists”

Šajā gadījumā statistikas iegūšana notika ļoti ātri.


Optimizātors paliek nokonfigurēts uz resursu analīzes balstīto pieeju, kura izmanto statistiku.


6.4.2.1.att. Izpildes plāna iegūšana vaicājumam ar “Exists”


Tagad izgūsim vaicājuma izpildes plānu no PLAN_TABLE un pamēģināsim to izanalizēt.

47

Šoreiz plāna izgūšanai uzreiz izmantosim Oracle piedāvāto skriptu (utlxpls.sql), kuru izsaucot, tiek attēlots pēdējais iegūtais izpildes plāns (skat. 6.4.3.1.att.). Ar šo plāna izgūšanas metodi mēs varam redzēt arī izpildāmo darbību līmeņus (pirmās ir tās, kuras ir ‘dziļāk’ kokā).

6.4.3.1.att. Izpildes plāna izgūšana vaicājumam ar “Exists”

Tagad, kad varam redzēt vaicājuma izpildes plānu, mēģināsim to izanalizēt.Šoreiz gan sīki neskaidrošu katru darbību vai darbības izvēles secību, ja līdzīgi gadījumi bija

izskaidroti iepriekšējos izpildes plānos. Vairāk pievērsīšos tam, kas vēl nav ticis aprakstīts. Tā pat sniegšu pilnu darbību izpildes secību sarakstu.

PLĀNA ANALĪZE:Redzam, ka TABLE ACCESS FULL ALGAS un TABLE ACCESS FULL NODALAS ir vienā līmenī.

Tātad arī šajā gadījumā pirmā darbība ir tā, kura ir augstāk (tajā pašā līmenī). Tālāk mums parādās jauna rinda – HASH JOIN RIGHT SEMI, kas nozīmē to, ka (uz

resursiem balstītās pieejas gadījumā) tiek izmantota darbība HASH JOIN, kas savieno divas rindu kopas un atgriež rezultātus, izmantojot heš funkciju, jeb heš tabulu savienojumu.


TABLE ACCESS FULL ALGAS - tiek izgūtas visas rindas no tabulas ALGAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan).

TABLE ACCESS FULL NODALAS - tiek izgūtas visas rindas no tabulas NODALAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan) - tiek izpildīta filtrēšana pēc definētajiem nosacījumiem: filter("N"."PILSETA"='Saulkrasti').

48

HASH JOIN RIGHT SEMI - tiek izmantota darbība HASH JOIN, kas savieno divas rindu kopas (no tabulām NODAĻAS un ALGAS) un atgriež rezultātus, izmantojot heš funkciju, jeb heš tabulu savienojumu - tiek izpildīta piekļuve tabulai, pēc identifikatoriem: access("N"."ID"="A"."NOD_IZSNIEDZ").




6.4.4.1.att. Optimizatora konfigurēšana vaicājumam “Exists”

Tādā pašā veidā izpildām darbību izpildes plāna iegūšanai, kā to darījām iepriekš, vienīgi dotam šim plānam identifikatoru (STATEMENT_ID) ‘2VAIC_1’, lai varētu to vieglāk izgūt. Tālāk atkal izpildām tā paša skripta palaišanu un iegūstam izpildes plānu vaicājumam ar “Exists”, tikai izmantojot uz likumiem balstītu pieeju (skat. 6.4.4.2.att.).

49

6.4.4.2.att. Izpildes plāna izgūšana vaicājumam ar vaicājumam “Exists” (uz likumiem balstīta pieeja)


Ja salīdzinām šo izpildes plānu ar 6.4.3.1.attēlā attēloto izpildes plānu šim pašam vaicājumam, tad šeit ir ievērojamas izmaiņas. Sāksim ar to, ka notiek ierakstu atlase pēc unikāliem identifikatoriem ar INDEX UNIQUE SCAN NOD_PK, kas ne vienmēr ir labi, sevišķi tad, ja katrai vienai rindai no vienas kopas atbilst vairākas no citas. Tad tas var izraisīt ļoti garu darbību secību. Šajā gadījumā tiek realizēta piekļuve tabulām, izmantojot identifikatorus, tādejādi apmierinot nosacījumus: access("N"."ID"=:B1). Pēc tam, kad ir veikta rindu atlase no tabulas ALGAS, notiek tabulas NODALAS vienas rindas atrašana pēc indeksa ar TABLE ACCESS BY INDEX ROWID NODALAS, izpildot filstrēšanu pēc nosacījumiem: filter("N"."PILSETA"='Saulkrasti').

Ja pirmajā gadījumā tiktu pielietota operācija HASH JOIN RIGHT SEMI, kopu savienošanai, tad šajā gadījumā jau tiek izmantota operācija FILTER, kura veic rindu kopu akceptēšanu,

50

izslēdzot dažas no tām un atgriežot pārējās, kuras atbilst vaicājumā uzdotajiem nosacījumiem. Šajā gadījumā tiek izpildīta filtrēšana pēc definētajiem nosacījumiem: filter( EXISTS (SELECT 0 FROM "NODALAS" "N" WHERE "N"."ID"=:B1 AND "N"."PILSETA"='Saulkrasti')).

Uzskatu, ka pirmā veida izpildes plāns tomēr ir labāks, jo ir jācenšas atteikties no unikālu indeksu pārmeklēšanas, sevišķi tad, ja tabulu ierakstu skaits ir ļoti liels.

Izpildes plāns vaicājumam ar „Group by Cube”



Vaicājuma kods:

select v.valsts_nos, p.dzimte, count(p.dzimte) as Personasfrom valstis v, personas pwhere p.valsts=v.valsts_kodsgroup by cube(v.valsts_nos, p.dzimte)

Vaicājuma realizācijā piedalās divas tabulas – VALSTIS un PERSONAS. Tātad, ģenerēsim statistiku šīm tabulām (skat. 6.5.1.1.att.).

6.5.1.1.att. Statistikas ģenerēšana vaicājumam ar “Group By Cube”

Šajā gadījumā statistikas iegūšana atkal ieilga, kad bija jāieņem statistika no tabulas PERSONAS.


Optimizātors paliek nokonfigurēts uz resursu analīzei balstīto pieeju, kura izmanto statistiku.


51

6.4.2.1.att. Izpildes plāna iegūšana vaicājumam ar “Group By Cube”


Tagad izgūsim vaicājuma izpildes plānu no PLAN_TABLE un pamēģināsim to izanalizēt.Šoreiz plāna izgūšanai uzreiz izmantosim Oracle piedāvāto skriptu (utlxpls.sql), kuru

izsaucot, tiek attēlots pēdējais iegūtais izpildes plāns (skat. 6.5.3.1.att.). Ar šo plāna izgūšanas metodi mēs varam redzēt arī izpildāmo darbību līmeņus (pirmās ir tās, kuras ir ‘dziļāk’ kokā).

6.5.3.1.att. Izpildes plāna izgūšana vaicājumam ar “Group By Cube”

Tagad, kad varam redzēt vaicājuma izpildes plānu, mēģināsim to izanalizēt.Sīki neskaidrošu katru darbību vai darbības izvēles secību, ja līdzīgi gadījumi bija


52

PLĀNA ANALĪZE:Šajā izpildes plānā redzam jaunu ierakstu – GENERATE CUBE, kas nozīmē to, ka šajā vietā

vaicājuma izpildes gaitā tiek uzģenerēts, jeb izveidots kubs no nepieciešamajiem datiem, kuri pirms tam jau ir izvēlēti.


TABLE ACCESS FULL VALSTIS - tiek izgūtas visas rindas no tabulas VALSTIS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan).

TABLE ACCESS FULL PERSONAS - tiek izgūtas visas rindas no tabulas PERSONAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan).

HASH JOIN - tiek izmantota darbība HASH JOIN, kas savieno divas rindu kopas (no tabulām VALSTIS un PERSONAS) un atgriež rezultātus, izmantojot heš funkciju, jeb heš tabulu savienojumu - tiek izpildīta piekļuve tabulai, pēc identifikatoriem: access("P"."VALSTS"="V"."VALSTS_KODS").

SORT GROUP BY – rindu kopas tiek sašķirotas grupās, jo vaicājumā ir GROUP BY parametrs, proti, rindas tiek grupētas tā, lai no tām varētu izveidot kubu.

GENERATE CUBE – tiek izveidots kubs no iegūtajiem datiem. SORT GROUP BY – rindu kopas tiek sašķirotas grupās, jo vaicājumā ir GROUP BY

parametrs, proti, rindas tiek grupētas pēc ‘v.valsts_nos’ un ‘p.dzimte’ parametriem. SELECT STATEMENT – vajadzīgo datu izvade uz ekrāna.



6.5.4.1.att. Optimizatora konfigurēšana vaicājumam ar “Group By Cube”

Tādā pašā veidā izpildām darbību izpildes plāna iegūšanai, kā to darījām iepriekš, vienīgi dotam šim plānam identifikatoru (STATEMENT_ID) ‘3VAIC_1’, lai varētu to vieglāk izgūt. Tālāk atkal izpildām hierarhisko vaicājumu un iegūstam izpildes plānu vaicājumam ar „Group by Cube”, tikai izmantojot uz likumiem balstītu pieeju (skat. 6.5.4.2.att.).

53

6.5.4.2.att. Izpildes plāna izgūšana vaicājumam ar “Group By Cube” (uz likumiem balstīta pieeja)

To, ka tā ir uz likumiem balstīta pieeja, mēs varam redzēt pašā tabulas pirmajā rindā, ailē OPTIMIZATORS (redzam – RULE).

Ja salīdzinām šo izpildes plānu ar 6.5.3.1.attēlā attēloto izpildes plānu šim pašam vaicājumam, tad mēs neredzam pilnīgi nekādu atšķirību, tātad plāni ir pilnīgi vienādi.

Izpildes plāns vaicājumam ar „Over”



Vaicājuma kods:

select v.valsts_nos, p.dzimte, count(p.dzimte) as Personasfrom valstis v, personas pwhere p.valsts=v.valsts_kodsgroup by cube(v.valsts_nos, p.dzimte)

Vaicājuma realizācijā piedalās trīs tabulas – ALGAS, NODAĻAS un PERSONAS. Tātad, ģenerēsim statistiku šīm tabulām (skat. 6.6.1.1.att.).

54

6.6.1.1.att. Statistikas ģenerēšana vaicājumam ar “Over”

Šajā gadījumā statistikas iegūšana atkal ieilga, kad bija jāieņem statistika no tabulas PERSONAS.




6.6.2.1.att. Izpildes plāna iegūšana vaicājumam ar “Over”


Tagad izgūsim vaicājuma izpildes plānu no PLAN_TABLE un pamēģināsim to izanalizēt.

55

Šoreiz plāna izgūšanai izmantosim Oracle piedāvāto skriptu (utlxpls.sql), kuru izsaucot, tiek attēlots pēdējais iegūtais izpildes plāns (skat. 6.6.3.1.att.). Ar šo plāna izgūšanas metodi mēs varam redzēt arī izpildāmo darbību līmeņus (pirmās ir tās, kuras ir ‘dziļāk’ kokā).

6.4.3.1.att. Izpildes plāna izgūšana vaicājumam ar “Over”

Tagad, kad varam redzēt vaicājuma izpildes plānu, mēģināsim to izanalizēt. Acīmredzami ir tas, ka iegūtais plāns ir daudz sarežģītāks, nekā iepriekš iegūtie vaicājumu izpildes plāni.

Šoreiz gan sīki neskaidrošu katru darbību vai darbības izvēles secību, ja līdzīgi gadījumi bija izskaidroti iepriekšējos izpildes plānos. Vairāk pievērsīšos tam, kas vēl nav ticis aprakstīts. Tā pat sniegšu pilnu darbību izpildes secību sarakstu.

PLĀNA ANALĪZE:Mēs redzam, ka ir parādījusies rinda HASH GROUP BY. Šī darbība nozīmē to, ka tiek

savienotas ierakstu kopas grupās, tādējādi ļaujot izpildīt vaicājuma izvades rezultāta grupēšanu pēc GROUP BY nosacījuma. Tādējādi, šī darbība notiek, izmantojot heš funkcijas.

56

Tā pat mums ir parādījies uzraksts INDEX RANGE SCAN NOD_PK. Operācija RANGE SCAN nozīmē to, ka tiek veikta viena vai vairāku ROWID iegūšana no indeksa. Indeksa vērtības tiek pārmeklētas augošā secībā. Šajā gadījumā tiek izpildīta piekļuve tabulām, pēc nodaļu identifikatoriem, apmierinot definētos nosacījumus.

Ir arī jauna rinda WINDOWS SORT, kas nozīto to, ka šeit tiek attēlots piemērots mehānisms tam, lai pielietotu analītisko funkciju. Tātad, izmantojot logus (WINDOW), tiek veikta atlase un tiek pielietota analītiskā funkcija RANK().

Tā pat, attēlotais INLIST ITERATOR uzraksts nozīmē to, ka tālākā operācija (Table Access Full PERSONAS) atkārtojas priekš katras vērtības, kura ir sastopama IN saraksta predikātā – mūsu gadījumā IN sarakstā ir tikai viena vērtība – ‘EST’.


INDEX RANGE SCAN NOD_PK – tiek veikta viena vai vairāku ROWID iegūšana no indeksa. Indeksa vērtības tiek pārmeklētas augošā secībā - tiek izpildīta piekļuve tabulām, pēc nodaļu identifikatoriem, apmierinot definētos nosacījumus: access("N"."ID"=1 OR "N"."ID"=6 OR "N"."ID"=12 OR "N"."ID"=17 OR "N"."ID"=21 OR "N"."ID"=24 OR "N"."ID"=27 OR "N"."ID"=32 OR "N"."ID"=36 OR "N"."ID"=39 OR "N"."ID"=40).

TABLE ACCESS BY INDEX ROWID NODALAS - tiek izgūtas rindas, kas bāzētas uz to ROWID izgūšanu no tabulas NODAĻAS, attiecīgi kolonnas ‘nodalas’.

TABLE ACCESS FULL ALGAS - tiek izgūtas visas rindas no tabulas ALGAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan) - tiek izpildīta filtrēšana pēc definētajiem nosacījumiem: filter("A"."NOD_IZSNIEDZ"=1 OR "A"."NOD_IZSNIEDZ"=6 OR "A"."NOD_IZSNIEDZ"=12 OR "A"."NOD_IZSNIEDZ"=17 OR "A"."NOD_IZSNIEDZ"=21 OR "A"."NOD_IZSN IEDZ"=24 OR "A"."NOD_IZSNIEDZ"=27 OR "A"."NOD_IZSNIEDZ"=32 OR "A"."NOD_IZSNIED Z"=36 OR "A"."NOD_IZSNIEDZ"=39 OR "A"."NOD_IZSNIEDZ"=40).

INLIST ITERATOR - tālākā operācija (Table Access Full PERSONAS) atkārtojas priekš katras vērtības, kura ir sastopama IN saraksta predikātā.

TABLE ACCESS FULL PERSONAS - tiek izgūtas visas rindas no tabulas PERSONAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan) - tiek izpildīta filtrēšana pēc definētajiem nosacījumiem: filter("P"."VALSTS"='EST' AND ("P"."NODALAS_ID"=1 OR "P"."NODALAS_ID"=6 OR "P"."NODALAS_ID"=12 OR "P"."NODALAS_ID"=17 OR "P"."NODALAS_ID"=21 OR "P"."NODALAS_ID"=24 OR "P"."NODALAS_ID"=27 OR "P"."NODALAS_ID"=32 OR "P"."NODALAS_ID"=36 OR "P"."NODALAS_ID"=39 OR "P"."NODALAS_ID"=40).

HASH JOIN - tiek izmantota darbība HASH JOIN, kas savieno divas rindu kopas (no tabulām NODAĻAS un ALGAS) un atgriež rezultātus, izmantojot heš funkciju, jeb heš tabulu savienojumu - tiek izpildīta piekļuve tabulām, pēc identifikatoriem: access("N"."ID"="A"."NOD_IZSNIEDZ").

HASH JOIN - tiek izmantota darbība HASH JOIN, kas savieno divas rindu kopas (no tabulām NODAĻAS un PERSONAS) un atgriež rezultātus, izmantojot heš funkciju, jeb heš tabulu savienojumu - tiek izpildīta piekļuve tabulām, pēc identifikatoriem: access("N"."ID"="P"."NODALAS_ID").

HASH GROUP BY – tiek savienotas ierakstu kopas grupās, tādā veidā izpildot vaicājuma izvades rezultātu grupēšanu pēc GROUP BY nosacījuma (‘n.nodala’ un ‘n.pilseta’), izmantojot heš funkcijas.

57

WINDOW SORT – tiek attēlots piemērots mehānisms tam, lai pielietotu analītisko funkciju. Tātad, izmantojot logus (WINDOW), tiek veikta atlase un tiek pielietota analītiskā funkcija RANK().




6.6.4.1.att. Optimizatora konfigurēšana vaicājumam ar “Over”

Tādā pašā veidā izpildām darbību izpildes plāna iegūšanai, kā to darījām iepriekš, vienīgi dotam šim plānam identifikatoru (STATEMENT_ID) ‘4VAIC_1’, lai varētu to vieglāk izgūt. Tālāk atkal izpildām tā paša skripta palaišanu un iegūstam izpildes plānu vaicājumam ar “Over”, tikai izmantojot uz likumiem balstītu pieeju (skat. 6.6.4.2.att.).

58

6.6.4.2.att. Izpildes plāna izgūšana vaicājumam ar vaicājumam ar “Over” (uz likumiem balstīta pieeja)


Ja salīdzinām šo izpildes plānu ar 6.6.3.1.attēlā attēloto izpildes plānu šim pašam vaicājumam, tad mēs redzam, ka tika izvadīts ļoti liela apjoma izpildes plāns. Tas ietver 91 izpildes darbību, kas ir ļoti daudz, salīdzinājumā ar gadījumu, kad tiek izmantota uz resursiem balstīta pieeja. Tik daudzas darbības notiek, jo nepārtraukti tiek veikta unikāla indeksu atlase, salīdzinājumā ar kopas atlasi pirmajā gadījumā (ar INDEX RANGE SCAN). Līdz ar to šeit uzreiz varētu secināt, ka uz resursu analīzi balstīta pieeja šim vaicājumam ir daudz reižu labāka.

Izpildes plāns vaicājumam ar Hierarhiju



Vaicājuma kods:

select id, nod_kods, nodala, pilseta, levelfrom nodalaswhere pilseta IN ('Riga')start with nod_kods is null connect by prior id=nod_kodsorder by level

Vaicājuma realizācijā piedalās viena tabula – NODAĻAS. Tātad, ģenerēsim statistiku šīm tabulām (skat. 6.7.1.1.att.).

6.7.1.1.att. Statistikas ģenerēšana vaicājumam ar Hierarhiju

Šajā gadījumā statistikas iegūšana nebija ilga.




59

6.7.2.1.att. Izpildes plāna iegūšana vaicājumam ar Hierarhiju


Tagad izgūsim vaicājuma izpildes plānu no PLAN_TABLE un pamēģināsim to izanalizēt.Šoreiz plāna izgūšanai izmantosim Oracle piedāvāto skriptu (utlxpls.sql), kuru izsaucot,

tiek attēlots pēdējais iegūtais izpildes plāns (skat. 6.7.3.1.att.). Ar šo plāna izgūšanas metodi mēs varam redzēt arī izpildāmo darbību līmeņus (pirmās ir tās, kuras ir ‘dziļāk’ kokā).

6.7.3.1.att. Izpildes plāna izgūšana vaicājumam ar vaicājumam ar Hierarhiju60

Tagad, kad varam redzēt vaicājuma izpildes plānu, mēģināsim to izanalizēt, taču piebildīšu vēl to, ka arī šis izpildes plāns nav no vienkāršākajiem.

Sīki neskaidrošu katru darbību vai darbības izvēles secību, ja līdzīgi gadījumi bija izskaidroti iepriekšējos izpildes plānos. Vairāk pievērsīšos tam, kas vēl nav ticis aprakstīts. Tā pat sniegšu pilnu darbību izpildes secību sarakstu.

PLĀNA ANALĪZE:Mēs redzam, ka mums ir divu veidu CONNECT BY uzraksti. Pēc savas būtības, CONNECT BY

atlasa ierakstus hierarhiskajā secībā priekš vaicājumiem, kuri ietver CONNECT BY nosacījumu. CONNECT BY FILTERING veic hierarhisko vaicājumu savienošanu un filtrēšanu, savukārt CONNECT BY PUMP veic tikai hierarhisko savienošanu ar sevi.

Cita jaunā operācija FILTER veic rindu kopu akceptēšanu, izslēdzot dažas no tām un atgriežot pārējās, kuras atbilst vaicājumā uzdotajiem nosacījumiem.


TABLE ACCESS FULL NODALAS - tiek izgūtas visas rindas no tabulas NODAĻAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan).

CONNECT BY PUMP - veic tikai hierarhisko savienošanu ar sevi, tādējādi atlasot datus hierarhiskā secībā.


FILTER - veic rindu kopu akceptēšanu, izslēdzot dažas no tām un atgriežot pārējās, kuras atbilst vaicājumā uzdotajiem nosacījumiem - tiek izpildīta filtrēšana pēc nosacījuma: filter("NOD_KODS" IS NULL).

HASH JOIN - tiek izmantota darbība HASH JOIN, kas savieno divas rindu kopas (no tabulas NODAĻAS, savienojot to pašu ar sevi, kā sakni definējot to, kurai nav vecāku) un atgriež rezultātus, izmantojot heš funkciju, jeb heš tabulu savienojumu - tiek izpildīta piekļuve tabulām, pēc identifikatoriem: access("NOD_KODS"=NULL).


CONNECT BY FILTERING - veic hierarhisko vaicājumu savienošanu un filtrēšanu, tādējādi atlasot datus hierarhiskā secībā - tiek izpildīta filtrēšana pēc nosacījuma: filter("NOD_KODS" IS NULL).

FILTER - veic rindu kopu akceptēšanu, izslēdzot dažas no tām un atgriežot pārējās, kuras atbilst vaicājumā uzdotajiem nosacījumiem - tiek izpildīta filtrēšana pēc definētajiem nosacījumiem: filter("PILSETA"='Riga').




61

6.7.4.1.att. Optimizatora konfigurēšana vaicājumam ar Hierarhiju

Tādā pašā veidā izpildām darbību izpildes plāna iegūšanai, kā to darījām iepriekš, vienīgi dotam šim plānam identifikatoru (STATEMENT_ID) ‘5VAIC_1’, lai varētu to vieglāk izgūt. Tālāk atkal izpildām tā paša skripta palaišanu un iegūstam izpildes plānu vaicājumam ar Hierarhiju, tikai izmantojot uz likumiem balstītu pieeju (skat. 6.7.4.2.att.).

62

6.7.4.2.att. Izpildes plāna izgūšana vaicājumam ar vaicājumam ar Hierarhiju (uz likumiem balstīta pieeja)


Ja salīdzinām šo izpildes plānu ar 6.7.3.1.attēlā attēloto izpildes plānu šim pašam vaicājumam, tad acīmredzams ir tas, ka ir izmainījies tas, ka HASH JOIN operācija, kura tika realizēta balstoties uz resursu analīzes bāzētu pieeju, tiek aizvietota uzreiz ar divām citām – BUFFER SORT un NESTED LOOPS. Līdz ar to, nedaudz izmainās arī darbību izpildes secība. Šeit sākumā tiek sastādīta bāze hierarhiskajam vaicājumam ar CONNECT BY PUMP palīdzību, tad ar

63

TABLE ACCESS FULL NODALAS tiek atlasītas visas rindas, un ar BUFFER SORT sakārto datus, ko atgriež CONNECT BY PUMP, tātad, pēc hierarhiskās struktūras. Pēc tam atkal notiek NESTED LOOP un tālākās operācijas, kas neatšķiras no pirmā gadījuma beigu izpildes operācijām.

Izpildes plāns vaicājumam ar pakārtotu vaicājumu „FROM” rindā



Vaicājuma kods:

Select p.id, INITCAP(p.vards||' '||p.uzvards) as Persona, p.valsts, p.kategorijafrom personas b, (select a.id, a.vards, a.uzvards, a.valsts, a.kategorija, n.nodalafrom personas a, nodalas nwhere (a.kategorija='A' and n.id=6)) pwhere b.id=p.id and (p.valsts='GBR' and (p.vards LIKE 'VIKTORIJA' and p.uzvards like 'RA%'))

Vaicājuma realizācijā piedalās divas tabulas – PERSONAS un NODAĻAS. Tātad, ģenerēsim statistiku šīm tabulām (skat. 6.8.1.1.att.).

6.8.1.1.att. Statistikas ģenerēšana vaicājumam ar pakārtotu vaicājumu „FROM” rindā

Ari šeit statistikas iegūšana atkal ieilga, kad bija jāieņem statistika no tabulas PERSONAS.




64

6.8.2.1.att. Izpildes plāna iegūšana vaicājumam ar pakārtotu vaicājumu „FROM” rindā




6.8.3.1.att. Izpildes plāna izgūšana vaicājumam ar vaicājumam ar pakārtotu vaicājumu „FROM” rindā

65



PLĀNA ANALĪZE:Pēc iegūtā izpildes plāna secinām, ka visas darbībām mums ir vairāk vai mazāk skaidras un

saprotamas. Bez tam, šis izpildes plāns ir diezgan vienkāršs un visas operāciju īpašības jau tika iepriekš izskatītas


INDEX UNIQUE SCAN NOD_PK - viena ROWID izgūšana no indeksa – tiek izpildīta piekļuve tabulai, pēc identifikatoriem, apmierinot definētos nosacījumus: access("N"."ID"=6); arī TABLE ACCESS FULL PERSONAS - tiek izgūtas visas rindas no tabulas PERSONAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan).

TABLE ACCESS FULL PERSONAS - tiek izgūtas visas rindas no tabulas PERSONAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan) - tiek izpildīta filtrēšana pēc nosacījuma: filter("A"."VARDS" LIKE 'VIKTORIJA' AND "A"."VALSTS"='GBR' AND "A"."KATEGORIJA"='A' AND "A"."UZVARDS" LIKE 'RA%').

NESTED LOOPS – notiek savienošanas darbības, kas akceptē divas rindu kopas, ārējo kopu un iekšējo kopu. Oracle salīdzina katru ārējās kopas rindu ar katru iekšējās kopas rindu un atgriež rindas, kas apmierina nosacījumu. Pēc būtības tās ir tabulu savienošanas (šajā gadījumā tiek savienotas tabulas NODAĻAS un PERSONAS) darbības.

HASH JOIN - tiek izmantota darbība HASH JOIN, kas savieno divas rindu kopas (no tabulām PERSONAS un pakārtotā SELECT vaicājuma atlasītajām rindu kopām) un atgriež rezultātus, izmantojot heš funkciju, jeb heš tabulu savienojumu - tiek izpildīta piekļuve tabulām, pēc identifikatoriem: access("B"."ID"="A"."ID").




6.8.4.1.att. Optimizatora konfigurēšana vaicājumam ar pakārtotu vaicājumu „FROM” rindā

Tādā pašā veidā izpildām darbību izpildes plāna iegūšanai, kā to darījām iepriekš, vienīgi dotam šim plānam identifikatoru (STATEMENT_ID) ‘6VAIC_1’, lai varētu to vieglāk izgūt. Tālāk

66

atkal izpildām tā paša skripta palaišanu un iegūstam izpildes plānu vaicājumam ar pakārtotu vaicājumu „FROM” rindā, tikai izmantojot uz likumiem balstītu pieeju (skat. 6.8.4.2.att.).

6.8.4.2.att. Izpildes plāna izgūšana vaicājumam ar vaicājumam ar pakārtotu vaicājumu „FROM” rindā (uz likumiem balstīta pieeja)


Ja salīdzinām šo izpildes plānu ar 6.8.3.1.attēlā attēloto izpildes plānu šim pašam vaicājumam, tad plāni nedaudz atšķiras. Ja pirmās trīs darbības ir nemainīgas, tad tālāk mēs jau redzam izmaiņas. Pirmkārt, pēc INDEX UNIQUE SCAN NOD_PK, TABLE ACCESS FULL PERSONAS un NESTED LOOPS operācijām tiek veikta SORT JOIN, kas ir nepieciešama tam, lai sašķirotu rindu kopas pirms MERGE JOIN operācijas. Šajā gadījumā tiek nodrošināta piekļuve tabulām pēc

67

identifikatoriem: access(„B”.”ID”=’A”.”ID”). Tad atkal notiek SORT JOIN, savienojot divas vaicājuma daļas. Pēc tam notiek MERGE JOIN operācija, kura saņem divas rindu kopas, kura katra ir sašķirota pēc specifiskās vērtības. Šīs divas rindu kopas tiek sakombinētas sekojoši - katra rinda no vienas kopas ar atbilstošām rindām no citas kopas. Rezultātā tiek atgriezta jau savienotā kopa.

Šis paņēmiens ir nedaudz garāks un sarežģītāks, taču kāds no tiem ir labāks, ir grūti noteikt.

Izpildes plāns vaicājumam ar pakārtotu vaicājumu „SELECT” rindā



Vaicājuma kods:

SELECT n.id, n.nodala, n.pilseta,(SELECT sum(a.videja_alga)from algas awhere n.id=a.nod_izsniedz) as algu_izmaksasfrom nodalas nwhere n.id in (1,5,10,15,20,25,30,35,40)

Vaicājuma realizācijā piedalās divas tabulas – ALGAS un NODAĻAS. Tātad, ģenerēsim statistiku šīm tabulām (skat. 6.9.1.1.att.).

6.9.1.1.att. Statistikas ģenerēšana vaicājumam ar pakārtotu vaicājumu „SELECT” rindā

Statistikas iegūšana nebija ilga.




68

6.9.2.1.att. Izpildes plāna iegūšana vaicājumam ar pakārtotu vaicājumu „SELECT” rindā




6.9.3.1.att. Izpildes plāna izgūšana vaicājumam ar vaicājumam ar pakārtotu vaicājumu „SELECT” rindā

Tagad, kad varam redzēt vaicājuma izpildes plānu, mēģināsim to izanalizēt.

69

Sīki neskaidrošu katru darbību vai darbības izvēles secību, ja līdzīgi gadījumi bija izskaidroti iepriekšējos izpildes plānos. Vairāk pievērsīšos tam, kas vēl nav ticis aprakstīts. Tā pat sniegšu pilnu darbību izpildes secību sarakstu.


saprotamas. Bez tam, šis izpildes plāns ir diezgan vienkāršs.Mums ir tikai viena jauna operācija SORT AGGREGATE, kas nozīmē to, ka šeit tiek atlasīta

viena rinda, kura ir grupēšanas funkcijas pielietošanas rezultāts. Grupēšanas funkcija šeit ir notikusi ar nolūku – sagrupēt visas izvēlētās rindas.


INDEX RANGE SCAN NOD_PK – tiek veikta viena vai vairāku ROWID iegūšana no indeksa. Indeksa vērtības tiek pārmeklētas augošā secībā - tiek izpildīta piekļuve tabulām, pēc identifikatoriem: access("N"."ID"=1 OR "N"."ID"=5 OR "N"."ID"=10 OR "N"."ID"=15 OR "N"."ID"=20 OR "N"."ID"=25 OR "N"."ID"=30 OR "N"."ID"=35 OR "N"."ID"=40).

TABLE ACCESS FULL ALGAS - tiek izgūtas visas rindas no tabulas ALGAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan) - tiek izpildīta filtrēšana pēc nosacījuma: filter("A"."NOD_IZSNIEDZ"=:B1).

TABLE ACCESS BY INDEX ROWID NODALAS - tiek izgūtas rindas, kas bāzētas uz to ROWID izgūšanu no tabulas NODAĻAS, attiecīgi kolonnas ‘nodalas’.

SORT AGGREGATE - vienas rindas atlase, kura ir grupēšanas funkcijas pielietošanas rezultāts, lai sagrupētu izvēlētās rindas.

INLIST ITERATOR - operācija atkārtojas priekš katras vērtības, kura ir sastopama IN saraksta predikātā (tiek pārmeklēti nodaļu identifikācijas numuri).




6.9.4.1.att. Optimizatora konfigurēšana vaicājumam ar pakārtotu vaicājumu „SELECT” rindā

Tādā pašā veidā izpildām darbību izpildes plāna iegūšanai, kā to darījām iepriekš, vienīgi dotam šim plānam identifikatoru (STATEMENT_ID) ‘7VAIC_1’, lai varētu to vieglāk izgūt. Tālāk atkal izpildām tā paša skripta palaišanu un iegūstam izpildes plānu vaicājumam ar pakārtotu vaicājumu „SELECT” rindā, tikai izmantojot uz likumiem balstītu pieeju (skat. 6.9.4.2.att.).

70

6.9.4.2.att. Izpildes plāna izgūšana vaicājumam ar vaicājumam ar pakārtotu vaicājumu „SELECT” rindā (uz likumiem balstīta pieeja)

71


Ja salīdzinām šo izpildes plānu ar 6.9.3.1.attēlā attēloto izpildes plānu šim pašam vaicājumam, tad plāni atšķiras. Redzam, ka tam, lai īstenotu IN predikāta saraksta nosacījumu pārbaudi, ir veiktas vairākas atkārtotās darbības viena pēc otras (INDEX UNIQUE SCAN NOD_PK un TABLE ACCESS BY INDEX ROWID NODALAS). Tad, ar CONCATENATION operāciju, tika atlasītas dašādas rindu kopas, kuras atgriež kopēju apvienotu kopu.

Līdz ar to, INDEX RANGE SCAN un INLIST ITERATOR operāciju izpilde gadījumā, ja plāns tiek iegūts balstoties uz resursu analīzes bāzētu pieeju, manāmi samazina darbību skaitu. Otrajā gadījumā, tiek veikta identifikatoru atlase pēc unikālām vērtībām, savukārt pirmajā gadījumā – tiek veikta veselas kopas atlase uzreiz. Līdz ar to, šim vaicājumam – labāka ir uz resursu analīzes bāzēta pieeja.

Izpildes plāns vaicājumam ar pakārtotu vaicājumu „HAVING” rindā



Vaicājuma kods:

select id, min(videja_alga) as algafrom algaswhere nod_izsniedz IN (39) group by idhaving min(videja_alga) < (Select avg(videja_alga)from algaswhere nod_izsniedz IN (39))

Vaicājuma realizācijā piedalās viena tabula – ALGAS. Tātad, ģenerēsim statistiku šīm tabulām (skat. 6.10.1.1.att.).

6.10.1.1.att. Statistikas ģenerēšana vaicājumam ar pakārtotu vaicājumu „HAVING” rindā

Statistikas iegūšana nebija ilga, neskatoties uz to, ka tabulā ALGAS ir vairāki tūkstoši ierakstu. Tomēr tas nav tik daudz kā tabulā PERSONAS, kad statistikas ievākšana aizņem ilgāku laiku.



72


6.10.2.1.att. Izpildes plāna iegūšana vaicājumam ar pakārtotu vaicājumu „HAVING” rindā




6.10.3.1.att. Izpildes plāna izgūšana vaicājumam ar vaicājumam ar pakārtotu vaicājumu „HAVING” rindā

73




saprotamas. Bez tam, šis izpildes plāns ir diezgan vienkāršs un visas izvadītās darbības jau ir skaidras un saprotamas, pēc iepriekšējo plānu izvades.


TABLE ACCESS FULL ALGAS - tiek izgūtas visas rindas no tabulas ALGAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan) - tiek izpildīta filtrēšana pēc nosacījuma: filter("NOD_IZSNIEDZ"=39).

TABLE ACCESS FULL ALGAS – otro reizi tiek izgūtas visas rindas no tabulas ALGAS, izmantojot pilnu rindu pārlasīšanu pēc kārtas (Full table scan). Šeit izgūšana notiek izejot jau no pakārtotā vaicājuma nosacījumiem - tiek izpildīta filtrēšana pēc nosacījuma: filter("NOD_IZSNIEDZ"=39).

HASH GROUP BY – tiek savienotas ierakstu kopas grupās, tādā veidā izpildot vaicājuma izvades rezultātu grupēšanu pēc GROUP BY nosacījuma (šajā gadījumā pēc algas ID numura), izmantojot heš funkcijas.

SORT AGGREGATE - vienas rindas atlase, kura ir grupēšanas funkcijas pielietošanas rezultāts, lai sagrupētu izvēlētās rindas.

FILTER - veic rindu kopu akceptēšanu, izslēdzot dažas no tām un atgriežot pārējās, kuras atbilst vaicājumā uzdotajiem nosacījumiem - tiek izpildīta filtrēšana pēc definētajiem nosacījumiem: filter(MIN("VIDEJA_ALGA")<(SELECT AVG("VIDEJA_ALGA") FROM "ALGAS" "ALGAS" WHERE "NOD_IZSNIEDZ"=39)).




6.10.4.1.att. Optimizatora konfigurēšana vaicājumam ar pakārtotu vaicājumu „HAVING” rindā

Tādā pašā veidā izpildām darbību izpildes plāna iegūšanai, kā to darījām iepriekš, vienīgi dotam šim plānam identifikatoru (STATEMENT_ID) ‘8VAIC_1’, lai varētu to vieglāk izgūt. Tālāk atkal izpildām tā paša skripta palaišanu un iegūstam izpildes plānu vaicājumam ar pakārtotu vaicājumu „HAVING” rindā, tikai izmantojot uz likumiem balstītu pieeju (skat. 6.10.4.2.att.).

74

6.10.4.2.att. Izpildes plāna izgūšana vaicājumam ar vaicājumam ar pakārtotu vaicājumu „HAVING” rindā (uz likumiem balstīta pieeja)


Ja salīdzinām šo izpildes plānu ar 6.10.3.1.attēlā attēloto izpildes plānu šim pašam vaicājumam, tad HASH GROUP BY vietā mums tagad ir SORT GROUP BY, kas ir operācija, kas veic rindu kopu sašķirošanu grupās tiem vaicājumiem, kuriem ir GROUP BY nosacījums.

Pēc būtības, šīs darbības ir līdzīgas, vienīgi pirmajā gadījumā grupēšanas realizēšanai tiek izmantotas heš tabulas.

75

7. IETEIKUMU REALIZĒŠANA

L;lProgrammatūras izstrādātājs bieži vien var zināt vairāk par tabulu datiem, nekā to zina

Oracle optimizētājs. Piemēram, programmatūras izstrādātājs var zināt, ka noteikts indekss ir daudz selektīvāks noteiktam vaicājumam. Bāzējoties uz šo informāciju, ir iespējams izveidot daudz efektīvāku vaicājuma izpildes plānu, nekā to izdarītu optimizētājs. Šādos gadījumos tiek lietoti ieteikumi (hints), lai piespiestu optimizētāju izmantot optimālo izpildes plānu.

Ieteikumi atļauj programmatūras izstrādātājam jeb administratoram pieņemt tos lēmumus, kurus parasti pieņem optimizētājs.

Ieteikumus var izmantot, lai specificētu sekojošo: optimizācijas pieeju SQL komandai jeb vaicājumam. Resursu analīzes bāzēta optimizētāja mērķi SQL vaicājumam. Tabulas pieejas ceļu, kurai piekļūst vaicājums. Savienošanas kārtību savienošanas komandai. Savienošanas darbību savienošanas komandā.

Ieteikumi nodrošina mehānismus, lai vadītu optimizētāju izvēlēties noteikta vaicājuma izpildes plānu bāzējoties uz sekojošiem kritērijiem:

savienošanas kārtība (join order), savienošanas metode (join method), pieejas metode (access method), paralelizācija.

Ieteikumi (izņemot RULE ieteikumu) izsauc resursu analīzes bāzētu optimizētāju. Ja pirms ieteikumu izmantošanas nav savākta statistika, tad tiek izmantota statistika, kas ir uzstādīta Oracle pēc noklusējuma.

Ja vaicājumā ieteikums tiek nepareizi definēts, tad Oracle to ignorē, tomēr neatgriež kļūdas paziņojumu.

Ieteikums var sākties tikai un vienīgi pēc DELETE, SELECT vai UPDATE izteiksmes. Tas tiek realizēts kā komentārs, izmantojot ‘ /* ‘ simboliem, sākot komentāru, un ‘ */ ‘ simboli - noslēdzot komentāru. Bez tam, lai ieteikums tiktu izskatīts, uzreiz pēc komentāra sākuma simboliem (bez atstarpēm) ir jāliek plusa zīme – ‘ + ‘, aiz kura arī (komentāra ietvaros) tiek definēts pats ieteikums.

Izveidotie indeksi

Indeksu izmantošana ir ļoti lietderīga, ja ir nepieciešamība palielināt vaicājuma ātrdarbību, sevišķi tad, ja tas tiks pielietots tabulai ar mazu ierakstu skaitu. Indeksu izmantošana palīdzēs nepāršķirstīt visas tabulu rindas, bet meklēt nepieciešamos ierakstus tikai pēc indeksa. Tā pat būtu jāatceras, ka indeksus nevajadzētu pielietot, ja ir ļoti daudz nosacījumu vaicājuma WHERE rindā, jo tad katram nosacījumam šī pārmeklēšana varētu atkārtoties. Vēl vairāk – jāatceras tas, ka pārmeklēšanas rezultāts notiek sekojoši: ja vienai operācijai identifikators ir tāds pats, kāds tas ir otrajai operācijai ailē PARENT_ID, tad tas nozīmē, ka pirmā operācija izmanto otrās rezultātu. Tādējādi, pārmeklējamo ierakstu skaits ir jāreizina ar bērna rezultātu skaitu. Kas nozīmē to, ka pārmeklējamo ierakstu skaits var palielināties pat līdz vairākiem miljoniem rindu.

76

Pamēģināsim noskaidrot, kādi indeksi mums ir izveidojušies brīdī, kad mēs izveidojām tabulas ar ierobežojumiem priekš tabulu primārām atslēgām, nodefinējot CONSTRAINT (skat. 7.1.1.att.).

7.1.1.att. Automātiski izveidotie indeksi

Tātad, redzam ka mums ir 3 indeksi, ko esam ieguvuši, definējot primārās atslēgas, kā arī viens indekss, ko ir uzģenerējusi sistēma, izveidojot PLAN_TABLE. Pēdējo indeksu mēs neizmantosim, taču pārējos trīs gan. Bez tam, varam pamanīt, ka tabulai PERSONAS nav indeksa. Tas ir saistīts ar to, ka šī tabula ir kā Faktu tabula.

Optimizatora konfigurēšana (CHOOSE)

Tā kā ieteikumi izsauc uz resursu analīzēm bāzētu optimizētāju, tad labāk veiksim konfigurēšanu, uzstādot optimizētāja režīmu uz „CHOOSE” (skat. 7.2.1.att.).

7.2.1.att.Optimizātora konfigurēšana (CHOOSE)

Tātad, tagad ieteikumu realizēšanai tiks izmantots CHOOSE režīms.

Ieteikumu realizācija vaicājumam ar „Exists”

Lai ērtāk būtu pārbaudīt ieteikumu efektivitāti konkrētajam vaicājumam, apskatīsimies vēlreiz to, kāds izskatījās izpildes plāns vaicājumam ar ‘Exists’ (skat. 7.3.1.att.).

77

7.3.1.att.Izpildes plāns vaicājumam ar ‘Exists’

Varam redzēt, ka diezgan daudz procenti no CPU resursiem tiek patērēti rezultātu izvadei un apvienošanai. Tas viennozīmīgi ir saistīts ar to, ka pārmeklējot visas tabulas ar FULL TABLE SCAN, tika iegūti daudz ieraksti, kas arī paildzina apvienošanas un izvades procesu.

Kā jau minēju, tad ieteikums ar INDEX izmantošanu izvēlas indeksu pārmeklēšanu definētajai tabulai. Šajā gadījumā ir iespējams izmantot indeksu domēnam, B-kokam, bitmap-am un bitmap-u savienošanas indeksam. Tieši tāpēc, pamēģināsim ieteikt šim vaicājumam izmantot INDEX pārmeklēšanu, tādējādi iespējami samazinot kopējās procentuālās CPU izmaksas.

Indeksu izmantošanas sintakse ir apskatāma 7.3.2.attēlā, kur:TABLE nosaka tabulas nosaukumu vai tabulas pieņemto apzīmējumu, kura tiek pielietota

indeksu skenēšanā;INDEX nosaka indeksu, uz kura pamata izpildīsies indeksu pārmeklēšana.

7.3.2.att. Ieteikuma INDEX pielietošanas sintakse

Tātad, ieteiksim vaicājumam pārmeklēt pakārtotajā vaicājumā rezultātus pēc nodaļu identifikatora (nod_pk), bet galvenajā vaicājumā pēc algu identifikatora (aid_pk) (skat.7.3.3.att.). Izmantosim jau iepriekš sastādītos vaicājumus, tikai STATEMENT_ID definēsim kā ‘2VAIC_2’, jo ‘2VAIC’ vaicājumam ar ‘Exists’ mums tika izmantots darbībām ar uz resursiem bāzētu pieeju, savukārt ‘2VAIC_1’ – darbībām ar uz likumiem balstītu pieeju.

78

7.3.3.att. Izpildes plāna iegūšana vaicājumam ar ‘Exists’, izmantojot ieteikumus

Tagad, kad plāns ir iegūts, pamēģināsim to izgūt. Izgūšanu veiksim ar jau pierastā skripta izmantošanu, plāna izgūšanai no PLAN_TABLE, ko piedāvā Oracle. Ievadot to, mums uzreiz ekrānā parādās pēdējais iegūtais izpildes plāns (skat. 7.3.4.att.).

7.3.4.att. Izpildes plāna izgūšana vaicājumam ar ‘Exists’, izmantojot ieteikumus

79

Kā varam redzēt, tad mums ir parādījusies papildus divas operācijas, kuras veic pilnīgu indeksu pārmeklēšanu (3 un 5 soļi). Bez tam, pilnās tabulu izgūšanas un pārmeklēšanas vietā mums ir parādījusies tabulu rindas pārmeklēšana pēc ROWID, t.i. uzreiz tiek izgūtas tikai nepieciešamās rindas. Neskatoties uz to, ka darbību skaits ir palielinājies, varam redzēt, ka kopējais procentuālais CPU (%CPU aile) ir mazāks (summā 8), par to, kāds tas ir bijis pirms ieteikuma realizēšanas (summā 18). Varam redzēt arī to, ka datu apvienošana ar heš tabulām un rezultātu izvade patērē mazāk resursu, jo vairs nav jāsavieno tik daudz ierakstu, kā iepriekš.

Līdz ar to, viss iepriekš minētais kļūst par pamatu secinājuma, ka vaicājuma optimizācija ir veiksmīga, jo pēc tās vaicājuma izpildei tiek patērēts mazāk resursu.

Varam pāriet pie cita ieteikuma realizēšanas nākošajam vaicājumam.

Ieteikumu realizācija vaicājumam ar „Over”

Lai ērtāk būtu pārbaudīt ieteikumu efektivitāti konkrētajam vaicājumam, apskatīsimies vēlreiz to, kāds izskatījās izpildes plāns vaicājumam ar ‘Over’ (skat. 7.4.1.att.).

7.4.1.att.Izpildes plāns vaicājumam ar ‘Over’

Attēlā redzams, ka visvairāk CPU procentuālo resursu patērē HASH GROUP BY, WINDOW SORT un SELECT STATEMENT operācijas. Tas ir saistīts ar to, ka atkal – savienojamo datu apjoms ir ļoti liels, jo kā redzam, vaicājumā atkal tiek pielietota pilnā tabulu pārmeklēšana. Tādējādi, būtu nepieciešamas samazināt ierakstu kopas savienošanu grupās operācijas resursu procentuālo patērētību, tādējādi automātiski samazinot šķirošanu, izmantojot logus un nepieciešamo datu izvadi.

80

Lai liktu Oracle savienot katru noteikto tabulu ar citu ierakstu avotu ar NESTED LOOPS apvienojumu, izmantojot noteikto tabulu kā iekšējo, mums ir jāizmanto ieteikums USE_NL. Tabulu savienošana ar NESTED LOOPS, protams, patērēs vairāk resursu, tomēr šis savienojums ir gana labs vidēji lielām tabulām, tādējādi samazinot resursu patērētību turpmākajām operācijām, jo pirms tam izmantotā HASH JOIN operācija pati par sevi patērēja daudz resursu. Tāpēc, vismaz vienu savienošanu veiksim, izmantojot USE_NL operāciju. USE_NL ieteikuma izmantošanas sintakse ir apskatāma 7.4.2.attēlā, kur

TABLE nosaka tabulas nosaukumu vai tabulas pieņemto apzīmējumu ar mērķi izmantot tabulu kā iekšējo tabulu, priekš NESTED LOOPS apvienojuma.

7.4.2.att. Ieteikuma USE_NL pielietošanas sintakse

Tā pat, ar ORDERED ieteikuma palīdzību, pamēģināsim likt Oracle savienot tabulas tādā secībā, kā tie parādās vaicājuma FROM rindā, jo iepriekš savienošana tika veikta no otra gala, kas iespējams arī izraisīja lielu datu apjomu atlasīšanu. ORDERED ieteikuma izmantošanas sintakse ir apskatāma 7.4.3.attēlā.

7.4.3.att. Ieteikuma ORDERED pielietošanas sintakse

Bez tā visa, izmantosim arī daudzpusīgu INDEX_COMBINED ieteikumu, ko var izmantot uzreiz vairāku indeksu izmantošanai. Šī ieteikuma izmantošanas sintakse ir tāda pati, kā iepriekš apskatītajam INDEX ieteikumam.

Tātad, ieteiksim vaicājumam pārmeklēt pakārtotajā vaicājumā rezultātus pēc nodaļu identifikatora (nod_pk) un algu identifikatora (aid_pk) (skat.7.4.4.att.). Tā pat, noteiksim, lai vaicājums savieno tabulas FROM rindas secībā, un savienojumu ar NESTED LOOPS veic tabulai ALGAS, kura kļūs par apvienojuma iekšējo tabulu. Izmantosim jau iepriekš sastādītos vaicājumus, tikai STATEMENT_ID definēsim kā ‘4VAIC_2’, jo ‘4VAIC’ vaicājumam ar ‘Over’ mums tika izmantots darbībām ar uz resursiem bāzētu pieeju, savukārt ‘4VAIC_1’ – darbībām ar uz likumiem balstītu pieeju.

7.4.4.att. Izpildes plāna iegūšana vaicājumam ar ‘Over’, izmantojot ieteikumus81


7.4.5.att. Izpildes plāna izgūšana vaicājumam ar ‘Over’, izmantojot ieteikumus

Pēc attēla redzam, ka operāciju skaits nav mainījies, savukārt ir mainījusies tabulu pārmeklēšanas secība. Redzam, ka ir parādījies NESTED LOOPS savienojums, lai savienotu

82

tabulas ALGAS atrastos ierakstus ar iepriekšējā (HASH JOIN) savienojuma rezultātiem. Bez tam, redzam, ka pateicoties NESTED LOOPS apvienojumam, kurš izmanto 14% no CPU resursiem arī tālākās operācijas, kuras ir saistītas ar grupēšanu, šķirošanu un izvadi, patērē tikai 14%, iepriekšējo 48% vietā. Tādējādi, varu arī šeit droši secināt, ka optimizācija ir notikusi veiksmīgi, jo kopējais procentuālais CPU (%CPU aile) ir mazāks (summā 83), par to, kāds tas ir bijis pirms ieteikuma realizēšanas (summā 186).

Ieteikumu realizācija vaicājumam ar pakārtotu vaicājumu „FROM” rindā

Lai ērtāk būtu pārbaudīt ieteikumu efektivitāti konkrētajam vaicājumam, apskatīsimies vēlreiz to, kāds izskatījās izpildes plāns vaicājumam ar pakārtotu vaicājumu ‘FROM’ rindā (skat. 7.5.1.att.).

7.5.1.att.Izpildes plāns vaicājumam ar pakārtotu vaicājumu ‘FROM’ rindā

Pēc attēla varam redzēt, ka vaicājums sākumā veic indeksu skenēšanu, taču šo darbību vajadzētu veikt pēc tam, kad jau ir izdarīts pirmais savienojums. Tas ļaus ieekonomēt tālākās apvienošanas resursus. Bez tam, būtu loģiski, ja tabula PERSONAS, tā kā tā ir diezgan liela, tiktu apvienota ar pati ar sevi, izejot no pakārtotā vaicājuma nosacījumiem. Tas ļaus uzreiz atlasīt datus pēc nepieciešamajiem kritērijiem, līdz ar to, tālāka savienošana ar citiem datiem būs vienkāršāka.

Pamēģināsim ieteikt vaicājumam izmantot USE_MERGE ieteikumu, kas liek Oracle savienot katru noteiktu tabulu ar citu ierakstu avotu, izmantojot SORT MERGE savienojumu. Tieši tas ļaus mums sākumā savienot pirmās atlases tabulas PERSONAS datus ar otrās atlases datiem tajā pašā tabulā, bet jau pēc galvenā vaicājuma nosacījumu daļas, lai tālākās operācijas,

83

izmantojot šo apvienojuma rezultātu, ieekonomētu resursus, ko patērēs pārmeklēšanai un apvienojumam. USE_MERGE ieteikuma izmantošanas sintakse ir apskatāma 7.5.3.attēlā, kur

TABLE nosaka to tabulu, kurai ir jābūt savienotai ar ierakstu avotu no iepriekšējās tabulu apvienošanas, izmantojot SORT MERGE savienojumu.

7.5.3.att. Ieteikuma USE_MERGE pielietošanas sintakse

Tā par, ieteiksim vaicājumam veikt pārējos apvienojumus secībā, kāda tika definēta galvenā vaicājuma FROM rindā, izmantojot ORDERED ieteikumu, kurš jau tika izskatīts iepriekš, kā arī pakārtotajam vaicājumam ieteiksim lietot INDEX_COMBINED ieteikumu, ko var izmantot uzreiz vairāku indeksu izmantošanai.

Izmantosim jau iepriekš sastādītos vaicājumus, tikai STATEMENT_ID definēsim kā ‘6VAIC_2’, jo ‘6VAIC’ vaicājumam ar pakārtotu vaicājumu ‘FROM’ rindā mums tika izmantots darbībām ar uz resursiem bāzētu pieeju, savukārt ‘6VAIC_1’ – darbībām ar uz likumiem balstītu pieeju (skat. 7.5.4.att.).

7.5.4.att. Izpildes plāna iegūšana vaicājumam ar pakārtotu vaicājumu ‘FROM’ rindā


84

7.5.5.att. Izpildes plāna izgūšana vaicājumam ar pakārtotu vaicājumu ‘FROM’ rindā

85

Kā varam redzēt pēc jaunā izpildes plāna, tad ieteikumi patiešām ir realizējušies. Ir izpildījies mūsu galvenais iecerējums – sākumā uzreiz apvienot abu vaicājumu (gan galvenā, gan pakārtotā) izpildes no tabulas PERSONAS. Šīs tabulas tika arī apvienotas ar HASH JOIN, jo tabulas ir apjomīgas. Un tālāk sekoja papildus pārmeklēšana indeksiem un jau ar NESTED LOOPS tika veiks galējais apvienojums jau diezgan mazāk un atlasītām kopām. Rezultātā mēs redzam, ka visu apvienojumu un izvades procentuālais CPU ir samazinājies. Kaut arī tikai par 2% kopumā, tomēr rezultātā mēs iegūstam daudz loģiskāku vaicājuma izpildi, ar daudz korektāku darbību izpildes secību. Tādējādi, arī šī ieteikuma realizācija ir notikusi veiksmīgi.

Ieteikumu realizācija vaicājumam ar „Select...From T1,T2 Where...”

Pamēģināsim izveidot arī kādu neefektīvu ieteikumu, lai pārliecinātos par to, ka ne katrs ieteikums spēj uzlabot vaicājuma izpildi.

Lai ērtāk būtu pārbaudīt ieteikumu efektivitāti konkrētajam vaicājumam, apskatīsimies vēlreiz to, kāds izskatījās izpildes plāns vaicājumam ar pakārtotu vaicājumu ‘FROM’ rindā (skat. 7.6.1.att.).

7.6.1.att.Izpildes plāns vaicājumam ar ‘Select...From T1,T2 Where...’

Pēc būtības dotais izpildes plāns ir diezgan efektīvs, kaut gan ir ieviešami daži labojumi. Piemēram, būtu labāk, ja tomēr lielā tabula PERSONAS tiktu savienota ar citu tabulu, izmantojot HASH JOIN, jo tieši šis savienojums ir labāks un efektīvāks priekš lielām tabulām. Tā pat šeit

86

gribētos izvairīties no indeksu pārmeklēšanas, jo lielākā pārmeklēšana notiek tabulā PERSONAS, kura, kā jau minēju, ir ļoti liela šim nolūkam – pārmeklēšana, lai apmierinātu vaicājuma nosacījumus var patērēt ļoti daudz resursu. Līdz ar to, indeksus labāk ir izmantot mazām tabulām.

Tātad, pamēģināsim likt Oracle savienot tabulas ar HASH_JOIN. Šim nolūkam ir jāizmanto USE_HASH ieteikums. USE_HASH liek Oracle savienot katru noteiktu tabulu ar citu ierakstu avotu ar HASH JOIN savienojumu. HASH JOIN ieteikuma izmantošanas sintakse ir apskatāma 7.6.3.attēlā, kur

TABLE nosaka to tabulu, kurai ir jābūt savienotai ar ierakstu avotu no iepriekšējās tabulu apvienošanas, izmantojot HASH JOIN savienojumu.

7.6.3.att. Ieteikuma USE_HASH pielietošanas sintakse

Izmantosim jau iepriekš sastādītos vaicājumus, tikai STATEMENT_ID definēsim kā ‘1VAIC_2’, jo ‘1VAIC’ vaicājumam ar ‘Select...From T1,T2 Where...’ mums tika izmantots darbībām ar uz resursiem bāzētu pieeju, savukārt ‘1VAIC_1’ – darbībām ar uz likumiem balstītu pieeju (skat. 7.6.4.att.).

Pamēģināsim arī izdarīt vienu nepareizu ieteikumu – liksim Oracle veikt visus savienojumus ar HASH JOIN. Kā jau tika minēts, gribām, lai katru reizi tabula PERSONAS tiktu savienota ar citām, izmantojot HASH JOIN, taču mēs definēsim arī to, lai tabula NODAĻAS ar visām citām (arī ar tabulu VALSTIS) tiktu savienota ar HASH JOIN. Tas nebūtu labi, jo tabulas nav tik lielas, lai izmantotu operāciju, kura pēc resursiem ir nedaudz apjomīgāka, jo ir paredzēta lielāku tabulu apvienošanai.

Tā pat ieteiksim Oracle apvienot tabulas secībā, kādā tās tika definētas vaicājuma FROM rindā, izmantojot ieteikumu ORDERED.

7.6.4.att. Izpildes plāna iegūšana vaicājumam ar ‘Select...From T1,T2 Where...’

87


7.6.5.att. Izpildes plāna izgūšana vaicājumam ar ‘Select...From T1,T2 Where...’

Kā varam redzēt, tad izpildes plāns ir samazinājies par vienu darbību, jo sakārtojot tabulu apvienošanas secību mēs esam izvairījušies no indeksu pārmeklēšanas lielajās tabulās. Tā ir notikusi tikai tabulā VALSTIS, kura ir salīdzinoši maza. Tā pat arī redzam, ka mums ir divas savienošanas operācijas HASH JOIN. Kā varam redzēt, tad tabulas PERSONAS atlasītie dati patiešām savienojas ar tabulas VALSTIS atlasītajiem datiem pēc indeksiem, savukārt pēc tam, arī

88

tabula NODAĻAS jau tika apvienota ar iepriekšējo apvienojumu, izmantojot HASH JOIN. Tas arī uzreiz ir palielinājis CPU procentuālo resursu patērētību katrai nākošajai operācijai (gan SORT ORDER BY, gan SELECT STATEMENT). Tādējādi - kopējais procentuālais CPU (%CPU aile) ir nedaudz lielāks (summā 24), par to, kāds tas ir bijis pirms ieteikuma realizēšanas (summā 22). Kaut gan tas ir lielāks tikai par 2%, tomēr vienmēr ir jārēķinās ar to, ka iespējams tabulu apjoms būtu vēl lielāks, un vaicājums sarežģītāks, līdz ar to, nevajadzētu tomēr likt mazas tabulas apvienot ar HASH JOIN savienojumu. Vislabāk, protams, tabulu NODAĻAS pievienot iepriekšējam apvienojumam būtu ar NESTED LOOPS palīdzību, taču mans mērķis šī ieteikuma realizācijā, bija pārliecināties par to, ka var realizēt arī neefektīvu ieteikumu.

Tātad, kad ir veiksmīgi realizēti trīs ieteikumi, izmantojot ORDERED, INDEX, INDEX_COMBINED, USE_HASH, USE_MERGE un USE_NL ieteikumus, kā arī pārbaudīts tas, ka pastāv iespējamība nekorekti veikt ieteikumu, kas palielinās datora noslogotību.

89

SECINĀJUMI

Dotais darbs ir izstrādāts atbilstoši definētajai uzdevuma nostādnei, kuras galvenais mērķis bija izpētīt SQL vaicājumu izpildes plānu iegūšanas, analīzes un optimizācijas iespējas, izmantojot dažādus ieteikumus.

Darba gaitā tika izmantota pasniedzēja piedāvātā datu bāze MS ACCESS vidē. Lai varētu veikt SQL analīzi un optimizāciju, ir nepieciešama liela datu bāze, ar daudziem ierakstiem. Tas ir nepieciešams tam, lai varētu izjust vaicājumu izpildes laiku. Tieši tādēļ tika izmantota gatavā datu bāze, kurā divās no tabulām bija vairāki desmiti tūkstoši ierakstu, un pat pāri par diviem miljoniem ierakstu. Protams, datu bāze uzreiz tika nedaudz koriģēta, lai labāk varētu izpildīt uzdevuma nostādnes posmus, piemēram, tika izveidota unārā saite, lai realizētu hierarhisko vaicājumu, kā arī datu bāzes tabulas tika savienotas savā starpā, kas nebija izdarīts iepriekš. Šīs datu bāzes pārnešanai uz ORACLE, eksportēju tabulu datus uz *.txt failiem, un pārkonvertēju tos *.dat formātā. Tā pat izveidoju *.ctl failus, ar mērķi ielādēt datus ORACLE datu bāzē ar SQL*Loader palīdzību. Taču pirms tam, izveidoju Oracle vidē nepieciešamās tabulas ar parasto CREATE TABLE. Protams, esmu mēģinājusi arī veikt eksportēšanu ar SQL Developer palīdzību, taču tas aizņēma vairākas stundas un datu bāzi nebija iespējams pēc tam labot. Tieši tādēļ – ērtāk un ātrāk šķita izveidot datu bāzi patstāvīgi un ielādēt datus ar SQL*Loader palīdzību, kas arī tika veiksmīgi izdarīts.

Pēc tam tika veikta pārbaude – vai visi dati ir ievadīti tabulās. Šeit pieļāvu lielu kļūdu – pārbaudot datu esamību tabulās ar pierasto ‘Select * From <Tabula>’, bija jāgaida bezmaz vai stunda, kamēr tika izvadīti visi dati (sevišķi lielajām tabulām – Personas un Algas), līdz ar to ir nācies pārtraukt vaicājuma izpildi, jo tā pat jau biju pārliecinājusies, ka dati tabulā ir un nav vērts izvadīt tos visus, lai par to pārliecinātos.

Kad datu bāze praktiskajam darbam bija gatava, sāku veidot vaicājumus. Šeit palīdzēja DB1 kursa pirmais darbs, kurā kādreiz tika veidoti dažādas grūtības vaicājumi MS ACCESS vidē, līdz ar to – ar pirmo daļu vaicājumu ātri tiku galā. Tā pat palīdzēja DB2 kursa darbi, ar kuru palīdzību atcerējos hierarhisko vaicājumu izveidi un klona tabulu izmantošanu. Šī darba daļa nebija tā grūtākā un ātri tiku tai cauri. Kaut gan bija dažas problēmas ar vaicājumu izpildi – sarežģītākie vaicājumi (sevišķi ar klona tabulām un hierarhiskie) aizņēma lielu laiku izpildei un rezultātu izvadei uz ekrāna – līdz pat vairākām minūtēm.

Tālāk sastapos ar dažām neskaidrībām, pētot pieciem vaicājumiem izpildāmās relāciju algebras komandas. Sākumā nevarēju izprast, no kura gala sākas vaicājuma izpilde, taču šeit par palīgu vienmēr nāk interneta resursi, pasniedzēja piedāvātie materiāli, kā arī iemaņas par šo tēmu, kuras tika iegūtas citos priekšmetos. Pēc būtības, kad izpratu kādā secībā ir jārealizējas vaicājuma darbībām, darbu pie šī posma pabeidzu ļoti ātri un ar citām problēmām šeit nesastapos.

Pēc tam sekoja izpildes plānu iegūšana. Izpildes plānus centos iegūt būtiskākajiem vaicājumiem (kuri darba sākumā uzdevuma nostādne tika atzīmēti ar zvaigznīti ‘*’),

90

vienkāršākos izlaižot (piemēram vaicājumu vienai tabulai un vienkāršo vaicājumu ar Having, kurš arī tika izmantots vienai tabulai – sarežģītāks vaicājums ar Having tika izskatīts gadījumā ar pakārtoto vaicājumu Having rindā). Pēc nelielas teorijas izpētes, kā pirmo soli šajā posmā - izveidoju PLAN_TABLE ar gatavā skripta palīdzību, ko piedāvā Oracle. Uzstādīju optimizātoru uz „ALL_ROWS” režīmu, lai iegūtu izpildes plānu ar EXPLAIN PLAN komandas palīdzību, balstoties uz resursu analīzes bāzētu pieeju, pēc tam - tam pašam vaicājumam uz „RULE”, lai iegūtu izpildes plānu, balstoties uz likumiem. Šo divu dažādu režīmu izmantošanu pielietoju katram izskatītajam vaicājumam. Pirms katra vaicājuma veicu statistikas iegūšanu tabulām, kuras piedalās vaicājuma realizācijā. Taču tad, kad vēlējos izgūt vaicājumu izpildes plānus - kaut kas notika ar manu datoru un tas burtiski „uzkārās” pēc katra vaicājuma izpildes plāna izgūšanas pieprasījuma. Tieši tādēļ, nācās vairākas reizes „restartēt” datoru (gandrīz pēc katra vaicājuma analīzes) un atkārtoti ievākt statistikas tabulām. Kad beidzot izdevās izvadīt kādu no izpildes plāniem (tas arī nenācās viegli – izvadīt plānu tā, lai tas būtu pārskatāms, tāpēc izmēģināju vairākus paņēmienus un tomēr beigās paliku pie skripta izmantošanas, ko piedāvā Oracle) – sākās lielākās grūtības, konkrētāk – ar izpildes plāna analīzi. Pārlasīju ļoti lielu informācijas klāstu par operācijām, kuras tiek attēlotas izpildes plānā, lai saprastu ko tās dara. Tā pat bija grūtības izprast izpildes secību attēlotajā plānā. Tomēr, kad tiku galā ar šiem jautājumiem un noskaidroju gan operāciju izpildes kārtību, gan atsevišķus gadījumus, kad operācijas ir attēlotas vienā līmenī, tad arī darbs sāka iet ātrāk uz priekšu. Beigās es jau uzreiz redzēju ar ko plāns sākas, ar ko beidzas un vai tā izpilde ir optimāla.

Šajā vietā varētu izdarīt nelielu secinājumu par optimizātoru izmantošanu. Manuprāt, efektīvāks ir uz resursiem bāzētas pieejas izmantošana optimizātoram. Izmantojot to, uzreiz var novērtēt vaicājuma darbību izpildi gan laika ziņā, gan datora resursu patērētību procentuālajā ziņā (%CPU aile). Bez tam, izmantojot uz likumiem balstītu pieeju, bieži vien optimizātors, atlasot ierakstus pēc vaicājuma noteikumiem ar vairākiem AND/OR vai IN sarakstiem, veica vairākas vienveidīgas manipulācijas ar indeksiem, kas lielām tabulām nav izdevīgi un var aizņemt ne tikai daudz resursu, bet arī daudz laika.

Balstoties tieši uz šīs pieredzes, nākošajai darba daļai, kura bija saistīta ar vaicājumu optimizāciju un koriģēšanu, nokonfigurēju optimizātoru „CHOOSE” režīmā, lai optimizātors pats izvēlās pieeju (bez tam zināju to, ka ja ir iespējams savākt statistiku, tad tiks izmantota uz resursu analīzes bāzēta pieeja, ko arī es vēlējos panākt; tā pat – vairāki ieteikumi tiek realizēti tikai tad, ja optimizātors ir nokonfigurēts šādā veidā).

Tātad, kā pēdējo darba daļu – izpētīju ieteikumu realizācijas iespējas. Darba gaitā veiksmīgi realizēju trīs ieteikumus, izmantojot ORDERED, INDEX, INDEX_COMBINED, USE_HASH, USE_MERGE un USE_NL ieteikumus, kā arī pārliecinājos par to, ka pastāv iespējamība nekorekti veikt ieteikumu, kas palielinās datora noslogotību. Jau iepriekš biju secinājusi kuri rezultāti nav optimāli – tos arī mēģināju optimizēt, izmantojot dažādus ieteikumus. Piemēram, bieži vien tiek izmantota pilna tabulas pārmeklēšana tajās vietās, kur labāk būtu jāizmanto indeksi (sevišķi mazām tabulām). Tā pat sastapos ar ne visai korektu apvienošanas secību un apvienošanas

91

veidu. Visas šīs nepilnības mēģināju labot, izmantojot ieteikumus, kas man, manuprāt, arī veiksmīgi izdevās.

Tā pat, darba gaitā, mēģinot vairākus ieteikumu variantus pārliecinājos par to, ka ne katrs sniegtais ieteikums tiks „paklausīts” un ne katrs sniegs efektīvāku rezultātu. Pamēģināju arī realizēt vienu neefektīvu vaicājumu, definējot ieteikumu, kurš savienos visas tabulas ar HASH JOIN apvienojumu. Tas rezultātā kļuva par cēloni tam, ka procentuālā CPU patērētība palielinājās tālākām vaicājuma izpildes darbībām. Par iemeslu tam kļuva tas, ka HASH JOIN savienošana ir piemērota lielajām tabulām, savukārt vidējām labāk ir izmantot NESTED LOOPS (bet mazām, attiecīgi, indeksus).

Šis pēdējais darbs bija patiešām interesants, kaut arī ļoti laikietilpīgs, kas prasa ļoti daudz spēka un reizēm bezspēka gūstā ir grūti izdomāt nākošā darba punkta realizācijas iespēju.

Izskatīta datu bāze bija piemērota tam, lai gūtu patiesu priekšstatu par SQL vaicājumu analīzes un optimizācijas iespējām. Šīs zināšanas viennozīmīgi palīdz izstrādātajam realizēt kvalitatīvākas un efektīvākas informācijas sistēmas. Tā pat, šāda veida secīga darbību izpēte var arī palīdzēt atrast kļūdas ne tikai vaicājumos, bet arī pašās datu bāzēs, ko ir grūti izdarīt bez detalizētas analīzes, neskatoties uz to, ka tas ir ļoti laikietilpīgs process.

92

IZMANTOTIE AVOTI

Literatūra latviski:1. J.Eiduks, 2008./2009.māc.g. Izdales materiāli no diska2. Semināra materiāli: vaicājumi valodā SQL un tas paplašinājums PL/SQL. J.Eiduks (no 2002

gada).

Literatūra krieviski:3. Базы данных, Проектированиеб реализация и сопровождение. Теория и практика / Под

ред. Т. Конноли, К. Бегг, А. Страчан. – М., изд. дом Вильямс, 20004. С. Мишра, А. Бьюли - Секреты Oracle SQL, Санкт-П. – Москва, СИМВОЛ, 2003

Literatūra angliski:5. Martin Gruber, „Understanding SQL”, MOSCOW, 19936. Oracle Documentation, Oracle.7. “Introduction to Oracle9i : SQL” Nancy Greenberg, Priya Nathan, 2001. gads8. Martin Gruber, „Understanding SQL”, MOSCOW, 19939. Oracle Documentation, Oracle.10. “Oracle9i : The Complete Reference” Kevin Loney, George Koch, 2002. gads11. Oracle10g Help. 12. O'Reilly „Oracle-SQLProgramming” – 2002. gads

Internets:13. http://books.kulichki.net/data/sql/sql1/14. http://lv.wikipedia.org/wiki/SQL 15. http://rowa.giso.de/oracle/latex/Index.html16. http://sql.1keydata.com/cn/17. http://www.infogoal.com/sql/sql.htm18. http://www.loader.datenbank-wissen.de/index.htm19. http://www.sql-tutorial.com/sql-introduction-sql-tutorial/20. http://www.techonthenet.com/top10/sql.php 21. http://www.1keydata.com/sql/sqlselect.html 22. http://www.mail-archive.com/[email protected]/msg30518.html23. http://forums.devshed.com/oracle-development-96/how-to-joining-two-fields-into-one-

368490.html24. http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/toc.htm25. http://www.psoug.org/reference/string_func.html26. http://felipecruz.com/oracle-string-functions-version-10g.php27. http://www.adp-gmbh.ch/ora/explainplan.html28. http://www-camden.rutgers.edu/HELP/Documentation/Oracle/server.815/a67775/

ch13_exp.htm29. http://www.oracle-base.com/articles/8i/ExplainPlanUsage.php30. http://optimizermagic.blogspot.com/2008/02/displaying-and-reading-execution-plans.html31. http://www.praetoriate.com/t_op_sql_execution_plan.htm32. http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm

93

Documents

UZDEVUMA NOSTĀDNE - Web viewIzskatīsim vaicājuma izpildi pa soļiem. Pirmajā rindā redzam, ka pavisam mums ir vairāk nekā 2 miljoni cilvēku datu bāzē. ... tiek vei. kta