Como continuación de EJECUCIÓN DE PROCESOS INEFICIENTES – PARTE I.
Vamos analizar una de las dos consultas que pinta el awr.
Lo primero que vamos a hacer es generar el tkprof de una de las consultas. 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 tarda en dar respuesta 2 segundos
Si miramos el árbol de ejecución, vemos que más sufre es al acceder a la tabla particionado.
Vamos a analizar el SQL para ver cómo podemos restructurar los datos.
Con esta restructuración, ¡la consulta vuela! Con una lectura de 125 bloques y una respuesta inmediata.
El “truco” ha sido cambiar el acceso a la tabla particionada, al ser una tabla con más de 87.000.000 de registros, la SQL hay que montarla de una manera que facilite al CBO hacer su trabajo de manera eficiente.
Aquí vemos el SQL original y el reajustado.
