Fin del soporte de RDS Custom para Oracle

1. Inicio y configuración de una instancia de EC2

   Inicie una instancia de EC2 teniendo en cuenta lo siguiente:

   • Tipo de instancia: elija un tipo de instancia de EC2 que cumpla con los requisitos de recursos de su carga de trabajo. Usar la misma clase de instancia que su instancia de RDS Custom es un buen punto de partida. Tenga en cuenta los requisitos de memoria, CPU y ancho de banda de la red.

   • Sistema operativo: Oracle Linux o Red Hat Enterprise Linux (que coincida o sea compatible con su versión del sistema operativo personalizado de RDS)

   • Software de Oracle: instale el software de Oracle Database (con la misma versión principal, la misma versión secundaria, la misma actualización de versión y, a ser posible, los mismos parches únicos que en RDS Custom). Asegúrese de que el software de Oracle esté instalado en /u01/app/oracle/ o en la ubicación que prefiera.

   • Almacenamiento: configure los volúmenes de Amazon EBS con el tamaño e IOPS adecuados para cumplir con sus requisitos de carga de trabajo. Considere la posibilidad de utilizar los volúmenes gp3 para obtener un rendimiento rentable o io2 Block Express para cargas de trabajo de alto rendimiento.

2. Configuración de la arquitectura de almacenamiento

   1. Almacenamiento en el sistema de archivos (recomendado para la mayoría de los casos)

      • Uso de directorios estándar del sistema de archivos para los archivos de datos de Oracle

      • Más fácil de administrar y adecuado para la mayoría de las cargas de trabajo

      • En esta guía se utilizan ejemplos de almacenamiento de sistemas de archivos

   2. Oracle Automatic Storage Management (ASM)

      • Si su carga de trabajo requiere ASM, instale y configure ASM independiente en la instancia de EC2.

      • Ajuste todos los parámetros de ruta en el archivo de inicialización según corresponda para utilizar grupos de discos ASM (por ejemplo, +DATA, +FRA).

      • El proceso de migración es similar para ASM con ajustes de ruta.

3. Configuración de mecanismo de transferencia de archivos

   Cree un mecanismo para transferir archivos entre las instancias RDS Custom y EC2. Dispone de varias opciones para hacerlo:

   1. Opción A: Amazon S3 (recomendada para la mayoría de los escenarios)

      • Cree un bucket de S3 o utilice uno existente.

      • Instale y configure AWS CLI en las dos instancias.

      • Para obtener instrucciones, consulte Introducción a la AWS CLI.

   2. Opción B: SCP/SFTP directo

      • Si los puertos SSH están abiertos entre instancias, puede transferir archivos directamente.

      • Adecuado para archivos pequeños, como archivos de parámetros y archivos de contraseñas.

   3. Opción C: Amazon EFS

      • Si ya tiene Amazon EFS montado en ambas instancias, puede usarlo como un sistema de archivos compartidos.

      • Adecuado para entornos con infraestructura EFS existente.

      Esta guía utiliza Amazon S3 para los ejemplos, pero puede adaptar los comandos al método que elija.

4. Configuración de la conectividad de red

   Asegúrese de que exista conectividad de red entre las instancias de RDS Custom y EC2:

   • Misma VPC: los grupos de seguridad deben permitir el tráfico bidireccional en el puerto de oyente de Oracle (1521 predeterminado o su puerto personalizado).

   • Diferentes VPC (misma cuenta): configure el emparejamiento de VPC y configure tablas de enrutamiento y grupos de seguridad.

   • Diferentes cuentas: configure el emparejamiento de VPC entre cuentas o utilice AWS Transit Gateway.

   • Compruebe la conectividad: utilice ping y telnet para comprobar la conectividad en el puerto de la DB.

5. Creación de una estructura de directorios en EC2

   La estructura de directorios depende de la arquitectura de su DB:

   ejemplo Para no CDB:

   # Non-CDB directories
   mkdir -p /u01/app/oracle/oradata/ORCL/controlfile/
   mkdir -p /u01/app/oracle/oradata/ORCL/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/onlinelog
   mkdir -p /u01/app/oracle/oradata/ORCL/arch
   mkdir -p /u01/app/oracle/admin/ORCL/adump
   mkdir -p /u01/app/oracle/backup
   # Set ownership
   chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
   chown -R oracle:oinstall /u01/app/oracle/admin/ORCL
   chown -R oracle:oinstall /u01/app/oracle/backup

   ejemplo Para multitenencia (CDB con PDB)

   # CDB directories
   mkdir -p /u01/app/oracle/oradata/ORCL/controlfile/
   mkdir -p /u01/app/oracle/oradata/ORCL/cdb/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/pdbseed/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/onlinelog
   mkdir -p /u01/app/oracle/oradata/ORCL/arch
   mkdir -p /u01/app/oracle/admin/ORCL/adump
   mkdir -p /u01/app/oracle/backup
   # PDB directories (RDS Custom uses OMF with GUID-based paths)
   # Create a generic pdb directory - migration will create subdirectories as needed
   mkdir -p /u01/app/oracle/oradata/ORCL/pdb/datafile
   # Set ownership
   chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
   chown -R oracle:oinstall /u01/app/oracle/admin/ORCL
   chown -R oracle:oinstall /u01/app/oracle/backup

   nota

   RDS Custom para Oracle utiliza Oracle Managed Files (OMF) para los archivos de datos de las PDB con subdirectorios basados en GUID (por ejemplo, /rdsdbdata/db/pdb/RDSCDB_A/{GUID}/datafile/). El proceso de migración creará automáticamente la estructura de subdirectorios necesaria en el destino. Solo tiene que crear los directorios principales.

   Estrategia de almacenamiento: considere la posibilidad de utilizar un volumen de EBS independiente para /u01/app/oracle/backup, a fin de poder desconectarlo y eliminarlo fácilmente una vez finalizada la migración, lo que le permitirá reducir los costes de almacenamiento.

