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.

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

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?

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

Šī 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.

• Ar 1. Dokumentācijas neesamība un 2. Vienīgā zinošā persona nesen mainīja darbu jūs nezināt KO mainīt;
• Ar 3. Sākotnējā projektējuma trūkums un 4. Nosaukumu vadlīniju trūkums jūs nezināt KĀ mainīt;
• Ar 5. Visa loģika aplikācijā / datubāzē ir tikai tabulas un 7.1. Datu integritātes ierobežojumu trūkums jūs nevarat būt droši, ka mazākā jūsu izmaiņa neizsauks neprognozējamas izmaiņas pavisam citur un vienkārši nenobeigs jūsu sistēmu.

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

Šī 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.