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
Hi Mike, Any update on the patching “feature” with AU?
Hi Erwin,
it is there since Fall 2022 now. If you grab the most recent version, you will have it.
Cheers
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,
Just confirmed that not commenting out SQLNET.WALLET_OVERRIDE=TRUE from the 11g home still causes DRAIN to fail. This is true of 22.4.220712 and the previoius 22.3 releases. I have submitted a reopen request on my SR that was originally submitted back in October.
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
Does anyone ever test this on windows database? Some fools still think it’s a suitable platform.
# New options for migrating and creating CDB from NONCDB
upg1.sid=UPG1
upg1.target_cdb=CDBUPG1 # ORACLE_SID of the target DB/CDB
upg1.source_dblink.UPG1=CLONENONCDB 60 # Refresh from source every 60 seconds
upg1.target_pdb_name.UPG1=PDBUPG1
upg1.target_pdb_copy_option.UPG1=file_name_convert=(‘E:\Oracle\OraData\UPG1’, ‘E:\Oracle\OraData\CDBUPG1\PDBUPG1’)
upg1.start_time=+45m
upg1.upgrade_node=WIN-0JTF1QLOG2T
Exception: SQLException
Err message: Errors executing [/* D8F25E */exec dbms_pdb.describe(pdb_descr_file => ‘H:\app\oracle\Autoupgrade\Logs\UPG1\108\prechecks\UPG1-PDBUPG1.xml’);
BEGIN dbms_pdb.describe(pdb_descr_file => ‘H:\app\oracle\Autoupgrade\Logs\UPG1\108\prechecks\UPG1-PDBUPG1.xml’); END;
*
ERROR at line 1:
ORA-65026: XML metadata file error : LPX-00202: could not open “H:\app\oracle\Autoupgrade\Logs\UPG1\108\prechecks\UPG1-PDBUPG1.xml” (error 0)
ORA-06512: at “SYS.DBMS_PDB”, line 13
ORA-06512: at line 1
] [UPG1]
java.sql.SQLException: Errors executing [/* D8F25E */exec dbms_pdb.describe(pdb_descr_file => ‘H:\app\oracle\Autoupgrade\Logs\UPG1\108\prechecks\UPG1-PDBUPG1.xml’);
BEGIN dbms_pdb.describe(pdb_descr_file => ‘H:\app\oracle\Autoupgrade\Logs\UPG1\108\prechecks\UPG1-PDBUPG1.xml’); END;
*
ERROR at line 1:
ORA-65026: XML metadata file error : LPX-00202: could not open “H:\app\oracle\Autoupgrade\Logs\UPG1\108\prechecks\UPG1-PDBUPG1.xml” (error 0)
ORA-06512: at “SYS.DBMS_PDB”, line 13
ORA-06512: at line 1
Hi Fred,
we do – and I think the newest AU version has a fix for it.
Cheers
Mike
Confirming that even with autoupgrade 22.3.220503, SQLNET.WALLET_OVERRIDE=TRUE must be temporarily commented out from the 11g sqlnet.ora when upgrading from 11.2.0.4.
This permission issue is very similar to the tortuous journey into autograde version 1 on windows where I couldn’t read the logs from failures due to permission errors. The security has been scramble again on the logs directory where the pdb describe is being written. “The permissions on 101 are incorrectly ordered which may cause some entries to be ineffective”. Obviously fixing it now is pointless as the next run is going to create directory 102 which is also going to be corrupt.
Running the failing SQL into a different directory works:
1 BEGIN
2 DBMS_PDB.DESCRIBE(pdb_descr_file => ‘C:\temp\UPG1-PDBUPG1.xml’);
3* end;
upg1:SYS@UPG1 > /
PL/SQL procedure successfully completed.
Fred,
did you open an SR and upload the logs of AU?
If yes, please share the SR number with me.
If no, could you please do this and share the SR number with me?
java -jar autoupgrade.jar -config myconfig.cfg -zip
Thanks
Mike
Hi Mike, see SR-29692720841 -AutoUpgrade Version 2 doesn’t work on windows.
Created June 1st 2022, last visited by support June 21st when I uploaded the last zip file I have.
Regards,
Fred
Hi Fred,
I see you have two SRs:
3-29692720841
3-30211883561
whereas the 2nd one is the internal collaboration SR opened by the support team.
Support works on both of them – I will keep an eye on them.
Cheers
Mike
Hi Mike,
We have a requirement to upgrade customer database running on 11.2.0.4 RAC (source) on RHEL 6.5 to 19.3 RAC (target) on RHEL 7.6.
One option I thought was to install 11.2.0.4 RAC in target and setup DG and upgrade using DBUA. Customer not agreeing to install 11.2.0.4 RAC in target.
Can I use Autoupgrade 2.0 with Source DB and Target DB in separate servers?
Regards,
Thiru
Hi Thiru,
yes, this is exactly the use case we created it for. Please see:
https://mikedietrichde.com/2020/08/03/oracle-autoupgrade-between-two-servers/
https://mikedietrichde.com/2020/08/04/oracle-autoupgrade-between-two-servers-and-plugin/
And you need to do the SRVCTL configuration in this case on the target host to register the database with Clusterware.
Cheers
Mike
Hi Mike
I think autoupgrade doesn’t adjust the PATH for the DATA_PUMP_DIR directory. After a data guard Fast_Start failover and/or a switchover on the upgraded databases, the DATA_PUMP_DIR default PATH pointing to the old ORACLE_HOME is recreated. I was just wondering why the old directory was created again under old ORACLE_HOME/rdbms/log. (Severity 3 SR 3-29887793741 : logfiles are placed in old ORACLE_HOME)
But yes, autoupgrade was very helpful and does a really good job 🙂
We used autoupgrade for lots of 12.2 to 19c migrations and all was working fine:-)
Wish You a nice day.
best regards
Stefan
Hi Stefan,
to which patch bundle are you upgrading?
I’m asking because it does not depend on AU but on the patch level.
You could run:
$ORACLE_HOME/rdbms/admin/utlfixdirs.sql
to fix this.
See here:
https://mikedietrichde.com/2021/08/12/dbms_optim_bundle-and-out-of-place-patching/
Thanks
Mike
Hi Mike,
thank You very much for the excellent informations. It’s very helpful for me:-)
with best regards
Stefan
Thanks for the feedback, Stefan!
Cheers,
Mike
I would like to restrict user access to a specific database before starting autoupgrade but also after since we need to make some additional changes. If I put the database in restricted mode, would autoupgrade (1) complain/fail (2) disable restricted mode once done ????
Hi Pedro,
this is the wrong way of doing it. Disable the service – or the listener instead.
Cheers
Mike
I Agree with you, we typically do that for non_RAC database upgrades. But in a RAC installation with multiple databases in the same cluster, what would be the best way to do that ?
Hi Pedro,
this depends on the load and noise you’d like to have, and other things such as “common downtime” etc.
Please have a look into our Virtual Classroom Seminar 14 for the new features we added for RAC databases:
https://mikedietrichde.com/videos/
Cheers,
Mike
Hi Mike,
I can’t get enough of Your Videos!
So: What about Release 22.4.220712?
AutoUpgrade Patching sound’s quite interresting.
Are there changes when working with Hot Cloning/Relocate.
As my company asked me to talk about autoupgrade on DOAG Berlin in November, it would be great to get some words about autoupgrade from You – who else could do it better?
Regrards Christiam
Hi Christian,
the new AU version is coming in a few days.
Please wait for our slides from OCW next week – this is what you are looking for 🙂
Cheers
Mike