Oracle Enterprise Manager (OEM) 13c – Core Components Explained

 Oracle Enterprise Manager (OEM) 13c is Oracle’s centralized monitoring and management framework used to manage databases, hosts, middleware, applications, and enterprise infrastructure from a single console.

Understanding the core components of OEM is essential for DBAs and system administrators to effectively deploy, monitor, and troubleshoot the environment.

OMS – Oracle Management Service

The Oracle Management Service (OMS) is a web-based application that acts as the brain of the OEM architecture.

OMS orchestrates communication with the Management Agents and plug-ins to discover targets, monitor and manage them, and store the collected information in a repository for future analysis.

• Receives data from Management Agents
• Coordinates monitoring activities
• Processes alerts and incidents
• Serves data to the OEM Console
• Runs as WebLogic managed server

OMR – Oracle Management Repository

The Oracle Management Repository (OMR) is the central storage location where all monitoring data is stored.

It is a database schema that contains:

• Database jobs
• Packages and procedures
• Views and tables
• Historical performance data
• Target configuration details

OMR is typically hosted on a dedicated Oracle Database (19c recommended) for better performance and stability.

Management Agent

The Management Agent is a lightweight software component installed on every host that needs to be monitored.

It converts an unmanaged host into a managed host within the OEM ecosystem.

• Collects metrics from targets
• Executes jobs and scripts
• Communicates with OMS

Types of Management Agents

• Central Agent: Installed automatically with OMS and used to monitor the OMS host itself.
• Standalone Target Agent: Installed on remote hosts to monitor databases, applications, and servers.

Targets

Targets are the entities that can be monitored within an enterprise.

Managed targets include:

• Hosts
• Databases
• Application servers
• Applications
• Listeners

BI Publisher

Oracle BI Publisher is the primary reporting tool used in OEM.

• Highly formatted reports
• Dashboards and summaries
• Compliance and audit reports

Connectors

Connectors allow OEM to integrate with third-party tools.

They act as a mediator between OEM and external systems such as:

• BMC Remedy
• ServiceNow
• Other ticketing systems

Connectors enable automatic ticket generation from OEM incidents.

JVMD Engine

The Java Virtual Machine Diagnostics (JVMD) Engine helps diagnose performance issues in Java applications.

• Thread analysis
• Memory usage
• Garbage collection behavior

OEM Console

The OEM Console is the graphical user interface of the Enterprise Manager system.

It provides a single-pane-of-glass view for:

• Monitoring all targets
• Viewing alerts and incidents
• Analyzing performance metrics
• Managing jobs and patches

EMCLI

The Enterprise Manager Command Line Interface (EM CLI) enables automation and scripting.

emcli login -username=sysman
emcli login
emcli sync
emcli logout
emcli list_targets
emcli get_targets
emcli add_target
emcli get_supported_platforms
emcli create_job
emcli get_jobs
emcli get_blackout_details

EMCTL

EMCTL is used to control OMS and Management Agents.

emctl start oms
emctl stop oms
emctl start agent
emctl start agent
emctl stop agent
emctl stop agent
emctl status agent
emctl upload agent
emctl reload agent
emctl clearstate agent
emctl start blackout Blackout_name
emctl secure agent
emctl unsecure agent

Plug-ins

Plug-ins extend OEM capabilities to manage different technologies.

By default, OEM 13c includes:

• Oracle Database
• Oracle Fusion Middleware
• Oracle Exadata
• Oracle Cloud Framework
• Oracle System Infrastructure

Additional plug-ins can be installed as required.

Without plug-ins, OEM cannot discover or manage specific target types.

Conclusion

Oracle Enterprise Manager 13c provides a powerful and modular architecture for enterprise monitoring. Each component plays a critical role in ensuring visibility, automation, and proactive management of IT systems.

The Investigation (AWR Checklist)

 The Investigation (AWR Checklist)

==================
Before resizing anything, check Instance Efficiency and Load Profile:
Soft Parse %
If this is low, you don’t have a memory problem — you have a SQL design problem.
Execute to Parse %
Are statements being parsed almost as often as they are executed?
Parse CPU vs. Total CPU
If parsing consumes 40%+ of CPU, the application is choking the Shared Pool.

The Root Cause: Literal Chaos
==================
When applications use literals
WHERE ID = 123
instead of bind variables
WHERE ID = :b1
Oracle treats each execution as a new SQL statement.
Result: A flood of hard parses

Impact:
=======
Useful cursors get aged out
High object reloading
Increased latch and mutex contention

