Upgrading Oracle RDS 19c to 21c: The Two-Step Path AWS Doesn't Advertise

Why There Is No In-Place Upgrade

On-premises Oracle supports in-place upgrades using the Database Upgrade Assistant (DBUA) or manual upgrade scripts. RDS does not expose the OS or Oracle home directly, so in-place DBUA upgrades are not available. AWS's approach for major version upgrades on RDS Oracle is to restore a snapshot to a new instance running the target version — effectively a migrate-by-restore pattern rather than an upgrade-in-place pattern.

For minor version upgrades within 19c (e.g., 19.0.0.0.ru-2021-01.rur-2021-01.r1 to a newer RU), RDS does support in-place modification. The snapshot-restore path applies to major version jumps: 19c to 21c is the current relevant case, and 19c to 23ai will be the next one.

Note that Oracle 21c is an innovation release, not a long-term support release. Oracle's LTS releases are 19c (through 2027 Premier, 2032 Extended) and 23ai (through 2030 Premier). If you are upgrading primarily to access new 21c features, verify whether those features are also available in 23ai before committing to 21c — you may be upgrading twice in a short window.

Step 1: Pre-Upgrade Validation on the 19c Source

Run Oracle's pre-upgrade information tool against the source database before taking the snapshot. This surfaces compatibility issues that will cause the upgrade to fail or produce an inconsistent state.

-- Connect to the 19c RDS instance and run the pre-upgrade check
-- The preupgrade.jar is available from Oracle's support site
-- On RDS, run via SQL*Plus connected as SYSDBA

-- Run the pre-upgrade checks
@/path/to/preupgrade.sql

-- The output identifies:
-- FIXUPS_REQUIRED: issues that must be resolved before upgrade
-- FIXUPS_RECOMMENDED: issues that should be resolved
-- INFORMATIONAL: items to be aware of

The most common blockers for 19c-to-21c upgrades:

Invalid Objects

-- Count invalid objects by type
SELECT object_type, COUNT(*) AS invalid_count
FROM dba_objects
WHERE status = 'INVALID'
  AND owner NOT IN ('SYS', 'SYSTEM', 'XDB', 'APEX_200200', 'APEX_210100')
GROUP BY object_type
ORDER BY invalid_count DESC;

-- Recompile invalid objects before upgrade
EXEC UTL_RECOMP.RECOMP_PARALLEL(8);  -- 8 parallel recompile workers

-- Verify the count dropped to zero (or near zero for expected exceptions)
SELECT COUNT(*) FROM dba_objects
WHERE status = 'INVALID'
  AND owner NOT IN ('SYS', 'SYSTEM', 'XDB');

Timezone File Version Compatibility

This is the check that most teams miss. Oracle databases have a timezone file version that must be compatible between source and target. RDS 21c ships with a specific timezone file version; if the source 19c database uses a newer timezone file version than what 21c supports, the restore will fail.

-- Check current timezone file version on 19c source
SELECT version FROM v$timezone_file;

-- Check the TSTZ data in the database (timestamps with timezone)
SELECT COUNT(*) FROM dba_tab_columns
WHERE data_type LIKE '%WITH TIME ZONE%';

-- If TSTZ data exists, the timezone file version must be compatible
-- Check Oracle's RDS documentation for supported timezone file versions per engine version

Deprecated Parameters

-- Check for parameters deprecated or removed in 21c
SELECT name, value, description
FROM v$parameter
WHERE name IN (
  'unified_audit_sga_queue_size',  -- deprecated in 21c
  'enable_ddl_logging',            -- behavior changed in 21c
  'optimizer_adaptive_plans',      -- default changed in 21c
  'parallel_degree_policy'         -- default changed in 21c
)
AND value != 'FALSE'
ORDER BY name;

Incompatible Data Dictionary Objects

-- Check for objects in SYS/SYSTEM schema owned by application users
-- (common in legacy databases where developers had excessive privileges)
SELECT owner, object_name, object_type
FROM dba_objects
WHERE object_name IN (
  SELECT object_name FROM dba_objects WHERE owner = 'SYS'
)
AND owner NOT IN ('SYS', 'SYSTEM', 'PUBLIC', 'XDB', 'WMSYS', 'CTXSYS',
                  'DBSNMP', 'APPQOSSYS', 'OJVMSYS', 'ORDSYS', 'ORDDATA')
ORDER BY owner, object_name;

Step 2: The Snapshot Restore Process

Once pre-upgrade validation is clean, the upgrade procedure is:

