AutoUpgrade, my first incident
As part of an upgrade project from Oracle 11.2 to Oracle 19c, the first step is to run AutoUpgrade in analyze mode for each of the databases to work with; something relatively easy, bulletproof, or at least I thought so, because at the first attempt I got error messages, in less than 2 seconds!
java -jar autoupgrade.jar -config dbron.cfg -mode analyze
AutoUpgrade 24.8.241119 launched with default internal options
Processing config file ...
Internal Error has occurred. Please contact Oracle support.
java.lang.IllegalStateException
at oracle.commonx.config.rac.ClusterDetails.findCurrentInstance(ClusterDetails.java:396)
at oracle.commonx.config.rac.ClusterDetails.generateRacOneList(ClusterDetails.java:328)
at oracle.commonx.config.rac.ClusterDetails.getNodeInstanceInfos(ClusterDetails.java:307)
at oracle.commonx.config.rac.ClusterDetails.buildPojo(ClusterDetails.java:433)
at oracle.upgrade.autoupgrade.config.crafter.FullUpgCreator.craft(FullUpgCreator.java:757) Checking the log, it was noticeable that AutoUpgrade did not even connect to the database.
What could be happening? Let’s see.
The problem
The cluster I was working on consists of 3 physical servers (NODE1, NODE2, NODE3), running RHEL 7.9, Oracle Clusterware 19.24, and a dozen RAC One Node (aka RON) databases on Oracle 11.2.0.4.
In the autoupgrade.log file it is noted that AutoUpgrade aborts when executing the findCurrentInstance method, inside the ClusterDetails class.
2025-01-07 08:20:35.043 WARNING null - Bootstrap.processCLIParams#83
java.lang.IllegalStateException
at oracle.commonx.config.rac.ClusterDetails.findCurrentInstance(ClusterDetails.java:396)I don’t know much about Java, but I had the idea that maybe it was something simple, so I searched the web for a decompiler to take a look at the code.
I find that within findCurrentInstance it searches if the server from which I am running AutoUpgrade (which is where the active instance of dbron is running) is within the list of servers on which it can run the RON database.
So far, everything seems to be within the normal logic, so why the failure?
In the same log, lines before the error, it is observed that the list of candidate servers are: node1 and node2.
2025-01-07 08:20:35.043 INFO RACOne detected - ClusterDetails.generateRacOneList#311
2025-01-07 08:20:35.043 INFO Starting - ClusterDetails.getCandidateServers#402
2025-01-07 08:20:35.043 INFO Candidate servers node1,node2 - ClusterDetails.getCandidateServers#405
2025-01-07 08:20:35.043 INFO Candidates [node1, node2] - ClusterDetails.generateRacOneList#315 Have you noticed? I’ll give you a few minutes to elaborate your theories….
Answer: AutoUpgrade is considering node1 and node2 as valid servers, but the servers are actually NODE1 and NODE2.
As AutoUpgrade and the active instance of dbron is being executed from NODE1, this string is searched in the list of candidate servers node1, node2, and certainly does not find it and aborts immediately.
The solution
It is unavoidable to turn to Oracle Support and open a Service Request.
I attach all the available information, and I point out my suspicions about the comparison of upper and lower case strings, and in a few hours they provide me with a new jar which I run and voila, everything works correctly!!!!
java -jar autoupgrade_custom.jar -config dbron.cfg -mode analyze
AutoUpgrade 25.8.250108 launched with default internal options
Processing config file ...
+--------------------------------+
| Starting AutoUpgrade execution |
+--------------------------------+
1 Non-CDB(s) will be analyzed
Type 'help' to list console commands
upg> Job 100 completed
------------------- Final Summary --------------------
Number of databases [ 1 ]
Jobs finished [1]
Jobs failed [0]
Please check the summary report at:
/u01/app/oracle/cfgtoollogs/autoupgrade/dbron/cfgtoollogs/upgrade/auto/status/status.html
/u01/app/oracle/cfgtoollogs/autoupgrade/dbron/cfgtoollogs/upgrade/auto/status/status.log Since I have the Java decompiler, I take another look at the code and find that now the strings to be compared are transformed to lowercase prior to the search (toLowerCase).
With this I close the case and continue with the upgrade tasks without major problems.
I take this opportunity to thank the AutoUpgrade development team for the excellent service they provided me, they are the best!!!!