Amb aquesta breu publicació m'agradaria dissipar un malentès relacionat amb l'anàlisi de bases de dades AWR que s'executen a Oracle Exadata. Durant gairebé 10 anys, m'he enfrontat constantment a la pregunta: quina és la contribució d'Exadata Software a la productivitat? O utilitzant paraules recentment encunyades: com d'"expert" és el treball d'una base de dades en particular?
Sovint aquesta pregunta correcta, al meu entendre, es respon incorrectament en referència a les estadístiques AWR. Presenta el mètode d'espera del sistema, que tracta el temps de resposta com la suma del temps de funcionament dels processadors (CPU de base de dades) i el temps d'espera de diverses classes.
Amb l'arribada d'Exadata, les expectatives específiques del sistema relacionades amb el funcionament del programari Exadata van aparèixer a les estadístiques d'AWR. Per regla general, els noms d'aquestes esperes comencen amb la paraula "cel·la" (el servidor d'emmagatzematge d'Exadata s'anomena cel·la), de les quals les més habituals són les esperes amb noms indicatius "escaneig de taula intel·ligent de cel·les", "lectura física de blocs múltiples de cel·les". i "lectura física de bloc únic de cel·la".
En la majoria dels casos, la proporció d'aquestes esperes d'Exadata en el temps de resposta total és petita i, per tant, ni tan sols entren a la secció Top10 d'esdeveniments de primer pla per temps d'espera total (en aquest cas, cal que les cerqueu a la secció d'espera de primer pla). secció d'esdeveniments). Amb molta dificultat, vam trobar un exemple d'AWR diari dels nostres clients, en què les expectatives d'Exadata s'incloïen a la secció Top10 i en total ascendien al voltant del 5%:
esdeveniment
Espera
Temps d'espera total (s)
Espera mitjana
% DB temps
Espera Classe
CPU de base de dades
115.2K
70.4
SQL*Net més dades de dblink
670,196
5471.5
8.16ms
3.3
Xarxa
lectura física de bloc únic de cel·la
5,661,452
3827.6
676.07us
2.3
E/S d'usuari
Sincronitza el reequilibri ASM
4,350,012
3481.3
800.30us
2.1
un altre
lectura física multibloc cel·lular
759,885
2252
2.96ms
1.4
E/S d'usuari
lectura directa del camí
374,368
1811.3
4.84ms
1.1
E/S d'usuari
Missatge SQL*Net de dblink
7,983
1725
216.08ms
1.1
Xarxa
exploració de la taula intel·ligent de cel·les
1,007,520
1260.7
1.25ms
0.8
E/S d'usuari
ruta directa lectura temp
520,211
808.4
1.55ms
0.5
E/S d'usuari
enq: TM - contenció
652
795.8
1220.55ms
0.5
Sol·licitud
Sovint s'extreuen les següents conclusions d'aquestes estadístiques d'AWR:
1. La contribució de la màgia d'Exadata al rendiment de la base de dades no és alta: no supera el 5% i la base de dades "exadatitza" malament.
2. Si aquesta base de dades es transfereix des d'Exadata a l'arquitectura clàssica "servidor + matriu", el rendiment no canviarà gaire. Perquè fins i tot si aquesta matriu resulta ser tres vegades més lent que el sistema d'emmagatzematge Exadata (cosa que difícilment és possible per a les matrius All Flash modernes), multiplicant el 5% per tres obtenim un augment de la quota d'espera d'E/S fins al 15% - Sens dubte, la base de dades sobreviurà a això!
Ambdues conclusions són inexactes i, a més, distorsionen la comprensió de la idea que hi ha darrere del programari Exadata. Exadata no només proporciona una E/S ràpida, sinó que funciona de manera fonamentalment diferent en comparació amb l'arquitectura clàssica de servidor + matriu. Si l'operació de la base de dades està realment "exadaptada", la lògica SQL es transfereix al sistema d'emmagatzematge. Els servidors d'emmagatzematge, gràcies a una sèrie de mecanismes especials (principalment índexs d'emmagatzematge Exadata, però no només), troben les dades necessàries ells mateixos i envien la base de dades als servidors. Ho fan de manera bastant eficient, de manera que la proporció d'espera típiques d'Exadata en el temps de resposta total és petita.
Com canviarà aquesta quota fora d'Exadata? Com afectarà això al rendiment de la base de dades en conjunt? Les proves respondran millor aquestes preguntes. Per exemple, esperar una "exploració de la taula intel·ligent de cel·les" fora d'Exadata pot convertir-se en una exploració completa de taula tan pesada que l'E/S ocupa tot el temps de resposta i el rendiment es degrada dràsticament. Per això és incorrecte, a l'hora d'analitzar AWR, considerar el percentatge total d'expectatives d'Exadata com la contribució de la seva màgia al rendiment, i encara més utilitzar aquest percentatge per predir el rendiment fora d'Exadata. Per entendre com d'"exacte" és el treball de la base de dades, cal estudiar les estadístiques AWR de la secció "Estadístiques d'activitat de la instància" (hi ha moltes estadístiques amb noms que s'explicaran per si mateix) i comparar-les entre elles.
I per entendre com es sentirà una base de dades fora d'Exadata, el millor és fer un clon de base de dades a partir d'una còpia de seguretat a l'arquitectura de destinació i analitzar el rendiment d'aquest clon sota càrrega. Els propietaris d'Exadata, per regla general, tenen aquesta oportunitat.
autor: Alexey Struchenko, cap del departament de bases de dades de Jet Infosystems
Font: www.habr.com