Al estudiar las herramientas de monitorización y análisis de rendimiento disponibles en Oracle, una de las que merece especial atención es Statspack. Esta herramienta permite recopilar estadísticas de rendimiento y generar informes detallados sobre el comportamiento de la base de datos durante un periodo de tiempo determinado y al no requerir licencias adicionales, puede utilizarse en Standard Edition, lo que la convierte en una alternativa especialmente útil para el análisis de rendimiento en entornos donde herramientas como AWR no están disponibles.

La tarea consistía redactar un pequeño diagnóstico analizando los varios fragmentos de un informe Stackpack, asi sin más, sin contexto, a ciegas, solo tú vs métricas. Por tanto, no es un informe completo ni una auditoria pero nos va a servir para una primera toma de contacto con Stackpack para ver qué significan algunas de sus métricas y que conclusiones podemos deducir de ellas.

Estos informes nos proporcionan la información sobre un periodo en el tiempo, pero el trabajo de análisis y diagnóstico corresponde al DBA. Asique vamos con ello, pero antes, recuerda:

"Paso a paso y los problemas de uno en uno" .

Análisis de Stackpack

1. Información básica

• 6 horas de ejecución

• Elapsed: 360 mins

• DB time: 27.96 min → la BD trabajó 27.96 min de las 6 h reales →0.1 av de actives sessions ( 0.077)

• Primera conclusión: no ha tenido mucha caga, la base de datos no está estresada.

2. Top 5 timed events

Primero una breve definición de lo que estamos analizando:

• CPU time: tiempo que oracle pasó ejecutando activamente código en la cpu, representa el tiempo de trabajo real:

  • Ejecución de sentencias SQL, JOINS....

  • Parseo

  • Ejecuciones de PL/SQL

  • Cálculo de planes

• log file sync: evento de espera, tras hacer un commit:

  • Escribe los redo logs

  • Espera confirmacion fisica del disco

  • Devuelve control al user

  • La sesión está esperando a que el LGWR termine de escribir los redo

• direct path read: oracle está leyendo bloques desde disco a la PGA directamente, sin pasar por buffer cache.

  • Ampliar conocimiento

• db file sequencial read: lectura secuencial de bloques individuales( normalmente implica acceso por índice). Un valor alto puede implicar:

  • Nested loops excesivos, índices malo, I/O lento

  • SQL ejecutándose millones de veces

  • Importante mirar → Average wait

  • Tiempos:

    • 0-2 ms : excelente

    • 3-8 ms: normal

    • 10-20 ms: sospechoso

    • >20: storage lento

• Disk file operations I/O: oracle espera operaciones físicas sobre archivos, no necesariamente lecturas de tablas. Muy común en RMAN, autoextend, tempfile creciendo, ASM/filesystem lento. Puede involucrar:

  • Apertura/cierre de datafiles

  • Resize de archivos

  • File metadata

  • Tempfiles

Resumen:

• CPU alta → problemas lógicos (SQL)

• Sequencial read alto → problema de acceso a datos

• Direct path read alto → queries grandes /full scans

• Log files sync alto → problemas de commit/ redo

• Disk file operation i/o → problema infra/storage

Ahora interpretamos los parámetros que acompañan a los eventos

• Waits: cantidad de veces que oracle tuve que esperar ese evento

• Time(S): total tiempo acumulado esperando ese evento ( tiempo total perdido)

• Avgs wait(ms) : tiempo promedio que oracle tardó en cada spera ( es decir, si el recurso responde rápido o lento)

• % total call time: porcentaje del tiempo total de DB Time consumido por ese evento

Volviendo a nuestro informe:

CPU time

• Oracle estuvo 878 segundo ejecutando trabajo

• Conclusión: 58.6% del db time fue cpu → más de la mitad del tiempo fue trabajo efectivo de oracle, no esperas

Log file sync

• 241.888 waits → 242mil eventos de redo log escribiéndose en disco para una bd con solo 27.96 mins de DB time

  • entonces, no estaba sobrecargada pero algo podría estar dando lugar a un elevado numero de commits, checkpoints, escrituras internas

  • conformando el 25.4% del DB Time

