DBUA Deprecation and future Desupport in Oracle Database 23c

Daniel pointed me to Tim Hall’s blog post about deprecated and desupported features in Oracle Database 23c. And his first bullet point mentioned is the DBUA Deprecation and future Desupport in Oracle Database 23c. Since Daniel and I agree that this needs a bit more explanation, we would like to share more background information with you.

Photo by Ajeet Mestry on Unsplash

Deprecated vs Desupport?

At first, let me refresh an old topic. What does deprecated mean, and what is the difference to desupport? A long while ago I wrote this blog post about it, and nothing has changed since then. In a few words, deprecation means “the feature or tool or datatype is fully supported, we still fix issues – but be aware that we will desupport it someday or soon, and that it may disappear from the code or release“. In addition, once something is desupported, it may still exist – but we won’t generate fixes for it anymore.

The most visible example for this process is the CDB architecture. In 2015 in Oracle Database 12.1.0.2 we announced that the non-CDB architecture gets deprecated, and that it may be desupported and disappear in a future release of the Oracle Database. And in 2019 then we announced the desupport and disappearance of the non-CDB architecture with Oracle Database 21c.

Now, since we clarified the terms, let me add one comment to Tim’s blog post.

Currently, Oracle Database 23c Enterprise or Standard Edition is not available yet. The documentation Tim’s blog post is settling on is the documentation shared with the Oracle Database 23c Free Developer Edition. So please keep in mind that the list currently available may not be the final list, and changes may happen.

But not to this one below.

Deprecation of DBUA and manual upgrade in Oracle 23c

So at first, right now I can only share the link to the 23c Free Developer Release’s documentation with you. It says:

Database Upgrade Assistant (DBUA) and manual upgrades using the Parallel Upgrade Utility (catctl.pl) and the dbupgrade script are deprecated in Oracle Database 23c.

To improve the reliability and support for Oracle Database upgrades, Oracle is deprecating Database Upgrade Assistant (DBUA), and manual upgrades using the Parallel Upgrade Utility (catctl.pl) , and the database upgrade scripts dbupgrade and dbupgrade.cmd. Use AutoUpgrade for Oracle Database upgrades. Deprecating obsolete upgrade methods enables Oracle to focus on improving and extending the features and manageability of the AutoUpgrade utility.

As Tim wrote already, AutoUpgrade is the state-of-the-art tool to do database upgrades. And this is the tool we extend further for many reasons.

Walking down memory lane

But now you may ask yourself: Why is Oracle deprecating these tools?

The answer is very simple. But let me start with a little bit of history at first, at least to the point I remember and can share with you solidly. When I got “thrown” into the upgrade pond by my previous VP, Günther Stürner, we wrote the year 2003. I have to scratch my head and look backwards for two decades. In the early 2000s I changed from Oracle Support to Presales (or Sales Consulting as it was called at this time).

Now take a second and refresh your own memory.The cellphone Nokia’s 8910i was the luxury model of the by then dominating brand – and it had a color screen already. I most likely had a Siemens S45 with up to 300 hours standby time. Impressive, isn’t it?! I could phone with it, and of course send text messages. Nobody had an idea how the world will change a few years later when Steve Jobs entered the stage at Moscone Center in October 2007 to introduce the iPhone.

So you are in the right place in memory lane. At this time we had the Database Migration Assistant in Oracle 9i.

Source: https://docs.oracle.com/cd/A91034_01/DOC/server.901/a90191/migbyast.htm#21532

It got used to primarily migrate Oracle 7 databases to 9i. Those of you who deal a bit longer with Oracle databases will remember that we changed the block address format after Oracle 7 to accommodate larger database sizes, and to allow more flexibility. But every block in a database needed to be adjusted. Luckily we didn’t have databases of hundreds of TB size yet. But the purpose of the Migration Assistant at first was to allow a safe and transparent migration. And of course, you could also upgrade an 8i database to 9i with it.

Now, as we walked down memory lane together, you get an idea how old DBUA (Database Upgrade Assistant) is. The Migration Assistant got renamed later to Upgrade Assistant. In the screenshot above you read that we speak already about “migration” for Oracle 7 databases since we physically had to migrate the blocks but “upgrade” when it came to 8i as source.

The birth of AutoUpgrade

So let’s do a time flip together – and now we are back in 2023, approximately 20 years later.

Certainly, the DBUA has been evolved over time. Stuff got added, it has been even hardwired into upgrades in the Oracle Cloud tooling. But the DBUA had many limitations I listed already in presentations my presales days more than 16 years ago. It could not upgrade more than 1 database at a time from one home. When it fails, there is no resume and poor diagnostics. And going through its logs is a true nightmare (at least, for me!) It asks you to things the tool should do instead for you. And in a very rough summary, it is a tool from the past which had served its purpose nicely a long time ago. But it misses a ton of modern functionality for DBAs and DevOps.

When our team worked with many customers over the years, often in reference projects, almost everybody showed us a 5000-line-long shell script or an upgrade robot with emcli. Even Daniel before he joined our team had used the XML output of preupgrade.jar to pass this on to his PowerShell scripts. And every customer asked why Oracle is not offering a tool which automates database upgrades.

