Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Optimización del rendimiento y procedimientos de evaluación comparativa de bases de datos de Oracle

03/13/2024 Colaboradores

PDF

Las pruebas precisas del rendimiento del almacenamiento de la base de datos son un tema muy complicado. Requiere una comprensión de los siguientes problemas:

IOPS y rendimiento
La diferencia entre las operaciones de I/O en primer plano y en segundo plano
El efecto de la latencia sobre la base de datos
Numerosos sistemas operativos y configuraciones de red que también afectan al rendimiento del almacenamiento

Además, hay tareas que no son de almacenamiento que se deben tener en cuenta. Hay un punto en el cual la optimización del rendimiento del almacenamiento no proporciona ventajas útiles, porque el rendimiento del almacenamiento ya no es un factor limitador del rendimiento.

La mayoría de clientes de bases de datos seleccionan ahora las cabinas all-flash, lo que crea algunas consideraciones adicionales. Por ejemplo, piense en las pruebas de rendimiento en un sistema AFF A900 de dos nodos:

Con una tasa de lectura/escritura de 80/20:1, dos nodos de A900 pueden ofrecer más de 1M 000 IOPS de base de datos aleatorias antes de que la latencia supere incluso la marca 150µs. Esto supera con creces las demandas de rendimiento actuales de la mayoría de las bases de datos, que es difícil predecir la mejora esperada. El almacenamiento se borrará en gran medida como un cuello de botella.
El ancho de banda de red es una fuente cada vez más común de limitaciones de rendimiento. Por ejemplo, las soluciones de discos giratorios suelen ser cuellos de botella en el rendimiento de las bases de datos porque la latencia de I/O es muy alta. Cuando una cabina all-flash elimina las limitaciones de latencia, la barrera cambia frecuentemente a la red. Esto es especialmente notable en entornos virtualizados y sistemas blade donde la verdadera conectividad de red es difícil de visualizar. Esto puede complicar las pruebas de rendimiento si el sistema de almacenamiento en sí no se puede utilizar completamente debido a las limitaciones de ancho de banda.
Comparar el rendimiento de una cabina all-flash con una cabina que contiene discos giratorios no es posible debido a la latencia drásticamente mejorada de las cabinas all-flash. Los resultados de las pruebas no suelen ser significativos.
La comparación del rendimiento máximo de IOPS con una cabina all-flash no suele ser una prueba útil porque las bases de datos no están limitadas por las operaciones de I/O de almacenamiento Por ejemplo, supongamos que una cabina puede admitir 500K 000 IOPS aleatorias, mientras que otra puede admitir 300K. La diferencia no es relevante en el mundo real si la base de datos gasta el 99% de su tiempo en procesamiento de CPU. Las cargas de trabajo nunca utilizan todas las funcionalidades de la cabina de almacenamiento. En cambio, las funcionalidades de IOPS máximo pueden ser cruciales en una plataforma de consolidación en la cual se espera que la cabina de almacenamiento se cargue en sus capacidades máximas.
Considere siempre la latencia así como IOPS en cualquier prueba de almacenamiento. Muchas cabinas de almacenamiento del mercado afirman niveles extremos de IOPS, pero la latencia hace que dichas IOPS sean inútiles en dichos niveles. El destino típico de las cabinas all-flash es la marca 1ms. Un método mejor de prueba no es medir el máximo de IOPS posibles, sino determinar cuántas IOPS puede admitir una cabina de almacenamiento antes de que la latencia media sea superior a 1ms ms.

Oracle Automatic Workload Repository y benchmarking

El estándar oro para las comparaciones de rendimiento de Oracle es un informe de Oracle Automatic Workload Repository (AWR).

Hay varios tipos de informes de AWR. Desde el punto de vista del almacenamiento, un informe generado por la ejecución del awrrpt.sql Command es el más completo y valioso porque se dirige a una instancia de base de datos específica e incluye algunos histogramas detallados que desglosan eventos de I/O de almacenamiento en función de la latencia.

La comparación ideal de dos cabinas de rendimiento implica ejecutar la misma carga de trabajo en cada cabina y producir un informe de AWR que apunte con precisión a la carga de trabajo. En el caso de una carga de trabajo de ejecución muy prolongada, se puede utilizar un único informe de AWR con un tiempo transcurrido que abarque el tiempo de inicio y de finalización, pero es preferible dividir los datos de AWR como varios informes. Por ejemplo, si un trabajo por lotes se ejecutó desde la medianoche hasta las 6 a.m., cree una serie de informes de AWR de una hora de medianoche a las 1 a.m., de 1 a.m. a 2 a.m., etc.

En otros casos, se debe optimizar una consulta muy corta. La mejor opción es un informe de AWR basado en una instantánea de AWR creada cuando se inicia la consulta y una segunda instantánea de AWR creada cuando finaliza la consulta. El servidor de la base de datos debería ser silencioso para minimizar la actividad en segundo plano que oscurecería la actividad de la consulta en análisis.

Cuando los informes de AWR no están disponibles, los informes de Oracle statspack son una buena alternativa. Contienen la mayoría de las mismas estadísticas de E/S que un informe AWR.

Oracle AWR y solución de problemas

Un informe AWR es también la herramienta más importante para analizar un problema de rendimiento.

Al igual que sucede con las pruebas de rendimiento, la solución de problemas de rendimiento requiere medir con precisión una carga de trabajo determinada. Siempre que sea posible, facilite los datos de AWR cuando notifique un problema de rendimiento al centro de soporte de NetApp o cuando trabaje con un NetApp o con un equipo de cuentas de partners sobre una nueva solución.

