Viss plūst viss mainās, MySQL te bija pats savs MySQL, te Sun MySQL, tagad jau Oracle’s MySQL
Oracle savai 11 dažādu DBVS kolekcijai varēs pievienot vēl vienu. OK nezinu kā tur ir ar visādām licencēm/autortiesībām, bet katrā ziņā nākotne izskatās interesanti.

Tā kā Oracle dzimtā DBVS jau ir kļuvusi pārāk sakārtota un tuvu pilnībai un kā mēs zinām, tad viss, kas kļūst pilnīgs, bankrotē un tiek aizvietots ar kaut ko haotiskāku un mazāk sakārtotu, tad var izrādīties, ka vismaz lielākais haoss būs jāmeklē tajā pašā kompānijā

Darījums, protams, vēl procesā, cena 7,4 miljardi, sīkākas detaļas skat. Bloomberg.com lapā un arī pašas Oracle interpretācijā. Sapnis par Oracle spēju nodrošināt visu sākot ar dzelžiem, operētājsistēmu, līdz DBVS un gatavām aplikācijām kļūst aizvien tuvāks…

SQL teikumu izpildes plāns (query execution plan) – kurš gan nopietni interesējoties par datubāzu izstrādi tādu terminu nav dzirdējis? Vaicājums lēni strādā – paskaties izpildes plānu! Tiesa gan vairumā gadījumu tiek pašas par sevi pieņemtas divas (varbūt pat trīs) lietas:

• persona zin, kā izpildes plānu dabūt;
• persona zin, ko iegūtais izpildes plāns nozīmē;
• persona zin, kā panākt, lai izpildes plāns būtu optimālāks nekā iegūtais vai arī saprot, ka nekas labāks nevar sanākt (neobligātais solis).

Šai rakstā apspriedīšu pirmo soli jau parasti izvēlētajām DBVS – Oracle, MySQL, SQL Server. Kā jau Jūs noteikti zinat visas DBVS ir atšķirīgas, attiecīgi atšķirīgas ir arī metodes, kā izpildes plānu iegūt. Tātad pēc kārtas.

Oracle

Oraclē ir vairākas metodes, kā iegūt SQL teikuma izpildes plānu, ar dažādu sarežģītību un ticamības pakāpi. Ja izmantojat rīku SQL*Plus, tad visvienkāršāk ir izmantot šī rīka komandu autotrace. Es šeit gari nekāvēšos pie šī rīka un komandas apraksta, jo tie abi ir augšminētajās saitēs, šeit tikai īss piemērs. Visiem turpmākajiem piemēriem tiks izmantotas tabulas no raksta par Dekarta reizinājumu.

Piemērs 1. Izpildes plāna iegūšana izmantojot autotrace.

SQL> set autot traceonly explain
SQL> SELECT prs_personas_kods, prs_vards, adr_pilseta
  2  FROM personas
  3  INNER JOIN adreses ON prs_adr_id = adr_id
  4  /
Execution Plan
----------------------------------------------------------
Plan hash value: 4160699136
----------------------------------------------------------------
|Id|Operation          |Name    |Rows|Bytes|Cost(%CPU)|Time    |
----------------------------------------------------------------
| 0|SELECT STATEMENT   |        |  3 | 231 |   7  (15)|00:00:01|
|*1| HASH JOIN         |        |  3 | 231 |   7  (15)|00:00:01|
| 2|  TABLE ACCESS FULL|ADRESES |  3 | 105 |   3   (0)|00:00:01|
| 3|  TABLE ACCESS FULL|PERSONAS|  4 | 168 |   3   (0)|00:00:01|
----------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - access("PRS_ADR_ID"="ADR_ID")
Note
-----
   - dynamic sampling used for this statement

Jāatgādina, ka autotrace mēdz melot – izpildes plāns ir tas ko Oracle domā, ka izpildīs zinot pašreizējo informāciju, aktuālajā izpildē situācija noteiktos apstākļos var mainīties. Tiesa gan meli ir relatīvi reti, bet ir.

Nākošā metode, kas ir sākot no 9 versijas, bet kopš 10 versijas tā jau ir vienkārši nenormāli ērta, ir izmantot pakotni dbms_xplan. Tātad, lai iegūtu izpildes plānu tabulā plan_table (noklusētā tabula), mēs varam 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. Arī šis veids mēdz melot, jo pēc būtības autotrace dara to pašu tikai klusiņām fonā.

Piemērs 2. Izpildes plāna saglabāšana tabulā plan_table un iegūšana no tās izmantojot dbms_xplan. Šis strādā jau no 9 versijas.

SQL> set autot off
SQL> EXPLAIN PLAN FOR
  2  SELECT prs_personas_kods, prs_vards, adr_pilseta
  3  FROM personas
  4  INNER JOIN adreses ON prs_adr_id = adr_id
  5  /
Explained.
SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
----------------------------------------------------------------
Plan hash value: 4160699136
----------------------------------------------------------------
|Id|Operation          |Name    |Rows|Bytes|Cost(%CPU)|Time    |
----------------------------------------------------------------
| 0|SELECT STATEMENT   |        |  3 | 231 |   7  (15)|00:00:01|
|*1| HASH JOIN         |        |  3 | 231 |   7  (15)|00:00:01|
| 2|  TABLE ACCESS FULL|ADRESES |  3 | 105 |   3   (0)|00:00:01|
| 3|  TABLE ACCESS FULL|PERSONAS|  4 | 168 |   3   (0)|00:00:01|
----------------------------------------------------------------

PLAN_TABLE_OUTPUT
----------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - access("PRS_ADR_ID"="ADR_ID")
Note
-----
   - dynamic sampling used for this statement

Tad tagad par to nenormāli ērto piegājienu, lai iegūtu patieso izpildes plānu un piedevām vēl gan sagaidīto kardinalitāti, gan patieso – to, kas tika iegūta izpildes laikā. Un tātad jāizmanto dbms_xplan.display_cursor. Ar piemērā redzamajiem parametriem izpildes plāns tiek paņemts pēdējam izpildītajam SQL teikuma no datu vārdnīcas dinamiskajiem (v$) skatījumiem. SQL teikumā pierakstot hintu gather_plan_statistics, iegūstam arī patieso izpildes laika kardinalitāti un izpildes laiku katram plāna solim.

Piemērs 3. Pēdējā izpildītā SQL teikuma izpildes plāna iegūšana no sistēmas dinamiskajiem skatījumiem.

SQL> set pages 50000
SQL> set serveroutput off
SQL> SELECT /*+ gather_plan_statistics */
  2  prs_personas_kods, prs_vards, adr_pilseta
  3  FROM personas
  4  INNER JOIN adreses ON prs_adr_id = adr_id;
PRS_PERSONA PRS_VARDS      ADR_PILSETA
----------- -------------- ------------
23456789012 PĒTERIS        TALSI
34567890123 ANNA           TALSI
45678901234 KĀRLIS         TALSI
SQL> select * from
  2  table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
--------------------------------------------
SQL_ID  6u4ahhavg90cy, child number 0
-------------------------------------
SELECT /*+ gather_plan_statistics */
prs_personas_kods, prs_vards, adr_pilseta
FROM personas INNER JOIN
adreses ON prs_adr_id = adr_id
Plan hash value: 4160699136
----------------------------------------------------------
|Id|Operation         |Name    |E-Rows|A-Rows|   A-Time  |
----------------------------------------------------------
|*1|HASH JOIN         |        |    3 |    3 |00:00:00.01|
| 2| TABLE ACCESS FULL|ADRESES |    3 |    3 |00:00:00.01|
| 3| TABLE ACCESS FULL|PERSONAS|    4 |    4 |00:00:00.01|
----------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - access("PRS_ADR_ID"="ADR_ID")
Note
-----
   - dynamic sampling used for this statement
 

Augšminētajā  piemērā es esmu izvācis ārā dažas kolonas, jo tās diemžēl bojā izskatu visai vietnei , bet interesantākās esmu atstājis – E-Rows ir paredzētais ierakstu skaits (estimated rows), bet A-Rows ir aktuālāis ierakstu skaits (actual rows). A-Time savukārt ir laiks, cik paterēts katram solim. Kā redzam šai gadījumā plānotais un reālais ierakstu skaits sakrīt, bet laiks ir 0.01 sekunde (tā kā norādītajam laikam ir noapaļošanas kļūdas, tad uz tik maziem lielumiem precizitāte, protams, klibo).

