Ar šo īso ziņu es vēlos kliedēt vienu pārpratumu saistībā ar AWR datu bāzu analīzi, kas darbojas Oracle Exadata. Gandrīz 10 gadus esmu pastāvīgi saskāries ar jautājumu: kāds ir Exadata programmatūras ieguldījums produktivitātē? Vai izmantojot jaunradītus vārdus: cik “eksperts” ir konkrētas datu bāzes darbs?
Bieži vien uz šo pareizo jautājumu, manuprāt, tiek sniegta nepareiza atbilde, atsaucoties uz AWR statistiku. Tas parāda sistēmas gaidīšanas metodi, kas uztver reakcijas laiku kā procesoru (DB CPU) darbības laika un dažādu klašu gaidīšanas laika summu.
Līdz ar Exadata parādīšanos AWR statistikā parādījās īpašas sistēmas cerības, kas saistītas ar Exadata programmatūras darbību. Parasti šādu gaidīšanas nosaukumi sākas ar vārdu “šūna” (Exadata Storage serveri sauc par šūnu), no kuriem visizplatītākie ir gaidīšanas ar pašsaprotamiem nosaukumiem “šūnu viedās tabulas skenēšana”, “šūnu daudzbloki fiziskā lasīšana” un “šūnas viena bloka fiziskā lasīšana”.
Vairumā gadījumu šādu Exadata gaidīšanas gadījumu īpatsvars kopējā atbildes laikā ir neliels, un tāpēc tie pat neietilpst sadaļā Top10 priekšplāna notikumi pēc kopējā gaidīšanas laika (šajā gadījumā tie jāmeklē priekšplāna gaidīšanas laikā Notikumu sadaļa). Ar lielām grūtībām mēs atradām mūsu klientu ikdienas AWR piemēru, kurā Exadata cerības tika iekļautas Top10 sadaļā un kopā sastādīja aptuveni 5%:
notikums
Gaida
Kopējais gaidīšanas laiks (s)
Vid. pagaidiet
%DB laiks
Pagaidiet klase
DB centrālais procesors
115.2K
70.4
SQL*Neto vairāk datu no dblink
670,196
5471.5
8.16ms
3.3
tīkls
šūnas viena bloka fiziskā lasīšana
5,661,452
3827.6
676.07us
2.3
Lietotāja I/O
Sinhronizēt ASM līdzsvarošanu
4,350,012
3481.3
800.30us
2.1
cits
šūnu vairāku bloku fiziskā lasīšana
759,885
2252
2.96ms
1.4
Lietotāja I/O
tiešā ceļa lasīšana
374,368
1811.3
4.84ms
1.1
Lietotāja I/O
SQL*Net ziņojums no dblink
7,983
1725
216.08ms
1.1
tīkls
šūnu viedā tabulas skenēšana
1,007,520
1260.7
1.25ms
0.8
Lietotāja I/O
tiešais ceļš nolasīšanas temp
520,211
808.4
1.55ms
0.5
Lietotāja I/O
enq: TM - strīds
652
795.8
1220.55ms
0.5
iesniegums
No šādas AWR statistikas bieži tiek izdarīti šādi secinājumi:
1. Exadata maģijas ieguldījums datu bāzes veiktspējā nav liels - tas nepārsniedz 5%, un datubāze slikti “eksadatizē”.
2. Ja šādu datu bāzi no Exadata pārnes uz klasisko “serveris + masīvs” arhitektūru, tad veiktspēja īpaši nemainīsies. Jo pat tad, ja šis masīvs izrādās trīs reizes lēnāks par Exadata glabāšanas sistēmu (kas diez vai ir iespējams mūsdienu All Flash masīviem), tad reizinot 5% ar trīs, iegūstam I/O gaidu īpatsvara pieaugumu līdz 15%. - datubāze to noteikti izdzīvos!
Abi šie secinājumi ir neprecīzi, turklāt tie deformē izpratni par Exadata Software ideju. Exadata ne tikai nodrošina ātru I/O, bet arī darbojas būtiski savādāk, salīdzinot ar klasisko servera + masīva arhitektūru. Ja datu bāzes darbība ir patiesi “pielāgota”, SQL loģika tiek pārsūtīta uz uzglabāšanas sistēmu. Krātuves serveri, pateicoties vairākiem īpašiem mehānismiem (galvenokārt Exadata Storage Indexes, bet ne tikai), paši atrod nepieciešamos datus un nosūta DB uz serveriem. Viņi to dara diezgan efektīvi, tāpēc tipisko Exadata gaidīšanas gadījumu īpatsvars kopējā atbildes laikā ir neliels.
Kā šī kopīgošana mainīsies ārpus Exadata? Kā tas ietekmēs datubāzes darbību kopumā? Testēšana vislabāk atbildēs uz šiem jautājumiem. Piemēram, gaidot “šūnu viedās tabulas skenēšanu” ārpus Exadata, tas var pārvērsties par tik smagu pilnas tabulas skenēšanu, ka I/O aizņem visu reakcijas laiku un veiktspēja krasi pasliktinās. Tāpēc ir nepareizi, analizējot AWR, uzskatīt Exadata gaidu kopējo procentuālo daļu kā tās maģisko ieguldījumu veiktspējā, un vēl jo vairāk izmantot šo procentuālo daļu, lai prognozētu veiktspēju ārpus Exadata. Lai saprastu, cik “precīzs” ir datu bāzes darbs, jāizpēta sadaļas “Instance Activity Stats” AWR statistika (ir ļoti daudz statistikas ar pašsaprotamiem nosaukumiem) un jāsalīdzina tā savā starpā.
Un, lai saprastu, kā jutīsies datu bāze ārpus Exadata, vislabāk ir izveidot datu bāzes klonu no dublējuma mērķa arhitektūrā un analizēt šī klona veiktspēju slodzes laikā. Exadata īpašniekiem, kā likums, šī iespēja ir.
Autors: Aleksejs Stručenko, Jet Infosystems datu bāzes nodaļas vadītājs
Avots: www.habr.com