6. Comprobación de la configuración de la DB de origen

1. Inicie sesión en el host de DB personalizado de RDS como usuario de rdsdb y configure el entorno:

   ejemplo

   # For non-CDB
   export ORACLE_HOME=/rdsdbbin/oracle.19.custom.r1.EE.1
   export ORACLE_SID=ORCL
   export PATH=$ORACLE_HOME/bin:$PATH
   
   # For multitenant CDB
   export ORACLE_HOME=/rdsdbbin/oracle.19.custom.r1.EE-CDB.1
   export ORACLE_SID=RDSCDB
   export PATH=$ORACLE_HOME/bin:$PATH

2. Conéctese a la DB y compruebe la arquitectura:

   ejemplo

   sqlplus / as sysdba
   SQL> SELECT name, cdb, open_mode, log_mode FROM v$database;

   ejemplo Para no CDB, resultado esperado

   NAME CDB OPEN_MODE                 LOG_MODE
   --------- --- -------------------- ------------
   ORCL NO  READ  WRITE               ARCHIVELOG

   ejemplo Para multitenencia (CDB), resultado esperado:

   NAME    CDB  OPEN_MODE             LOG_MODE
   --------- --- -------------------- ------------
   RDSCDB    YES READ WRITE           ARCHIVELOG

3. Si tiene una CDB multitenencia, enumere todas las PDB y su estado:

   ejemplo

   SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs;

   Resultado esperado (ejemplo con 1 PDB denominada ORCLDB):

   ejemplo

   CON_ID     NAME                           OPEN_MODE  RES
   ---------- ------------------------------ ---------- ---
   2          PDB$SEED                       READ ONLY  NO
   3          ORCLDB                         READ WRITE NO

4. Compruebe el tamaño total de la DB:

   ejemplo Para no CDB:

   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;

   ejemplo Para multitenencia:

   -- Total CDB size (all containers)
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM cdb_data_files;
   -- Size per PDB
   SQL> SELECT p.name AS pdb_name,
         ROUND(SUM(d.bytes)/1024/1024/1024, 2) AS size_gb
   FROM v$pdbs p
   JOIN cdb_data_files d ON p.con_id = d.con_id
   GROUP BY p.name, p.con_id
   ORDER BY p.con_id;

Plazo habitual

1. Fase de duplicación (la DB de origen permanece en línea): de 30 minutos a varias horas, dependiendo del tamaño de la DB.

2. Fase de validación (el origen permanece en línea): de unas horas a varios días, según sea necesario.

3. Fase de transición (tiempo de inactividad breve): minutos para redirigir las aplicaciones a EC2.

Pasos para la instancia de DB RDS Custom (origen):

1. Pause la automatización de Amazon RDS Custom.

2. Verifique la arquitectura de la DB (no CDB o CDB con PDB).

3. Cree un archivo de contraseñas y un archivo de parámetros a partir de la DB de origen.

4. Copie el archivo de contraseñas y el archivo de parámetros en la instancia de EC2 de destino.

5. Compruebe que la DB de origen se esté ejecutando en modo de registro de archivo.

6. Configure tnsnames.ora en el servidor de DB de RDS Custom.

Pasos de la instancia de DB de EC2 (destino):

1. Edite el archivo de parámetros de EC2 (específico de la arquitectura).

2. Configure tnsnames.ora en EC2.

3. Configure el entorno de la instancia de EC2.

4. Configure el oyente de Oracle en EC2.

5. Inicie la DB en EC2 en estado NOMOUNT.

Pasos de duplicación de RMAN:

1. Realice la duplicación activa de RMAN.

2. Abra la DB (y las PDB multitenencia).

3. Configure la apertura automática de PDB (solo multitenencia).

4. Elimine usuarios y objetos específicos de RDS Custom.

5. Cree SPFILE y configure el inicio automático.

6. Reanude la automatización de Amazon RDS Custom en el origen (si lo mantiene activo).

1. Actualice el nombre de la DB: para multitenencia, cambie todas las apariciones de RDSCDB a ORCL.

2. Convierta rutas de RDS Custom en rutas de EC2: sustituya /rdsdbdata/ por /u01/app/oracle/.

3. Elimine parámetros específicos de RDS Custom.

   • dg_broker_config_file1 y dg_broker_config_file2 (si está presente, indica que existía una réplica)

   • standby_file_management (si está presente)

   • spfile (crearemos un SPFILE nuevo más adelante)

   • Cualquier parámetro log_archive_dest que apunte a un destino en espera (conserve solo log_archive_dest_1 para el archivado local)

4. Añada parámetros de conversión de nombres de archivo (véase más abajo).

5. Ajuste los parámetros de memoria en función del tamaño de la instancia de EC2 (opcional pero recomendable).

El proceso de duplicación activa de RMAN incluye varias fases:

1. Conexión a DB de origen y destino

2. Creación de un SPFILE a partir de la memoria en el destino

3. Restauración del archivo de control en el destino

4. Montaje de la DB de destino

5. Copia de todos los archivos de datos del origen al destino a través de la red (el origen permanece en línea)

6. Recuperación de la DB de destino

7. Apertura de la DB de destino con RESETLOGS

1. Supervisión de resultado de RMAN:

   La sesión RMAN mostrará información detallada sobre el progreso, que incluye:

   • Asignación de canales

   • Progreso de la copia del archivo de datos

   • Tiempo de finalización estimado

   • Bytes procesados

   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00001 name=/rdsdbdata/db/ORCL_A/datafile/system01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/system01.dbf tag=TAG20260303T120000
   channel ORA_AUX_DISK_1: datafile copy complete, elapsed time: 00:05:23
   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00003 name=/rdsdbdata/db/ORCL_A/datafile/sysaux01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/sysaux01.dbf tag=TAG20260303T120000

   ejemplo Ejemplo de código de salida:

   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00001 name=/rdsdbdata/db/ORCL_A/datafile/system01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/system01.dbf tag=TAG20260303T120000
   channel ORA_AUX_DISK_1: datafile copy complete, elapsed time: 00:05:23
   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00003 name=/rdsdbdata/db/ORCL_A/datafile/sysaux01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/sysaux01.dbf tag=TAG20260303T120000

2. Supervisión de las operaciones de larga duración:

   ejemplo En una sesión independiente de SQL*Plus en la instancia de EC2 de destino:

   SQL> SELECT sid, serial#, opname, sofar, totalwork,
          ROUND(sofar/totalwork*100,2) pct_complete,
          time_remaining, elapsed_seconds
   FROM v$session_longops
   WHERE totalwork > 0 AND sofar <> totalwork
   ORDER BY start_time;

   Esta consulta muestra lo siguiente:

   • opname: nombre de la operación (por ejemplo, “RMAN: restauración completa del archivo de datos”)

   • sofar: bloques procesados hasta el momento

   • totalwork: número total de bloques que se van a procesar

   • pct_complete: porcentaje completado

   • time_remaining: segundos restantes estimados

   • elapsed_seconds: tiempo transcurrido hasta el momento

3. Supervisión de los canales de RMAN:

   ejemplo

   SQL> SELECT sid, serial#, context, sofar, totalwork,
          ROUND(sofar/totalwork*100,2) pct_complete
          FROM v$session_longops
   WHERE opname LIKE 'RMAN%'
          AND totalwork > 0
          AND sofar <> totalwork;

4. Comprobación del registro de alertas:

   ejemplo En la instancia de EC2 de destino, supervise el registro de alertas para detectar cualquier error o advertencia:

   tail -f $ORACLE_BASE/diag/rdbms/orcl/ORCL/trace/alert_ORCL.log

   Problemas comunes durante la duplicación de RMAN:

   • Tiempo de espera de la red

     RMAN-03009: failure of duplicate command on ORA_AUX_DISK_1 channel
     ORA-03135: connection lost contact

     Solución: aumente los valores del tiempo de espera de la red en sqlnet.ora en ambas instancias:

     SQLNET.RECV_TIMEOUT=600
     SQLNET.SEND_TIMEOUT=600

   • Espacio insuficiente en el destino

     RMAN-03009: failure of duplicate command
     ORA-19504: failed to create file "/u01/app/oracle/oradata/ORCL/datafile/users01.dbf"
     ORA-27040: file create error, unable to create file
     Linux-x86_64 Error: 28: No space left on device

     Solución: compruebe el espacio disponible y añada más capacidad de volumen de EBS:

     df -h /u01/app/oracle/oradata

   • Errores en el archivo de parámetros

     RMAN-05021: this configuration cannot be used
     RMAN-06004: ORACLE error from auxiliary database: ORA-01261: Parameter db_create_file_dest destination string cannot be translated

     Solución: compruebe que todos los directorios del archivo de parámetros existen y tienen los permisos adecuados.

   • Discrepancia en el archivo de contraseñas

     RMAN-00571: ===========================================================
     RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
     RMAN-00571: ===========================================================
     RMAN-03002: failure of duplicate command at 03/03/2026 12:00:00
     RMAN-06136: ORACLE error from auxiliary database: ORA-01017: invalid username/password; logon denied

     Solución: asegúrese de que el archivo de contraseñas de destino coincida con el de origen y tenga el nombre correcto (orapwORCL).

Pasos de la instancia de DB de RDS Custom (principal):

1. Pause la automatización de Amazon RDS Custom.

2. Verifique la arquitectura de la DB (no CDB o CDB con PDB).

3. Compruebe que la DB principal se está ejecutando en modo de registro de archivo y que FORCE_LOGGING está habilitado.

4. Cree un archivo de contraseñas.

5. Realice una copia de seguridad en línea de la DB principal mediante RMAN (o utilice la duplicación activa).

6. Cree un archivo de parámetros a partir de la DB de origen.

7. Copie los conjuntos de copias de seguridad, el archivo de parámetros y el archivo de contraseñas en la instancia de EC2 de destino.

Pasos de la instancia de DB de EC2 (en espera):

1. Copie todos los archivos del origen en la instancia de EC2.

2. Copie el archivo de contraseñas en la instancia de EC2.

3. Edite el archivo de parámetros de EC2 (específico de la arquitectura).

4. Cree el archivo de parámetros del servidor a partir del archivo de parámetros.

5. Restaure el archivo de control y la DB en espera.

Pasos de configuración de Data Guard:

1. Configure los oyentes de Oracle en ambas instancias.

2. Configure tnsnames.ora en ambas instancias.

3. Inicie el agente de Oracle Data Guard en ambas instancias (opcional, pero recomendable).

4. Habilite la configuración de Oracle Data Guard.

5. Configure fal_server y fal_client en la instancia de reserva de EC2.

6. Configure los archivos de registro de rehacer en espera en ambas instancias.

7. Recupere la instancia en espera.

8. Realice la conmutación manual.

9. Abra la DB (y las PDB multitenencia).

10. Configure la apertura automática de PDB (solo multitenencia).

11. Elimine usuarios y objetos específicos de RDS Custom.

12. Cree SPFILE y configure el inicio automático.

1. Actualice el nombre de la DB: para multitenencia, cambie todas las apariciones de RDSCDB a ORCL.

2. Cambie db_unique_name: de ORCL_A (o RDSCDB_A) a ORCL_B.

3. Convierta rutas de RDS Custom en rutas de EC2: sustituya /rdsdbdata/ por /u01/app/oracle/.

4. Elimine parámetros específicos de RDS Custom.

   • dg_broker_config_file1 y dg_broker_config_file2 (si están presentes)

   • standby_file_management (si está presente)

   • spfile (crearemos un SPFILE nuevo más adelante)

   • Cualquier parámetro log_archive_dest que apunte a destinos en espera.

5. Ajuste los parámetros de memoria en función del tamaño de la instancia de EC2 (opcional pero recomendable).

1. Supervisión de las estadísticas de Data Guard:

   -- Comprehensive Data Guard statistics
   SQL> SELECT name, value, unit, time_computed, datum_time
   FROM v$dataguard_stats
   ORDER BY name;

   Métricas clave que se deben supervisar:

   • retraso en el transporte: diferencia de tiempo entre el momento en que se generó la acción de rehacer en principal y el momento en que se recibió en espera.

   • retraso de aplicación: diferencia de tiempo entre el momento en que se generó la acción de rehacer y el momento en que se aplicó en espera.

   • velocidad de aplicación: velocidad a la que se aplica la acción de rehacer (MB/s).

   • recepción de rehacer: total de acciones de rehacer recibidas por espera.

   • aplicación de rehacer: acciones de rehacer totales aplicadas por espera.

2. Supervisión del envío de registro de archivos:

   En principal (RDS Custom):

   -- Check archive log generation rate
   SQL> SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24') AS hour,
          COUNT(*) AS log_count,
          ROUND(SUM(blocks * block_size)/1024/1024/1024, 2) AS size_gb
   FROM v$archived_log
   WHERE first_time > SYSDATE - 1
   GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD HH24')
   ORDER BY hour;
   
   -- Check archive log destination status
   SQL> SELECT dest_id, status, error, destination
   FROM v$archive_dest
   WHERE status != 'INACTIVE';

   En espera (EC2):

   -- Check archive log apply status
   SQL> SELECT sequence#, first_time, next_time, applied
   FROM v$archived_log
   WHERE applied = 'NO'
   ORDER BY sequence#;
   
   -- Check archive log gap
   SQL> SELECT thread#, low_sequence#, high_sequence#
   FROM v$archive_gap;

3. Supervisión del proceso de recuperación administrado:

   -- Check if managed recovery is running
   SQL> SELECT process, status, thread#, sequence#, block#, blocks
   FROM v$managed_standby
   WHERE process LIKE 'MRP%' OR process LIKE 'RFS%';
   
   -- Check recovery progress
   SQL> SELECT process, status, sequence#,
          TO_CHAR(timestamp, 'YYYY-MM-DD HH24:MI:SS') AS timestamp
   FROM v$managed_standby
   ORDER BY process;

4. Supervisión de la velocidad de aplicación de rehacer para multitenencia:

   En el caso de las DB multitenencia, supervise la velocidad de aplicación por PDB:

   -- Check redo apply rate per container
   SQL> SELECT con_id, name,
          ROUND(SUM(value)/1024/1024, 2) AS redo_applied_mb
   FROM v$con_sysstat cs, v$containers c
   WHERE cs.con_id = c.con_id
     AND cs.name = 'redo size'
   GROUP BY con_id, name
   ORDER BY con_id;

5. Supervisión de los registros de rehacer en espera:

   -- Check standby redo log status
   SQL> SELECT group#, thread#, sequence#, bytes/1024/1024 AS size_mb, status
   FROM v$standby_log
   ORDER BY group#;
   
   -- Check if standby redo logs are being used
   SQL> SELECT group#, thread#, sequence#, status, archived
   FROM v$standby_log
   WHERE status = 'ACTIVE';

6. Estimación de la finalización de sincronización:

   Calcule el tiempo restante en función de la velocidad de aplicación:

   -- Calculate estimated time to catch up
   SQL> SELECT
          ROUND((SELECT value FROM v$dataguard_stats WHERE name = 'apply lag')/60, 2) AS lag_minutes,
          ROUND((SELECT value FROM v$dataguard_stats WHERE name = 'apply rate')/1024, 2) AS apply_rate_mbps,
          ROUND(
            (SELECT value FROM v$dataguard_stats WHERE name = 'apply lag') /
            NULLIF((SELECT value FROM v$dataguard_stats WHERE name = 'apply rate'), 0) / 60,
            2
          ) AS estimated_catchup_minutes
   FROM dual;

