Oracle Database Upgrade from 12.2 to 19c Using DBUA — A Complete Step-by-Step Implementation Guide

Why This Blog Post?

Every Oracle DBA eventually faces the same pivotal moment: the database that has loyally served the business for years is sitting on a release whose mainstream support has already lapsed. Oracle 12c (12.2.0.1) is exactly that case — Premier Support ended in November 2020 and Extended/Limited Error Correction support has long since concluded. The natural and most strategic path forward is Oracle Database 19c — the Long-Term Release (LTR) that delivers stability, extended support, and a dependable runway for years to come.

In this blog post, will walk you through the complete journey of upgrading an Oracle 12c (12.2.0.1) database to Oracle 19c using the Database Upgrade Assistant (DBUA). You'll see exactly what I planned, what I checked, what I executed, and what I verified — based on a real implementation on a multitenant CDB/PDB architecture.

Whether you're preparing for your first Oracle upgrade or polishing your runbook for a production cutover, this guide is designed to give you a clear, battle-tested map.

1. Introduction

Upgrading Oracle databases is no longer a "nice to have" — it's a fundamental responsibility. Modern enterprises demand better performance, tighter security, and access to new features that only newer releases provide. Oracle Database 19c, being a Long-Term Release, brings:

Enhanced stability with multiple Release Updates (RUs) over its lifecycle
A more intelligent cost-based optimizer with new adaptive features
Extended support that allows organizations to plan upgrades on their own timeline
A consolidated foundation for moving toward Oracle 23ai and future releases when the time comes

This guide outlines the end-to-end process of upgrading an Oracle 12c database to 19c using the Database Upgrade Assistant (DBUA). DBUA provides a guided, automated, and reliable approach that minimizes manual effort and reduces operational risk during one of the most sensitive activities a DBA performs.

The journey is broken into four logical phases:

Pre-upgrade checks — confirm the source database is healthy and ready
Environment validation — verify Oracle homes, listeners, parameters, and storage
DBUA execution — run the guided GUI-based upgrade
Post-upgrade verification — validate integrity, components, and performance

Let's dive in.

2. Objective and Scope

Objective

Upgrade Oracle Database from 12.2.0.1 to 19c
Ensure minimal downtime and full data integrity
Validate database readiness before touching the upgrade
Perform the upgrade using DBUA (GUI-based approach)
Execute post-upgrade validation and optimization steps

Scope

Aspect	Detail
Source Database	Oracle 12c (12.2.0.1)
Target Database	Oracle 19c
Architecture	Multitenant (CDB with PDB)
Upgrade Method	DBUA (Database Upgrade Assistant)
Activities Included	Pre-upgrade fixups, backup, DBUA execution, post-upgrade validation and cleanup

3. Environment Details

Before any upgrade, document the environment so that every team member, vendor, and reviewer has a single source of truth. Here's the environment used for this implementation:

Parameter	Details
Hostname	srv5.cloudmap.in
Database Name	NEXUS
Source Version	12.2.0.1
Target Version	19c
Architecture	CDB (Single Instance)
PDB Name	APP_PDB
Source Oracle Home	`/u01/app/oracle/product/12.2.0.1/db_1`
Target Oracle Home	`/u01/app/oracle/product/19.0.0/dbhome_1`
Operating System	Linux x86 64-bit
Upgrade Method	DBUA

Pro tip : Always lock down this table inside your runbook before the change window. If anything goes sideways, you want every fact about the environment a single page-flip away.

4. Prerequisites — Don't Skip Even One

This is the section experienced DBAs read twice. The upgrade itself is rarely the painful part — missing a prerequisite is. Before kicking off the upgrade, ensure every item below is satisfied:

