RDS Custom for Oracle end of support

1. Launch and configure EC2 instance

   Launch an EC2 instance with the following considerations:

   • Instance type: Choose an EC2 instance type that meets the resource requirements of your workload. Using the same instance class as your RDS Custom instance is a good starting point. Consider memory, CPU, and network bandwidth requirements.

   • Operating system: Oracle Linux or Red Hat Enterprise Linux (matching or compatible with your RDS Custom OS version)

   • Oracle software: Install Oracle Database software (same major version, minor version, Release Update, and ideally the same one-off patches as RDS Custom). Ensure the Oracle software is installed in /u01/app/oracle/ or your preferred location.

   • Storage: Configure Amazon EBS volumes with appropriate size and IOPS to meet your workload requirements. Consider using gp3 volumes for cost-effective performance or io2 Block Express for high-performance workloads.

2. Configure storage architecture

   1. File system storage (recommended for most scenarios)

      • Use standard file system directories for Oracle data files

      • Simpler to manage and suitable for most workloads

      • This guidance uses file system storage examples

   2. Oracle Automatic Storage Management (ASM)

      • If your workload requires ASM, install and configure standalone ASM on the EC2 instance

      • Adjust all path parameters in the init file accordingly to use ASM disk groups (e.g., +DATA, +FRA)

      • The migration process is similar for ASM, with path adjustments

3. Set up file transfer mechanism

   Create a mechanism to transfer files between RDS Custom and EC2 instances. You have several options:

   1. Option A: Amazon S3 (recommended for most scenarios)

      • Create an Amazon S3 bucket or use an existing one

      • Install and configure Amazon CLI on both instances

      • For instructions, see Getting started with the Amazon CLI.

   2. Option B: Direct SCP/SFTP

      • If SSH ports are open between instances, you can transfer files directly

      • Suitable for small files like parameter files and password files

   3. Option C: Amazon EFS

      • If you already have Amazon EFS mounted on both instances, you can use it as a shared file system

      • Suitable for environments with existing EFS infrastructure

      This guidance uses Amazon S3 for examples, but you can adapt the commands for your chosen method.

4. Configure network connectivity

   Ensure network connectivity between the RDS Custom and EC2 instances:

   • Same VPC: Security groups must allow bidirectional traffic on the Oracle listener port (default 1521, or your custom port)

   • Different VPCs (same account): Set up VPC peering and configure route tables and security groups

   • Different accounts: Set up VPC peering across accounts or use Amazon Transit Gateway

   • Verify connectivity: Use ping and telnet to test connectivity on the database port

5. Create directory structure on EC2

   The directory structure depends on your database architecture:

   Example For Non-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

   Example For Multitenant (CDB with PDBs)

   # 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

   Note

   RDS Custom for Oracle uses Oracle Managed Files (OMF) for PDB data files with GUID-based subdirectories (e.g., /rdsdbdata/db/pdb/RDSCDB_A/{GUID}/datafile/). The migration process will automatically create the necessary subdirectory structure on the target. You only need to create the parent directories.

   Storage strategy: Consider using a separate EBS volume for /u01/app/oracle/backup to easily detach and remove it after migration completes, freeing up storage costs.

6. Verify source database configuration

1. Log in to the RDS Custom database host as the rdsdb user and set the environment:

   Example

   # 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. Connect to the database and check the architecture:

   Example

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

   Example For Non-CDB, expected output

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

   Example For Multitenant (CDB), expected output:

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

3. If you have a multitenant CDB, list all PDBs and their status:

   Example

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

   Expected output (example with 1 PDB named ORCLDB):

   Example

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

4. Check the total database size:

   Example For Non-CDB:

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

   Example For Multitenant:

   -- 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;

Typical timeline

1. Duplication phase (source remains online): 30 minutes to several hours depending on database size

2. Validation phase (source remains online): Hours to days as needed

3. Cutover phase (brief downtime): Minutes to redirect applications to EC2

RDS Custom DB instance (source) steps:

1. Pause Amazon RDS Custom automation

2. Verify database architecture (non-CDB or CDB with PDBs)

3. Create a password file and parameter file from the source database

4. Copy the password file and parameter file to the target EC2 instance

5. Verify the source database is running in archive log mode

6. Configure tnsnames.ora on the RDS Custom DB server