1. Compruebe las versiones de zona horaria:

   SELECT * FROM v$timezone_file;
   SELECT PROPERTY_NAME, PROPERTY_VALUE
   FROM database_properties
   WHERE PROPERTY_NAME LIKE '%DST%';

2. Como solución alternativa, defina la variable de entorno del archivo de zona horaria para que coincida con la que tiene disponible su $ORACLE_HOME:

   ls $ORACLE_HOME/oracore/zoneinfo/timezlrg_*.dat
   export ORA_TZFILE=$ORACLE_HOME/oracore/zoneinfo/timezone_40.dat

   Ajuste el número para que coincida con la versión disponible en su instalación.

3. Vuelva a intentar la eliminación:

   sqlplus / as sysdba
   SQL> DROP USER RDSADMIN CASCADE;

1. Compruebe la versión RU exacta tanto en el origen como en la de destino:

   -- On both source and target
   SQL> SELECT * FROM v$version;
   
   SQL> SELECT patch_id, patch_uid, version, action, status, description
   FROM dba_registry_sqlpatch
   ORDER BY action_time DESC;

2. Compruebe el nivel de parche de $ORACLE_HOME:

   # On both instances
   $ORACLE_HOME/OPatch/opatch lsinventory

3. Si las versiones no coinciden, alinéelas antes de la migración aplicando o anulando los parches según sea necesario.

4. Si debe continuar con las RU que no coinciden, ejecute el parche de datos después de la migración:

   cd $ORACLE_HOME/OPatch
   ./datapatch -verbose

5. Compruebe si hay objetos no válidos y repita la compilación:

   SQL> @?/rdbms/admin/utlrp.sql
   
   SQL> SELECT owner, object_type, COUNT(*)
   FROM dba_objects
   WHERE status = 'INVALID'
   GROUP BY owner, object_type;

1. Compruebe que los grupos de seguridad permiten el puerto de forma bidireccional.

2. Compruebe iptables en EC2:

   sudo iptables -L INPUT -n -v

3. Agregue una regla si es necesario:

   # Insert rule before the REJECT rule (typically position 5)
   sudo iptables -I INPUT 5 -p tcp --dport 1521 -j ACCEPT
   
   # For enhanced security, allow only from specific source IPs
   sudo iptables -I INPUT 5 -p tcp -s <RDS_Custom_IP> --dport 1521 -j ACCEPT
   
   # Save rules permanently
   sudo service iptables save

4. Prueba de conectividad:

   telnet <EC2_instance_IP> 1521
   tnsping DB_SOURCE
   tnsping DB_TARGET

1. Compruebe qué archivos de datos faltan:

   SQL> SELECT name, status FROM v$datafile WHERE status != 'ONLINE';

2. Si los archivos se colocaron en el directorio incorrecto, cámbieles el nombre en el archivo de control:

   SQL> ALTER DATABASE RENAME FILE '/wrong/path/datafile.dbf' TO '/correct/path/datafile.dbf';

3. Para evitarlo, compruebe siempre las rutas del archivo de datos de origen SELECT con_id, name FROM v$datafile ORDER BY con_id; antes de configurar el archivo de parámetros.

1. Fuerce el registro del servicio:

   SQL> ALTER SYSTEM REGISTER;

2. Si los servicios siguen sin aparecer, compruebe el parámetro local_listener:

   SQL> SHOW PARAMETER local_listener;

   Asegúrese de que apunta a la dirección correcta del oyente. Si es necesario, actualícelo:

   SQL> ALTER SYSTEM SET local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=<EC2_instance_IP>)(PORT=1521))';
   SQL> ALTER SYSTEM REGISTER;

3. Compruebe con:

   lsnrctl services

1. Compruebe que la espera esté en modo MOUNT:

   SQL> SELECT status FROM v$instance;

2. Compruebe que fal_server y fal_client estén configurados correctamente en espera:

   SQL> SHOW PARAMETER fal_server
   SQL> SHOW PARAMETER fal_client

3. Compruebe la conectividad de la red:

   tnsping ORCL_A # or RDSCDB_A for multitenant

4. Compruebe el parámetro log_archive_dest_2 en los puntos principales que conducen a la espera (si se configura manualmente sin agente).

1. Compruebe la velocidad de aplicación:

   SQL> SELECT name, value, unit FROM v$dataguard_stats WHERE name IN ('apply rate', 'apply lag');

2. Considere aumentar el paralelismo para la aplicación de rehacer (requiere licencia de Active Data Guard):

   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE PARALLEL 4 DISCONNECT FROM SESSION;

3. Compruebe que no haya restricciones de recursos (CPU, E/S) en la instancia de espera.

1. Compruebe y limpie las entradas de registro de archivos obsoletas:

   RMAN> CROSSCHECK ARCHIVELOG ALL;
   RMAN> DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;

2. Vuelva a ejecutar solo la copia de seguridad del registro de archivos:

   RMAN> RUN {
   SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
   BACKUP AS COMPRESSED BACKUPSET
   FILESPERSET 50
   FORMAT '/rdsdbdata/backup/arch_%U'
   ARCHIVELOG ALL;
   }

