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

novembris 24, 2008

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.

Advertisements

Patērētā laika mērīšana Oraclē

novembris 13, 2007

Turpinot iesākto tēmu “Kā noskaidrot, kur paliek laiks?” tagad sīkāk par to kā procedūras, funkcijas, SQL teikuma utt. izpildes laiku var izmērīt Oracle datubāzē.
Protams, varētu mēģināt sēdēt ekrāna priekšā ar hronometru vai pulksteni rokā un tādā veidā noskaidrot cik tad laiks tika patērēts. Tiesa gan tā nav no tām precīzākajām metodēm un arī ļoti mazus izpildes laikus vis nenoķersi. Tā kā jārīkojas mazliet gudrāk.
Pati elementārākā iespēja ir izmantot rīku SQLPlus un izmantot šī rīka komandu SET TIMING ON.
Tas izskatās šādi:

SQL> set timing on
SQL> exec dari_kautko
PL/SQL procedure successfully completed.
Elapsed: 00:00:03.00
SQL>

Ne vienmēr, protams, visas PL/SQL procedūras un/vai SQL teikumi tiek izsaukti izmantojot SQLPlusu, kā arī bieži rodas ļoti liela vēlēšanās mērīt procedūras iekšienē, cik ilgi katrs SQL teikums vai kāds procedūras bloks izpildās. Tādā gadījumā ir iespējams izmantot vairākas iespējas. Visvienkāršākā, protams, ir lietot mainīgo ar datu tipu date, kas patiesībā ir datumlaiks, bet tā mīnuss ir tas, ka mazākā vienība ir sekunde. Itin bieži tas jau ir pārāk liels laika sprīdis.
Jau krietni labāka iespēja ir lietot iebūvētās pakotnes dbms_utility funkciju get_time, kas atgriež laiku sekundes simtdaļās. Šī pakotne ir pieejama vismaz no versijas 8i, tai skaitā protams 9i, 10g un arī jaunajā 11g. Parasti get_time lieto tikai, lai fiksētu sākuma atskaites punktu un tad iegūtu starpību starp beigu atskaites punktu un iepriekš fiksēto sākuma atskaites punktu, piemēram, šādi:

SQL> set serveroutput on
SQL> declare
  2 v number;
  3 begin
  4 v := dbms_utility.get_time;
  5 dari_kautko;
  6 dbms_output.put_line(‘Patērētais laiks ir:’ ||
  7 (dbms_utility.get_time – v) / 100 || ‘ sekundes’);
  8 end;
  9 /
Patērētais laiks ir:3 sekundes
PL/SQL procedure successfully completed.
Elapsed: 00:00:03.00
SQL>

Nākošā iespēja ir lietot timestamp datu tipu, kas satur arī sekundes daļas līdz pat 9 cipariem aiz komata (noklusēti 6). Atņemot no viena timestamp datu tipa otru tiek iegūts intervāls. Diemžēl intervāla datu tipam ir nepatīkama atšķirība no datuma un timestamp datu tipa, jo attēlojot to uz ekrāna nav iespējams ērti lietot formatēšanas modeļa elementus un tāpēc nākas darboties nedaudz viltīgi, lai neteiktu, piedodiet par izteicienu “čerez ž…“. Šajā piemērā intervāls tiek pieskaitīts timestamp vērtībai, kam tiek nogriezta visa laika daļā, līdz ar to piemērs strādās korekti, ja intervāls būs mazāks kā 24 stundas. Vairumā gadījumu ar to pilnīgi pietiek.

SQL> set serveroutput on
SQL> declare
  2 v timestamp;
  3 begin
  4 v := systimestamp;
  5 dari_kautko;
  6 dbms_output.put_line(‘Patērētais laiks ir:’ ||
  7 to_char(cast (trunc(systimestamp) as timestamp) + (systimestamp – v),’hh24:mi:ss.FF’));
  8 end;
  9 /
Patērētais laiks ir:00:00:03.000000000
PL/SQL procedure successfully completed.
Elapsed: 00:00:03.03

Ja jūs lietojat kādu tā saucamo grafisko lietotājam draudzīgo rīku, piemēram, PL/SQL Developer vai tamlīdzīgus, tad vismaz visai procedūrai kopā parasti izpildes laiks tiek parādīts, piemēram, šī rīka SQL Window izpildes loga statusa joslā tiek attēlots paziņojums “Done in 3,015 seconds”.

Nākošais līmenis jau ir mērīt ne tikai patērēto laiku, bet arī veikt citus mērījumus, kas sniedz plašāku ieskatu, kas tad tur apakšā patiesībā notika. Par to turpinājums ir rakstā par SQL*Plus komandu autotrace.


Kā noskaidrot, kur paliek laiks?

novembris 6, 2007

