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

Goal

Establish an alerting approach that surfaces critical database conditions — such as tablespace exhaustion or sustained CPU saturation — without flooding operators with repeated notifications for the same underlying issue.

Constraints and Uncertainty

Metric-based alerts configured through DBMS_SERVER_ALERT or EM Express aggregate repeated threshold breaches into a single active alert until the metric returns to normal, reducing noise by design. However, they only expose a predefined set of system metrics and clear automatically once the condition subsides, potentially hiding intermittent spikes unless supplemental logging is enabled. In contrast, DBMS_ALERT provides application-level, point-to-point signaling for custom conditions, but each SIGNALWAITANY or WAITONE.

Enterprise Manager adds suppression policies (repeat interval, escalation after N occurrences) that apply to both mechanisms, yet those policies require specific privileges on MGMT_* views and may not propagate to third-party tools that read the alert log directly. Changing threshold values or repeat intervals can also require a database bounce or EM repository reload in some releases, affecting monitoring continuity.

Questions

1. For a workload where only a handful of system metrics (tablespace usage, CPU, session count) matter, does the built-in aggregation of metric-based alerts provide sufficient noise reduction without custom code?
2. If application-specific conditions (e.g., a PL/SQL batch job exceeding a runtime SLA) must be surfaced, can DBMS_ALERT be throttled effectively at the source, or should a lightweight wrapper table with timestamp-based deduplication be used instead?
3. How do EM suppression policies interact with DBMS_ALERT signals consumed by external monitoring — are they applied before the signal reaches the queue, or only within the EM console?