Kā izvēlēties datubāzi

Novembris 21, 2007

Atruna – virsrakstā un arī tālāk tekstā minētais vārds “datubāze” šajā rakstā ir domāts kā Datu bāzu vadības sistēma (DBVS), ko piedāvā kāds no to izstrādātājiem.

Es centīšos būt pēc iespējas objektīvs, cik nu tas vispār iespējams ievērojot manu iepriekšējo pieredzi. Lai maksimāli izvairītos no noteiktiem mājieniem, es vismaz rakstā nevienu konkrētu datu bāzu vadības sistēmas vārdu labāk nenosaukšu ;)

Tātad jums ir jauns projekts un jūs varat vismaz daļēji iespaidot to kādu datu bāzi jūsu projektā izvēlēties. Kādi būtu galvenie kritēriji, lai izdarītu izvēli, kuru vēlāk nevajadzētu nožēlot, un kas šai gadījumā svarīgāk – ilgtermiņā samazināt $$, € vai Ls, kas tiks ņemti no jūsu pašu vai jūsu atbildībā esošās naudas? Aplūkosim manuprāt svarīgākos kritērijus šai procesā.

1. Visas datubāzes nav vienādas

Pirmais visā šajā izvēles procesā gan nav konkrēts kritērijs. Pats pirmais un pats svarīgākais šai procesā ir saprast uzstādījumu, ka datu bāzu vadības sistēmas gluži tāpat kā mašīnas ir ārkārtīgi dažādas sākot no mums labi zināmā Zaporožeca līdz pat Ferrari, Maybach un tādiem monstriem, kādi nesen Rīgā paralizēja kādu brīdi Salu tiltu, un Latvijā nemaz nav redzēti. Tieši tāpat ir ar datubāzēm. Jūs nevarat cerēt, ka ar zaporožecu jūs jutīsieties komfortabli vai varēsiet aizvest lielu kravu grants. Ja jūs mēģināsiet burtiski pielietot to pašu ātruma pārslēgšanas metodi mašīnai ar automātisko ātrumkārbu, kādu jūs iemācījāties mašīnai ar manuālo ātrumkārbu, galarezultātā jūs varat nolauzt ātrumkloķi vai sabeigt ātrumkārbu. Analoģiski ar datubāzēm – tās izstrādā dažādas kompānijas un to arhitektūra atšķiras – un jūs nevarat tieši tās pašas labās un pareizās metodes, kas derēja DBVS X, izmantot nemainīti arī visās citās DBVS.

2. Apzināties savas pašreizējās prasības, bet tomēr domāt arī par nākotni

Šis ir kritērijs, kam visnopietnāk būtu jāietekmē jūsu izvēli. Jums ir jānoskaidro jūsu funkcionālās un nefunkcionālās prasības pret potenciālo galaproduktu un jāizvēlas datubāze, kas atbildīs šīm jūsu prasībām. Prasības, kam noteikti būtu jāpievērš uzmanība ir vismaz šādas:
1) datu apjoms un datu veids (tekstuāli, bināri, ģeogrāfiski u.c. specifiski dati);
2) potenciālais vienlaicīgo lietotāju daudzums;
3) potenciālā pieejamība, t.i. cik daudz gadā jūs varat atļauties situācijas, kad datubāze nav pieejama;
4) mērogojamība – kas notiks, kad jūsu datu apjoms un lietotāju skaits augs;
5) drošība, cik svarīgas jums ir tādas lietas kā datu drošība, datu šifrēšana, lietotāju administrēšana, datu pieejamība atkarībā no tiesībām;
6) pārvaldība un administrēšana, cik viegli un “lietotājam draudzīgi” jūs gribat tikt galā ar datu bāzes uzraudzīšanu un pārvaldīšanu;
7) kādas gudras un modernas papildus lietas jūs gribētu sagaidīt no datu bāzes.
Kā jau parasti savas vēlmes vajadzētu sabalansēt ar iespējām un reālajām vajadzībām. Protams, ir nepieciešams skatīties mazliet nākotnē un izsacīt prasības, kas arī rīt un parīt nodrošinās jūsu datubāzes veiksmīgu darbību, bet tai pašā laikā nevajadzētu orientēties uz maksimāli iespējamo 0.01% ticamo scenāriju un visas prasības balstīt uz to. Daži piemēri, kas lielā mērā atspoguļo manu reālo dzīves pieredzi :) Vajadzētu vienmēr pārliecināties, vai tiešām jums ir reāli nepieciešama 99,9% pieejamība (kas nozīmē nepieejamību 8.76 stundas gadā), ja tai pašā laikā naktīs ar jūsu sistēmu strādā pāris lietotāji, kuri mierīgi var paciesties kādu nakti līdz rītam vai mežonīga drošība, ja operatoram alga ir 200 Ls uz rokas un viņam ir pieejami visi dati. Jāatceras, ka, piemēram, pieejamība ir ļoti komplekss problēmu kopums un tas, ka datubāze strādās un būs pieejama lokāli, nenozīmē, ka tā būs pieejama jūsu klientiem tīkla atteices gadījumā. Otrs piemērs – ir vērts atcerēties arī par tādiem sīkumiem, kā rezerves kondicionieriem, jo, ja jūsu datu centrā karstā vasaras dienā pārstās strādāt esošais(-ie), tad nekāda dzelžu konfigurācija, datubāzes spoguļošana un klāsterēšana, atsevišķi dīzeļģeneratori un Dievs vien zina kas vēl nelīdzēs :)