Virsraksts ir ļoti filozofisks, bet tai pašā laikā ļoti saistīts ar datubāzēm un programmēšanu kā tādu. Ikviens no programmētājiem ir saskāries ar problēmu, ka kods izpildās lēnāk nekā iecerēts vai katrā ziņā vismaz klientam tā šķiet. Tajā brīdī katrs no mums pielieto sev mīļākās metodes ko nu darīt. Daži tūlīt metas pie darba devēja vai klienta un sāk runāt par niknāka dzelža iegādi, daži drudžaini mēģina uzlabot tur kaut ko un šeit kaut ko, ja cilvēks ir veiksmīgs, iespējams tas viņam pat izdodas.
Diemžēl ne visi dzīvē ir veiksminieki un ne visi dzīvē ir tik pieredzējuši, lai ar savu intuīciju vai iepriekšējo pieredzi spētu izdomāt, kur tad šis laiks paliek. Un šajā gadījumā nekas cits neatliek kā izveidot precīzu atskaiti, kur tad laiks tiek pavadīts.
Ja es dzīvoju Jūrmalā (gribētos jau nu gan, bet patiesībā nekā:(), braucu ar mašīnu uz darbu Rīgā un katru rītu ierodos darbā par vēlu, tad ko man darīt? Tīri intuitīvi ko mēs darām? Pareizi – skriešus veicam pēdējos metrus no stāvvietas līdz darbam. Vai tiešām tam ir kāda jēga? Nu neapšaubāmi tam ir sportiska jēga un iespējams arī emocionāla jēga, kad priekšnieks redz, cik ļoti padotais vēlas strādāt. Taču attiecībā pret mūsu galveno mērķi – ierasties darbā ātrāk – jēga ir ļoti maza. Kāpēc? Tāpēc, ka sadalot pa sastāvdaļām mūsu maršruts izskatās apmēram šādi:

  • 5 minūtes, lai no Jūrmalas tiktu ārā;
  • 10 minūtes no Jūrmalas robežas līdz pirmajiem sastrēgumiem Rīgā;
  • 30 minūtes, lai tiktu pāri tiltam līdz darbam;
  • 2 minūtes, lai no stāvvietas uzkāptu pa trepēm un ienāktu birojā.

Pat, ja mēs iemācītos teleportēties no stāvvietas līdz birojam, tas kopējo laiku 47 minūtes samazinātu līdz 45 minūtēm un ietaupījums būtu ~4%. Diez ko iepriecinoši vis neizskatās.
Jūs teiksiet muļķīgi darām, vai ne? Jāminimizē kaut kā tie lielākie laika posmi!
Piemēram, varētu sākt ar 30 minūšu tupēšanu sastrēgumos. Kādas ir iespējas?

  • Izbraukt ātrāk?
  • Izbraukt vēlāk un sarunāt ar priekšnieku, ka mainam darba dienas sākumu un beigas?

Varbūt kļūt radošākiem un “domāt ārpus kastes” (think out of the box)? Piemēram:

  • Iegādāties helikopteru?
  • Mainīt darbu?
  • Mainīt dzīvesvietu?
  • Kļūt par rantjē?

Tieši tas pats attiecas arī uz standarta problēmu, kad programma strādā lēni. Nav haotiski un drudžaini jācenšas veikt kaut kādas maģiskas darbības, kuras palīdzēja Jānim pagājušogad un Pēterim vēl nupat nesen. Nav vērts savas pūles ieguldīt līdz neprātam skaņojot lielu SQL teikumu, kurš izpildās vienreiz un aizņem 5% no kopējā izpildes laika, bet tajā pašā laikā ir viens it kā sīks un necils SQL teikums, kas ciklā izpildās 10 tūkštoš reižu un aizņem 95% laika. Ir vienkārši jānoskaidro, kur laiks tiek patērēts. Jāsastāda atskaite ar darbībām, kas tiek veiktas pēc pogas nospiešanas un katrai šai darbībai jānomēra tās izpildes laiks. Un tad, kad ir skaidrs, kas bremzē un kas aizņem lielāko daļu laika, ir jāķeras pie šīs bremzes novēršanas.
Tikai tad jūs beidzot sapratīsiet, ko patiesībā jūs kods dara 🙂 Tikai tad jūs beidzot sapratīsiet kāda funkcionalitāte vispār zem šīs pogas slēpjas. Tikai tad jūs beidzot droši un precīzi varēsiet pateikt, lai beidz visās nelaimēs vainot Kanādu t.i. datu bāzi, vai arī tieši otrādi ķerties pie sliktā SQL teikuma vai procedūras (kas noteikti ir jāanalizē ar tādu pašu metodi tālāk) uzlabošanas/pārrakstīšanas/izmešanas.
Kādā veidā izveidot atskaiti, kurā parādās izpildītie soļi un to patērētais laiks, kā arī kādā veidā tad mēģināt panākt, lai konkrētā bremze nebūtu tik bremzīga, tas jau nav vairs šī raksta uzdevums.


Datu bāze vai datu izgāztuve? III

Oktobris 31, 2007

Šī ir trešā un pagaidām pēdējā daļa rakstam, kurš tika iesākts šeit. Šai daļā ir apkopoti tie “ieguvumi”, ko jūs varat gaidīt no savas datu izgāztuves.

Datu izgāztuves sekas

Zemāk uzskaitītās potenciālās sekas protams nav pilnīgs uzskaitījums, tās ir spēkā tad, ja ir sliktākais scenārijs atbilstoši iepriekš uzskaitītajām datu izgāztuves pazīmēm. Tāpēc es ceru, ka ir maz tādas datubāzes pasaulē un Latvijā, kas atbilst pilnīgi visām šīm pazīmēm, vai sliktākajā gadījumā jums vismaz ar tādām nav jādarbojas 🙂 Pat ja jums tomēr nav īpaši paveicies un nākas ar kaut ko tādu darboties, jācer, ka jums izdosies kaut kā izkļūt no situācijas, piemēram, atrodot kādu, kas jau ir izpētījis šo datu bāzi, varbūt datubāze ir tik maza, ka to spēj izanalizēt jebkurš saprātīgā laikā, varbūt jūs varat pierunāt klientu sākt jaunu skaistu dzīvi bez vecajiem nevienam nesaprotamajiem datiem.

1. Attīstība un izmaiņas ir gandrīz neiespējamas

Jo vairāk jūsu datu bāze patiesībā ir datu izgāztuve, jo vairāk katra izmaiņa jums izmaksās.

Jūs esat nolemti būt kopā ar savu datu izgāztuvi un nekas cits neatliek kā lūgt Dievu, lai kāds neatrastu kādu kļūdu.

2. Migrācija (Datu konversija) ir gandrīz neiespējama

Pieņemsim, ka jūs esat sapratis, kādā ķezā esat iekūlies un nolēmis sākt jaunu skaistu dzīvi, tiesa gan no vecās sistēmas izgūstot ārā vecos datus. Sliktās ziņas ir tādas, ka īstas datu izgāztuves gadījumā tas var būt ļoti sarežģīti un robežoties ar manuālu darbu.

  • Ar 1. Dokumentācijas neesamība un 2. Vienīgā zinošā persona nesen mainīja darbu jūs nezināt KO migrēt. Jūs nezināt, kurās tabulās un kolonās glabājas kādi dati, nav skaidrs kuri no tiem ir jāņem vērā, bet kurus var ignorēt, piemēram, tāpēc, ka kolona tabulā ir palikusi, bet to reāli neviens vairs neizmanto. Patiesību sakot jums nav skaidrs, ko vispār šis tabulu un kolonu jūklis nozīmē.
  • Ar 5. Visa loģika aplikācijā / datubāzē ir tikai tabulas un 7.1. Datu integritātes ierobežojumu trūkums jums ir ieraksti bez nepieciešamās informācijas (jo nav NOT NULL ierobežojumu), jums ir bāreņu ieraksti, jums vairākās vietās glabājas viena un tā pati informācija, kas ir pretrunīga utt.
  • Ar 7.3. Klasifikatoru trūkums un 7.4. Nekorektu datu tipu lietošana katrs lietotājs ir ievadījis datus kā viņam labpatika, tā vietā lai veiktu tiešu klasifikatoru pārkodēšanu jums ir jākasa ārā informācijas druskas no teksta laukiem. Tā vietā lai vienkārši iegūtu datumu, jums ir jāveic konvertācija no 5 dažādiem laika formātiem vienā un tai paša laukā, piedevām izdomājot ko darīt, ja tāds datums vienkārši neeksistē. Pats sliktākais scenārijs šai gadījumā ir tāds, ka jūs esat spiesti nolīgt kādu bariņu ar studentiem/melnstrādniekiem, kas manuāli iziet cauri visiem ierakstiem un tos salabo.
  • Ar 7.2. Šifrēti un neinformatīvi tabulu nosaukumi migrācijas koda rakstīšanas uzdevums kļūst par murgu un katru vakaru jums sāpēs galva 🙂

Parasti tā visa rezultātā ar milzīgām pūlēm jums ir izdevies vismaz daļēji pārnest datus, bet visi lietotāji sūdzas, ka iepriekšējā sistēma bija labāka, jo tajā bija visi dati un tā pieļāva daudz lielāku rīcības brīvību (varēja dažus laukus ievadīt, dažus ne, varēja pierakstīt visu teksta laukā savā iemīļotajā formātā, tagad jāizvēlas kaut kādas predefinētas vērtības, lai papildinātu klasifikatorus, jāiet uz citām formām utt.).

3. Teorija, ka aplikācija ir galvenā vērtība nevis dati

Iespējams, ka datu izgāztuves biežākais cēlonis ir doma, ka galvenais ir aplikācija nevis paši dati. Šī diskusija laika gaitā uzpeld atkal un atkal. Es gan esmu redzējis tikai to, ka aplikācijas nāk un iet bet vēlme pēc vēsturiskajiem datiem paliek. Piemērs par man zināmāko Oracle datu bāzi. Es neredzu īpašu iemeslu kāpēc šodien nevarētu lietot to pašu datu modeli, kas tika saprātīgi projektēts deviņdesmito gadu sākumā versijā 7.X. Tai pašā laikā pa šo laiku ir mainījušās vairākas modes kā tad ir stilīgi un vajadzētu programmēt aplikācijas, piemēram,

  • tekstuālas formas, kas tika izpildītas uz servera;
  • klienta servera formas;
  • 3 līmeņu arhitektūra, ar aplikāciju serveri neskaitāmās valodās, piemēram, java, php, .NET, kur katram ir savs adeptu bariņš.

Lielākajā daļā esošo projektu esmu redzējis vēlmes ielādēt sākotnējos datus no teksta failiem, dažādām vēsturiskām un ne tik vēsturiskām datu bāzu pārvaldību sistēmu datu bāzēm vai tās pašas DBPS iepriekšējā datu modeļa versijas. Visi šie dati tika ievadīti izmantojot kādu aplikāciju. Kur tās ir tagad? Izmestas vēstures mēslainē, neviens par tām neatceras, ja neskaita iespējams kāda izstrādātāja nostaļģiskas atmiņas. Bet to ievadītie dati bieži ir interesanti vēl joprojām. Diemžēl ja jums ir datu izgāztuves cienīga datu bāze, tad ir spēkā šī teorija, ka galvenā vērtība ir aplikācija, jo datus bez aplikācijas neviens nespēj saprast un apstrādāt.

Kopsavilkums

Datu izgāztuves simptomu neesamība negarantē, ka jūsu datubāzei nebūs problēmu. Bet pieļaujot šīs kļūdas jums būs problēmas, ko nav iespējams atrisināt (izņemot 7.5. Haotiski indeksi) ar skaņošanu, kešošanu, rakstot optimālākus SQL vaicājumus, lietojot bind (bind) mainīgos, iegādājoties „niknāku” dzelzi vai ko citu. Tās ir loģiskās kļūdas, kas bieži vien nozīmē datubāzes projektēšanu no sākuma un iespējams arī jūsu aplikācijas pārrakstīšanu no nulles. Ja jūs noteikti esat pārliecināts, ka kādu no šiem simptomiem jūs apzināti gribat pieļaut, tad pārdomājiet to vismaz divreiz un vismaz sev noformulējiet gan plusus, gan mīnusus jūsu izvēlētajai pieejai. Tas vismaz ļaus jums ielūkoties dziļāk iespējamās problēmās un iegūt jaunas lēmumu pieņemšanas prasmes 🙂

Turpmākā lasāmviela:

1. http://en.wikipedia.org/wiki/Anti-pattern – Anti-pattern, no Vikipēdijas, brīvās enciklopēdijas;

2. http://www.web-hits.org/txt/codingunmaintainable.html – Kā rakstīt neuzturamu kodu;

3. http://asktom.oracle.com/pls/asktom/f?p=100:8:3045776155360546::NO – Oracle Open World 2006 programmētāju un DBA slikto paradumu prezentācija, lielākā daļa no tām attiecas uz jebkuru datubāzi.

Raksta pirmā daļa, otrā daļa.


Datu bāze vai datu izgāztuve? II

Oktobris 30, 2007

Šī ir otrā daļa rakstam, kurš tika iesākts šeit. Būs vēl arī trešā pēdējā daļa, kurā tiks paskaidrots, kādas potenciālas problēmas jūs nakotnē gaida, ja jūs veidojat nevis datu bāzi, bet datu izgāztuvi.

4. Nosaukumu vadlīniju trūkums

Parasti šī problēma iet roku rokā ar Sākotnējā projektējuma trūkums (3). Haotiski nosaukumi gan datubāzes objektiem, gan programmatūrā ir viens no labākajiem veidiem, kā rakstīt neuzturamu kodu. Tas rada pilnīgi nesapratni, par katru objektu ir jāpārliecinās, ko tas patiesi nozīmē, nav iespējams izmantot analoģiju, balstoties uz esošajām zināšanām. Nav tik būtiski kādas tieši vadlīnijas tiek izmantotas, kā tieši nosaukumu tiek veidoti, bet ļoti būtiski ir, lai jūsu projektā nosaukumu veidošanas vadlīnijas tiktu pieņemtas un pēc tam tās tiktu ievērotas.

Turpmākā lasāmviela:

1. http://www.gplivna.eu/papers/naming_conventions.htm – Nosaukumu veidošanas vadlīnijas Oracle tabulām, kolonām, indeksiem, ierobežojumiem u.c.

5. Visa loģika aplikācijā / datubāzē ir tikai tabulas

Visa jūsu aplikācijas biznesa loģika ir ārpus Oracle datubāzes? Jā? Tad kāda iemesla dēļ jūs iztērējāt tik daudz naudas par Oracle licencēm? Jūs noteikti būtu iztikuši ar MySQL. Kāpēc? Vienkārši tāpēc, ka Oracle piedāvātā funkcionalitāte salīdzinot ar MySQL ir daudz lielāka, un tas neapšaubāmi atstāj iespaidu arī uz ātrdarbību. Tas būtu apmēram tas pats, kā īrēt milzīgu māju, ar daudzām istabām un dažādu aprīkojumu, bet spītīgi izmantot tikai dzīvojamo istabu. Jūs nelietojat piemēram tualeti. Galu galā kāpēc lai lietotu, var taču iziet ārā dārzā un paveikt nepieciešamās lietas tur 🙂 Jūs nelietojat virtuvi, jo var taču tāpat ārā uz ugunskura. Un te nu lūk ir jautājums – vai tiešām jūs šādi rīkotos arī ar savu īrēto māju, par kuru esat samaksājis krietnu naudu, bet tās piedāvātās iespējas izmantojat tikai par dažiem procentiem? Tieši tāda pati situācija ir ar datubāzēm, jo sevišķi datubāzēm, kas nodrošina plašu funkcionalitāti. Jūs esat samaksājis tik daudz naudas un pēc tam labprātīgi sevi aplaupat.

Ja jūs meklējat brīnumu, ko sauc par datubāzes neatkarību, tad visticamāk jūs esat sasnieguši situāciju, kad jūsu aplikācija optimāli nestrādā ne uz vienas no izmantotajām datubāzēm Visa iebūvētā funkcionalitāte ir cik vien iespējams tuvu datiem un tas ir primārais iemesls, kāpēc tā parasti veic attiecīgās lietas labāk, nekā tās pašas iespējas ārpus datubāzes. Pēc iepriekšējās analoģijas tas būtu kā dzīvot dažādas arhitektūras mājās, bet izmantot vienalga tikai dzīvojamo istabu. Esmu pārliecināts, ka jūs nebūtu apmierināts ar šādu dzīves kvalitāti.

Turpmākā lasāmviela:

1. http://www.rittmanmead.com/2004/11/24/the-cost-of-database-independence/ – The Cost of Database Independence by Mark Rittman.

6. Daudzas personas jau ir pielikušas savu pirkstu datu izgāztuves veidošanā

Kopā ar Sākotnējā projektējuma trūkumu (3) un Nosaukumu vadlīniju trūkumu (4) visi projekta dalībnieki, kas papildina jūsu datubāzi, ir kā bars cilvēku, kas izgrezno jūsu māju gan no iekšpuses, gan ārpuses bez jebkādas kopējas idejas un katrs pēc sava prāta un talanta spējām. Ja jūs esat veiksminieks, var gadīties, ka rezultāts jūs apmierina, bet vairumā gadījumu, tas būs kaut kas tāds, kas iedzīs šausmās pat vislielāko flegmatiķi. Tieši tāda pati situācija ir ar datubāzēm. Ir daudzas konvencijas, standarti un vadlīnijas, ko ievērot un, ja vairāk kā viena tiek lietota jūsu datubāzē, tad katra nākošā palielina kopējo neskaidrības un nesapratnes līmeni. Tas visacīmredzamāk kļūst tad, kad jums nākas vienlaicīgi modificēt divus objektus, kas izstrādāti vadoties pēc dažādām vadlīnijām – ko tagad darīt, turpināt, tādā pašā jau iesāktajā garā un palielināt kopējo dažādību vai izvēlēties vienu no esošajām, tādējādi iegūstot moduli, kam puse izskatās vienādi, bet otra puse otrādi? Varbūt vēl kādu citu variantu?

7. Datubāzu objektu fiziskie atribūti

7.1. Datu integritātes ierobežojumu trūkums

Šī parasti ir visradikālākā Visa loģika aplikācijā / datubāzē ir tikai tabulas (5) forma vai arī vienkārši rezultāts absolūtai nekompetencei. Ja jums datubāzē nav datu integritātes ierobežojumu, tad tas ir tikai laika jautājums, kad jums būs bāreņu (orphan) ieraksti, dublicētas vērtības un nevēlamas vērtības. Agrāk vai vēlāk kāds pamainīs datus apejot jūsu aplikāciju, agrāk vai vēlāk kāds pat negribot atradīs kļūdu jūsu aplikācijā un jūsu dati tiks sabojāti.

Mēģinājumi aplikācijas līdzekļiem ierobežot, piemēram, unikālas vērtības kādā kolonā  apriori ir gandrīz vienmēr lemti neveiksmei (vai arī risinājumi būs nepilnīgi), it sevišķi, ja jūsu aplikāciju vienlaicīgi lietos vairāk kā viens lietotājs 😉

Turpmākā lasāmviela:

1. http://en.wikipedia.org/wiki/Referential_integrity – Datu integritāte, no Vikipēdijas, brīvās enciklopēdijas;

2. Oracle® Database Application Developer’s Guide – Fundamentals, 6 Maintaining Data Integrity in Application Development;

3. http://tkyte.blogspot.com/2006/06/what-did-i-decide-on.html – The Tom Kyte Blog, some worst practises.

7.2. Šifrēti un neinformatīvi tabulu nosaukumi

Tabulas ar nosaukumiem tab1, tab2 un/vai kolonas ar nosaukumiem kol1, kol2 var pārvērst jebkura cilvēka dzīvi ellē. Tad jau labāk tabulu nosaukumi kādā matabelelendas valodā, vismaz ir iemesls uzzināt ko daži vārdi šai valodā nozīmē. Strādājot ar iepriekš neiepazītu datubāzi ir grūti atcerēties loģiskus nosaukumus, nemaz nerunājot par kol1 vai tab2. Katra tāda lietošanas reize nozīmē ieskatīšanos dokumentācijā vai cita veida pierakstos.

7.3. Klasifikatoru trūkums

Cilvēks spēj izlasīt un saprast informāciju, kas ir pasniegta daudzos un dažādos veidos. Cliēvks sēpj izloībt jgēu arī no dizeagn kļūidanas ifnomrācjias. Ar datu bāzēm un precīziem algoritmiem ir daudz sliktāk. Tiklīdz kā jums nāksies uzrakstīt kādu atskaiti par lietām, kas it kā datu bāzē glabājas, bet ir, piemēram, teksta laukā, tā momentāli radīsies lielas un pamatīgas problēmas. Pieņemsim, ka jūs vēlaties nopirkt auto ar elektriski paceļamiem logiem un meklējat tādus kādā no mūsu sludinājumu serveriem. Kā cilvēks es saprotu, ka el. logu pacēlāji, el. logu pac., Elektriski regulējami logi, el. Logi ir viens un tas pats, bet atskaiti ģenerēt uz šādiem tekstiem būtu krietni vien grūtāk. Patiesības labad jāsaka, ka visos lielākajos sludinājumu serveros ir iespēja atķeksēt pārdodamajam auto šo „ekstru” un iegūt vienu kopīgu tekstu visos sludinājumos, tiesa gan tas nekavē dažus censoņus tekstā ievadīt savus variantus. Protams arī klasificētas vērtības vien nenodrošinās korektu datu ievadi, piemēram, vienā no sludinājumu serveriem Opel Zafira bija klasificēta kā mikroautobuss, universāls un hečbeks, tai pašā laikā parasti tā visur tiek saukta kā minivens, bet šāda iespēja izvēlēties netika piedāvāta 🙂

Otra iespēja ir vienā laukā glabāt saliktus datus, piemēram, vārds un uzvārds. Agrāk vai vēlāk būs tādas iespējas, kā Jānis Bērziņš, Bērziņš Jānis, J. Bērziņš, Bērziņš J. un iespējams arī kādi citi varianti. Protams, ja jūsu biznesa vajadzības nekad neprasīs šos laukus sadalīt un atpazīt, tad viss ir kārtībā, citādi radīsies problēmas.

7.4. Nekorektu datu tipu lietošana

Visbiežāk novērotā grēkošana ir VARCHAR tipa lietošana NUMBER un DATE vietā. Tā rezultātā ir iegūts liels kļūdu potenciāls. Skaitļu vietā simboli, korektu datumu vietā 30. februāri ir tikai sākums. Turpinājumā kārtošana nez kāpēc notiks samērā dīvaini – vispirms ‘1’, ‘10’ un tad tikai ‘2’, nemaz nerunājot par to, kā kārtos datumus. Dažāda veida netiešo (implicit) konversiju sekas būs neoptimāli vaicājumu izpildes plāni. Lai no tā visa izvairītos ir jāizdara relatīvi vienkārša lieta – jāizvēlas atbilstošs datu tips katrai kolonai.

7.5. Haotiski indeksi

Šis ir vairāk fiziskais nekā loģiskais datu bāzes aspekts. Ja datubāzei ir vairāk vai mazāk tikai tie indeksi, kas tai reāli nepieciešami, tad ir vieglāk atrast kopējas datu pieejas shēmas. Ja datu bāzei indeksi ir veidoti haotiski un kā pagadās, tad pirmkārt tiek nevajadzīgi uzturēti lieki indeksi, kas palēnina DML (izņemot SELECT) teikumus, otrkārt – nav nekādas skaidrības kā tad aplikācija un/vai citas saskarnes iegūst datus.

Raksta pirmā daļa, trešā daļa.


Datu bāze vai datu izgāztuve?

Oktobris 24, 2007

Šī raksta oriģināls ir angliski un atrodams šeit. Tā kā tas ir manis paša rakstīts, tad ar autortiesībām viss ir kārtībāJ

Katrs no mums ir vairāk vai mazāk pazīstams ar datu bāzēm. Sākot ar vecu lapiņu jūkli ar telefonu numuriem un draugu dzimšanas dienām, un beidzot ar relāciju datu bāzu vadības sistēmām, kuras satur miljoniem ierakstu un terabaitiem datu.

Lielākā daļa cilvēku domā, ka nezin, kas ir datu izgāztuves. Bet patiesībā tā nemaz nav!

Kas tad ir datu izgāztuve?

Īsumā tā ir datu bāze, kurā nav definētu noteiktu algoritmu, kā iegūt korektus datus un dati ir pretrunīgi. Ja tā ir jūsu papīru kaudzīte vai tas ir jūsu dators, kas satur jums vien saprotamā haosā esošas datnes, tad tā ir tikai un vienīgi jūsu problēma. Bet, ja tā ir datu bāze, ko lieto desmitiem un simtiem lietotāju, kas nodrošina ar informāciju veselas organizācijas un pat valstis, tad, protams, situācija ir daudz sliktāka.

Kā jau tas parasts – apzināšanās, ka esat bedrē, ir jau pirmais solis ārā no bedres 🙂

Tāpēc sākumā parunāsim, kādi ir datu izgāztuves simptomi, bet tālāk kādas tam ir potenciāli sliktas sekas.

Kā no tā tikt vaļā – lūk tas jau ir krietni sarežģītāks jautājums. Diemžēl, kā jau parasti nesalīdzināmi daudz vieglāk ir ķezā neiekulties, nekā mēģināt no tās tikt ārā.

Datu izgāztuves simptomi

Šeit esmu centies apkopot plašāk izplatītos datu izgāztuvju simptomus. Lielākā daļa no tiem nav tīri jā/nē tipa jautājumi un atbildes, bet jo vairāk jums šādu simptomu ir pēc skaita un jo spēcīgāk jums tie izpaužas, jo lielāka iespēja, ka agrāk vai vēlāk jums nāksies sastapties ar negatīvām sekām.

Lai gan atsauces lielākoties ir saistītas ar Oracle datu bāzi, šie simptomi ir attiecināmi uz jebkuru datu bāzi, neatkarīgi no tā kādā vidē tā ir izstrādāta, ja vien šī datubāze nodrošina kaut ko vairāk, nekā iespēju glabāt datus tabulās.

1. Dokumentācijas neesamība

Ko es saprotu ar dokumentāciju? Es šeit nedomāju tikai un vienīgi dokumentus MS Word formātā atbilstoši kādam vispārpieņemtam standartam, kaut gan tā ir viena no ļoti reālām iespējām. Patiesībā dokumentācija var būt ļoti dažāda veida:

1) programmatūras projektējuma apraksts atbilstoši LVS standartam;

