Monitor Oracle AI Database 26ai with Enterprise Manager 24ai

With notification delivery configured, the next task is deciding which database conditions require attention. Oracle Enterprise Manager 24ai collects information from supported targets, detects relevant changes, and applies configured rules to help administrators respond. This lesson uses database availability and tablespace capacity to explain that workflow for supported Oracle AI Database 26ai environments.

Monitoring produces events. Incident rules evaluate those events and can create incidents, notify administrators, or initiate other configured actions. A metric alert is already a type of event; an incident rule does not convert an ordinary measurement into that alert.

Not every metric has an alert threshold, not every event becomes an incident, and not every incident sends email. Effective monitoring requires checking each stage.

1. Verify the Targets and Collection Health

Begin with the target inventory established earlier in this module. Confirm that the intended database, host, listener, and applicable container database (CDB) and pluggable database (PDB) targets are present. Check their identities carefully, especially where development and production names are similar.

A PDB is not a separate database instance. A CDB showing an Up status does not establish that every PDB or application service is usable. For Oracle RAC or service-specific availability, review the corresponding targets and relationships rather than relying on one instance's status.

Before changing alert settings, examine:

• The database target's current availability and monitoring configuration.
• The Management Agent's communication and recent uploads.
• The last collection times for the metrics you intend to use.
• Monitoring credential validation and any collection errors.
• The supported combination of OMS, agent, plug-in, database, and host-platform versions.

Stale data, an unreachable agent, and a detected database-down condition require different investigations. A responsive Enterprise Manager console does not prove that collection is healthy. Use independent service or application checks when necessary to establish the impact on users.

Work through an individually assigned administrator with appropriate target privileges. Monitoring credentials differ from the preferred host credentials used to execute jobs. Check the applicable licensing guide before using management-pack features; a visible menu does not establish entitlement.

2. Choose Useful Metrics and Understand Their Definitions

For the selected database target, open its Monitoring > Metric and Collection Settings area, as exposed by the installed target type and plug-in. Review the metric help before editing settings. Confirm its units, comparison direction, key columns, collection schedule, and alert behavior.

A useful alert describes a condition someone can assess and act on. For example, a tablespace capacity alert should identify the affected database or container and tablespace. Its response procedure should explain how to assess growth and available storage.

Do not interpret every utilization percentage as used space divided by currently allocated space. The selected metric can account for maximum size or autoextend behavior. Read its definition and compare the reported value with the configuration being monitored.

Percentage and remaining capacity answer different questions. A large tablespace with substantial free space may need a different response from a smaller, rapidly growing tablespace with a similar percentage. File maximum sizes, autoextend settings, and backing storage can constrain growth even when an apparently reassuring value is displayed.

3. Configure Warning and Critical Thresholds

Use a controlled sequence for the tablespace example:

1. Identify the correct target, container scope, and tablespace key.
2. Review recent values and the expected growth pattern.
3. Choose warning and critical levels that leave time for investigation and an approved response.
4. Review any supported consecutive-occurrence or duration settings.
5. Save, then inspect the effective settings and subsequent collections.

For illustration, an increasing-utilization metric might have a warning threshold of 80 percent and a critical threshold of 90 percent. These values demonstrate severity ordering; they are not stated Oracle defaults or universal recommendations. Use the metric's comparison operator and your workload requirements to determine actual settings.

Evaluate whether a brief crossing should create an alert or whether the supported configuration should require persistence. Also consider detection delay: collection, evaluation, processing, and notification delivery take time. Saving a threshold does not promise an immediate email, and selecting the shortest possible polling interval for every metric can add unnecessary collection work.

Record why a threshold was chosen, who should respond, and what evidence that person should examine. This makes future tuning more useful than simply raising a threshold whenever messages become inconvenient.

4. Reuse Settings with Monitoring Templates

A monitoring template packages monitoring settings for application to compatible targets. It helps establish consistent collection and threshold choices across a group of databases without reentering every setting individually.

Select or create an appropriate template, review its included settings, and apply it first to a small test scope. Inspect the resulting target configuration before extending its use. Production and development environments may need different profiles because their workloads and response requirements differ.

A template is not an incident rule set or an SMTP configuration. Also, editing a standalone template does not necessarily update every target to which it was previously applied. Explicit application and automated template mechanisms have different behavior.

Document any centrally managed settings. If a manual threshold change later disappears, investigate template application or another configuration process before assuming that the console failed to save it.

5. Monitor Database Availability

The original question, whether a database has stopped or become available again, is addressed through availability monitoring and event handling. Verify the target's monitoring configuration and use availability-event criteria appropriate to that target. An availability event does not require inventing a numeric capacity threshold.

Investigate a reported loss of availability by comparing the database, host, listener, agent, and relevant service state. A listener problem can prevent new connections while the database instance continues running. An agent communication failure can leave Enterprise Manager without current observations. These situations should not automatically be described as a database shutdown.