Pro-Level Tuning Steps
=================
+Find the Culprits
Use FORCE_MATCHING_SIGNATURE in V$SQL to group statements differing only by literals.
+Identify “Heavy” Objects
Query V$DB_OBJECT_CACHE. Frequently reloading large PL/SQL objects create serious shared pool pressure.
+The KEEP Strategy
Use DBMS_SHARED_POOL.KEEP to pin large, frequently used packages and prevent unnecessary reloads and contiguous memory allocation pressure.
+Consult the Advisor (Last Step)
After fixing SQL, check V$SHARED_POOL_ADVICE.
If parse time savings are negligible with more memory — do not increase the Shared Pool.

Technical Takeaway
==================
A larger Shared Pool does not fix bad SQL. In fact, it can lead to:
Longer LRU scans
Higher latch contention
Fix the SQL design first. Tune memory second.

Oracle Performance Views You Must Know

 V$SESSION | V$SQLAREA | V$SQL | V$SYSTEM_EVENT & More

Oracle performance tuning starts with visibility.

And visibility comes from dynamic performance views (V$ views).

If you know how to read these views, you can diagnose 80% of production issues quickly 👇

⭐ Why V$ Views Matter

V$ views show what is happening right now inside the database:

✔ Active sessions

✔ Running SQL

✔ CPU & wait events

✔ Memory usage

✔ Contention & blockers

👉 They are the foundation of performance analysis.

⭐ 1️⃣ V$SESSION — Who Is Doing What

The most-used performance view.

Use it to find:

✔ Active vs inactive sessions

✔ Waiting sessions & wait events

✔ Blocking sessions

✔ Current SQL per session

Key columns

• SID, SERIAL#

• STATUS

• EVENT, WAIT_CLASS

• BLOCKING_SESSION

• SQL_ID

👉 First place to check when users say “database is slow”.

⭐ 2️⃣ V$SQLAREA — Top SQL by Resource Usage

Shows aggregated statistics per SQL.

Use it to identify:

✔ Top CPU SQL

✔ High elapsed time SQL

✔ Frequently executed SQL

Key columns

• SQL_ID

• EXECUTIONS

• ELAPSED_TIME

• CPU_TIME

• BUFFER_GETS

• DISK_READS

👉 Find the real heavy hitters.

⭐ 3️⃣ V$SQL — Child Cursor Details

Shows SQL per execution plan / child cursor.

Use it to diagnose:

✔ Bind peeking issues

✔ Multiple child cursors

✔ Plan instability

Key columns

• SQL_ID

• CHILD_NUMBER

• PLAN_HASH_VALUE

• EXECUTIONS

👉 Essential for plan issues.

⭐ 4️⃣ V$SYSTEM_EVENT — Where the DB Is Waiting

Shows system-wide wait events.

Use it to identify:

✔ I/O bottlenecks

✔ Lock contention

✔ Network waits

✔ CPU vs wait issues

Key columns

• EVENT

• TOTAL_WAITS

• TIME_WAITED

👉 Answers “why is the database slow overall?”

⭐ 5️⃣ V$SESSION_WAIT / V$SESSION_EVENT

Shows current and cumulative waits per session.

Use for:

✔ Session-level delays

✔ Intermittent waits

👉 Complements V$SESSION.

⭐ 6️⃣ V$ACTIVE_SESSION_HISTORY (ASH)

Samples what sessions were doing over time.

Use it to:

✔ Analyze short-lived issues

✔ Identify top SQL & waits

✔ Correlate workload spikes

👉 Time-based performance truth.

⭐ 7️⃣ V$LOCK — Lock Analysis

Use it to identify:

✔ Who is blocking

✔ Lock type

✔ Contention severity

👉 Critical for blocking & deadlocks.

🧠 Typical Troubleshooting Flow

1️⃣ Check V$SESSION

2️⃣ Identify SQL using SQL_ID

3️⃣ Analyze in V$SQLAREA / V$SQL

4️⃣ Check waits in V$SYSTEM_EVENT

5️⃣ Validate with ASH / SQL Monitoring

👉 Structured approach = faster resolution.

🎯 Final Takeaway

Oracle performance tuning is impossible without V$ views.

✔ V$SESSION → session activity

✔ V$SQLAREA → heavy SQL

✔ V$SQL → plan instability

✔ V$SYSTEM_EVENT → bottlenecks

✔ ASH → historical truth

Master these views, and you’ll diagnose issues confidently in Oracle production systems.