2) atsevišķs dokuments ko var nosaukt piemēram par datubāzes projektējuma aprakstu;

3) komentāri datubāzē pie katras tabulas un kolonas.

Ir ļoti svarīgi atcerēties, ka galvenais dokumentācijas mērķis nav iegūt visu tabulu un kolonu uzskaitījumu, bet ka galvenais mērķis ir darīt zināmu, kāpēc šāda tabula vai kolona ir izveidota, kādas ir tās iespējamās vērtības, ko katra vērtība nozīmē, kāda ir tabulas/kolonas sūtība.

Ir ļoti viegli noģenerēt kolonu un/vai tabulu sarakstu no datubāzes, ir ļoti viegli izgūt visām tabulām primārās atslēgas, sasvstarpējās relācijas un citus ierobežojumus, izmantojot datu vārdnīcu, bet daudz grūtāk ir saprast ko katrs no šiem objektiem dara un kādam mērķim kalpo. Piemēram, ir diezgan bezjēdzīgi kolonas komentāros rakstīt, ka tā ir ārējā atslēga uz tabulu X, bet nepaskaidrot tās biznesa nozīmi. To, ka šī kolona ir ārējā atslēga, ir ļoti viegli noskaidrot izmantojot datu vārdnīcu vai (kas būtu vēl labāk) pēc nosaukuma, kas atbilst attiecīgām vadlīnijām. Tai pašā laikā ne vienmēr ir acīmredzami, kāda ir biznesa nozīme šādai ārējai atslēgai.