• Tiempo consumido = 382 s (6.36 s)

• Avg: probablemente truncado → 1.58 mins x 241.888 = 382 s

  • 2ms para log file sync es bueno

• Conclusión: la infra parece estar sana, el problema puede estar en la aplicación.

Direct path read

• 127 mil operaciones.

• Avg wait excelente.

• Tiempo consumido 146s (2.4 min)

• menos del 10% del tiempo total de oracle

• Conclusión: aunque ocurrió con un frecuencia alta, apenas supone el 10% total.

Segunda conclusión general:

• DB sana a nivel de infraestructura.

• Posibles problemas:

  • de lógica SQL

  • commints frecuentes

  • consultas muy grandes.

3. SQLs de alto impacto

SELECT * FROM ZNOTIFICACIONES

• Elapsed time : tiempo total consumido por todas las ejecuciones

  • 176.91-32.36 = 144.45s que estuvo esperando

• Executions: se ejecutó 108 veces

• Elap per exec : cada ejecución tarda 1.64 s

• Total: consume el 10.5% del tiempo total

• CPU time: solo 32.46 s fueron de cpu

• Physical read: lecturas a disco porque no está en buffer cache  (valor muy alto)

• FECHA_CREACION <= SYSDATE

→ Todo lo creado hasta hoy (probablemente toda la tabla , lo que implicará un Full Scan

→ Sumamos carga al ordenarlo luego por id

• Cada vez que se lanza está leyendo casi 58,633.5 bloques

  • Cada bloque ≃  8KB → 58.633 bloques  x 8KB = aprox 469 MB por ejecución

• Physical Reads totales ≃ 6.332.423 x 8 kb ≃ 48 GB leídos en disco

• Conclusión: 48 GB leídos en disco, excesivo para una select sobre una tabla

DETELE FROM SINCRTMP

• Executions:  número muy elevado de ejecuciones

  • 31900 veces ejecutada cada hora →532 veces cada minuto → se puede estar ejecutando en bucle

• Buffer Gets: lecturas lógicas altísimas

• Gets per executioin → muy alto para borrado usando una clave

• Elapsed time: unos casi 25 min, mucho tiempo

  • Se ejecuta 191.857 veces y cada ejecución lee aproximadamente 1.919 bloques lógicos

  • Tiempo medio de ejecución: 1490.41s / 191.857 = aprox 0.0078s ( 8 ms)

    • 8 ms x 191.857 veces = aprox 1534s (aprox el elapsed time, casi 25 min )

• Tiempo medio de ejecución: 1490.41s / 191.857 = aprox 0.0078s ( 8 ms)

  • 8 ms x 191.857 veces = aprox 1534s (aprox el elapsd time,casi 25 min)

Buffer gets son bloques leídos en memoria, desde buffer cache. No implican disco, pero sí implican trabajo lógico de oracle:

• Buscar bloques

• Recorrer índices

• Comprobar filas

Conclusión: muy probable Oracle está haciendo un Full Scan para cada delete  → problema con el índice, quizás mal definido/inexistente ??

Soluciones:

• Comprimir la tabla.

• Crear un índice por clave.

• Analizar si es posibles reducir esas 191.857 ejecuciones con un sleep para bajar la frecuencia con la que se ejecuta, una vez por minuto por ejemplo, en vez de cada 8 ms.

Análisis de segmentos

Que porcentaje de todas las lecturas lógicas de la bd pertenece a ese objeto.

Los logical reads (buffer gets):

• Bloques leídos desde buffer cache

• Accesos lógicos en memoria oracle

• Conclusiones:

  • Las ejecuciones sobre la tabla ZNOTIFICACIONES genera el 93.9 % de todas las lecturas físicas de la instancia

  • Logical reads = 3.219.424  ≃  Physical Reads= 3.218.456

→ prácticamente cada lectura lógica ha implicado una lectura física a disco

→no está usando bloques en caché

SELECT…. INNER JOIN….

• CPU TIME ≈ Elapsed → la query no espera, consume CPU principalmente

• Ese 36.6% es sobre el trabajo efectivo, esos 27 minutos totales de la bd

• Gets per Exec demasiado alta para una select con filtros

Lo que podemos deducir:

• En cada ejecución leemos esos 2.147 bloques, es decir, nos lo estamos trayendo todo prácticamente en cada ejecución

• la ZSD puede ser una vista

• JOIN en el que probablemente no coincidan FK con PK

• JOIN transformada para que encaje bien

• Se estań completando los valores con 0

• Conclusión: no parece un problema de disco ni esperas, puede ser un problema con las columnas que se utilizan para hacer el join y los filtros.

En mi nuevo camino, aprendiendo a leer e interpretar métricas de informes Stackpack y AWR (quizás haga algún post sobre esto más adelante) , hoy les traigo un poco de teoría, y como estos son apuntes tanto para vosotros, curiosos lectores, como para mi, aqui os dejo un poco de información que quizás os sea útil en algún momento.

La pregunta del verano:

✨ cuál es la diferencia entre db_scattered_read, db_file_sequential_read y direct_path_read ? ✨

La respuesta más corta podría ser:

• db_scattered_read y db_file_sequential_read son eventos de espera generados por lecturas de tablas mediante "full table scan" y lecturas a tablas a partir de un índice, que devuelven un gran número de filas, respectivamente.

• direct_path_read es una lectura de bloques desde disco a la PGA (área de memoria del proceso) sin cargar y almacenar estos bloques en el buffer cahe de la SGA.

Ahora bien, vamos a desarrollar esto un poco más, para los más curiosos y hambrientos de conocimiento.

db_scattered_read* y *db_file_sequential_read

Lo primero a tener en cuenta es que "scattered" y "sequencial" NO hace referencia a cómo se lee fisicamente el db_file, si no, a qué se hace con esas lecturas físicas

• Sequencial es una lectura secuencial de bloques independientes. Hasta que no recupera un bloque, no va al siguiente secuencialmente (normalmente implica acceso por índice). Un valor alto de db_sequential_read puede indicar:

  • demasiados excesos fila a fila

  • nested loops excesivos

  • índices malos

  • sql ejecutándose millones de veces

  • I/O lento

• Scattered es un lectura de multibloque. Esto significa que en una misma operación se leen varios bloques contiguos y los almacena de manera dispersa en el buffer cache, en bloques no contiguos (normalmente indica un Full Table Scan). Un alto valor en db_scattered_read puede indicar:

  • Full Table Scans sobe tablas muy grandes

  • Falta de índices

  • Planes de ejecución ineficientes

direct_path_read

Como su nombre indica, son lecturas de bloques directamente desde el disco a la PGA del proceso, sin pasar por la Buffer Cache del SGA.

Es común encontrarlo en:

• Grandes Full Tables Scans

• Operaciones paralelas

• Procesos de RMAN (backups y restores)

• Hash Joins que procesan grandes volúmenes de datos

Oracle utiliza el direct_path_read cuando estima que cargar los bloques en la buffer cache tendría poco beneficio final, ya que una consulta que lea millones de bloques una única vez desplazaría datos en la cache que sí podrían reutilizar otros procesos.

Resolución de nombres

Cuando un cliente quiere conectarse a la base de datos RAC, usa el nombre SCAN en su conexión. El cliente realiza una consulta DNS para poder resolver el nombre SCAN y el servidor DNS devuelve una de las IPs SCAN (generalmente se hace un balanceo de carga simple tipo Round-Robin entre las IPs SCAN configuradas).

El cliente se conecta a la IP SCAN obtenida, donde uno de los SCAN listeners está escuchando. Cada IP SCAN tiene un listener asociado, y estos listeners se distribuyen en los nodos del cluster para garantizar la alta disponibilidad. El SCAN listener recibe la solicitud de conexión inicial, pero este no gestiona la conexión directamente a las instancias de bases de datos, en cambio, se comunica con los local listeners en los nodos para redirigir la conexion al nodo adecuado.

El SCAN listener consulta el Oracle Cluster Registry (OCR) para obtener el estado de la base de datos y las instancias disponibles, asi como los recursos de carga de trabajo en cada nodo. Basándose en esta información, el SCAN listener redirige la conexión a uno de los local listeners de un nodo específico del cluster que este disponible. El cliente es redirigido a la direccion IP del nodo específico donde se encuentra el local listener.

Una vez conectado al local listener del nodo, el cliente establece la sesion de base de datos con una instancia en ese nodo. Si el nodo está ocupado o sufre un fallo, Oracle RAC y el Clusterware gestionarán el failover de la conexión a otro nodo automáticamente.

Configurar SCAN es un paso esencial en la instalación y configuración de un entorno de RAC, y a continuación veremos paso a paso como hacer dicha configruación.

Let’s go!

1. Configurar SCAN en DNS

Configurar SCAN en el DNS es un paso crítico. El nombre SCAN debe resolver a tres direcciones IP.

• Ejemplo:

  • Si tu SCAN es rac-scan.example.com, debes configurar las siguientes entradas en el DNS

    root@rac-example.localhost:~> nslookup rac-example-scan
    Server:         127.0.0.1
    Address:        127.0.0.1#53
    
    Name:   rac-example-scan
    Address: 192.168.1.101
    Name:   rac-example-scan
    Address: 192.168.1.102
    Name:   rac-example-scan
    Address: 192.168.1.103
    ** server cant find rac-example-scan: SERVFAIL
    

  • Esto significa que el nombre rac-scan.example.com puede resolverse en cualquiera de estas tres direcciones IP, permitiendo que el balanceo de carga distribuya las conexiones entrantes entre ellas.

2. Configurar el entorno de red en los nodos RAC

En cada nodo del clúster RAC, asegúrate de que el entorno de red está correctamente configurado en cada nodo. Esto incluye tener interfaces de red separadas:

• Red pública

• Red privada (interconexión entre nodos)

• IP virtual (SCAN)

  • Asegurando que las direcciones IP de SCAN (192.168.1.101, 192.168.1.102, 192.168.1.103) no estén asignadas a ninguna interfaz física.

• Oracle Grid Infrastructure gestionará estas IPs como IPs virtuales.

3. Instalación y configuración de Oracle Grid Infrastructure

Durante la instalación de Oracle Grid Infrastructure, te pedirá que ingreses el nombre de SCAN. Aquí es donde ingresas rac-scan.example.com.

• Ejemplo de instalación:

  • Al ejecutar el instalador de Oracle Grid Infrastructure, en la sección de configuración de la red:

    SCAN Name: rac-scan.example.com
    SCAN Port: 1521 # o el puerto de escucha predeterminado
    

    • El instalador verificará que rac-scan.example.com resuelve a tres direcciones IP diferentes.

4. Verificar la configuración de SCAN

Después de completar la instalación, puedes verificar que SCAN esté funcionando correctamente. Oracle CRS (Cluster Ready Services) administrará los servicios SCAN y se asegurará de que estén en funcionamiento.

Para verificar que las IPs de SCAN están correctamente registradas y que los listeners de SCAN están en funcionamiento, puedes usar:

srvctl config scan
srvctl config scan_listener
srvctl status scan
srvctl status scan_listener

• Estos comandos te mostrarán la configuración de SCAN, las IPs asociadas, y el estado de los listeners de SCAN.

Oracle nos proporciona códigos de error que nos ayudan a identificar la causa del fallo.

Pero… ¿y si no sabes interpretar esos códigos?

Fue lo primero que pensé cuando empecé a pelearme con la infrastructura. Asi decidí crear mi propia documentación de errores, tan útil como la documentación de soluciones.

ORA-00265

SQL> alter database archivelog;

    ERROR at line 1:

    ORA-00265: instance recovery required, cannot set ARCHIVELOG mode

• la BD no se apagó correctamente

ORA-02097 & ORA-19802

SQL> alter system set db_recovery_file_dest='/mnt/oracle/fast_recovery_area';

    ERROR at line 1:

ORA-02097: parameter cannot be modified because specified value is invalid
ORA-19802: cannot use DB_RECOVERY_FILE_DEST without DB_RECOVERY_FILE_DEST_SIZE

• Antes de especificar un destino para los ARCHIVE LOGs necesitamos especificar un tamaño, eso se hace definiendo el parámetro db_recovery_file_dest_size

ORA-01261 & ORA-01262

Estos errores están relacionados con el parámetro db_recovery_file_dest.

• Oracle no puede acceder o encontrar el directorio especificado para db_recovery_file_dest, ubicación de la Fast Recovery Area (FRA). Esto puede deberse a:

  • Directorio no existe

  • problemas de permisos

  • ruta mal configurada

  • FRA apunta a una ruta mal montada, Oracle verifica permisos y acceso físico

• Verifica el contenido de tu archivo init.ora y busca el parámetro db_recovery_file_dest .

  • Asegúrate de que el directorio especificado exista en el sistema operativo

  • usuario oracle tenga permisos para acceder y escribir en ese directorio.

SQL> startup

ORA-01261: Parameter db_recovery_file_dest destination string is not valid
ORA-01262: Parameter db_recovery_file_dest destination cannot be translated
Errors in file /u01/app/oracle/diag/rdbms/orcl/trace/orcl_ora_12345.trc:
ORA-19802: cannot use DB_RECOVERY_FILE_DEST without DB_RECOVERY_FILE_DEST_SIZE

-- el arranque se detiene en NOMOUNT O MOUNT, sin llegar a abrirse la BD
-- Oracle hace esto antes de abrir los datafiles, si no puede garantizar el acceso al destino
-- de la FRA, no continua el arranque


--Verificalos parametros
show parameter db_recovery_file_dest
show parameter db_recovery_file_dest_size



ALTER SYSTEM SET db_recovery_file_dest_size=10G; 
ALTER SYSTEM SET db_recovery_file_dest='/mnt/oracle/fast_recovery_area'; 

• Error al montar el Filesystem en la FRA

Oracle intenta acceder a una ruta que sí existe como carpeta, pero en realidad está vacía porque el volumen no está montado.

ORA-01261: Parameter db_recovery_file_dest destination string is not valid
ORA-01262: Parameter db_recovery_file_dest destination cannot be translated

Incluso si la BD logra abrirse, los procesos ARC o RMAN intentarán escribir en la FRA. Si en ese momento el filesystem se desmonta o no tiene acceso correcto, se repiten estos errores en el alert.log:

ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 2: No such file or directory

ORA-19809

Cuando se excede el espacio asignado a la FRA (db_recovery_file_dest_size) , y Oracle no puede liberar espacio automáticamente.

ORA-19804

Oracle RMAN (Recovery Manager) no puede reclamar espacio necesario para completar el backup. annot reclaim the space needed to complete the backup.

• Ampliar tamaño

• Eliminar backups antiguos

DPI-1080: connection was closed by ORA-03113

ORA-03113: indica que la conexión se perdió abruptamente entre cliente y servidor.

• Oracle cierra las sesiones de usuarios inactivos (idle). Este error se da en el lado del cliente, no en el servidor.

DPI-1080: es el error correspondiente en el cliente cx_Oracle o ODPI-C (usado por Python, Node.js, etc.).

• Causas comunes:

  • Sesión matada por inactividad

  • Timeout

  • Fallo en el listener o reinicio del servidor

• Revisar en el lado del cliente si el firewall tiene timeouts/idle time en:

  • Firewall

  • VPN setup

  • Load balancer

ORA-12170 Connection Timeout

Indica que el cliente intentó conectarse a la base de datos Oracle, pero no recibió respuesta dentro del tiempo límite configurado. Es básicamente un timeout en la conexión inicial.

• Verificar la conectividad:

# Si usas hostname
ping <nombre_servidor>
# O directamente la IP
ping <ip_servidor>

#Conectividad a nivel de puerto
telnet <host> <puerto>
nc -vz <host> <puerto>
Test-NetConnection -ComputerName <host> -Port <puerto> # (Windows)

# Verificar que el listener esté arriba
lsnrctl status

# Verificar conectividad TNS desde cliente a traves de la capa TNS de Oracle
tnsping <alias_tns>

# Verificar ruta
traceroute <host>
# o en Windows:
tracert <host>

ORA-00600: internal error code, arguments: [...][...][...][...]

Error interno del motor de Oracle. Indica un fallo en una verificación interna o corrupción lógica.

Puedes encontrar mas informacion en alert.log, buscar el trace file en $ORACLE_BASE/diag , e interpretar los arguments para diagnosticar corrupción de bloques, errores de redo o bugs.

• ORA-00600 [2662]: ocurre cuando el SCN leído es menor al SCN requerido, generalmente por un recovery inconsistente.

ORA-01555: snapshot too old

Ocurre cuando una consulta larga intenta leer versiones antiguas de bloques del undo tablespace, pero esos bloques ya fueron sobrescritos.

Vistas que pueden dar mas información:

• v$undostat

• v$transaction

ORA-19502 / ORA-19504

Error en la escritura de backup (RMAN o exportación). Puede ser por:

• Espacio

• Permisos

• Fallos en disco/NFS

Recomendación, verificar:

• Permisos en el destino de backup

• Configuración del db_recovery_file_dest y rman channels

Este post se actualizará periódicamente.

Y tú, que errores conoces?

‘‘ Puedes llevar 20 años trabajando con bases de datos, que si no sabes responder esta sencilla pregunta, no has entendido cómo funcionan realmente las bases de datos, asi que: Qué diferencia hay entre el estado MOUNT y NOMOUNT? “

Pensé en lo que habia aprendido en clase, cuando nos explicaban los diferentes estados en lo que podia encontrarse las bases de datos de Oracle. Pero, sorpresa: no tenia una respuesta directa que dar. En mi mente era texto memorizado y escrito en un examen.

Y así llegó mi primera lección: si no puedes responder a una pregunta sencila sobre cómo funciona internamente una base de datos, de poco sirve lanzar queries o saber hacer un shutdown.

Por tanto, vamos a contestar a esta pregunta, MOUNT y NOMOUNT, he aquí la cuestión.

La respuesta corta es:

“En NOMOUNT arranca y se construye la instancia de Oracle, pero la base de datos no está montada, no es accesible.”

Ahora vamos a documentar un poco más esta lección. Primero, Oracle separa el arranque en varias fases porque su arquitectura tambien está dividida:

• Por una lado tenemos la instancia

• Por otro lado, la base de datos física

Y encontramos tres estados en Oracle, OPEN, MOUNT y NOMOUNT.

NOMOUNT

Es el primer estado de arranque. Se construye la instancia (procesos + áreas de memoria), pero en este punto la instancia todavia no tiene ninguna informacion acerca de los ficheros que componen la base de datos y su estructura (esa informacion se encuentra en los ficheros de control o CONTROLFILES)

Oracle solo lee los archivos de parámetros en $ORACLE_HOME/dbs :

• primero lee spfile.ora

• si no lo encuentra, lee el init.ora

ℹ️ Especificando el PFILE en el comando de arranque STARTUP se puede iniciar con otro PFILE determinado

SQL> STARTUP NOMOUNT PFILE='/home/oracle/my_pfile_.ora';

Este estado se usa para:

• Crear o recuperar archivos de control

• Tareas de mantenimiento que no requieren acceso a los DATAFILES

• Recuperar o crear una base de datos

MOUNT

En este estado, Oracle monta la base de datos, es decir, lee los controls files (parámetro CONTROLFILE) en el archivo de parámetros, que contiene la estructura fisica de la base de datos. Los archivos de control tiene información sobre los:

• DATAFILES

• REDO LOGs

Pero en este punto todavia, los datos todavía no son accesibles.

Se usa para:

• Recuperaciones (recovery)

• Cambiar el modo de archivado (ARCHIVELOG / NOARCHIVELOG)

OPEN

Es el estado operativo final. En este punto, Oracle abre los archivos de datos y los redo logs, la base de datos ya esta lista para poder conectarse, hacer consultas, etc.

Se usa para:

• Conexiones de usuarios

• Consultas y modificaciones de datos (DML)

• Otras operaciones