Cómo Mejorar el Rendimiento Degradado en Oracle RAC: Análisis de Memoria y Eventos de Espera.

ORA-4031, TNS-12637

---

🔬 Diagnóstico clínico: Lentitud severa, errores intermitentes y un RAC al borde del colapso

En esta edición de La Botica del DBA, te comparto un caso real que involucró un entorno de producción crítico, alojado en Oracle Cloud Infrastructure (OCI), sobre infraestructura Exadata. El síntoma inicial era claro: lentitud progresiva, sesiones en espera, y errores intermitentes de conexión (TNS-12637) en múltiples instancias del clúster.

El problema escaló hasta transformarse en una degradación severa del rendimiento.

---

🔬 Primera observación: concurrencia, secuencias y contención

Uno de los focos del problema estaba relacionado con la secuencia ID_REG_RECETARIO.NEXTVAL. Con una configuración inicial de CACHE=10 y más de 26,000 ejecuciones, el diccionario de datos se actualizaba constantemente, generando:

• row cache lock

• buffer busy waits

• enq: TX - index contention

Una sola instancia podía sostener la carga, pero al levantar la segunda del clúster, la presión de concurrencia creaba un efecto dominó.

🧴 Tratamiento aplicado:

ALTER SEQUENCE BOTICARIO.ID_REG_RECETARIO CACHE 1000;

Este simple cambio redujo de 1300 a solo 23 las escrituras en el diccionario de datos por cada 26K valores generados.

---

🧠 Segunda observación: HugePages mal dosificadas = ORA-4031

El siguiente síntoma fue el famoso y temido ORA-4031, con trazas que reportaban fallas al asignar memoria en los heaps de lectura/escritura de In-Memory Column Store (IMC). Las métricas mostraban una configuración deficiente de vm.nr_hugepages.

📌 El entorno requería más de 104K HugePages, pero el sistema operaba con mucho menos, generando:

• Fragmentación de memoria

• Presión durante el startup simultáneo de instancias

• Fallos esporádicos de conectividad

🧪 Diagnóstico confirmado:

grep Hugepagesize /proc/meminfo
# Resultado: 2048 kB

🧾 Herramienta recomendada:

hugepages_settings.sh (Doc ID 401749.1)

💊 Tratamiento sugerido:

• Calcular vm.nr_hugepages adecuadamente

• Aplicar el cambio en una ventana de mantenimiento programada con reinicio

---

🩻 Análisis postmortem (AWR)

El análisis de los reportes AWR confirmó una sobrecarga significativa en la tabla AUD$, reflejada en esperas críticas que impactaban el rendimiento global del clúster:

🔬 Observación de laboratorio:

La causa principal fue una operación de inserción masiva y continua sobre la tabla AUD$, en un entorno donde:

• La auditoría no estaba particionada

• No se aplicaban técnicas de retención ni purga automatizada

• El diseño no estaba optimizado para alto volumen de concurrencia

🔍 Este patrón es más común de lo que parece y puede llevar a síntomas graves de contención en entornos RAC.

📖 ¿Te interesa profundizar en este caso específico?
Consulta el artículo detallado:
➡️ Análisis postmortem con AWR: el caso de la AUD$ desbordada

---

💊 Prescripción final:

Pequeñas dosis de ajuste, gran alivio.

Este caso nos recuerda que los problemas de rendimiento en Oracle RAC no siempre vienen de grandes bugs. A veces, una secuencia sin cachear o una mala configuración de memoria puede detener un entorno entero.

💊 Recomendaciones de La Botica Del DBA:

1. Cachea tus secuencias — especialmente si son muy invocadas

2. Calcula y configura adecuadamente HugePages

3. Monitorea AWR y los Top Events de forma proactiva

4. Evita que AUD$ se convierta en un cuello de botella

5. Haz pruebas de carga con múltiples instancias activas

---

📫 ¿Quieres más recetas Oracle como esta?

Suscríbete a La Botica del DBA para recibir más casos reales, scripts útiles y aprendizajes prácticos desde el quirófano de producción.
📥 Escríbeme a: admin@laboticadeldba.com