febrero 2026

viernes, 27 de febrero de 2026

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


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.

lunes, 16 de febrero de 2026

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


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.