Oracle Enterprise Manager and the Management Agent: Module Summary

This module set out to answer a question that sounds simple and isn't quite: which agent does Oracle AI Database 26ai actually use, and how do you work with it? The honest answer took ten lessons, because the real work wasn't just naming the current tool, it was untangling decades of terminology, correcting a few genuinely stale specifics along the way, and repeatedly drawing a line between things that share a word but aren't the same product. This closing lesson pulls those ten lessons back together.

The monitoring agent's own lineage is straightforward once laid out in order: the Oracle Intelligent Agent, SNMP-based, running from Oracle 7 through 9i, gave way to the Enterprise Manager 10g Agent, which moved to HTTPS and the Oracle Management Service model that's still the foundation today. That line continued, largely unbroken in concept, into the Oracle Management Agent that runs under Enterprise Manager 24ai now, current at Management Agent 24.1.x, deployable as a local agent, a Central Agent on the first OMS host, or, new with EM 24ai, a Remote Agent that monitors a target with no local agent installed at all.

The distinction worth holding onto throughout this whole module, because the terminology invites confusion every time it comes up: the Oracle Management Agent is host and database monitoring software, part of Enterprise Manager. It has nothing to do with 26ai's newer Select AI Agent framework or Private Agent Factory, in-database AI/agentic tooling for building and running AI agents against your data. Two unrelated products, sharing one word. Lesson 7 made this distinction load-bearing in a very concrete way: starting or stopping a Management Agent means emctl start agent or the console's Control page; enabling or disabling a Select AI Agent means the entirely separate DBMS_CLOUD_AI_AGENT.ENABLE_AGENT and DISABLE_AGENT calls, confirmed exactly against Oracle's own 26ai documentation. Neither replaced the other, because they were never solving the same problem.

Since both releases remain active and supported, Lesson 1 worked out the actual comparison rather than assuming one had simply replaced the other. Oracle splits releases into Long Term Support and Innovation tracks: 19c is LTS through December 2029 (Extended through 2032), 26ai is the current LTS through December 2031, and 21c, an Innovation release, has no Extended Support at all. 23c and 23ai aren't a separate ongoing option, applying the October 2025 release update is what turns a 23ai database into 26ai. For monitoring purposes specifically, both 19c and 26ai targets are managed identically, through the same Management Agent and EM 24ai's Database plug-in; the agent architecture doesn't change based on which LTS release you're running.

Lesson 2 organized EM 24ai's capabilities around four themes worth keeping as a map: platform modernization (a multi-container architecture replacing the old monolithic OMS, Remote Agents, and a fully web-based JET UI with no dependency on Flash or Java applets, unsupported in any browser since 2021), operational continuity (zero-downtime monitoring, jobs, and patching, so maintaining EM itself doesn't create a monitoring blackout), AI-driven insight (the Oracle AI Database Assistant, current name for what shipped as "Ask EM" in earlier release updates, plus AI Cloud Extensions for SQL Insights and capacity planning, plus a built-in MCP server as of Release Update 12), and fleet-scale performance and automation, everything from AWR Explorer and True Cache monitoring to the separately-licensed Exadata and ZDLRA Management Packs.

Put together, the shape of the product is clearer than any one feature: platform modernization exists so monitoring doesn't become a single point of failure, operational continuity exists so patching EM doesn't cost you visibility, AI-driven insight surfaces what a human would otherwise dig for, and fleet-scale capability exists because managing one database and managing a thousand are genuinely different problems. Two of the AI-driven specifics are worth remembering precisely rather than just generally: SQL Insights analyzes roughly the top 2,000 SQL statements per database, collected every 30 minutes, and capacity planning draws on up to 25 months of historical data to forecast CPU, I/O, storage, and memory before over- or under-allocation becomes a real problem. Both numbers were confirmed directly against Oracle's own announcement rather than assumed.

