Resolving OCI Database Management "UNKNOWN" Status and "Monitoring Stopped" Alerts

Introduction

If you are managing Oracle databases on Oracle Cloud Infrastructure (OCI), few sights are as jarring as seeing a critical "Monitoring Stopped - Metric collection issue" alarm fire out of nowhere. If you navigate to the OCI Console only to find your Managed Database status marked as UNKNOWN, you are likely dealing with a communication breakdown.

In this blog, I’ll walk through how a standard database password expiration policy can completely blindside your OCI cloud monitoring—and how to quickly fix it by resetting the DBSNMP user and updating the OCI vault. 

The issue typically begins with a critical automated alert from OCI Monitoring:

Alarm: OK_TO_FIRING : CRITICAL : Monitoring Stopped - Metric collection issue

When you log into the OCI Console to investigate, the database page shows:

• Status: UNKNOWN

• Metrics: All charts (CPU, Memory, Session limits) flatlined or showing empty gaps.

• 
  
  
  
  

Because the status is UNKNOWN (rather than DOWN), it indicates that while the infrastructure may be fine, the OCI Management Agent cannot pull telemetry from the database.

How to Resolve It (Step-by-Step)

1. First, you need to log into your database host via SSH and run SQL*Plus as SYSDBA to check the account's actual status and reset the password.

Tip: If you want to prevent this from happening again to your service accounts, consider assigning DBSNMP to a custom DB profile with a longer (or unlimited) password lifetime policy.

2. Since the DBSNMP user password has EXPIRED, I decided to extend the password by reusing the encrypted hash value. You can get the hash value using the below command. 

     

With the method of extending the DBSNMP password, there is no need to update the OCI vault secret because it is the same password. 

3. After extending the DBSNMP password, check the status of the database monitoring The status should change from UNKNOWN to UP.

Fixing False-Positive OCI IPsec Alarms in Active-Passive Topologies

 

When deploying an Oracle Cloud Infrastructure (OCI) Site-to-Site VPN in an active-passive (standby) configuration, Tunnel 2 is often intentionally left down on the customer-premises equipment (CPE). However, a default OCI Monitoring alarm will treat this intentional downtime as a critical failure, flooding your inbox with repeat alerts.

This happens because an un-scoped Monitoring Query Language (MQL) expression evaluates all metric streams across the entire compartment, and tunnel 1 which is active remains in FIRING state. The screenshot below shows that Tunnel2 is in the resourceName of the notification sent from the monitoring instead of Tunnel1. This blog provides a guided approach to avoid false alarm for the active tunnel.

The Problem: Blanket MQL Queries causing active Tunnel to remain in FIRING state

A standard alarm query often looks like this:

TunnelState[5m].mean() == 0

Because no specific dimensions are defined inside the curly braces {}, OCI checks the TunnelState of both Tunnel 1 and Tunnel 2. Even if Tunnel 1 is perfectly healthy (returning a value of 1), Tunnel 2 being down (returning 0) satisfies the condition, triggering a false CRITICAL state and tunnel 1 remains in FIRING state.

 

Step-by-Step Resolution Procedure

Step 1: Identify the Affected Alarm

1. Log into the OCI Console.
2. Open the navigation menu, go to Observability & Management, and select Alarm Definitions under the Monitoring section.
3. Locate and click on the alarm that is generating the false alerts 
4. 
   
   

4. Step 2: Edit the Alarm Query

1. On the alarm's detail page, click the Edit button at the top.
2. Scroll down to the Creation Mode section and choose advance mode to enable you edit the  MQL expression.
3. Look at the Query text box. Notice that it lacks specific resource dimensions.

 

Step 3: Scope the Query to the Active Tunnel

To force the monitoring engine to ignore the standby tunnel, modify the query to explicitly filter by the resourceName dimension of your active tunnel.

Update the expression to the following:

Step 4: Verify and Save

1. Click the Edit query or Stream graph preview button to ensure the metric stream updates correctly and shows only the data for Tunnel 1.
2. Scroll to the bottom of the page and click Save changes.

The Result

Once saved, OCI's Monitoring service drops the Tunnel 2 metric stream from its evaluation loop. Within one evaluation cycle 5 minutes based on my window, the alarm state will transition from FIRING back to OK, permanently stopping the repetitive alert emails while keeping your primary production path fully monitored.