Saglabātās procedūras

SQLs, protams, ir laba, spēcīga un spējīga datu apstrādes valoda, tomēr reižu reizēm ar to nepietiek. Tiesa gan pirms ķerties pie kaut kā vairāk noteikti ir jāpārliecinās, ka ar SQL vien nepietiek, atceroties, piemēram, tādas lietas kā grupēšanas, apakšvaicājumus, savienojumus, analītiskās funkcijas, model klauzas u.c. iespējas. Sīkāk par to, kādā kārtībā vajadzētu mēģināt risināt problēmas, rakstīju pagājušoreiz.

Tomēr, ja biznesa loģika un realizējamie algoritmi ir pārāk sarežģīti, tad nākas ķerties pie kaut kā sarežģītāka un ar lielākām iespējām un tās ir iebūvētās (reizēm laikam saka arī iegultās vai barbarisms storētās, no angļu stored) procedūras un funkcijas. Lielāka daļa DBVS (tālāk būs viens un tas pats piemērs Oracle, SQL Server un MySQL), kas cenšas attīstīt un piedāvāt lielāku funkcionalitāti, ir izveidojušas vai paņēmušas jau esošu programmēšanas valodu, kurā tad šīs procedūras un funkcijas var veidot. Būtiski ir tas, ka šīs procedurālās vienības tiek glabātas datubāzē. Tā ir pirmā un pati būtiskākā atšķirība, kas tās atšķir no jebkuras citas procedūras vai funkcijas, kas izveidotas un parasti atrodas uz klienta (klienta-servera sistēmā) vai lietojumprogrammu servera (application server) trīs līmeņu sistēmā. Tas faktiski arī nosaka šo procedurālo vienību labās un sliktās īpašības salīdzinājumā ar parastām procedūrām un funkcijām.

Procedūru un funkciju lietošanas mehānisms ir šāds:

1. Vispirms procedūra vai funkcija tiek izveidota, saglabāta un nokompilēta datubāzē. To dara līdzīgi kā ar jebkuru citu datubāzes objektu, izmantojot CREATE PROCEDURE vai CREATE FUNCTION SQL DDL teikumu. Šai brīdī procedūra vai funkcija tiek tikai izveidota, tā vēl netiek pildīta. Šai brīdī parasti DBVS veic arī zināmas pārbaudes, vai procedūra/funkcija ir korekta sintaktiski, vai ir pieejami tajā minētie objekti u.c.
2. Pēc tam, kad procedūra vai funkcija ir veiksmīgi izveidota un bez kļūdām nokompilēta, to var izpildīt (execute). Katrā DBVS to dara mazliet atsķirīgi, bet šis ir tas brīdis, kad visa procedūrā vai funkcijā iekodētā loģika tiešām tiek izpildīta un iegūts (cerams vēlamais 😉 ) rezultāts.

Tālāk neliels iebūvētās procedūras piemērs visās trīs tradicionāli manis aprunātajās DBVS.

Ironija augstākajā pakāpē

Vakar biju uz Microsoft organizētu semināru, ko vadīja Kevin Ashby, Microsoft Microsoft Enterprise Technical Strategist EMEA. Pirmā semināra daļa bija orientēta uz to, kāpēc būtu jāizvēlas Microsoft Information Platforma, kas patiesībā reducējās uz stāstu par to, kāpēc SQL Serveris un Microsoft kā tāds ir labāks nekā Oracle. Cik nācies būt uz pēdējiem Microsoft semināriem par SQL Serveri, šī nepārtrauktā salīdzināšana un ciparu grozīšana jau sāk šķist mazliet paranoidāla, es šādos semināros labāk klausītos nevis nepārtrauktus salīdzinājumus un citu mārketinga stuffu, bet tiešām stāstus par to kā SQL Serverī kaut ko var tehniski izdarīt, piemēram, par to kā detaļās notiek vaicājumu izpilde, procesu, atmiņas u.c. resursu pārvaldība un tamlīdzīgas tehniskas lietas. Šai ziņā perfekts bija seminārs ko rīkoja .NET lietotāju grupa un kurā uzstājās Maciej Pilecki, kurš stāstīja par SQL Servera atmiņas pārvaldību. Arī viņš dažas reizes pieminēja Oracli, bet tas bija salīdzinot tehniskas lietas, nevis nepārtraukti masējot ar statistiskiem skaitļiem, kurus katra puse groza atbilstoši nepieciešamībai un kurus jau es katras puses izpildījumā esmu n reizes redzējis.

