Database upgrade can be performed either using manual or DBUA. Below are the steps for upgrading oracle database from oracle 12c to 19c version using DBUA.

Important points:

  • Direct upgrade to 19  can be performed from,, & 18c .
  • Compatible parameter should be at minimum 11.2.0
  • Post upgrade , oracle default accounts ( whose password has not been reset before upgrade), will be locked and set to NO AUTHENICATE MODE.
  • Post upgrade, you may not be able to login to the existing users with the password, because of new authentication method. To fix this, sqlnet.ora file need to be update(details explained at the end of this article).

Current environment details:




CURRENT ORACLE_HOME=/oracle/app/oracle/product/

NEW ORACLE_HOME = /oracle/app/oracle/product/


Install oracle 19c ORACLE_HOME:

unzip the binary and run

mkdir -p /oracle/app/oracle/product/














  1. Run preupgrade tool script

preupgrade.jar tool file is available with the oracle database binary. Run this to do the precheck

export ORACLE_HOME=/oracle/app/oracle/product/

$ORACLE_HOME/jdk/bin/java -jar /oracle/app/oracle/product/


Execute fixup scripts as indicated below:

Before upgrade:

Log into the database and execute the preupgrade fixups

After the upgrade:

Log into the database and execute the postupgrade fixups

Preupgrade complete: 2019-08-26T13:09:51

Run the pre-upgrade fixup script:

SQL> @/oracle/app/oracle/product/

Executing Oracle PRE-Upgrade Fixup Script

Auto-Generated by:       Oracle Preupgrade Script
                         Version: Build: 1
Generated on:            2019-08-26 13:09:37

For Source Database:     TESTDB
Source Database Version:
For Upgrade to Version:

Preup                             Preupgrade
Action                            Issue Is
Number  Preupgrade Check Name     Remedied    Further DBA Action
------  ------------------------  ----------  --------------------------------
    1.  invalid_objects_exist     NO          Manual fixup recommended.
    2.  exclusive_mode_auth       NO          Manual fixup recommended.
    3.  case_insensitive_auth     NO          Manual fixup recommended.
    4.  underscore_events         NO          Informational only.
                                              Further action is optional.
    5.  dictionary_stats          YES         None.
    6.  parameter_deprecated      NO          Informational only.
                                              Further action is optional.
    7.  min_archive_dest_size     NO          Informational only.
                                              Further action is optional.
    8.  rman_recovery_version     NO          Informational only.
                                              Further action is optional.

The fixup scripts have been run and resolved what they can. However,
there are still issues originally identified by the preupgrade that
have not been remedied and are still present in the database.
Depending on the severity of the specific issue, and the nature of
the issue itself, that could mean that your database is not ready
for upgrade.  To resolve the outstanding issues, start by reviewing
the preupgrade_fixups.sql and searching it for the name of
the failed CHECK NAME or Preupgrade Action Number listed above.
There you will find the original corresponding diagnostic message
from the preupgrade which explains in more detail what still needs
to be done.

PL/SQL procedure successfully completed.

2.Run utlrp.sql:( to compile invalid objects) 

SQL> @$ORACLE_HOME/rdbms/admin/utlrp.sql

SQL> select count(*) from dba_objects where status='INVALID';


3.Check database component status:

set pagesize500
set linesize 100
select substr(comp_name,1,40) comp_name, status, substr(version,1,10) version from dba_registry order by comp_name;

----------- ----------------------------------------
JServer JAVA Virtual Machine

Oracle Database Catalog Views

Oracle Database Java Packages

Oracle Database Packages and Types

Oracle Multimedia

Oracle Text

Oracle Workspace Manager

Oracle XDK

Oracle XML Database

SQL> SELECT FROM sys.obj$ o, sys.user$ u, sys.sum$ s WHERE o.type# = 42 AND bitand(s.mflags, 8) =8;

no rows selected

4.Check timezone version:

SQL> select * from v$timezone_file;

FILENAME                VERSION     CON_ID
-------------------- ---------- ----------
timezlrg_18.dat              18          0

5.Check files in backup mode:(should return zero rows)

SQL> SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';

no rows selected

SQL> SELECT * FROM v$recover_file;

no rows selected

6.Purge recyclebin:

SQL> purge dba_recyclebin;

As pre-check is successful . Now we will proceed with the upgrade



Enable the flashback on the database.

    1. To enable restore , in case of failure, enable flashback option.
alter system set db_recovery_file_dest_size=20G scope=both;
alter system set db_recovery_file_dest='/dumparea/FRA/' scope=both;
alter database flashback on;


2.Start DBUA

export ORACLE_HOME=/oracle/app/oracle/product/













We can pause and resume the upgrade during the process also.


Upgrade completed successfully.


SQL> select comp_id,status from dba_registry;

COMP_ID                        STATUS
------------------------------ -----------
CATALOG                        VALID
CATPROC                        VALID
JAVAVM                         VALID
XML                            VALID
CATJAVA                        VALID
RAC                            OPTION OFF
XDB                            VALID
OWM                            VALID
CONTEXT                        VALID
ORDIM                          VALID

10 rows selected.

SQL> select * from v$timezone_file;

FILENAME                VERSION     CON_ID
-------------------- ---------- ----------
timezlrg_32.dat              32          0

3. Updating sqlnet.ora file

Post upgrade, you might not be able to connect to the existing users with the passwords. So to fix this add SQLNET.ALLOWED_LOGON_VERSION_SERVER=11 to sqlnet.ora file

export ORACLE_HOME=/oracle/app/oracle/product/

cd $ORACLE_HOME/network/admin

cat sqlnet.ora


4. Once you have confirmed that upgrade is successful and there is no rollback, you can drop the restore point.

select * from v$restore_point;

drop restore point 

5. Updating compatible parameter post upgrade.

Once upgrade is successful , do testing on your database . Once testing is successful you can update the compatible parameter. However once compatible parameter is updated, database cannot be downgraded. So always do proper testing and take a full backup before updating the compatible parameter.

  • Take fullbackup of the database.
  • Update compatible parameter
alter system set compatible='19.0.0' scope=spfile;
shutdown immediate;

SELECT name, value FROM v$parameter
         WHERE name = 'compatible';