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.
Siguiendo el post anterior Ejecuciones que se pierden, vamos a continuar con la optimización de la consulta. Los puntos que vamos a atacar van a ser principalmente intentar reducir la lectura de bloques que se producen en las operaciones nesteed loop...
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)
Esta es la historia de cómo una consulta que se ejecutaba en 33 minutos, se optimizo a 1,44 minutos…
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 lanza n hilos donde cada uno de ellos se ejecuta de manera diaria hasta cubrir el mes. Analizando la ejecución de este proceso, vemos una serie 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 la ejecución de cada uno de ellos.
Analizando el tkproff de uno de los hilos, vemos una consulta con unos índices altos al acceder a los datos pero en cambio el tiempo de ejecución no es muy alto (no llega al segundo) ¡hay algo raro!
Analizando en detalle el tkproff vemos que en la operación 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 más de 10.000 bloques leídos.
Si miramos el árbol de ejecución, vemos que ese salto en bloques leídos se produce en la clausula exists que lleva la consulta.
¿Sería necesario cambiarlo por un IN? Quizás sería lo correcto, porque la consulta principal es más pesada. Vamos a comprobar cómo se comportaría en este caso la consulta cambiando a IN porque según podemos observar el grueso de la ejecución esta en la consulta principal y no en la subconsulta.
Este es el resultado:
Vaya, vemos que el resultado no es el esperado, el cambio a “in” no mejoran los tiempos, así que solo queda una cosa ¡hay que meter mano a la consulta!
Analizando las tablas que se utilizan en la consulta principal y en la subconsulta: condiciones que se utilizan, orden, conversiones… etc. opto por deshacer la subconsulta y subir esas tablas al from principal. El resultado es el siguiente:
Si contrastamos el tkproff original con la restructuración de la consulta, vemos una gran reducción de bloques leídos con un menor consume de CPU
¡Los tiempos mejoran y el acceso a los datos es óptimo! Por lo tanto, el principal problema de esta consulta era de escritura de SQL, modificando la consulta para que se acceda de manera correcta a los datos no solo mejoramos el acceso sino también los tiempos.
En el siguiente capitulo veremos como se comportan el resto de hilos.