OEM 24ai Remote Agents: Stop Deploying an Agent on Every Host You Monitor

This Oracle observability post is about the agent layer itself: why your agent fleet is probably your biggest hidden maintenance burden, and what EM 24ai's Remote Agent does about it.

Ask any DBA running OEM at scale what eats their patching cycles, and agent lifecycle management is near the top of the list. Every host you monitor needs an agent installed, configured, secured, and kept current. Multiply that by a few hundred database hosts across on-prem and cloud, and "patch the agents" becomes its own quarterly project — separate from the database patching you actually care about.

That's the problem OEM 24ai's Remote Agent was built to solve. Instead of an agent on every target host, you deploy a small number of dedicated Remote Agents that monitor databases and hosts remotely, over SSH and standard remote protocols. No agent footprint on the target itself.

If you've upgraded to EM 24ai and haven't looked at Remote Agent yet, this is worth twenty minutes of your time — especially if agent count, not database count, is what's driving your maintenance windows.

What a Remote Agent Actually Is

A Remote Agent is a distinct agent type introduced in EM 24ai. It runs on a dedicated host — not a target host — and uses remote protocols plus SSH to monitor and manage databases and hosts elsewhere on the network. One Remote Agent can cover many targets, which is the entire point.

A few architectural facts worth knowing before you plan a deployment:

• The Remote Agent host must be dedicated — no databases or applications running on it.

• It currently supports Linux x86-64 only, and the Remote Agent and the target host must run the same OS platform. Additional platforms are planned in future release updates.

• Supported Oracle Database versions are 19c and above, including 23ai.

• Engineered Systems targets (Exadata) are explicitly not supported with Remote Agents — those still need a local agent.

• Sizing isn't something to eyeball. Oracle has published a dedicated MOS note for Remote Agent hardware requirements (Doc ID 3076694.1) — pull the actual numbers before you size the host, don't guess.

The Setup Flow

Deployment is three steps: deploy the Remote Agent, register the remote hosts against it, then discover targets exactly as you would with a local agent.

Step 1 — Deploy the Remote Agent. This uses the same agent push or silent-install mechanisms you already know, just with a configuration flag that marks it as a Remote Agent rather than a standard local agent. OMS needs SSH access to the Remote Agent host to push the software and run configuration.

Step 2 — Add remote host targets. From the console: Setup → Add Target → Add Targets Manually → Remote Agent tab → Add Host Targets to Remote Agent. You'll supply two separate credential sets — a Host Monitoring Credential for routine metric collection (no root needed) and a Host Admin Credential for cache maintenance operations that require privilege escalation via sudo. You'll also see the Remote Agent's current resource utilization before committing more hosts to it, which is a nice guardrail against overloading one Remote Agent with too large a fleet.

Step 3 — Discover and monitor. Once the hosts are registered, database discovery works exactly like the local-agent workflow — auto-discovery, guided discovery, manual discovery, or EM CLI. Nothing changes downstream: monitoring templates, incident rules, blackouts, all of it applies the same way regardless of whether the agent watching the target is local or remote.

Note: EM CLI syntax below is representative. Exact parameter names vary by OEM version and job type. Always validate against your environment: emcli help <verb> and Oracle's official EM CLI reference.

# Discover a database target through an already-registered remote host
# — the discovery command itself doesn't change; the host is already
# marked as remotely-monitored before this step runs
emcli discover_db \
  -host="dbhost03.example.com" \
  -sys_password="<password>" \
  -db_name="PRODDB" \
  -oracle_home="/u01/app/oracle/product/19.0.0/dbhome_1"

Local Agent vs. Remote Agent, Side by Side

Before you plan a pilot, it helps to see the trade-off in one place:

Read that table as "which tool for which job," not "which tool wins." Most estates will run both side by side for years.

A Worked Example

Say you're standing up twelve new Oracle Database 23ai instances across two availability domains for a new application — six hosts per domain, no RAC, no Data Guard yet. Under the old model, that's twelve agents to install, secure, and patch going forward. Under the Remote Agent model, you deploy one dedicated Remote Agent per availability domain, register the six hosts in each domain against its local Remote Agent, and discover all twelve databases through the standard workflow. You've gone from twelve agent lifecycles to two. When Oracle ships an RU with a CVE fix for the agent stack, you're patching two hosts instead of twelve — and neither of those two hosts is a production database server, so the patching window doesn't compete with your database maintenance windows at all.

That's the actual return on this feature: it's not just fewer agents, it's fewer things touching your production database hosts in the first place.

Placing Remote Agents Around RAC and Data Guard

This is the part that trips people up, and Oracle's own documentation is explicit about it: proximity matters.

For a clustered database, add every node of the cluster to the same Remote Agent, then discover the cluster database as a whole. A two-node RAC gets both hosts registered to one Remote Agent before you run discovery — not one Remote Agent per node.

For Data Guard, do the opposite. If your primary and standby databases sit in different datacenters, don't try to cover both from a single Remote Agent in one location. Use a Remote Agent local to the primary's datacenter and a separate Remote Agent local to the standby's datacenter. The logic is straightforward: a Remote Agent talking to targets over a WAN link introduces latency and a new failure domain into your monitoring path, and if that link degrades, you don't want your standby's monitoring to go dark along with it.

Practically, this means your Remote Agent topology should mirror your database topology's failure domains — one Remote Agent (or a small pool) per datacenter or availability domain, not one Remote Agent trying to reach across your whole estate.

What Remote Agent Doesn't Do Yet

Be honest with your team about the current limitations before you sell this internally as a full agent-sprawl fix:

• No migration path for existing targets. If a database is already monitored by a local agent, you can't convert it to remote monitoring today. Remote Agent currently only covers newly discovered targets. Oracle has said migration tooling is planned for a future release — it isn't here yet.

• Linux x86-64 only, on both the Remote Agent host and the target host, with the same OS platform required on both sides.

• No Engineered Systems. Exadata stays on local agents regardless of how much you'd like to consolidate.

• One dedicated host per Remote Agent deployment. You're not saving hardware by co-locating it with a monitored target — that defeats the design.

None of this makes Remote Agent a bad investment. It makes it the right tool for new deployments and new target onboarding right now, and a phased migration candidate once Oracle ships the conversion capability for existing local-agent targets.

What Good Looks Like

A well-planned Remote Agent rollout looks like this: one Remote Agent pool per datacenter or availability domain, sized against Oracle's published hardware guidance rather than guesswork, with RAC nodes grouped onto a single Remote Agent per cluster and Data Guard pairs split across Remote Agents that match their physical topology. New database provisioning defaults to remote monitoring from day one, while existing local-agent targets stay put until Oracle ships migration tooling — no forced rip-and-replace. Credentials are scoped correctly: a low-privilege monitoring credential doing the routine polling, and the sudo-capable admin credential reserved strictly for cache maintenance operations, not handed out more broadly than it needs to be.

What it doesn't look like: one Remote Agent trying to cover three datacenters because it seemed simpler to stand up, or a team quietly forgetting that Exadata targets still need their local agent and finding that out during an outage.

The Bottom Line

Remote Agent is EM 24ai's answer to a problem every large Oracle shop has quietly lived with for years: an agent fleet that's grown larger than the database fleet it's supposed to be watching, and patching cycles that spend more time on the monitoring tool than the thing being monitored. It's not a wholesale replacement for local agents yet — Engineered Systems and existing monitored targets aren't in scope — but for new database onboarding, it's a real reduction in footprint and lifecycle overhead, and the RAC/Data Guard placement guidance from Oracle is specific enough to plan around today.

If your agent count has been climbing faster than your database count, this is the release feature to pilot next.