Search for a command to run...
Ingeniero informático, Oracle ACE, DBA y Arquitecto OCI, con más de 15 años de experiencia en plataformas Oracle. Certificado en OCI Certified Architect Professional y OCI Migration and Integration Certified Professional.
No comments yet. Be the first to comment.
En el post anterior Análisis de AWR – Particiones que no se acceden correctamente evaluamos el rendimiento en horas de trabajo, y ahora vamos a estudiar la carga en fin de semana para ver si hay algún punto mejorable Igual que hicimos en el caso ante...
En el artículo de hoy vamos a ver las Calendar functions en 26ai, diseñadas para simplificar la "vida" a los desarrolladores. Antes de su existencia, esto se resolvía con ingeniosas combinaciones usan
![[26ai] SQL: Calendar functions/Aggregation Filters "CALENDAR"](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F587e3328-9877-4c7a-aad7-7811e251f81e.png&w=3840&q=75)
En el artículo de hoy vamos a ver como podemos recrear una PDB$Seed de manera fácil en caso que se quede corrupta y no tengamos backup. sys@> alter pluggable database PDB$SEED open read only; alter pl
![[OCI] Recreación PDB$SEED](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F289ede5b-558c-4f93-b5c0-fa04680c91ca.png&w=3840&q=75)
El artículo también se encuentra publicado en Ingles English version. En el artículo de hoy vamos a ver como podemos clonar una PDB usando RMAN Active Duplicate o bien usando una instrucción DDL entre
![[OCI] Clone PDB](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F8ce0c665-4a5d-459d-91cf-ffe3f47d8176.png&w=3840&q=75)
El artículo también se encuentra publicado en Ingles English version. En el artículo de hoy voy a compartir un sh que utilizo para ver de una manera rápida los jobs que se ejecutan desde Oracle Databa
![[OCI] Check Jobs DBCli](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F1376a869-58fa-491e-926a-a6ead08f9c80.png&w=3840&q=75)
El artículo también se encuentra publicado en Ingles English version. En el artículo de hoy vamos a ver la nueva sintaxis introducida para simplificar aún más los joins evitando errores comunes, hacie
![[26ai] JOIN_TO_ME](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F16a23f6e-ec4c-4f0a-9529-2c8a2af2ef5e.png&w=3840&q=75)
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.
