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 contar la historia de como una consulta que se lanza por periodos anuales, pasa de no llegar a ejecutarse a tardar 8 segundos. Lo primero que vamos a hacer es generar el tkprof. Con esto vamos a poder determinar qué está sucediendo internamen...
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 contar la historia de como una consulta que se lanza de manera anual, pasa de una ejecución de 24 minutos a 18 segundos.
Lo primero que vamos a hacer es generar el tkprof. Con esto vamos a poder determinar qué está sucediendo internamente en el tiempo de ejecución.
Analizando el tkproff, vemos un índices muy altos al acceder a los datos con un tiempo de ejecución también muy alto, ¡casi 24 minutos de ejecución!
Para poder optimizar un consulta con estos índices tan altos a nivel de cpu, lecturas en disco o de bloques, lo que vamos a hacer es ejecutarlo de manera mensual a ver si nos da una pista de lo que sucede realmente para poder acotar el problema
Si ejecutamos la consulta de manera mensual, los tiempos no son muy elevados en cuanto a la ejecución, pero si a nivel de cpu o bloques leídos, adjunto captura el tkproff
¿Qué está sucediendo realmente? Lo primero que hay que decir que no es una consulta sencilla, es una consulta con unas 1000 líneas de SQL compuesta por cuatro bloques por UNION ALL ¡una monstruosidad!
Analizando en detalle el tkproff vemos muchas operaciones nested loops con más de 100.000 bloques leídos.
Si miramos el árbol de ejecución de cada una de esas operaciones, vemos accesos a tablas pequeñas que leen muchísimos bloques.
Algo raro se cuece dentro que vamos a explicar en el próximo capítulo.