The Migration Project That Changed My Career

After almost 5 years of my Oracle journey, I joined HCL and got the opportunity to work on a Database Migration Project.

At that time, I didn't realize how important this project would become in my career.

Looking back now, I can confidently say — this project was one of the biggest turning points in my Oracle journey.

It was not just about migrating databases from one place to another. It was where I got the chance to learn the complete lifecycle of an Oracle database.

DB Creation? ✅
Schema creation? ✅
Objects? ✅
Data Guard setup and troubleshooting? ✅
GoldenGate setup and maintenance? ✅
OEM setup and monitoring? ✅
RMAN backup and restore? ✅
ZDLRA? ✅
PSU patching? ✅
Database upgrades? ✅

Honestly, you name an Oracle technology or activity, and somehow it was part of that migration project! 😄

And that's what made the project so special for me.

I learned not only how to perform these activities, but also why they matter in a real production environment. I learned how to troubleshoot when things don't go as planned, how to handle critical databases, and most importantly, how to take ownership.

There were long days, challenging migrations, unexpected issues, troubleshooting calls and plenty of learning along the way.

But every challenge added something to my experience.

That project gave me a strong foundation, and many of the things I learned there are still helping me today.

Five years into my Oracle journey, I thought I was just joining another project.

I didn't know I was joining a project that would shape the next chapter of my career.

Even today, I am still counting the lessons from that project. ❤️

Sometimes, a project is more than just a project.
Sometimes, it becomes a part of your career story.

#OracleDBA #OracleDatabase #DatabaseMigration #HCL #DataGuard #GoldenGate #OEM #RMAN #ZDLRA #OracleCommunity #DBALife #CareerJourney #LearningNeverStops

Oracle Enterprise Manager (OEM) Integration with ServiceNow (SNOW) – Complete Configuration Guide

 

Oracle OEM to ServiceNow Integration for Automatic Incident Creation

In enterprise environments, Oracle Enterprise Manager (OEM) continuously monitors databases, hosts, middleware, and engineered systems. However, monitoring alone is not enough. Organizations need automated incident creation so that operations teams can respond immediately whenever a critical alert occurs.

Integrating Oracle Enterprise Manager (OEM) with ServiceNow (SNOW) enables automatic ticket generation, ensuring every critical alert is tracked, assigned, and resolved through the organization's ITSM process.

This guide demonstrates the complete configuration process used in production environments.

---

Purpose

To configure and validate the integration between Oracle Enterprise Manager (OEM) and ServiceNow for automatic incident creation and management.

---

Scope

This procedure applies to:

• Oracle Enterprise Manager Administrators
• Oracle DBAs
• Monitoring Administrators
• ServiceNow Administrators
• IT Operations Teams

---

Architecture

Oracle Database
        │
        ▼
Oracle Enterprise Manager (OEM)
        │
        ▼
Management Connector
        │
        ▼
REST API
        │
        ▼
ServiceNow
        │
        ▼
Incident Created
        │
        ▼
Assignment Group
        │
        ▼
Operations Team

---

Step 1 – Access Management Connectors

Login to Oracle Enterprise Manager Cloud Control.

Navigate to:

Setup
   ↓
Extensibility
   ↓
Management Connectors

The Management Connectors page displays all configured external integrations.

---

Step 2 – Verify Connector Status

Locate the ServiceNow Connector.

Verify its status.

Healthy Connector

🟢 Green Status

This indicates:

• OEM can communicate with ServiceNow.
• Connector is active.
• REST API communication is successful.

If the connector is not green:

• Verify ServiceNow URL.
• Verify firewall connectivity.
• Verify credentials.
• Check OEM Management Connector logs.
• Validate API endpoints.

Do not continue until the connector status is healthy.

---

Step 3 – Configure Connection Settings

Open the ServiceNow Connector.

Navigate to:

Connection Settings

Configure the required REST API endpoints.

Typical operations include:

• Incident Create
• Incident Update
• Incident Query
• Incident Close

Ensure the ServiceNow instance URL is correct and reachable.

---

Step 4 – Configure Authentication

Provide the ServiceNow integration account.

Example:

Username

oracle_integration

Password

Retrieve securely from the organization's password vault (for example, KeePass).

Never store passwords in plain text.

Best practice:

