Customizing Oracle Alerts

"Database events" in the Enterprise Manager console aren't a single list of ORA- errors. They're Enterprise Manager events raised against Database Instance, Cluster Database, PDB, Listener, ASM, and Data Guard targets, and 26ai is explicitly covered: where the Metric Reference Manual says a metric applies to "all versions," that means 19c, 21c, 23ai, and 26ai alike under EM 24ai.

These are the event classes available when building an incident rule:

Event type	What it means for a 26ai database
Target Availability	Database, instance, listener, or PDB up, down, agent unreachable, or a blackout in effect
Metric Alert	A threshold crossed on a collected metric, tablespace full, session limit, wait bottlenecks, and similar
Metric Evaluation Error	The agent couldn't collect a metric group at all
High Availability	Startup, shutdown, backups, Data Guard switchover or failover, and other HA state changes
Job Status Change	An EM job against the database, backup, SQL, corrective action, changed state
Compliance Standard Rule / Score Violation	A security or configuration standard failed on the target
Target Monitoring Disruption	The agent can't monitor normally, hung collections, resource pressure
Blackout Infrastructure Alert	A blackout start, stop, or edit itself failed
User-reported	Manually created events

Severity runs from Fatal (availability events only) through Critical, Warning, Advisory, Clear, and Informational.

Enterprise Manager ships several hundred database metrics, documented in full in the Oracle Enterprise Manager Oracle Database Metric Reference Manual, 24ai Release 1. For a typical 26ai Database Instance, the categories worth knowing:

• Availability and response: instance up or down, overall status
• Alert log: generic errors, archiver errors, media failure, block corruption, session terminated, best tracked with the dedicated Alert Log metrics rather than log scraping
• Space: tablespace used percentage, datafile and archive/recovery area usage
• Database limits: session, process, lock, open cursor, and user limit usage
• Performance and load: average active sessions, CPU, I/O, physical reads and writes, throughput
• Wait bottlenecks: active sessions waiting on I/O or other categories, top wait events
• Efficiency: buffer cache hit ratio, sorts in memory, SQL response time, though worth a caveat below
• Concurrency: blocking sessions, user locks
• Jobs: Scheduler elapsed time and failures, broken or failed jobs
• Data Guard: status, lag, role-change readiness
• True Cache: metrics specific to 26ai-era True Cache targets, where discovered
• Related targets worth watching alongside the database itself: Listener (refused connections, load), ASM, Cluster, and PDB

Out-of-the-box corrective actions most commonly attach to database down, listener down, and tablespace full, the three conditions where an automatic first response tends to buy the most time.

Worth a specific caveat on buffer cache hit ratio: it's still tracked, and still useful as one signal among several, but modern tuning practice doesn't treat it as a reliable standalone indicator the way older guidance sometimes did. A high ratio doesn't guarantee good performance, and a lower one isn't automatically a problem; wait-event and Active Session History-based analysis is the more trusted primary approach today. Alert on it, but don't build your whole picture of database health around a single hit-ratio number.

1. From the target's homepage, go to Monitoring, then Metric and Collection Settings, to enable or disable specific metrics and set their thresholds.
2. Go to Setup, then Incidents, then Incident Rules, to choose an event type, Metric Alert or Target Availability, for instance, and decide what happens when it fires: notify someone, create an incident, or run a corrective action.
3. For the full, current catalog of every metric and its defaults, the Oracle Enterprise Manager Oracle Database Metric Reference Manual for 24ai Release 1 is the authoritative reference.

Worth being precise about scope: these are Enterprise Manager events specifically, not OCI Events, not DBMS_ALERT, and not Advanced Queuing-based database events. Those are separate notification systems entirely, some of them covered in the previous lesson; don't assume configuring one covers the others.

Tracing a single condition through the whole system makes the pieces easier to place than reading about them separately. Take the tablespace-full example that opened this lesson.

1. Under Metric and Collection Settings on the target's homepage, the tablespace used percentage metric already has a default threshold; adjust it to whatever Warning and Critical levels fit the environment, 85 and 95 percent, for instance, and set a collection frequency.
2. When usage crosses that line, EM raises a Metric Alert event, one of the event types from the table above, at Warning or Critical severity depending on which threshold was crossed.
3. An incident rule built under Setup, then Incidents, then Incident Rules, targeting Metric Alert events on this database, decides what happens next: create an incident, notify the on-call DBA by email, and optionally attach a corrective action, extending the tablespace automatically, as a Job Status Change event once that job runs.
4. The exception logic from the previous section applies right here: if this particular tablespace is read-only, the threshold itself should exclude it, rather than relying on someone remembering to ignore the alert every time it fires.

One condition, moving through metric collection, event generation, incident rules, and an optional automated fix, all without anyone writing a line of Tcl.

No single threshold applies everywhere, and this hasn't changed regardless of what mechanism enforces it. A few exceptions worth building into your monitoring policy from the start rather than discovering the hard way:

• A read-only tablespace legitimately sitting at 100% full isn't a problem; a blanket "alert at 95%" rule needs an exception for it.
• Rollback and undo structures routinely reach extent limits as part of normal operation; that alone doesn't warrant paging anyone.
• A database running in NOARCHIVELOG mode has no archived redo log destination to monitor at all, so that whole category of alert simply doesn't apply.

In short, almost every real environment needs its monitoring policy tuned with exceptions like these. Where Tcl-based monitors once needed this logic hand-coded into each script, it's now expressed through metric-level exclusions, group-specific thresholds, and target properties in Enterprise Manager, the judgment involved hasn't gotten any less important, just easier to express and maintain centrally.

This kind of threshold-driven, semi-automated monitoring is really a continuation of a shift that started with Oracle Database 10g's introduction of the Automatic Workload Repository and the Automatic Database Diagnostic Monitor, which began evaluating database statistics on a regular cadence and surfacing potential problems before a DBA had to go looking manually. Enterprise Manager's current event and metric system is the direct descendant of that shift: a near real-time view of database conditions, an increasing share of the routine diagnostic work automated, and the DBA's attention directed toward the exceptions and judgment calls that still genuinely need it.

That's really the thread running through this entire module: an agent that watches the target, a console that turns what it collects into events worth acting on, and a DBA whose job has shifted from writing and maintaining the monitoring logic by hand to setting the policy the automation runs under, and stepping in for the exceptions no policy can fully anticipate.

The next lesson concludes this module.