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

Resolviendo las limitaciones del Auto Optimizer Stats Collection en Oracle

Resolviendo las limitaciones del Auto Optimizer Stats Collection en Oracle

   marzo 20, 2026       Luis Felipe

---

En el mundo de la administración de bases de datos, las estadísticas son la ruta de acceso que el optimizador (CBO) elegirá para ejecutar una sentencia SQL. Sin ellas, hasta la consulta más simple puede convertirse en una pesadilla de rendimiento. Oracle nos ofrece por defecto el Auto Optimizer Stats Collection, un job diseñado gestionar la recolección de estadísticas de forma integral y desatendida. Sin embargo, en entornos de Data Warehouse con volúmenes masivos de datos esto suele ser insuficiente.

Recientemente, en una de las bases de datos que administro, me enfrenté a un escenario crítico: el mantenimiento nativo de Oracle no lograba concluir dentro de la ventana programada de 4 horas. Esto derivaba en la presencia de estadísticas obsoletas (STALE) y el bloqueo de estadísticas en objetos específicos, provocando una degradación progresiva en el rendimiento global de la base de datos.

• El proceso se interrumpía dejando gran parte de los objetos sin procesar.

• Las estadísticas quedaban en un estado inconsistente, impidiendo actualizaciones manuales y disparando errores como el ORA-20005.

• Sin datos frescos, el optimizador elegía rutas de acceso ineficientes, aumentando drásticamente la latencia global del sistema.

Para romper este ciclo, decidimos tomar el control total mediante una automatización personalizada. Nuestra lógica aplica reglas de ingeniería de datos claras:

• El procedimiento identifica si el esquema contiene tablas particionadas o normales para aplicar el método de recolección correcto.

• Priorizamos la última partición vigente, asegurando que el optimizador (CBO) siempre tenga datos frescos de la carga reciente sin desperdiciar recursos en datos históricos estáticos.

• Implementamos una tabla de control para registrar cada inicio, fin y duración, permitiendo una auditoría que el job nativo no ofrece de forma tan detallada.

Importante: Antes de implementar esta solución es necesario desactivar la recolección automática de estadísticas de Oracle. 

Pero antes verificamos el estado actual de la tarea de recolección de estadísticas.

select client_name,status from dba_autotask_client where client_name='auto optimizer stats collection';

Procedemos a desactivar la tarea de recolección automática de Oracle.

BEGIN
  DBMS_AUTO_TASK_ADMIN.DISABLE(
    client_name => 'auto optimizer stats collection',
    operation   => NULL,
    window_name => NULL
  );
END;
/

Verificamos nuevamente el estado actual de la tarea de recolección de estadísticas.

He compartido la solución completa (DDL de bitácora, procedimiento PL/SQL y configuración del Job) en mi repositorio de GitHub para que la comunidad pueda adaptarlo:

🔗Oracle-Stats-Automation

Puedes consultar el estado de tus estadísticas y el rendimiento del job mediante la tabla de bitácora:

select * from sys.gbd_bitacora_estat where grupo=5 order by 1,2 asc;

Esta solución fue desarrollada y validada con éxito en un entorno Oracle Database 12c, demostrando una estabilidad total tanto en la gestión de objetos particionados como en la integración con el Oracle Scheduler. Aunque el enfoque es estándar, se recomienda realizar pruebas previas en entornos de desarrollo antes de pasar a producción.

Read More

Reubicación de la Auditoría Estándar (AUD$) en Oracle

Reubicación de la Auditoría Estándar (AUD$) en Oracle

   marzo 10, 2026       Luis Felipe

---

En entornos de producción, es común que las áreas de Seguridad de la Información exijan auditar las acciones de los usuarios. El objetivo es claro: garantizar el control y la trazabilidad ante incidentes que puedan impactar negativamente al negocio. Sin embargo, habilitar esta auditoría es solo la mitad del trabajo; la otra mitad es gestionarla correctamente para no comprometer la disponibilidad de la base de datos.

Uno de los errores más peligrosos en configuraciones por defecto es permitir que la tabla de auditoría estándar (AUD$) crezca dentro de los tablespaces del sistema (SYSTEM o SYSAUX). Si esta crece sin control, corres el riesgo de fragmentar el diccionario de datos o colapsar la instancia por falta de espacio.

Si la tabla AUD$ crece sin control, corres el riesgo de fragmentar el diccionario de datos o, peor aún, colapsar la instancia por falta de espacio. En este post, te mostraré la forma correcta y soportada de mover la auditoría a un tablespace dedicado utilizando el paquete DBMS_AUDIT_MGMT.

Importante: Este procedimiento es válido únicamente para la Auditoría Tradicional. Si tu base de datos tiene habilitado Unified Auditing (lo cual es el estándar en 19c), los registros se almacenan en el esquema AUDSYS y la gestión del espacio se realiza exclusivamente mediante el paquete DBMS_AUDIT_MGMT.

Lo primero es crear un tablespace exclusivo. Es una buena práctica habilitar el AUTOEXTEND con un límite razonable para evitar sorpresas.

CREATE TABLESPACE TBS_AUDIT DATAFILE '+DATA' SIZE 2G AUTOEXTEND ON NEXT 512M MAXSIZE 30G;

Antes de realizar cambios, debemos validar la ubicación actual de la tabla AUD$:

SELECT table_name, tablespace_name 
FROM dba_tables 
WHERE table_name IN ('AUD$');

Para realizar el movimiento de forma segura y soportada, utilizaremos el procedimiento SET_AUDIT_TRAIL_LOCATION. Este se encarga de mover tanto la tabla como sus índices (LOBs incluidos) sin afectar el diccionario de datos.

BEGIN

DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,

audit_trail_location_value => 'TBS_AUDIT'); 

END;

/

Una vez ejecutado, verifica que el cambio se haya aplicado correctamente consultando nuevamente el diccionario de datos.

SELECT table_name, tablespace_name FROM dba_tables WHERE table_name IN ('AUD$');

Mover la auditoría no es solo una tarea de mantenimiento, es una medida de seguridad operativa. Al separar los logs de auditoría del tablespace SYSTEM, proteges la salud de tu diccionario de datos y facilitas la gestión de purgas futuras.

Nota: Este procedimiento fue probado en la versión 12c de Oracle.

Saludos.

Read More

De 12c a 19c: Guía de Migración y Upgrade mediante RMAN (Método Manual)

De 12c a 19c: Guía de Migración y Upgrade mediante RMAN (Método Manual)

   febrero 27, 2026       Luis Felipe

---

A todos nos ha pasado que, dentro de las tareas que desempeña un DBA, está la de "actualizar la versión del motor" a una superior, ya sea por temas de obsolescencia, bugs, fin de soporte, etc.

Recientemente, me tocó actualizar y migrar hacia otro servidor una de las bases de datos que administro. Esta decisión no fue opcional: la versión 12c ya no cuenta con soporte oficial de Oracle para parches de seguridad y el sistema operativo del servidor original presentaba vulnerabilidades críticas debido a su antigüedad.

Lo primero que realicé fue verificar el modo de operación de la base de datos. Una de las estrategias clave para mantener el mínimo de indisponibilidad (downtime) es trabajar con la base de datos en modo ARCHIVELOG.

¿Por qué es esto vital? Porque nos permite definir un punto de corte claro y realizar el cambio (switchover) de forma controlada. Al tener los archivelogs activos, podemos asegurar que no se pierda ni una sola transacción durante el proceso de movimiento entre servidores.

Luego de ello, me enfoqué en generar el respaldo de la base de datos desde rman, dejo por aquí el código que utilicé, deben reemplaza nombre_de_tu_base por el nombre de la base de datos:

RESPALDO:

         backup_database.sh

export ORACLE_SID=nombre_de_tu_base
export ORACLE_BASE=/oracle/oracle/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/12.2.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH
export NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'
rman target / log=/backups/RMAN/backup_nombre_de_tu_base.log << EOF
run
{
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 4G;
allocate channel c1 device type disk;
allocate channel c2 device type disk;
allocate channel c3 device type disk;
allocate channel c4 device type disk;
backup spfile format '/backups/RMAN/nombre_de_tu_base_spfile_%u';
backup filesperset=4 database format '/backups/RMAN/nombre_de_tu_base_datafiles_%U';
backup current controlfile format '/backups/RMAN/nombre_de_tu_base_control-%U';
backup archivelog all format '/backups/RMAN/nombre_de_tu_base_arc_%U';
release channel c1;
release channel c2;
release channel c3;
release channel c4;
}
exit;
EOF

Ejecutamos el proceso de respaldo con el comando:

nohup sh backup_database.sh &

Un vez finalizado el proceso de respaldo, en el directorio encontraremos archivos nombrados como: nombre_de_tu_base_spfile, nombre_de_tu_base_datafiles, nombre_de_tu_base_control, nombre_de_tu_base_arc.

Procedemos a ejecutar la restauración de la base en un home 19c con el backup generado en la versión 12c.

RESTAURACIÓN:

Creamos un init.ora para nuestra base de datos en el nuevo servidor en la ruta: /oracle/oracle/app/oracle/product/19.0.0/db_home/dbs

            init.ora

*.audit_file_dest='/oracle/oracle/app/oracle/oracle_base/admin/nombre_de_tu_base/adump'
*.audit_trail='db'
*.control_files='+GDATA','+GFRA'
*.db_block_size=8192
*.db_name='nombre_de_tu_base'
*.db_unique_name='nombre_de_tu_base'
*.compatible='12.2.0'
*.db_files=2000
*.db_recovery_file_dest='+GFRA'
*.db_recovery_file_dest_size=2000g
*.diagnostic_dest='/oracle/oracle/app/oracle/oracle_base'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=dbgenXDB)'
*.nls_language='AMERICAN'
*.nls_territory='AMERICA'
*.open_cursors=300
*.pga_aggregate_target=15g
*.processes=2600
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=50g
*.undo_tablespace='UNDOTBS1'

IMPORTANTE: Asegúrate de que el parámetro compatible en tu init.ora sea exactamente el mismo que tenía la base de datos origen (ej. 12.2.0).  

Si no existe, procedemos a crear la carpeta adump:

mkdir /oracle/oracle/app/oracle/oracle_base/admin/nombre_de_tu_base/adump -p

Iniciamos la base de datos en modo no mount:

STARTUP NOMOUNT PFILE='/oracle/oracle/app/oracle/product/19.0.0/db_home/dbs/initdnombre_de_tu_base.ora';

 Restauramos los control file, usualmente el archivo contiene la palabra *control*:

rman target /
restore controlfile from '/backups/RMAN/nombre_de_tu_base_control-gk4b2vc8_1_1';

El paso anterior nos dará la ruta donde se han restaurado los control file, las cuales deberemos copiar y reemplazar en nuestro init.ora

output file name=+GDATA/NOMBRE_DE_TU_BASE/CONTROLFILE/current.261.1219619035
output file name=+GFRA/NOMBRE_DE_TU_BASE/CONTROLFILE/current.508.1219619037 

 Apagamos la base de datos para modificar el init.ora

shutdown immediate;

Modificamos en el init.ora el apartado de *.control_files con las rutas del anterio paso.

vi init.ora

*.control_files='+GDATA/nombre_de_tu_base/CONTROLFILE/current.258.1217774787','+GFRA/nombre_de_tu_base/CONTROLFILE/current.256.1217774787'

Iniciamos la base de datos en modo mount.

STARTUP MOUNT PFILE='/oracle/oracle/app/oracle/product/19.0.0/db_home/dbs/init.ora';

Creamos nuestro SPFILE a partir de nuestro PFILE (init.ora).

 CREATE SPFILE FROM PFILE='/oracle/oracle/app/oracle/product/19.0.0/db_home/dbs/init.ora';

Catalogamos los datafiles desde RMAN.

rman target /
CATALOG START WITH '/backups/RMAN/';

yes

 Sincronizamos el catalogo de respaldos y eliminamos los que se encuentren en estado expirado.

