Oracle 19c is Oracle's long-term support release — supported until 2027 for premier support and 2032 for extended support. If you're still on 12c, the clock is ticking. This article walks through the complete upgrade path, pre-checks, and the most common failure points.

## Why Upgrade to 19c

12c premier support ended in July 2021. If you're on 12.1, you're running unsupported software with no security patches. 12.2 extended support ends in March 2025 — most sites are already past that window.

19c brings real operational benefits beyond just support:

- **Automatic indexing** — the database creates, validates, and drops indexes based on workload automatically
- **Real Application Testing improvements** — better SQL Plan Management and SQL Tuning Advisor integration
- **Multitenant at no extra cost** — CDB/PDB architecture available in all editions from 19c onward
- **JSON natively** — JSON_TABLE, JSON_OBJECT, JSON_ARRAYAGG as first-class SQL functions
- **Active Data Guard DML redirection** — read-mostly workloads can redirect writes to primary automatically

## Pre-Upgrade Checklist

Run the Pre-Upgrade Information Tool first. Oracle ships it with every release:

```sql
-- Run from the SOURCE 12c home
cd $ORACLE_HOME/rdbms/admin
java -jar preupgrade.jar TERMINAL TEXT
```

This generates two scripts:
- `preupgrade_fixups.sql` — run in the source DB before upgrade
- `postupgrade_fixups.sql` — run after upgrade completes

**Do not skip these.** The pre-upgrade tool catches invalid objects, deprecated parameters, and timezone version mismatches that will fail your upgrade silently.

Key things to check manually:

```sql
-- Check database version and components
SELECT comp_name, version, status
FROM dba_registry
ORDER BY comp_name;

-- Check for invalid objects
SELECT owner, object_type, COUNT(*)
FROM dba_objects
WHERE status = 'INVALID'
GROUP BY owner, object_type
ORDER BY owner;

-- Check deprecated/desupported parameters
SELECT name, value, description
FROM v$parameter
WHERE name IN (
  'sec_case_sensitive_logon',
  'utl_file_dir',
  'o7_dictionary_accessibility',
  'remote_os_authent',
  'db_block_checksum'
)
AND value != 'FALSE';

-- Check timezone version (must match or upgrade first)
SELECT version FROM v$timezone_file;
SELECT dbms_dst.get_db_version_dst() FROM dual;

-- Check for tables using deprecated types
SELECT owner, table_name, column_name, data_type
FROM dba_tab_columns
WHERE data_type IN ('LONG', 'LONG RAW')
AND owner NOT IN ('SYS','SYSTEM')
ORDER BY owner, table_name;
```

## Upgrade Methods

### Method 1: DBUA (Database Upgrade Assistant)

The GUI-based upgrade tool. Best for non-EBS databases and for DBAs who want a guided experience with automatic rollback on failure.

```bash
# From the 19c ORACLE_HOME
$ORACLE_HOME/bin/dbua
```

DBUA handles the entire upgrade including running fixup scripts, recompiling invalid objects, and updating the data dictionary. It creates a restore point automatically before upgrading.

### Method 2: Manual Upgrade (Recommended for EBS and complex environments)

```bash
# 1. Shut down the source database cleanly
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;

# 2. Start up the database with the 19c binary in UPGRADE mode
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
$ORACLE_HOME/bin/sqlplus / as sysdba
STARTUP UPGRADE;

# 3. Run the upgrade script
@$ORACLE_HOME/rdbms/admin/catupgrd.sql

# 4. Restart normally
SHUTDOWN IMMEDIATE;
STARTUP;

# 5. Run post-upgrade fixups
@$ORACLE_HOME/rdbms/admin/postupgrade_fixups.sql

# 6. Recompile invalid objects
@$ORACLE_HOME/rdbms/admin/utlrp.sql
```

### Method 3: AutoUpgrade (19c+, Recommended for bulk upgrades)

Oracle's AutoUpgrade tool handles the entire lifecycle including pre-checks, upgrade, and post-upgrade fixups in a single automated run with built-in resume capability:

```bash
# Generate a config file
java -jar autoupgrade.jar -create_sample_file config

# Edit config.cfg with your source/target homes and DB details
# Then run in analyze mode first (no changes)
java -jar autoupgrade.jar -config config.cfg -mode analyze

# If analyze passes, run the full upgrade
java -jar autoupgrade.jar -config config.cfg -mode deploy
```

AutoUpgrade is the recommended approach for 19c upgrades — it handles multiple databases in parallel, provides progress monitoring, and can resume from failures.

## For EBS 12.2 Environments

EBS 12.2 on 12c requires additional steps before upgrading the DB tier. The upgrade itself follows the standard Oracle DB upgrade path, but you must:

1. Apply the latest AD-TXK Delta patches before the DB upgrade
2. Run ETCC (EBS Technology Codelevel Checker) and apply all recommended patches post-upgrade
3. Run AutoConfig on both tiers after the upgrade
4. Verify all EBS components: CM, WF Mailer, Apache, WLS

```sql
-- Post-upgrade EBS check: verify APPS schema is valid
SELECT object_type, COUNT(*) invalid_count
FROM dba_objects
WHERE owner = 'APPS'
  AND status = 'INVALID'
GROUP BY object_type
ORDER BY invalid_count DESC;

-- Recompile APPS invalid objects
EXEC UTL_RECOMP.RECOMP_PARALLEL(4, 'APPS');
```

Check MOS Note 1349240.1 (Interoperability Notes: Oracle EBS with Oracle Database 19c) before starting any EBS + 19c upgrade.

## Common Failure Points

**Timezone mismatch** — if the source DB timezone version doesn't match 19c, the upgrade fails with ORA-39405. Fix:

```sql
-- Check current version
SELECT version FROM v$timezone_file;

-- Upgrade timezone (run in source before upgrade)
EXEC DBMS_DST.BEGIN_UPGRADE(32);
-- Follow MOS Note 1585343.1 for the full DST upgrade procedure
```

**Invalid objects in SYS** — any invalid SYS-owned objects must be resolved before upgrade. Run `utlrp.sql` in the source DB and resolve any that remain invalid.

**Parameter changes** — 19c removes or changes the behavior of several parameters. The pre-upgrade tool flags these, but common ones to check:

```sql
-- Parameters removed in 19c (must be removed from spfile/pfile)
ALTER SYSTEM RESET sec_case_sensitive_logon SCOPE=SPFILE;
ALTER SYSTEM RESET utl_file_dir SCOPE=SPFILE;
```

**Supplemental logging** — if you have GoldenGate or LogMiner configured, verify supplemental logging settings survive the upgrade.

## Post-Upgrade Validation

```sql
-- Verify upgrade completed successfully
SELECT name, open_mode, version, status
FROM v$database d, v$instance i
WHERE 1=1;

-- Check all components upgraded
SELECT comp_name, version, status
FROM dba_registry
WHERE status != 'VALID'
ORDER BY comp_name;

-- Run full recompile
@$ORACLE_HOME/rdbms/admin/utlrp.sql

-- Verify no invalid objects remain
SELECT COUNT(*) FROM dba_objects WHERE status = 'INVALID';

-- Run DBMS_STATS to refresh optimizer statistics
EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
```

## Rollback Plan

Always have a rollback path before upgrading production:

1. **Guaranteed Restore Point** — create one before upgrade, flashback if needed (requires ARCHIVELOG mode)
2. **Cold backup** — full RMAN backup of the source database before upgrade
3. **DataPump export** — export critical schemas for logical restore option

```sql
-- Create guaranteed restore point before upgrade
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
CREATE RESTORE POINT pre_19c_upgrade GUARANTEE FLASHBACK DATABASE;

-- To rollback after upgrade (if needed within retention period)
STARTUP MOUNT;
FLASHBACK DATABASE TO RESTORE POINT pre_19c_upgrade;
ALTER DATABASE OPEN RESETLOGS;
```

TuneVault's health checks run automatically after your 19c upgrade — connect your upgraded database to get a baseline score and catch any post-upgrade configuration issues before they impact users.
