Vamos a contar la historia de como una consulta que se lanza de manera anual, pasa de una ejecución de 24 minutos a 18 segundos.

Lo primero que vamos a hacer es generar el tkprof. Con esto vamos a poder determinar qué está sucediendo internamente en el tiempo de ejecución.

Analizando el tkproff, vemos un índices muy altos al acceder a los datos con un tiempo de ejecución también muy alto, ¡casi 24 minutos de ejecución!

Para poder optimizar un consulta con estos índices tan altos a nivel de cpu, lecturas en disco o de bloques, lo que vamos a hacer es ejecutarlo de manera mensual a ver si nos da una pista de lo que sucede realmente para poder acotar el problema

Si ejecutamos la consulta de manera mensual, los tiempos no son muy elevados en cuanto a la ejecución, pero si a nivel de cpu o bloques leídos, adjunto captura el tkproff

¿Qué está sucediendo realmente? Lo primero que hay que decir que no es una consulta sencilla, es una consulta con unas 1000 líneas de SQL compuesta por cuatro bloques por UNION ALL ¡una monstruosidad!

Analizando en detalle el tkproff vemos muchas operaciones nested loops con más de 100.000 bloques leídos.

Si miramos el árbol de ejecución de cada una de esas operaciones, vemos accesos a tablas pequeñas que leen muchísimos bloques.

Algo raro se cuece dentro que vamos a explicar en el próximo capítulo.