Prin această mică postare, aș dori să clarific o neînțelegere legată de analiza AWR a bazelor de date care funcționează pe Oracle Exadata. De aproape 10 ani, mă confrunt constant cu întrebarea: care este contribuția software-ului Exadata la performanță? Sau, folosind termeni noi, cât de „exadatizată” este activitatea unei anumite baze de date?
Adesea, pentru această întrebare corectă, din punctul meu de vedere, se oferă un răspuns greșit, bazat pe statisticile AWR. Aceste statistici prezintă un metodă de a analiza așteptările sistemului, interpretând timpul de răspuns ca suma timpului de operare a procesoarelor (DB CPU) și a timpului de așteptare pentru diverse clase.
Odată cu apariția Exadata, în statisticile AWR au apărut așteptări sistemice specifice legate de activitatea software-ului Exadata. De obicei, numele acestor așteptări încep cu cuvântul “cell” (un server de stocare Exadata este denumit celulă), iar cele mai întâlnite așteptări au denumiri sugestive precum “cell smart table scan”, “cell multiblock physical read” și “cell single block physical read”.
În cele mai multe cazuri, proporția acestor așteptări Exadata în timpul total de răspuns este mică, așa că ele nu apar nici măcar în secțiunea Top10 Evenimente de Prim-plan după Timpul Total de Așteptare (în acest caz, trebuie căutate în secțiunea Evenimentele de Așteptare în Prim-plan). Cu greu am descoperit, la clienții noștri, un exemplu de AWR zilnic în care așteptările Exadata au apărut în secțiunea Top10 și au totalizat aproximativ 5%:
Eveniment
Așteptări
Timp total de așteptare (sec)
Timp mediu de așteptare
% din timpul DB
Clasa de așteptare
DB CPU
115.2K
70.4
SQL*Net mai multe date din dblink
670,196
5471.5
8.16ms
3.3
Rețea
cell single block physical read
5,661,452
3827.6
676.07us
2.3
User I/O
Sync ASM rebalance
4,350,012
3481.3
800.30us
2.1
Altele
cell multiblock physical read
759,885
2252
2.96ms
1.4
User I/O
direct path read
374,368
1811.3
4.84ms
1.1
User I/O
SQL*Net mesaj de la dblink
7,983
1725
216.08ms
1.1
Rețea
cell smart table scan
1,007,520
1260.7
1.25ms
0.8
User I/O
direct path read temp
520,211
808.4
1.55ms
0.5
User I/O
enq: TM — contencție
652
795.8
1220.55ms
0.5
Application
Din astfel de statistici AWR, se fac adesea concluzii precum:
1. Contribuția magiei Exadata la performanța bazei de date nu este mare — nu depășește 5%, iar baza de date „exadatizează” slab.
2. Dacă o astfel de bază de date ar fi mutată de pe Exadata pe o arhitectură clasică „server + stocare”, performanța nu s-ar schimba semnificativ. Pentru că, chiar dacă acest sistem de stocare ar fi de trei ori mai lent decât sistemul de stocare Exadata (ceea ce este puțin probabil pentru sistemele All Flash moderne), atunci înmulțind 5% cu trei, am obține o creștere a proporției așteptărilor de intrare/ieșire până la 15% — o astfel de bază de date cu siguranță va rezista!
Ambele aceste ieșiri sunt inexacte, ba mai mult, distorsionează înțelegerea ideii introduse în Exadata Software. Exadata nu oferă doar un input-output rapid, ci funcționează fundamental diferit în comparație cu arhitectura clasică „server + masiv”. Dacă activitatea bazei de date este cu adevărat „exadată”, atunci logica SQL este transferată pe sistemul de stocare. Storage servere datorită unei serii de mecanisme speciale (în special Exadata Storage Indexes, dar nu doar) găsesc singure datele necesare și le transmit serverelor DB. Fac acest lucru destul de eficient, astfel încât proporția așteptărilor caracteristice Exadata în timpul total de răspuns este mică.
Cum se va schimba această proporție în afara Exadata? Cum va influența aceasta performanța bazei de date în ansamblu? Cele mai bune răspunsuri la aceste întrebări le va da testarea. De exemplu, așteptarea „cell smart table scan” în afara Exadata se poate transforma într-un scan complet al tabelului atât de greu încât input-output-ul să ocupe tot timpul de răspuns, iar performanța să scadă dramatic. De aceea, nu este corect să considerăm procentul total al așteptărilor Exadata drept contribuția sa magică la performanță și, cu atât mai puțin, să folosim acest procent pentru a prezice performanța în afara Exadata. Pentru a înțelege cât de „exadată” este activitatea bazei, este necesar să studiem statisticile din secțiunea AWR „Instance Activity Stats” (acolo sunt multe statistici cu nume relevante) și să le comparăm între ele.
Și, pentru a înțelege cum se va simți baza de date în afara Exadata, cel mai bine este să facem un clon al bazei dintr-un backup pe arhitectura țintă și să analizăm performanța acestui clon sub sarcină. Această posibilitate este, de obicei, disponibilă pentru deținătorii de Exadata.
Autor: Aleksei Strucenko, șeful departamentului Baze de Date „Infosistem Jet”
Sursa: habr.com
