Oracle 19c to 26ai Upgrade: Step-by-Step Migration Guide

Oracle 19c is the most widely deployed Oracle version in enterprise environments today — stable, mature, and still under Premier Support until April 2024 (extended support through 2027). Oracle Database 26ai, released in 2026, is not just the next version number — it is the first Oracle release that fundamentally changes what a database can do, adding native AI vector search, in-database LLM inference, and a converged data model that handles relational, JSON, graph, and vector data in a single engine. This guide covers the complete upgrade path from Oracle 19c to 26ai — from the pre-upgrade assessment to enabling AI features after go-live.

1. Should You Upgrade Now?

Before planning the upgrade, the honest answer to this question depends on your situation. Oracle 26ai is production-ready, but not every organization needs to be on the latest version immediately.

Upgrade now if:

• You want to use Oracle's native AI features — vector search, in-database LLM, Select AI, RAG patterns on ERP data
• Your Oracle 19c extended support window is approaching and you want to stay current
• You are planning new application development that can benefit from 26ai features
• You are migrating from an older version (12c, 11g) and can go directly to 26ai
• Your vendor has certified their application for Oracle 26ai

Wait if:

• Your critical application (ERP, banking core, manufacturing system) has not been vendor-certified for Oracle 26ai yet
• You are in a regulated environment (pharma, banking) and the validation cycle for a version upgrade would be too disruptive right now
• You recently completed a major upgrade and your team needs stability
• Your Oracle 19c support window still has 12+ months remaining

If you are staying on 19c for now, plan the 26ai upgrade timeline today — do not wait until you are under support pressure to make a rushed decision.

2. Understanding the Upgrade Paths

Oracle supports direct upgrade from 19c to 26ai. If you are on an older version, your path depends on your starting point:

From Version	Direct to 26ai?	Recommended Path
19c	✅ Yes — direct	19c → 26ai (DBUA or manual)
21c	✅ Yes — direct	21c → 26ai (DBUA or manual)
12.2	⚠️ Via 19c first	12.2 → 19c → 26ai
12.1	❌ Not direct	12.1 → 19c → 26ai
11g	❌ Not direct	11g → 19c → 26ai (or export/import)

3. Pre-Upgrade Phase (2–3 Weeks Before)

A rushed upgrade is a dangerous upgrade. The pre-upgrade phase is where most of the actual work happens — the upgrade itself, if preparation is thorough, takes a few hours.

3.1 Run the Pre-Upgrade Information Tool

Oracle provides a Pre-Upgrade Information Tool (preupgrade.jar) that must be run against the source database. It identifies compatibility issues, deprecated features, and required actions before the upgrade can proceed.

-- Run the Pre-Upgrade Information Tool from 26ai Oracle Home
-- against the running 19c database
$ORACLE_HOME_26AI/jdk/bin/java \
  -jar $ORACLE_HOME_26AI/rdbms/admin/preupgrade.jar \
  FILE DIR /tmp/preupgrade_output

-- Review the output files:
-- /tmp/preupgrade_output/preupgrade.log  -- findings and recommendations
-- /tmp/preupgrade_output/preupgrade_fixups.sql  -- fixup scripts to run BEFORE upgrade
-- /tmp/preupgrade_output/postupgrade_fixups.sql -- fixup scripts to run AFTER upgrade

Read every line of the preupgrade.log. Every WARNING must be understood. Every ERROR must be resolved before proceeding. Do not skip this step.

3.2 Run Pre-Upgrade Fixup Scripts

-- Connect to 19c database and run pre-upgrade fixups
sqlplus / as sysdba
SQL> @/tmp/preupgrade_output/preupgrade_fixups.sql

3.3 Check Application and Driver Compatibility

• JDBC drivers: Ensure your application JDBC driver version is compatible with Oracle 26ai. Oracle recommends using the same version JDBC driver as the database
• Application compatibility: Verify with your ERP or application vendor that their product is certified on Oracle 26ai. This is non-negotiable for production upgrades
• PL/SQL packages: Check for use of deprecated or desupported built-in packages
• Partitioning and advanced features: Confirm any features you use are supported and behave identically in 26ai

3.4 Gather Optimizer Statistics

-- Gather fresh statistics on the source database before upgrade
-- The new Oracle 26ai optimizer needs accurate statistics to perform well
EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
EXEC DBMS_STATS.GATHER_DATABASE_STATS(
  options         => 'GATHER STALE',
  degree          => 8,
  cascade         => TRUE
);

