| Lesson 4 | Overview of Oracle agents |
| Objective | Explain how Oracle agents work on remote servers. |
Overview of Oracle Agents
Oracle Intelligent Agent (OIA) was officially sunset and replaced by the Oracle Management Agent (OMA)[1] starting with Oracle Enterprise Manager 10g.
- Oracle 9i and earlier: used Oracle Intelligent Agent for remote monitoring and job execution, communicating over SNMP, with configuration that was manual and dependent on local OS services and Tcl-based event scripts.
- Oracle 10g (circa 2003-2004): introduced Oracle Management Agent as part of the Enterprise Manager Grid Control architecture, more scalable, secure, and flexible than the OIA model, communicating over HTTPS instead of SNMP. OIA was deprecated in this same release.
- Oracle 11g and beyond: the Intelligent Agent is no longer supported at all; every current Enterprise Manager capability requires the Management Agent.
| Feature | Oracle Intelligent Agent (OIA) | Oracle Management Agent (OMA) |
|---|---|---|
| Introduced in | Oracle 7/8/9 | Oracle 10g |
| Communication | SNMP-based | HTTPS (secure, encrypted) |
| Architecture | Standalone agents | Part of the Grid Control/Cloud Control framework |
| Scripting | Tcl-based events | Plug-ins and metric extensions |
| Status | Deprecated after 9i | Actively supported and evolved, current at Enterprise Manager 24ai |
Why This Isn't a Live Upgrade Path Today
Older material sometimes frames moving from Intelligent Agent to Management Agent as a step-by-step migration you'd actually perform, stop the legacy agent, install the new one, rediscover targets, recreate monitoring by hand. Worth being direct about this: that's not a realistic scenario in 2026. OIA has been unsupported for over two decades, and any environment still running it would be many major database versions behind long before a modern Management Agent became relevant at all, there's no direct hop from a 9i-era Intelligent Agent to an Enterprise Manager 24ai Management Agent that skips everything in between.
What's actually durable from that transition is the architectural shift itself, not a procedure: monitoring moved from decentralized, script-based configuration tied to whatever Tcl events an administrator hand-wrote, to a centralized model where thresholds and rules live in Enterprise Manager itself, and custom checks are added through metric extensions rather than custom scripting bolted onto the agent. If you're planning an actual current upgrade, the number that matters is Oracle's own current one: Enterprise Manager 24ai requires a minimum database version of 19.22 for its Management Repository, not merely "at least 10g." Check the Enterprise Manager Certification Matrix on My Oracle Support for exact target and repository database requirements before planning any real upgrade.
Made concrete, the shift looks like this: under the old model, checking whether a tablespace was running low on space meant an administrator writing a Tcl script that queried the database directly, scheduling it through the Intelligent Agent's own local event mechanism, and hand-coding what should happen if the check failed, usually little more than a log entry or a page. The same check today is a metric setting defined once against the target (or a whole group of targets at once), evaluated by the agent locally exactly as before, but the response, who gets notified, whether it becomes an incident, whether a corrective action fires automatically, is configured centrally in Enterprise Manager rather than baked into a script sitting on one server. The detection still happens locally; what moved is everything downstream of detection.
What's actually durable from that transition is the architectural shift itself, not a procedure: monitoring moved from decentralized, script-based configuration tied to whatever Tcl events an administrator hand-wrote, to a centralized model where thresholds and rules live in Enterprise Manager itself, and custom checks are added through metric extensions rather than custom scripting bolted onto the agent. If you're planning an actual current upgrade, the number that matters is Oracle's own current one: Enterprise Manager 24ai requires a minimum database version of 19.22 for its Management Repository, not merely "at least 10g." Check the Enterprise Manager Certification Matrix on My Oracle Support for exact target and repository database requirements before planning any real upgrade.
Made concrete, the shift looks like this: under the old model, checking whether a tablespace was running low on space meant an administrator writing a Tcl script that queried the database directly, scheduling it through the Intelligent Agent's own local event mechanism, and hand-coding what should happen if the check failed, usually little more than a log entry or a page. The same check today is a metric setting defined once against the target (or a whole group of targets at once), evaluated by the agent locally exactly as before, but the response, who gets notified, whether it becomes an incident, whether a corrective action fires automatically, is configured centrally in Enterprise Manager rather than baked into a script sitting on one server. The detection still happens locally; what moved is everything downstream of detection.
Oracle Enterprise Manager 24ai Centralizes DBA Monitoring for Oracle AI Database 26ai
The Oracle Enterprise Manager 24ai console centralizes DBA monitoring and lets you attach pre-defined corrective actions to events. The work still runs at the target through the Oracle Management Agent on the remote host, so detection and remediation stay local to the server. That remains an important point: a lost network connection between the console and the estate shouldn't stop monitoring or an already-triggered corrective job.
You no longer design "event sets" in the old OEM Event Manager. In EM 24ai you create metric settings and incident rules. Events are the detected conditions, metric thresholds, availability, job status, and similar. Incident Manager is where those events become incidents you can notify, compress, ticket, and optionally auto-fix.
Default availability monitoring on a typical host still covers three layers, now as events and badges rather than map icons: the host or server itself, each Oracle AI Database 26ai instance running on that host, and the Oracle Management Agent that collects and runs local work. Graphical badges and incident lists on target, group, and system pages replace drawing the event on the old OEM map, but the underlying pattern is unchanged from the classic Event Manager plus fixit-job model: detect, notify, optionally run a job to remediate.
That local-detection design is worth returning to once more, since it's easy to read past as a footnote rather than the actual point: a corrective action attached to a tablespace threshold doesn't wait for a round trip to the OMS to fire, the agent detects the breach and can execute the remediation job on the spot, then reports what happened once connectivity allows. For an estate spread across sites with less-than-perfect WAN reliability, that's the difference between a real incident response system and one that quietly stops working the moment a link between the console and a remote data center drops.
The next lesson looks at how Oracle Management Agents communicate with the Oracle Management Service and Incident Manager.
You no longer design "event sets" in the old OEM Event Manager. In EM 24ai you create metric settings and incident rules. Events are the detected conditions, metric thresholds, availability, job status, and similar. Incident Manager is where those events become incidents you can notify, compress, ticket, and optionally auto-fix.
- Creating customized monitoring in Incident Manager. Custom monitoring no longer depends on writing Tcl, OraTcl, or Agent API scripts in the console. Define thresholds and collection settings on the target or group, then use incident rules to control notification, event compression, and corrective actions. If you need a check that isn't in the shipped metrics, use a metric extension, SQL, OS, or another supported adapter, applied to databases, hosts, listeners, groups, or systems. Licensed packs still add ready-made performance, configuration, and security monitoring, launched from the target homepage context rather than dropped in as scripts.
- Availability, system events, and database notifications. Availability events replace the old default up/down checks: host up/down, database up/down, listener up/down, and agent status. Separately from EM metrics, Oracle AI Database 26ai still supports database-level event tracking, LOGON and SHUTDOWN, for example, through triggers and event attribute functions, which can deliver asynchronous messages to an application directly. EM 24ai watches the instance as a managed target on top of that and can raise incidents when availability or thresholds breach.
Default availability monitoring on a typical host still covers three layers, now as events and badges rather than map icons: the host or server itself, each Oracle AI Database 26ai instance running on that host, and the Oracle Management Agent that collects and runs local work. Graphical badges and incident lists on target, group, and system pages replace drawing the event on the old OEM map, but the underlying pattern is unchanged from the classic Event Manager plus fixit-job model: detect, notify, optionally run a job to remediate.
That local-detection design is worth returning to once more, since it's easy to read past as a footnote rather than the actual point: a corrective action attached to a tablespace threshold doesn't wait for a round trip to the OMS to fire, the agent detects the breach and can execute the remediation job on the spot, then reports what happened once connectivity allows. For an estate spread across sites with less-than-perfect WAN reliability, that's the difference between a real incident response system and one that quietly stops working the moment a link between the console and a remote data center drops.
The next lesson looks at how Oracle Management Agents communicate with the Oracle Management Service and Incident Manager.
[1] Oracle Management Agent (OMA): in Oracle Enterprise Manager 24ai, the Oracle Management Agent is the component deployed on managed hosts. It discovers and monitors Oracle AI Database 26ai instances and other targets, forwards metric and availability data to the Oracle Management Service, and executes jobs and corrective actions locally. That local execution is what keeps monitoring and remediation running if the console session or WAN path is interrupted. OMA remains essential on 26ai estates for performance monitoring, job scheduling, configuration collection, and incident-driven automation.