Restarting a failed Database Upgrade with DBUA 12.2

In my previous blog post I did showcase how to restart a failed database upgrade on the command line before Oracle Database 12c, with Oracle Database 12.1.0.x and with the new Oracle Database 12.2.0.x:

Restarting a failed Database Upgrade with

Here I’d like to show the new capability of the Database Upgrade Assistant (DBUA) to restart an upgrade, a functionality the DBUA was missing until now. Please note that you can always go back to the command line, no matter in which version you have used the DBUA.

I won’t describe an upgrade with the DBUA in this blog post as this is showcased in the documentation already:

Starting the database upgrade with DBUA

I will upgrade the UPGR database well known from our Hands-On Lab.

DBUA Database Selection Oracle 12.2

And please don’t put in your credentials in the fields below – if you are logged in as the oracle user then this will lead to failure and drive you crazy …

Another thing which puzzles me:
I still have to execute the olspreupgrade.sql script from the newer (in my case the 12.2) home by myself. I’d wish
the DBUA would do this for me as well as I’ll have to open an xterm, set my environment and type in a very long path name to point to the new 12.2 home in order to execute this script in my source environment.

DBUA Database Selection Oracle 12.2

Ok, let’s kick off the upgrade:

Oracle 12.2 DBUA Database Upgrade

The progress bar is very imprecise in relation to the duration – you can ignore it more or less.

And – very sad – the Alert and Activity Monitor buttons disappeared – but they may reappear in a later release of the DBUA.

The Error Scenario

It’s always fun to kill pmon finding out how cool this database is 😉 It survives the deadly attack 🙂 Of course it does … it’s the Oracle Database 😉

kill -9 pmon


The DBUA recognizes the failure

Even though the DBUA recognized the failure quite quickly it still tries to complete the upgrade – which of course results in a ton of errors. It just means that you’ll have to wait until the DBUA has “progressed” the upgrade till the end – and DON’T CLOSE THE DBUA as otherwise you’ll lose the ability to RETRY.

DBUA - upgrade failure

You’ll see the error count going up until the DBUA has reached the “end” of the (failed) upgrade.

DBUA Oracle 12.2 - upgrade failure scenario 2

And then it displays the RETRY button:

DBUA Oracle 12.2 - upgrade failure scenario

Rerun the Database Upgrade

Once you hit RETRY the DBUA will try to solve the situation – and in my case it will start up my source database in STARTUP UPGRADE mode again – and then process the upgrade using the -R option of (described in the previous blog post)

DBUA Oracle 12.2 - upgrade failure scenario

You’ll find also a new set of logfiles in $ORACLE_BASE/cfgtoollogs/dbua/ subdirectories indication with a number (here: 1) and an “R” that this is the first restart attempt’s logs:

Logfiles from DBUA rerun 12.2


Share this:

14 thoughts on “Restarting a failed Database Upgrade with DBUA 12.2

  1. Mike,
    As usual, excellent posts about 12.2 upgrade. My question is: Let’s say during upgrade, some database related issue is found and upgrade fails. To correct the issue, I have to start the database in normal mode which might be impossible because upgrade already made changes to data dictionary half way. What is my course of action?


  2. Arun,

    you raise a very good question.

    There are things you can solve in STARTUP UPGRADE mode. But once the upgrade kicked off you usually can’t start it in NORMAL MODE anymore as you’ll get BOOTSTRAP TABLE errors.

    If you really can’t fix something in STARTUP UPGRADE mode anymore than I would FLASHBACK DATABASE to a GUARANTEED RESTORE POINT which is my preferred way of resolving issues during upgrade (or for testing). Now I know that you can’t use this technique with SE environments as there’s no FLASHBACK DATABASE in SE. In this case you can only restore your backup, either your ONLINE backup or your PARTIAL OFFLINE backup (both described in the FALLBACK section in our big slide deck).


  3. Pingback: Restarting a failed Database Upgrade with | Upgrade your Database - NOW!

  4. Hi Mike,
    I’m, probably far from the smartest person even in our office, so I don’t still get it. Let’s say a very common situation (my situation right now). I have a database in process of upgrade and some component failed during the upgrade due to something in the database. Then I’m in the phase where all components finished it’s migration process (only one failed with some minor error which I unfortunately am not able to resolve) and I would like to continue to the next part – post upgrade. In previous DB versions it was possible – I was able to simple ignore this errors and continue and then resolve those errors manually. Now I can only Retry (which is useless since the error occurs again) or abort – which I don’t want to. I can’t press Ignore since it is grayed out.
    Now what?


    • Vasek,

      the behavior shouldn’t be any different from previous version. If a component does not upgrade correctly but the DBUA does not treat this as “I must exit” the upgrade will finish. The “Restart” option is meant for cases when, for instance the upgrade got stuck, you fixed the reason for a stuck upgrade by applying the change with a SQL*Plus session, and then you continue in DBUA by restarting the upgrade. The crucial point IMHO is that in most cases people will quit the DBUA – and once it has been quit you can only retry the upgrade on the command line by using “ -R”. This by the way will finish a quit DBUA upgrade 😉

      Therefore, no difference in behavior to previous versions. Just a new option.


  5. The primary reason I would need to restart an upgrade is that the network disconnected and DBUA has exited on its own. So the instructions that you lose the ability to restart if DBUA has exited – makes any talk of restart, nearly completely useless.

    What would be nice is if the tool kept track of where it was, and had the ability to start where it left off – the thing that we have to do manually now.

    Maybe someday. This tool is not improved much.

  6. Hi Mike,

    I’m totally blocked with DBUA, not even pass the first screen. When no credentials are set on the first screen, I got “[FATAL] [DBT-20010] Specified database “mibdd11g” could not be started.” When I set credentials, “[FATAL] [DBT-20007] Specified SYSDBA credentials are not correct. Specify the correct SYSDBA credentials and try again.”

    As you stated, this is driving me crazy after hours and hours of orapw, parameters and other security stuff revisions.

    I’m going to use manual method, but don’t know if this maybe already happened to you.

    Thanks a lot.

    • Boris,

      I ___NEVER___ put the credentials into the DBUA screen as I have seen only issues with it.
      Use preupgrade.jar from MOS 884522.1 first (download the newest one), then follow the output – and then run simply “dbupgrade -l /home/oracle” to upgrade your database. Then follow the “post upgrade” advice of preupgrade.jar and all will be good.


      • Don’t use the DBUA – use AutoUpgrade from 19c – see the blog for news next week – but it will work for as well as long as you have at least the Jan 2019 RU installed in your destination home.


  7. Hi,

    I was totally crazy trying to update my test database for a training due to incorrect SYSDBA credentials (error was DBT-20007, logs showed PRCR-1097, PRCD-1024). After hours of research and changes specially to authentication parameters and pwfile, I noticed in logs this error was associated with some SRVCTL validations. So, I deleted the resource configuration with “srvctl remove database -d testdb”. When dbua 12.2 was executed after that, the error disappeared.

    Hope this helps.

Leave a Reply

Your email address will not be published. Required fields are marked *

* Checkbox to comply with GDPR is required


I agree

This site uses Akismet to reduce spam. Learn how your comment data is processed.