✅ Full database backup is available and verified (RMAN backup preferred)
✅ Backup of configuration files:
- tnsnames.ora
- listener.ora
- sqlnet.ora
- spfile / pfile
- Password file
✅ Database is in ARCHIVELOG mode
✅ Sufficient space available in the Fast Recovery Area (FRA)
✅ Run the Pre-Upgrade Information Tool (preupgrade.jar)
✅ Execute preupgrade_fixups.sql
✅ Confirm no critical errors in pre-upgrade logs
✅ Verify tablespace sizing is sufficient (SYSTEM, SYSAUX, UNDO, TEMP)
✅ Purge the recycle bin to remove unnecessary objects
✅ Gather dictionary statistics and fixed object statistics

Why this matters: the Pre-Upgrade Information Tool is your friend. If it whispers a warning during the dry run, it will shout during the cutover. Resolve everything early.

5. Implementation — Upgrade Steps

This section is the heart of the blog post. Each step below mirrors the actual sequence I executed in the production-like environment.

5.1 Oracle 19c Software Availability

Verified that the Oracle 19c Oracle Home is installed at:
```
/u01/app/oracle/product/19.0.0/dbhome_1
```
Oracle 19c was already installed and properly configured on the server, so the upgrade proceeded using the existing 19c software without any additional installation.
If 19c is not available on your server, download and install it before continuing — DBUA will not perform a software install.

5.2 Source Database Validation

Before running anything destructive, sanity-check the source database:

Verify oratab — confirm the source database entry points to the 12.2 Oracle Home
Check PDBs — list all pluggable databases and confirm they are OPEN READ WRITE
Check Compatibility — current compatible parameter must be supported for upgrade to 19c
Confirm Database Version — SELECT banner FROM v$version; should return 12.2.0.1.0
Component Status — every component in DBA_REGISTRY must be VALID

Zaheer's rule of thumb: if even one component is INVALID or LOADING, fix it now. Don't carry technical debt into the upgrade window.

5.3 Backup Activities

5.3.1 Database Backup

Confirm an RMAN full database backup is available — and that it can actually be restored. A backup that has never been tested is just expensive optimism.

5.3.2 Network Configuration Backup

Back up listener and TNS configuration files. DBUA will modify the listener configuration during the upgrade, so having an untouched copy is non-negotiable.

5.3.3 Parameter and Password Files Backup

Take physical copies of spfile, pfile, and the password file. If anything misbehaves with the parameter file post-upgrade, you'll want the original within arm's reach.

5.4 Run Pre-Upgrade Tool

Run the Pre-Upgrade Information Tool (preupgrade.jar) shipped with the 19c Oracle Home. It analyzes the 12c database and generates:

A report describing required actions
preupgrade_fixups.sql — fixups to run before the upgrade
postupgrade_fixups.sql — fixups to run after the upgrade

5.5 Review the Pre-Upgrade Report

Carefully read the generated report. In this implementation, the observations were:

No mandatory actions required
Recommended actions:
- Gather fixed object statistics
- Verify tablespace sizing for SYSTEM, SYSAUX, UNDO, and TEMP
- Plan a timezone upgrade post-upgrade

5.6 Tablespace Verification

All critical tablespaces had AUTOEXTEND ON with appropriate MAXSIZE values configured.
✔ No action required — sizing was already healthy.

5.7 Initialization Parameters Check

Pre-upgrade report flagged no parameter changes as required.
All deprecated and obsolete parameters were already absent.

5.8 Optimize Database Before Upgrade

Gathered dictionary statistics using DBMS_STATS.GATHER_DICTIONARY_STATS
Gathered fixed object statistics using DBMS_STATS.GATHER_FIXED_OBJECTS_STATS
Purged the recycle bin to drop obsolete objects

5.9 Execute Pre-Upgrade Fixups

Oracle strongly recommends running the Pre-Upgrade Information Tool before starting DBUA. While DBUA itself runs the tool internally, running it ahead of time lets you address issues during business hours and shrink the actual cutover window.

Executed preupgrade_fixups.sql
✔ All fixups completed successfully

5.10 Archive Log and FRA Verification

Confirmed the database is in ARCHIVELOG mode
Verified Fast Recovery Area (FRA) has enough free space for archive logs and the guaranteed restore point
✔ Sufficient space confirmed

5.11 Create a Guaranteed Restore Point

This is the safety net of the entire operation.

