Oracle Express Edition pasākums

Visiem, kas interesējas par datubāzēm, bet vēl neko īpaši nav ielauzušies Oracles pasaulē (vai arī tajā nav tikuši pārāk tālu) varētu būt interesants Oracle Database Installfest pasākums 4. decembrī plkst 15:00 Latvijas Universitātes Mazajā aulā (Raiņa bulvārī 19).

Pasākumā ieeja ir bezmaksas un, kā lasāms pasākuma anotācijā, tiks prezentēta Oracle Express redakcija (XE) un izstrādes vide Application Express. XE ir viena no piecām Oracle redakcijām (editions), pati mazākā ar lielākajiem ierobežojumiem, toties pilnīgi bezmaksas. Ja kāds vēlas jau iepriekš pamēģināt mājās, kā tas ir un cik lielas iemaņas prasa, tad šis stāsts bildēs rāda, ka instalācija patiesībā ir ļoti vienkārša. Visi trīs anotācijā minētie pasniedzēji ir ļoti tehniski cilvēki, tāpēc pasākums solās būt diezgan tehnisks

Šodienas baisās krīzes apstākļos apgūt jaunas zināšanas noteikti ir viena no iespējām, kā no tās izvairīties, kā arī, ja Jūsu mīļākā DBVS ir jebkas cits, nevis Oracle, Jums droši vien būs iespēja uzdot kādus indīgus jautājumus

Nekāda speciāla reģistrācija, kā Edgars saka šeit, nav nepieciešama.

Vairāk info par pasākumu:

• Oracle Database Installfest 2008.

Atskaņas par Oracle traucējummeklēšanas (troubleshooting) semināru

Kā jau pirms ilgāka laika rakstīju Rīgā nu jau ir noticis Advanced Oracle troubleshooting seminārs, ko lasīja Tanels Poders (Tanel Poder). Manus kopējos iespaidus var raksturot tas, ka vienu brīdi nebija īstas skaidrības, vai man pašam par to nebūs jāmaksā, galu galā pašam jāmaksā nebija, bet, ja arī būtu bijis, noteikti nenožēlotu.

Seminārā pavisam piedalījās 27 klausītāji, no kuriem daži bija arī no tuvējām ārzemēm (Igaunijas un Lietuvas). Tas nozīmē, ka pie mums tepat Latvijā ir vismaz vairāk kā 20 cilvēki, kas, es atļaušos teikt, ļoti nopietnā līmenī interesējas un (jādomā) pārzin Oracle datubāzi. Otra lieta, kas norāda, ka Latvija acīmredzot tomēr ir informātikas lielvalsts, ir fakts, ka iepriekšējā Tanela pasākumā Lietuvā esot bijis krietni mazāk cilvēku

Par ko tad bija seminārs?

Galvenais uzsvars tika likts uz sistemātisku pieeju, kā noskaidrot, kas pašlaik Oracle procesā (kas apkalpo kādu konkrētu sesiju) notiek. Problēmas (datubāze lēni strādā) gadījumā:

• nevis meklēt šur un tur, ar mērķi ja nu trāpu;
• nevis paļauties uz iepriekšējo pieredzi, kas pirms gada Pēterim palīdzēja (kaut gan zināmas sistēmas periodiski atkārtojošos gadījumos arī tas var būt ļoti efektīvs risinājums);
• nevis sākt drudžaini kaut ko pētīt no operātājsistēmas, tīkla u.c puses;
• BET atrast vainīgo sesiju un sākt problēmas izpēti no tās.

Protams, klasiskā klienta servera gadījumā sesiju atrast nav sevišķi problēmātiski, arī gadījumā, ja problēma ir visiem, tad grūtības nav lielas – pietiek izvēlēties jebkuru, un visdrīzāk, arī tā būs labs reprezentants -, sliktāk ir sesiju pūla (connection pooling) gadījumā, ja problēmas ir vienam vai tikai dažiem lietotājiem, jo tad Oracle galā katrs pieprasījums var būt citas sesijas ietvaros. Bet principā arī tam Oracle piedāvā risinājumus dbms_session (set_identifier) un dbms_application_info (set_action/set_module) izskatā priekš pl/sql, savukārt citām vidēm, kas slēdzas pie Oracle, jāpēta atsevišķi.

Kad vainīgā sesija ir atrasta, tad augstā līmenī runājot nākošie soļi ir:

• Skatīties, ko rāda v$session, v$session_event un v$session_wait. Ja tajās parādās nopietns patērētais laiks vienam vai vairākiem Oracle gaidīšanas notikumiem (wait events), tad meklējam ko tas nozīmē Oracle dokumentācijā.
• Ja iepriekšējā solī nekāds nozīmīgs laika patēriņš netika atrasts, tad skatīties, vai nozīmīgi nepalielinās sesijas līmeņa statistiskie rādītāji v$sesstat (deltas!! nevis rādītāja lielums no sesijas izveides brīža pirms 2 nedēļām). Ja izrādās, ka tā notiek, tad meklējam, ko katra no statistikām nozīmē Oracle dokumentācijā.
• Ja arī tas nepalīdz, tad izgāžam (dump) procesa steku un pētam to. Lūk šī daļa man patika vislabāk un kā izrādījās vismaz daļēji tas nemaz nav tik briesmīgi, kā pirmajā brīdī izklausās.  Oracle Metalinks un iespējams Google var palīdzēt.

Turpinājumā tika vairāk vai mazāk sīki iztirzātas tādas lietas, kā procesa steks, atmiņas struktūras (x$ tabulas), latches (atmiņas struktūras, kas nodrošina tikai vienu vienlaicīgu kādas oprācijas izpildi), datu bloku kešs un ko nozīmē lasīšana no tā, gaidīšanas notikumu saskarne (wait events interface) – kā no dinamiskajiem skatījumiem (v$xxx) iegūt nepieciešamo info, kas ir kursors, kas ir SQL teikuma izpildes plāns un tā saistība ar iekšējām funkcijām, kas ir transakcija un kā notiek atrite (rollback) procesa atteices (crash) gadījumā. Noteikti, ka neuzskaitīju visu.

Ja nu tas viss Jūs ir ieinteresējis, bet tādu vai citādu iemeslu dēļ uz pasākumu netikāt, tad atliek tikai sākt pētīt augstākminēto Tanela blogu un tur atrodamo studēt pašam.

Rekursīvie vaicājumi

Veidojot datu modeli mēdz būt situācijas, kad nākas sastapties ar rekursijām (entītijai saite pašai uz sevi). Tipiskākie piemēri iz dzīves – organizācijas struktūra, kur ir viena virsiestāde un zem tās dažādos līmeņos pakļautās iestādes. Līdzīgi arī darbinieku pakļautība, ir galvenais boss, tam pakļautie un tā tālāk līdz pat katrai apkopējai. Vispārīgā gadījumā rekursija, protams, nav bezgalīga (vismaz datubāzu pasaulē), bet tai arī nav zināms maksimālais dziļums vai arī tas ir mainīgs un/vai pārāk liels, lai veidotu fiksētu hierarhisku datu struktūru, kurā datus glabāt. Rekursija, protams, vispārīgā gadījumā var būt arī vizuāla, kā tas redzams nākošajā fotogrāfijā.

Vizuāla rekursija

Konceptuālais datu modelis jau iepriekšminētajam, piemēram, par darbinieku pakļautību izskatās šāds. Ir entītija darbinieks. Katram darbiniekam var būt viens boss (kas atkal savukārt ir darbinieks). Katram darbiniekam var būt viens vai vairāki pakļautie, kas, savukārt, ir darbinieki.

Rekursija konceptuālajā datu modelī

Savukārt loģiskais datu modelis šai pašā situācijā izskatās šāds. Ir tabula DARBINIEKI. Ir naturālā primārā atslēga uz PERSONAS KODU. Ir ārējā atslēga BOSA_PERSONAS_KODS pašai tabulai uz sevi, kas norāda priekšnieku.

Rekursija loģiskajā datu modelī

Šo tabulu arī tad izmantosim turpmāko vaicājumu veidošanā.

Datu modelēšana – ievads

