Oracle ODA 19.30 Patching Issue: update-dbhome Fails

Introduction

Recently, I encountered an unexpected issue while patching an Oracle Database Appliance (ODA) environment from 19.26 to 19.30.

Although I followed Oracle’s official patching instructions (X10 Deployment and User’s Guide for Linux x86-64), the odacli update-dbhome operation completed successfully on the first node but failed on the second node with a message indicating that no running database was found in the specified Oracle Database Home.

DCS-10045:Validation error encountered: No 'Running' databases found to patch. 

What made this situation particularly confusing was that the database instance on the second node was still running from the old 19.26 Oracle Home, while Oracle Clusterware had already modified the database with the new 19.30 Oracle Home.

Consequently, the patching process could not continue normally, and the database SQL patching phase (datapatch) also remained incomplete.

I could not find a documented procedure addressing this particular situation, so I had to investigate the current situation and complete the remaining steps manually.

In this post, I will explain what happened and how I resolved the issue.

1. Following Oracle’s Official Patching Procedure:

According to the Oracle Database Appliance 19.30 patching documentation, a prepatch report must be created before running odacli update-dbhome.

Oracle explicitly states:

You must run the odacli create-prepatchreport command before you patch your Oracle Database homes; otherwise, the odacli update-dbhome command fails with an error message prompting you to run the patching pre-checks.

I followed this requirement and completed the necessary prepatch checks before proceeding with the Database Home update. I ran the odacli create-prepatchreport command without the –local flag to perform the prepatch checks on both nodes.

In this command, <DB_HOME_ID> refers to the ID of my existing Oracle Database 19.26 home.

[root@myoda1 ~]# odacli create-prepatchreport --dbhome --dbhomeId <DB_HOME_ID> -v 19.30.0.0.0
Job details
----------------------------------------------------------------
               	   ID:  8c6e98fd-c541-4e1e-bfcb-9852649af4d1
          Description:  Patch pre-checks for [DB, RHPDB, ORACHKDB] to 19.30.0.0.0: DbHome is OraDB19000_home12
               Status:  Created
              Created:  July 23, 2026 21:19:21 EET
              Message:  Use 'odacli describe-prepatchreport -i 8c6e98fd-c541-4e1e-bfcb-9852649af4d1' to check details of results
 

Then later, I proceeded with the dbhome update. The command used to update the Oracle Home was:

[root@myoda1 ~]# odacli update-dbhome  --id <DB_HOME_ID> -v 19.30.0.0.0 --local  -f

Because I was performing the operation locally on each node for no down time, I used the --local option. Since this option provides rolling capability.

On Node 1: Update completed successfully. On the first node, odacli update-dbhome job completed successfully. The database instance was moved to the new 19.30 Oracle Home.

When I executed the same command on the second node, the operation failed. The error indicated that there was no running database associated with the specified Oracle Database Home. This was unexpected because the database instance was still running on node 2, using the old 19.26 Oracle Home.

Naturally, my first question was: How could odacli report that there was no running database when the instance was clearly running especially from the specified the DB_HOME_ID.

2. Investigating the Oracle Home Configuration

To understand what was happening, I checked the database configuration registered in Oracle Clusterware using srvctl.

[root@myoda1 ~]# srvctl config database -d <db_unique_name>

To my surprise, the database was already configured to use the new 19.30 Oracle Home. However, the instance on the second node had not yet been restarted from that home.

The successful update of the first node had already modified the database’s Oracle Clusterware configuration to point to the new Oracle Home. In fact, the new Oracle Database 19.30 home, including the required patches on top of the Release Update (RU), had already been provisioned during the prepatch phase. Instead, the problem was with completing the transition of the second database instance to the new home and executing the remaining database patching steps.

At this point, simply rerunning odacli update-dbhome on node2 was not resolving the issue.

3. Datapatch Could Not Complete

The problem was not limited to the Oracle Home configuration. During the patching workflow on the first node, a background job responsible for running datapatch performs a series of checks to make sure that all nodes are running with same patch level. Because node 1 was already using 19.30 while node 2 was still running from 19.26, the validation could not complete successfully.

Consequently, datapatch was not executed successfully as part of the automated process.

This left the environment in a partially updated state:

• The new Oracle Home was available.
• Clusterware pointed to the new Oracle Home.
• Node 1 was running from 19.30.
• Node 2 was still running from 19.26.
• Database SQL patching remained incomplete.

4. Workaround: Completing the Remaining Steps Manually

Since I could not find a documented procedure for this exact situation, I decided to complete the remaining operations manually.

Step 1: Stop the database instance on node 2

First, I stopped the database instance that was still running from the old 19.26 Oracle Home.

[oracle@myoda1 ~]$ srvctl stop instance -d <db_unique_name>   -i <instance_name_2>

This ensured that the instance was no longer running from the old Oracle Home.

Step 2: Start the instance from the new Oracle Home

Next, I started the database instance again using srvctl.

[oracle@myoda1 ~]$ srvctl start instance -d <db_unique_name>   -i <instance_name_2>

Because Clusterware was already configured with the new 19.30 Oracle Home, the instance started using the new home. After starting the instance, I verified that it was running correctly and using the expected Oracle Home. At this stage, both database instances were running from the updated 19.30 Oracle Home.

Step 3: Create the datapatch prepatch report

The next step was to complete the database SQL patching phase by running datapatch.

One important requirement is that Oracle Database Appliance (ODA) expects the corresponding prepatch report to exist before proceeding with the database SQL patching operation. If the datapatch prepatch report has not already been generated, you can create it using the following command:

[root@myoda1 ~]# odacli create-prepatchreport -dp  -dbid <databaseId>

Important: The <databaseId> parameter refers to the unique identifier of the database object managed by ODA, not the Oracle Database DBID. You can find the appropriate database ID by running:

[root@myoda1 ~]# odacli list-databases

This generates the prepatch report for the database SQL patching operation.

Step 4: Execute datapatch through ODACLI

After the prepatch checks were completed successfully, I executed the following command.

[root@myoda1 ~]# odacli update-database -i <databaseId> -dp

This command runs the datapatch on first node. In my case, this completed the remaining datapatch operation successfully.

Step 5: Verify the database patch level

Finally, I verified the database patching status. The following SQL query can be used to inspect the SQL patches applied in the database.

SELECT patch_id,
       patch_type,
       action,
       status,
       description,
       action_time
FROM dba_registry_sqlpatch
ORDER BY action_time DESC;

5. Conclusion

What initially appeared to be a straightforward Oracle Database Appliance patching operation from 19.26 to 19.30 turned into an unexpected troubleshooting exercise. The first node was patched successfully, but the second node could not proceed because Clusterware had already registered the new Oracle Home while its database instance was still running from the old home. In my environment, the solution was to stop the second instance, start it from the new Oracle Home, and then complete the SQL patching operation using odacli update-database -dp, after generating and reviewing the required prepatch report.

I cannot confirm the underlying product defect or precise internal failure without additional diagnostic information, but the mismatch between the registered Oracle Home and the home used by the running instance was clearly observable. Sometimes, even when you follow the official documentation step by step, the actual patching process can behave differently than expected.

Hope this post helps.