Vamos a realizar un pequeño análisis para ver si hay algún punto mejorable en un proceso que se lanza a nivel mensual. Este proceso ejecuta n hilos donde cada hilo se ejecuta de manera diaria hasta cubrir el mes. Analizando la ejecución de este proceso, vemos una seria de hilos que tardan más de la cuenta.

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

Analizando el tkproff de uno de los hilos vemos una consulta con un índices y una ejecución en tiempo altos

Para la ejecución de un día, tarda unos 30’’ para devolver 1804 filas con más de 3.000.000 de bloques leídos.

Analizando en detalle el tkproff vemos que el siguiente nested loops se lleva el mayor grueso de la ejecución. Estas dos operaciones del row source, son realmente las que más consumen, con casi 3.000.000 de bloques leídos.

Analizando la SQL y el árbol de ejecución, veo que el problema radica en un índice que se creó. Viendo el uso que se está haciendo de ese índice, no podemos eliminarle ni hacerle invisible para que lo use el CBO, así que optamos por forzar no usarle en la consulta con el hint NO_INDEX.

Ejecutamos la consulta de nuevo con estos tiempos

La ejecución de un día es prácticamente inmediata, no llega al 1’’ la ejecución y la lectura de bloques ha bajado del 1.000.000 de bloques leídos.

El tiempo es bueno, pero el número de bloques leídos es aún alto. En el próximo capitulo abordaremos como hemos conseguido disminuir el número de bloques leídos.