Vēl divas iespējas, lai iegūtu  reālos izpildes plānus citām sesijām un/vai vairākiem SQL teikumiem, ir izmantot vai nu to pašu dbms_xplan.display_cursor noskaidrojot sql_id vērtību, piemēram, no v$sql, vai arī palaist trasēšanu (trace), kas ģenerē trasēšanas datni uz servera, kurā var iegūt arī visus precīzos izpildes plānus u.c. informāciju.

Protams, ja izmantojat kādu no vizuālajiem rīkiem, tad lielākajā daļā no tiem ir iebūvēta plāna izpildes apskate. PL/SQL Developer tas tiek ņemts no plan_table (attiecīgi nav pilnīgas drošības par tā patiesumu) un izskatās šādi:

Piemērs 4. Vizuāls SQL teikuma izpildes plāns rīkā PL/SQL Developer.

Savukārt, ja gadās izmantot Enterprise Manager konsoli, tad tas ir reālais izpildes plāns un izskatās šādi:

Piemērs 5. Vizuāls SQL teikuma izpildes plāns Enterprise Manager Console.

MySQL

MySQLā ir komanda EXPLAIN, ko vienkārši piekabina sākumā SQL Select teikumam un iegūst izpildes plānu.

Piemērs 6. Izpildes plāna iegūšana MySQLā.

mysql> EXPLAIN
    -> SELECT prs_personas_kods, prs_vards, adr_pilseta
    -> FROM personas
    -> INNER JOIN adreses ON prs_adr_id = adr_id;
+--+-----------+--------+------+-------------+-------+-------+----+
|id|select_type|table   |type  |possible_keys|key    |key_len|rows|
+--+-----------+--------+------+-------------+-------+-------+----+
| 1|SIMPLE     |personas|ALL   |NULL         |NULL   |NULL   |   1|
| 1|SIMPLE     |adreses |eq_ref|PRIMARY      |PRIMARY|4      |   1|
+--+-----------+--------+------+-------------+-------+-------+----+
2 rows in set (0.00 sec)

Ja nu gadījumā  jums šāds izskats nepatīk, tad varat mēģināt izmantot rīku Maatkit, kas sola izpildes plānu vizualizēt koka formā, tiesa gan pats neesmu lietojis.

Līdzīgi kā Oraclei arī šeit EXPLAIN komanda var melot un tai ir arī citi šādi tādi mīnusi, kā rakstīts šai MySQL Performance Blog rakstā, tiesa gan izskatās, ka MySQL nav citu alternatīvu veidu, kā 100% droši iegūt faktisko izpildes plānu.

SQL Server 

SQL Server kā zināms izceļas ar savu “pogaino” interfeisu un tur iegūt izpildes plānu var ļoti vienkārši piespiežot pareizo podziņu SQL Server Mangement Studio ir divas pogas 1) parādīt paredzamo izpildes plānu (Display Estimated Execution Plan) un 2) parādīt reālo izpildes plānu (Display Actual Execution Plan). Pirmā podziņa speciāli uzģenerē plānu, kas izskatās šādi.

Piemērs 7. Vizuāls paredzamais SQL teikuma izpildes plāns SQL Serverī.

Lai dabūtu reālo izpildes plānu, ir jānospiež podziņa mazliet pa labi un pēc SQL teikums jāizpilda, normālā gadījumā tas jau neatšķiras no paredzamā, tikai ar kursoru uzbraucot uz operācijas var iegūt papildus ziņas (piemēram, reālais ierakstu skaits Actual Number of Rows).

Piemērs 8. Vizuāls reālais SQL teikuma izpildes plāns SQL Serverī.

Izmantojot šādus SET teikumus, augstāk redzamās bildītes – izpildes plānus – var iegūt arī teksta formā:

• SET SHOWPLAN_ALL { ON | OFF } – attēlo paredzamo izpildes plānu.
• SET STATISTICS PROFILE { ON | OFF } – attēlo reālo izpildes plānu un reālo ierakstu skaitu katrā solī.

Ilustrācijai piemērs ar SET SHOWPLAN_ALL ON:

Piemērs 9. Paredzamais SQL teikuma izpildes plāns SQL Serverī.

