Vamos a contar la historia de un caso de una consulta anual que el cliente se cansaba de esperar a que diera una respuesta.
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 su respuesta es inmediata (0,14 segundos), con lo que de manera diaria no nos va a dar alguna pista de lo que pueda estar sucediendo internamente. Vamos a generar un nuevo tkprof pero esta vez para un mes.
Con esto ya podemos ver que hay algo raro, no solo el tiempo se dispara a los 46 segundos respecto a la diaria, sino que el número de bloques leídos se dispara a los 6.000.000 cuando para un día eran unos 32.000 bloques.
Analizando en detalle el tkproff vemos una operacion nested loops sospechosa
Esta operación del row source es la que realmente más consumen, con más de 2.000.000 bloques leídos en memoria. Otro punto más que nos llama la atención de este cruce es el tiempo.
Si miramos el árbol de ejecución, vemos que ese salto tanto en bloques leídos como en tiempo de ejecución se produce al acceder a la tabla resaltada a continuación.
En este punto, es donde deberíamos atacar para optimizar la consulta.
En el próximo capítulo abordaremos la optimización.