3.5 Purge the Recycle Bin

-- Empty the recycle bin (speeds up upgrade significantly)
SQL> PURGE DBA_RECYCLEBIN;

3.6 Invalid Objects Baseline

-- Record invalid objects BEFORE upgrade (compare after)
SELECT owner, object_type, COUNT(*) AS invalid_count
FROM DBA_OBJECTS
WHERE status = 'INVALID'
GROUP BY owner, object_type
ORDER BY owner, object_type;

SPOOL /tmp/invalid_before_upgrade.txt
/
SPOOL OFF

3.7 Take a Full RMAN Backup

This is mandatory — not optional. Take a full RMAN backup of the 19c database immediately before the upgrade. This is your rollback option if the upgrade fails after it has started modifying the database.

RMAN> BACKUP AS COMPRESSED BACKUPSET
        DATABASE PLUS ARCHIVELOG
        TAG 'PRE_26AI_UPGRADE';
RMAN> BACKUP CURRENT CONTROLFILE TAG 'PRE_26AI_UPGRADE_CF';

3.8 Rehearse on a Clone — Always

In my 18+ years I have never run a major version upgrade in production without first running the identical upgrade on an RMAN-restored clone. Not a schema copy — a full restore of the actual production database onto a test server, upgraded with the exact same steps and scripts I plan to use on the night.

A rehearsal like this once saved a client of mine a very bad weekend. The preupgrade report on their ERP database had flagged a handful of deprecated initialization parameters as warnings — the kind of finding a busy DBA mentally files under "later". On the rehearsal clone, the upgraded instance refused to start cleanly until those parameters were removed from the spfile. Fixing that took twenty minutes on a Tuesday afternoon in test. Discovering it at 2 AM inside a production window, with the business waiting, would have been a very different conversation.

The rehearsal also gives you the one number nobody can estimate from documentation: how long your database actually takes to upgrade. That number is what you build the production window around.

4. The Upgrade Methods

4.1 Method 1: DBUA (Database Upgrade Assistant) — GUI

DBUA is Oracle's graphical upgrade tool. It guides you through each step, runs pre-checks automatically, and provides a progress interface. Best for DBAs who prefer a guided process and want fewer manual steps. DBUA also generates a detailed upgrade log and supports automatic rollback if a critical failure occurs.

# Launch DBUA from the 26ai Oracle Home
$ORACLE_HOME_26AI/bin/dbua

DBUA will detect existing databases, run compatibility checks, and walk you through the upgrade interactively. Select the source 19c database, review the findings, accept or resolve issues, then start the upgrade.

4.2 Method 2: Manual Upgrade (Command Line)

Manual upgrade gives the DBA full visibility and control over every step. Preferred in production environments where DBAs want to understand exactly what is happening, and in automated/scripted upgrade scenarios.

-- Step 1: Shut down the 19c database cleanly
sqlplus / as sysdba
SQL> SHUTDOWN IMMEDIATE;

-- Step 2: Start the database in UPGRADE mode using 26ai Oracle Home
export ORACLE_HOME=$ORACLE_HOME_26AI
export PATH=$ORACLE_HOME/bin:$PATH
sqlplus / as sysdba
SQL> STARTUP UPGRADE;

-- Step 3: Run the upgrade script (catupgrd.sql)
-- This is the main upgrade — takes 30 minutes to several hours
SQL> @$ORACLE_HOME_26AI/rdbms/admin/catupgrd.sql

-- Step 4: Shut down and restart normally
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;

-- Step 5: Run post-upgrade fixup scripts
SQL> @$ORACLE_HOME_26AI/rdbms/admin/utlrp.sql
SQL> @/tmp/preupgrade_output/postupgrade_fixups.sql

4.3 Method 3: AutoUpgrade Tool (Recommended for Multiple Databases)

Oracle's AutoUpgrade tool automates the entire upgrade lifecycle — analyze, fixup, upgrade, postupgrade — and supports upgrading multiple databases in parallel. It includes automatic rollback capability and detailed logging.

# Create AutoUpgrade configuration file
cat > /tmp/upgrade_config.cfg << 'EOF'
global.autoupg_log_dir=/tmp/autoupgrade_logs
upg1.source_home=/u01/app/oracle/product/19.0.0/dbhome_1
upg1.target_home=/u01/app/oracle/product/26.0.0/dbhome_1
upg1.sid=ERPDB
upg1.log_dir=/tmp/autoupgrade_logs/ERPDB
upg1.upgrade_node=localhost
EOF