StmtText                                                          
------------------------------------------------------------------
SELECT prs_personas_kods, prs_vards, adr_pilseta
FROM personas
INNER JOIN adreses ON prs_adr_id = adr_id                         
|-Nested Loops(Inner Join, OUTER REFERENCES:(personas.prs_adr_id))
  |-Clustered Index Scan(OBJECT:(personas.PK__personas__4374BBA0))
  |-Clustered Index Seek(OBJECT:(adreses.PK__adreses__418C732E),..

Uzrakstot SET STATISTICS PROFILE ON, iegūst sql teikuma izpildes rezultātu, to pašu, ko iepriekšējā piemērā un vēl kolonas Rows un Executes, kas norāda cik ieraksti atgriezti un cik reizes operācija izpildīta:

Piemērs 10. Reālais SQL teikuma izpildes plāns SQL Serverī.

Rows Executes StmtText                                       
---- -------- ------------------------------------------------
3    1        SELECT prs_personas_kods, prs_vards, adr_pilseta
              FROM personas
              INNER JOIN adreses ON prs_adr_id = adr_id
3    1        |--Nested Loops(Inner Join, OUTER REFERENCES
4    1          |--Clustered Index Scan(OBJECT...
3    4          |--Clustered Index Seek(OBJECT...

Tālākā lasāmviela

• Šis raksts jau bija gandrīz pabeigts pirms es ķēros pie savas Oracle prezentācijas par SQL teikuma izpildes plānu. Tajā neapšaubāmi ir vairāk informācijas kā šeit, bet, protams, bez īpašiem paskaidrojumiem;
• dbms_xplan 10g versijā – Jonathan Lewis raksts par dbms_xplan.

Strādājot ar lielākiem datu apjomiem, datubāzēs parasti rodas problēmas ar ātrdarbību. Viens no izplatītiem iemesliem (par ko es rakstīju arī savās 7 lietās, ko nevajag darīt) ir datu uztveršana un darbības ar tiem pa ierakstiem un nevis kopām. Protams, ne es pirmais, ne pēdējais, kas izrunā šo maģisko vārdu savienojumu “apstrādāt datus datubāzē KĀ KOPAS“, tikai, skatoties uz komentāru pie šī paša raksta, acīmredzot ir problēmas saprast, ko tas īsti nozīmē. Tad nu mēģināšu paskaidrot sīkāk, ko nozīmē datus uztvert kā kopas un ar ko tas atšķiras no tradicionālās programmēšanas pieejas. Tā lūk ir paradigmas maiņa no viena veida datu uztveres uz citu.

Tradicionālā programmēšanas pieeja

Tradicionālajā programmēšanā darbība vienlaicīgi notiek ar vienu ierakstu. Tas var būt vienkāršs ar vienu vienkāršu lauku, piemēram, skaitlis 17, tas var būt sarežģītāks, piemēram, adreses objekts, kurš sastāv no 10 sīkākiem laukiem, bet objekts parasti ir viens. Un tas viens arī tiek vienlaicīgi apstrādāts. Dabiski, ka programmētājam, sākot darboties ar datubāzēm, šāda pieeja tiek pārnesta arī tur. Programmētājs, rakstot pieprasījumus datubāzei (gan datu atlases, gan mainīšanas), vienlaicīgi “redz” tikai vienu ierakstu. Tas var būt sarežģītāks, mazāk sarežģīts, bet tikai vienu. Šāda pieeja nerada nekādas vai rada relatīvi mazas problēmas tradicionālu ievades/rediģēšanas formu gadījumā, jo tajās lietotāji arī parasti strādā ar vienu vai dažiem ierakstiem un parasta programmētāja pieeja “redzot” tikai vienu ierakstu neko daudz neskādē, vai pat bieži nekāda cita pieeja vispār nav izmantojama. Taču problēmas rodas lielāku datu kopu apstrādē. Un tad ir jāveic izmaiņas domāšanā un jāpāriet uz..

Datu kopu pieeja

Šī pieeja ir svarīga un vislielākos ieguvumus dod, ja tiek apstrādāts relatīvi liels ierakstu skaits. Daži piemēri:

• Atskaišu izveide;
• Vienreizēja datu migrācija no vecās sistēmas uz jauno;
• Regulāra datu pārnešana/sinhronizācija no vienas sistēmas uz otru;
• Regulāra specifiska lielu apjoma datu apstrādes (dienas rezultātu apstrāde, noteiktā laika periodā ievadīto datu kvalitātes pārbaude) utt.

Izmantojot tradicionālo viena ieraksta pieeju, rezultāta ieguve ir aptuveni šāda:

Ciklā pa nepieciešamajiem ierakstiem atskaitei vai apstrādei
  Veicam katram ierakstam nepieciešamās darbības
    (kolonu aprēķini, kvalitātes pārbaudes utml)
  Papildinam gala summu vai saglabājam rezultātu datubāzē

Ko tas nozīmē no ātrdarbības viedokļa? Rezultāta ieguve ir tieši proporcionāla apstrādājamo datu apjomam. Ja katra ieraksta apstrāde mums prasa nieka 0,1 sekundi, tad pie ierakstu skaita 1 miljons (kas nav nekas īpašs) rezultāta ieguve prasīs 1 000 000 * 0,1 sekundes ≈ 1667 minūtes ≈ 28 stundas. Tātad, ja reizi diennaktī Jūs saņemat šādu datu apjomu, tad diemžēl ir liela problēma, jo datu apstrāde aizņem vairāk nekā diennakti. Pat, ja šāds datu apjoms ir reizi nedēļā, patērētais laiks nav īpaši iepriecinošs. Un ko darīt, ja datu apjoms var tikai pieaugt? Tādā gadījumā ir jāveic principiālas izmaiņas un jāpāriet no domas ierakstu pa ierakstiem uz domu par visiem ierakstiem reizē, un tātad:

• Kā visiem ierakstiem reizē iegūt atskaites kolonu vai vēl labāk vairākas, vai vislabāk visas kolonas?
• Kā veikt noteiktu kvalitātes pārbaudi nevis vienam ierakstam, bet kā to paveikt visiem ierakstiem reizē? Vai sliktākajā gadījumā ierakstu daļai?
• Kā ierakstīt tabulā nevis viena ieraksta datus, bet kā ierakstīt visus uzreiz.

Tātad domāt kopās nozīmē nevis

• paņemt kārtējo ierakstu un izpildīt tam 17 pārbaudes un tad to izmētāt pa 10 tabulām,

bet

• visiem ierakstiem reizē izpildīt pārbaudi 1, 2, … , 17 un tad visus ierakstus reizē ielikt tabulā 1, 2, …, 10.

Tātad domāt kopās nozīmē nevis

• paņemt kārtējo ierakstu un izrēķināt tam visas atskaites kolonas, pieskaitīt tās starprezultātam un beigās izdot gala rezultātu,

bet

• izrēķināt kolonu A visiem ierakstiem, izrēķināt kolonu B visiem ierakstiem, optimālā gadījumā šos rēķinus apvienojot vienā vaicājumā.

Protams, nevajadzētu šo pasākumu kaut kādā veidā nomaskēt, piemēram, ar lietotāja definētu funkciju, kas tiek izsaukta katram pārbaudāmajam ierakstam un kurā, savukārt, atkal iekšā ir ntie vaicājumi. Šādā veidā ieguvums vai nu nebūs nekāds, vai relatīvi niecīgs.

Iespējams arī, ka Jūs nevarat VISUS ierakstus apstrādāt vienlaicīgi, t.i., atkarībā no ieraksta veida un datiem veicamās darbības ir ļoti atšķirīgas. Tādā gadījumā Jūs noteikti varat ierakstus sadalīt loģiskās daļās, kur visiem vienas daļas ierakstiem veicamā darbība ir vienāda.

Kāds ir ieguvums?

Galvenais ieguvums ir tāds, ka izveidotais process vairs nav tieši proporcionāli atkarīgs no ierakstu skaita. Kāpēc? Tam ir vairāki iemesli:

• Protams, ka palielinoties ierakstu skaitam, izveidotajiem SQL teikumiem būs jāapstrādā lielāks datu apjoms, taču parasti šis process nav tieši proporcionāls datu apjomam, tas ir – ir iespēja datus apstrādāt ātrāk nekā tieši proporcionāli.
• Nav nepieciešams atkal un atkal lasīt vienus un tos pašus datus (klasifikatorus vai citus references datus), kas neglābjami būs, ja notiks apstrāde ierakstu pa ierakstam.
• Nav nepieciešams atkal un atkal izpildīt vienus un tos pašus mazos SQL teikumiņus, kas katrs prasa maz laika, bet kopsummā tomēr laiks salasās.
• Nav nepieciešams mētāties no procedurālās programmēšanas vides uz SQL vidi. Oraclē tas ir PL/SQL un SQL, citur tas var būt kaut kas cits, bet ideja nemainās un laiks tiek patērēts.

Laika izteiksmē ieguvums, protams, ir atkarīgs no datu daudzuma, izejas stāvokļa un gala stāvokļa, cik viens un otrs ir bijis optimāls. Bet ir redzēti gadījumi, gan kad ieguvums ir bezgalīgs, jo nevienam nebija pacietības sagaidīt rezultātu no ierakstu pa ierakstam pieejas , un arī tādas reizes, kad ieguvums ir bijis vismaz par kārtu.

Tālākā lasāmviela

• 7 lietas, ko nevajag darīt;
• Thinking Set-Based …. or not? - raksts par to, ka problēmas ir jāmēģina saskaldīt un atrisināt soli pa solim.

Tuvojoties nākošajām pašvaldību un eiroparlamenta vēlēšanām dzīve Latvijas vēlētājiem – interneta lietotājiem – ir kļuvusi mazliet vieglāka. Ja esat apzinīgs Latvijas pilsonis (vai ES valsts pilsonis) un neesat saņēmis vēstuli ar informāciju, kurā vēlēšanu iecirknī esat reģistrēts, vai arī veiksmīgi esat to pakāsis, un Jūs nomoka mūžīgais jautājums “KUR BALSOT?“, tad viss vēl nav zaudēts, jo savu vēlēšanu iecirkni var uzzināt ļoti vienkārši pat nemaksājot ne santīma zvanam uz CVK informatīvo tālruni. Vienkārši ir jauns e-pakalpojums “Vēlēšanu iecirkņa noskaidrošana“, kurā katram atliek ievadīt personas kodu, uzvārdu un vārdu un Jums taps skaidrs, kādā iecirknī esat vai neesat reģistrēts. Tātad informācija no valsts nozīmes datubāzes – Vēlētāju reģistra – ir kļuvusi parastiem mirstīgajiem mazliet pieejamāka.

Atgādinu arī, ka e-pakalpojumi (vai vismaz lietas, kas par tādām ir nosauktas) ir pieejami arī:

• Portālā latvija.lv - šī nu, protams, ir visslavenākā vietne no visiem e-pakalpojumu sniedzējiem Patīkami, ka pašlaik autentificēties var arī ar internetbankas kontu – tātad nav nepieciešams tikai Latvijas pasta e-paraksts.
• Rīgas pašvaldības portālā - piemēram, kura vieta kurā bērnudārzā ir Jūsu sīkajam, kam autorizācija nav nepieciešama un visādas citādas lietas ar nepieciešamu autentifikāciju. Arī šeit var izmantot internetbankas kontus.
• CSDD – uzzini savus soda punktus, mašīnas, kas Jums pieder, dabūt vienas dienas atļauju utml. Pietiek ar to, ka Jums ir e-pasts un vadītāja apliecība.

Protams, ir vēl milzums vietnes, kurās šis tas ir elektroniski pieejams, taču tajās dotā informācija ir saistoša mazākam cilvēku skaitam.

Latvijas Oracle lietotāju grupas (LVOUG) pirmā konference/seminārs ir veiksmīgi beidzies – paldies tā organizētājiem! Nezinu īsti, cik oficiāli bija cilvēku pieteikušies, bet es teiktu, ka kāds simtiņš kopā sanāca. Pasākums bija atšķirīgs no oficiālājām Oracle dienām ar to, ka nebija nevienas prezentācijas (vismaz no tām, ko apmeklēju es), kurā nodarbotos ar mārketingu Visas prezentācijas bija tehniski orientētas un bez oficiālajiem reklāmas rullīšiem.

Arī es stāstīju prezentāciju par SQL teikuma izpildes plānu - kā to iegūt, kā attēlot, kā saprast un kā uzlabot. Centos pastāstīt arī par dažām visbiežāk izpildāmajām operācijām un jo sevišķi sīkāk par fiziskajiem savienojumu izpildes veidiem (nested loops, hash join, sort merge join).

Tiem, kam ir dziļāka interese par SQL teikuma izpildes plānu un kam nepaveicās nokļūt uz neseno Tanela Podera semināru, es gribētu speciāli uzsvērt šo viņa emuāra rakstu, kurā ir saite uz failu “Oracle SQL Plan Execution: How It Really Works”. Tā prezentācija ir ļoti interesanta pat tad, ja klātienē nedzirdējāt sīkāku stāstu.

Un visbeidzot šeit ir arī saite uz manis lasīto prezentāciju par to kā saprast SQL teikuma izpildes plānu.

… par datubāzēm, protams, ko gan citu?

Apaļš gads ir pagājis kopš iepriekšējā apkopojuma ar saitēm uz citiem blogu rakstiem par datubāzēm. Šai laikā ir uzradušies 2 jauni emuāri, kas ir uzrakstījuši vairāk nekā vienu ierakstu, kuri likās pietiekami interesanti. Saskaņā ar kaktuzs iedalījumu (kurš man ļoti iepatikās ) šiem rakstītājiem ir bijušas idejas un pacietība veselam mēnesim (vismaz konkrētajā jomā), jācer, ka būs arī turpinājums. Divi augšminētie ir alx un iinuu. Bet tagad viss uzskaitījums (vēlos arī piezīmēt, ka ne viss ir ļoti labā kvalitātē un ne visam es piekrītu):

MySQL

• Kārtošana un NULL vērtības;
• Rekursīva lapas karte;
• Ierakstu dalīšana pa lappusēm;
• Web izstrāde – slodzes un optimizācijas;
• Mysql > gettext;
• Performances meklējumos;
• Nākamā id vērtība (next_id, auto_increment);
• Lietotāja definētie mainīgie sql vaicājumā;
• Null, 0, vai -1 kā noklusētā vērtība?
• Kā optimizēt MySQL kverijus ar datuma intervālu.

SQL Server

• LINQ to SQL pret LINQ to Entities;
• MS SQL TOP.
   

Vispārīgi

• Drošības pamati web lapās;
• Datubāzes struktūras: mantošana, klasifikācija, arks;
• Datubāzes normālformas vai kā projektēt pareizi.

Sērfojot pa internetu uzdūros vietnei esaite.lv, kurā ir atrodami dažādi digitālie mācību materiāli latviski, tai skaitā arī par datu bāzēm uz Windows un Linux operētājsistēmām. Tā kā mani interesē viss, kas vairāk vai mazāk ir saistīts ar datubāzēm (jo sevišķi latviski), tad sāku pētīt, ko tad mūsu cienījamie universitātes mācību spēki ir radījuši.

Pirmais iespaids bija visnotaļ dīvains, jo bija acīmredzami, ka es visdrīzāk Eiropas datorprasmes sertifikātu neiegūtu; attiecīgi saskaņā ar formulējumu dokumentā man nebūtu “zināšanas par datu bāzes pamatjēdzieniem, un es nevarētu parādīt, ka protu strādāt ar datu bāzi datorā.”

OK tātad kas šai 2 dokumentos par datu bāzēm:

• datu bāzes Windows vidē (Microsoft Access iesācēja rokasgrāmata latviski) un
• datu bāzes Linux vidē (OpenOffice.org Base iesācēja rokasgrāmata latviski)

ir atrodams?

1. Tās ir ļoti specifiskas konkrētajai programmatūrai (attiecīgi Access un OO Base) lielu un pamatīgu uzsvaru liekot uz tādām svarīgām lietām, kā konkrētas ikonas izskatu un kur izvēlnēs ir atrodama konkrēta darbība.
2. Tās ir pamatīgi ilustrētas ar ekrānšāviņiem un pilnīgam iesācējam ļauj soli pa solim paveikt nepieciešamās darbības.
3. Pretendējot uz vispārīgu ieskatu par datubāzēm kā tādām, dokumenti satur faktuālas kļūdas, piemēram, apgalvojumu, ka indekss esot datu lauka atribūts vai “tikai tad, ja ir izveidotas tabulu saistības (ar to domājot ārējās atslēgas), ir iespējams veikt darbības ar informāciju, kas atrodas dažādās tabulās un ir loģiski saistīta”.
4. Tajos ne ar vārdu nav pieminēts SQL.
5. Sīkums, protams, bet visnotaļ komiski izskatās projekta nosaukums dokumenta virsrakstā “IKT ZINĀŠANU STANDARTIZĀCIJA ZEMGALES REĢIONĀ”, kas vedina uz domām, ka datu bāzes Latgalē ir atšķirīgas un Kurzemē noteikti būs ar Ventiņu “tā viš i” īpatnībām

Tomēr lasītājam, kas vēlas apgūt tieši Microsoft Access vai OpenOffice.org Base, kā pirmais iepazīšanās solis šie dokumenti varētu būt interesanti un noderīgi. Pie tam šai vietnē ir vēl citi mācību materiāli, kas domāti pilnīgiem iesācējiem datorlietās, un man jau ir padomā daži radinieki, kam šo lapu parādīt

Kas ir indekss?

Indeksi popularitātes ziņā droši vien ir nākošie objekti datubāzēm pēc tabulām. Tos bieži izmanto vietā un iespējams gandrīz tikpat bieži patiesībā lieto nevajadzīgi. Bet tātad vispirms būtu jāsaprot, kas tad tie ir un kāda aptuveni ir to uzbūve.

Parasti runājot par indeksiem vispirms tos saprot kā kokveidīgu struktūru, kuras pirmais un galvenais uzdevums ir ātri atrast datus tabulā, kuras dati, ja vien tā nav ļoti speciāla veida tabula, ir nesakārtoti. Nākošajā attēlā ir parādīta konceptuāla indeksa struktūra. Protams, ka reālajās implementācijās katrā DBVS tas ir mazliet atšķirīgi, bet ideja paliek viena un tā pati – koks, pa kuru ātri nonāk līdz nepieciešamajai vērtībai un tad taisnā ceļā izmantojot norādes dodas uz tabulu, no kuras var nolasīt konkrēto ierakstu. Nevajadzētu, protams, arī uztvert datu bloku skaitīšanu kā precīzu algoritmu, kas pie šīm vērtībām tā arī notiek, bet drīzāk kā konceptuālu ideju.

Indekss un tabula

Tātad, ja mēs meklējam vērtību “Kuldīga” (nosacījums WHERE pilsetas_nosaukums = ‘Kuldīga’) tabulā, tad mums ir divas iespējas:

• skanējam cauri visu tabulu (full scan), kurā dati ir nesakārtoti, un atrodam attiecīgo ierakstu. Šai piemērā tas nosacīti prasītu 6 tabulas bloku lasījumus.
• atrodam precīzu vērtību indeksā, kurā vērtības ir sakārtotas. Tur meklēšanas ceļš (attēlā augstāk iezīmēts ar raustītu līniju) ir šāds – iekavās attēlots nolasīto bloku skaits kopumā:
  • “Kuldīga” < “O”, kas ir indeksa saknes  blokā (root block), tātad jāiet pa kreisi. (1)
  • “Kuldīga” > “K”, kas ir zarā pa kreisi (branch block), tātad jaiet pa labi. (2)
  • Nākošā pa labi ir lapa (leaf block), kura satur vērtību “Kuldīga” un precīzu norādi uz tabulas ierakstu. (3)
  • Nolasam tabulas bloku ar vērtību “Kuldīga”. Esam kopumā nolasījuši 4 datu blokus, kas ir mazāk nekā lasot visus tabulas datus. (4)

Apskatīsim otru piemēru – gribam atrast visas pilsētas, kuru nosaukumi sākas ar R (nosacījums WHERE pilsetas_nosaukums LIKE ‘R%’). Vizuāli meklēšanas ceļš ir šāds.

Vairāku vērtību nolasīšana no indeksa

• Pilnas tabulas skans ir tāds pats kā iepriekš, tajā nekas nemainās.
• Savukārt meklēšana pēc indeksa (attēlā ar raustītām līnijām) būs šāda:
  • “R” > “O”, tātad jāiet pa labi. (1)
  • “R” < “T”, tātad jāiet pa kreisi. (2)
  • Indeksa lapā atrodam vērtību “Rēzekne”, kas atbilst nosacījumam. (3)
  • Pēc indeksa norādes precīzi atrodam ierakstu tabulā un nolasam šo bloku. (4)
  • Indeksa lapā atrodam vērtību “Rīga”, kas atbilst nosacījumam. (4)
  • Pēc indeksa norādes precīzi atrodam ierakstu tabulā un nolasam šo bloku. (5) Tātad kopsummā esam apmeklējuši 5 datu blokus, kas ir mazāk nekā 6 ko prasītu pilna tabulas skanēšana.

Pilnam komplektam arī trešais piemērs – gribam atrast pilsētas, kuru nosaukumi ir lielāki nekā “R” bet mazāki nekā “U” (nosacījums WHERE pilsetas_nosaukums BETWEEN ‘R’ AND ‘U’). Vizuāli tas izskatās šādi:

Vairāku vērtību nolasīšana no indeksa (arī vairākām indeksa lapām)

• Pilnas tabulas skans ir tāds pats kā iepriekš, tajā nekas nemainās.
• Savukārt meklēšana pēc indeksa (attēlā ar raustītām līnijām, pievērsiet uzmanību raustītajai līnijai starp lapām) būs šāda:
  • “R” > “O”, tātad jāiet pa labi. (1)
  • “R” < “T”, tātad jāiet pa kreisi. (2)
  • Indeksa lapā atrodam vērtību “Rēzekne”, kas atbilst nosacījumam. (3)
  • Pēc indeksa norādes precīzi atrodam ierakstu tabulā un nolasam šo bloku. (4)
  • Indeksa lapā atrodam vērtību “Rīga”, kas atbilst nosacījumam. (4)
  • Pēc indeksa norādes precīzi atrodam ierakstu tabulā un nolasam šo bloku. (5)
  • Šai indeksa lapā vairāk vērtību nav tāpēc jāiet uz nākošo lapu pa labi. Indeksa lapā atrodam vērtību “Talsi”, kas atbilst nosacījumam. (6)
  • Pēc indeksa norādes precīzi atrodam ierakstu tabulā un nolasam šo bloku. (7) Vairāk vērtību atbilstoši nosacījumiem nav. Tātad kopsummā esam apmeklējuši 7 datu blokus, kas ir vairāk nekā 6, ko prasītu pilna tabulas skanēšana, tātad šai gadījumā tabulas pilna skanēšana būtu lētāka nekā lasīšana indekss-tabula.

Indeksa izveides sintakse

CREATE [UNIQUE] INDEX <indeksa vārds>
ON <tabulas vārds> (<kolona1>[, <kolona2>[, ..., <kolonaN>]]); 

• Indeksam ir jāpiešķir <indeksa vārds>. Atkarībā no DBVS tam jābūt unikālam tabulas ietvaros (MySQLā piemēram), vai shēmas ietvaros (Oraclē).
• ON klauzā tiek norādīts kādai tabulai indekss tiek veidots.
• Iekavās var rakstīt vienu vai vairākas kolonas uz kurām indeksu veidot. Vairāku kolonu gadījumā tas būs kompozītais (composite) indekss.

Savukārt, lai tiktu vaļā no indeksa ir jaizmanto variācija par

DROP INDEX <indeksa vārds>

MySQLā tai vēl ON klauzā jānorāda tabulas vārds, kas gluži loģiski jo vienā datubāzē var būt vairāki indeksi ar vienādu vārdu, tāpēc jāprecizē tabula.

Indeksu piemēri un operācijas – indeksu spožums

Piemēriem izmantosim zemāk redzamo tabulu un datus, kā arī indeksu uz pilsētas nosaukuma. Tā kā Latvijā pilsētu nosaukumi ir unikāli, tad varam veidot unikālo indeksu. Iedzīvotāju skaits ņemts no Lielā pasaules atlanta.

CREATE TABLE pilsetas (
  id INTEGER PRIMARY KEY,
  pilsetas_nosaukums varchar(40),
  iedz_skaits INTEGER);
INSERT INTO pilsetas VALUES (1, 'Rīga', 719600);
INSERT INTO pilsetas VALUES (2, 'Kuldīga', 13000);
-- šī komanda ir specifiska Oracle un tās mērķis ir nodrošināt,
-- ka vienā datu blokā ir ne vairāk kā 2 ieraksti
-- (balstoties uz 2 jau ieliktajiem)
ALTER TABLE pilsetas MINIMIZE records_per_block;
INSERT INTO pilsetas VALUES (3, 'Talsi', 11400);
INSERT INTO pilsetas VALUES (4, 'Ventspils', 43400);
INSERT INTO pilsetas VALUES (5, 'Rēzekne', 35900);
INSERT INTO pilsetas VALUES (6, 'Daugavpils', 106100);
INSERT INTO pilsetas VALUES (7, 'Ogre', 26800);
INSERT INTO pilsetas VALUES (8, 'Valmiera', 27500);
INSERT INTO pilsetas VALUES (9, 'Cēsis', 18200);
INSERT INTO pilsetas VALUES (10, 'Krāslava', 10500);
INSERT INTO pilsetas VALUES (11, 'Bauska', 10200);
INSERT INTO pilsetas VALUES (12, 'Liepāja', 85300);
COMMIT;

Piemēru pielietošana Oracle DBVS

Pagaidām, kamēr mums indeksa nav, paskatamies, cik datu bloki tiek nolasīti. Šim mērķim izmantosim SQL*Plus komandu autotrace. Es atstāšu tikai tos rezultātus, kas ir svarīgi šim piemēram, patiesībā izpildes statistika tiek ģenerēta vairāk.

SQL> set autot on
SQL> SELECT * FROM pilsetas
  2  WHERE pilsetas_nosaukums = 'Kuldīga';
        ID PILSETAS_NOSAUKUMS                       IEDZ_SKAITS
---------- ---------------------------------------- -----------
         2 Kuldīga                                        13000
-------------------------------------------------------------------
| Id  | Operation         | Name     | Rows  | Bytes | Cost (%CPU)|
-------------------------------------------------------------------
|   0 | SELECT STATEMENT  |          |     1 |    48 |     3   (0)|
|*  1 |  TABLE ACCESS FULL| PILSETAS |     1 |    48 |     3   (0)|
-------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("PILSETAS_NOSAUKUMS"='Kuldīga')
Statistics
----------------------------------------------------------
          16 consistent gets
          1  rows processed

Tagad izveidojam indeksu un pievēršama uzmanību izpildes plāna izmaiņām un datu bloku nolasījumiem (consistent gets).

SQL> CREATE UNIQUE INDEX pils_nos_idx
  2  ON pilsetas (pilsetas_nosaukums);
SQL> SELECT * FROM pilsetas
  2  WHERE pilsetas_nosaukums = 'Kuldīga';
        ID PILSETAS_NOSAUKUMS                       IEDZ_SKAITS
---------- ---------------------------------------- -----------
         2 Kuldīga                                        13000
--------------------------------------------------------------------
|Id|Operation                   |Name        |Rows|Bytes|Cost(%CPU)|
--------------------------------------------------------------------
| 0|SELECT STATEMENT            |            |  1 |   48|    1  (0)|
| 1| TABLE ACCESS BY INDEX ROWID|PILSETAS    |  1 |   48|    1  (0)|
|*2|  INDEX UNIQUE SCAN         |PILS_NOS_IDX|  1 |     |    0  (0)|
--------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("PILSETAS_NOSAUKUMS"='Kuldīga')
Statistics
----------------------------------------------------------
          2  consistent gets
          1  rows processed

Tagad skatamies, kas notiek, ja atlasam vērtības no otrā piemēra.

SQL> SELECT * FROM pilsetas
  2  WHERE pilsetas_nosaukums like 'R%';
        ID PILSETAS_NOSAUKUMS                       IEDZ_SKAITS
---------- ---------------------------------------- -----------
         5 Rēzekne                                        35900
         1 Rīga                                          719600
---------------------------------------------------------------------
|Id|Operation                   |Name        |Rows |Bytes|Cost(%CPU)|
---------------------------------------------------------------------
| 0|SELECT STATEMENT            |            |    2|   96|    3  (0)|
| 1| TABLE ACCESS BY INDEX ROWID|PILSETAS    |    2|   96|    3  (0)|
|*2|  INDEX RANGE SCAN          |PILS_NOS_IDX|    2|     |    1  (0)|
---------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("PILSETAS_NOSAUKUMS" LIKE 'R%')
       filter("PILSETAS_NOSAUKUMS" LIKE 'R%')
Statistics
----------------------------------------------------------
          4  consistent gets
          2  rows processed

Pēdējo gadījumu nesākšu drukāt šeit, jo tas 99% lasītāju būs apnicīgi, vienkārši vienā tabuliņā apkopošu rezultātus.

Tātad kāda morale? Bez indeksa izmantošanas mēs dabūjam 16 datu bloku lasījumus jebkurā gadījumā, pat atlasot vienu ierakstu. Savukārt, ja mums ir unikālais indekss, tad ir divas pamatoperācijas:

• INDEX UNIQUE SCAN – tiek izmantota tad, ja DBVS zin, ka tiks atlasīts ne vairāk kā 1 ieraksts. Var protams, atlasīt arī o.  Vispārīgā gadījumā ļoti grūti izdomāt kādu efektīvāku operāciju.
• INDEX RANGE SCAN – tiek izmantota tad, ja izmantojot indeksu ir jānolasa vairākas vērtības pēc kārtas. Šai gadījumā, ja skanēšana ir relatīvi īsa, tad tas var būt efektīvāk nekā pilns tabulas skans, savukārt, ja indeksa skanēšana ir gara, tad tā var būt arī neefektīvāka nekā pilna tabulas skanēšana.

Piemēru pielietošana MySQL DBVS

Paskatamies kā šie paši plāni izskatīsies MySQLā. Pirmajā gadījumā, kad indeksa vēl nav:

mysql> explain SELECT * FROM pilsetas
    -> WHERE pilsetas_nosaukums = 'Kuldiga';
+--+-----------+---------+----+-------------+----+----+----+
|id|select_type|table    |type|possible_keys|key |ref |rows|
+--+-----------+---------+----+-------------+----+----+----+
| 1|SIMPLE     |pilsetas |ALL |NULL         |NULL|NULL|12  |
+--+-----------+---------+----+-------------+----+----+----+
+-----------+
|Extra      |
+-----------+
|Using where|
+-----------+

Kā redzams tajā bija type = ALL, kas viena ieraksta atlasei par neko labu neliecina. Extra kolona arī liecina par to, ka tiek lietots papildus filtrs.

Savukārt, unikālais indeksa skans izskatās šādi. Pievērsiet uzmanību type kolonai un to, ka mums parādās key (indekss), kas tiek izmantots.

mysql> explain SELECT * FROM pilsetas
    -> WHERE pilsetas_nosaukums = 'Kuldīga';
+--+-----------+--------+-----+-------------+------------+-----+----+
|id|select_type|table   |type |possible_keys|key         |ref  |rows|
+--+-----------+--------+-----+-------------+------------+-----+----+
| 1|SIMPLE     |pilsetas|const|pils_nos_idx |pils_nos_idx|const|   1|
+--+-----------+--------+-----+-------------+------------+-----+----+

Savukārt vairāku vērtību nolasīšana no indeksa izskatās šādi. Kā redzams šeit type=range un key palicis tas pats, kā arī parādījusies garum gara Extra kolona, kur parādās vēl divas papildus optimizācijas. Par katru no tām var lasīt MySQL dokumentācijā.

mysql> explain SELECT * FROM pilsetas
    -> WHERE pilsetas_nosaukums like 'R%';
+--+-----------+--------+-----+-------------+------------+----+----+
|id|select_type|table   |type |possible_keys|key         |ref |rows|
+--+-----------+--------+-----+-------------+------------+----+----+
| 1|SIMPLE     |pilsetas|range|pils_nos_idx |pils_nos_idx|NULL|   2|
+--+-----------+--------+-----+-------------+------------+----+----+
+-------------------------------+
|Extra                          |
+-------------------------------+
|Using index condition;Using MRR|
+-------------------------------+

MySQLā diemžēl man neizdodas dabūt nolasītos blokus, jo vienīgais man zināmais rīks MySQL profiler, par ko rakstīju iepriekšējā rakstā, kas to varētu darīt, Windows OSā to nerāda. Taču lielākiem vaicājumiem, kur patiešām ir būtiska atšķirība, Jūs noteikti varat izmantot šo rīku mērījumiem.

Ļoti bieži indeksi tiek uzskatīti par panaceju ar ko atrisināt visas DBVS problēmas - pieliksim kādu klāt un viss būs kārtībā.

Indeksu posts

Diemžēl, kā katrai lietai, arī indeksiem ir savas ēnas puses. Pati pirmā un galvenā ēna ir indekss varbūt var uzlabot SELECT vaicājumu ātrdarbību, bet tas noteikti palēninās INSERT, UPDATE, DELETE un MERGE ātrdarbību. Parastā tradicionālā kaudzes (heap) tabulā ir vienalga, kur ieraksts nonāk. Indeksā katrai vērtībai ir sava precīza vieta, tāpēc pirmkārt tā ir jāieliek divās vietās, otrkārt var gadīties, ka to vajadzīgajā vietā nevar ielikt, jo tur trūkst vietas un ir jāveic papildus darbības (tātad papildus diska noslodze), lai to varētu izdarīt. Jo vairāk indeksu tabulā būs, jo dārgāk izmaksās to uzturēšana. Tādējādi var pienākt brīdis, kad potenciālais ieguvums SELECT vaicājumos ir mazāks nekā zaudējusm pārējos datu manipulēšanas vaicājumos.

Tātad liekam jaunu ierakstu klāt (INSERT), mainam viena ieraksta visas kolonas ieskaitot primāro atslēgu (UPDATE) un dzēšam vienu ierakstu (DELETE) un skatamies, kā mainās raksturīgās statistikas. Lai būtu skaidrāk redzama atšķirība, apkopošu rezultātus tabuliņā.

Tātad daži secinājumi skatoties uz šiem skaitļiem:

• Priekš INSERT katra indeksa pielikšana prasa aizvien vairāk lasīt/rakstīt datu blokus (db block gets + consistent gets), 3 indeksu gadījumā tas jau ir vairāk kā 2reiz vairāk nekā bez indeksiem.
• Priekš UPDATE un DELETE neviens indekss (jo es dzēsu pēc id lauka) nozīmē tabulas pilnu skanēšanu tāpēc bez neviena indeksa tas prasa vairāk datu bloku lasīšanas.
• UPDATE un DELETE pieliekot primāro indeksu ir būtisks lasīšanas samazinājums (consistent gets) , tai pašā laikā rakstīšana (db block gets) aug. Kā redzams UPDATE tas aug sevišķi strauji, jo indeksā vērtības ir nepieciešams dzēst un pēc tam likt atkal klāt.
• Ar katru jaunu indeksu aug redo size – rakstījumi, kas nodrošina atrites (rollback) operāciju. Tas sevišķi uzskatāmi ir UPDATE, jo šeit arī indeksu blokiem ir jānodrošina šīs izmaiņas.
• No šīm papildus IO operācijām nav iespējams nekādā citā veidā izbēgt, kā vien, vai nu neveidojot indeksus, vai nerakstot datus tabulā. Tātad galvenais uzdevums ir indeksu skaitu minimizēt un veidot tikai tos, kas patiešām ir nepieciešami. 

Kopsavilkums

• Indeksi var ļoti būtiski iespaidot ātrdarbību. Diemžēl abos virzienos – gan sliktā, gan labā nozīmē.
• Indeksi ir kā zāles, ko nevajag pārdozēt. Pārdozēšana var radīt reālas problēmas.
• Šei ir apskatītas tikai ļoti nedaudzas un pašas pamatlietas no indeksu iezīmēm un operācijām. Katrā DBVS vēl var būt burtiski padsmitiem citu.
• Atkārtojot savā vidē šeit minētos piemērus, Jums var nākties redzēt citus skaitļus, bet tendencēm gan būtu jābūt tādām kā šeit minēts.

Tālākā lasāmviela

• Pārskats par indeksiem Oracle dokumentācijā;
• Richard Foote blogs (Oracle) – emuārs, kurā indeksi tiek secēti un iztirzāti visos sīkumos;
• Julian Dyke prezentācijas (Oracle) – šai gadījumā interesantas varētu būt Index Internals un Bitmap Index Internals;
• Kā MySQL lieto indeksus – no MySQL dokumentācijas;
• Ieskats SQL Server indeksos.

Jauns gads ar jauniem vietējiem pasākumiem ir klāt. 27. martā (šajā 2009. gadā, protams ) Latvijas Oracle lietotāju grupa rīko savu pirmo konferenci. Tā sākas pusdienlaikā 13.00 un paralēli notiks 2 sesijās. Konferencē uzstāsies vietējie LVOUG pārstāvji, kas dalīsies pieredzē par dažām Oracle 11g jaunajām iespējām ieskaitot 11g SQL plānu pārvaldību un Database replay iespēju, vairākas prezentācijas no administratoru skatupunkta, Oracle vs MySQL (kazi varētu būt interesanti ne tikai rūdītiem Oracle faniem) un Raimonda iemīļotais jājamzirdziņš Ruby on Rails. Arī es centīšos dot savu artavu šai lietā ar prezentāciju par SQL teikuma izpildes plānu (execution plan), tā iegūšanu un izpratni, mazdruscīt par biežākājām tajos sastopamajām operācijām, tai skaitā savienojumu (join) fiziskajiem izpildīšanas veidiem (nested loops, hash join, merge join) un mazliet par garajām operācijām (long operations).

Papildus pašmāju bāleliņiem (jā kur gan mums ir daiļā dzimuma pārstāves??) būs arī viesis Kuassi Mensah no Oracle, kurš uzstāsies ar divām prezentācijām.

Ja nu Tu, lasītāj, skaties un nesaproti, kāpēc Tevis nav konferences prezentētāju sarakstā, vai arī Tu varētu kaut ko interesantu citiem pastāstīt, tad seko līdzi LVOUG grupas e-pasta listei un nākošreiz piesakies! Pie tam vajadzētu atcerēties, ka ne jau tikai hiperjaunās un hipersarežģītās lietas ir vērts stāstīt, Oracle ir pietiekami liela un monstroza, lai atrastu gana interesantas tēmas arī it kā zināmākās lietās un vietās.

Vēl svarīgi zināt - dalība konferencē ir bezmaksas, bet nepieciešams reģistrēties šeit.

Un visbeidzot - konference notiks viesnīcā Monika Elizabetes ielā 21. Tā ir viesnīca uz Elizabetes un Pulkveža Brieža ielas stūra, turpat apakšā ir restorāns Vincents sevišķajiem gardēžiem

Saites

• Konferences prezentāciju grafiks;
• Reģistrēšanās konferencei;
• Konferences norises vieta.

Es ik pa laikam iedomājos vai MySQLā arī var lietot līdzīgas iespējas, kā piemēram Oracle autotrace, lai varētu mērīt izpildes laiku, paveiktos soļus un kaut kādu statistiku vaicājumiem, un lai salīdzinātu, kas tad izpildījās ātrāk un kāpēc. Tad nu izrādās, ka jau vismaz kopš 2007. gada pavasara eksistē tāda lieta, kā MySQL profiler, kas lielā mērā to nodrošina. Jau pašā sākumā jābrīdina, ka MySQL ir visai dīvaina DBVS un visai dīvainas izstrādes metodes vismaz no mana skatupunkta, jo pirmkārt MySQL Profiler nav pieejams MySQL Enterprise Server un notiek arī tāda mistiska dīvainība, ka vecākās versijās ir, bet jaunākās nē, piemēram, 5.0.37 ir, bet 6.0.4 nav (uz to arī es uzrāvos un brīnījos kā gan tas nākas), savukārt pēdējā novelkamajā 6.0.9. alpha atkal ir. Tā kā iespējams ne visiem lietotājiem būs tā iespēja šo rīku arī izmantot. Vēl tāds interesants fakts, ka šajā brīdī meklējot Googlē MySQL profiler latviskās lapās (tas ir pirms šī raksta, ko pašlaik lasat, publicēšanas) tiek atrasti 17 rezultāti, no kuriem tieši 1 ir kādā sakarā ar meklēto frāzi.

Kā jālieto?

Profiler sākšana un beigšana ir ļoti vienkārša. Lai sāktu, rakstam:

mysql> set profiling=1;
Query OK, 0 rows affected (0.00 sec)

Lai beigtu, rakstam:

mysql> set profiling=0;
Query OK, 0 rows affected (0.00 sec)

Lai noskaidrotu, kādā stāvoklī esam:

mysql> select @@profiling;
+-------------+
| @@profiling |
+-------------+
|           0 |
+-------------+
1 row in set (0.00 sec)

Ko ar to var redzēt?

Apsolījumi ir, ka ar to var redzēt daudz un dažādas lietas ieskaitot kopējo patērēto laiku, procesora laiku, lasītos un rakstītos blokus u.c. lietas. Visuzskatāmāk to var redzēt paskatoties, ko tad glabā information_schema shēmas tabula profiling, kur tiek glabāta profilēšanas informācija.

mysql> desc information_schema.profiling;
+---------------------+--------------+------+
| Field               | Type         | Null |
+---------------------+--------------+------+
| QUERY_ID            | int(20)      | NO   |
| SEQ                 | int(20)      | NO   |
| STATE               | varchar(30)  | NO   |
| DURATION            | decimal(9,6) | NO   |
| CPU_USER            | decimal(9,6) | YES  |
| CPU_SYSTEM          | decimal(9,6) | YES  |
| CONTEXT_VOLUNTARY   | int(20)      | YES  |
| CONTEXT_INVOLUNTARY | int(20)      | YES  |
| BLOCK_OPS_IN        | int(20)      | YES  |
| BLOCK_OPS_OUT       | int(20)      | YES  |
| MESSAGES_SENT       | int(20)      | YES  |
| MESSAGES_RECEIVED   | int(20)      | YES  |
| PAGE_FAULTS_MAJOR   | int(20)      | YES  |
| PAGE_FAULTS_MINOR   | int(20)      | YES  |
| SWAPS               | int(20)      | YES  |
| SOURCE_FUNCTION     | varchar(30)  | YES  |
| SOURCE_FILE         | varchar(20)  | YES  |
| SOURCE_LINE         | int(20)      | YES  |
+---------------------+--------------+------+

Diemžēl arī statistiku ziņā rīks ir nepilnīgs, jo kā rakstīts arī dokumentācijā, ne visur visu var dabūt. Un MySQL uz Windows (ko es arī testēju) noteikti nerāda visu, pareizāk izsakoties rāda statusu (nosacītu vaicājuma izpildes stāvokli), laiku, izejas failu un izejas koda rindiņu. Jāatzīst, ka iesākumam arī tas nav slikti, jo:

• laiks tiek fiksēts ar precizitāti līdz mikrosekundēm (6 zīmes aiz komata), kas ir krietni labāk nekā noklusētās centisekundes (ko rāda pēc katra izpildītā vaicājuma);
• skatoties uz stāvokļiem rodas lielāka skaidrība, kādas operācijas vaicājuma izpildes gaitā tiek veiktas, cik tās tiek veiktas un cik laiku katra prasa.

Tātad apskatīsim 2 piemērus, kas balstīti uz tabulām ierakstā par IN un EXISTS apakšvaicājumiem. Pirmais piemērs būs izmantojot IN operatoru, otrais EXISTS, bet to rezultāti ir identiski. Redzēsim, kā apskatīties profilus visus kopā un kā sīkāk katru atsevišķi.

mysql> SELECT * FROM b
    -> WHERE y1 IN (
    ->   SELECT x1
    ->   FROM a);
+------+------+------+
| y1   | y2   | y3   |
+------+------+------+
|    1 |    1 |    1 |
|    1 |    2 |    1 |
|    2 |    2 |    3 |
+------+------+------+
3 rows in set (0.00 sec)
mysql> SELECT * FROM b
    -> WHERE EXISTS (
    ->   SELECT 1
    ->   FROM a
    ->   WHERE a.x1 = b.y1);
+------+------+------+
| y1   | y2   | y3   |
+------+------+------+
|    1 |    1 |    1 |
|    1 |    2 |    1 |
|    2 |    2 |    3 |
+------+------+------+
3 rows in set (0.01 sec)

It kā otrais mums ir izpildījies ilgāk, skatamies kā tad tas ir saskaņā ar profiler datiem. Lai to darītu jāraksta SHOW PROFILES, daudzskaitlī. Man jau ir izpildītii vairāki vaicājumi, tāpēc šie ir ar lielākiem numuriem (46 un 47):

mysql> show profiles;
+----------+------------+-----------------------------------
| Query_ID | Duration   | Query
+----------+------------+-----------------------------------
|       46 | 0.00092950 | SELECT * FROM b
WHERE y1 IN (
  SELECT x1
  FROM a)                     |
|       47 | 0.00084825 | SELECT * FROM b
WHERE EXISTS (
  SELECT 1
  FROM a
  WHERE a.x1 = b.y1) |
+----------+------------+-----------------------------------

Interesanti, ka saskaņā ar profiling info, vaicājums ar EXISTS ir pat izpildījies ātrāk nekā ar IN un kas pats interesantākais neviens no tiem nav tuvu centisekundei. Jādomā, ka tas saistīts ar kaut kādām noapaļošanas kļūdām un pārāk maziem skaitļiem, lai būtu precīzi mērījumi

Tagad nāk interesantākā daļa, skatamies, kāds tad izskatās katrs atsevišķais profails. Tam izmantojam komandu SHOW PROFILE, vienskaitlī. Komandai pieliekot klāt argumentu iegūstam profailu iepriekš izpildītam vaicājumam ar numuru X.

Tātad vaicājuma ar IN operatoru profails izskatās šādi:

mysql> show profile for query 46;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000025 |
| checking query cache for query | 0.000101 |
| Opening tables                 | 0.000033 |
| System lock                    | 0.000007 |
| Table lock                     | 0.000064 |
| init                           | 0.000056 |
| optimizing                     | 0.000021 |
| statistics                     | 0.000028 |
| preparing                      | 0.000162 |
| executing                      | 0.000006 |
| Sending data                   | 0.000209 |
| end                            | 0.000006 |
| removing tmp table             | 0.000023 |
| end                            | 0.000006 |
| query end                      | 0.000005 |
| freeing items                  | 0.000146 |
| storing result in query cache  | 0.000024 |
| logging slow query             | 0.000003 |
| cleaning up                    | 0.000009 |
+--------------------------------+----------+

Tātad skatoties uz šo var izdarīt vairākus secinājumus:

• kura operācija aizņem visvairāk laiku;
• rodas priekšstats par to, ko tad serveris vaicājuma izpildes gaitā vispār dara;
• redzam, ka šis apakšvaicājums ir prasījis pagaidu tabulas izveidi (jo ir solis removing tmp table), tas būs interesanti saistībā ar otru vaicājumu.

Tagad profails ar EXISTS apakšvaicājumu:

mysql> show profile for query 47;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000025 |
| checking query cache for query | 0.000111 |
| Opening tables                 | 0.000034 |
| System lock                    | 0.000006 |
| Table lock                     | 0.000062 |
| init                           | 0.000049 |
| optimizing                     | 0.000009 |
| statistics                     | 0.000022 |
| preparing                      | 0.000016 |
| executing                      | 0.000005 |
| Sending data                   | 0.000054 |
| optimizing                     | 0.000015 |
| statistics                     | 0.000018 |
| preparing                      | 0.000013 |
| executing                      | 0.000004 |
| Sending data                   | 0.000049 |
| executing                      | 0.000004 |
| Sending data                   | 0.000024 |
| executing                      | 0.000003 |
| Sending data                   | 0.000019 |
| executing                      | 0.000004 |
| Sending data                   | 0.000022 |
| executing                      | 0.000003 |
| Sending data                   | 0.000019 |
| executing                      | 0.000003 |
| Sending data                   | 0.000072 |
| end                            | 0.000013 |
| query end                      | 0.000004 |
| freeing items                  | 0.000139 |
| storing result in query cache  | 0.000022 |
| logging slow query             | 0.000003 |
| cleaning up                    | 0.000009 |
+--------------------------------+----------+

Ko redzam šeit:

• atšķirībā no IN šeit nav pagaidu tabulas dzēšana;
• ir 2 sekvences optimizing, statistics, preparing, executing, Sending data un pēc tam 5 sekvences executing, Sending data. Tas izskatās pēc 2 vaicājumu optimizēšanas – pirmā virsvaicājumam un otrā apakšvaicājumam un pēc tam vēl 5 reizes ierakstu nolasīšanas. Ja paskatamies izpildes plānā, tad arī tā izskatās, taču, protams, neņemos teoretizēt kādā kārtībā kādi ieraksti tika tur lasīti

Tālāk paskatamies vēl dažas interesantas lietas – palaižam vaicājumu ar EXISTS vēlreiz. Tagad pēc show profiles var redzēt, ka otrajā reizē tieši tas pats vaicājums ir izpildījies ~6 reizes ātrāk nekā pirmajā un ir palikušas tikai dažas operācijas:

mysql> show profiles;
+----------+------------+-----------------------------------
| Query_ID | Duration   | Query
+----------+------------+-----------------------------------
|       49 | 0.00014200 | SELECT * FROM b
WHERE EXISTS (
  SELECT 1
  FROM a
  WHERE a.x1 = b.y1)         |
+----------+------------+--------------------
mysql> show profile for query 49;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000025 |
| checking query cache for query | 0.000009 |
| checking privileges on cached  | 0.000011 |
| sending cached result to clien | 0.000089 |
| logging slow query             | 0.000004 |
| cleaning up                    | 0.000003 |
+--------------------------------+----------+

Pēc visām šīm operācijām ir acīmredzami, ka tiek izmantots iekešotais rezultāts un kā tas iespaido gan operāciju skaitu, gan kopējo vaicājuma izpildes ātrumu.

Dažas papildus lietas, ko atcerēties

• Profilēšana strādā arī citiem sql teikumiem, ne tikai select vaicājumiem.
• Ļoti nepatīkami, ka uz Windows nerāda BLOCKS IO, jo tā noteikti varētu būt nākošā interesantākā statistika pēc izpildes laika.
• Ir tiešām vērts izpētīt izpildāmās operācijas, pie ORDER BY, piemēram, parādās Sorting result un tai atbilstošais laiks, kas ļoti uzskatāmi parāda, ko nozīmē ORDER BY pievienošana. Savukārt GROUP BY parādās gan Sorting result, gan arī pirms tam Creating tmp table, kas parāda kā MySQL veic šīs operācijas.
• Ilgi izpildošamies vaicājumiem varētu būt ļoti daudzas operācijas un tad vienkārša komanda show profile varētu dot ļoti nepārskatām rezultātu. Tad ir vērts atcerēties par information_schema.profiling tabulu, kuras rezultātus ar tiem pašiem SELECT vaicājumiem un grupēšanu pēc operācijas var padarīt krietni lasāmākus. 

Tālākā lasāmviela

• Using the New MySQL Query Profiler - apraksts par MySQL profiler ar piemēriem, kā to izmantot.
• SHOW PROFILES sintakse MySQL 5.0 dokumentācijā.