Embed Size (px)
Citation preview
Rīgas Tehniskā Universitāte
Datorzinātnes un informācijas tehnoloģijas
fakultāte
INFORMĀCIJAS TEHNOLOĢIJAS INSTITŪTS
Lielu datu bāzu tehnoloģija
„SQL VAICĀJUMU OPTIMIZĀCIJA”
Laboratorijas darbs Nr.3
Izstrādāja:
Pārbaudīja: prof. J.Eiduks
2008./2009.m.g.
Liāna Natenadze
DMIO2051RDB234
SATURS
SATURS...........................................................................................................................2
UZDEVUMA NOSTĀDNE...............................................................................................4
1. PRIEKŠMETISKĀS VIDES APRAKSTS..................................................................5
1.1. MS Access datu bāzes pārskats.............................................................5
1.2. Datu bāzes ER diagramma....................................................................8
2. DATU BĀZES MIGRĀCIJA......................................................................................9
2.1. Datu bāzes migrācija ar SQL Developer...............................................9
2.2. Datu pārbaude.....................................................................................21
3. VAICĀJUMU REALIZĀCIJA..................................................................................25
3.1. Vaicājums vienai tabulai.....................................................................25
3.2. Vaicājums vienai tabulai ar nosacījumu............................................25
3.3. Vaicājums divām tabulām ar nosacījumiem......................................26
3.4. Vaicājums ar HAVING..........................................................................26
3.5. Vaicājums ar EXISTS............................................................................27
3.6. Vaicājums ar GROUP BU CUBE...........................................................28
3.7. Vaicājums ar OVER..............................................................................29
3.8. Hierarhiskie vaicājumi........................................................................30
3.9. Vaicājums ar pakārtoto vaicājumu FROM rindā...............................35
3.10. Vaicājums ar pakārtoto vaicājumu SELECT rindā..........................36
3.11. Vaicājums ar pakārtoto vaicājumu HAVING rindā.........................36
4. RELĀCIJU ALGEBRAS KOMANDAS.............................................................37
4.1. Vaicājums vienai tabulai ar nosacījumu............................................37
4.2. Vaicājums divām tabulām ar nosacījumu..........................................38
4.3. Vaicājums ar apakšvaicājumu FROM rindā.......................................39
4.4. Vaicājums ar HAVING..........................................................................41
4.5. Vaicājums ar apakšvaicājumu HAVING rindā...................................42
5. IZPILDES PLĀNA IEGŪŠANA UN ANALĪZE................................................43
5.1. Izpildes plāns.......................................................................................43
5.2. Plāna tabulas izveidošana...................................................................45
5.3. Optimizators........................................................................................45
5.3.1. RBO optimizators.....................................................................................46
2
5.3.2. CBO optimizators.....................................................................................46
5.3.3. Optimizatora konfigurēšana....................................................................46
5.4. Izpildes plāna iegūšana.......................................................................48
5.4.1. Vaicājums vienai tabulai..........................................................................48
5.4.2. Vaicājums vienai tabulai ar nosacījumu..................................................50
5.4.3. Vaicājums divām tabulām ar nosacījumu................................................51
5.4.4. Vaicājums ar HAVING............................................................................53
5.4.5. Vaicājums ar EXISTS...............................................................................54
5.4.6. Vaicājums ar OVER.................................................................................56
5.4.7. Vaicājums ar GROUP BY CUBE............................................................58
5.4.8. Hierarhiskais vaicājums 1.......................................................................59
5.4.9. Hierarhiskais vaicājums 2.......................................................................60
5.4.10. Hierarhiskais vaicājums 3.....................................................................60
5.4.11. Vaicājums ar apakšvaicājumu FROM rindā.........................................62
5.4.12. Vaicājums ar apakšvaicājumu SELECT rindā......................................63
5.4.13. Vaicājums ar apakšvaicājumu HAVING rindā......................................64
6. IETEIKUMU (HINTS) REALIZĀCIJA...................................................................67
6.1. 1 analizējamais vaicājums...................................................................67
6.2. 2 analizējamais vaicājums...................................................................69
6.3. 3 analizējamais vaicājums...................................................................71
SECINĀJUMI.................................................................................................................72
INFORMĀCIJAS AVOTI................................................................................................74
3
UZDEVUMA NOSTĀDNE
1. Datu Bāzes izveidošana (MS Access ~ 800MB izmērs):
2. Vaicājumu izveidošana;
SELECT … FROM T1…;
SELECT … FROM T1 WHERE…AND, OR;
SELECT ... FROM ... T1, T2…;
SELECT ... FROM ... HAVING…;
…EXISTS;
GROUP BY CUBE;
OVER;
Hierarhiskie vaicājumi
Vaicājums ar apakšvaicājumu FROM rindā
Vaicājums ar apakšvaicājumu SELECT rindā
Vaicājums ar apakšvaicājumu HAVING rindā;
3. 5 Vaicājumi( izpildāmas relāciju algebras komandas);
4. Izpildes plāna iegūšana un analīze;
5. 3 Ieteikumu realizēšana (hints);
6. Secinājumi.
4
1. PRIEKŠMETISKĀS VIDES APRAKSTS
Trešajā laboratorijas darbā tiek piedavāta jau eksistējoša .mdb datu bāzes ar
nosaukumu DEMO_DB. Lai sāktu darbu, vispirms jāiepizinās ar to struktūru un
problēmsfēru, lai atklātu datu bāzes būtību un to tabulu savstarpēju saistību. Tātād, datu
bāzē DEMO_DB pāstāv 4 tabulas: PERSONAS, NODALAS, VALSTIS un ALGAS.
1.1. MS Access datu bāzes pārskats
Kā es jau minēju, šajā datu bāzē ir 4 tabulas, kuras tikts apskatītas zēmāk.
Tabulā PERSONAS tiek glabāti sekojošie dati:
ID – personas identifikācijas numurs
NUM- personas identifikācijas numurs (dublē ID lauka saturu)
VALSTS – valsts kods, kurā persona dzīvo
DZIM_DAT – personas dzimšanas datums
KATEGORIJA – kaut kāda kategorija, kas ir saistīta ar valsts kodu
PERS_KODS – personālais kods
VARDS – personas vārds
UZVARDS – personas uzvārds
TIPS – tips
DZIMTE – personas dzimte
NODALAS_KODS – nodaļas kods
Pievēršu uzmanību tam, cik ierakstu ir šajā tabulā. Tas ir attēlots paša loga apakšā. Tātād
kopējais ierakstu skaits tabulā PERSONAS ir 2448813
Tad apskatīsim tabulu NODALAS.
5
Tabulā NODALAS tiek glabāti sekojošie dati:
ID – nodaļas identifikācijas numurs
NOD_KODS – nodaļas kods
NODALA – nodaļas nosaukums
ORGAN_KODS – organizācijas kods
PILSETA – pilsēta
RAJONS – rajons
Un atkal fiksēju kā ierakstu skaits tabulā NODALAS ir 38
Nakošā tabula ALGAS, kurā ir 27460 ierakstu.
Tabulā ALGAS tiek glabāti sekojošie dati:
ID – algas identifikācijas numurs
SAKUMA_DATUMS – sākuma datums
BEIGU_DATUMS – beigu datums
VIDEJA_ALGA – vidēja alga
FAKTISKA_ALGA – faktiskā alga
6
Un pēdējā tabulā VALSTIS ierakstu skaits ir 43
Tabulā VALSTIS tiek glabāti sekojošie dati:
VALSTS_KODS – valsts kods
VALSTS_NOS – valsts nosaukums
PILSONIBAS_NOS – valsts pilsonības nosaukums
Ierakstu skaits talākājā darbā palīdzēs pārvaudīt datu bāzes migrācijas procesa
rezultātu.
1.2. Datu bāzes ER diagramma
Kad tabulas ir apskatītas, ar MS Access funkcijas Relationships palīdzību
apskatīsim, kādā veidā šīs tabulas ir saistītas veina ar otru. Bet, kā var redzēt saišu nav,
un tabulai PERSONAS nav pat noteikta primāra atslēga. To visu ņemšu vērā, talākājā
darbā:
7
8
2. DATU BĀZES MIGRĀCIJA
Pastāv vairākas iespējas, kā importēt MS Access datu bāzi Oracle datu bāzē.
Var izmantot MS Access ODBC data source iespējas un ar fukciju Import importēt
datu bāzes struktūru un datus Oracle datu bāzē
Var izmantot jebkuru jaudīgu case-rīku, piemēram Toad Data Modeler vai Erwin,
ko apskatījām otrajā laboratorijas darbā. Ar Reverse Enginering fukcijas
palīdzību pārnest datu bāzes struktūru Oracle DBVS un ar SQL*Loader’u ievadīt
esošajā struktūrā datus.
Var ar rokam izveidot tabulas Oracle’ā un ar to pašu SQL*Loader’u ievadīt tajās
datus.
Var izmantot speciālu Oracle rīku SQL Developer, un tieši šo migrācijas veidu es
izvēlējos un aprakstīju zēmāk.
2.1. Datu bāzes migrācija ar SQL Developer
Oracle SQL Developer ir grafisks un pilnvērtīgs rīks datu bāžu izstradei. To var
brīvi lejupladēt ar OTN licenzes apstiprinašanas, no oracle oficiālās mājas lapas
(www.oracle.com). SQL Developer ļauj ne tikai veikt SQL vaicājumu un skriptu izpildi, bet
arī piedāva migrācijas iespējas.
Šīs rīks ir jauns priekš mani, un
manuprāt ir diezgan interesants, tieši
tāpēc es centīšos aprakstīt datu bāzes
migrāciju ļoti rūpīgi un detalīzēti.
Palaižot SQL Developer, pirmkārt ir
jānorādā failu tipu, kurā strādās SQL
Developer.
9
Lai sāktu datu bāzes migrāciju, jānodrošinā savienojumu ar to. Šīm nolūkam
panelē jāizvēlās piktogramma, kura apzīmē jaunu savienojumu:
Pirmkārt jāizveido savienojumu ar MS Access datu bāzi, līdz ar to jaizvēlās cilni
Access, patvaļīgi jānodefinē savienojuma nosaukums, un jānorāda datu bāzes faila
lokācija:
Nospiežot pogu Test, izvādās ārā sekojošais paziņojums:10
Tas nozīme, kā SQL Developer’am nav lasīšanas tiesību, lai piekļūt MS Access
datu bāzei. Lai dotu šīs tiesības ir jātvēr MS Access DEMO_DB datu bāzi, izvēlēties Tools -
> Options un jāieliek ķeksīti cilnes View, „system objects” rindiņā:
Turpat, Tools -> Security jāpiešķīr visas atļaujas tabulam MSysObjects,
MSysQueries un MsysRelations:
11
Visi iestatījumi ir jāsaglabā un atkal SQL Developer’ā jāveido MS Access
savienojumu, tā, kā bija aprakstīts iepriekš.
Nospiežot pogu Test var redzet Status:Success, līdz ar to var spiest pogu Connect.
Pēc savienošanas ar MS Access datu bāzi, panelē Connections var redzēt MS Access bāzi,
un zem ta tabulam, var redzēt visas 4 agrāk aprakstītas tabulas:
Tagad ir jāveic savienojums ar Oracle datu bāzi. Šīm mērķim Oracle SQL*Plus
izveidošu lietotāju Migrations, un protams piešķirsim visas atļaujas tām:
12
SQL Developer’ī tapat kā iepriekš veidoju jaunu savienojumu, tikai tagad izvēlējos
Oracle cilni, noradot tur savienojuma nosaukumu (Migration_Work), noradot lietotāju
(Migrations) un noradot paroli (qwerty). Pārējie iestatījumi tiek noradīti pēc
noklusējuma. Tad spiežot Test, paradās paziņojums par savienošanas neveiksmi:
Status: failure – test failed: Listener refused the connection with the following
error: ORA-12505, TNS: listener does not currently know of SID given in connect
descriptor The connection descriptor used by the client was: localhost:1521:xe
Var secināt, kā dati kas ir noradīti pēc noklusējuma nav pareizi, un līdz ar to datu
bāzes SID un ports nav noradīti pareizi.
13
Lai noprecizēto tos datus, Oracle direktorijā jāsameklē fails tnsnames.ora, kur šī
informācija glabājās.
DB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = user-PC)(PORT = 1522)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DB) ) )Tagad redzu, kā ports ir 1522 un SID = Service_Name = DB. To arī norādu
savienojumā, un spiežot Test, savienojuma Status = Success
Tad jānospiež Connect un savienojuma rezultātā, Connection panelē, paradīsies
tiko veikts savienojums Migration_Work:
Tagad ir jānoradā, kā tieši tas ir migrācijas repozitorijs, vietā, kur tiks migrēta
datu bāze:
14
Kad šīs process, ir izpildīts var ķērties klāt MS Access datu bāzes „kopēšanai”. To
jāveic nospiežot ar labo pēles pogu, un izvēloties funkciju Capture Microsoft Acces:
15
Kad šīs process ir pabeigts, var redzēt kopējo „nokopēto” objektu skaitu:
Nospiežot Close, panelē Captured Models, parādās tiko nokopēta MS Access datu
bāze:
16
Tagad var veikt šīs datu bāzes konvertāciju Oracle datu bāzē. Lai to izdarītu, ar
labo pēles pogu ir jānozpiež uz „nokopēto” datu bāzi, un jāizvēlās
Pirms konvertācijas, SQL Developer piedāvā izvēlēties kādus datu tipus ir
jākonvertē:
17
Sekojošā veidā notiek datu bāzes konvertācija:
Un kad process ir pabeigts, tad arī panelē Converted Models parādās tikko
konvertēta datu bāze DEMO_DB:
18
Tagad jāizvedo SQL skriptu, šīm mērķim jāizmanto fukciju Generate, nospiežot ar
labo pēles pogu uz tikko konvertēto datu bāzi:
Tad notiek SQL skripta ģenerēšana:
Kā rezultātā, SQL Developer galvēnajā logā var redzēt noģenerētu SQL skriptu:
19
Tad tas ir jāpalaiž, nospiežot piktogrammu Run Script:
Noradām savienojumu Migration_Work:
Šī procesa rezultātā Script Output cilnē var apskatīt šī skripta izpildes norisi:
20
Tagad, kad datu bāzes struktūra ir realizēta, Oracle DBVS, var kērties klāt datu
migrācijai. Lai to izpildītu, jāizvēlas Migration->Migrate Data:
Tad jānoprecizē, no kurienes dati tiks ņemti (MS Acces savienojums) un datu
avotu, kurā migrēti dati tiek domāti (Migration_Work savienojums), kā arī jānoradā
konvertēto modeli (Converted:Demo_DB(Access)):
Tad sākas datu migrācijas process. Jāpiebilst, kā šīs process ir diezgan ilgstošs, jo
ierakstu skaits it īpašī tabulā PERSONAS ir ļoti liels. Visa migrācija aizņema apmērām 3
stundas, bet tā, kā man nebija iespējas pārbaudīt cik ilgi datu migrācija aizņem,
izmantojot citas pieejas, nevaru apgalvot: 3 stundas ir daudz vai maz.
Var redzēt ziņojumu, kurā atspoguļo procesa rezultātu:
21
Tieši tagad, var konstantēt, kā ierakstu skaits katrā tabulā, kas tiek pārnesti
Oracle datu bāze precīzi sakrīt ar ierakstu skaitu MS Access datu bāzē DEMO_DB. Tas
liecinā par veikmīgu migrāciju.
2.2. Datu pārbaude
Lai pārbaudītu migrēto datu bāzi, izveidosim jaunu savienojumu Migration_Try,
tāda paša veidā, kā bija aprakstīts iepriekš:
22
Zem DEMO_DB lietotāja, var redzēt visas 4 tabulas:
Tagad vēlreiz pievēršu uzmanību saitēm starp tabulām un veikšu nelielas
izmaiņas ar mērķi saglabāt datu integritāti.
Ar labo pogu uzkļikšķinot uz tabulam, izvēlējos Edit funkciju, lai apskatītu tabulu
struktūru datus, primāras un ārējas atslēgas:
23
Tatad, kā arī bija konstatēts agrāk nekādu ārējo atslēgu nav, un tabulai PERSONAS
nav primāras atslēgas.
Līdz ar to pirmkārt nodefinēšu tabulai PERSONAS primāro atslēgu, kas ir lauks ID:
Primary key constraints Personas_pk is defined identically to index PersonasID.
Tagad visām tabulām ir primāra atslēga. Talāk pāriešu pie ārējo atslēgu
definēšanas.
24
Jāsavieno tabulas PERSONAS un VALSTIS, jo tabulā PERSONAS ir atribūts VALSTS,
kas atbilst tabulas VALSTIS primārai atslēgai VALSTS_KODS, tātad
PERSONAS.VALSTS=VALSTIS.VALSTS.KODS
Tagad vēršos klāt tabulu PERSONAS un NODALAS savienošanai. Ka ir zināms
tabulā PERSONAS ir atribūts NOD_KODS, kurā glabās tabulas NODALAS atribūta
NOD_KODS, kas savukārt nav primāra atslēga. Lai atrisinātu šo situāciju, izmainīšu
tabulas NODALAS primāro atslēgu no ID uz NOD_KODS, jo šīs atribūts arī ir unikāls, un
atbilst primārp atslēgu prasībam. Vēl varētu vispār izdzēst kolonnu ID, jo tā kļūs par
nevajadzīgo, bet tiklīdz saglabāsīm visu kā ir, un pie nepieciešamības izdarīsīm to vēlāk.
Tagad sasaistīšu abas tabulas sekojošā veidā:
PERSONAS.NOD_KODS=NODALAS.NOD_KODS
25
Tagad jāsavieno tabulas ALGAS un PERSONAS. Tabulā PERSONAS nav neviena
atribūta, kas atsaucās uz tabulas ALGAS primāro atslēgu. Ka risinājums, tabulā
PERSONAS jāpievieno jauns atribūts ALGAS_NUM, aizpildīt to ar datiem un pēc tam
savienot ar tabulu ALGA. Bet tā kā tabulā PERSONAS ir ap 2 miljoniem ierakstu, tad,
veidojot jaunu atribūtu, nodefinēsim, ka atribūta vērtība var būt Null, un aizpildīšu to
daļu. Kad tas ir paveikts jāsavieno tabulas sekojošā veidā:
PERSONAS.ALGAS_NUM=ALGAS.ID
26
Tagad, kad visas primāras un ārējas atslēgas tiek nodefinētas, var ķērties pie
vaicājumu definēšanas.
27
3. VAICĀJUMU REALIZĀCIJA
3.1. Vaicājums vienai tabulai
Tas ir vienkāršs vaicājums vienai tabulai bez nosacījumiem. Tas izvada visus
nodaļas kodus, nodaļas nosaukumus, organizācijas kodus, pilsētas un rajonus, kas
glabājas tabulā NODALAS:
3.2. Vaicājums vienai tabulai ar nosacījumu
Tas ir vienkārš vaicājums vienai tabulai ar nosacījumu, rindā WHERE .Tad izvada
nodaļas kodus, nodaļas nosaukumus, pilsētas un rajonus, tām nodaļam, kuri atrodās vai
nu Rīgā, vai nu Jūrmalā:
28
3.3. Vaicājums divām tabulām ar nosacījumiem
Šīs vaicājums izvada datus par personu (vārdu, uzvārdu un personas kodu) ka arī šīs
personas videjo algu, kuri dzīvo Latvijā un kuru vidēja alga ir mazāka par 150 latiem:
29
3.4. Vaicājums ar HAVING
Šājā vaicājumā atslēgas vards HAVING darbojās gandrīz kā WHERE, ar tādu
atšķirību, ka HAVING nosacījuma darbība tiek realizēta uz rezultējošam kolonnam, kuras
ir specificētas GROUP BY rindā, bet WHERE nosacījums darbojas uz fiziskās tabulas
kolonnam. Tas nozīme, kā HAVING rindā tiek definēts nosacījums agregātfunkcijai. Un
šīs vaicājums izvada nodaļu nosaukumus un tajā reģistrēto cilvēku skaitu dilstošā
kārtībā, gadījumā ja reģistrēto personu skaits ir lielāks par 100000:
30
3.5. Vaicājums ar EXISTS
Operatora EXISTS rezultāts ir pareizi vai nepareizi. Tas nozīme, kā tas ņem
apakšvaicājumu ka argumentu un novērtē to kā pareizo, jā tas veic jebkādu izvadi, un kā
nepareizo, ja neviens ieraksts nav izvadīts.
Līdz ar to, šīs vaicājums izvada datus par tam personam, kuru vidēja alga ir
mazāka par 100 latiem. Pirmkārt apakšvaicājumā tiek pārbaudīts, vai eksistē vispār
algas, kas atbilst nosacījumam, un kad tiek atgriezts pozitīvs rezultāts atlasa atbilstošus
vārdus un uzvārdus:
31
3.6. Vaicājums ar GROUP BU CUBE
CUBE operators ļauj vienlaikus veikt visu atribūtu kombināciju agregāciju. Pie N
atribūtiem, rezultāts ir 2N , tāpēc CUBE operators ir ļoti resursietilpīgs un parasti tiek
pielietots, tad kad ir neliels atribūtu un datu skaits.
Šīs vaicājums izvada reģistrēto cilvēku skaits pa pilsētam, pie tam, lai rezultāts
būtu pārskatamāks es izmantoju funkcijas GROUPING un CASE konstrukciju:
32
3.7. Vaicājums ar OVER
Šīs vaicājums izvada datus par personam kuru vidēja alga ir fiksēta par vislielāku
visā nodaļa reģistrēto personu starpā, kā arī nodaļas nosaukumu:
33
3.8. Hierarhiskie vaicājumi
Lai veiktu hierarhiskus vaicājumus, datu
bāzē ir jābūt tabula ar unāro saiti, jeb citiem
vārdiem sakot, kādai no tābulam jābūt hierarhijai.
Šī iemesla deļ es izveidoju jaunu tabulu.
Tabulas nosaukums būs NOD_DARBINIEKI
un ievietošu sekojošus atribūtus:
ID – darbinieka identifikācijas numurs
(primāra atslēga);
VARDS – darbinieka vārds;
UZVARDS – darbinieka uzvārds;
PROFESIJA – darbienieka amats;
NODALA – nodalas kods, kurā strāda darbienieks (ārēja atslēga);
34
VADITAJS – darbinieka vadītājs (ārēja atslēga, kas reālizēs unāro saiti).
Kad tabula ir izveidota definēšu visas ārējas atslēgas pēc agrāk noteikta plāna.
Pirmkārt savienoju tabulas NODALAS un NOD_DARBINIEKI. Un tad realizēju unāro saiti,
norādot kā tabulas NOD_DARBINIEKI atribūts VADITAJS atsaucās uz tas pašas tabulas
primāro atslēgu ID:
35
Kad tabula ir izveidota un saites nodefinētas, tabula ir jāaizpild. Šīm mērķim es
izmantoju MS Excel. Tā kā nodaļu skaits ir diezgan liels, es nolēmi aizpildīt (vaicājumu
veikšanai, tas būs pietiekams) 4 nodaļu darbiniekus (2,17,31 un 15). Kā arī noteicu
darbinieku hierarhiju, kur visgalvēnais ir nodaļas vadītājs (var redzēt, kā viņam ir tukšs
lauciņš kolonnā VADITAJS) un pēc loģikas seko pārējie darbinieki:
36
Lai veiksmīgi importētu šo .xls failu ir jānorada arī ievades vaicājumu, ko
izmantos SQL Developer. Līdz ar to šajā MS Excel failā ir jāpievieno sekojošais vaicājums,
kurš noradīs kur un ko ir jāievadā:
SELECT ID ID, NUM NUM, VARDS VARDS, UZVARDS UZVARDS, PROFESIJA
PROFESIJA, NOD_KODS NOD_KODS, VADITAJS VADITAJS
FROM (SELECT * FROM "DEMO_DB"."NOD_DARBINIEKI")
37
Kad .xls fails ir sagatavots, saglabāts un aizvērts, ir jāatgriežās pie SQL Developer,
un uzkļikšķinot ar labo pēles pogu uz tabulas NOD_DARBINIEKI, jāizvēlās Import Data.
Un izmantojot Import Wizard pa soļiem jāveic datu importu:
38
Beidzot kad datu importēšana ir pabeigta var realizēt hierarhiskus vaicājumus.
Šīs vaicājums izvada datus par 2 nodaļas darbiniekiem, attēlojot to līmeni (hierarhijas
struktūrā) un attēlojot augstāk stāvošus darbieniekus (vadītājus) path veidā:
Nākošais vaicājums parāda
visu nodaļu darbinieku hierarhiju
koka veidā. Tas arī ļoti pārskatams
veids, hierarhijas attēlošanai.
39
Vēl viens hierarhiskais vaicājums ar apakšvaicājumu WHERE rindā, izvada datus
par darbienieku hierarhiju , kuri strādā konkrētajā nodaļā – Rīgas pilsētas Centra filiālē:
3.9. Vaicājums ar pakārtoto vaicājumu FROM rindā
Šīs vaicājums izvada datus par personam, kuru amats ir gramatvedis un kuri
strādā Cesī:
40
3.10. Vaicājums ar pakārtoto vaicājumu SELECT rindā
Šīs vaicājums izvada to personu pilsonību, kuru uzvārds ir Pilats:
3.11. Vaicājums ar pakārtoto vaicājumu HAVING rindā
Izvada datus par personam, kuriem ir vislielāka fiksēta faktiska alga no visiem:
41
42
4. RELĀCIJU ALGEBRAS KOMANDAS
4.1. Vaicājums vienai tabulai ar nosacījumu
Datu atlase notiek no tabulas NODALAS, kurā ir sekojošas kolonnas:
1. Selekcija – atlasa datus, kas atbilst nosacījumiem. Tātad, tiek veikta datu
atlasīšana, pēc WHERE rindā uzdotajiem nosacījumiem PILSETA='Riga' vai
PILSETA=’Jurmala’.
2. Projekcija – atlasa un izvada tikai vaicājumā uzdotās kolonnas –
NOD_KODS,NODALA,PILSETA, RAJONS :
43
4.2. Vaicājums divām tabulām ar nosacījumu
Datu atlase notiek divās tabulās PERSONAS:
un ALGAS:
44
1. Dekarta reizinājums – jebkurš tabulu savienojums tas ir dekarta reizinājuma
apakškopa. Apakškopas būtību noteic WHERE rindā (tas ļāuj atmest nevajadzīgus
dekarta reizinājuma iegūtus ierakstus)
WHERE P.ALGAS_NUM=A.ID
2. Selekcija – no dekarta reizinājuma apakškopas, tiek atlasīti dati no WHERE rindas
WHERE P.VALSTS=’LAT’ AND V.VIDEJA_ALGA<150
3. Projekcija – no atlasītiem datiem tiek projecēti tieši tie, kuri ir noteikti SELECT
rindā, P.UZVARDS, P.VARDS, P.PER_KODS, A.VIDEJA_ALGA:
45
4.3. Vaicājums ar apakšvaicājumu FROM rindā
Datu atlase notiek divās tabulās NOD_DARBINIEKI:
un NODALAS:
Pirmkārt notiek apakšvaicājuma izpilde:
1. Dekarta reizinājums – tabulu apvienojums, un apakškopas noteikšana
WHERE NOD.NOD_KODS=N.NODALA
2. Selekcija – dati tiek atlasīti pēc nosacījuma, kurā tiek nodefinēts ka pilsētas
nosaukums ir ‘Cesis’:
3. Projekcija – no atlasītiem datiem tiek attēloti vajadzīgie dati, N.ID, N.VARDS,
N.UZVARDS, N.PROFESIJA. Apakšvaicājuma rezultāts ir:
46
Tad notiek galvena vaicājuma izpilde:
4. Kad apakšvaicājuma izpildes rezultātā tiek iegūta datu kopa, notiek tabulu
NOD_DARBINIEKI un atlasīto datu dekarta reizinājums ar noteikto nosacījumu
WHERE N.ID=A.ID
5. Selekcija – no dekarta reizinājuma apakškopas tiek atlasīti dati kuri atbilst
nosacījumam
WHERE ND.PROFESIJA=’GRAMATVEDIS’
6. Un beidzot tiek veikta projekcija, kurā tiek izvadīti atbilstoši dati N.VARDS,
N.UZVARDS, N.PROFESIJA:
47
4.4. Vaicājums ar HAVING
Šī vaicājuma apakšvaicājumā datu atlase notiek tabulā ALGAS:
Vaicājuma pamatā ir sekojošas relāciju algebras darbības:
1. Dekarta reizinājums – tabulu PERSONAS un ALGAS apvienojums, un
apakškopas noteikšana
WHERE P.ALGAS_NUM=A.ID
2. Selekcija – dati tiek atlasīti pēc nosacījuma, kurā tiek nodefinēts ka vidējai algai
ir jābūt <100 latiem
3. Selekcija – EXISTS nosacījuma pārbaude un līdz ar to vajadzīgo datu atlase
4. Projekcija – datu izvade (P.VARDS, P.UZVARDS)
48
4.5. Vaicājums ar apakšvaicājumu HAVING rindā
1. Selekcija apakšvaicājuma ar agregātfunkcijas aprēķināšanu. Selekcijas rezultāts:
2. Dekarta reizinājums – tabulu PERSONAS un ALGAS dekarta reizinājums, ar
WHERE nosacījuma noteikšanas
WHERE P.ALGAS_NUM=A.ID
5. Atlasīto datu grupēšana (kas tiek veikta ar vairāku selekciju palīdzību)
6. Sagrupētai datu kopai tiek pielietota selekcija ar mērķi atlasīt datus kas atbilst
noteiktam nosacījam, citiem vārdiem sākot ar mērķi atlasīt datus, kas ir vienādi ar
apakšvaicājuma selekcijas rezultātu.
7. Projekcija – izvēlēto datu izvade un agregātfunkcijas apreķināšana.
49
5. IZPILDES PLĀNA IEGŪŠANA UN ANALĪZE
5.1. Izpildes plāns
Izpildes plāns ir pieejams
DML teikumiem (SELECT, INSERT, UPDATE, DELETE, MERGE)
Dažiem DDL teikumiem (CREATE TABLE, CREATE INDEX, ALTER INDEX, u.t.t)
Oracle’ā ir vairākas metodes, kā iegūt SQL teikuma izpildes plānu, ar dažādu
sarežģītību un ticamības pakāpi. Darbojoties SQL*Plus vidē, visvienkāršāk ir izmantot
komandu AUTOTRACE:
Nākošā metode, kas ir sākot no 9 versijas, ir izmantot pakotni DBMS XPLAN.
Tātad, lai iegūtu izpildes plānu tabulā PLAN_TABLE var izmantot komandu EXPLAIN
PLAN, kas rezultātu ieraksta jau augšminētajā tabulā un tad no tās iegūt formatētā veidā
izmantojot pakotnes DBMS XPLAN funkciju display:
50
Vai var veikt hierarhisko vaicājumu tabulai PLAN_TABLE:
Protams eksistē vēl iespējas, izmantojot vizuālus SQL rīkus, tādus kā SQL
Developer, PL/SQL Developer vai nu pat Enterprise Manager. Parasti tājos jau ir iebūvēti
izpildes plānu iegūšanas mehanismi. Par SQL Developer izpildes plana iegūšanas veidu
runa ies talāk, jo tieši SQL Developer’ī es turpināšu darbu, šīm mērķim ir jāizveido
51
PLAN_TABLE, kurā izpildes plāni tiks glabāti.
5.2. Plāna tabulas izveidošana
Talākājam darbam, kā bija minēts agrāk ir jāizveido plānu tabula, lai būtu
iespējams kur saglabāt Explain Plan izejas datus. Lai izveidotu izejas datu tabulu var
sekot diviem variantiem.
1. variants. Jāpalaiž SQL skriptu UTLXPLAN.SQL, lai izveidotu plāna tabulas
paraugu, kuru sauc par PLAN_TABLE. Skripta nosaukums, protams, varētu būt citāds, tas
arī attiecas pie atrašanas vietas: tas ir atkarīgs no operētājsistēmas, kura tiek izmantota.
PLAN_TABLE ir tabula pēc noklusējuma, kurā Explain Plan vaicājums ievieto rindas, kas
apraksta izpildes plānu.
2. variants. Izmantot CREATE TABLE komandu, lai izveidotu izejas datu tabulu
pašiem. Tabulai drīkst piešķirt jebkuru vārdu . Kad tiek radīts Explain Plan vaicājums, šī
plāna izejas dati tiks nosūtīti uz šo tabulu. Bet jebkurā gadījumā pašizveidotai 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.
Ir acimredzami, kā 1 variants ir gan vieglāks un ātrāks, gan drošāks, tieši tāpēc
savā darbā es izmantošu pirmu pieeju, palaidīšu SQL skriptu, kurš glabājās manā
gadījumā šajā direktorijā: C:\ oracle\product\10.2.0\db_1\rdbms\admin\utlxplan.sql
Pārkopējot tabulas PLAN_TABLE izveidošanas vaicājumu no failu, un palaidot to
izpildei, rezultātā pie iepriekš izveidotām tabulām pievienojās vēl viena jauna
PLAN_TABLE, ka ir redzams zemāk:
Tātad, tagad es izveidoju tabulu, kurā glabāsies visi vaicājumu izpildes plāni, kuri
tiks iegūti talākajā darbā.
5.3. Optimizators
Par vaicājuma izpildes algoritma, jeb izpildes plāna izstrādi atbild optimizators.
52
Jāpiezīmē, kā Oracle eksistē divi optimizatori: uz likumiem bāzēts (RBO – Rule Based
Optimizer) un uz izmaksas bazēts (CBO – Costs Based Optimizer). Katrs vaicājums tiek
apstrādāts ar vienu no šīm optimizatoriem, izslēdzot gadījumus ar apakšvaicājumiem,
kuriem optimizatora veidu var noteikt individuāli, neatkarīgi no ārēja vaicājuma.
Optimizators – programma, kuru uzrakstīja cilvēki, izejot no vispārīgiem
pieņēmumiem, bet katra datu bāze ir konkrēta, tieši tāpēc, izpildes plāni, ko piedāva
optimizatori ir optimalākie. Šī iemesla deļ, viena no datu bāzes izstrādātāja
galvenakājiem uzdevumiem ir izpildes plānu kontrole, ar mērķi izmainīt tos, padarot
efektīvākus. Praksē, šī kontrole kļūs nepieciešama pati par sevī, cīņā par vaicājumu
izpildes laika samazināšanu.
5.3.1. RBO optimizators
Konceptuāli RBO darbs izskātās šādi: vispirms optimizators sastāda pilnu visu
pieejamo vaicājumu izpildes plāna variantu sarakstu, tad aprēķina katram variantam
svaru un izvēlas „vieglāku”. Faktiski, tā nenotiek, jo pats par sevī saprotams kā variantu
skaits ir neaptverāms.
Uz izpildes plāna istrādes ar šo optimizatoru ietekmē sekojošie faktori:
DBVS versija, un līdz ar to optimizatora versija;
vaicājuma sintakse;
palīg un pamat glabašanas struktūru esamība vai trūkums (indeksi, klasteri).
5.3.2. CBO optimizators
Atškīrībā no RBO, CBO cenšās optimizēt datora resursu izmaksas izpildot katru
atsevišķu vaicājumu. Bet eksistē vismāz 3 resursi: procesoru laiks, operatīvas atmiņas
izmaksas un diska izmantošanas reižu skaits. Daudzkriteriālai optimizācijai nav kopīga
risinājuma, tieši tāpēc CBO cenšās piedāvāt kompromisu, bet šīs kompromis var
nesakrīst ar izstrādātāja prioritātem.
CBO ir daudz sarežģitakāis optimizators un uz izpildes plāna istrādes ar šo
optimizatoru ietekmē sekojošie faktori:
DBVS versija, un līdz ar to optimizatora versija;
vaicājuma sintakse;
palīg un pamat glabašanas struktūru esamība vai trūkums (indeksi, klasteri);
dažu INIT parametru vertības (SORT_AREA_SIZE, CURSOR_SHARING,
53
DB_FILE_MULTIBLOCK_READ_COUNT u.t.t.);
glabājamo objektu statistikas esamība vaicājuma izpildes momentā.
5.3.3. Optimizatora konfigurēšana
Oracle pēc noklusēšanas ir uzstādīta uz likumiem bāzēta optimizācijas metode.
Sekojoša komanda ļauj izmanīt optimizācijas metodi:
ALTER SESSION SET OPTIMIZER_GOAL= (…)
Parametrs Paskaidrojums
CHOOSE
Optimizētājs izvēlas starp izmaksas bāzētu pieeju un likumu bāzētu pieeju, atkarībā no tā, vai statistika ir pieejama izmaksu bāzētai pieejai. Ja datu vārdnīcā ir statistika vismaz vienai no pieejamām tabulām, tad optimizētājs izmanto uz izmaksām bāzētu pieeju un optimizācija notiek ar mērķi iegūt vislabāko caurlaidspēju. Ja datu vārdnīcā ir statistika jebkurai pieejamai tabulai, tad optimizētājs izmanto likumu bāzētu optimizācijas pieeju
ALL_ROWS
Optimizētājs izmanto izmaksu bāzētu pieeju visām SQL komandām sesijā neatkarīgi no pieejamās statistikas. Optimizācijas mērķis ir labāku caurlaidspēju (minimālā resursu izmantošana, lai izpildītu pilnībā visu komandu).
FIRST_ROWS
Optimizētājs izmanto izmaksu bāzētu pieeju visām SQL komandām sesijā neatkarīgi no pieejamās statistikas. Optimizācijas mērķis ir labākais atbildes laiks (minimāls resursu pielietojums, lai atgrieztu rezultātu kopas pirmo rindu).
RULE Optimizētājs izmanto likumu bāzētu pieeju visām SQL komandām.
Izmaksu bāzēta pieeja kā bija minēts, balstās uz statistiku, tāpēc lai realizētu uz
izmaksam bāzētu pieeju, vispirms ir jāsavāc statistiku par tabulam, kolonam vai
indeksiem (vai visu kopā). Šīm mērķim es ģēnerēju ar SQL vaicājuma palīdzību statistiku
visam izveidotām tabulām:
54
5.4. Izpildes plāna iegūšana
Tā kā es strādāju SQL Develop’ī, es varu izmantot arī citas iespējas izpildes plāna
iegūšanai. Un tieši panelē atrodas cilne EXPLAIN un AUTOTRACE ar to palīdzību palaižot
vaicājumu es uzreiz varu redzēt izpildes plānu, netaisot vaicājumus PLAN_TABLE
tabulai. Taču jāatzīmē, kā dati vienalga tiek ņemti no PLAN_TABLE.
5.4.1. Vaicājums vienai tabulai
Uz likumiem bāzēta plāna izgūšana
55
Analīze:
Jāpiezīmē kā vispirms tiek izpildīts tas, kas ir zemāk, tāpēc arī analīzi sākšu no
lejas uz augšu.
TABLE ACCESS NODALAS FULL – pilna tabulas NODALAS pārmeklēšana
SELECT STATEMENT – vajadzīgo datu izvade uz ekrāna
Uz resursiem bāzēta analīze
Analīze:
Kā redzams izpildes plāns, ko piedāva COB ir pilnīgi līdzīgs RBO plānam, taču
tiek pievienotas vērtības COST kolonnā. Tas nozīme izmaksas, ko patērē datora resursi,
šo vērtību izrēķinā COB. Ka redzams, izmaksas nav lielas, līdz ar to vaicājuma izpildes
laiks ir mazs.
To pašu var izdarīt, kā jau agrāk aprakstīju izmantojot parastas SQL komandas un
vaicājumus. Var salidzīnāt rezultātus ar to ko iegūvu izmantojot SQL Developer EXPLAIN
funkciju:
56
Apskatot abus rezultātus, var secināt, ka tie ir identiski, līdz ar to turpmāk arī
turpināšu izmantot SQL Developer iebūvēto funkciju.
5.4.2. Vaicājums vienai tabulai ar nosacījumu
RBO plāna izgūšana
57
Analīze:
TABLE ACCCESS NODALAS FULL
FILTER PREDICATES – katrs tabulas NODALAS ieraksts tiek filtrēts pēc
nosacījuma, pie pilnas tabulas pārmeklēšanas.
SELECT STATEMENT – tiek izvadīti filtrācijas rezultāta dati.
CBO plāna izgūšana
Analīze:
Tapāt ka agrāk, šīs izpildes plāns ir līdzīgs RBO plānam, tāpēc analīzēt to atsevšķi
nav vērts.
58
5.4.3. Vaicājums divām tabulām ar nosacījumu
RBO plāna izgūšana
Analīze:
NESTED LOOP – tas ir divu tabulu apvienojums kas darbojās pēc sekojoša
algoritma:
katram ierakstam R1 ārējā tabulā PERSONAS,
katram ierakstam R2 iekšējā tabulā ALGAS ,
ja ierakstiem R1 un R2 izpildās savienojuma nosacījums
P.ALGAS_NUM=A.ID,
tad atgriež {R1, R2}
Pie tam tabulā PERSONAS notiek pilna parmēklēšana, filtrējot ierakstus atbilstoši
predikāta filtra nosacījumam. Bet tabula ALGAS vaicājums vispirms salīdzīna
savienošanas nosacījumu ar indeksu ALGAS_PK, izpildot unikālu skanēšanu, un tad
iegūst piekļuvi tabulai pēc ROWID, atbilstoši filtra nosacījumam.
SORT – iegūtie dati tiek sortēti pēc ORDER BY nosacījuma
SELECT STATEMENT – dati tiek izvadīti
59
CBO plāna izgūšana
Analīze:
HASH JOIN - šājā gadījumā atšķīrībā no RBO izpildes plāna tiek izvēlēts cits tabulu
savienojuma veids, kas darbojās pēc sekojoša algoritma:
katram ierakstam R1 kreisās puses tabulā PERSONAS
izrēķinā hešfunkciju f(R1) savienojuma kolonnai(-ām)
saglabā ierakstu attiecīgājā heštabulas vietā
katram ierakstam R2 labās puses tabulā ALGAS
izreķinā hešfunkciju f(R2) savienojuma kolonnai(-ām)
katram ierakstam R1, kam f(R1)=f(R2)
ja ierakstiem R1 un R2 izpildās savienojuma nosacījums
P.ALGAS_NUM=A.ID
tad atgriež {R1, R2}
Pie tam vispirms notiek pilna tabulu PERSONAS un ALGAS pārmēklēšana, atbilstoši filtra
nosacījumiem un tikai tad izpildās tabulu savienojuma algoritms, jau sākotnēji atlasītiem
60
datiem.
SORT – iegūtie dati tiek sortēti pēc ORDER BY nosacījuma
SELECT STATEMENT – dati tiek izvadīti
5.4.4. Vaicājums ar HAVING
RBO plāna izgūšana
Analīze:
NESTED LOOP- tabulu savienošana līdzīgi iepriekšajām vaicājumam notiek ar šo
algoritmu, tapāt tabula PERSONAS tiek pārmēklēta pilnīgi, un tabula ALGAS
skanēta pēc indeksa, salīdzīnot savienojuma nosacījumu.
FILTER – atlasīti dati tiek filtrēti pēc nosacījuma ar agregātfukcijas izmantošanu
SORT – dati tiek sortēti pēc ORDER BY nosacījuma
SELECT STATEMENT – izvada datus
CBO plāna izgūšana
61
Analīze:
HASH JOIN – arī šeit CBO izvēlējās HASH JOIN tabulu savienošanai. Kā var redzēt
šeit tapat notiek vispirms tabulu savienojums atbilstoši HASH JOIN algoritmam
( ar pilnu tabulu pārmēklēšanu)
FILTER – tapat atlasītie dati tiek filtrēti pēc nosacījuma ar agregātfunkcijas
vērtības salīdzinajumu
SORT – atlasītie dati tiek sortēti atbilstoši ORDER BY nosacījumam
SELECT STATEMENT - dati tiek izvadīti
5.4.5. Vaicājums ar EXISTS
RBO plāna izgūšana
62
Analīze:
Šeit, nav pilnīgi redzams, EXISTS rindā izpildoša apakšvaicājuma komandu:
EXISTS (SELECT 0 FROM ALGAS A
WHERE A.ID=:B1
AND A.VIDEJA_ALGA<100)
Var redzēt kā tiek ievests mainīgais B1, kuram pēc būtības jāsatur tabulas PERSONAS
kolonnas ALGAS_NUM vērtības. Šajā gadījumā, pēc manām domām, izpildes plāna secība
ir sekojoša. Uzreiz notiek EXISTS nosacījuma pārbaude, pilnīgi pārmeklējot vispirms
tabulu PERSONAS, un saglabājot ALGAS_NUM vērtību B1 mainīgajā un katru reizi
salīdzīnot to ar tabulas ALGAS indeksu (ALGAS_PK), jā vertības sakrit, tad abi ieraksti
tiek atgriezti EXISTS nosacījuma pārbaudei, un jā tie atbilst, notiek SELECT STATEMENT
tabulai PERSONAS.
CBO plāna analīze
63
Analīze:
HASH JOIN – šis izpildes plāns ir labāk saprotams. Notiek tabulu savienojums pēc
HASH JOIN algoritma ar savienojuma nosacījumu P.ALGAS_NUM=A.ID. Šeit notiek pilnā
abu tabulu pārmeklēšana kā ir redzams, un EXISTS nosacījuma izpilde šajā gadījumā tiek
realizēta ar P.ALGAS_NUM IS NOT NULL nosacījuma pārbaudi. Un tiešām, ja ALGAS_NUM
satur vērtību, tad jā tas atbilst tabulas ALGAS nosacījumam A.VIDEJA_ALGA<100, tad tas
apmierinā vaicājumu.
5.4.6. Vaicājums ar OVER
RBO plāna izgūšana
64
Analīze:
NESTED LOOP - notiek pirmais tabulu PERSONAS un ALGAS savienojums ar
savienojuma nosacījumu P.ALGAS_NUM=A.ID, pēc jau zināma algortima
NESTED LOOP – tad notiek otrais savienojums, tabula NODALAS, tiek savienota
ar iepriekš atlasīto datu kopu ar savienojuma nosacījumu
P.NOD_KODS=N.NOD_KODS
WINDOW SORT sakārtojuma komandas WINDOW izmantošanu nosāka
analitiskas funkcijas OVER izmantošana.
VIEW – operācija izpilda virtuālu struktūru - skatu un atgriež atlasītus ierakstus
SELECT STATEMENT operācijai
SELECT STATEMENT – izvada datus
CBO plāna izgūšana
65
Analīze:
MERGE JOIN –tabulu savienojuma tips , kas vienmēr notiek ar sortēšanu pēc
sekojoša algoritma:
sakārto tabulas NODALAS ierakstus pēc savienojuma kolonnas (NOD_KODS)
sakārto tabulas PERSONAS ierakstus pēc savienojuma kolonnas
iegūst pirmo ierakstu R1 no NODALAS
iegūst pirmo ierakst R2 no PERSONAS
kamēr nav sasniegts A vai B beigas
ja ierakstiem R1 un R2 izpildās savienojuma nosacījums
(P.NOD_KODS=N.NOD_KODS)
tad atgriež {R1, R2}
citādi ja R1<R2
tad iegūst nākošo ierakstu R1 no NODALAS66
citādi
tad iegūst nākošo ierakstu R2 no PERSONAS
HASH JOIN – tad notiek atlasīto datu savienojums ar tabulu ALGAS pēc HASH
JOIN algoritma, kas ir minēts agrāk
WINDOW SORT sakārtojuma komandas WINDOW izmantošanu nosāka
analitiskas funkcijas OVER izmantošana.
VIEW – operācija izpilda virtuālu struktūru - skatu un atgriež atlasītus ierakstus
SELECT STATEMENT operācijai
SELECT STATEMENT – izvada datus
5.4.7. Vaicājums ar GROUP BY CUBE
CBO plāna izgūšana
67
Analīze:
HASH JOIN – notiek tabulu NODALAS un PERSONAS savienojum pēc noteikta
algoritma
HASH TABLE ACCESS – operācija saglaba temporālā tabulā sagrupētus pēc
GROUP BY ieraktus.
VIEW - no temporālas tabulas viedo skatu (virtuālu struktūru)
LOAD AS SELECT – iegūst visus datus no izpildāmām funkcijam
TEMP TABLE TRANSFORMATION – temporālas tabulas transformācija un datu
nodošana VIEW komandai
VIEW – virtuālas struktūras veidošana, un datu nodošana nākamai komandai
SELECT STATEMENT – datu izvade
68
5.4.8. Hierarhiskais vaicājums 1
CBO plāna izgūšana
Analīze:
CONNECT BY – notiek tabulas NOD_DABINIEKI hierarhiskais savienojums, pie
pilnās tabulas pārmēklēšanas un ar nosacījumu UZVARDS=’PARAMONOVS’
FILTER – atlasīto datu filtrēšana, pēc nosacījuma un datu nodošana nākamai
komandai
SELECT STATEMENT – izvada datus
5.4.9. Hierarhiskais vaicājums 2
CBO plāna izgūšana
69
Analīze:
CONNECT BY - notiek tabulas NOD_DABINIEKI hierarhiskais savienojums, pie
pilnās tabulas pārmēklēšanas un ar nosacījumu VADITAJS IS NULL
SELECT STATEMENT – atlasīto datu izvade
5.4.10.Hierarhiskais vaicājums 3
CBO plāna izgūšana
70
Analīze:
CONNECT BY - notiek tabulas NOD_DABINIEKI hierarhiskais savienojums, pie
pilnās tabulas pārmēklēšanas un ar nosacījumu VADITAJS IS NULL
FILTER – no tabulas NODALAS tiek atlasīti dati, kas atbilst nosacījumam
NODALAS.NODALA=’Rigas pilsetas filiale’ un atlasīta iepriekšējā solī kopā tiek
atlasīta atbilstoši nosacījumam, kas izpildās apakšvaicājumā no tabulas NODALAS
SELECT STATEMENT – izvada datus
71
5.4.11.Vaicājums ar apakšvaicājumu FROM rindā
RBO plāna izgūšana
Analīze:
NESTED LOOP – notiek tabulu NOD_DARBINIEKI un NODALAS savienojums pēc
NESTED LOOP algoritma, ar savienojuma nosacījumu
NOD.NOD_KODS=N.NODALA. Tabula NOD_DARBINIEKI ir pilnīgi pārmeklēta, un
vērtības ir salīdzīnātas ar tabulas NODALAS indeksu (NODALAS_PK) un
pārbaudot nosacījumu tabulai NODALAS, NOD.PILSETA=’Cesis’
NESTED LOOP – tāda pašā veidā, kā iepriekš, notiek atlasīto iepriekšēja solī datu
kopas savienojums ar tabulu NOD_DARBINIEKI, pārmēklējot pēc indeksa ar
savienojuma nosacījumu ND.ID=N.ID
SELECT STATEMENT – izvada datus
CBO plāna izgūšana72
Analīze:
MERGE JOIN SORT – tabulā NOD_DARBINIEKI tiek atlasīti dati pēc nosacījuma
ND.PROFESIJA=’GRAMATVEDIS’, tie dati ir sortēti pēc savienojuma kolonnas ID.
HASH JOIN – tiek savienoti atlasītie dati un tabula NODALAS ar savienojuma
nosacījumu NOD.NOD_KODS=N.NODALA.
SELECT STATEMENT – izvada datus
5.4.12.Vaicājums ar apakšvaicājumu SELECT rindā
RBO un CBO plāna izgūšana
RBO un CBO plāni šajā vaicājumā pilnīgi sakrīt:
73
Tāpēc analīzēšu CBO plānu:
Analīze:
SORT – notiek tabulas PERSONAS ierakstu sortēšana pie pilnās pārmēklēšanas,
pēc nosacījuma P.UZVARDS=’PILATS’
TABLE ACCESS VALSTIS BY ROWID – tiek pārmēklēta tabula VALSTIS pēc
ierakstu indeksiem, kur valsts ID sakrīt ar tabulas PERSONAS vērtību VALSTS
SELECT STATEMENT – tiek izvadīti dati
5.4.13.Vaicājums ar apakšvaicājumu HAVING rindā
RBO plāna izgūšana
74
Analīze:
NESTED LOOP – tabulu PERSONAS un ALGAS savienojums pēc noteikta algoritma
ar savienojuma nosacījumu P.ALGAS_NUM=A.ID
SORT – iegūto savienojuma rezultāta datu sortēšana pēc GROUP BY nosacījuma,
atsevišķi tabulas ALGAS sortēšāna ar agregātfunkcijas aprēķināšanu
FILTER – datu filtrēšana atbiltoši nosacījumam ar apakšvaicājumu
SELECT STATEMENT – datu izvade
CBO plāna izgūšana
75
Analīze:
Līdzīgi RBO plānam notiek tabulu apvienošana un datu sortēšana
HASH JOIN – tabulu PERSONAS un ALGAS savienojums pēc noteikta algoritma, ar
savienojuma nosacījumu P.ALGAS_NUM=A.ID
SORT – iegūto savienojuma rezultāta datu sortēšana pēc GROUP BY nosacījuma,
atsevišķi tabulas ALGAS sortēšāna ar agregātfunkcijas aprēķināšanu
FILTER – datu filtrēšana atbiltoši nosacījumam ar apakšvaicājumu
SELECT STATEMENT – datu izvade
Kopumā var secināt, kā dažreiz RBO un CBO plāni sakrit, bet lielakoties, tiem ir
noteiktas atsevišķas pazīmes. Tā piemērām RBO dod priekšroku NESTED LOOP
savienojumu tipam, ar indeksu pārmēklēšanu, savukārt CBO dod priekšroku HASH JOIN
savienojumam, ar pilnu tabulu pārmēklēšanu. Kā tas ietekmē uz vaicājuma izpildes
ātrdarbību, meģināšu izprast nākamā 6. nodaļā.
76
6. IETEIKUMU (HINTS) REALIZĀCIJA
HINT – tas ir ieteikums optimizatoram, kurš tiek pievienots SQL vaicājumam. Ar
ieteikumu palīdzību var definēt tabulu savienojuma kārtību, tabulu skanēšanas veidus,
var noradīt indeksus, kurus ir jāizmanto, kā arī var definēt optimizācijas mērķus. Lai
izmantotu HINT’u vaicājumā, to ir nepieciešams ievietot uzreiz aiz SELECT operatora
sekojošā veidā /*+ <HINT> */
Piemērām lai mainīt optimizācijas mērķi var izmantot sekojošus ieteikumus, kas
pēc būtības ir tas pats ko var darīt mainot SQL sesijas parametrus:
SELECT /*+ FIRST_ROWS */
SELECT /*+ ALL_ROWS */
SELECT /*+ CHOOSE */
SELECT /*+ RULE */
Tā kā darba gaitā es analizēju gan RBO, gan CBO izpildes plānus, es tiešā veidā
neizmantošu ieteikumus vaicājumu optimizēšanai, jo tādu ieteikumu izmantošana ka
indeksu norādīšana, vai tabulu savienojuma tipa definēšana CBO izpildes plāna nekā
nevar ietekmēt, jo lielākoties CBO optimizators arī izvēlās visefektīvāku variantu un
savienojuma tipu. To arī es centīšos paradīt ar piemēriem.
6.1. 1 analizējamais vaicājums
Zemāk var redzēt izpildes plānu vaicājumam, ko piedāvā RBO:
77
Diemžēl nav zināms šī izpildes plāna izmaksas, bet to var uzzināt, jā noteikt
optimizatoram, lai tas izpild NESTED LOOP tabulu savienojumu, tā kā tas ir RBO izpildes
plānā:
78
Kā rezultāts tiks iegūts tāds pats izpildes plāns, ko piedāvā RBO optimizators, un
ar apreķinātam izmaksam. Tās ir diezgan lielas, jo šīs vaicājums vēršās pie tabulas
PERSONAS, un tajā kā zināms ir aptuvēni 2 miljonu ierakstu.
Tagad meģināšu ar HINT’u palīdzību noteik citu tabulu savienojumu tipu, un tieši
HASH JOIN un salīdzīnāšu abus rezultātus:
79
Lai neatgrieztos atpakaļ, atzīmēšu kā tagad tiek iegūts, tieši tāds izpildes plāns, ko
piedavājā CBO optimizators. Un ka var redzēt izmaksas ir krietni mazākas, kaut gan
ierakstu skaits tabulai PERSONAS paliek nemainīgs.
80
6.2. 2 analizējamais vaicājums
Šī vaicājuma izpildes plāns ar ieteikumu izmantot NESTED LOOP savienojumu arī
ir pilnīgi līdzīgs RBO šī vaicājuma izpildes plānam. Ir redzams, kā izmaksas šajā
gadījumā ir pārāk lielas.
Tagad meģināšu ieteikt izmantot HASH JOIN savienojumu un tapat pārbaudīšu
MERGE JOIN savienojumu:
81
Bez šaubām tieši HASH JOIN savienojums dod optimālāku risinājumu.
No visa tā var secināt, kā:
MERGE JOIN savienojums, tiek izmantots ar tabulu sakārtošanu (vai jau sakārtotam
tabulāmm un tiek izmantots tad, kad HASH JOIN savienojums nav iespējams
HASH JOIN savienojums, tiek izmantots liela datu apjoma apstrādei un kad
nepieciešama pilnā tabulu pārmeklēšana
NESTED LOOP savienojums, tiek izmantots neliela apjoma datu apstrādei, jo lielāko
datu apjomām krietni pazeminā ātrdarbību.
6.3. 3 analizējamais vaicājums
Vēl viens vaicājums, ko es gribu apskatīt ir ar EXISTS funkcijas izmantošanu.
Zemāk ir paradīts CBO piedāvātais plāns:
Ka redzams, šī plāna ietvaros notiek pilna tabulu skānēšana pēc indeksiem. Šajā
gadījumā pilna tabulu pārmeklēšana varētu dod rezultātus atrāk. Līdz ar to
optimizatoram ievadu ieteikumu neizmantot nevienu indeksu, un veikt pilnu
pārmēklēšanu:
82
Ka rezultāts pie pilnas pārmēklēšanas šajā vaicājumu izmaksas ir nedaudz mazākas.
83
SECINĀJUMI
Šī laboratorijas darba mērķis bija iepazīties ar vaicājumu izpildes plāna jēdzienu
un koncepciju, kā arī iegūt kaut minimālas iemaņas praktiskājā vaicājumu optimizācijā.
Šīs darbs bija daudzuzdevumu, tā kā vaicājumu optimizācijas realizācijai, bija
nepieciešams, pirmkārt, migrēt MS Access datu bāzi Oracle’ā. Tā kā agrāk man nebija
tādas pieredze, diezgan ilgu laiku pavadīju, iedziļinoties būtībā un apskatot visu
iespējāmo variantu datu bāzes migrācijai, lai tas būtu visefektīvākais un visātrākais
variants. Šajā jautājumā man palīdzēja tīmekļa resursi, kuros diezgan plaši un detalīzēti
ir apgaismoti dotie jautājumi. Izvēlējoties datu bāzes migrāciju ar SQL Developer
palīdzību, es veiksmīgu tiku galā ar šo uzdevumu, neskatoties uz dažām problēmam.
Kopumā migrācija aizņema apmērām 3 stundas, un lielāka daļa no šī laika, tiek atvēlēta
tabulas PERSONAS ierakstu migrācijai (ap 2 miljonu ierakstu). Darba sākumā, man bija
grūti spriest cik tas ir daudz vai mazs, bet tagad man bija iespēja uzzināt no kolēģiem
studetiem, kuri bija izmantojuši citu pieeju, cik daudz laika aizņēma datu bāzes
migrācija, izmantojot dažas citas metodes. Un viens no ātrākājiem, bija arī viens no
vieglākajiem, un tieši: 4 tabulu izveidošana Oracle’ā, MS Access tabulu ierakstu
importēšana teksta failos un visbeidzot datu ievade ar SQL*Loader palīdzību. Daži
ievadīja datus, izmantojot MS Excel un ODBC iespējas, nevis SQL*Loader (savā darbā,
veidojot un aizpildot jaunu tabulu hierarhieskiem vaicājumiem, es arī apskatīju un
aprakstīju šo iespēju), taču tiem, kas izmantoja šo peieju sākotnējas datu bāzes
migrācijai, nācas sastopties ar sekojošu problēmu: MS Excel’ī eksistē ierakstu skaita
ierobežojums, līdz ar to visi 2 miljoni tabulas PERSONAS ieraksti nevarēja pārnest
pilnīgi. Kas attiecās uz SQL Developer rīku, ko izvēlējos es, varu pateikt kā neskatoties uz
ilgu procesu, šī pieeja dod garantētu un pilnu veiksmīgu datu bāzes migrāciju. Kopumā,
priekšsagatavošanas darbs (datu bāzes migrācija) man iznāca diezgan apjomīgs, bet
interesants, un deva man ļoti interesantu pieredzi.
Nākošais darba etaps, vaicājumu realizācija, bija man diezgan pazīstams
uzdevums, tāpēc lielu gŗūtību nesagādāja. Ir jāpiezīmē, kā pēc datu bāzes migrācijas, bija
nepieciešams veikts vairākas piestrādes, pēc kurām ķļūva iespējam vispār veikt
vaicājumus, jo tabulas pat nebija savā starpā savienotas.
Vaicājumos izpildāmo relācijas algebras operāciju apraksts bija vērtīgs, jo
palīdzēja tikt skaidrībā un izprasts vaicājumu izpildes sēcību un loģiku. Tieši šīs
84
detalizets apraksts, deva priekšstatu par to kas ir vaicājuma izpildes plāns, par kuru
talāk darbā ies runa.
Vissvarīgākais, manuprāt, darba etaps tika saistīts tieši ar optimizatora darbības
principa, to režīmu izpratni un izpildes plānu analīzi. Tieši planu analīze, man likas pats
grūtākais šajā darbā, jo dažreiz tā vai citā vaicajuma izpildes plāna loģiku ir grūi
„atšifrēt” nepārzinot visas funkcijas un komandas , ļoti sajutās pieredzes un zināšanu
trūkums šajā ziņā. Izpildes plānu „atšifrēšanai” man bija nepieciešams diezgan daudz
laika. Varu piezīmēt, kā pieejami materiāli par šo tēmu ir ļoti apjomīgi un nekonkrēti,
kas vēlreiz apliecināja, kā šī tēma ir ļoti plaša un dzīļa, tāpēc „pārliecinātākai” analīzei
nepieciešama ilgāka un dzīļaka SQL vaicājumu optimizācijas stūdēšana. No citās pusēs,
es sapratu, cik tas ir svarīgs jautājums, daudzlietotāju un operatīvas IS izstrādei.
Tā kā savā darbā es apskatīju un analīzēju gan RBO, gan CBO izpildes plānus, varu
secināt, kā CBO plāni ir daudz efektīvākie, nekā RBO un lielakoties, tiešām, atrod
optimālāku risinājumu. Taču šajā gadījumā daudz kas ir atkarīgs no statistisko datu
precīzitātes. Šo secinājumu es izdarīju, balstoties uz sekojoša fakta: uzlabot CBO izpildes
plānus ar hintiem man praktiski neizdevās. Bet kopumā, es arī secināju , kā vaicājuma
ātrdarbību ļoti ietekmē pareizais tabulu savienojumu veids, kas tieši katrā konkrētajā
gadījumā, vislābāk der. Piemērām, tad, kad vaicājums griežās pie tabulas ar ļoti lielu
datu apjomu, labāk ir izmantot HASH JOIN savienojumu, neskatoties uz pilnu tabulu
skānēšanu, jo tas izrādās krietni „vieglāks” nekā piemērām NESTED LOOP savienojums
ar indeksu pārmēklēšanu pie tāda paša datu apjoma.
Jebkurā gadījumā, šī tēma paliek ļoti aktuāla un orientēta uz prakstisku pusi.
Grūti atrast precīzu pamācību, kā optimizēt vaicājumus, jo katrs vaicājums ir atsevišķs
gadījums. Paliek tikai ekperimentēt un prakstiski pārbaudīt visus pieņemumus, lai
iegūtu reālu priekšstatu par vaicājumu optimizāciju un apgūtu lielu HINT’u daudzumu.
Es uzskatu, kā šīs darbs ir lieliska iespēja un meģinājums ieskatīties šajā tēmā, un
iegūt pieredzi, kas obligāti būs lietderīga nākotnē.
85
INFORMĀCIJAS AVOTI
1. J.Eiduks, 2008./2009.māc.g. Izdales materiāli no diska
2. http://forum.vingrad.ru/forum/topic-100586.html
3. http://www.oracle.com/technology/tech/migration/workbench/viewlets/
msaccesslauncher.html
4. http://www.sql.ru/forum/actualsearch.aspx?
search=access+oracle&sin=1&a=&ma=0&bid=3&dt=-1&s=1&so=1&pg=2
5. http://www.oracle.com/technology/tech/migration/workbench/viewlets/
accessconnlauncher.html
6. http://msdn.microsoft.com/ru-ru/library/bb522495.aspx
7. http://www.interface.ru/fset.asp?Url=/oracle/kakie.htm
8. http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/
toc.htm
86