Datu modelēšana iet cieši rokrokā ar datubāzēm un SQLu. Bez konceptuālās modelēšanas nav iespējams (vai ir ļoti maza varbūtība) iegūt datubāzes modeli, kuru varēs veiksmīgi izmantot gan lai rakstītu saprātīgus pieprasījumus, gan lai potenciālas izmaiņas nenovestu pie pilnīgas esošā modeļa pārstrādes, gan lai pieprasījumu rezultāti tiktu iegūti pieteikami ātri. Tieši tāpat kā bez projektēšanas nav iespējams uzcelt lielu māju, lai tā nesagāztos un nebūtu šķība, tāpat bez datu modelēšanas nav iespējams iegūt labu datu modeli daudzmaz sarežģītākai situācijai. Savukārt mazmājiņai vai mazam šķūnītim nekāds oficiāls projekts, protams, nav vajadzīgs, bet nu mazs uzmetums uz papīra arī nebūt neskādētu. Bez loģiskās datu modelēšanas, ķeroties uzreiz pie tabulām, var ļoti viegli pazaudēt kopējo pārskatu, izlaist detaļas, izveidot katru modeļa daļu savādāk, nepamanīt kādas kopējas lietas, ko varētu unificēt utt. utjp.

Kas ir datu modelēšana?

Datu modelēšana ir process, kura laikā tiek analizēti un saprasti biznesam svarīgie datu objekti un kura rezultātā tiek izveidots datu modelis. Ar biznesu šet jāsaprot kāda joma, ko Jūs esat nolēmuši analizēt un saprast, piemēram, tā var būt mājas bibliotēkas uzskaites izveide (populārs uzdevums studentiem), grāmatvedība, dokumentu vadība, metamodeļa (modelis par datu modeli) izveide. Analīze un saprašana, protams, kaut kādē mērā ir formalizēta, vai vismaz tās vizuālais rezultāts – datu modelis – ir formalizēts. Tas nozīmē, ka Jūs varat sev šo modeli fiksēt jebkādā veidā, bet ir vispārpieņemtas notācijas, kā to pieņemts darīt tā, lai saprastu arī citi ļaudis. Tādas piemēram ir ER (Entity-relationship) modelēšana vai UML (Unified modeling language).

Kā norisinās datu modelēšana?

Aptauja par izplatītākajām DBVS noslēgusies

Pirms apmēram 2 nedēļām es aicināju lasītājus atbildēt uz jautājumu, kādas datubāzu vadības sistēmas viņi lieto. Laiks ir pagājis un aptauja tiek slēgta. Pavisam šai laikā tika saņemtas 176 balsis. Tā kā bija iespējams balsot par vairākām DBVS vienlaicīgi, tad nobalsojušo cilvēku skaits noteikti ir mazāks, bet, spriežot pēc tā kā auga dati, nemaz ne tik briesmīgi daudzi vienlaicīgi izvēlējās vairākas atbildes. Kas tad nu Latvijā (vai precīzāk tajā Latvijas daļā, kas lasa šo emuāru un saņēmās atbildēt) ir tas populārākais?

Tātad šeit uzskatāmā veidā parādīts balsu sadalījums: 

Populārākās datubāzes

Datubāzu Saeimā vēlēšanu robežu pārvarētu MySQL ar 34%, Oracle ar 27%, SQL Server ar 11%, Acess ar 9%, un PostgreSQL ar 8% balsīm.

Ka redzams tās 3 DBVS par kurām vairāk vai mazāk aktīvi stāstu, arī tiek visvairāk lietotas. Protams rodas jautājums – kurš te ir pirmais vista vai ola? Tas ir – vai nu pārējās DBVS nelieto, vai arī tomēr lieto un tāpēc, ka šeit par tām neko neraksta, tad arī nelasa un nepiedalās aptaujā. Es personīgi sliektos uz variantu, ka citas arī diez ko nelieto. Arīdzan interesanti, ka no diezgan daudzām DBVS, ko esmu uzskaitījis, lieto tikai apmēram 10.

Vaicāsiet kāda no tā visa praktiska jēga? Nu ja neskaita to, ka vienkārši interesanti zināt, tad nenoliedzama praktiska jēga ir tāda, ka Jūs, piemēram, varat atrast 59 cilvēkus, kas kaut ko pēdējā laikā ir darījuši vairāk vai mazāk ar MySQL, bet tikai vienu - ar DB2. Negribu apgalvot, ka tās ir absolūtās tendences Latvijā, bet kaut kāda nozīme tam varētu būt un tas varētu sniegt atbildi uz jautājumu par potenciāli pieejamo darba spēka tirgu attiecībā uz izvēlēto DBVS.

Nobeigumā paldies visiem atbildētājiem, bez Jums šeit nekas jēdzīgs nesanāktu!