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 cómo hemos tratado una consulta para que la ejecución anual de la misma sea de un tiempo mínimo Lo primero que vamos a hacer es generar el tkprof para un mes, en vez de para un día como se ha realizado otras veces. El mo...
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 un proceso que se lanza a nivel mensual. Este proceso ejecuta n hilos donde cada hilo se ejecuta de manera diaria hasta cubrir el mes. Analizando la ejecución de este proceso, vemos una seria 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 el tiempo de ejecución de cada uno de ellos.
Analizando el tkproff de uno de los hilos vemos una consulta con un índices y una ejecución en tiempo altos
Para la ejecución de un día, tarda unos 30’’ para devolver 1804 filas con más de 3.000.000 de bloques leídos.
Analizando en detalle el tkproff vemos que el siguiente 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 casi 3.000.000 de bloques leídos.
Analizando la SQL y el árbol de ejecución, veo que el problema radica en un índice que se creó. Viendo el uso que se está haciendo de ese índice, no podemos eliminarle ni hacerle invisible para que lo use el CBO, así que optamos por forzar no usarle en la consulta con el hint NO_INDEX.
Ejecutamos la consulta de nuevo con estos tiempos
La ejecución de un día es prácticamente inmediata, no llega al 1’’ la ejecución y la lectura de bloques ha bajado del 1.000.000 de bloques leídos.
El tiempo es bueno, pero el número de bloques leídos es aún alto. En el próximo capitulo abordaremos como hemos conseguido disminuir el número de bloques leídos.