# Run AutoUpgrade in analyze mode first (no changes made)
$ORACLE_HOME_26AI/bin/autoupgrade.sh \
  -config /tmp/upgrade_config.cfg \
  -mode analyze

# Run the full upgrade
$ORACLE_HOME_26AI/bin/autoupgrade.sh \
  -config /tmp/upgrade_config.cfg \
  -mode deploy

5. Post-Upgrade Steps

The database is now running Oracle 26ai, but the upgrade is not complete until all post-upgrade tasks are done.

5.1 Compile Invalid Objects

-- Recompile all invalid objects created during upgrade
SQL> @$ORACLE_HOME_26AI/rdbms/admin/utlrp.sql

-- Verify invalid object count vs pre-upgrade baseline
SELECT owner, object_type, COUNT(*) AS invalid_count
FROM DBA_OBJECTS
WHERE status = 'INVALID'
GROUP BY owner, object_type
ORDER BY owner, object_type;

5.2 Run Post-Upgrade Status Tool

-- Check the upgrade completed successfully
SQL> @$ORACLE_HOME_26AI/rdbms/admin/postupgrade_fixups.sql

-- Verify the database version
SELECT version, status FROM V$INSTANCE;
SELECT * FROM V$VERSION;

5.3 Update Compatibility Parameter

-- Raise the COMPATIBLE parameter to 26.0.0
-- WARNING: This is irreversible. Do this only after
-- confirming the upgrade is stable and rollback is no longer needed.
ALTER SYSTEM SET COMPATIBLE = '26.0.0' SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP;

5.4 Gather Dictionary Statistics

-- Gather stats on the upgraded dictionary (optimizer needs this)
EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;

5.5 Update RMAN Recovery Catalog

-- If you use a recovery catalog, upgrade it
RMAN> CONNECT CATALOG rman_catalog/@catalog_db
RMAN> UPGRADE CATALOG;

5.6 Data Guard: Upgrade the Standby

For Data Guard configurations, the standby must also be upgraded. The recommended approach: upgrade the standby first (using a transient logical standby), then the primary — achieving a near-zero-downtime upgrade.

-- Convert physical standby to transient logical for rolling upgrade
-- (on primary)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

-- Upgrade the physical standby database to 26ai first
-- Then switchover primary to the upgraded standby
-- Then upgrade the original primary (now standby)

6. Enabling Oracle 26ai Features After Upgrade

Upgrading the database engine is just the beginning. To use Oracle 26ai's AI capabilities, you need to enable and configure specific features.

6.1 Enable the VECTOR Datatype

-- VECTOR datatype is available immediately after upgrade
-- Test with a simple vector column
CREATE TABLE test_vectors (
  id     NUMBER,
  data   VARCHAR2(200),
  vec    VECTOR(128, FLOAT32)
);
DROP TABLE test_vectors;

6.2 Load an ONNX Embedding Model

-- Load a pre-trained ONNX model into Oracle for in-database embeddings
EXEC DBMS_VECTOR.LOAD_ONNX_MODEL(
  directory  => 'ONNX_MODELS_DIR',
  file_name  => 'all_minilm_l6_v2.onnx',
  model_name => 'MY_EMBEDDING_MODEL',
  metadata   => JSON('{"function":"embedding","embeddingOutput":"embedding","input":{"input":["DATA"]}}')
);

6.3 Configure Select AI

-- Set up Select AI for natural language SQL on your ERP schema
BEGIN
  DBMS_CLOUD_AI.CREATE_PROFILE(
    profile_name => 'ERP_AI',
    attributes   => '{
      "provider"    : "database",
      "model"       : "MY_LOCAL_LLM",
      "object_list" : [
        {"owner":"ERP","name":"PRODUCTS"},
        {"owner":"ERP","name":"ORDERS"},
        {"owner":"ERP","name":"INVENTORY"}
      ]
    }'
  );
END;
/

-- Test natural language query
SELECT DBMS_CLOUD_AI.GENERATE(
  prompt       => 'What are the top 5 products by sales this month?',
  profile_name => 'ERP_AI',
  action       => 'narrate'
) FROM DUAL;

