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.
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 don...
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 siguiente consulta del cliente. Es una consulta que se suele consultar a nivel anual, pero como se dispara de tiempos consultando un año vamos a consultarla para un solo día.
Lo primero que vamos hacer es generar el tkprof. 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 este select.
Ahí vemos un posible problema, la consulta internamente realiza un producto cartesiano ¿pero es realmente este el problema? Si miramos en detalle el tiempo de ese MERGE JOIN CARTESIAN es de 6 milisegundos, ¡muy poco tiempo!
Por mucho que asuste un producto cartesiano, tenemos que ver esta información a nivel global. Si vemos, se están combinando 177 filas de la tabla T_TEMP_PARAM con 1 fila, es decir, para Oracle una combinación de 177 filas con 1, la forma más rápida para acceder y recorrer esas filas, es vía producto cartesiano, no hay necesidad de forzar un nested loop o un hash join. Es como si añadiésemos una columna más al conjunto de resultados.
Entonces, ¿dónde se está produciendo grueso de la ejecución? Aquí:
Estas tres operaciones del row source, son realmente las que más consumen, con más de 100.000 bloques leídos en memoria. Otro punto más que nos llama la atención de este cruce es el tiempo, pasamos de 7 milisegundos a 1 segundo.
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.
El acceso a esta tabla particionada se encuentra en la consulta principal, ahí es donde consultamos dicha tabla. Al utilizar el “exists”, estamos haciendo que se accede varias veces a esa tabla en función de los elementos que existan. Entonces, ¿sería correcto usar “exists” o habría que cambiar a “in”?
Hay que tener claro una cosa, cuando nosotros tenemos una select que tiene una subconsulta como es nuestro caso, si es una subconsulta «in” y tenemos que el grueso de la ejecución se lo lleva la select y la subconsulta “in”, tiene poco peso, es decir, que es una consulta ligera, vamos a tener mejor rendimiento utilizando “in” que utilizando “exists”, porque “exists” me va dar un mejor beneficio cuando el grueso de “exists” sea muy grande respecto a una ejecución ligera de la consulta principal.
En este caso, ambas subconsultas son ejecuciones ligeras respecto a la principal con lo que en este caso es mejor usar “in”.
Modificamos esa sentencia cambiando “exists” por “in y ahora la consulta vuela, de un tiempo de CPU de 1,45 a 0.1, prácticamente inmediato.
Además, ¡ha desaparecido el producto cartesiano!