Turpmākā lasāmviela:

1.New Media (Oracle) Database Design Template(Ļoti laba datubāzes projektējuma apraksta veidne).

2. Vienīgā zinošā persona nesen mainīja darbu

Kopā ar Dokumentācijas neesamība (1) un Visa loģika aplikācijā / datubāzē ir tikai tabulas (5) ir ļoti lielas problēmas, ja sistēmā ir nepieciešamas izmaiņas vai no sistēmas ir jāizgūst dati. Tādā gadījumā vienīgā izeja ir analizēt datu modeli, analizēt datus un aplikācijas kodu (ja ir pieejams pirmkods). Tas prasa laiku. Tas prasa ļoti daudz laiku un resursus. Un nav nekādas garantijas, ka veiktās izmaiņas neizsauks pilnīgi neprognozētas sekas kaut kur citur. Iespējams, ka jūs tikai pēc kāda laika uzzināsiet, ka jūsu veiktās izmaiņas rada kļūdu kādā speciālā gadījumā vai vēl sliktāk – nemanāmi sabojā jūsu datus. Tāpēc rūpējieties un neizturieties pavirši pret jūsu vienīgo zinošo personu, bet tai pašā laikā piespiediet viņu atrisināt Dokumentācijas neesamības problēmu vai vismaz nodot savas zināšanas citiem kolēģiem.

