Uso de “Hard Parse” vs “Soft Parse” BBDD Oracle

Uso de “Hard Parse” vs “Soft Parse” BBDD Oracle Permite encontrar mejoras sencillas para la sustitución de constantes por “bind variables”. El objetivo de la detección del uso inadecuado de “Hard parse” es la disminución del consumo de recursos y la duración sentencias implicada

Compartir esta entrada:

Detección

Tras lanzar una query en un entorno de BBDD Oracle, el primer paso del proceso es conocido como Parsing. En este paso divide la sentencia en sus distintos componentes para determinar qué tipo de sentencia se trata y realizar un chequeo tanto sintáctico como semántico de la misma. Una vez realizada esta comprobación sin errores, se procede a buscar si dicha sentencia ya ha sido procesada por otra sesión, esto se realiza buscando dicha sentencia en la SGA de la instancia.

En caso de que la sentencia se encuentre ya procesada en la SGA, nos encontramos ante un «Soft Parse», la instancia utilizará el plan de ejecución y acceso generado con anterioridad y procederá a buscar las filas afectadas por la sentencia.

En el caso contrario, si la sentencia no ha sido procesada con anterioridad, nos encontramos ante un «Hard Parse». La instancia de BBDD ha de generar un plan de ejecución y acceso optimizado para dicha sentencia y, posteriormente, leer las filas afectadas. Este proceso de «Hard Parse» puede suponer un problema de rendimiento, ya que el consumo de CPU necesario es notablemente superior al de un «Soft Parse». Aunque como mínimo es necesario efectuar un «Hard Parse» por cada sentencia, el exceso de este aumentará notablemente el consumo de CPU de la sentencia y dificultará el análisis de posibles problemas de rendimiento, puesto que las estadísticas de ejecución de sentencias que se pueden considerar iguales no se verán agrupadas.

El exceso de «Hard Parsing» suele darse por el uso de valores constantes en los filtros de las sentencias. Al hacer uso de constantes, el Optimizador de Oracle interpretará cada sentencia que se quiera ejecutar como una sentencia nueva y tendrá que ejecutar el proceso de parsing completo. Esta mala praxis se puede solventar por medio del utilización de «Bind Variables», de este modo el optimizador interpreta que la sentencia contiene valores variables y puede considerar dos sentencias como iguales, pudiendo, así, reutilizar planes ya generados y agrupar estadísticas de ejecución.

Ejemplo y Resultados

A continuación, mostramos un ejemplo, de una sentencia que hará la búsqueda de los valores del 1 al 10 en la columna «C1» de la tabla «T1»:

  • Uso de valores constantes:

                              SELECT * FROM T1 WHERE C1=1;

                              SELECT * FROM T1 WHERE C1=2;

                              ….                                                          

                              SELECT * FROM T1 WHERE C1=10;

En este caso, se puede observar que las sentencias son iguales, no obstante, el optimizador ha de realizar 10 «Hard Parses», ya que no puede interpretar que tiene un valor variable y generará un plan de ejecución para cada una de las ejecuciones y las estadísticas de ejecución mostrarán los valores separados lo que dificulta el seguimiento del rendimiento de la sentencia.

  • Uso de «Bind Variables»:

                              SELECT * FROM T1 WHERE C1=:B1;

En este caso, al hacer uso de «Bind Variables», el optimizador sabe que el valor a buscar en C1 es variable y, por tanto, el plan generado se podrá utilizar sin importar el valor que se busque de C1. Para nuestro ejemplo se efectuará un primer «Hard Parse» y el resto de las ejecuciones realizarán un «Soft Parse». Además, las estadísticas de ejecución de esta sentencia se verán agrupadas lo que simplificará el seguimiento del impacto que tiene sobre la instancia.

En el ejemplo desarrollado anteriormente, el elapsed por ejecución es de 1.000ms con un consumo de CPU de 600ms para las ejecuciones que efectúan “Hard Parse”. En caso de hacer uso de “Bind Variables” y poder realizar “Soft Parses” se estima una reducción de un 40% de uso de CPU y un 24% de elapsed por ejecución. Se ha de contar que es necesario realizar un primer “Hard Parse” aunque se haga uso de “Bind Variables”, por lo que el elapsed total para las 10 ejecuciones del ejemplo se reduce de 10.000ms a 7.840ms y el consumo de CPU se ve reducido de 6.000ms a 3.840ms.

En conclusión, si vamos a ejecutar de forma repetida una query que acceda a la o las mismas tablas en busca de valores distintos, siempre es recomendable hacer empleo de “Bind Variables”. De este modo, el Optimizador de Oracle será capaz de interpretar que se trata de sentencias iguales y podremos ahorrar el consumo de CPU que genera la creación de un plan de ejecución y acceso, reutilizando los ya creados con anterioridad.

Expertise relacionados

  • Tiempos de respuesta del software: la inmediatez como requisito

    Tiempos de respuesta del software: la inmediatez como requisito

    La eficiencia de las TI ante las demandas de los usuarios es vital para la experiencia del cliente. En picos…

  • Cumplimiento SLA ¿están tus procesos batch optimizados?

    Cumplimiento SLA ¿están tus procesos batch optimizados?

    Todas las empresas se enfrentan a desafíos relacionados con el cumplimiento SLA o de acuerdos de nivel de servicio, tanto…

  • Ineficiencias en el software: abórdalas para mejorar tu ROI empresarial

    Ineficiencias en el software: abórdalas para mejorar tu ROI empresarial

    El crecimiento de las infraestructuras tecnológicas multiplica las ineficiencias del software, causando caídas en el servicio y tiempos de reparación…

Suscríbete a nuestra newsletter y no te pierdas nada