Dimensionamiento de Memoria en Oracle

Dimensionamiento de Memoria en Oracle

   marzo 31, 2026       Luis Felipe

---

El rendimiento de una base de datos Oracle no depende de cuánta RAM tengas, sino de cómo la distribuyes. En un entorno de producción, la memoria es un recurso finito y costoso; asignarla en exceso es tan peligroso como quedarse corto, ya que puede inducir problemas de paginación a nivel de OS o enmascarar consultas ineficientes que deberían ser optimizadas en código.

En esta guía aprenderemos a interpretar los Advisors para ajustar la SGA y la PGA utilizando los componentes internos del motor.

Antes de tocar parámetros, debemos entender que es SGA y PGA:

• SGA (System Global Area): Memoria compartida. Su objetivo es minimizar la I/O física (lectura de disco).

• PGA (Program Global Area): Memoria privada por proceso. Su objetivo es realizar ordenamientos y uniones "In-Memory".

• db file sequential read (11.4% del tiempo): Es el tiempo que la base de datos pasa esperando a que el disco le entregue un bloque de datos que no encontró en la memoria. La SGA es demasiado pequeña para el volumen de datos que consultamos. El motor está "trabajando de más" yendo al disco por información que debería estar ya en la RAM.

• acknowledge over PGA limit: Este es un evento "semáforo". Aparece cuando Oracle detiene un proceso porque ya se alcanzó el límite máximo de memoria RAM permitido. El sistema está asfixiado. Literalmente está "poniendo en cola" a los usuarios porque no hay más memoria disponible para procesar sus consultas. Es la confirmación de que nuestra PGA necesita crecer urgentemente.

Diagnostico SGA (V$SGA_TARGET_ADVICE):
Ejecuta la siguiente consulta:

SELECT sga_size, sga_size_factor, estd_db_time, estd_physical_reads
FROM v$sga_target_advice
ORDER BY sga_size_factor;

Si aumentamos la SGA de 30 GB a 45 GB (Factor 1.5):

• Lecturas Físicas: Bajan de 170B a 149B (Una reducción del ~12%).
• Tiempo de DB: Baja de 118M a 114M (Una mejora de apenas el 3.4%).

Necesitamos invertir 15 GB adicionales de RAM para obtener una mejora de velocidad que el usuario final probablemente ni siquiera notará.

Diagnostico PGA(V$PGA_TARGET_ADVICE):
Ejecuta la siguiente consulta:

SELECT pga_target_for_estimate/1024/1024 AS target_mb, 
       pga_target_factor, 
       estd_extra_bytes_rw,
       estd_pga_cache_hit_percentage
FROM v$pga_target_advice;

Si aumentamos la PGA de 10 GB a 18 GB (Factor 1.8):

• Tráfico en Disco (Extra Bytes RW): Baja de 186 TB a 182 TB. Ahorramos 4 Terabytes de escritura innecesaria en el TEMP.

• Eficiencia (Cache Hit %): Sube del 91% al 92%.

Es una inversión inteligente. Con solo 8 GB adicionales de RAM, eliminamos el cuello de botella que causa el evento acknowledge over PGA limit y estabilizamos las operaciones pesadas.

Una vez identificado el tamaño óptimo, aplica los cambios. Recuerda que si usas ASMM (Automatic Shared Memory Management), solo ajustas los targets.

Puedes usar esta consulta para verificar:

SELECT 
    name, 
    value/1024/1024 AS mbytes, 
    CASE 
        WHEN name = 'sga_target' AND value > 0 THEN 'ASMM: Gestión Automática de SGA'
        WHEN name = 'pga_aggregate_target' AND value > 0 THEN 'PGA: Gestión Automática de Procesos'
        WHEN name = 'memory_target' AND value > 0 THEN 'AMM: Gestión Total (SGA + PGA)'
        ELSE 'Gestión Manual / Límite Estricto'
    END AS modo_gestion
FROM v$parameter 
WHERE name IN ('sga_target', 'pga_aggregate_target', 'memory_target', 'pga_aggregate_limit');

En este caso solo redimensionaremos la PGA, dado que tenemos mayor beneficio por un bajo costo (8GB de RAM).

-- 1. Subir el Target
ALTER SYSTEM SET pga_aggregate_target = 18G SCOPE=BOTH;

-- 2.  Lo ideal es que el limit sea al menos 2x el target
ALTER SYSTEM SET pga_aggregate_limit = 36G SCOPE=BOTH; 

La PGA es mucho más flexible. Puedes aplicar los cambios y tendrán efecto inmediato, pero cuidado con el límite (limit), debe ser siempre mayor al target.

IMPORTANTE:

No redimensiones sin validar estos tres puntos:

1. Evitar el Paging: La suma de SGA + PGA + SO nunca debe superar el 80% de la RAM física. Si el SO empieza a usar Swap, el rendimiento de Oracle colapsará.

2. HugePages (Solo Linux): Si tu SGA es mayor a 8GB, asegúrate de configurar HugePages a nivel de kernel para evitar que el proceso vktm consuma demasiada CPU gestionando tablas de páginas.

3. Monitoreo Post-Cambio: Tras el ajuste, monitorea V$SQL_WORKAREA_ACTIVE para confirmar que las operaciones pasaron de MULTI-PASS a OPTIMAL.

La mejor optimización de memoria no es comprar más módulos de RAM, sino reducir la necesidad de ella mediante la indexación correcta y el tuning de sentencias SQL.

Read More