3. Sākotnējā projektējuma trūkums

Jebkas, kas nav triviāls vai neskaitāmas reizes jau paveikts un kļuvis par absolūtu rutīnu prasa sākotnējo projektējumu. Saskaņā ar būvniecības noteikumiem Latvijā nevienu māju nav iespējams uzbūvēt bez projekta. Diemžēl nez kāpēc cilvēkiem liekas, ka Informāciju tehnoloģijās tas nav spēkā un ka ir iespējams ietaupīt laiku un resursus projektējumu neveicot. Patiesībā vismaz ilgtermiņā tas ir daudz dārgāk. Jo tuvāk projekta sākumam tiek pieļauta kļūda, jo dārgāk tā izmaksās. Ja datu modelis ir nekorekts jau pašā sākumā, neviens pasaules ģeniālākais programmētājs nespēs panākt, lai jūsu aplikācija darbojas pieņemamā ātrumā un arī paši “niknākie dzelži” tur būs bezspēcīgi.

Turpmākā lasāmviela:
Loģiskā modelēšana:

1. Data Model Patterns: Conventions of Thought by David C. Hay, ISBN: 0932633293;

2. The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises by Len Silverston, ISBN: 0471380237;

3. Requirements Analysis: From Business Views to Architecture by David C. Hay, ISBN: 0130282286;

