Ovim kratkim postom želio bih otkloniti jedan nesporazum u vezi sa analizom AWR baza podataka koje rade na Oracle Exadata. Gotovo 10 godina stalno se suočavam s pitanjem: kakav je doprinos Exadata softvera produktivnosti? Ili koristeći novonastale riječi: koliko je “stručan” rad određene baze podataka?
Često se na ovo ispravno pitanje, po mom mišljenju, daje netačan odgovor u odnosu na AWR statistiku. Predstavlja metodu sistemskog čekanja, koja vrijeme odgovora tretira kao zbir radnog vremena procesora (DB CPU) i vremena čekanja različitih klasa.
Sa pojavom Exadata, specifična sistemska očekivanja vezana za rad Exadata softvera pojavila su se u AWR statistici. U pravilu, nazivi takvih čekanja počinju riječju "ćelija" (Exadata Storage server se zove ćelija), od kojih su najčešća čekanja sa izgovorenim nazivima "cell smart table scan", "cell multiblock fizičko čitanje" i „fizičko čitanje jednog bloka ćelije“.
U većini slučajeva, udio takvih Exadata čekanja u ukupnom vremenu odgovora je mali, pa stoga oni čak ni ne spadaju u Top10 Foreground Events prema ukupnom vremenu čekanja (u ovom slučaju, trebate ih potražiti u Foreground Wait Sekcija događaja). Uz velike poteškoće, pronašli smo primjer dnevnog AWR-a od naših kupaca, u kojem su očekivanja Exadata uključena u Top10 odjeljak i ukupno su iznosila oko 5%:
događaj
Čeka
Ukupno vrijeme čekanja (sek)
Avg Wait
%DB vrijeme
Čekaj razred
DB CPU
115.2K
70.4
SQL*Net više podataka od dblink-a
670,196
5471.5
8.16ms
3.3
mreža
fizičko čitanje jednog bloka ćelije
5,661,452
3827.6
676.07us
2.3
Korisnički I/O
Sync ASM rebalans
4,350,012
3481.3
800.30us
2.1
drugi
fizičko čitanje više blokova ćelija
759,885
2252
2.96ms
1.4
Korisnički I/O
čitanje direktnog puta
374,368
1811.3
4.84ms
1.1
Korisnički I/O
SQL*Net poruka od dblink-a
7,983
1725
216.08ms
1.1
mreža
cell smart table skeniranje
1,007,520
1260.7
1.25ms
0.8
Korisnički I/O
direktan put očitavanje temp
520,211
808.4
1.55ms
0.5
Korisnički I/O
enq: TM - spor
652
795.8
1220.55ms
0.5
aplikacija
Sljedeći zaključci se često izvode iz takve AWR statistike:
1. Doprinos Exadata magije performansama baze podataka nije visok – ne prelazi 5%, a baza podataka se slabo „eksadatizira“.
2. Ako se takva baza podataka prenese sa Exadata na klasičnu arhitekturu „server + niz“, tada se performanse neće mnogo promijeniti. Jer čak i ako se ispostavi da je ovaj niz tri puta sporiji od Exadata sistema za skladištenje (što je teško moguće za moderne All Flash nizove), onda množenjem 5% sa tri dobijamo povećanje udjela I/O čekanja na 15% - baza podataka će ovo sigurno preživjeti!
Oba ova zaključka su netačna, štoviše, iskrivljuju razumijevanje ideje koja stoji iza Exadata softvera. Exadata ne pruža samo brzi I/O, već funkcioniše fundamentalno drugačije u poređenju sa klasičnom arhitekturom server + niz. Ako je operacija baze podataka zaista “prilagođena”, onda se SQL logika prenosi u sistem skladištenja. Storage serveri, zahvaljujući nizu posebnih mehanizama (prvenstveno Exadata Storage Indexes, ali ne samo), sami pronalaze potrebne podatke i šalju DB serverima. Oni to rade prilično efikasno, tako da je udio tipičnih Exadata čekanja u ukupnom vremenu odgovora mali.
Kako će se ovo udio promijeniti izvan Exadata? Kako će to uticati na performanse baze podataka u cjelini? Testiranje će najbolje odgovoriti na ova pitanja. Na primjer, čekanje na "skeniranje pametne tablice ćelije" izvan Exadata može se pretvoriti u toliko teško skeniranje tablice da I/O zauzima cijelo vrijeme odgovora i performanse se dramatično smanjuju. Zato je pogrešno, kada se analizira AWR, smatrati ukupan procenat očekivanja Exadata kao doprinos njegove magije performansama, a još više koristiti ovaj procenat za predviđanje performansi izvan Exadata. Da biste razumjeli koliko je “precizan” rad baze podataka, potrebno je da proučite AWR statistiku u odjeljku “Statistike aktivnosti instance” (postoji mnogo statistika sa nazivima koji su sami po sebi razumljivi) i uporedite ih međusobno.
A da biste razumjeli kako će se osjećati baza podataka izvan Exadata, najbolje je napraviti klon baze podataka iz sigurnosne kopije na ciljnoj arhitekturi i analizirati performanse ovog klona pod opterećenjem. Vlasnici Exadata, po pravilu, imaju tu mogućnost.
Autor: Alexey Struchenko, šef odjela baze podataka Jet Infosystems
izvor: www.habr.com