Con esta breve publicación me gustaría disipar un malentendido relacionado con el análisis de bases de datos AWR que se ejecutan en Oracle Exadata. Durante casi 10 años, me he enfrentado constantemente a la pregunta: ¿cuál es la contribución de Exadata Software a la productividad? O usando palabras recién acuñadas: ¿qué tan “experto” es el trabajo de una base de datos en particular?
A menudo, en mi opinión, esta pregunta correcta se responde incorrectamente con referencia a las estadísticas de AWR. Presenta el método de espera del sistema, que trata el tiempo de respuesta como la suma del tiempo de funcionamiento de los procesadores (CPU de base de datos) y el tiempo de espera de varias clases.
Con la llegada de Exadata, aparecieron en las estadísticas de AWR expectativas específicas del sistema relacionadas con el funcionamiento del software Exadata. Como regla general, los nombres de dichas esperas comienzan con la palabra "celda" (el servidor Exadata Storage se llama celda), de las cuales las más comunes son las esperas con nombres reveladores "escaneo de tabla inteligente de celda", "lectura física multibloque de celda" y “lectura física de bloque único de celda”.
En la mayoría de los casos, la proporción de dichas esperas de Exadata en el tiempo total de respuesta es pequeña y, por lo tanto, ni siquiera se incluyen en la sección Los 10 principales eventos en primer plano por tiempo total de espera (en este caso, debe buscarlos en la sección Espera en primer plano). Sección de eventos). Con gran dificultad, encontramos un ejemplo de AWR diario de nuestros clientes, en el que las expectativas de Exadata estaban incluidas en la sección Top10 y en total ascendían a aproximadamente el 5%:
Evento
Murga
Tiempo total de espera (seg)
Espera promedio
% tiempo de base de datos
clase de espera
CPU de base de datos
115.2K
70.4
SQL*Net más datos de dblink
670,196
5471.5
8.16ms
3.3
Nuestra red
lectura física de un solo bloque de celda
5,661,452
3827.6
676.07us
2.3
E/S de usuario
Sincronizar reequilibrio de ASM
4,350,012
3481.3
800.30us
2.1
Otro
lectura física multibloque celular
759,885
2252
2.96ms
1.4
E/S de usuario
lectura de ruta directa
374,368
1811.3
4.84ms
1.1
E/S de usuario
Mensaje SQL*Net de dblink
7,983
1725
216.08ms
1.1
Nuestra red
escaneo de mesa inteligente celular
1,007,520
1260.7
1.25ms
0.8
E/S de usuario
temperatura de lectura de ruta directa
520,211
808.4
1.55ms
0.5
E/S de usuario
enq: TM - contención
652
795.8
1220.55ms
0.5
Aplicación
A menudo se extraen las siguientes conclusiones de dichas estadísticas de AWR:
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 se "exadatiza" mal.
2. Si dicha base de datos se transfiere de Exadata a la arquitectura clásica de "servidor + matriz", el rendimiento no cambiará mucho. Porque incluso si este arreglo resulta ser tres veces más lento que el sistema de almacenamiento Exadata (lo cual es difícilmente posible para los arreglos All Flash modernos), multiplicando el 5% por tres obtenemos un aumento en la proporción de esperas de E/S al 15%. - ¡La base de datos seguramente sobrevivirá a esto!
Ambas conclusiones son inexactas y, además, distorsionan la comprensión de la idea detrás de Exadata Software. Exadata no solo proporciona E/S rápidas, sino que funciona de manera fundamentalmente diferente en comparación con la arquitectura clásica de servidor + matriz. Si la operación de la base de datos está realmente "exadaptada", entonces la lógica SQL se transfiere al sistema de almacenamiento. Los servidores de almacenamiento, gracias a una serie de mecanismos especiales (principalmente índices de almacenamiento Exadata, pero no solo), encuentran ellos mismos los datos necesarios y envían la base de datos a los servidores. Lo hacen de manera bastante eficiente, por lo que la proporción de esperas típicas de Exadata en el tiempo total de respuesta es pequeña.
¿Cómo cambiará este porcentaje fuera de Exadata? ¿Cómo afectará esto al rendimiento de la base de datos en su conjunto? Las pruebas responderán mejor a estas preguntas. Por ejemplo, esperar un “escaneo de tabla inteligente de celda” fuera de Exadata puede convertirse en un escaneo completo de tabla tan pesado que la E/S ocupa todo el tiempo de respuesta y el rendimiento se degrada dramáticamente. Por eso es incorrecto, al analizar AWR, considerar el porcentaje total de expectativas de Exadata como la contribución de su magia al rendimiento, y más aún utilizar este porcentaje para predecir el rendimiento fuera de Exadata. Para comprender cuán "exacto" es el trabajo de la base de datos, debe estudiar las estadísticas de AWR en la sección "Estadísticas de actividad de la instancia" (hay muchas estadísticas con nombres que se explican por sí mismos) y compararlas entre sí.
Y para comprender cómo se sentirá una base de datos fuera de Exadata, es mejor hacer un clon de la base de datos a partir de una copia de seguridad en la arquitectura de destino y analizar el rendimiento de este clon bajo carga. Como regla general, los propietarios de Exadata tienen esta oportunidad.
autor: Alexey Struchenko, jefe del departamento de bases de datos de Jet Infosystems
Fuente: habr.com