3. Ņemiet vērā savu iepriekšējo pieredzi darbā ar datu bāzēm

Noteikti ņemiet vērā savu iepriekšējo pieredzi un zināšanas darbā ar datu bāzēm. Kā jau minēju, tās ir atšķirīgas. Ja jūs izvēlēsieties jums nepazīstamu vai mazpazīstamu datu bāzi, noteikti būs nepieciešams laiks, lai to iepazītu, lai iepazītu tās atbalstītos rīkus, noskaidrotu, ko ar to var panākt un ko nevar, uzzinātu par tās vājajām vietām, ko parasti jau neviens tā vis neafišē. Iespējams jūsu darbiniekiem vajadzēs kursus (papildus jau esošajam normālajam kursu grafikam, kurš jūs organizācijā, protams, ir, vai ne?), kuri ne tikai paši maksās, bet arī tai laikā jūsu darbinieki nepildīs ikdienas darbu.

4. Esošā situācija (sadarbība ar esošajām sistēmām) – jauna pirmā dbvs vai citas jau priekšā

Ir liela atšķirība, vai šis jūsu projekts ir radīts tukšā vietā, kur nekā priekšā nav – tādā gadījumā jums ir daudz lielāka izvēles brīvība -, vai arī jums jau ir N citas datubāzes, ar ko jūsējai būs jāsadarbojas. Skaidrs, ka katrs datu bāzu izstrādātājs ir pacenties, lai ar šī paša izstrādātāja datu bāzēm “sarunāšanās” notiktu daudz vieglāk, nekā ar konkurentiem. Otrs iemesls, kāpēc nopietni pārdomāt jau esošās datubāzes izmantošanu, ir organizācijā esošā pieredze darbā ar datubāzi, pieredze darbā ar datubāzes izstrādātāja lietotāju atbalstu, ko kopsummā varētu nosaukt par esošās zināšanu bāzes izmantošanu. Jaunas lietas parasti ir riskantākas nekā vecās.

5. Novērtējiet pieejamo darba spēka tirgu Latvijā attiecībā uz potenciālo izvēlēto DBVS

Latvija nav liela. Latvijā pieejamais IT speciālistu loks ir vēl mazāks. Ja jūs nopirksiet kādu nevienam nezināma izstrādātāja mašīnas modeli, reti kāds serviss uzņemsies tādu labot vispār, savukārt, ja kāds būs gatavs to darīt, tad rodas jautājums, vai viņš to nedarīs tāpēc, ka nevienu parastu mašīnu šim servisam neuztic? Līdzīgi ir ar datubāzēm – pirms galīgās izvēles noskaidrojiet cik un vai vispār Latvijā ir kāds cilvēks, kas problēmu gadījumā ar šo datubāzi spēs tikt galā. Būs ļoti nepatīkami, ja jums nāksies maksāt pamatīgu naudu dienā kādam, kas savedīs jūsu unikālo datubāzi darba kārtībā, bet vēl daudz nepatīkamāk būs, ja jūs vienkārši nevienu nevarēsiet atrast, jo visi esošie būs pārāk aizņemti vai arī tādu vienkārši nebūs.