1. Copia de seguridad final: realice una copia de seguridad final de la instancia de RDS Custom para archivarla.

   # Create final snapshot
   aws rds create-db-snapshot \
     --db-instance-identifier my-custom-instance \
     --db-snapshot-identifier my-custom-instance-final-snapshot \
     --region us-east-1

2. Documente la migración: actualice los manuales de procedimiento y la documentación con la nueva configuración de EC2.

3. Elimine la instancia de RDS Custom: utilice la consola de AWS o la CLI para eliminar la instancia.

   # Delete RDS Custom instance without final snapshot (if already created above)
   aws rds delete-db-instance \
     --db-instance-identifier my-custom-instance \
     --skip-final-snapshot \
     --region us-east-1
   
   # Or create a final snapshot before deletion
   aws rds delete-db-instance \
     --db-instance-identifier my-custom-instance \
     --final-db-snapshot-identifier my-custom-instance-final-snapshot \
     --region us-east-1

4. Limpie los recursos: elimine las instantáneas, los grupos de parámetros y los grupos de opciones asociados si ya no son necesarios.

5. Actualice la documentación: asegúrese de que toda la documentación operativa refleje la nueva arquitectura basada en EC2.

1. Realice una evaluación exhaustiva:

   Antes de iniciar la migración, realice una evaluación exhaustiva de su entorno:

   • Inventario de DB: documente todas las DB, sus tamaños, arquitecturas (no CDB o multitenencia) y dependencias.

   • Dependencias de aplicaciones: identifique todas las aplicaciones que se conectan a la DB y sus métodos de conexión.

   • Referencias de rendimiento: capture las métricas de rendimiento (CPU, memoria, E/S, red) para compararlas después de la migración.

   • Requisitos de copia de seguridad y recuperación: documente el RPO (objetivo de punto de recuperación) y el RTO (objetivo de tiempo de recuperación).

   • Requisitos de conformidad: identifique cualquier requisito reglamentario o de conformidad que pueda afectar a la migración.

2. Elija el tipo de instancia de EC2 adecuado:

   Seleccione un tipo de instancia de EC2 en función de las características de su carga de trabajo:

   Tipo de carga de trabajo	Familia de instancias recomendada	Características clave
   OLTP de uso general	M6i, M6a, M7i	Equilibrio entre potencia de computación, memoria y red
   Uso intensivo de memoria	R6i, R6a, R7i, X2idn	Alta relación entre memoria y CPU
   Uso intensivo de computación	C6i, C6a, C7i	Alto rendimiento de CPU
   Uso intensivo de E/S	I4i, Im4gn	Gran capacidad de almacenamiento local en SSD NVMe
   Cargas de trabajo mixtas	M5, M5a, M5n	Rendimiento equilibrado y rentable

   Directrices de tamaño de instancias:

   • Comience con la misma clase de instancia que su instancia de RDS Custom.

   • Supervise el uso de los recursos durante una migración de prueba.

   • Considera el uso de AWS Compute Optimizer para obtener recomendaciones.

   • Planifique un margen del 20-30 % para el crecimiento y las cargas máximas.

3. Diseñe su arquitectura de almacenamiento:

   Tipos de volumen de EBS:

   Tipo de volumen	Caso de uso	Desempeño	Costo
   gp3	Uso general, la mayoría de las cargas de trabajo	Hasta 16 000 IOPS, 1000 MB/s	Bajo
   io2 Block Express	Misión crítica, alto rendimiento	Hasta 256 000 IOPS, 4000 MB/s	Alto
   Io1	Bases de datos de alto rendimiento	Hasta 64 000 IOPS, 1000 MB/s	Medio-alto
   gp2	Legado de uso general	Hasta 16 000 IOPS	Bajo

   Recomendaciones de diseño de almacenamiento:

   # Recommended layout for production databases
         /u01/app/oracle          # Oracle software (50-100 GB, gp3)
         /u01/app/oracle/oradata  # Data files (sized for database, gp3 or io2)
         /u01/app/oracle/arch     # Archive logs (separate volume, gp3)
         /u01/app/oracle/backup   # Backups (separate volume, gp3, can be detached post-migration)

   Ventajas de los volúmenes separados:

   • Asignación de IOPS independiente

   • Administración de capacidad más sencillo

   • Estrategias simplificadas de copias de seguridad e instantáneas

   • Mejor aislamiento del rendimiento

4. Establezca un plan de reversión:

   Tenga siempre una estrategia de reversión:

   • Mantenga la instancia de RDS Custom en ejecución durante el período de validación (se recomiendan de 1 a 2 semanas).

   • Mantenga copias de seguridad periódicas tanto del origen como del destino.

   • Documente los procedimientos de reversión, incluidos los cambios en la cadena de conexión.

   • Pruebe el proceso de reversión en un entorno que no sea de producción.

   • Defina los criterios de reversión (degradación del rendimiento, incoherencia de los datos, errores de aplicación).

1. Cronometrar la migración:

   Elija el periodo de tiempo óptimo:

   • Periodos de poco tráfico: fines de semana, días festivos u horas de menor actividad.

   • Periodos de mantenimiento: si es posible, ajústelos al mantenimiento programado.

   • Evite los períodos de fin de mes/fin de trimestre: estos períodos suelen tener un alto volumen de transacciones.

   • Tenga en cuenta las zonas horarias: para las solicitudes globales, elija una hora que minimice el impacto en todas las regiones.

