Customizing Oracle Alerts and Reactions

Question: do you need Oracle Enterprise Manager Cloud Control to customize alerts and reactions on Oracle AI Database 26ai?

No, not always. Enterprise Manager 24ai is the most complete console for this work, metric thresholds with custom text, incident rules, event compression, corrective actions, and notification routing to email, Slack, webhooks, SNMP, or a script, all managed centrally across a fleet. That's the right tool when you have many targets, need consistent policy across them, and want automated remediation and routing built in. But it's not the only path, and for a small number of databases with straightforward thresholds, you can accomplish real alerting without it. This lesson covers both.

Create or customize metric thresholds

1. Log in to Enterprise Manager.
2. Navigate to Targets, then Databases, select your database, then Monitoring, then Metric and Collection Settings.
3. Locate the metric, tablespace usage percentage, for instance.
4. Click Edit.
5. Set Warning and Critical thresholds.
6. Choose a collection frequency.
7. Save.

Set up corrective actions

1. Still within Metric and Collection Settings, find the metric in question.
2. Select Set Corrective Action.
3. Attach a shell or SQL script, restarting a listener, resizing a tablespace, or notifying a DBA directly.
4. Define the scope, Warning level, Critical level, or both.
5. Save.

A common example: automatically extending a tablespace once usage crosses 95 percent.

Notification rules

1. Go to Setup, then Notifications, then Rules.
2. Create a rule set for the Database Instance target type.
3. Choose specific metrics or alert severities.
4. Set the notification method: email, SNMP trap, webhook, or a custom script.

What's available depends on where the database actually runs:

Need	Without Cloud Control
Database server-generated alerts (tablespace usage, snapshot too old, and similar)	Set thresholds with DBMS_SERVER_ALERT; view DBA_OUTSTANDING_ALERTS and DBA_ALERT_HISTORY
Application-level "something changed" signals	DBMS_ALERT combined with triggers
Autonomous Database lifecycle and maintenance events	OCI Events and Notifications (email, Slack, Functions, HTTPS)
Sending Slack or email directly from Autonomous	DBMS_CLOUD_NOTIFICATION
Security or audit-style alerts	Unified Audit combined with Data Safe alert policies
Health and first-failure diagnostics	Autonomous Health Framework (AHF)

Each of these lets you define a condition and a reaction, email, webhook, script, or ticket, without standing up Cloud Control at all.

Two of these are worth a closer look, since a table entry alone undersells them. DBMS_CLOUD_NOTIFICATION lets an Autonomous Database send a Slack message or email directly from PL/SQL, no external orchestration layer required, useful for exactly the kind of "notify someone now" reaction that would otherwise mean standing up a separate notification service. The Autonomous Health Framework, AHF, bundles what used to be several separate diagnostic collection tools into one, capturing the first-failure diagnostic data an issue actually needs before anyone manually intervenes and potentially disturbs the evidence. Neither requires Enterprise Manager, and both are specifically built for Autonomous and cloud-hosted deployments rather than being cloud-adapted versions of on-premises tools.

A working example using DBMS_SERVER_ALERT directly, on-premises or in any scripted environment:

BEGIN
  DBMS_SERVER_ALERT.SET_THRESHOLD(
    metrics_id              => DBMS_SERVER_ALERT.TABLESPACE_PCT_FULL,
    warning_operator        => DBMS_SERVER_ALERT.OPERATOR_GT,
    warning_value           => '85',
    critical_operator       => DBMS_SERVER_ALERT.OPERATOR_GT,
    critical_value          => '95',
    observation_period      => 1,
    consecutive_occurrences => 1,
    instance_name           => NULL,
    object_type             => DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE,
    object_name             => 'USERS'
  );
END;
/

Review what's outstanding directly from SQL, no console required:

SELECT * FROM DBA_OUTSTANDING_ALERTS;
SELECT * FROM DBA_THRESHOLDS;

These two approaches aren't really competing options so much as points on the same path most environments actually travel. A small shop with one or two databases often starts exactly where the PL/SQL example above leaves off: a handful of DBMS_SERVER_ALERT thresholds, checked with a quick SQL query when something seems off, maybe a cron job emailing the DBA when DBA_OUTSTANDING_ALERTS returns a row. That's a completely reasonable, low-overhead setup, and there's no need to apologize for it or feel behind for not running Enterprise Manager.

What usually forces a change isn't the thresholds themselves, it's scale and consistency. Once there are a dozen databases instead of two, and a new hire needs to know what "normal" looks like without reading through scattered scripts on each host, the case for a centralized console with templated policy and a real notification pipeline gets much stronger. That's the point at which the up-front cost of standing up Cloud Control starts paying for itself, not because the PL/SQL approach stopped working, but because keeping it consistent across many hosts by hand becomes its own maintenance burden. Recognizing which side of that line your own environment sits on is really the core judgment call this lesson is meant to support.

Feature	Enterprise Manager	OCI Database Management / Events	PL/SQL API
Custom thresholds	Yes	Yes	Yes (DBMS_SERVER_ALERT)
Automatic corrective action	Yes	Via Functions	Yes, via scripts
Email notification	Yes	Yes	Yes
SNMP or webhooks	Yes	Limited	No
Visual dashboard	Yes	Yes	No

The practical guidance: for one or a few databases with simple thresholds or scripts, skipping Cloud Control entirely is reasonable. For many targets, custom alert text, automated remediation, and routing into Slack or a ticketing system, Enterprise Manager 24ai is the right tool, not because the database requires it, but because that's the problem it's actually built to solve.