Tieši tas pats ir arī par normālu darba procesu izmantojot jūs izvēlēto datubāzi. Visu datu bāzu administratoriem un izstrādātājiem nemaksā vienādu algu. Katrā konkrētā laika posmā iespējams, ka tendences ir mainīgas, bet parasti ir tā, ka ir vieglāk dabūt izstrādātājus datubāzei X par zināmu algas apjomu, nekā datubāzei Y par to pašu algu. Darba spēka pieejamība tieši iespaido algas, tā tieši iespaido to, vai jums vispār izdosies un par kādu cenu vajadzības gadījumā iegādāties darbiniekus no kādas citas iestādes. Pieejamība nodrošina jūs ar lielākām vai mazākām manevra iespējām gadījumā, ja kāds darbinieks nerāda gluži to sniegumu, ko jūs no viņa esiet gaidījuši.

Nelielu ieskatu par potenciālu darba spēka pieejamību attiecībā uz darbaspēka pieejamību varat redzēt šeit – aptauja par popularākajām DBVS Latvijā.

6. Novērtējiet iespējamās tiešās izmaksas

6.1. Licences

Šī ir tā lieta, par ko visi uztraucas, smalki rēķina un salīdzina, ka lūk datubāze X ir lētāka nekā Y. Patiesībā šis faktors ir tikai viens no vairākiem, kas tieši ietekmē cenu, nemaz nerunājot par visiem tiem, kas cenu ietekmē netieši. Runājot par licenču cenām ir jāatceras, ka:

  • datubāzēm mēdz būt dažādi licencēšanas modeļi, piemēram, pēc lietotāju skaita, pēc procesoru skaita, pēc operatīvās atmiņas lieluma;
  • lai ko arī neteiktu oficiālā datubāzes izstrādātāja lapa, iespējams, ka ar pārdevēju jūs varat vienoties par zemāku cenu, jo sevišķi, ja tā nav jūsu ne pirmā, ne vienīgā šī izstrādātāja datubāze;
  • lielākajām datubāzēm mēdz būt dažādas versijas, piemēram, enterprise un standard, kur ir ļoti būtiskas atšķirības to licenču cenā. Pārdomājiet, vai tiešām jums ir nepieciešama enterprise versija (kas parasti ir tā, uz ko visi pirmajā brīdī orientējas), jo enterprise versijas parasti ir domātas ASV tirgum un Latvijā vispār nav lielu uzņēmumu skatoties ASV mērogā, līdz ar to iespējams, ka jums pilnīgi pietiek ar standard versiju. Vēl ļoti nozīmīgs faktors – atcerieties pirmo punktu – datubāzes ir ļoti dažādas tāpēc, kas vienai varbūt ir enterprise versija, citai ir tikai standard. Līdz ar to nekļūstiet maldināti un nekad mehāniski nesalīdziniet versiju cenas, nepainteresējoties, kāda piedāvātā funkcionalitāte katrā ir iekšā.

6.2. Atbalsts

Noskaidrojiet, cik maksā atbalsts un kas tajā ietilpst. Parasti atbalsta līmeņi mēdz būt dažādi, ar attiecīgi dažādām cenām un piedāvātajām iespējām.

6.3. Papildus iespējas

Mēdz būt papildus iespējas, kas neietilpst nevienā no piedāvātajām versijām, arī enterprise. Tas nozīmē, ka jūs maksāsiet gan par enterprise/standard versiju, gan par papildus funkcionalitāti. Šis nu ir tas gadījums, kad ļoti skaidri un ļoti tieši ir jānovērtē vai attiecīgā papildus funkcionalitāte tik tiešām ir nepieciešama, kā arī šis var būt labs gadījums, kad pārdevējam tomēr prasīt kādu atlaidi :)

6.4. Operētājsistēmas prasības

Dažas datubāzes darbojas tikai uz noteiktām operētājsistēmām. Operētājsistēmas tāpat kā datubāzes mēdz būt dažādas. To izmaksu novērtēšanā var izmantot līdzīgus kritērijus kā šeit uzskaitītajām datubāzēm un ļoti var gadīties, ka tad, kad jums nāksies smalki konfigurēt nepazīstamu operētājsistēmu, jums vairs nemaz nebūs svarīga tās vai citas operētājsistēmas licences cena.

7. Datubāzes atteice

Cik liela ir varbūtība, ka izvēlētā datubāze kādā brīdī tādu vai citādu iemeslu dēļ atteiksies strādāt? Kurš jums to atjaunos? Kāds ir sagaidāmais laiks tās atjaunošanai? Cik daudz naudas jūs vai jūsu klients tai laikā zaudēs/neiegūs?

8. Specifiska industrija