2. Plan de comunicación:

   Establezca una comunicación clara.

   • Notificación a las partes interesadas: informe a todas las partes interesadas con al menos 2 semanas de antelación.

   • Equipos de aplicaciones: coordine con los equipos de aplicaciones las actualizaciones de las cadenas de conexión.

   • Actualizaciones de estado: proporcione actualizaciones periódicas durante la migración.

   • Ruta de escalado: defina procedimientos de escalado claros para los problemas.

   • Comunicación posterior a la migración: confirme la finalización satisfactoria y cualquier acción de seguimiento.

3. Puntos de control de validación:

   Implemente la validación en cada etapa:

   Validación previa a la migración:

   -- Capture object counts
   SQL> SELECT object_type, COUNT(*) FROM dba_objects GROUP BY object_type ORDER BY object_type;
   
   -- Capture tablespace usage
   SQL> SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb
   FROM dba_data_files GROUP BY tablespace_name;
   
   -- Capture user counts
   SQL> SELECT COUNT(*) FROM dba_users;
   
   -- For multitenant, capture PDB information
   SQL> SELECT con_id, name, open_mode FROM v$pdbs;

   Validación posterior a la migración:

   -- Verify object counts match
   SQL> SELECT object_type, COUNT(*) FROM dba_objects GROUP BY object_type ORDER BY object_type;
   
   -- Verify no invalid objects
   SQL> SELECT owner, object_type, object_name FROM dba_objects WHERE status = 'INVALID';
   
   -- Verify tablespace usage
   SQL> SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb
   FROM dba_data_files GROUP BY tablespace_name;
   
   -- Verify database size matches
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;
   
   -- For multitenant, verify all PDBs are open
   SQL> SELECT con_id, name, open_mode FROM v$pdbs;

4. Validación del rendimiento:

   Compare las métricas de rendimiento antes y después de la migración:

   -- Capture AWR snapshots before migration (on RDS Custom)
   SQL> EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;
   
   -- After migration (on EC2), compare metrics
   SQL> SELECT snap_id, begin_interval_time, end_interval_time
   FROM dba_hist_snapshot
   ORDER BY snap_id DESC
   FETCH FIRST 10 ROWS ONLY;
   
   -- Generate AWR report for comparison
   SQL> @?/rdbms/admin/awrrpt.sql

   Métricas clave para comparar:

   • Sesiones activas promedio

   • Tiempo de DB por transacción

   • Lecturas físicas por segundo

   • Lecturas físicas por segundo

   • Tamaño de rehacer por segundo

   • Llamadas de usuario por segundo

   • Tiempo de análisis por ejecución