Availability monitoring is also not a complete audit of every startup or shutdown command. Detection depends on the monitoring mechanism, collection timing, and event semantics. Brief transitions may require additional evidence from the database and operating-system logs.

When service returns, verify fresh observations and the applicable event-clear or recovery behavior. Configure recovery notifications where supported and useful. A recovery message reports a monitored change; it does not mean that a scheduled job performed the recovery or that every application connection has been tested.

6. Route Events Through Incident Rules

Open Setup > Incidents > Incident Rules. Review existing rules before adding another, since overlapping rules can produce duplicate notifications or unexpected actions.

1. Select or create a rule set with the intended target or group scope.
2. Choose the relevant event class and matching conditions.
3. Define the required actions, such as creating an incident or notifying the responsible administrator.
4. Review supported ownership or priority settings where appropriate.
5. Check recipients, enabled state, and rule-processing behavior, then save.

The availability example uses availability events; the tablespace example uses metric alerts. Keep their conditions and responses understandable instead of applying every action to every event. Creating an incident and sending a notification are separately configured actions.

Use the email transport, recipient settings, schedules, and time-zone checks from Lesson 4. If repeated notifications or escalation are needed, define a purposeful policy rather than sending a message for every collection. Confirm which recovery or clearing transitions should also notify the team.

Corrective actions are optional automation with their own authorization and execution requirements. Establish reliable detection and an appropriate human response before considering automated restarts or storage changes. This monitoring setup does not require enabling those actions.

7. Investigate Incidents and Confirm Resolution

Use Incident Manager to inspect the source target, timestamps, severity, event details, and related conditions. Assign responsibility and record investigation steps where appropriate. Acknowledging an incident indicates that someone has taken responsibility; it does not repair the underlying condition.

For a capacity incident, assess the growth pattern, file limits, and available storage before choosing an approved remedy. For availability, establish which component failed and whether applications are affected. Related events can help identify a common cause, such as a host problem producing several apparent target failures.

After corrective work, check newly collected data and the expected event-clearing behavior. Some event types allow manual clearing and others do not. Use the operations supported for that type, and avoid treating a cleared display as evidence that the original problem was fixed.

Record the cause and outcome so the next similar incident can be handled with better evidence.

8. Test the Complete Monitoring Path

Validate four checkpoints: fresh data, a detected test condition, the expected rule action, and delivery to the intended recipient. A successful mail-server test verifies only part of this sequence.

Use a nonproduction target and an approved reversible test. If adjusting a laboratory threshold temporarily, record its original value, wait for actual collection and evaluation, observe the resulting event, and inspect the matching action. Restore the setting and verify subsequent recovery behavior.

Oracle also documents an event-rule simulation capability for evaluating rule actions without performing them. Use the interface supported by your installed release. Simulation does not prove that collection works, an incident was actually created, or an email reached a mailbox.

Record target identity, settings, timestamps, event details, and observed results. Do not fill a production tablespace or stop a production database for a demonstration. When a result is missing, follow the sequence to find the first unsuccessful checkpoint instead of changing unrelated settings.

For example, fresh capacity data and a generated alert show that collection and evaluation worked. If no notification follows, the next checks are rule matching, action configuration, recipient eligibility, and delivery. Reconfiguring the agent at that point would not address the evidence already collected.

9. Plan Maintenance with the Appropriate Blackout

Planned maintenance can produce expected changes that should be handled differently from unexpected outages. A monitoring blackout suspends relevant monitoring activity; a notification blackout suppresses notifications while monitoring continues. Choose the mechanism that fits the maintenance and reporting requirements.

Review the selected targets, duration, and maintenance-window options. Related targets and jobs can have behavior that depends on the chosen configuration, so do not assume every operation is treated identically. Specify an end time and verify normal collection and notification behavior when the work finishes.

Do not permanently disable a metric to silence a temporary maintenance condition. Also, do not assume every message suppressed during a notification blackout will later be replayed. Review the supported behavior and examine the target's state after the maintenance window.

Troubleshoot from Collection to Delivery

Preserve the relevant error details and timestamps. Make a targeted correction, then repeat the check at that stage. This provides a clearer explanation than changing thresholds, credentials, and email settings simultaneously.

Keep the Monitoring Configuration Useful

Before handing over the configuration, confirm that:

• The intended targets and container scope are monitored with fresh data.
• Thresholds have documented reasons and leave an appropriate response interval.
• Template application and local exceptions are understood.
• Events reach the intended rules and responsible administrators.
• Detection, notification, and recovery behavior have been tested.
• Maintenance suppression ends as planned and changes are documented.

Review these decisions as workloads and ownership change. Monitoring is most useful when each important condition has a clear interpretation and a practical response.

Oracle Documentation

• Event Management
• Rule Actions and Simulation
• Using Monitoring Templates
• Database Instance Metric Reference
• Working with Incidents
• Blackouts and Notification Blackouts

The next lesson brings together the module's browser access, credentials, notifications, and database monitoring workflow.