OEM 24ai: Add Targets and Build Your First Dashboard

Published Aug 2026 · 6 min read

Installing Oracle Enterprise Manager is the part everyone writes about. What happens next is where most installations quietly stall: OMS is up, the console loads, and the dashboard is empty because nothing is being monitored yet. A monitoring tool that monitors nothing is just another server to patch.

This walkthrough takes you from a freshly installed OEM 24ai to a working dashboard — deploy an agent, discover targets, group them, set thresholds that will not spam you, and build a page a manager will actually read. Commands were run against OEM 24ai with a 19c target on Oracle Linux 9.

Before you deploy anything: check the ground

Almost every failed agent deployment is a prerequisite problem, not an OEM problem. Five minutes here saves an hour of log reading.

On the target host you need a supported OS, an oracle user that the OMS can reach over SSH, a directory for the agent with real free space, and the agent port open back to the OMS. Name resolution must work in both directions — forward and reverse — because the agent registers itself by hostname and a mismatch is the single most common cause of a target that deploys but never reports.

# on the TARGET host - confirm the basics before deploying
hostname -f
nslookup $(hostname -f)          # forward
nslookup <target-ip>             # reverse - must return the same name

df -h /u01/app/oracle/agent      # agent needs real space, plan ~10 GB
id oracle

# from the OMS host - can we reach the agent port?
nc -zv <target-host> 3872

# on the OMS - is the software library set up? (agent push needs it)
emcli login -username=sysman
emcli get_supported_platforms

Deploying the agent

You have two routes and they suit different situations. The push method drives everything from the console: Setup → Add Target → Add Targets Manually → Install Agent on Host. It is the fastest way to add a handful of hosts and it validates prerequisites for you.

The pull method — a silent install from an agent gold image — is what you want at scale or when the OMS cannot SSH to the target, which is common across a firewall or into a DMZ. You download the image once, copy it to the host, and install non-interactively.

# PULL method: install the agent silently on the target
./agentDeploy.sh AGENT_BASE_DIR=/u01/app/oracle/agent \
  OMS_HOST=oms.example.com EM_UPLOAD_PORT=4903 \
  AGENT_REGISTRATION_PASSWORD=<password>

# as root, once, on the target
/u01/app/oracle/agent/agent_13.5.0.0.0/root.sh

# verify from the target
./emctl status agent
./emctl upload agent          # force an upload; must report success

If emctl status agent shows the agent running but the last upload failed, you are almost always looking at a clock skew, a certificate issue or a blocked upload port. Check the agent log at $AGENT_BASE/agent_inst/sysman/log/emagent.trc before changing anything in the console.

Discovering targets — and why the defaults miss things

With an agent reporting, run discovery: Setup → Add Target → Configure Auto Discovery. OEM scans the host and finds databases, listeners, ASM instances and clusters. Then promote what it found, because discovered targets are not monitored until promoted — a step that catches people out constantly.

Two things routinely get missed. Databases that were not running during the scan will not be found, so start everything first. And monitoring credentials must be set per target: OEM needs a database login to collect metrics, and dbsnmp is the account intended for it. A target that shows a metric-collection error almost always has a locked or expired dbsnmp.

-- on each target database: the monitoring account OEM will use
ALTER USER dbsnmp ACCOUNT UNLOCK;
ALTER USER dbsnmp IDENTIFIED BY <password>;

-- check it will not expire and surprise you in 180 days
SELECT username, account_status, expiry_date, profile
FROM   dba_users WHERE username = 'DBSNMP';

-- from the OMS, script the whole thing instead of clicking
emcli add_target -name="orcl_prod" -type="oracle_database" \
  -host="db1.example.com" \
  -credentials="UserName:dbsnmp;password:<pw>;Role:Normal" \
  -properties="SID:orcl;Port:1521;OracleHome:/u01/app/oracle/product/19c"

emcli list -resource="Targets" -search="TARGET_NAME like 'orcl%'"

Groups and thresholds: the step that decides whether anyone uses OEM

An unstructured target list becomes unusable at about thirty entries. Before you build any dashboard, create groups — by environment (production, UAT, development), by application, or both. A dynamic group whose membership is driven by a target property is better than a static one, because new targets join automatically instead of being forgotten.

Then fix the thresholds. Out of the box OEM will alert on tablespace usage at a level that fires constantly on databases using autoextend, and that is how monitoring gets ignored: not because it is silent, but because it cries wolf. Set thresholds that reflect what you would actually get out of bed for, and use monitoring templates so the same standard applies to every database rather than being tuned target by target.

A practical starting point: warn on tablespace at 85% and go critical at 95% only where autoextend is off or maxsize is close; alert on the instance being down immediately; alert on a blocked-session count rather than on every long-running query. Whatever numbers you choose, apply them with a template so a new database inherits them on day one.

Building a dashboard a manager will read

The mistake is building a dashboard for yourself. You already know where to look; the dashboard exists so that someone who does not can see whether things are fine in about five seconds.

Use Enterprise → Dashboards and keep the top row to status, not detail — a target availability summary for the production group, and the count of open critical incidents. Someone should be able to glance at that row and stop reading. Below it, put the three or four metrics that predict a call: tablespace headroom, ASM diskgroup usage, active sessions, and the slowest SQL by elapsed time.

Leave capacity trends for a second page. Trends are for planning conversations, not for the screen someone checks at 9am, and mixing the two is what makes dashboards feel noisy. If you want the numbers to reach people without them logging in at all, schedule an Information Publisher report to email the group weekly — that single habit does more for OEM adoption than any dashboard layout.

What to check when a target goes to "unknown" or "pending"

Three states, three different causes, and knowing which is which saves a lot of time.

Pending means the target is registered but has not uploaded data yet — normal for a few minutes after discovery, and if it persists the agent is not uploading. Unknown means the agent stopped reporting, so check the agent first, not the database. Metric collection error means the agent is fine but cannot log in to the target, which sends you straight back to dbsnmp.

# the standard triage, in order
emctl status agent                       # is it even running?
emctl status agent scheduler | head -20  # are collections scheduled?
emctl upload agent                       # force an upload, read the error

# clear a stuck agent state
emctl clearstate agent
emctl stop agent && emctl start agent

# from the OMS side
emcli list -resource="Targets" -search="STATUS_NAME='Unknown'"
emctl status oms -details

Where teams usually stop too early

Most installations get as far as "targets are green" and stop. The value is in the next two steps: incident rules that route the right alert to the right person instead of emailing everyone, and a monitoring template applied estate-wide so every new database is monitored to the same standard without anyone remembering to configure it.

If you take one thing from this: OEM is not finished when the console opens. It is finished when someone who is not a DBA can look at one page and know whether to worry — and when a database added next month is monitored properly without you touching it.

If you would rather build this on a real environment than a slide deck, our Oracle Enterprise Manager training walks through agent deployment, discovery, incident rules and dashboards on a working estate. If you want to practise on your own machine first, the pre-built OEM Cloud Control VM lab kit gives you an OMS and repository already configured, so you can start at the interesting part. Oracle's Enterprise Manager documentation is the authoritative reference for version-specific details.