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.
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...
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)
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 anterior, vemos que es una base de datos single instance que sin arquitectura CDB
Si miramos como ha estado la CPU durante ese fin de semana, vemos que tenemos mucha memoria libre con un 95,1 %Idle, es decir menos carga incluso que durante la semana: menos de un 4% de carga de usuario.
A nivel de eventos de espera “Top 10 Foreground Events by Total Wait Time” no vemos tampoco nada anómalo. En esta lista, el evento DB CPU es el primer evento, con lo que el funcionamiento que hay en la base de datos parece correcto
Hasta aquí podemos decir que el funcionamiento de la base de datos durante ese fin de semana ha sido relajado.
No obstante, si entramos en la parte de sentencias SQL y no a nivel global vemos algo que nos llama la atención, una consulta con más de 5.000.000 millones de lecturas de bloque, !una burrada!
Vamos a revisar esa sentencia en detalle por ver si tenemos algún problema a nivel de SQL: que esté mal escrito, problemas con las estadísticas, no se esté atacando bien a los datos…etc.
Para analizar esa consulta vamos a generar el AWR de sentencia de esa consulta utilizando el SQL_ID que hemos localizado en el apartado de “SQL ordered by Gets”, es decir, SQL ordenado por lectura de bloques en memoria.
Aquí vemos que el tiempo total de la sentencia no tarda mucho a penas llega el minuto (Elapsed Time 51.900 segundos) pero el valor de lectura de bloques es muy alto: 83Gb.
Otra cosa interesante que nos dice el informe es que se está aplicando un dynamic sampling, es decir, estadísticas al vuelo porque hay alguna tabla que no tiene estadísticas frescas. Habría que revisar cada tabla utilizada y comprobar por cuales se están generando.
Para ver si las estadísticas están frescas, es decir, se corresponden con la volumetría actual de los objetos, hay que ir a la tabla ALL_TAB_STATISTICS y el campo STALE_STATS nos dice si se necesita pasar estadísticas para esa tabla.
Al revisar las estadísticas de las tablas utilizadas en la consulta, vemos que la única que no tiene estadísticas frescas es una tabla temporal.
Analizamos vemos la estimación y los recursos consumidos
Y vemos que se realizan un montón de productos cartesianos.
Desde el punto de vista del optimizador, el join de estas tablas cuando sólo tienen una única fila se realiza de forma más eficiente con un producto cartesiano, es decir, combinar todos con todos o, lo que sería en este caso, combinar únicamente una fila con otra. El problema se produce cuando en la práctica la estimación de una única fila no se corresponde con el volumen real, y se producen combinaciones cartesianas de miles o millones de filas.
En el siguiente capitulo veremos como optimizar la consulta para hacer desaparecer esos productos cartesianos.