crosscheck backup;
delete noprompt expired backup; 

Sincronizamos el catalogo de archivelogs y eliminamos los que se encuentren en estado expirado.

crosscheck archivelog all;
delete noprompt expired archivelog all;

 Creamos el script bash para restaura la base de datos.

        restore_database.sh

export ORACLE_SID=nombre_de_tu_base
export ORACLE_BASE=/oracle/oracle/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/19.0.0/db_home
export PATH=$ORACLE_HOME/bin:$PATH
export NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'
rman target / log=/oracle/oracle/restore_database.log <<EOF
run
{
allocate channel c1 device type disk;
allocate channel c2 device type disk;
allocate channel c3 device type disk;
allocate channel c4 device type disk;
allocate channel c5 device type disk;
allocate channel c6 device type disk;
allocate channel c7 device type disk;
allocate channel c8 device type disk;
set newname for database to '+GDATA';
restore database;
switch datafile all;
recover database;
release channel c1;
release channel c2;
release channel c3;
release channel c4;
release channel c5;
release channel c6;
release channel c7;
release channel c8;
}
exit;
EOF 

Ejecutamos el proceso de restauración con el comando:

nohup sh restore_database.sh &

Catalogamos los archivelogs y procedemos a aplicar para terminar de sincronizar la base de datos.

rman target /
CATALOG START WITH '/backups/RMAN/ARCHIVELOG';

yes

recover database;

Apagamos la base de datos y la iniciamos en modo UPGRADE para proceder con la actualización.

sqlplus / as sysdba

SHUTDOWN IMMEDIATE;

STARTUP UPGRADE;

exit

IMPORTANTE: No intentes un ALTER DATABASE OPEN RESETLOGS convencional, ya que fallará debido a la diferencia de versiones del diccionario.

ACTUALIZACIÓN:

Con esto podemos iniciar el upgrade de la base de datos, es necesario dar permisos de ejecución al utilitario de upgrade.

chmod u+x $ORACLE_HOME/rdbms/admin/catctl.pl

 Antes de realizar el upgrade, necesitas saber si tu base de datos cumple con los requisitos mínimos. Oracle proporciona un archivo Java llamado preupgrade.jar

$ORACLE_HOME_19c/jdk/bin/java -jar $ORACLE_HOME_19c/rdbms/admin/preupgrade.jar terminal

Ejecutar el utilitario de upgrade database desde linux y guardar la ejecución en un log. Podemos colocarle 4 hilos para que el proceso lo haga en menos tiempo, depende mucho de la capacidad computacional de tu servidor. 

        Con hilos:

nohup $ORACLE_HOME/rdbms/admin/catctl.pl -n 4 $ORACLE_HOME/rdbms/admin/catupgrd.sql > upgrade.log &

         Sin hilos:

nohup $ORACLE_HOME/rdbms/admin/catctl.pl $ORACLE_HOME/rdbms/admin/catupgrd.sql > upgrade.log &

Iniciamos la base de datos, dado que luego de la actualización se queda en estado shutdown.

sqlplus / as sysdba
startup;

Compilamos los objetos inválidos que desde SQLPlus tras la actualización.

@$ORACLE_HOME/rdbms/admin/utlrp.sql

 Ejecutamos la actualización del diccionario desde SQLPlus.

EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

Verificamos el estado final del registro de componentes para asegurarnos que todo quede en estado VALIDO.

COLUMN comp_name FORMAT A40
COLUMN version FORMAT A15
SELECT comp_name, version, status FROM dba_registry;

Cambiamos la compatibilidad a versión 19.0.0.0.0 para aprovechar todas la nuevas funciones que trae esta nueva versión.

ALTER SYSTEM SET compatible = '19.0.0.0.0' SCOPE=SPFILE;

IMPORTANTE: Cambia la compatibilidad a 19.0.0 una vez que el upgrade del diccionario haya finalizado con éxito. Este es el ÚLTIMO paso de todo el proceso.

Reiniciamos la base de datos para que tome efecto el cambio de la compatibilidad.

