S to kratko objavo bi rad razblinil en nesporazum v zvezi z analizo baz podatkov AWR, ki se izvajajo na Oracle Exadata. Že skoraj 10 let se nenehno soočam z vprašanjem: kakšen je prispevek programske opreme Exadata k produktivnosti? Ali z novo skovanko: kako »strokovno« je delo določene podatkovne baze?
Po mojem mnenju je na to pravilno vprašanje pogosto napačno odgovorjeno glede na statistiko AWR. Predstavljena je metoda sistemskega čakanja, ki odzivni čas obravnava kot vsoto časa delovanja procesorjev (DB CPE) in čakalne dobe različnih razredov.
S prihodom Exadate so se v statistiki AWR pojavila posebna sistemska pričakovanja, povezana z delovanjem programske opreme Exadata. Imena takšnih čakanj se praviloma začnejo z besedo »celica« (strežnik Exadata Storage se imenuje celica), med katerimi so najpogostejša čakanja s samoumevnimi imeni »cell smart table scan«, »cell multiblock«. fizično branje« in »fizično branje enega bloka celice«.
V večini primerov je delež takšnih čakanj Exadata v skupnem odzivnem času majhen, zato sploh ne sodijo v razdelek Top10 Foreground Events by Total Wait Time (v tem primeru jih morate iskati v Foreground Wait razdelek o dogodkih). Z veliko težavo smo našli primer dnevnega AWR naših strank, v katerem so bila pričakovanja Exadata vključena v razdelek Top10 in so skupaj znašala približno 5%:
Event
Čaka
Skupni čakalni čas (s)
Povpr. počakajte
%DB časa
Počakajte razred
CPU DB
115.2K
70.4
SQL*Net več podatkov iz dblink
670,196
5471.5
8.16ms
3.3
mreža
fizično branje enega bloka celice
5,661,452
3827.6
676.07us
2.3
Uporabniški V/I
Ponovno uravnoteženje sinhronizacije ASM
4,350,012
3481.3
800.30us
2.1
Ostalo
fizično branje več blokov celic
759,885
2252
2.96ms
1.4
Uporabniški V/I
direktna pot branja
374,368
1811.3
4.84ms
1.1
Uporabniški V/I
Sporočilo SQL*Net od dblink
7,983
1725
216.08ms
1.1
mreža
skeniranje pametne tabele v celici
1,007,520
1260.7
1.25ms
0.8
Uporabniški V/I
direktna pot branja temp
520,211
808.4
1.55ms
0.5
Uporabniški V/I
enq: TM - spor
652
795.8
1220.55ms
0.5
uporaba
Iz takšnih statističnih podatkov AWR se pogosto sklepa na naslednje:
1. Prispevek čarovnije Exadata k zmogljivosti baze podatkov ni visok - ne presega 5%, baza podatkov pa se slabo "eksadatira".
2. Če takšno bazo prenesemo iz Exadate v klasično arhitekturo “server + array”, se zmogljivost ne bo bistveno spremenila. Ker tudi če se izkaže, da je to polje trikrat počasnejše od pomnilniškega sistema Exadata (kar je komaj mogoče za sodobna polja All Flash), potem z množenjem 5 % s tri dobimo povečanje deleža I/O čakanja na 15 %. - baza bo to zagotovo preživela!
Oba zaključka sta netočna, poleg tega izkrivljata razumevanje ideje, ki stoji za programsko opremo Exadata. Exadata ne zagotavlja le hitrega V/I, ampak deluje bistveno drugače v primerjavi s klasično arhitekturo strežnik + polje. Če je delovanje baze podatkov resnično »exadaptirano«, se logika SQL prenese v sistem za shranjevanje. Storage strežniki, zahvaljujoč številnim posebnim mehanizmom (predvsem Exadata Storage Indexes, vendar ne samo), sami najdejo potrebne podatke in pošljejo DB strežnikom. To počnejo precej učinkovito, zato je delež tipičnih čakanj Exadata v skupnem odzivnem času majhen.
Kako se bo ta delež spremenil zunaj Exadate? Kako bo to vplivalo na delovanje baze podatkov kot celote? Testiranje bo najbolje odgovorilo na ta vprašanja. Na primer, čakanje na »skeniranje pametne tabele v celici« zunaj Exadate se lahko spremeni v tako težko popolno skeniranje tabele, da V/I zavzame celoten odzivni čas in zmogljivost se dramatično poslabša. Zato je napačno pri analizi AWR upoštevati skupni odstotek pričakovanj Exadate kot prispevek njene magije k uspešnosti, še bolj pa ta odstotek uporabiti za napovedovanje uspešnosti zunaj Exadate. Da bi razumeli, kako "natančno" je delo baze podatkov, morate preučiti statistiko AWR v razdelku "Statistika dejavnosti primerka" (obstaja veliko statistik s samoumevnimi imeni) in jih primerjati med seboj.
Da bi razumeli, kako se bo počutila zbirka podatkov zunaj Exadate, je najbolje narediti klon baze podatkov iz varnostne kopije na ciljni arhitekturi in analizirati delovanje tega klona pod obremenitvijo. Lastniki Exadata imajo praviloma to možnost.
Avtor: Alexey Struchenko, vodja oddelka za baze podatkov Jet Infosystems
Vir: www.habr.com