Vamos a contar la historia de un caso que unas veces la ejecución es inmediata y otras la ejecución se demora por horas.
Si consultamos la siguiente captura, observamos que la ejecución el día 28 se demoró más de 13h y en cambio, el resto de las ejecuciones ha sido inmediata
Vamos a generar el tkproff de la sentencia y sacar el awr de sentencia del día 28 de febrero, a ver si nos da alguna pista. Con el tkproff vamos a poder determinar qué está sucediendo internamente en el tiempo de ejecución y con el awr de sentencia vamos a poder ver si tiene por ejemplo planes adaptativos
Con el tkproff no vemos un índices muy altos
En cambio, el awr de sentencia sí que nos dice dos cosas que debemos tener cuidado:
- Más de 10.000.000 de lecturas.
- La consulta tiene planes adaptativos
Analizando en detalle el tkproff vemos que la mayoría de las operaciones hash tienen índices altos
Estas operaciones no tienen quizás muchos bloques leídos en memoria, pero hay que revisarlas porque quizá es la causa.
Otra cosa muy interesante que tenemos en el tkproff es que hay una conversión a bitmap desde btree, que es algo muy interesante que quizás deberíamos abordar en otro tema
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 particionada
En este punto, es donde deberíamos atacar para optimizar la consulta.