Many of you have used AutoUpgrade for your database upgrades already. Just a few days ago I received some almost enthusiastic comments which made me very very happy. And if you thought it can’t get any better, no worries: AutoUpgrade 2.0 has been released – and got reuploaded.

Photo by Graham Pengelly on Unsplash
Why AutoUpgrade 2.0?
As you know, we don’t do marketing but just talk tech. But you may have also recognized that we slowed down in our agile release cycle for AutoUpgrade. The simple reason for this long period of silence was that we’ve had a massive refresh of AutoUpgrade in our minds. The entire development team worked very hard not only in fixing some open issues and including some long awaited enhancements but also on releasing some new key features.
And this is the reason why we rather call it AutoUpgrade 2.0 as it marks a new major release with lots of new features, improvements and functionalities.
Still, no worries: You need only the newest version of AutoUpgrade. As usual, you just replace the existing version of AutoUpgrade on disk with the newest one you download from:
This is the version you need to have as of now:
$ java -jar autoupgrade.jar -version build.version 22.2.220324 build.date 2022/03/24 10:38:48 -0400 build.hash 122250c build.hash_date 2022/03/24 10:31:13 -0400 build.supported_target_versions 12.2,18,19,21 build.type production
Why reuploaded?
As much as we tested, somehow an issue came with the first revision of the tool. So please make sure in case you downloaded it within the first days to refresh it. You need version 22.2.220324.
Otherwise you may see this error pattern:
[Log Directory] /u01/software/upgrade19/sid/100/prechecks [Detail] /u01/software/upgrade19/sid/100/prechecks/cdb_preupgrade.log Check failed for CDB$ROOT, manual intervention needed for the below checks [TARGET_HOME_REGISTERED_INVENTORY] Cause: Reason: Database Checks has Failed details in /u01/software/upgrade19/sid/100/prechecks Action: [MANUAL] Info: Return status is ERROR ExecutionError: No Error Message: None REQUIRED ACTIONS ================ 1. Execute command $ORACLE_HOME/oui/bin/attachHome to attach the target ORACLE HOME on each listed node. The target ORACLE HOME for the following hostnames [localhost] are not registered on the Oracle Inventory. Deploy mode will be aborted. The target ORACLE HOME must be registered on the Oracle Inventory.
You won’t solve the issue by reattaching your Oracle Home. But the version of AutoUpgrade from March 24, 2022 fixes this incorrect error check.
What’s new?
The list of new features and enhancements is incredibly long. And we did an internal beta test in January to stress the new features. As usual, you’ll find the change log in MOS Note: 2485457.1. And when you check this time, you will find key features such as:
- Hot Cloning/Relocate with AutoUpgrade
- Often an upgrade goes in line with a hardware migration, too. Hence, you will move a database from one server to another.
AutoUpgrade can perform this operation for you and automate these manual steps. The feature supports non-CDBs and PDBs as source, and will lead to a PDB on the target host. You will need to create a database link between the target CDB and the source database.
- Often an upgrade goes in line with a hardware migration, too. Hence, you will move a database from one server to another.
- Proactive-Fixups
- The name of the feature may be a bit misleading but it means that postupgrade fixups in PDBs can be done as soon as the CDB$ROOT upgrade has been finished. So assume a CDB with 50 PDBs. As soon as the first PDBs are upgraded, the fixups can be started while the next stack of PDBs are in still in upgrade mode. This will allow you quicker access to the PDBs. Beforehand, the postupgrade fixups did happen once all PDBs were upgraded. I’d rather call this an efficiency enhancement.
- AutoUpgrade REST API for the Oracle Database using RESTful Services in a web environment
- From now on you can orchestrate AutoUpgrade with ORDS (Oracle REST Data Services) calls. This way, AutoUpgrade REST APIs provide a uniform interface for AutoUpgrade on client-server architectures, and enables you to leverage and integrate AutoUpgrade features through HTTP and HTTPS protocols. Now you can upgrade Oracle Databases automatically.
The Oracle REST Data Services implementation is based on a Java Enterprise Edition (Java EE) data service that provides enhanced security, file-caching features, and RESTful Web Services. This service provides increased flexibility for standalone deployments, as well as through servers, such as Oracle WebLogic Server and Apache Tomcat. Oracle REST Data Services is a common plugin mechanism used by most Oracle Database components and tools.
- From now on you can orchestrate AutoUpgrade with ORDS (Oracle REST Data Services) calls. This way, AutoUpgrade REST APIs provide a uniform interface for AutoUpgrade on client-server architectures, and enables you to leverage and integrate AutoUpgrade features through HTTP and HTTPS protocols. Now you can upgrade Oracle Databases automatically.
- Enhanced Transparent Data Encryption (TDE) support
- AutoUpgrade did support TDE setups before already. But in several scenarios you needed to do some manual steps, especially with non-auto-logon keystores/wallets. The new enhancements will allow to progress the upgrade in “deploy” mode without manual intervention.
- Distributed Database Upgrade via RAC
- Did you ever ask yourself why you couldn’t leverage all the other nodes in your RAC environment for PDB upgrades, too? Now AutoUpgrade supports distributing the upgrade workload to all nodes in a RAC environment. This way not only the workload per node gets decreased but you’ll see overall much faster upgrade times in RAC environments, and hence less downtime, too.
Curious now? Then sign up …
You want to hear more? No problem, you’ll sign up to our next Virtual Classroom Seminar, Episode 14: AutoUpgrade 2.0 where we demonstrate and showcase all these new features.
The registration is already open. And we look forward to show you those cool new features in a few weeks. If you tried them out before already, then bring your questions. As usual we’ll try to answer all of them throughout the seminar.
Further Links and Information
- MOS Note: 2485457.1 – AutoUpgrade Tool Download
- May 5, 2022 – 14:00h CET – Virtual Classroom Seminar Episode 14: AutoUpgrade 2.0
–Mike
great, thanks for amazing job Mike.
Thanks Mustafa!!
Cheers,
Mike
AutoUpgrade 2.0 – New Features and Best Practices
A new version of AutoUpgrade has been released. But this time it is a highly improved version with many new key features such as Patching……..
Patching, interesting, I can’t find any example in de docs yet, can you spend a blog on this?
Kind Regards, Erwin
Wait for the seminar – there will be another AU version in between. This is not included in the current one 🙂
So you’ll have to wait for the first week of May 🙂
Cheersm
Mike
“Hot Cloning/Relocate with AutoUpgrade: The feature supports non-CDBs and PDBs as source, and will lead to a PDB on the target host.”
Does this mean non-CDB to non-CDB cloning is not possible?
Hi Ravi,
not with AutoUpgrade. Cloning is a PDB feature. And we allow this by having a non-CDB as source.
If you’d like to clone non-CDB to non-CDB you’d have to use solutions such as gdbclone.
Cheers,
Mike
Any plans moving it from “attachment to a MOS document” into getting a bug number and ARU API download?
Thanks.
Hi Juraj,
we tried this but it didn’t get approved yet.
Cheers
Mike
Has this version addressed the need to comment out SQLNET.WALLET_OVERRIDE=TRUE from sqlnet.ora before running autoupgrade? Not commenting this out in previous versions caused the DRAIN step to fail.
Hi DougK,
all should be fixed and working.
Please see our Virtual Classroom Seminar about AutoUpgrade 2.0 where we describe all aspects.
https://MikeDietrichDE.com/videos
Cheers,
Mike
Hi Mike,
running a POC on TDE, I’m still getting an error on TARGET_CDB_COMPATIBILITY – Master key is not set in the CDB while when using -load_password all passwords are Verified and v$encryption_wallet shows open (auto login wallets are used).
I have a 19c non-CDB patched to 19.15.0 and I try to upgrade it to 21c and plug into an existing 21c CDB.
Is this an issue in Autoupgrade tool that still needs to be corrected or am I missing something ?
TDE support has been added with -load_password but I’m not sure I missed something.
Thanks
Hi Stephane,
we refreshed the version of AU and fixed a few things. Can you please check again with the version being available since last week – and if it does not work, open an SR, upload the logs collected with “java -jar autoupgrade.jar -config myconfig.cfg -zip” and send me the SR number either via the blog here or via email (mike.dietrich …. at ….. oracle.com) ?
Thanks
Mike
Hi Mike
I had some help from Daniel and the issue is solved now. On the CDB a keystore needs to be created and a master key needs to be set before AutoUpgrade is called. Then AU takes care of copying the keys from source to target Db. I did not find this step documented and I copied the p12 and sso files from source to target Db, which should not be done.
Regards
Hi Stephane,
I think Daniel is already working with the doc writer to embed the steps into the doc.
Thanks for your patience, and glad you could solve it together with Daniel!
Mike
Hi Mike,
I can confirm that this isn’t fixed in 22.2.220324. If SQLNET.WALLET_OVERRIDE=TRUE is not commented out of the 11g home sqlnet.ora file, the DRAIN step fails.
I mentioned this issue to Daniel a week or two ago.
Regards,
Doug
Thanks Doug!
Then Daniel will have reported it to the Dev team.
Cheers
Mike
I just this moment noticed that 22.3.220503 has been released. Will let you know if this has been fixed in this most recent version.
Thanks.
Thanks!
Cheers
Mike