• Dedicated integration account
• Minimum required privileges
• Password rotation policy
• Vault-based credential management

---

Step 5 – Test the Connection

Before enabling production alerts:

Open

Test Connection

Enter a valid ServiceNow Incident Number.

Example:

INC0012345

Click:

Test

Expected Result:

• OEM successfully connects.
• Incident information is retrieved.
• Connection validation completes successfully.

If the test fails:

• Verify credentials.
• Verify API permissions.
• Check connector logs.
• Validate ServiceNow REST API availability.

---

Step 6 – Configure Incident Template

Navigate to:

Template Settings

Open:

ServiceNow Incident Create and Update

This template determines the information automatically populated whenever OEM creates an incident.

Common pre-filled fields include:

• Caller
• Contact Type
• Assignment Group
• Business Service
• Configuration Item (CI)
• Category
• Subcategory
• Impact
• Urgency
• Priority
• Work Notes
• Description

A well-designed template ensures standardized ticket creation and faster incident handling.

---

Example Incident Flow

Database Down
      │
      ▼
OEM Detects Alert
      │
      ▼
Severity = Critical
      │
      ▼
Management Connector
      │
      ▼
ServiceNow REST API
      │
      ▼
Incident Created
      │
      ▼
Assignment Group = Oracle DBA
      │
      ▼
Email Notification
      │
      ▼
DBA Begins Troubleshooting

---

Validation Checklist

Check	Status
OEM Connector Installed	✅
Connector Status Green	✅
ServiceNow URL Reachable	✅
Authentication Successful	✅
Test Connection Passed	✅
Incident Template Configured	✅
Automatic Ticket Creation Verified	✅

---

Production Example

OEM Alert Generated

Target

PRODDB01

Alert

Database Availability

Severity

Critical

Message

Database Instance PRODDB01 is Down

↓

OEM automatically sends the alert to the configured ServiceNow connector.

↓

ServiceNow Incident Created

Incident Number

INC00125874

Short Description

Critical OEM Alert - PRODDB01 Database Down

Assignment Group

Oracle DBA Team

Priority

P1

Impact

High

Urgency

High

Status

New

↓

The Oracle DBA team receives the notification and immediately begins troubleshooting.

---

Best Practices

• Use a dedicated ServiceNow integration account.
• Secure credentials using a password vault.
• Validate connector health after OEM upgrades.
• Test integration after ServiceNow maintenance.
• Configure meaningful assignment groups.
• Standardize incident templates across environments.
• Monitor connector logs for failed API calls.
• Periodically verify end-to-end incident creation.

---

Conclusion

Oracle Enterprise Manager and ServiceNow integration enables automated incident management, reducing manual effort and improving response times for critical database events. By validating connector health, securing authentication, testing connectivity, and maintaining standardized incident templates, organizations can ensure reliable, consistent, and auditable incident creation.

A successful deployment is confirmed when an OEM-generated critical alert automatically creates a corresponding ServiceNow incident with the correct assignment group, priority, and incident details—allowing the operations team to respond without delay.

---

📘 OEM Runbook (L2/L3) – Oracle Monitoring & Alert Management

Using Oracle Enterprise Manager 13c

---

🎯 Objective

To:

• Monitor database health

• Detect issues proactively

• Reduce alert noise

• Troubleshoot incidents quickly

---

🧭 1. First Response Playbook (When Alert Comes)

🚨 Step 1: Open Incident Manager

📍 Navigation:

Enterprise → Monitoring → Incidents

Check:

• Severity (Critical / Warning)

• Target (DB / Host / Listener)

• Message (Tablespace / CPU / Lock etc.)

---

🧠 Step 2: Identify Issue Type

Alert Type	Meaning	Action
CPU High	Performance issue	Check SQL / load
Tablespace Full	Storage issue	Add space
Session Blocking	Lock issue	Kill blocker
Host Down	Infra issue	Check server
Listener Down	Connectivity issue	Restart

---

🔍 2. Deep Dive Troubleshooting

---

⚡ Case 1: Database Performance Issue

Step 1: Open Performance Page

📍

Target → Database → Performance → Top Activity

Check:

• CPU usage

• Wait events

• Active sessions

---

Step 2: Identify Top SQL

📍

Performance → SQL Monitoring / Top SQL

Action:

• Find high elapsed time SQL

• Capture SQL_ID

---

Step 3: Analyze Execution Plan

SELECT *
FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('<SQL_ID>', NULL, 'ALLSTATS LAST'));

---

Step 4: Fix

• Add index

• Gather stats

• Apply SQL Profile

---

🔒 Case 2: Blocking / Locking Issue

Step 1: Check Blocking Sessions

📍

Performance → Blocking Sessions

OR SQL:

SELECT blocking_session, sid, serial#
FROM v$session
WHERE blocking_session IS NOT NULL;

---

Step 2: Kill Blocking Session

ALTER SYSTEM KILL SESSION 'SID,SERIAL#' IMMEDIATE;

---

Step 3: Root Cause

• Application not committing

• Long transactions

---

💾 Case 3: Tablespace Full

Step 1: Check Usage

📍

Storage → Tablespaces

---

Step 2: Add Space

ALTER DATABASE DATAFILE '/path/file.dbf'
RESIZE 10G;

OR

ALTER TABLESPACE users
ADD DATAFILE '/path/file02.dbf' SIZE 5G;

---

🔥 Case 4: CPU Spike

Step 1: Check Load

📍

Performance → Top Activity

---

Step 2: Identify Cause

• High SQL load

• Batch jobs

• Parallel queries

---

Step 3: Action

• Tune SQL

• Kill runaway sessions

• Limit parallelism

---

🌐 Case 5: Listener / Connectivity Issue

Step 1: Check Listener Status

lsnrctl status

---

Step 2: Restart Listener

lsnrctl stop
lsnrctl start

---

🔁 3. Alert Noise Reduction (VERY IMPORTANT)

---

🔧 Configure Thresholds

📍

Targets → Monitoring → Metric Settings

Best Practice:

• Warning: 80%

• Critical: 90%

• Occurrence: 3

---

🔁 Configure Incident Rules

📍

Setup → Incidents → Incident Rules

Enable:

• ✔ Add to existing incident

• ✔ Event grouping

---

🔕 Configure Notifications

📍

Setup → Notifications

Rule:

• Only Critical alerts → Email

---

⛔ Configure Blackouts

📍

Enterprise → Monitoring → Blackouts

Use During:

• Patching

• Maintenance

---

📊 4. Daily Health Check (L2 Task)

---

✅ Check 1: Incident Summary

Enterprise → Incidents

---

✅ Check 2: DB Status

Targets → Databases

---

✅ Check 3: Tablespace Usage

Storage → Tablespaces

---

✅ Check 4: Backup Status

Availability → Backup Reports

---

✅ Check 5: Performance

Performance → Top Activity

---

🚀 5. L3 Advanced Activities

---

🔬 AWR / ADDM Analysis

📍

Performance → AWR → Reports

---

⚙️ SQL Tuning Advisor

📍

Performance → SQL → Tuning Advisor

---

🧠 ASH Analytics

📍

Performance → ASH Analytics

---

🔄 Corrective Actions (Auto-Healing)

📍

Metric Settings → Corrective Actions

Example:

lsnrctl start

---

🎯 6. SLA / Escalation Matrix

Severity	Action	SLA
Critical	Immediate fix	15 mins
High	Investigate	30 mins
Medium	Monitor	2 hrs
Low	Review	Next day

---

🧠 7. Interview Questions (L2/L3)

---

❓ How do you troubleshoot OEM alert?

Answer:

I check Incident Manager, identify alert type, drill into performance metrics, analyze SQL or system issue, and apply corrective action.

---

❓ How do you reduce alert noise?

Answer:

• Tune thresholds

• Configure incident rules

• Use blackout

• Filter notifications

---

❓ What is difference between Event and Incident?

Event	Incident
Raw alert	Grouped issue

---

❓ What is your first step in performance issue?

Answer:

Check Top Activity and wait events to identify bottleneck.

---

🏁 Final Production Mindset

“OEM is not just a monitoring tool…
It is your control tower for the entire database ecosystem.”

---

Screenshots of real OEM UI visuals

 Here are real OEM UI visuals (based on Oracle docs & actual console layouts) so you can understand how screens look in Oracle Enterprise Manager 13c.

I’ll walk you through the main screens with visual-style explanation (like screenshots) 👇

---

🖥️ 1. OEM Dashboard (Home Page)

----------------------------------------------------------
| Enterprise Manager Console                            |
----------------------------------------------------------
| Targets Status | Incidents | Alerts | Performance     |
----------------------------------------------------------
| DB1  ✅ Up     | Incidents: 3 🔴                    |
| DB2  ⚠ Warning | CPU High                          |
| HOST1 ✅       | Tablespace 90%                    |
----------------------------------------------------------
| Top Activity | CPU | Memory | Sessions              |
----------------------------------------------------------
| Graphs showing load, sessions, SQL activity          |
----------------------------------------------------------

🔍 What you see:

• Overall DB status

• Alerts summary

• Performance graphs

👉 This is your first landing page

---

🚨 2. Incident Manager Screen (MOST IMPORTANT)

📍 Navigation:
Enterprise → Monitoring → Incident Manager

----------------------------------------------------------
| Incident Manager                                      |
----------------------------------------------------------
| Summary:                                              |
| Open: 12 | Critical: 3 🔴 | Warning: 5 ⚠              |
----------------------------------------------------------
| Charts:                                               |
| - Incidents by Severity                               |
| - Incidents by Target                                 |
----------------------------------------------------------
| Incident List:                                        |
----------------------------------------------------------
| Time     | Target | Message             | Severity     |
----------------------------------------------------------
| 11:05    | DB1    | Tablespace Full     | CRITICAL 🔴  |
| 11:06    | DB1    | Tablespace Full     | CRITICAL 🔴  |
| 11:07    | DB1    | Tablespace Full     | CRITICAL 🔴  |
----------------------------------------------------------

💡 Key Point:

👉 With alert compression enabled

• These 3 rows → become 1 incident

📌 OEM groups events into incidents automatically (Oracle Documentation)

---

📊 3. Incident Dashboard (Graph View)

----------------------------------------------------------
| Incident Dashboard                                   |
----------------------------------------------------------
| 🔴 Critical: 3   ⚠ Warning: 5   ℹ Info: 4              |
----------------------------------------------------------
| Pie Chart:                                            |
| DB Issues: 50%                                        |
| Host Issues: 30%                                      |
| Listener: 20%                                         |
----------------------------------------------------------
| Actions:                                              |
| [Acknowledge] [Assign] [Escalate]                     |
----------------------------------------------------------

🔍 What this gives:

• Visual distribution of issues

• Quick filtering

👉 Dashboard auto-refreshes every ~30 sec (Oracle Documentation)

---

⚙️ 4. Metric & Threshold Configuration Screen

📍 Navigation:
Target → Monitoring → Metric and Collection Settings

----------------------------------------------------------
| Metric Settings: CPU Utilization                     |
----------------------------------------------------------
| Warning Threshold: 80%                               |
| Critical Threshold: 90%                              |
| Occurrences: 3                                       |
----------------------------------------------------------
| Corrective Action:                                   |
| Script: restart_service.sh                           |
----------------------------------------------------------
| [Save]                                               |
----------------------------------------------------------

💡 Important:

• Occurrences = key for alert suppression

• Prevents alert flapping

---

🔁 5. Incident Rules (Alert Compression Engine)

📍 Navigation:
Setup → Incidents → Incident Rules

----------------------------------------------------------
| Rule Set: DB_ALERT_COMPRESSION                       |
----------------------------------------------------------
| Condition:                                           |
| Target Type = Database                              |
| Severity = Critical                                 |
----------------------------------------------------------
| Actions:                                             |
| ✔ Create Incident                                   |
| ✔ Add to existing open incident (IMPORTANT)         |
| ✔ Send Notification                                |
----------------------------------------------------------

🔥 This is the feature:

👉 That actually performs alert grouping/compression

---

🔕 6. Notification Rules Screen

📍 Navigation:
Setup → Notifications → Notification Rules

----------------------------------------------------------
| Notification Rule                                   |
----------------------------------------------------------
| Target: All Databases                               |
| Event Type: Metric Alert                            |
| Severity: Critical Only                             |
----------------------------------------------------------
| Actions:                                             |
| Send Email: dba@company.com                         |
----------------------------------------------------------

💡 Result:

• No spam emails

• Only critical alerts sent

---

⛔ 7. Blackout Screen (Maintenance Mode)

📍 Navigation:
Enterprise → Monitoring → Blackouts

----------------------------------------------------------
| Create Blackout                                     |
----------------------------------------------------------
| Target: DB1                                         |
| Start Time: 10:00                                   |
| Duration: 2 Hours                                  |
----------------------------------------------------------
| Options:                                            |
| ✔ Stop Monitoring                                  |
| ✔ Suppress Alerts                                  |
----------------------------------------------------------

---

🎯 How It All Connects (Architecture Flow)

DB Metric → Threshold Breach → Event Generated
                ↓
        Incident Rule Applied
                ↓
     Event Grouped (Compression)
                ↓
         Incident Created
                ↓
     Notification Sent (if needed)

👉 OEM uses agents + rules to convert events into incidents (Oracle)

---

🧠 Real DBA Understanding

When you see OEM UI:

Screen	Purpose
Dashboard	Overall health
Incident Manager	Actual issues
Metric Settings	Control alerts
Incident Rules	Reduce noise
Notifications	Alert delivery

---

🚀 Pro Tip (From Production)

Most DBAs fail because:

• They only look at Incidents

• But never configure:

  • Thresholds

  • Rules

👉 Result = Alert storm

---

OEM 13.5 – Alert Noise Reduction (UI Configuration)

---

🔧 1. Configure Metric Thresholds (First & Most Important)

👉 This is where most alert noise comes from.

📍 Navigation:

Targets → Databases → Select your DB → Monitoring → Metric and Collection Settings

🪜 Steps:

1. Search for a metric (e.g., CPU Utilization, Tablespace Used (%))

2. Click Edit (pencil icon)

3. Set thresholds properly:

   • Warning: e.g., 80%

   • Critical: e.g., 90%

4. Set Occurrences (very important):

   • Example: Trigger only if 3 consecutive collections fail

5. Click OK → Save

💡 Tip:

• Use “Occurrences > 1” to avoid false alerts (flapping)

---

🔁 2. Configure Incident Rules (Event Grouping / Compression)

👉 This is the real “alert compression engine”

📍 Navigation:

Setup → Incidents → Incident Rules

🪜 Steps:

1. Click Create Rule Set

2. Name it (e.g., DB_ALERT_COMPRESSION)

3. Click Create Rule

---

🔹 Rule Configuration:

Condition:

• Target Type = Database Instance

• Severity = Critical / Warning

Actions:

• ✔ Create Incident

• ✔ Add to existing open incident (IMPORTANT)

• ✔ Set Incident Priority

👉 This ensures:

Same issue → 1 incident instead of many alerts

---

🔕 3. Configure Notification Rules (Avoid Spam Emails)

📍 Navigation:

Setup → Notifications → Notification Rules

🪜 Steps:

1. Click Create

2. Define:

   • Target (DB / Host)

   • Event Type (Metric Alert)

   • Severity (Critical only recommended)

3. Configure:

   • Send email only for Critical

   • Suppress Warning alerts (optional)

---

💡 Pro Tip:

• Send:

  • Warning → Dashboard only

  • Critical → Email/SMS

---

⛔ 4. Configure Blackouts (Maintenance Mode)

👉 Prevent alerts during planned work

📍 Navigation:

Enterprise → Monitoring → Blackouts

🪜 Steps:

1. Click Create Blackout

2. Select Target (DB / Host)

3. Define:

   • Duration (e.g., 2 hours)

4. Enable:

   • ✔ Stop monitoring

   • ✔ Suppress alerts

---

✅ Result:

No alerts during:

• Patching

• Restart

• Maintenance

---

🔄 5. Configure Corrective Actions (Auto-Healing)

👉 Stops repeated alerts automatically

📍 Navigation:

Targets → Database → Monitoring → Metric and Collection Settings

🪜 Steps:

1. Select a metric (e.g., Listener Down)

2. Click Edit

3. Go to Corrective Actions

4. Add script:

Example:

lsnrctl start

---

💡 Result:

• Issue auto-fixed

• Alert doesn’t repeat

---

🔍 6. Enable Event De-duplication & Correlation

👉 Mostly automatic but configurable

📍 Navigation:

Setup → Incidents → Incident Rules → Advanced Settings

🪜 Steps:

1. Enable:

   • ✔ Event de-duplication

   • ✔ Event correlation