4. http://www.phlonx.com/resources/nf3/ – Ieskats datubāzes normalizācijā;

5.http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:6692296628899 – piemērs kā nevajag darīt;

6. Oracle Insights Tales of the Oak Table, Chapter 11 Bad CaRMa by Tim Gorman, ISBN: 1590593871;

7. http://www.learndatamodeling.com/ – īss pārskatas par datu modelēšanu.

8. http://www.tdan.com/edatt1_archive.htm – rakstu arhīvs. Var meklēt piemēram David Hay; viņam ir vairāki vērtīgi raksti šajā vietnē.

9. ievads datu modelēšanā un relāciju modelēšanā.

 Fiziskā modelēšana Oraclei:

1. Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions by Thomas Kyte, ISBN: 1590595300;

2. Effective Oracle by Design (Osborne ORACLE Press Series) by Thomas Kyte, ISBN: 0072230657;

3. Oracle Insights Tales of the Oak Table, Chapter 10 Design Disasters by Jonathan Lewis, ISBN: 1590593871;

4. http://asktom.oracle.com – Thomas Kyte atbildes uz daudziem un dažādiem jautājumiem.

 

Raksta otrā daļa, trešā daļa.


Oracle problēmu risināšana

Oktobris 10, 2007

Agrāk vai vēlāk darbojoties ar Oracle ikviens sastopas ar kādu problēmu, ko nav iespējams atrisināt paša spēkiem. Tālākie scenāriji ir vairāki:

  1. Nedarīt neko, pacelt rokas un laisties dibenā. Problēma – jūsu darba devējs ar laiku var sākt kļūt neapmierināts un problēma tā arī paliek neatrisināta 😉
  2. Jautāt kolēģiem. Notiekti krietni labāka doma kā iepriekšējā, bet ir pāris mīnusu tik un tā – ar laiku kolēģim var apnikt un var, protams, gadīties, ka neviena zinoša kolēģa nav.
  3. Pa taisno bez domāšanas atvērt kādu forumu vai e-pasta listi un bliezt iekšā jautājumu un iespējams saņemt gatavu atbildi no kāda laba cilvēka. Mīnusi – nav nekādas garantijas, ka atbilde (vispār) tiks saņemta un gatavs risinājums parasti nepalielina esošo zināšanu krājumu.