EC2 DB instance (target) steps:

1. Edit the parameter file for EC2 (architecture-specific)

2. Configure tnsnames.ora on EC2

3. Configure the environment for the EC2 instance

4. Configure Oracle Listener on EC2

5. Start the database on EC2 in NOMOUNT state

RMAN duplication steps:

1. Perform RMAN active duplication

2. Open the database (and PDBs for multitenant)

3. Configure PDB auto-open (multitenant only)

4. Remove RDS Custom specific users and objects

5. Create SPFILE and configure automatic startup

6. Resume Amazon RDS Custom automation on source (if keeping it active)

1. Update database name: For multitenant, change all occurrences of RDSCDB to ORCL

2. Convert RDS Custom paths to EC2 paths: Replace /rdsdbdata/ with /u01/app/oracle/

3. Remove RDS Custom-specific parameters

   • dg_broker_config_file1 and dg_broker_config_file2 (if present - indicates a replica existed)

   • standby_file_management (if present)

   • spfile (we'll create a new SPFILE later)

   • Any log_archive_dest parameters pointing to standby destinations (keep only log_archive_dest_1 for local archiving)

4. Add file name conversion parameters (see below)

5. Adjust memory parameters based on your EC2 instance size (optional but recommended)

The RMAN active duplication process includes several phases:

1. Connecting to source and target databases

2. Creating an SPFILE from memory on the target

3. Restoring the control file to the target

4. Mounting the target database

5. Copying all data files from source to target over the network (source remains online)

6. Recovering the target database

7. Opening the target database with RESETLOGS

1. Monitor RMAN output:

   The RMAN session will display detailed progress information including:

   • Channel allocation

   • Datafile copy progress

   • Estimated completion time

   • Bytes processed

   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

   Example output:

   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. Monitor long-running operations:

   Example In a separate SQL*Plus session on the target EC2 instance:

   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;

   This query shows:

   • opname: Operation name (e.g., "RMAN: full datafile restore")

   • sofar: Blocks processed so far

   • totalwork: Total blocks to process

   • pct_complete: Percentage complete

   • time_remaining: Estimated seconds remaining

   • elapsed_seconds: Time elapsed so far

3. Monitor RMAN channels:

   Example

   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. Check alert log:

   Example On the target EC2 instance, monitor the alert log for any errors or warnings:

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

   Common issues during RMAN duplication:

   • Network timeout

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

     Solution: Increase network timeout values in sqlnet.ora on both instances:

     SQLNET.RECV_TIMEOUT=600
     SQLNET.SEND_TIMEOUT=600

   • Insufficient space on target

     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

     Solution: Check available space and add more EBS volume capacity:

     df -h /u01/app/oracle/oradata

   • Parameter file errors

     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

     Solution: Verify all directories in the parameter file exist and have proper permissions.

   • Password file mismatch

     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

     Solution: Ensure the password file on the target matches the source and has the correct name (orapwORCL).

RDS Custom DB instance (primary) steps:

1. Pause Amazon RDS Custom automation

2. Verify database architecture (non-CDB or CDB with PDBs)

3. Confirm the primary database is running in archive log mode and FORCE_LOGGING is enabled

4. Create a password file

5. Perform an RMAN online backup of the primary database (or use active duplication)

6. Create a parameter file from the source database

7. Copy the backup sets, parameter file, and password file to the target EC2 instance

EC2 DB instance (standby) steps:

1. Copy all files from the source to the EC2 instance

2. Copy the password file to the EC2 instance

3. Edit the parameter file for EC2 (architecture-specific)

4. Create the server parameter file from the parameter file

5. Restore standby control file and database

Data Guard configuration steps:

1. Configure Oracle listeners on both instances

2. Configure tnsnames.ora on both instances

3. Start the Oracle Data Guard broker on both instances (optional but recommended)

4. Enable Oracle Data Guard configuration

5. Configure fal_server and fal_client on the EC2 standby instance

6. Configure the standby redo log files on both instances

7. Recover the standby instance

8. Perform the manual switchover

9. Open the database (and PDBs for multitenant)

10. Configure PDB auto-open (multitenant only)

11. Remove RDS Custom specific users and objects

12. Create SPFILE and configure automatic startup

1. Update database name: For multitenant, change all occurrences of RDSCDB to ORCL

2. Change db_unique_name: From ORCL_A (or RDSCDB_A) to ORCL_B

3. Convert RDS Custom paths to EC2 paths: Replace /rdsdbdata/ with /u01/app/oracle/

4. Remove RDS Custom-specific parameters

   • dg_broker_config_file1 and dg_broker_config_file2 (if present)

   • standby_file_management (if present)

   • spfile (we'll create a new SPFILE later)

   • Any log_archive_dest parameters pointing to standby destinations

5. Adjust memory parameters based on your EC2 instance size (optional but recommended)

1. Monitor Data Guard statistics:

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

   Key metrics to monitor:

   • transport lag: Time difference between when redo was generated on primary and received on standby

   • apply lag: Time difference between when redo was generated and applied on standby

   • apply rate: Rate at which redo is being applied (MB/sec)

   • redo received: Total redo received by standby

   • redo applied: Total redo applied by standby

2. Monitor archive log shipping:

   On the primary (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';

   On the standby (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. Monitor managed recovery process:

   -- 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. Monitor redo apply rate for multitenant:

   For multitenant databases, monitor apply rate per 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. Monitor standby redo logs:

   -- 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. Estimate synchronization completion:

   Calculate the remaining time based on apply rate:

   -- 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. Check the timezone versions:

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

2. As a workaround, set the timezone file environment variable to match what your $ORACLE_HOME has available:

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

   Adjust the number to match the version available in your installation.

3. Retry the drop:

   sqlplus / as sysdba
   SQL> DROP USER RDSADMIN CASCADE;

1. Check the exact RU version on both source and target:

   -- 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. Verify the $ORACLE_HOME patch level:

   # On both instances
   $ORACLE_HOME/OPatch/opatch lsinventory

3. If versions don't match, align them before migration by applying or rolling back patches as needed.

4. If you must proceed with mismatched RUs, run datapatch after migration:

   cd $ORACLE_HOME/OPatch
   ./datapatch -verbose

5. Check for invalid objects and recompile:

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

1. Verify security groups allow the port bidirectionally

2. Check iptables on EC2:

   sudo iptables -L INPUT -n -v

3. Add rule if needed:

   # 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. Test connectivity:

   telnet <EC2_instance_IP> 1521
   tnsping DB_SOURCE
   tnsping DB_TARGET

1. Check which data files are missing:

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

2. If the files were placed in the wrong directory, rename them in the control file:

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

3. To prevent this, always verify the source data file paths with SELECT con_id, name FROM v$datafile ORDER BY con_id; before configuring the parameter file.

1. Force service registration:

   SQL> ALTER SYSTEM REGISTER;

2. If services still don't appear, check the local_listener parameter:

   SQL> SHOW PARAMETER local_listener;

   Ensure it points to the correct listener address. If needed, update it:

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

3. Verify with:

   lsnrctl services

1. Verify the standby is in MOUNT mode:

   SQL> SELECT status FROM v$instance;

2. Check fal_server and fal_client are set correctly on the standby:

   SQL> SHOW PARAMETER fal_server
   SQL> SHOW PARAMETER fal_client

3. Verify network connectivity:

   tnsping ORCL_A # or RDSCDB_A for multitenant

4. Check the log_archive_dest_2 parameter on the primary points to the standby (if configured manually without broker).

1. Check the apply rate:

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

2. Consider increasing parallelism for redo apply (requires Active Data Guard license):

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

3. Verify there are no resource constraints (CPU, I/O) on the standby instance.

1. Crosscheck and clean up stale archive log entries:

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

2. Re-run just the archive log backup:

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

1. Final backup: Take a final backup of the RDS Custom instance for archival purposes

   # 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. Document the migration: Update runbooks and documentation with the new EC2 configuration

3. Delete the RDS Custom instance: Use the Amazon Console or CLI to delete the instance

   # 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. Clean up resources: Remove associated snapshots, parameter groups, and option groups if no longer needed

5. Update documentation: Ensure all operational documentation reflects the new EC2-based architecture

1. Conduct a thorough assessment:

   Before starting the migration, perform a comprehensive assessment of your environment:

   • Database inventory: Document all databases, their sizes, architectures (non-CDB vs multitenant), and dependencies

   • Application dependencies: Identify all applications connecting to the database and their connection methods

   • Performance baseline: Capture performance metrics (CPU, memory, I/O, network) for comparison post-migration

   • Backup and recovery requirements: Document RPO (Recovery Point Objective) and RTO (Recovery Time Objective)

   • Compliance requirements: Identify any regulatory or compliance requirements that may affect the migration

2. Choose the right EC2 instance type:

   Select an EC2 instance type based on your workload characteristics:

   Workload Type	Recommended Instance Family	Key Characteristics
   General purpose OLTP	M6i, M6a, M7i	Balanced compute, memory, and network
   Memory-intensive	R6i, R6a, R7i, X2idn	High memory-to-CPU ratio
   Compute-intensive	C6i, C6a, C7i	High CPU performance
   I/O-intensive	I4i, Im4gn	High local NVMe SSD storage
   Mixed workloads	M5, M5a, M5n	Cost-effective balanced performance

   Instance sizing guidelines:

   • Start with the same instance class as your RDS Custom instance

   • Monitor resource utilization during a test migration

   • Consider using Amazon Compute Optimizer for recommendations

   • Plan for 20-30% headroom for growth and peak loads

3. Design your storage architecture:

   EBS volume types:

   Volume Type	Use Case	Performance	Cost
   gp3	General purpose, most workloads	Up to 16,000 IOPS, 1,000 MB/s	Low
   io2 Block Express	Mission-critical, high-performance	Up to 256,000 IOPS, 4,000 MB/s	High
   Io1	High-performance databases	Up to 64,000 IOPS, 1,000 MB/s	Medium-High
   gp2	Legacy general purpose	Up to 16,000 IOPS	Low

   Storage layout recommendations:

   # 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)

   Benefits of separate volumes:

   • Independent IOPS allocation

   • Easier capacity management

   • Simplified backup and snapshot strategies

   • Better performance isolation

4. Establish a rollback plan:

   Always have a rollback strategy:

   • Keep RDS Custom instance running during validation period (1-2 weeks recommended)

   • Maintain regular backups of both source and target

   • Document rollback procedures including connection string changes

   • Test rollback process in a non-production environment

   • Define rollback criteria (performance degradation, data inconsistency, application errors)

1. Timing your migration:

   Choose the optimal time window:

   • Low-traffic periods: Weekends, holidays, or off-peak hours

   • Maintenance windows: Align with scheduled maintenance if possible

   • Avoid month-end/quarter-end: These periods typically have high transaction volumes

   • Consider time zones: For global applications, choose a time that minimizes impact across regions

2. Communication plan:

   Establish clear communication:

   • Stakeholder notification: Inform all stakeholders at least 2 weeks in advance

   • Application teams: Coordinate with application teams for connection string updates

   • Status updates: Provide regular updates during migration

   • Escalation path: Define clear escalation procedures for issues

   • Post-migration communication: Confirm successful completion and any follow-up actions

3. Validation checkpoints:

   Implement validation at each stage:

   Pre-migration validation:

   -- 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;

   Post-migration validation:

   -- 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. Performance validation:

   Compare performance metrics before and after migration:

   -- 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

   Key metrics to compare:

   • Average active sessions

   • DB time per transaction

   • Physical reads per second

   • Logical reads per second

   • Redo size per second

   • User calls per second

   • Parse time per execute

1. After migration, optimize database performance:

   1. Database performance tuning:

      Gather statistics:

      -- 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);

      Optimize memory parameters:

      -- 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 result cache:

      -- 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. Storage optimization:

      Enable compression:

      -- 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;

      Implement partitioning:

      -- 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. Implement monitoring and alerting:

      CloudWatch custom metrics:

      Create a script to publish Oracle metrics to 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.)

      Set up CloudWatch alarms:

      # 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. Security hardening:

      Database security:

      -- 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;

      Network security:

      # 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. Backup and recovery strategy:

   Implement comprehensive backup strategy:

   #!/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

   Schedule backups with 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. Assess your database architecture (non-CDB or multitenant)

2. Choose the appropriate migration option based on your downtime tolerance and complexity requirements

3. Complete all prerequisite steps including EC2 instance setup and network configuration

4. Follow the detailed migration steps for your chosen option

5. Perform thorough validation and testing

6. Complete post-migration tasks to ensure production readiness

7. Decommission the RDS Custom instance after successful validation