# Ejecuciones Diarias Que Se Demoran – Capítulo Iii

Vamos a realizar un pequeño análisis de una consulta que se lanza de manera diaria.

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

![](https://dbaenlasombra.files.wordpress.com/2023/10/1.png?w=567 align="left")

Analizando el tkproff vemos una consulta con un índices muy elevados donde la ejecución supera los cuatro minutos….

Analizando en detalle el tkproff y partiendo de la base que es una consulta monstruosa (más de 2000 líneas) vemos un acceso con un cr y tiempos muy elevados.

![](https://dbaenlasombra.files.wordpress.com/2023/10/2-1.png?w=567 align="left")

Analizando la consulta justo en el punto donde se nos escapa a cuanto a tiempos, vemos excesos de usos de cláusulas join no-join. Este tipo de cláusulas son la causa de que el cbo no acceda correctamente a nuestra tabla particionada.

![](https://dbaenlasombra.files.wordpress.com/2023/10/imagen7-1.png?w=559 align="left")

Reconstruimos la SQL y volvemos a generar el tkproff

![](https://dbaenlasombra.files.wordpress.com/2023/10/4.png?w=567 align="left")

El tiempo de ejecución ha bajado a menos de 1’’ y el número de bloques a menos de 200.000, y lo más importante, el acceso a la tabla ya tiene un acceso más lógico.

![](https://dbaenlasombra.files.wordpress.com/2023/10/69.png?w=567 align="left")

En los siguientes capítulos, abordaremos como hemos reducido el número de bloques leídos por la consulta.