Ovim kratkim postom želio bih otkloniti jedan nesporazum vezan uz analizu AWR baza podataka koje rade na Oracle Exadata. Skoro 10 godina neprestano se suočavam s pitanjem: koliki je doprinos Exadata softvera produktivnosti? Ili koristeći se novoskovanim riječima: koliko je “stručan” rad određene baze podataka?
Često se na ovo ispravno pitanje, po mom mišljenju, netočno odgovara u odnosu na AWR statistiku. Predstavlja metodu čekanja sustava, koja tretira vrijeme odziva kao zbroj vremena rada procesora (DB CPU) i vremena čekanja različitih klasa.
S pojavom Exadate, specifična očekivanja sustava vezana uz rad Exadata softvera pojavila su se u AWR statistici. Nazivi takvih čekanja u pravilu počinju riječju “ćelija” (Exadata Storage poslužitelj naziva se ćelija), od kojih su najčešća čekanja sa samorazumljivim 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 malen, te stoga oni niti ne spadaju u odjeljak Top10 Foreground Events by Total Wait Time (u ovom slučaju ih morate potražiti u Foreground Wait odjeljak Događaji). Uz velike poteškoće, pronašli smo primjer dnevnog AWR-a od naših kupaca, u kojem su Exadata očekivanja uključena u odjeljak Top10 i ukupno su iznosila oko 5%:
događaj
čeka
Ukupno vrijeme čekanja (sek)
Prosječno čekanje
%DB vrijeme
Čekaj razred
DB CPU
115.2K
70.4
SQL*Net više podataka iz dblink-a
670,196
5471.5
8.16ms
3.3
mreža
ćelija pojedinačni blok fizičko čitanje
5,661,452
3827.6
676.07us
2.3
Korisnički I/O
Sinkronizirajte rebalans ASM-a
4,350,012
3481.3
800.30us
2.1
drugo
stanica multiblock fizičko čitanje
759,885
2252
2.96ms
1.4
Korisnički I/O
direktni put čitati
374,368
1811.3
4.84ms
1.1
Korisnički I/O
SQL*Net poruka od dblink
7,983
1725
216.08ms
1.1
mreža
skeniranje pametne tablice ćelija
1,007,520
1260.7
1.25ms
0.8
Korisnički I/O
izravni put čitanja temp
520,211
808.4
1.55ms
0.5
Korisnički I/O
enq: TM - svađa
652
795.8
1220.55ms
0.5
primjena
Sljedeći se zaključci često izvlače iz takve AWR statistike:
1. Doprinos Exadata magije performansama baze podataka nije visok - ne prelazi 5%, a baza podataka se slabo "exadatira".
2. Ako se takva baza podataka prebaci iz Exadate u klasičnu arhitekturu “server + array”, tada se performanse neće puno promijeniti. Jer čak i ako se ispostavi da je ovaj niz tri puta sporiji od Exadata sustava za pohranu (što je teško moguće za moderne All Flash nizove), tada množenjem 5% s tri dobivamo povećanje udjela I/O čekanja na 15%. - baza će ovo sigurno preživjeti!
Oba ova zaključka su netočna, štoviše, iskrivljuju razumijevanje ideje svojstvene Exadata Software-u. Exadata ne pruža samo brzi I/O, već radi bitno drugačije u usporedbi s klasičnom arhitekturom poslužitelja + polja. Ako je operacija baze podataka doista "exadaptirana", tada se SQL logika prenosi u sustav za pohranu. Storage poslužitelji, zahvaljujući nizu posebnih mehanizama (prvenstveno Exadata Storage Indexes, ali ne samo), sami pronalaze potrebne podatke i šalju DB poslužiteljima. Oni to čine prilično učinkovito, tako da je udio tipičnih Exadata čekanja u ukupnom vremenu odgovora mali.
Kako će se ovaj udio promijeniti izvan Exadate? Kako će to utjecati na performanse baze podataka kao cjeline? Testiranje će najbolje odgovoriti na ova pitanja. Na primjer, čekanje na "cell smart table scan" izvan Exadate može se pretvoriti u toliko teško Table Full Scan da I/O zauzima cijelo vrijeme odgovora i performanse dramatično padaju. Zato je pogrešno, kada se analizira AWR, uzeti u obzir ukupni postotak očekivanja Exadate kao doprinos njezine magije performansama, a još više koristiti ovaj postotak za predviđanje performansi izvan Exadate. Da biste razumjeli koliko je "točan" rad baze podataka, morate proučiti statistiku AWR-a u odjeljku "Statistika aktivnosti instance" (postoji mnogo statistika s nazivima koji sami po sebi objašnjavaju) i međusobno ih usporediti.
A da biste razumjeli kako će se osjećati baza podataka izvan Exadate, najbolje je napraviti klon baze podataka iz sigurnosne kopije na ciljnoj arhitekturi i analizirati performanse ovog klona pod opterećenjem. Vlasnici Exadata, u pravilu, imaju ovu priliku.
Autor: Alexey Struchenko, voditelj odjela baze podataka Jet Infosystems
Izvor: www.habr.com