Vamos a contar la historia de cómo hemos tratado una consulta para que la ejecución anual de la misma sea de un tiempo mínimo

Lo primero que vamos a hacer es generar el tkprof para un día. En el tkprof vamos a ver la carga de cada paso del row source “Row Source Generator” y vamos a poder determinar qué está sucediendo internamente en el tiempo de ejecución de este select.

Analizando la consulta, vemos que de manera diaria tiene una respuesta de 21’’ para devolver 0 filas, con lo que de manera diaria ya nos puede dar una pista. Otro punto que nos llama la atención de la ejecución diaria es el número de bloques leídos, se dispara a más de 3.000.000

Analizando en detalle el tkproff vemos operaciones del row source que cruzan mucha volumetría

Hay que analizar el SQL para ver que está haciendo para que el CBO no ataque de manera correcta a esos datos.

Realizamos un primer reajuste a nivel de SQL, con este resultado.

Se ha reducido el número de bloques leídos, hemos bajado del 1.000.000 y el tiempo también ha bajado, de 21’’ a unos 5’’. Hay que bajar el tiempo aún más.

Realizamos un segundo reajuste en el SQL…

Y ahora sí que hemos conseguido unos buenos tiempos, unos 44000 bloques leídos y un tiempo menor a 1’’. En los próximos capítulos veremos cómo se comporta a nivel mensual y a nivel anual.