S tem manjšim prispevkom bi rad razjasnil eno zmedo, povezano z analizo AWR baz podatkov, ki delujejo na Oracle Exadata. Že skoraj 10 let se neprekinjeno srečujem z vprašanjem: kakšen je prispevek Exadata Software k zmogljivosti? Ali z uporabo novotvorjenih izrazov: kako zelo 'exadata' je delo te ali one baze podatkov?
Na to pravilno vprašanje se pogosto, po mojem mnenju, odgovarja napačno s sklicem na statistiko AWR. V njej je prikazana metoda sistemskih čakanj, ki razume čas odziva kot vsoto časa delovanja procesorjev (DB CPU) in časa čakanja različnih razredov.
S pojavom Exadata so se v statistiki AWR pojavila specifična sistemska čakanja, povezana z delovanjem Exadata Software. Navadno se imena takih čakanj začnejo s besedo “cell” (cell se imenuje Exadata Storage strežnik), najpogosteje pa se srečujemo s čakanji z izrazitimi imeni, kot so “cell smart table scan”, “cell multiblock physical read” in “cell single block physical read”.
V večini primerov delež takih Exadata čakanj v skupnem času odziva ni velik, zato se niti ne uvrstijo v odsek Top10 Foreground Events by Total Wait Time (v tem primeru jih je treba iskati v razdelku Foreground Wait Events). Z velikimi težavami smo pri naših strankah odkrili primer dnevne AWR, v katerem so se Exadata čakanja uvrstila v odsek Top10 in skupaj predstavljala približno 5%:
Dogodek
Čakanja
Skupni čas čakanja (sekunde)
Povprečno čakanje
% DB časa
Razred čakanja
DB CPU
115.2K
70.4
SQL*Net več podatkov iz dblink
670,196
5471.5
8.16ms
3.3
Mreža
cell enojno blokovno fizično branje
5,661,452
3827.6
676.07us
2.3
Uporabniški I/O
Sinhrono ASM balansiranje
4,350,012
3481.3
800.30us
2.1
Drugo
cell multiblock fizično branje
759,885
2252
2.96ms
1.4
Uporabniški I/O
direktno pot branje
374,368
1811.3
4.84ms
1.1
Uporabniški I/O
SQL*Net sporočilo iz dblink
7,983
1725
216.08ms
1.1
Mreža
cell pametno branje tabel
1,007,520
1260.7
1.25ms
0.8
Uporabniški I/O
direktno pot branje temp
520,211
808.4
1.55ms
0.5
Uporabniški I/O
enq: TM — vsebina
652
795.8
1220.55ms
0.5
Aplikacija
Iz takšne AWR statistike pogosto potegnejo take zaključke:
1. Prispevek magije Exadata k zmogljivosti baze podatkov ni velik — ne presega 5%, in baza podatkov je slabo 'exadata'.
2. Če takšno bazo prenesemo z Exadata na klasično arhitekturo 'strežnik + sistem', se zmogljivost ne bo bistveno spremenila. Kajti tudi če je ta sistem tri krat počasnejši od sistema shranjevanja Exadata (kar je malo verjetno za sodobne All Flash sisteme), bi ob množenju 5% s tremi pridobili povečanje deleža čakanj vhod/izhod na 15% — to baza podatkov gotovo prenese!
Oba ta izhoda sta netočna, celo več, zmedeta razumevanje ideje, ki je vgrajena v Exadata Software. Exadata ne zagotavlja samo hitrega vnosa in izhoda, deluje bistveno drugače v primerjavi s klasično arhitekturo „strežnik + shranjevanje“. Če se baza podatkov res „ekzadati“ — se SQL-logika prenese na sistem shranjevanja. Shranjevanje servere z zahvaljujoč vrsti posebnih mehanizmov (predvsem Exadata Storage Indexes, a ne samo to) sama najde potrebne podatke in jih pošlje strežnikom DB. To počnejo dovolj učinkovito, zato je delež značilnih Exadata-čakanj v skupnem času odziva majhen.
Kako se bo ta delež spremenil zunaj Exadata? Kako bo to vplivalo na zmogljivost baze podatkov kot celote? Najboljši odgovor na ta vprašanja bo dala testiranja. Na primer, čakanje na „cell smart table scan“ zunaj Exadata se lahko spremeni v tako težak Table Full Scan, da bo vnos in izhod vzel ves čas odziva in zmogljivost se bo drastično poslabšala. Zato je napačno pri analizi AWR upoštevati skupni odstotek čakanj Exadata kot prispevek njene magije k zmogljivosti in še posebej uporabiti ta odstotek za napovedovanje zmogljivosti zunaj Exadata. Da bi razumeli, kako zelo „ekzadati“ je delo baze, je treba preučiti statistike AWR sekcije “Instance Activity Stats” (tja je veliko statistik s pomenljivimi imeni) in jih med seboj primerjati.
Da bi razumeli, kako bo baza podatkov delovala zunaj Exadata, je najbolje ustvariti klon baze iz varnostne kopije na ciljni arhitekturi in analizirati zmogljivost tega klona pod obremenitvijo. Takšno priložnost imajo običajno lastniki Exadata.
Avtor: Aleksiej Strujenko, vodja oddelka za Baze podatkov v „Infososistemah Jet“
Izvor: habr.com
