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.
Datubāzes 