Lai cilvēkiem rastos priekšstats, kāpēc tāds iespringums, tad šeit ir pieejama līdzīga Kevin Ashby prezentācija par to kā un kāpēc migrēt uz SQL Serveri – pirmie pārdesmit slaidi bija apmēram tādi paši, tikai citā noformējumā, kārtībā un detalizācijas pakāpē. Starp citu uzdodot privātu jautājumu semināra autoram, radās skaidrība, ka viņš ir gana kompetents un zinošs arī tehniskās detaļās nevis tikai mārketinga frāzēs, jo paguva man pierādīt, kāpēc SQL Servera Mirroring ir labāks augstas pieejamības (High availability) risinājums salīdzinot ar Oracle RAC, jo tur esot īsāks vidējais laiks starp atteicēm(Mean time between failures). Abstrahējoties no tā vai tā tas ir, vai nav, nebija īsti skaidrs kāpēc šādas detaļas krietni lielākā daudzumā nevarēja būt arī publiskajā daļā.

OK beidzu savu gaušanos un tagad, protams, jautājums – kur tad solītā ironija augstākajā pakāpē?

Ironijā augstākajā pakāpē ir iekš tam, ka es vakar pusdienu klausījos cik SQL Serveris ir Highly available un Reliable, bet šorīt ierodoties darbā un skatoties uz SQL Serveri, kurā man daudzas stundas griezās daudzas fona  sesijas ar masīviem vaicājumiem un datu izmaiņām un es mērīju ātrdarbību dažiem testa scenārijiem, es redzu kļūdas paziņojumu “SQL Server detected a logical consistency-based I/O error: (bad checksum).[..]” un šādu attēlu:

Pēc restarta un recovery viss atkal darbojas un problēma izskatās pēc kaut kā līdzīga šim, bet nu tā kā tā ir izstrāde un veiktspējas testi, tad īpaša saspringuma nav, tā teikt, kam negadās… Bet smieklīgi bija vienalga.

DBVS tirgus daļas

Laiku pa laikam uzpeld tāds jautājums kā – kura ir vispopulārākā datubāze (DBVS)? Diemžēl šis jautājums ir visnotaļ neatbildēts. Es esmu redzējis ntos rakstus, kuros uz DBVS X atsaucas kā uz vienu no populārākajām vai pašu populārāko, taču pamatojums tam laikam ir tik pašsaprotams, ka vienmēr izpaliek 🙂 Apmēram pirms gada es veicu aptauju arī šai vietnē, kuras rezultāti vismaz ir kvantitatīvi izmērāmi un redzami šeit. Protams, tai ir savs trūkums, jo reāli tā ir DBVS popularitāte šīs vietnes lasītāju vidū nevis Latvijā. Tas pats trūkums būs arī visām citām interentā veiktajām aptaujām.

Bet tagad atgriežamies pie virsraksta – tirgus daļas (market share). Tas arī ir veids kā mērīt (un definēt) popularitāti. Tad nu lūk man nesen radās nepieciešamība to atrast un kā parasti – izrādās Google ir spēks! Tirgus pētījumu kompānija IDC katru gadu veic pētījumu par datubāzu daļu globālajā tirgū. Ļoti interesanti ir tas, ka pašā IDC lapā šie pētījumi maksā bargu naudu, taču kaut kādus izvilkumus var dabūt par velti.

Kāda tad ir tirgus daļa saskaņā ar šiem datiem?

Pirmo N ierakstu atlase

Atlasīt pirmos N (2, 3, 5, 10, 20, 100 utt.) ierakstus ir diezgan izplatīta prasība. Atlasīt N lielākos, N mazākos, N jaunākos utt. Angliski to parasti sauc kā Top N analysis vai Top N Query. Savukārt (parasti webiskās aplikācijās) mēdz būt vēl viena diezgan tipiska prasība – lapošana (pagination) – ierakstu atlase pa porcijām. Šīs ir tās lietas, kur datu bāzu vadības sistēmu atšķirības spīd visā savā spožumā. Tikai relatīvi pēdējā laikā izmantojot analītiskās funkcijas vismaz dažās DBVS var mēģināt izlīdzēties ar vienu un to pašu SQL teikumu pirmo N ierakstu atlasē un lapošanā. Kā jau vienmēr esmu mēģinājis uzsvērt, tas gan nebūtu jāuzskata par milzīgu trūkumu, jo arī, iekāpjot cita ražotāja automašīnā, Jūs negaidat, ka ātruma pārslēgs slēgsies precīzi tāpat ka iepriekšējā. Truli laužot to pierastajā pozīcijā, Jūs varat iegūt tikai salauztu mašīnu un ar datubāzēm, protams, ir līdzīgi. Tiktāl ievads, bet tagad pēc kārtas par Oracle, MySQL, SQL Server un analītisko funkciju universālo risinājumu.

SQL teikuma izpildes plāna iegūšana – Oracle, MySQL, SQL Server

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.