Esta es la historia de cómo una consulta que se ejecutaba en 33 minutos, se optimizo a 1,44 minutos…

Vamos a realizar un pequeño análisis para ver si hay algún punto mejorable en un proceso que se lanza a nivel mensual. Este proceso lanza n hilos donde cada uno de ellos se ejecuta de manera diaria hasta cubrir el mes. Analizando la ejecución de este proceso, vemos una serie de hilos que tardan más de la cuenta.

Lo primero que vamos a hacer es generar el tkprof.de cada uno de los hilos que exceden en el tiempo. Con esto vamos a poder determinar qué está sucediendo internamente en la ejecución de cada uno de ellos.

Analizando el tkproff de uno de los hilos, vemos una consulta con unos índices altos al acceder a los datos pero en cambio el tiempo de ejecución no es muy alto (no llega al segundo) ¡hay algo raro!

Analizando en detalle el tkproff vemos que en la operación nested loops se lleva el mayor grueso de la ejecución. Estas dos operaciones del row source, son realmente las que más consumen, con más de 10.000 bloques leídos.

Si miramos el árbol de ejecución, vemos que ese salto en bloques leídos se produce en la clausula exists que lleva la consulta.

¿Sería necesario cambiarlo por un IN? Quizás sería lo correcto, porque la consulta principal es más pesada. Vamos a comprobar cómo se comportaría en este caso la consulta cambiando a IN porque según podemos observar el grueso de la ejecución esta en la consulta principal y no en la subconsulta.

Este es el resultado:

Vaya, vemos que el resultado no es el esperado, el cambio a “in” no mejoran los tiempos, así que solo queda una cosa ¡hay que meter mano a la consulta!

Analizando las tablas que se utilizan en la consulta principal y en la subconsulta: condiciones que se utilizan, orden, conversiones… etc. opto por deshacer la subconsulta y subir esas tablas al from principal. El resultado es el siguiente:

Si contrastamos el tkproff original con la restructuración de la consulta, vemos una gran reducción de bloques leídos con un menor consume de CPU

¡Los tiempos mejoran y el acceso a los datos es óptimo! Por lo tanto, el principal problema de esta consulta era de escritura de SQL, modificando la consulta para que se acceda de manera correcta a los datos no solo mejoramos el acceso sino también los tiempos.

En el siguiente capitulo veremos como se comportan el resto de hilos.