Saglabātās procedūras

februāris 15, 2011

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, savienojumusanalī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. Lasīt pārējo šī ieraksta daļu »


Ironija augstākajā pakāpē

Septembris 30, 2010

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:

Sql Server Database in status Suspect

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

Decembris 4, 2009

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? Lasīt pārējo šī ieraksta daļu »


Pirmo N ierakstu atlase

Oktobris 13, 2009

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.

Lasīt pārējo šī ieraksta daļu »


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

aprīlis 7, 2009

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. Lasīt pārējo šī ieraksta daļu »


Rudens – pļaujas laiks

Septembris 23, 2008

Tā vien izskatās, ka pasākumi par datubāzēm birst gandrīz straumēm. Tātad visi, kam vārds Microsoft SQL Server kaut ko izsaka, var iepētīt sīkāk .NET grupas mājaslapas aktualitātes. Citēju:

“Grupas biedriem labi pazīstamais cilvēks Macejs Pilecki, ir izteicis vēlmi dalīties pieredzē, šoreiz apskatot atmiņas izmantošanas īpatnības MS SQL serverī. Prezentācijas tēma – „Dude, Where Is My Memory? Understanding Microsoft SQL Server Memory Usage and Management”. Jāatzīmē, ka prezentācijai piešķirts augstākais tehniskais līmenis (Level 400). Lai vieglāk uztvertu domu, ir padomāts par neformālāku norises vietu. Esat laipni gaidīti 30. septembrī, plkst. 18:00 – 20:00, Beļģu alus kafejnīcā Braserija „Bon Vivant”, Mārstaļu iela 8, Rīga.”

Ziņas autors Andrejs Mamontovs man teica, ka pasākums neesot tikai grupas biedriem, kaut gan tiešā tekstā oriģinālajā ziņā tas nav minēts 🙂

Par to, kas ir ziņā minētais Maciej Pilecki, sīkāk zin stāstīt google.


SQL “with” klauza

Septembris 16, 2008

Ja kāds vēl nav pamanījis, tad jau labu laiciņu dažās DBVS Select teikums var sākties nevis ar Select, bet ar atslēgas vārdu With. Tas ir kaut kādā mērā viens no apakšvaicājumu veidiem, kā tas tika apskaidrots iepriekšējā rakstā apakšvaicājumi – ievads.

Tātad kad to pielietot un kādi ir tā galvenie labumi? Ir divas galvenās lietas kādēļ ir vērts to lietot – lasāmībai un ātrdarbības uzlabošanai.

  • Lasāmību tas var uzlabot tādā veidā, ka, ja Jums ir SQL teikums, kurā vairākkārt tiek lietots viens un tas pats (vai līdzīgs) apakšvaicājums, tad Jūs varat izdalīt no tā ārā kopīgo daļu – tāda kas ir kopīga visos gadījumos un to rakstīt pašā sākumā zem šī With un tālāk atsaukties jau kā uz zināmu defīnīciju.
  • Savukārt ātrdarbībai optimizatoram tagad ir 2 iespējas. Viena iespēja ir ievietot Jūsu apakšvaicājuma definīciju pa taisno iekšā SQL teikumā visur, kur tas tiek izmantots, tādējādi it kā nonākot atpakaļ pie situācijas, kāda bija bez šīs klauzas pielietošanas. Otra iespēja ir vispirms materializēt Jūsu apakšvaicājumu pagaidu tabulā un tālāk veikt pamata SQL teikuma izpildi jau izmantojot šo materializēto pagaidu tabulu.

Es turpmāk apskatīšu sīkāk šīs With klauzas implementāciju divās DBVS – Oracle un SQL Server. Tradicionāli es mēdzu rakstīt arī par MySQL, bet tur šāda klauza nav pieejama.

Sintakse

WITH <vaicājuma nosaukums1>
AS (<apakšvaicājums1>)
[, <vaicājuma nosaukums2> AS (<apakšvaicājums2>), ...]

Tātad kā redzams viss sākas ar atslēgas vārdu WITH, pēc tam nāk <vaicājuma nosaukums>. Šeit ir nepieciešams vienkārši piešķirt vārdu šim apakšvaicājumam, lai vēlāk būtu iespējams uz to atsaukties. Pēc tam ir atslēgas vārds AS, aiz kura iekavās seko <apakšvaicājums>. Apakšvaicājums parasti var būt pilnvērtīgs Select teikums ar savienojumiem un citiem apakšvaicājumiem. Vienlaicīgi var būt vairāki šādā veidā definēti apakšvaicājumi, kas tiek viens no otra atdalīti ar komatu. It kā nekas sarežģīts tāpēc pārejam pie konkrētām DBVS un konkrētiem piemēriem. Lasīt pārējo šī ieraksta daļu »