Con esta breve publicación, me gustaría aclarar un malentendido relacionado con el análisis de AWR de bases de datos que funcionan en Oracle Exadata. Durante casi 10 años, he enfrentado constantemente la pregunta: ¿cuál es la contribución del software Exadata al rendimiento? O usando términos recién acuñados: ¿cuánto "exadatiza" el funcionamiento de una base de datos en particular?
A menudo, se da una respuesta incorrecta a esta pregunta, en mi opinión, refiriéndose a la estadística de AWR. Esta presenta un método de esperas del sistema que interpreta el tiempo de respuesta como la suma del tiempo de trabajo de los procesadores (DB CPU) y el tiempo de espera de diversas clases.
Con la aparición de Exadata, en la estadística de AWR se incluyeron esperas del sistema específicas relacionadas con el funcionamiento del software Exadata. Generalmente, los nombres de estas esperas comienzan con la palabra “cell” (la celda se refiere al servidor de almacenamiento Exadata), entre las cuales las más comunes son las esperas de nombre sugestivo como “cell smart table scan”, “cell multiblock physical read” y “cell single block physical read”.
En la mayoría de los casos, la parte de estas esperas de Exadata en el tiempo total de respuesta es baja, por lo que ni siquiera aparecen en la sección Top10 Foreground Events by Total Wait Time (en este caso, es necesario buscarlas en la sección Foreground Wait Events). Con gran dificultad, encontramos un ejemplo de AWR diario de nuestros clientes en el que las esperas de Exadata aparecieron en la sección Top10 y sumaron alrededor del 5%:
Evento
Esperas
Tiempo total de espera (segundos)
Tiempo promedio de espera
% del tiempo DB
Clase de espera
DB CPU
115.2K
70.4
SQL*Net más datos de dblink
670,196
5471.5
8.16ms
3.3
Red
cell single block physical read
5,661,452
3827.6
676.07us
2.3
Usuario I/O
Sincronización rebalanceo ASM
4,350,012
3481.3
800.30us
2.1
Otro
cell multiblock physical read
759,885
2252
2.96ms
1.4
Usuario I/O
lectura por ruta directa
374,368
1811.3
4.84ms
1.1
Usuario I/O
SQL*Net mensaje de dblink
7,983
1725
216.08ms
1.1
Red
cell smart table scan
1,007,520
1260.7
1.25ms
0.8
Usuario I/O
lectura por ruta directa temporal
520,211
808.4
1.55ms
0.5
Usuario I/O
enq: TM — contención
652
795.8
1220.55ms
0.5
Application
Con estadísticas de AWR así, a menudo se hacen las siguientes conclusiones:
1. La contribución de la magia de Exadata al rendimiento de la base de datos no es alta — no supera el 5%, y la base de datos "exadatiza" mal.
2. Si esta base de datos se trasladara de Exadata a una arquitectura clásica de "servidor + matriz", el rendimiento no cambiaría mucho. Porque incluso si esta matriz resulta ser tres veces más lenta que el sistema de almacenamiento Exadata (lo cual es poco probable para las matrices All Flash modernas), al multiplicar el 5% por tres obtendremos un aumento de la parte de esperas de entrada/salida hasta el 15% — una base de datos seguramente sobrevivirá a eso!
Ambas estas salidas son imprecisas, además distorsionan la comprensión de la idea subyacente en Exadata Software. Exadata no solo proporciona un rápido rendimiento de entrada/salida, sino que opera de manera fundamentalmente diferente en comparación con la arquitectura clásica de «servidor + matriz». Si la base de datos realmente se «exadatiza», la lógica SQL se traslada al sistema de almacenamiento. Storage servidores gracias a una serie de mecanismos especializados (en primer lugar, Exadata Storage Indexes, pero no solo) encuentran los datos necesarios y los envían a los servidores de la base de datos. Lo hacen de manera bastante eficiente, por lo que la proporción de esperas características de Exadata en el tiempo de respuesta total es pequeña.
¿Cómo cambiará esta proporción fuera de Exadata? ¿Cómo afectará esto al rendimiento de la base de datos en general? Las pruebas responderán mejor a estas preguntas. Por ejemplo, la espera de “cell smart table scan” fuera de Exadata puede convertirse en un pesado Table Full Scan, lo que significa que el rendimiento de entrada/salida ocupará todo el tiempo de respuesta y el rendimiento se verá drásticamente afectado. Por eso es incorrecto, al analizar AWR, considerar el porcentaje total de esperas de Exadata como una contribución mágica al rendimiento, y mucho menos usar este porcentaje para prever el rendimiento fuera de Exadata. Para entender cuán «exadatizada» está la operación de la base de datos, es necesario estudiar las estadísticas de la sección AWR “Instance Activity Stats” (donde hay muchas estadísticas con nombres elocuentes) y compararlas entre sí.
Y para entender cómo se comportará la base de datos fuera de Exadata, lo mejor es crear un clon de la base desde una copia de seguridad en la arquitectura objetivo y analizar el rendimiento de este clon bajo carga. Esta posibilidad está generalmente disponible para quienes poseen Exadata.
Autor: Aleksey Struchenko, gerente del departamento de bases de datos de «Infosistema Jet»
Fuente: habr.com