Al proporcionar datos de AWR, tenga en cuenta los siguientes requisitos:

Ejecute el awrrpt.sql comando para generar el informe. La salida puede ser texto o HTML.
Si se utiliza Oracle Real Application Clusters (RAC), genere informes de AWR para cada instancia del cluster.
Indique la hora específica a la que ha existido el problema. El tiempo transcurrido máximo aceptable de un informe de AWR suele ser de una hora. Si un problema persiste durante varias horas o implica una operación de varias horas, como un trabajo por lotes, proporcione varios informes de AWR de una hora que cubran todo el período que se va a analizar.
Si es posible, ajuste el intervalo de instantáneas de AWR a 15 minutos. Este ajuste permite realizar un análisis más detallado. Esto también requiere ejecuciones adicionales de awrrpt.sql para proporcionar un informe para cada intervalo de 15 minutos.
Si el problema es una consulta de ejecución muy corta, proporcione un informe AWR basado en una instantánea AWR creada al iniciar la operación y una segunda instantánea AWR creada al finalizar la operación. El servidor de base de datos debería ser silencioso para minimizar la actividad en segundo plano que oscurecería la actividad de la operación en análisis.
Si se informa de un problema de rendimiento en determinados momentos pero no en otros, proporcione datos de AWR adicionales que demuestren un buen rendimiento para la comparación.

calibrar_io

La calibrate_io nunca se debe usar el comando para probar, comparar ni hacer pruebas de rendimiento de los sistemas de almacenamiento. Tal y como se indica en la documentación de Oracle, este procedimiento calibra las capacidades de E/S del almacenamiento.

La calibración no es lo mismo que la evaluación comparativa. El objetivo de este comando es emitir E/S para ayudar a calibrar las operaciones de base de datos y mejorar su eficiencia mediante la optimización del nivel de E/S emitidas al host. Debido al tipo de I/O que realiza el calibrate_io La operación no representa la E/S real del usuario de la base de datos, los resultados no son predecibles y, con frecuencia, ni siquiera se pueden reproducir.

SLOB2

SLOB2, el Silly Little Oracle Benchmark, se ha convertido en la herramienta preferida para evaluar el rendimiento de la base de datos. Fue desarrollado por Kevin Closson y está disponible en "https://kevinclosson.net/slob/". Se necesitan minutos para instalar y configurar, y utiliza una base de datos Oracle real para generar patrones de E/S en un tablespace definido por el usuario. Es una de las pocas opciones de prueba disponibles que puede saturar una cabina all-flash con I/O. También es útil para generar niveles mucho más bajos de I/O para simular cargas de trabajo de almacenamiento que son bajas IOPS, pero sensibles a la latencia.

Swingbench

Swingbench puede ser útil para probar el rendimiento de las bases de datos, pero es extremadamente difícil utilizar Swingbench de una manera que pone a prueba el almacenamiento. NetApp no ha observado ninguna prueba de Swingbench que haya producido suficientes I/O como para representar una carga significativa en ninguna cabina AFF. En casos limitados, la prueba de entrada de órdenes (OET) puede utilizarse para evaluar el almacenamiento desde un punto de vista de latencia. Esto podría ser útil en situaciones en las que una base de datos tiene una dependencia de latencia conocida para consultas particulares. Se debe tener precaución para asegurarse de que el host y la red estén correctamente configurados de modo que se puedan aprovechar las posibilidades de latencia de una cabina all-flash.

HammerDB

HammerDB es una herramienta de prueba de bases de datos que simula las pruebas TPC-C y TPC-H. Construir un conjunto de datos lo suficientemente grande puede llevar mucho tiempo para ejecutar correctamente una prueba, pero puede ser una herramienta eficaz para evaluar el rendimiento de las aplicaciones de almacén de datos y OLTP.

Orión

La herramienta Oracle Orion se usaba comúnmente con Oracle 9, pero no se ha mantenido para garantizar la compatibilidad con los cambios en varios sistemas operativos de host. Rara vez se utiliza con Oracle 10 u Oracle 11 debido a incompatibilidades con el sistema operativo y la configuración del almacenamiento.

Oracle reescribió la herramienta y se instala por defecto con Oracle 12c. Aunque este producto se ha mejorado y utiliza muchas de las mismas llamadas que utiliza una base de datos Oracle real, no utiliza exactamente la misma ruta de acceso de código o el comportamiento de E/S utilizado por Oracle. Por ejemplo, la mayoría de las operaciones de I/O de Oracle se realizan de forma síncrona, lo que significa que la base de datos se detiene hasta que la E/S se completa a medida que la operación de E/S se completa en primer plano. Un inundamiento simple de un sistema de almacenamiento con I/O aleatorias no es una reproducción de las operaciones de I/O de Oracle reales y no ofrece un método directo de comparar matrices de almacenamiento o medir el efecto de los cambios de configuración.

Dicho esto, existen algunos casos de uso de Orion, como la medición general del rendimiento máximo posible de una determinada configuración host-red-almacenamiento o para medir el estado de un sistema de almacenamiento. Con una cuidadosa realización de pruebas, podrían concebirse pruebas de Orion útiles para comparar cabinas de almacenamiento o evaluar el efecto de un cambio en la configuración, siempre y cuando los parámetros incluyan considerar la consideración de IOPS, el rendimiento y la latencia, y tratar de replicar fielmente una carga de trabajo realista.