7. Performance Testing After Upgrade

Never declare an upgrade complete without validating performance. The Oracle 26ai optimizer may generate different execution plans for some queries — usually better, occasionally different enough to cause concern.

7.1 SQL Performance Analyzer (SPA)

SPA compares SQL execution plans and performance between the 19c and 26ai versions of your database — before you commit to the upgrade in production.

-- On the 19c database: capture a SQL Tuning Set
BEGIN
  DBMS_SQLTUNE.CREATE_SQLSET(sqlset_name => 'PRE_UPGRADE_STS');
  DBMS_SQLTUNE.CAPTURE_CURSOR_CACHE_SQLSET(
    sqlset_name     => 'PRE_UPGRADE_STS',
    time_limit      => 3600,
    repeat_interval => 300
  );
END;
/

-- Transport STS to 26ai database, then run SPA
VARIABLE spa_task VARCHAR2(64);
BEGIN
  :spa_task := DBMS_SQLPA.CREATE_ANALYSIS_TASK(
    sqlset_name => 'PRE_UPGRADE_STS',
    task_name   => 'UPGRADE_IMPACT_ANALYSIS'
  );
  DBMS_SQLPA.EXECUTE_ANALYSIS_TASK(
    task_name        => :spa_task,
    execution_type   => 'TEST EXECUTE',
    execution_name   => 'POST_UPGRADE_EXEC'
  );
  DBMS_SQLPA.COMPARE_SQLSET_BASELINES(
    task_name => :spa_task
  );
END;
/

7.2 Key Performance Metrics to Verify

• Transaction throughput (TPS) — should match or exceed pre-upgrade baseline
• Top 10 SQL statements — compare elapsed time pre vs post upgrade
• Wait event profile — no new dominant wait events introduced
• Buffer cache hit ratio — should remain above 95% for OLTP
• Application response times — measure end-user experience, not just DB metrics

7.3 My First-72-Hours Validation Routine

After every production upgrade I run the same routine for the first three days. It has caught plan regressions and alert-log surprises early enough to fix them quietly, before anyone raised a ticket.

1. Hour 0: Confirm version and open mode in V$INSTANCE, recompile invalid objects, and compare the invalid-object count against the pre-upgrade baseline.
2. Hour 1: Tail the alert log for ORA- errors and new deprecation messages; run one known-heavy business report end to end.
3. Day 1 morning: Compare the top 10 SQL by elapsed time against the 19c baseline; pin any regressed plan with SQL Plan Management.
4. Day 1 evening: Verify the RMAN backup job ran successfully against the upgraded database — a backup that fails silently is a rollback plan you no longer have.
5. Days 2–3: Review AWR snapshots for new dominant wait events, confirm batch jobs and interfaces completed on schedule, and collect sign-off from application owners.

Only when all five steps are clean for the full 72 hours do I start the clock on the 2–4 week stability period before touching COMPATIBLE.

8. Rollback Plan

Every upgrade must have a tested rollback procedure before the production upgrade window opens. For Oracle 19c to 26ai:

• Before raising COMPATIBLE: You can restore the pre-upgrade RMAN backup to the 19c Oracle Home and re-open the database on 19c. This is the clean rollback path.
• After raising COMPATIBLE to 26.0.0: You cannot downgrade the datafiles to 19c — the COMPATIBLE change is permanent. This is why raising COMPATIBLE should be delayed until the upgrade is confirmed stable (at minimum 2–4 weeks of production operation).
• AutoUpgrade rollback: If using AutoUpgrade, it supports automatic rollback to the source version during the upgrade process — but only before the upgrade completes and the database is opened normally.

8.1 Guaranteed Restore Point — The Cheap Insurance

Restoring a full RMAN backup of a multi-terabyte database can take many hours. My preferred first line of rollback is a guaranteed restore point with Flashback Database — it rewinds the database to the pre-upgrade state in minutes, not hours.

-- BEFORE the upgrade, on the 19c database:
CREATE RESTORE POINT before_26ai_upgrade GUARANTEE FLASHBACK DATABASE;

-- If rollback is needed (COMPATIBLE still at the 19c value):
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;   -- from the 19c Oracle Home
FLASHBACK DATABASE TO RESTORE POINT before_26ai_upgrade;
ALTER DATABASE OPEN RESETLOGS;

