ODA Patching Issue: Resolving DCS-10045 and DCS-12013 Errors During DB Home Update

DCS-10045: No Running Databases Found to Patch

During an Oracle Database Appliance (ODA) patching activity to version 19.30, I encountered two consecutive errors while running the database home prepatch checks: DCS-10045 and DCS-12013.

The database was a manually configured physical standby, and although it was running, the ODA patching workflow could not initially identify it as an eligible database. After addressing the first error, the prepatch checks failed again because of an inconsistency between the ODA storage metadata and the actual ASM directory structure.

In this post, I’ll explain how I investigated both errors and completed the DB Home patching process without recreating the standby database.

The steps of the overall patching is clearly defined in “X11 Deployment and User’s Guide for Linux x86-64 – Patching Oracle Database Appliance“. Also well defined in blog post “How to patch your ODA to 19.30?” by Jérôme Dubar.

In ODA patching, for each component you are patching, first you run prepare a patch report first.

[root@myoda ~]# /opt/oracle/dcs/bin/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 You may investigate the prepatch report by issuing the command below.

[root@myoda ~]# /opt/oracle/dcs/bin/odacli describe-prepatchreport -i 8c6e98fd-c541-4e1e-bfcb-9852649af4d1

In my case, Evaluate DBHome Patching with RHP Pre-Check Failed with:

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

There was no Oracle Support Note or a Blog post covering the issue I have encountered.

Although there was a database running from this database home, this was not reported by oda dcsagent (Oracle Database Appliance Database Cloud Service Agent).

This database was physical standby database which was setup manually and odacli was not aware of it. I have registered this database by using srvctl command provided below. It was a A single-node Oracle Database Appliance.

[grid@myoda1 ~]$ srvctl add database -db MYBLTDB -dbname MYBLTANKDB 
--oraclehome /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_12 
-spfile +DATA/MYBLTANKDB/PARAMETERFILE/spfilemybltankdb.ora 
-pwfile +DATA/MYBLTANKDB/PASSWORD/orapwMYBLTANKDB 
-role PHYSICAL_STANDBY -startoption MOUNT 
-stopoption IMMEDIATE -node myoda 

DCS-12013: Missing ASM Storage Location in ODA Metadata

After running this command, now crs and odacli was aware of the running standby database, but running precheck again still failed with the error provided below.

DCS-12013: Metadata validation error RHP encountered: dbStorage metadata missing Location info for database

The error indicated that ODA was unable to validate the database storage information registered in its metadata repository.

To investigate the issue, I checked the database storage information registered in ODA using:

[root@myoda ~]# odacli list-dbStorages

The command output showed the ASM storage locations associated with the database.

During the review, I noticed that one of the ASM locations registered in ODA did not actually exist in the ASM disk group. However, this directory was not present in ASM.

During the standby database creation, the db_file_name_convert parameter was used. This parameter redirected the database files to a different ASM directory location. As a result:

The original ASM directory registered in ODA metadata was never created. The actual database files were created under a different ASM path. I have created the directory it was searching for:

asmcmd> mkdir +DATA/MYBLTANKDB

Instead of modifying the ODA metadata or setting up the dataguard again, I created the missing ASM directory that was referenced by the dbStorage metadata. the dbStorage validation passed successfully. The ODA DB Home patching process was then completed without an error.

Hope it helps.