Dažās specifiskās nozarēs ar specifiskām vajadzībām (piemēram, ģeogrāfiskās informācijas sistēmas) jau ir iepriekš noteiktas viena vai vairākas datubāzes, kas tajā parasti tiek izmantotas. Iespējams, ka jūs varat darboties kā celmlauzis un kļūt šai nozarē par pirmo visā pasaulē, kas tajā ievieš datubāzi X, bet tikpat droši vai pat drošāk var būt, ka jūs sastapsieties ar pārāk daudz problēmām šai procesā. Tātad, ja jums ir kaut kādi specifiski dati vai specifisks datu apstrādes veids, ir vērts nopietni interesēties par pieņemto praksi šādu datu apstrādē.

9. Specifisks produkts

Ja jūs izvēlaties kādu jau esošu produktu, kas spēj strādāt ar dažādām datubāzēm, tad vispirmām kārtām pārliecinieties, vai tam nav pārāk spilgti izteiktas šādu produktu negatīvās īpašības. Ja nu jums tomēr nav izvēles vai arī produkta izstrādātājs ir runājis pietiekami pārliecinoši, tad noteikti painteresējieties, vai produktam ir kāda vairāk ieteicamā datubāze salīdzinājumā ar citām. Ja nu jums arī tagad stāsta, ka uz visām datubāzēm produkts darbojas vienlīdz labi, tad tas visdrīzāk nozīmē to, ka vai nu jums nez kāpēc nestāsta taisnību, vai uz visām datubāzēm tas darbojas arī vienlīdz slikti ;) Katrā ziņā tādā gadījumā mēģiniet noskaidrot, kura bija sākotnējā datubāze (visticamāk uz tās strādās vislabāk) vai arī pie esošajiem klientiem painteresējieties, kādas datubāzes šim produktam viņi izmanto un ar kādām problēmām ir sastapušies. Noteikti nenovēlu jums būt pirmajam produkta klientam uz izvēlētās datubāzes ;)

10. Esošā izstrādātāju kopiena, pieejamie info resursi  un popularitāte

Ja vien jums nav iedzimta vēlme būt celmlauzim, tad noteikti ir vērts painteresēties par esošās izstrādātāju kopienas (forumi, e-pasta listes, neformālas lietotāju apvienības, klātienes konferences un semināri) esamību un aktivitāti. Papildus tam painteresējieties, kādi ir pieejami rakstu krājumi, lietotāja/izstrādātāja rokasgrāmatas u.c. interneta resursi, kas grūtā brīdī noteikti noderēs un palīdzēs jums atrisināt radušās problēmas. Jūs visdrīzāk negribiet būt pirmais, kas risina daudzas radušās problēmas, pietiks jau arī ar dažām ;)

11. Nepieciešamā aparatūra

Ir vērts noskaidrot, kāda ir izvēlētās datubāzes rekomendējamā aparatūra un servera parametri (vismaz minimālie). Protams, tas ir ļoti atkarīgs no jūsu plānotā glabājamā datu daudzuma, vienlaicīgajiem lietotājiem un paredzamās noslodzes.

Kopsavilkums

Būsim jau nu godīgi, es neloloju ilūzijas, ka jūs ņemsiet vērā visus augšminētos kritērijus ;) Vēl vairāk – vairumā gadījumu, kad jūs veidojat mazu sistēmiņu 5 lietotājiem, jūs īpaši neinteresē tādas lietas kā augsta pieejamība, mērogojamība utt. BET ar šo rakstu es gribēju uzsvērt pašu galveno lietu – datubāzes cena nav tikai tās licences cena. Nē, nē un vēlreiz nē. Jo lielāku sistēmu jūs būvējat, jo mazāk licences cena iespaido kopējās izmaksas. Ar katru nākošo dzīves mēnesi Latvijā arī šis iespaids mazinās, jo darba spēka izmaksas aizvien palielinās un tie daži simti vai pat tūkstoši dolāru, ko izmaksā licence reizi n gados maz izceļas uz datu bāzes administratora algas fona.

Augšminētie kritēriji lielā mērā var kalpot arī par pamatu TCO aprēķinam, ja vien kāds sadūšojas šo metodi pielietot savā projektā datubāzes izvēlei, vai konkrēta produkta izvēlei, kas darbojas uz kādas datubāzes.


Dažu relāciju datu bāzu uzskaitījums

Novembris 16, 2007

Ja tā paskatās pasaules mērogā, tad ir trīs galvenie tā saucamie slēgtā vai komerciālā koda (closed, commercial source) DBVS produkti, kas dominē datu bāzu vadības sistēmu tirgū – Oracle, DB2 un SQL Server, ko izstrādā attiecīgi Oracle, IBM un Microsoft. Starp tiem un arī starp to klientiem un lietotājiem notiek nemitīga cīņa, kurš tad nu ir labākais, lētākais, izdevīgākais, kurš piedāvā visvairāk dažādu iespēju utt. utjp. Konkurence kā zināms ir laba lieta, un tikai tās rezultātā klientiem, piemēram, ir iespējams lietot šo datubāzu bezmaksas versijas, kurām protams ir lielāki vai mazāki ierobežojumi attiecībā uz datiem un izmantojamiem resursiem. Kāpēc es tās saucu par lielo trijnieku var apskatīties Gartner pētījumā par relāciju datubāzu tirgus daļu (Relational Database Market Share).

Savukārt no atvērtā koda produktiem gribētos atzīmēt divus – MySQL un PostgreSQL, kur pirmā sauklis attiecīgi ir “pasaules vispopulārākā atvērtā koda datubāze” (The world’s most popular open source database), savukārt, otrais sevi pozicionē kā “pasaules visprogresīvākā atvērtā koda datubāze” (The world’s most advanced open source database). Kā to viegli nojaust jau no šiem saukļiem vien, arī šeit notiek nemitīga cīņa par ietekmi un gala rezultātā $$$, kas principā nenāk par sliktu arī mums, kā klientiem. Šajā rakstā ir ļoti īss apskats gan par divām jau minētajām atvērtā koda datubāzēm, gan vēl dažām citām.

Tagad vēlreiz šis pašas 5 manis objektīvi/subjektīvi atlasītās DBVS un otrs saraksts ar dažām citām DBVS.
DB2
MySQL
Oracle
PostgreSQL
SQL Server

Jāatceras, ka abi saraksti kopā nekādā ziņā nav izsmeļoši, tie noteikti nepārskaita ne visas relāciju datubāzes, kā arī iespējams ir dažas citas, kas šeit nav minētas, un ir populārākas, nekā šeit uzskaitītās. Par dažām ir nelielas piezīmes, ja man bija kaut kas ko pateikt.

Adabas
Access -  Microsoft Office sastāvā, tikai uz Windows platformām.
AllBASE
Derby
FileMaker Pro
Firebird
FirstSQL
FoxPro
FrontBase
Greenplum
Informix - vēsturiski kādu brīdi bija viena no lielā trijnieka, tagad to ir pārpircis IBM un visdrīzāk to gaida lēna izmiršana.
Ingres
OpenBase SQL
Pervasive PSQL
SESAM/SQL-Server
SQLBase
SQLite
Sybase Adaptive Server Enterprise - vēsturiski Microsoft SQL Server priekštecis.
TimesTen - datubāze tikai atmiņā (in memory database), var lietot atsevišķi vai kopā ar Oracle.
Teradata - pārsvarā lieto datu noliktavu risinājumiem. Par datu noliktavām un tur izmantotajām DBVS ir labs raksts šeit Magic Quadrant for Data Warehouse Database Management Systems, 2007.

Tālākā lasāmviela


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.


Nedaudz par SQL*Plus

Novembris 6, 2007

Savā pirmajā rakstā nedaudz pastāstīšu par to, kā padarīt darbu ar Oracle SQL*Plus ērtāku, bet pirms tam atbildēšu uz jautājumu – kādēļ tas vispār vajadzīgs?

SQL*Plus ir standarta rīks darbam ar Oracle datu bāzēm un kā tāds, tas ir pieejams visās Oracle klienta un servera instalācijās. Ne vienmēr jums būs pieejams kāds no ierastajiem izstrādes vai administrēšanas rīkiem, tādēļ iesaku apgūt vismaz pašus SQL*Plus pamatus, lai nenonāktu situācijā, kad nepieciešams steidzami veikt kādu darbu, bet, piemēram, PL/SQL Developer instalācijas trūkuma dēļ to nevariet paveikt.