-- AFTER the stability period, drop it — it pins flashback
-- logs in the FRA and will fill the recovery area if forgotten:
DROP RESTORE POINT before_26ai_upgrade;

Two cautions from experience. First, size the fast recovery area for the flashback logs the restore point will retain during the upgrade — I have seen an FRA fill up mid-window because nobody did the arithmetic. Second, the restore point is only usable while COMPATIBLE remains at the old value — which is exactly why I never raise COMPATIBLE on upgrade night. The RMAN backup stays as the deeper layer of insurance underneath.

9. Upgrade Checklist Summary

• ☐ Application vendor confirmed Oracle 26ai certification
• ☐ Pre-Upgrade Information Tool run and all issues resolved
• ☐ Pre-upgrade fixup scripts executed
• ☐ Optimizer statistics gathered (fresh)
• ☐ Recycle bin purged
• ☐ Invalid objects baseline recorded
• ☐ Full RMAN backup completed and verified
• ☐ Guaranteed restore point created (FRA sized for flashback logs)
• ☐ Upgrade tested successfully in non-production environment
• ☐ SQL Performance Analyzer run on key workload
• ☐ Production upgrade window scheduled (low-traffic period)
• ☐ Rollback procedure documented and tested
• ☐ Post-upgrade: invalid objects recompiled
• ☐ Post-upgrade: dictionary statistics gathered
• ☐ Post-upgrade: RMAN catalog upgraded
• ☐ Post-upgrade: Data Guard standby upgraded (if applicable)
• ☐ Performance validation completed
• ☐ COMPATIBLE parameter raised (only after stable period)

Frequently Asked Questions

Can I upgrade directly from Oracle 19c to 26ai?

Yes. Oracle supports a direct upgrade from 19c (and 21c) to 26ai using DBUA, the manual catupgrd.sql method, or the AutoUpgrade tool. Databases on 12.1, 12.2, or 11g must be upgraded to 19c first, then to 26ai.

How long does a 19c to 26ai upgrade take?

The upgrade itself typically runs 30 minutes to a few hours, depending on the number of installed components and the size of the data dictionary. The full project — assessment, fixups, rehearsal, performance testing, and the production window — realistically spans 3 to 6 weeks. The database work is the short part; the preparation is the long part.

What breaks most often after an Oracle upgrade?

In my experience: optimizer plan changes on a handful of critical SQL statements, invalid objects in old application schemas, incompatible or ancient JDBC drivers, and deprecated initialization parameters left in the spfile. All four are catchable before go-live with SQL Performance Analyzer, an invalid-objects baseline, driver checks, and a careful read of the pre-upgrade report.

Is downtime avoidable during the upgrade?

It can be reduced to a brief switchover. With Data Guard, a rolling upgrade using a transient logical standby upgrades the standby first, switches over, then upgrades the old primary — near-zero downtime. Without Data Guard, plan a scheduled maintenance window; with good preparation the outage is usually one to a few hours.

When should I wait instead of upgrading to 26ai?

Wait if your critical application vendor has not certified Oracle 26ai, if you are in a regulated environment where the validation cycle would be disruptive right now, or if your 19c support window still has 12+ months remaining and you have no immediate need for the AI features. But plan the timeline now — do not wait until support pressure forces a rushed upgrade.

What is the rollback plan if the upgrade goes wrong?

Two layers: a guaranteed restore point with Flashback Database for a fast rollback measured in minutes, and a full RMAN backup as the deeper insurance. Both only work while the COMPATIBLE parameter is still at its 19c value — once you raise COMPATIBLE to 26.0.0, downgrade is no longer possible. That is why I keep COMPATIBLE unchanged for 2–4 weeks after go-live.

The Bottom Line

Upgrading from Oracle 19c to 26ai is one of the most consequential database projects an organization can undertake — not just because of the technical complexity, but because of what becomes possible after the upgrade. In-database AI, native vector search, and natural language SQL are not incremental improvements — they are capabilities that did not exist in enterprise databases before Oracle 26ai.

The organizations that plan this upgrade carefully — with thorough pre-upgrade testing, performance validation, and a clear rollback plan — will complete it in a scheduled maintenance window with no surprises. The ones that rush it, skip the pre-upgrade tool, or forget to validate in non-production first will spend their upgrade window firefighting instead of completing.

Start with the Pre-Upgrade Information Tool. Validate everything in non-production. Test your rollback before you start. The upgrade itself is then the easy part.