1. Tras la migración, optimice el rendimiento de la DB:

   1. Ajuste del rendimiento de la DB:

      Recopile estadísticas:

      -- Gather dictionary statistics
      SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
      
      -- Gather fixed object statistics
      SQL> EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
      
      -- Gather schema statistics
      SQL> EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SCHEMA_NAME', cascade=>TRUE);
      
      -- For multitenant, gather statistics for each PDB
      SQL> ALTER SESSION SET CONTAINER = PDB_NAME;
      SQL> EXEC DBMS_STATS.GATHER_DATABASE_STATS(cascade=>TRUE);

      Optimice los parámetros de memoria:

      -- Enable Automatic Memory Management (if not already enabled)
      SQL> ALTER SYSTEM SET MEMORY_TARGET = 24G SCOPE=SPFILE;
      SQL> ALTER SYSTEM SET MEMORY_MAX_TARGET = 28G SCOPE=SPFILE;
      SQL> SHUTDOWN IMMEDIATE;
      SQL> STARTUP;
      
      -- Or use Automatic Shared Memory Management
      SQL> ALTER SYSTEM SET SGA_TARGET = 16G SCOPE=SPFILE;
      SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 8G SCOPE=SPFILE;

      Configure la caché de resultados:

      -- Enable result cache for frequently accessed queries
      SQL> ALTER SYSTEM SET RESULT_CACHE_MAX_SIZE = 1G;
      SQL> ALTER SYSTEM SET RESULT_CACHE_MODE = MANUAL;

   2. Optimización del almacenamiento:

      Habilite la compresión:

      -- For tables with infrequent updates
      ALTER TABLE large_table MOVE COMPRESS FOR OLTP;
      
      -- For archive/historical data
      ALTER TABLE archive_table MOVE COMPRESS FOR ARCHIVE HIGH;
      
      -- Rebuild indexes after compression
      ALTER INDEX index_name REBUILD ONLINE;

      Implemente particiones:

      -- For large tables, consider partitioning
      -- Example: Range partitioning by date
      CREATE TABLE sales_partitioned (
          sale_id NUMBER,
          sale_date DATE,
          amount NUMBER
      )
      PARTITION BY RANGE (sale_date) (
          PARTITION sales_2024 VALUES LESS THAN (TO_DATE('2025-01-01', 'YYYY-MM-DD')),
          PARTITION sales_2025 VALUES LESS THAN (TO_DATE('2026-01-01', 'YYYY-MM-DD')),
          PARTITION sales_2026 VALUES LESS THAN (MAXVALUE)
      );

   3. Implemente la supervisión y las alertas:

      Métricas personalizadas de CloudWatch:

      Cree un script para publicar las métricas de Oracle en CloudWatch:

      #!/bin/bash
      # publish_oracle_metrics.sh
      
      INSTANCE_ID=$(ec2-metadata --instance-id | cut -d " " -f 2)
      REGION=$(ec2-metadata --availability-zone | cut -d " " -f 2 | sed 's/[a-z]$//')
      
      # Get tablespace usage
      TABLESPACE_USAGE=$(sqlplus -s / as sysdba << EOF
      SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF
      SELECT ROUND(MAX(percent_used), 2)
      FROM (
           SELECT tablespace_name,
                  ROUND((used_space/tablespace_size)*100, 2) AS percent_used
           FROM dba_tablespace_usage_metrics
      );
      EXIT;
      EOF
      )
      
      # Publish to CloudWatch
      aws cloudwatch put-metric-data \
        --region $REGION \
        --namespace "Oracle/Database" \
        --metric-name "TablespaceUsage" \
        --value $TABLESPACE_USAGE \
        --unit Percent \
        --dimensions InstanceId=$INSTANCE_ID,Database=ORCL
      # Add more metrics as needed (sessions, wait events, etc.)

      Configure las alarmas de CloudWatch:

      # Create alarm for high tablespace usage
      aws cloudwatch put-metric-alarm \
        --alarm-name oracle-high-tablespace-usage \
        --alarm-description "Alert when tablespace usage exceeds 85%" \
        --metric-name TablespaceUsage \
        --namespace Oracle/Database \
        --statistic Maximum \
        --period 300 \
        --evaluation-periods 2 \
        --threshold 85 \
        --comparison-operator GreaterThanThreshold \
        --alarm-actions arn:aws:sns:region:account-id:topic-name

   4. Endurecimiento de la seguridad:

      Seguridad de base de datos:

      -- Enforce password complexity
      ALTER PROFILE DEFAULT LIMIT
          PASSWORD_LIFE_TIME 90
          PASSWORD_GRACE_TIME 7
          PASSWORD_REUSE_TIME 365
          PASSWORD_REUSE_MAX 5
          FAILED_LOGIN_ATTEMPTS 5
          PASSWORD_LOCK_TIME 1;
      
      -- Enable audit
      ALTER SYSTEM SET AUDIT_TRAIL = DB, EXTENDED SCOPE=SPFILE;
      SHUTDOWN IMMEDIATE;
      STARTUP;
      
      -- Audit critical operations
      AUDIT ALL ON SYS.AUD$ BY ACCESS;
      AUDIT CREATE USER BY ACCESS;
      AUDIT DROP USER BY ACCESS;
      AUDIT ALTER USER BY ACCESS;
      AUDIT CREATE SESSION BY ACCESS WHENEVER NOT SUCCESSFUL;

      Seguridad de la red:

      # Restrict SSH access
      sudo vi /etc/ssh/sshd_config
      # Set: PermitRootLogin no
      # Set: PasswordAuthentication no
      
      # Configure firewall
      sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/8" port port="1521" protocol="tcp" accept'
      sudo firewall-cmd --reload
      
      # Enable Oracle Native Network Encryption
      # Edit sqlnet.ora
      SQLNET.ENCRYPTION_SERVER = REQUIRED
      SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)
      SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
      SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)

1. Estrategia de copia de seguridad y recuperación:

   Implemente una estrategia de copia de seguridad integral:

   #!/bin/bash
   # rman_backup.sh - Daily incremental backup script
   
   export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
   export ORACLE_SID=ORCL
   export PATH=$ORACLE_HOME/bin:$PATH
   
   # Backup to local disk
   rman target / << EOF
   RUN {
       ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup/inc_%U';
       BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
       DELETE NOPROMPT OBSOLETE;
       CROSSCHECK BACKUP;
       DELETE NOPROMPT EXPIRED BACKUP;
   }
   EXIT;
   EOF
   
   # Copy backups to S3
   aws s3 sync /u01/app/oracle/backup/ s3://my-oracle-backups/$(date +%Y%m%d)/ \
       --storage-class STANDARD_IA \
       --exclude "*" \
       --include "inc_*" \
       --include "arch_*"
   
   # Clean up local backups older than 7 days
   find /u01/app/oracle/backup/ -name "inc_*" -mtime +7 -delete
   find /u01/app/oracle/backup/ -name "arch_*" -mtime +7 -delete

   Programe copias de seguridad con cron:

   # Edit crontab
   crontab -e
   
   # Add backup schedule
   # Full backup on Sunday at 2 AM
   0 2 * * 0 /home/oracle/scripts/rman_full_backup.sh >> /home/oracle/logs/backup_full.log 2>&1
   
   # Incremental backup Monday-Saturday at 2 AM
   0 2 * * 1-6 /home/oracle/scripts/rman_incremental_backup.sh >> /home/oracle/logs/backup_inc.log 2>&1
   
   # Archive log backup every 4 hours
   0 */4 * * * /home/oracle/scripts/rman_archivelog_backup.sh >> /home/oracle/logs/backup_arch.log 2>&1

1. Evalúe la arquitectura de su DB (no CDB o multitenencia).

2. Elija la opción de migración adecuada en función de sus requisitos de complejidad y tolerancia de tiempo de inactividad.

3. Complete todos los pasos previos, incluida la configuración de la instancia de EC2 y la configuración de la red.

4. Siga los pasos de migración detallados para la opción que elija.

5. Realice pruebas y validaciones exhaustivas.

6. Complete las tareas posteriores a la migración para garantizar que el entorno de producción esté listo.

7. Retire la instancia de RDS Custom tras una validación correcta.