CREATE RESTORE POINT pre_19c_upgrade GUARANTEE FLASHBACK DATABASE;

A few critical notes:

From Oracle 11.2.0.1 onwards, you do not need to enable Flashback Database to use a guaranteed restore point.
The database must be in ARCHIVELOG mode.
Do NOT change the COMPATIBLE parameter to 19.0.0 yet — once you do, the restore point can no longer roll the database backward across that compatibility boundary.

✔ Restore point created successfully — and that one line of SQL might be the most reassuring command of the whole upgrade.

5.12 Set Environment for DBUA

DBUA is a GUI tool, so prepare the environment:

export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH
export DISPLAY=<your_x_server>:0.0
xhost +

Confirm the X11 display works (e.g. open xclock)
Many production servers run headless — plan for VNC, X forwarding, or NoMachine

5.13 Run DBUA — Database Upgrade Assistant

With everything green, launch DBUA from the target 19c Oracle Home:

$ORACLE_HOME/bin/dbua

Then walk through the wizard:

Select source database — choose NEXUS (the 12c database) for upgrade or migration. Provide SYSDBA credentials and click Next.
Validate PDBs — confirm APP_PDB is selected for upgrade, then click Next.
Prerequisite checks — DBUA automatically runs prerequisite checks. Ensure all checks pass cleanly before proceeding.
Upgrade options — enable the relevant upgrade options (parallelism, recompile invalid objects, gather statistics) and click Next.
Recovery options — select the FRA as the recovery destination, and confirm the previously created Guaranteed Restore Point is chosen for safe rollback.
Network configuration — DBUA updates the listener configuration:
- Adds the selected listener to the target Oracle Home
- Removes the entry from the source listener.ora
- Reloads listener configuration in both source and target environments
  Click Next.
EM Database Express — uncheck Enterprise Manager Database Express if you don't need it (saves cycles).
Review summary — verify every configuration on the summary screen. This is your last opportunity to back out.
Click Finish — and the upgrade begins.

During execution, monitor the upgrade status carefully. DBUA shows a progress bar and detailed log output for each phase: dictionary upgrade, component upgrade, recompilation, post-upgrade scripts.

After completion, the summary screen confirms:

Source and target database details
Upgrade success status
Total completion time

Zaheer's tip: screenshot every wizard screen as you go. When auditors or your future self ask what was selected on the listener configuration page, you'll have the answer in seconds.

5.14 Post-Upgrade Verification

Don't celebrate yet — verification is where you earn your DBA stripes.

5.14.1 Verify oratab

Confirm /etc/oratab points the NEXUS entry to the 19c Oracle Home.

5.14.2 Verify Database Version

SELECT banner FROM v$version;

Expected: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0

5.14.3 Verify Timezone Version

SELECT version FROM v$timezone_file;

If the timezone version is older than the latest supported by 19c, schedule the timezone upgrade as a follow-up task (it can be done online with brief windows).

5.14.4 Check for Invalid Objects

SELECT owner, object_type, COUNT(*)
FROM dba_invalid_objects
GROUP BY owner, object_type;

Recompile if needed:

@$ORACLE_HOME/rdbms/admin/utlrp.sql

5.14.5 Verify Component Status

SELECT comp_name, version, status FROM dba_registry;

Every component must report VALID.

5.15 Execute Post-Upgrade Fixups

Run postupgrade_fixups.sql generated by the Pre-Upgrade Information Tool. This script handles cleanup tasks Oracle recommends after the upgrade — things like removing obsolete parameters, refreshing statistics, and tidying up the dictionary.

5.16 Drop the Restore Point

Once the database is validated, stable, and the business has signed off:

DROP RESTORE POINT pre_19c_upgrade;

Don't be in a rush — keep the restore point for at least a few business cycles when possible.

5.17 Update the COMPATIBLE Parameter

⚠ Warning from Zaheer: changing COMPATIBLE to 19.0.0 is a one-way door. After this change, if for some reason a downgrade is required, the only available path is export/import — you cannot use Flashback Database to roll back across a compatibility change.

