AutoUpgrade 2.0 has been released – and got reuploaded

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.

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.
  • 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.
  • 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

–Mike

Share this: