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.