Lesson 3 traced what actually replaced the classic OEM Console's four panes, Navigator, Map, Job, and Event, once that Java-based thick client interface was retired: Targets and navigation (the Navigator's successor, not a schema tool, with no drag-and-drop icons left to drag), the Job System (still backed by DBMS_SCHEDULER in the database, unified with EM's own jobs in Scheduler Central), Groups, Systems, and topology (no Map window, but saved collections along any operational criterion you choose), and Incident Manager (metric settings and incident rules replacing hand-built "event sets"). The lesson's own worked example, a tablespace crossing 90%, threshold fires, incident opens, notification and an optional corrective action run, the job executes and reports back, showed these aren't four separate tools so much as four stages of one connected workflow, which the old console handled as four disconnected screens instead.

Lesson 4 made a point worth restating plainly: a step-by-step "migrate from Intelligent Agent to Management Agent" procedure isn't a live scenario in 2026. The Intelligent Agent has been unsupported for over two decades; anything still running it would need many major database upgrades before a modern Management Agent became relevant at all. What's actually durable is the architectural shift itself, not a procedure, monitoring moved from decentralized, hand-written Tcl event scripts to a centralized model where thresholds and rules live in Enterprise Manager and custom checks arrive through metric extensions. The one number worth carrying forward if you're planning a real upgrade: EM 24ai requires a minimum database version of 19.22 for its Management Repository, not the vague "at least 10g" older material sometimes cites.

Lesson 5 worked out something that looked, at first, like it might contradict Lesson 1's own findings: two different port numbers, both correct, because they cover two different directions of the same relationship. Port 3872, confirmed as the agent's own listening port, registered with IANA for oem-agent, is what the OMS uses to reach the agent, dispatching a job, for instance. Port 4903 is the OMS's upload port, what the agent connects to when pushing metrics and results upward. Both need to stay open through any firewall between them, or you end up with a monitoring setup that looks connected but only half-works. The lesson's own round-trip example, a tablespace metric pushed out through 4903, an incident raised, a corrective job dispatched back in through 3872, executed, and reported back out through 4903 again, is the cleanest illustration of why both directions matter.

Lessons 6 and 8 covered the actual mechanics: deployment through the Cloud Control wizard or silent installation, RAC-specific considerations including a consistent ORACLE_HOME and shared-home isolation between nodes, and configuration either through the console's Agent Properties page or directly via emd.properties and emctl on the host. One specific, confirmed gotcha is worth repeating on its own: editing the agent's agentTZRegion time zone setting by hand in the file, rather than running emctl resetTZ agent, is the single most common cause of an agent that starts, then gets shut down by the OMS shortly after, confirmed word for word against Oracle's own current troubleshooting documentation. At any real scale, editing agent properties host by host stops making sense too; the console's bulk-edit path, selecting many agents under Setup, then Manage Enterprise Manager, then Agents, exists specifically because inconsistent settings across an estate's agents are a common, hard-to-trace source of "why does this one host behave differently" investigations later.

Equally worth remembering: Oracle Cloud Infrastructure has its own, entirely separate product also called "Management Agent," configured through a response file with an install key rather than an OMS URL and a wallet. If a piece of documentation talks about install keys and gateways instead of the OMS and emctl, it's the wrong product for what this module covers.

Lessons 9 and 10 closed the module by establishing that Enterprise Manager, however capable, isn't the only path to real alerting. For a handful of databases with straightforward thresholds, DBMS_SERVER_ALERT, DBMS_ALERT, and, for Autonomous specifically, DBMS_CLOUD_NOTIFICATION and the Autonomous Health Framework cover genuine ground without standing up Cloud Control at all. What tends to force the move to EM isn't that the lighter approach stops working, it's scale: once a dozen databases replace two, keeping monitoring policy consistent by hand across every host becomes its own maintenance burden, and that's the point at which EM's templated, centralized approach starts paying for itself.

Lesson 10 catalogued what EM 24ai actually watches once you do use it, confirmed in unusual detail against Oracle's own current Metric Reference Manual, right down to a near word-for-word match on which database versions a given metric covers. The event types (Target Availability, Metric Alert, High Availability, and the rest), the metric groups (space, performance, wait bottlenecks, Data Guard, and now True Cache), and, just as importantly, the exceptions that never stopped mattering regardless of which mechanism enforces them: a read-only tablespace legitimately sitting at 100%, rollback structures routinely hitting extent limits, a NOARCHIVELOG database with no archive destination to monitor at all. That judgment didn't disappear when Tcl did; it just moved into metric-level exclusions and target properties instead of hand-coded conditionals.

Step back, and the throughline across all ten lessons is really one idea seen from several angles: the job Oracle Enterprise Manager does, watching an estate and turning what it collects into events a DBA can act on, hasn't changed in essence since the Intelligent Agent era. What changed is everything about how that job gets done: SNMP gave way to HTTPS, decentralized Tcl scripts gave way to centralized policy, a four-pane desktop client gave way to a web console built around Targets, Jobs, Groups, and Incidents, and a growing share of the routine diagnostic work now happens automatically, with AI-driven insight surfacing what used to require manual digging. The DBA's role moved with it: less time writing and maintaining monitoring logic by hand, more time setting the policy that logic runs under, and stepping in for exactly the exceptions no policy can fully anticipate. That's the actual shape of configuration management this module was built to teach, not a single tool, but the judgment to know which current tool, and which current fact, actually applies.

Before moving on to the next module, take a quiz to confirm your understanding of OEM.
Oracle Enterprise Manager - Quiz