Vairāk par SQL*Plus pamatiem variet atrast šeit:

  • SQL*Plus® Quick Reference
  • SQL*Plus® User’s Guide and Reference
  • Un tagad – pie lietas!

    1) Optimizējam piekļuvi saviem iecienītajiem skriptiem

    Regulāriem SQL*Plus lietotājiem bieži vien ir izveidojusies kolekcija ar skriptiem, kas tiek lietoti ikdienā – procesu, sesiju, ieplānoto darbu, tabulvietu parlūkošanai un administrēšanai. Ja lietojat SQL*Plus Windows versiju (sqlplusw.exe), tad skriptus var izsaukt divos veidos – izmantojot File -> Open izvēlnes vai līdzīgi kā komandrindas SQL*Plus (sqlplus / sqlplus.exe) norādot skripta nosaukumu aiz “@” zīmes, piemēram:

    SQL> @/export/home/san/scripts/oracle/skripts.sql

    Ja izsaucamie SQL skripti atrodas SQL*Plus darba direktorijā, tad nav nepieciešams rakstīt pilnu ceļu skripta nosaukumā:

    SQL> @skripts.sql

    Parasti gan SQL*Plus darba direktorija sakrīt ar konsoles darba direktoriju, bet sqlplusw.exe gadījumā tā ir direktorija, no kuras pēdējo reizi ar File -> Open izvēlnes palīdzību tika izsaukti skripti. Lai padarītu skriptu izsaukšanu pēc iespējas ērtāku, ieteicams izmantot vides mainīgā SQLPATH sniegtās priekšrocības. Ar SQLPATH palīdzību var definēt SQL*Plus darba direktoriju:

    bash$ pwd
    /
    bash$ export SQLPATH=/export/home/san/scripts/oracle/
    bash$ sqlplus ‘/ as sysdba’
    – ar šo komandu tiek izsaukts tas pats skripts.sql,
    – kas atrodas /export/home/san/scripts/oracle/,
    – tikai daudz ērtāk un ātrāk

    SQL> @skripts

    Windows vidē mainīgo SQLPATH var uzstādīt nospiežot Win+Break, aizejot uz Advanced tab’u -> Environment variables -> New …

    Unix/Linux to var ierakstīt savā .profile failā un dzīvot laimīgi.

    2) Modificējam SQL*Plus vidi

    Droši vien katram, kas ikdienā strādā ar vairāk par vienu DB, kādreiz ir sanācis nejauši veikt kādas darbības nepareizajā datu bāzē. Ja tas ir update vai pat delete, tad bēda maza – gandrīz vienmēr var glābt rollback. Ar nodropotiem objektiem jau ir nopietnākas problēmas.
    Šādas kļūdas nevar pilnībā novērst, bet samazināt to iespējamību gan var viegli.

    Šīm mērķim es izmantoju login.sql:

    REM modify sqlplus prompt

    set termout off

    define gname=idle
    column global_name new_value gname

    select lower(user) || ‘@’ ||
    substr(global_name, 1, decode (dot, 0, length(global_name), dot-1)) global_name
    from (select global_name, instr(global_name, ‘.’) dot from global_name);

    set sqlprompt ‘&gname> ‘

    set termout on

    Un rezultāts:

    sqlplus ‘/ as sysdba’
    SQL> — tagad izpildīšu login.sql …
    SQL> @login.sql
    sys@TEST>
    sys@TEST> — kā redzams, SQL> nomainījās pret sys@TEST>,
    sys@TEST> — kas parāda, ka esmu pieslēdzies TEST bāzei kā SYS lietotājs
    sys@TEST>

    Šādi man vienmēr ir redzams, kurai bāzei esmu pieslēdzies un pastāv mazāka iespēja, ka pārslēdzoties starp vairākiem logiem izpildīšu kādu komandu nepareizā sesijā.

    Ja login.sql ievieto direktorijā uz kuru norāda SQLPATH vides mainīgais, tad šīs skripts izpildīsies automātiski pie SQL*Plus palaišanas:

    bash$ sqlplus ‘/ as sysdba’

    SQL*Plus: Release 9.2.0.5.0 – Production on Wed Oct 10 21:37:06 2007

    Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

    Connected to:
    Oracle9i Enterprise Edition Release 9.2.0.5.0 – 64bit Production
    With the Partitioning, OLAP and Oracle Data Mining options
    JServer Release 9.2.0.5.0 – Production

    sys@TEST>

    Un pēdējais komentārs par login.sql – ja nokonfigurējat sistēmu tā, lai šis skripts izpildītos automātiski pie SQL*Plus palaišanas, tad ir ērti to papildināt ar vēl dažiem ierakstiem, piemēram:

    set linesize 200

    column object_name format a30
    column segment_name format a30
    column file_name format a75

    define _editor=vi

    utt.


    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.