1. Take a manual snapshot of the 19c RDS instance
2. Restore the snapshot specifying Oracle 21c as the engine version
3. The restored instance runs the Oracle upgrade scripts automatically during first startup
4. Validate the upgraded instance before cutting over application traffic

# AWS CLI: take a manual snapshot before upgrade
aws rds create-db-snapshot \
  --db-instance-identifier mydb-oracle-19c \
  --db-snapshot-identifier mydb-oracle-19c-pre-upgrade-$(date +%Y%m%d)

# Wait for the snapshot to complete
aws rds wait db-snapshot-available \
  --db-snapshot-identifier mydb-oracle-19c-pre-upgrade-$(date +%Y%m%d)

# Restore the snapshot to a new 21c instance
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier mydb-oracle-21c \
  --db-snapshot-identifier mydb-oracle-19c-pre-upgrade-$(date +%Y%m%d) \
  --engine oracle-ee \
  --engine-version 21.0.0.0.ru-2023-01.rur-2023-01.r1 \
  --db-instance-class db.r6i.2xlarge \
  --license-model bring-your-own-license \
  --option-group-name oracle-ee-21 \
  --db-parameter-group-name oracle-ee-21-params \
  --no-multi-az  # start as single-AZ for validation, enable Multi-AZ after cutover

# Monitor the restore and upgrade process
aws rds describe-db-instances \
  --db-instance-identifier mydb-oracle-21c \
  --query 'DBInstances[0].{Status:DBInstanceStatus,Engine:EngineVersion}'

The first startup of the restored 21c instance runs Oracle's upgrade scripts internally. This takes 20–60 minutes depending on database size and the number of installed components. The instance shows as "upgrading" in the RDS console during this period.

Post-Upgrade Validation

-- Verify Oracle version on the new 21c instance
SELECT version, version_full FROM v$instance;

-- Check for invalid objects introduced by the upgrade
SELECT object_type, COUNT(*) AS invalid_count
FROM dba_objects
WHERE status = 'INVALID'
  AND owner NOT IN ('SYS', 'SYSTEM')
GROUP BY object_type
ORDER BY invalid_count DESC;

-- Recompile any remaining invalid objects
EXEC UTL_RECOMP.RECOMP_PARALLEL(8);

-- Check upgrade log for errors
SELECT action_time, action, namespace, version, comments
FROM dba_registry_history
ORDER BY action_time DESC;

-- Verify all installed components are valid
SELECT comp_name, version, status
FROM dba_registry
ORDER BY comp_name;

Downtime Model

The snapshot-restore upgrade model has two phases of downtime:

Phase 1 — Snapshot window: Zero application downtime. The snapshot is taken online; RDS handles the I/O freeze internally. Snapshot time for a 2 TB database is typically 5–15 minutes for the initial snapshot (subsequent snapshots are incremental).

Phase 2 — Cutover window: This is where actual application downtime occurs. The sequence is: stop application writes to 19c, take a final snapshot, restore and upgrade to 21c (20–60 minutes), validate, update DNS/connection strings to point at the new 21c endpoint, resume application traffic.

The total planned downtime is typically 30–90 minutes. You cannot do a zero-downtime upgrade using this path. If zero downtime is a hard requirement, the alternative is Oracle GoldenGate replication from 19c to a pre-built 21c instance, followed by an application-layer cutover — but that requires GoldenGate licensing and significantly more setup.

Parameter Group and Option Group Preparation

Before running the restore, create a 21c-compatible parameter group and option group. Attempting to restore with a 19c parameter group attached to a 21c instance will fail or produce unexpected behavior.

# Create a 21c parameter group
aws rds create-db-parameter-group \
  --db-parameter-group-name oracle-ee-21-params \
  --db-parameter-group-family oracle-ee-21 \
  --description "Oracle EE 21c parameters"

# Copy custom parameters from the 19c group to 21c group
# (there is no direct copy command — export and reimport manually or via script)

# Create a 21c option group
aws rds create-option-group \
  --option-group-name oracle-ee-21 \
  --engine-name oracle-ee \
  --major-engine-version 21 \
  --option-group-description "Oracle EE 21c options"

# Add any options from the 19c option group (e.g., NATIVE_NETWORK_ENCRYPTION, SSL)
aws rds add-option-to-option-group \
  --option-group-name oracle-ee-21 \
  --options OptionName=NATIVE_NETWORK_ENCRYPTION

Rollback Plan

The 19c source instance remains untouched throughout this process — the upgrade operates on a restored copy, not the original. If validation on the 21c instance reveals blocking issues, the rollback is simply keeping applications pointed at the 19c instance and terminating the 21c instance. Keep the pre-upgrade snapshot for at least 30 days after successful cutover before allowing it to expire.