The recommended pattern is to leave COMPATIBLE unchanged for a few weeks post-upgrade so you can observe how the database behaves under real workload. If a downgrade becomes necessary during this window, it's quick and safe.

When you're confident:

ALTER SYSTEM SET compatible='19.0.0' SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP;

After changing COMPATIBLE, the existing guaranteed restore points are no longer useful (Flashback Database cannot cross a compatibility boundary), so you can drop them.

6. Risks and Mitigation

Every upgrade carries risk. Here's the matrix I work with:

⚠ Risk	✅ Mitigation
Upgrade failure due to unresolved pre-check issues	Run pre-upgrade tool early; resolve all warnings
Insufficient disk space or FRA size	Validate sizing days before cutover
Performance degradation after upgrade	Capture AWR snapshots before and after; tune SQL
Invalid objects or component failures	Run `utlrp.sql`; investigate stubborn invalid objects
Data inconsistency in case of interruption	Guaranteed restore point + verified RMAN backup
Application incompatibility	Run upgrade in UAT/Test environment first

7. Key Observations from This Implementation

The upgrade from 12.2.0.1 to 19c completed successfully using DBUA with minimal downtime
The Pre-Upgrade Information Tool identified no critical issues — only recommended actions
preupgrade_fixups.sql resolved all required pre-upgrade conditions cleanly
The database remained in ARCHIVELOG mode throughout, supporting safe upgrade and recovery
The Flashback Guaranteed Restore Point provided a reliable rollback mechanism
DBUA automatically handled:
- Listener configuration updates
- Environment switching between Oracle Homes
- Component upgrades across CDB and PDB
Post-upgrade tasks confirmed database stability and optimization

8. Benefits of Upgrading to Oracle 19c

🚀 Improved database performance and optimizer enhancements
🛡️ Enhanced security features and compliance capabilities
📅 Long-term support release — fewer frequent upgrades in the future
🧱 Better resource management in multitenant architecture (CDB/PDB)
🤖 Reduced manual effort thanks to DBUA's automation
🔌 Minimal application impact — no major structural changes typically required
🧪 Built-in pre-checks dramatically reduce upgrade risks

9. Conclusion

The upgrade from Oracle 12c (12.2.0.1) to Oracle 19c using DBUA was successfully completed using a structured and validated approach. Pre-upgrade checks ensured readiness, while DBUA simplified execution with minimal manual intervention. Post-upgrade validation confirmed database integrity, component status, and performance stability.

The database is now running on Oracle 19c, enjoying improved performance, enhanced security, and long-term support — exactly the foundation a modern enterprise needs.

If you're staring down your own 12c-to-19c upgrade, my advice is simple:

Plan twice, upgrade once.
Test in UAT with the same workload patterns as production.
Trust the tools — DBUA is mature, but it expects you to do your homework.
Document everything — your future self will send you a thank-you note.

10. Future Enhancements

After settling into 19c, here's the roadmap I personally recommend:

🛠 Adopt the AutoUpgrade utility for future upgrades — even more automated than DBUA
📊 Implement performance tuning using AWR/ASH reports
🌍 Upgrade the timezone file to the latest version (if pending)
🔒 Enable Unified Auditing for better security monitoring
🔁 Integrate with Data Guard and RMAN catalog upgrades
⚙️ Automate health checks and post-upgrade validation scripts
✨ Evaluate flagship 19c features:

Real-Time Statistics
Automatic Indexing
SQL Plan Management improvements

Closing Thoughts

A clean Oracle upgrade is the kind of work nobody notices when it goes well — and that's exactly the goal. With careful planning, thorough validation, and the right tool (DBUA in this case), upgrading from 12.2 to 19c is a confident, controlled, and even enjoyable exercise.

If this guide helped you, share it with a fellow DBA in the trenches. And if you'd like to dig deeper into AutoUpgrade, multitenant migration, or zero-downtime patterns, drop me a line.

Stay backed up, stay patched, and may your upgrades be uneventful.

thanks for reading :)

BR,

SYED ZAHEER