2. Define time window (e.g., 5–10 mins)

---

💡 Example:

• Same alert every minute
  ➡️ Only one incident shown

---

📊 7. Validate Configuration

📍 Navigation:

Enterprise → Monitoring → Incidents

Check:

• Alerts grouped properly

• No duplicate incidents

• Reduced alert count

---

🎯 Real Production Setup (Recommended)

Feature	Setting
Threshold Occurrence	3
Incident Grouping	Enabled
Notifications	Critical only
Blackouts	Mandatory
Auto-healing	Enabled

---

🧠 Interview-Ready Answer

👉 “How do you reduce alert noise in OEM?”

Answer:

“I tune metric thresholds with occurrence settings, configure incident rules to group alerts, use notification filtering to avoid unnecessary emails, apply blackouts during maintenance, and enable corrective actions to auto-resolve recurring issues.”

---

🚀 Final Thought

“OEM is powerful… but without tuning, it becomes noisy.
A good DBA makes OEM quiet but intelligent.”

---

Alert Compression / Noise Reduction in Oracle Enterprise Manager 13c

🧠 What is “Alert Compression”?

OEM doesn’t use the exact term “compression” officially, but in practice it means:

👉 Reducing duplicate, repetitive, or noisy alerts into fewer meaningful alerts

---

⚡ Why It’s Needed

Without this:

• Same issue → 100+ alerts

• DBAs get flooded

• Real issues get missed

With alert compression:

• Duplicate alerts → grouped / suppressed

• Only actionable alerts remain

---

🔧 Key Features That Enable Alert Compression

1️⃣ Incident Rules (Event Compression Engine)

👉 Core mechanism behind alert reduction

What it does:

• Groups multiple events into a single incident

• Prevents duplicate alerts

Example:

• 10 tablespace alerts
  ➡️ 1 incident instead of 10 alerts

---

2️⃣ Event De-duplication

OEM automatically:

• Detects same event repeating

• Suppresses repeated notifications

👉 Example:

• “CPU high” every minute
  ➡️ Only one alert generated

---

3️⃣ Event Correlation

👉 Combines related alerts into one

Example:

• DB down

• Listener down

• Host down

➡️ OEM shows one root incident

---

4️⃣ Metric Threshold Suppression

👉 Avoids alert flapping

How:

• Warning/Critical thresholds

• Clear condition required before re-alert

---

5️⃣ Blackouts (Temporary Alert Suppression)

👉 Used during maintenance

Patch window → No alerts triggered

---

6️⃣ Notification Rules Filtering

👉 Only send alerts when needed

• Based on severity

• Based on target

• Based on time

---

7️⃣ Corrective Actions (Auto-Healing)

👉 Prevents repeated alerts

Example:

• Listener down
  ➡️ Auto restart script
  ➡️ No repeated alerts

---

📊 Real Example (Before vs After)

❌ Without Alert Compression:

• 50 alerts for:

  • Tablespace full

  • CPU spike

  • Session blocking

---

✅ With OEM Features:

• 1 incident for tablespace

• 1 incident for CPU

• 1 incident for blocking

👉 Huge noise reduction

---

🎯 Best Practices (Production)

✅ 1. Use Incident Rules

• Group related alerts

• Define severity properly

---

✅ 2. Tune Thresholds

Avoid:

• Too sensitive alerts

• Too many false positives

---

✅ 3. Enable Blackouts

During:

• Patching

• Maintenance

---

✅ 4. Use Corrective Actions

Automate:

• Restart services

• Clear temp issues

---

🧠 Interview Questions

---

❓ What is alert compression in OEM?

Answer:

It is the process of reducing duplicate or repetitive alerts using incident rules, event correlation, and suppression mechanisms.

---

❓ How does OEM avoid alert flooding?

Answer:

• Incident rules

• Event de-duplication

• Threshold tuning

• Blackouts

---

❓ What is the difference between Event and Incident?

Event	Incident
Raw alert	Grouped actionable alert
Many	Few

---

❓ How do you reduce alert noise in OEM?

Answer:

• Tune thresholds

• Configure incident rules

• Use blackout

• Enable auto corrective actions

---

🚀 Final Thought

“A good DBA doesn’t monitor more alerts…
They monitor fewer, smarter alerts.”

---

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.