Monday, August 24, 2026

Troubleshooting OEM & Agent “No Route to Host” Errors on OCI

 

Resolving Oracle Enterprise Manager (OEM) on Oracle Cloud Infrastructure (OCI) can sometimes feel like peeling back layers of an onion. You’ve verified your VCN security lists, confirmed your ingress rules are wide open, and even checked that firewalld is inactive. Yet, the OEM console persists with a frustrating “No route to hosts” error on port 3872. If you’ve hit this wall, the culprit isn’t your cloud network – it’s hiding right underneath the OS hood. Oracle Linux images in OCI frequently carry pre-configured, low-level kernel packet filters or iptables rule chains that silently drop traffic on non-standard ports by default, completely bypassing higher-lelve firewall managers.

The below steps shows how to resolve “No Rout to Host” error on the OEM console.

 

1.       Check the ingress rule on the VCN to confirm that the OEM is allowed access to the VM on port 3872.

 

 

2.       Check Low-Level iptables Rules on the target VM

Run this command as root to see if a hidden drop or reject rule is intercepting port 3872 traffic:

sudo iptables -L -n -v | grep 3872

If this returns nothing or shows packets being dropped/rejected, iptables is blocking the connection.

3.       Test telnet from the OMS to the target VM on port 3872

Test telnet access from the OMS server to the DR server on port 3872.

The above output shows that the OEM is not able to reach the target VM on port 3872.

 

4.       Explicitly Force Open Port 3872 via iptables

To instantly force the local Linux firewall kernel to accept connections on port 3872, run:

  sudo iptables -I INPUT -p tcp --dport 3872 -j ACCEPT

5.       Test telnet access again from the OMS server to the DR server on port 3872.

The output shows that the OEM sever is now able to reach the target on port 3872.

 

6.       Add the internal targets and execute the upload agent command.

7.       The “No Route to Host” error is resolved and the target is now up.

The metric evaluation error is resolved, and the target is up on the OEM.

Friday, August 7, 2026

Fixing OCI Base DB GI Precheck Error DCS-10045 Caused by Metastore Duplication after OS Upgrade from Linux 7 to 8.


If you are upgrading an Oracle Cloud Infrastructure (OCI) Base Database Service operating system from Oracle Linux 7 to Oracle Linux 8, you might encounter a roadblock during Grid Infrastructure (GI) prechecks: 'DCS-10045: Validation error encountered: userNames are not unique' (or related DCS agent failures).

While standard DCS troubleshooting guides suggest restarting system services (‘systemctl restart initdcsagent’), this error often persists. In this blog, I’ll dive into why this happens after an OS upgrade and how to resolve it by cleaning up duplicate rows in the local MySQL metastore.

The below error is seen when the GI precheck process is executed.

                  

 Step by Step Procedure to resolve the DCS-10045 error

1. Connect to the MySQL instance on the DBCS

Switch to the root user and connect to local MySQL on port 3306 and switch to SQL mode.

2.        2. Identify Duplicate Entries

Run a query to check for duplicated user records across SysInstance_id, userId, userName, and userRole.

If this returns rows with cnt > 1, duplicate records are causing the conflict.

 3.       Deduplicate using a Temporary Table

To remove duplicates safely within a single transaction:

 4.       Verify that the user has been created

5.      Run the GI patch precheck again from the OCI console.

The precheck completes without any DCS-10045 error.

                

Troubleshooting OEM & Agent “No Route to Host” Errors on OCI

  Resolving Oracle Enterprise Manager (OEM) on Oracle Cloud Infrastructure (OCI) can sometimes feel like peeling back layers of an onion. Yo...