Es ieteiktu izmantot 4. veidu, kas manuprāt ir vissakarīgākais no visiem, jo:

  • māca kā atrast informāciju,
  • palielina esošo zināšanu bāzi,
  • pārlieku nenoslogo un “nebesī” citus cilvēkus.

Tātad pirmais solis ir izmantot Oracle dokumentāciju. Ir divi veidi kā pie tās tikt:

  • mana iemīļotā lapa ar indeksu uz Datu bāzes (un ne tikai) dokumentāciju dažādām versijām. Izvēlamies vajadzīgo DB versiju un aidā!
  • krietni nopietnāks indekss ar norādēm uz vairāk versijām un produktiem, bet man parasti nav nepieciešams.

Kā strādāt ar Oracle dokumentāciju?
10g versija satur vairāk kā 400 dokumentus un protams neviens mirstīgais nav spējīgs caurskatīt tos visus. Taču bez panikas – galvenais ir atcerēties dažus svarīgākos dokumentus:

  • Concepts – apraksts par Oracle uzbūvi, arhitektūru, atmiņu, failu sistēmu, transakcijām, shēmas objektiem, drošību, datu integritāti u.c. galvenajiem konceptiem. Ikvienam, kas gatavojas nopietni darboties ar Oracle datu bāzi būtu pienākums šo dokumentu vismaz pārskatīt.
  • SQL Reference – ja ir problēmas ar konkrēta SQL teikuma sintaksi vai nav skaidras šī SQL teikuma iespējas, tad tas ir īstais dokuments. Tāpat tajā ir informācija par visiem iebūvētajiem datu tipiem, hintiem, pseidokolonām, operatoriem un funkcijām. Saturs šim dokumentam nebūt nav tik liels, lai tam nevarētu nepilnas minūtes laikā pārskriet pāri un ar to iepazīties.
  • Application Developer’s Guide – Fundamentals – Vispārējas vadlīnijas db un uz tās balstīta produkta izstrādē, paskaidroti piemēram datu integritātes ierobežojumi, SQL procesēšana, datu tipu izvēle utml lietas.
  • PL/SQL User’s Guide and Reference – ja plānojat kaut ko programmēt izmantojot PL/SQLu – obligāti ieteicamā literatūra.
  • Performance Tuning Guide – izstrādes un konfigurēšanas vadlīnijas, lai jūsu izveidotā aplikācija strādātu saprātīgā ātrumā arī tad, kad to lietos vairāk kā viens lietotājs.
  • Reference – visi inicializācijas parametri un datu vārdnīcas skatījumi.
  • 2 Day DBA un Administrator’s Guide – īss un pilnīgs pārskats par Oracle datubāzes administrēšanu un uzturēšanu, ieskaitot instalēšanu, konfigurēšanu, rezerves kopiju veidošanu un atjaunošanu, skaņošanu utt.
  • New Features Guide – lietas, kas nākušas klāt kopš iepriekšējās versijas.
  • Licensing Information – informācija par Oracle db licencēšanas mehānismu.
  • Data Warehousing Guide – dažādas ļoti interesantas lietas, kas attiecas ne tikai uz datu noliktavām – particionēšana, materializētie skatījumi, analītiskās funkcijas, paralēlā izpilde utt.

Ja nu gadījumā ar dokumentāciju vien cauri netiekat vai nu tāpēc, ka nevarat atrast kur meklēt jūsu problēmas atrisinājumu, vai arī tāpēc, ka problēmas atrisinājums dokumentācijā tiešām nav atrodams, tad nākošais solis ir doties uz lapu ko uztur vīrs vārdā Thomas Kyte. Šeit ir ļoti daudz populāru jautājumu un ļoti daudz vērtīgu atbilžu, kaut vai piemēram, kā Oraclē var lapoties cauri rezultātam un var tikai apbrīnot kā viens cilvēks spēj atbildēt uz tik daudz jautājumiem un pa vidu vēl sarakstīt vērtīgas grāmatas…

Ja nu tomēr izrādās, ka jūsu jautājums ir absolūti unikāls, jauns, īpašs un nekad vēl neredzēts, tad trešajā solī varat doties uz Oracle forumiem izvēlēties atbilstošu kategoriju, drošības pēc pameklēt – varbūt tomēr kāds jūsu superunikālo jautājumu jau ir atbildējis – un, ja ne, tad uzdot foruma lietotājiem mīklu. Kas zina, viss var gadīties un viņi rod jūsu mīklai atbildi 😉

Tātad šai trīssoļu kombinācijai es neminu vēl 2 acīmredzamas lietas:

  • Lietojiet google, cilvēka labāko draugu.
  • Atcerieties, ka Oracle piedāvā arī oficiālu uzturēšanu un ir tāda lapa, kas gan ir pieejama tikai tad, ja jums ir spēkā esošs uzturēšanas līgums.