Vamos a realizar un pequeño análisis para ver si hay algún punto mejorable en la base de datos analizando el AWR del cliente. El AWR corresponde a una hora en horario de punta de trabajo.

Lo primero que nos vamos a fijar es la versión de la BBDD y si se trata de un RAC y si tiene arquitectura Multitenant. En este caso la BBDD es 19c y es una base de datos single instance noCDB

Ahora que conocemos el contexto, vamos a echar un vistazo a cómo ha estado la CPU durante esa hora, para ello vamos al bloque de Host CPU y vemos que tenemos de memoria libre un 91,7 % Idle, es decir muy poco saturada ya que tiene menos de un 10% de carga.

El segundo punto al que debemos ir es Top 10 Foreground Events by Total Wait Time y ahí podemos ver algo raro. En esta lista, el evento DB CPU no es el primer evento con lo que nos da una pista de que algo anómalo hay en la base de datos.

El primer evento de la lista es “direct path read”. Este evento tiene aprox. 4 millones de esperas con un 82% de consumo de BBDD y con esperas de unas 15 horas aprox.

¿Cómo calculamos las horas? A partir del valor de Total Wait Time. Este valor viene en segundos por lo que hay que pasarlo a horas, es decir, 53.100 segundos entre 60. Esto nos da 885 minutos que equivalen a 14,75 horas. Hay que buscar el motivo de los índices tan alto en este evento, para ello vamos a revisar el SQL.

A nivel de SQL vemos dos sentencias con muchas lecturas físicas con poco uso de CPU, concretamente dos bloques anónimos.

Si bajamos al bloque SQL ordered by user I/O Wait Time también nos aparecen esos dos mismos bloques anónimos junto a cuatro operaciones DML.

Vamos a cotejar los datos del AWR con el tkprof, que corresponde a la traza de la ejecución. 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 esos updates.

Ahí vemos el problema. Ese PARTITION LIST ALL PARTITION nos indica que se están leyendo todas las particiones y, por tanto, no se está atacando bien a la clave de partición, de ahí el volumen tan alto de lecturas físicas. Como nota curiosa la tabla tiene particionamiento compuesto LIST-LIST

Modificamos esa sentencia de forma que ataque correctamente a la partición correspondiente.

Y ahora la consulta vuela, de un tiempo de CPU de 5.71 a 0.08, prácticamente inmediato.

Volvemos a generar el AWR para revisar Top 10 Foreground Events by Total Wait Time.

Vemos que el evento DB CPU es el primer evento y podemos aventurarnos a decir que hemos vuelto a un comportamiento normal.