This was the birth of AutoUpgrade. We have some of the smartest people in Oracle in our team. And we have very smart customers. Bringing the pieces together, a few months later the folks showed me the first working prototype of AutoUpgrade. And from there, it took off like a rocket. We ran an extensive 9 month “secret” beta with 13 customers from all over the world, some with thousands of databases before we released AutoUpgrade in 2019 together with Oracle Database 19c officially to you. At this time we were already certain that it will serve its purpose, that it runs stable and allows complete end-to-end upgrade automation.

And over time, AutoUpgrade learned more and more new things.

Since we are already in the age of the CDB architecture with multiple PDBs, AutoUpgrade learned to migrate non-CDBs into PDBs, with or without encryption, it learned to unplug/plug/upgrade, it does your out-of-place patching – and so much more. It implements one of the coolest features in Oracle 19c, the refreshable clone PDBs as a migration technique with low outage time.

And trust me, this is not the end of the development. There is more coming. Our folks never rest. And we Product Managers have a lot of ideas we collect from you. AutoUpgrade constantly evolves and becomes better and more advanced. We’ll tell you soon what’s coming next …

But there is no GUI …

Please don’t cry. Pleaseeeee …

And yes, you are right. There is no GUI. But try to open a GUI on Exadata. Or on ExaCS? So you see easily: GUIs are not needed and often not useful. Of course, DBUA has this “silent” mode which gets used in our cloud here and there. But honestly, there is not a single task AutoUpgrade wouldn’t do better than DBUA. And you can fully script AutoUpgrade with all the flexibility we dreamed about 10 years ago.

I never missed the GUI since it made me inflexible. Clicking forward-forward-forward through a GUI tool slows me down. And using command line options over three lines to tell a GUI tool to do something I can do in AutoUpgrade with a simple and flexible config file sounds just broken to me. It is a bit like using Data Pump without a par file. Par files are smart. They make things repeatable and reproducible, you can automate tasks easily.

One day, one of our developers drafted a simple GUI prototype for AutoUpgrade. I bet it still sits in a drawer somewhere. I used it 2-3 times for fun – and I put it away. Not because it was badly implemented. It looked nice – and it did basically what I wanted. But it took away all the automation, all the ease I have with AutoUpgrade. I ran so many upgrades every week to test out things – and I just kick off a one-liner.

I never missed the GUI.

Coming back to DBUA and manual upgrade …

So let me now explain why we need to deprecate and desupport DBUA and the manual upgrade. I explained already that its tools from the past – and time has changed a lot. You don’t want to drill down into upgrades anymore. You have dozens and hundreds of databases to deal with. And AutoUpgrade has been proven to be the tool which automates all that for you, end-to-end. It gives you all the flexibility you need, and which the DBUA never offered, Upgrade with AutoUpgrade is resumable – and almost all larger customers we heard from use AutoUpgrade.

So it is time to retire DBUA and manual upgrade. Both are deprecated with Oracle Database 23c. Mapping back what I explained before, this means that we still will fix misbehavior where applicable – but we don’t develop anything anymore. And with the next innovation release both will be desupported, and may simply  disappear.

For me, this is a huge relief.

The number of customers getting addicted to AutoUpgrade is overwhelming. As you in your own environments need to retire tools and software from the past at one day, we do exactly the same. And if you ask me for my personal opinion, I would have sent DBUA and dbupgrade into retirement years ago already. They clearly deserve that. I think I did my last manual upgrade 3 years ago – and my last DBUA upgrade dates back even longer for multiple reasons.

Daniel raised a good point on the side: DBUA is using old Java too. Another reason why it must retire.

And in addition, we need to focus all developer resources on the tool everybody is using these days.

So don’t be angry on us. There is not one single thing you couldn’t do with AutoUpgrade which DBUA was able to do. But you can do a thousand things more – and better – with AutoUpgrade. And we can support it. Our Support team is very skilled with AutoUpgrade. In Oracle Database 23c, the DBUA and the dbupgrade wrapper will be still shipped for the evenings when you are in nostalgia mood and would like to walk down memory lane again and do an upgrade “the old way”.

And just to be clear, you should be able to use DBUA or dbupgrade to go to 23c since both are deprecated but not desupported. Still, I think it should be crystal-clear by now that you should use AutoUpgrade. Nobody in our PM will spend time to test DBUA to go to 23c. You should do the same, and just move forward with AutoUpgrade.

But frankly speaking, it is time to switch to something new, better, advanced, superior.

If you never tried AutoUpgrade, give it a try. Use our Hitchhiker’s Guide to Oracle Database Upgrade in our LiveLabs environment to play with it anytime anywhere for free.

And then, let us celebrate the deprecation and future desupport of the Database Upgrade Assistant together as soon as Oracle Database 23c gets released in the cloud and on-prem too.

Further Links and Information

• What does deprecated mean? And what does desupport mean?
• Tim Hall’s blog post about depreacted and desupported feature in Oracle Database 23c
• Oracle Database 23c Free Developer Edition
• The non-CDB architecture is deprecated in Oracle Database 12.1.0.2
• The non-CDB architecture is desupported and disappears in Oracle Database 21c
• Oracle Database 23c Free Developer Edition – Deprecation of DBUA
• Hitchhiker’s Guide to Oracle Database Upgrade in our LiveLabs environment
• AutoUpgrade to migrate from non-CDB to PDB, with or without refreshable clones

–Mike