Metric-Based Alerts vs. DBMS_ALERT: Choosing a Noise-Control Strategy for Oracle 19c

For standard system metrics, built-in metric-based alerts provide sufficient noise reduction. For application-specific SLAs, a wrapper table with timestamp-based deduplication is the recommended approach over DBMS_ALERT.

System Metrics and Noise Reduction

When monitoring common metrics like tablespace usage, CPU saturation, or session counts, DBMS_SERVER_ALERT (and by extension, EM Express) is the optimal choice. These mechanisms use native aggregation: once a threshold is breached, a single active alert is generated. Subsequent breaches of the same threshold do not trigger new notifications until the condition is resolved and the alert is cleared.

Verification of Metric Aggregation

You can verify the current state of aggregated alerts by querying the system views:

SELECT alert_name, status, last_modified
FROM v$alert_status
WHERE status = 'OPEN';

Application-Specific SLA Monitoring

DBMS_ALERT is a signaling mechanism for inter-session communication, not a monitoring framework. It lacks native throttling; every SIGNAL call wakes up every session waiting on that signal. To prevent notification storms during a sustained SLA breach, do not rely on DBMS_ALERT alone.

Recommended Implementation: Wrapper Table

To throttle application alerts, implement a lightweight state table to track the last notification time:

• Schema: Create a table containing alert_id, last_sent_timestamp, and current_status.
• Logic: Before signaling an alert, check if (SYSTIMESTAMP - last_sent_timestamp) exceeds your desired suppression interval (e.g., 1 hour).
• Action: Only trigger the notification and update the timestamp if the interval has elapsed or the status has changed from 'CRITICAL' to 'RESOLVED'.

EM Suppression and External Tooling

Enterprise Manager (EM) suppression policies are applied at the management console level. They govern how the EM UI displays alerts and how the EM notification engine sends emails or pages.

These policies do not filter the underlying data sources. If an external monitoring tool reads the alert log or listens for DBMS_ALERT signals directly, it will receive every event regardless of the EM suppression settings. To control noise for third-party tools, deduplication must happen at the database source (via the wrapper table method) or within the third-party tool's own logic.

Diagnostic Requirement

To refine this recommendation, please specify if your external monitoring tool consumes alerts via V$ views, the XML alert log, or a custom API, as this determines where the deduplication logic must reside.