sqlplus / as sysdba
shutdown immediate;
startup;

Migrar y actualizar una base de datos de producción es siempre un reto que pone a prueba nuestra planificación. Aunque el método manual que hemos visto hoy nos da un control total y un entendimiento profundo de lo que sucede, siempre recomiendo automatizar estos pasos en entornos extensos utilizando la herramienta AutoUpgrade de Oracle.

Saludos,

Luis Felipe.

Read More

Resolviendo el evento de espera: Streams AQ: enqueue blocked on low memory

Resolviendo el evento de espera: Streams AQ: enqueue blocked on low memory

   febrero 16, 2026       Luis Felipe

---

Era uno de esos días en los que me encontraba realizando tareas de respaldo de información de las particiones de tablas de una de las muchas bases de datos que administro.
Noté algo que me llamó la atención: ¿Cómo podían exportarse más de 1,735 particiones de otra base de datos en horas, mientras que las 762 particiones de esta base de datos demoraban días? Sí, leyeron bien: 2 a 3 días para completar la exportación.

Claramente esto no era normal, había algo que estaba afectando el proceso de exportación (EXPDP). Me puse manos a la obra para descubrir cuál era el problema. Inicialmente pensé que era un tema de tamaño de las particiones, por lo que revisé la cantidad de registros y el peso total de cada una, comparándolas con otra base de datos. Sorprendentemente, estas particiones eran más pequeñas, por lo que descarté esa hipótesis.

Generé un reporte AWR para analizar el rendimiento de la base de datos mientras se ejecutaba el proceso de exportación. Grande fue mi sorpresa al encontrar este tipo de espera:

Queueing
(Encolamiento: tiempo que una sesión pasa esperando recursos antes de poder ejecutarse)

Al revisar el top de eventos, identifiqué un evento peculiar que nunca antes había visto: Streams AQ: enqueue blocked on low memory.

Buscando información sobre este evento, encontré la nota de Oracle Support: EXPDP And IMPDP Slow Performance In 11gR2 and 12cR1 And Waits On Streams AQ: Enqueue Blocked On Low Memory (Doc ID 1596645.1)

El documento describía exactamente los síntomas que estaba experimentando:

• Oracle Data Pump Export (expdp) y Import (impdp) funcionan muy lentamente en versiones como 11gR2 y 12cR1

Solución:

Modificar el parámetro STREAMS_POOL_SIZE si no contaba con un valor asignado y luego reiniciar la base de datos para que el cambio surta efecto.

La pregunta siguiente era: ¿Cuánto asignarle? ¿8 MB? ¿16 MB?

En mi búsqueda encontré una consulta dinámica que calcula automáticamente un valor seguro, tomando el valor máximo entre los parámetros streams_pool_size y __streams_pool_size y sumándole 64 MB:

select 'alter system set streams_pool_size='||(max(to_number(trim(c.ksppstvl)))+67108864)||' SCOPE=SPFILE;' from sys.x$ksppi a, sys.x$ksppcv b, sys.x$ksppsv c where a.indx = b.indx and a.indx = c.indx and lower(a.ksppinm) in ('__streams_pool_size','streams_pool_size');

Con esto obtuve el valor recomendado para asignar al parámetro.

1. Conectarse como SYSDBA

sqlplus / as sysdba

2. Modificar el parámetro 

SQL> alter system set streams_pool_size=384m scope=both;

3. Reiniciar la base de datos

SQL> shutdown immediate;

SQL> startup;

4. Verificar el cambio

SQL> show parameter "streams_pool_size";

Luego del cambio:

• La espera Streams AQ: enqueue blocked on low memory desapareció.

• Las exportaciones con Data Pump progresaron con normalidad.

• El rendimiento general mejoró notablemente.

Si alguna vez experimentan exportaciones lentas con Data Pump y detectan el evento de espera: Streams AQ: enqueue blocked on low memory aumentar el parámetro STREAMS_POOL_SIZE siguiendo el procedimiento descrito es la solución más efectiva.

Saludos,

Luis Felipe.

Read More