Communication Between Oracle Management Agent (OMA) and Oracle Enterprise Manager (OEM) in Oracle 19c

In Oracle 19c, the "Oracle Management Agent (OMA)" communicates with "Oracle Enterprise Manager Cloud Control (OEM 13c/19c)" using a push-based, secure, and bidirectional protocol (primarily HTTP/HTTPS) instead of the older SNMP-based polling used in Oracle 8i.
1. Key Differences from Oracle 8i (SNMP-based) to Oracle 19c (HTTPS-based)

Feature	Oracle 8i (Intelligent Agent)	Oracle 19c (Management Agent - OMA)
Protocol	SNMP (Simple Network Management Protocol)	HTTPS (Secure HTTP)
Communication Model	Pull-based (Event Manager polls agents)	Push-based (Agent sends data to OEM)
Security	Basic community strings (less secure)	SSL/TLS encryption, certificate-based auth
Scalability	Limited (manual services file entries)	Dynamic, cloud-ready, auto-discovery
Monitoring Type	Static checks (predefined metrics)	Real-time, adaptive, plugin-based

2. How OMA Communicates with OEM 19c
A. Agent Registration and Secure Connection

1. Installation and Registration
   • The Management Agent (OMA) is installed on a target host (database, middleware, etc.).
   • During setup, it registers with OEM Cloud Control using:
     • OMS (Oracle Management Server) URL (e.g., https://<OEM-Server>:7802/em)
     • Mutual SSL Authentication (agent and OEM verify each other via certificates).
2. Secure Communication (HTTPS)
   • All data exchanges between OMA and OEM occur over HTTPS (Port 3872 by default).
   • Uses Oracle Wallet for credential storage and encryption.

1. Monitoring Plugins and Extensions
   • OMA runs plugins (e.g., oracle.sysman.db, oracle.sysman.emas) to collect metrics.
   • Plugins can be custom-developed or provided by Oracle (e.g., for databases, Fusion Middleware).
2. Push-Based Monitoring
   • Unlike SNMP (where the manager polls agents), OMA actively pushes data to OEM at configured intervals.
   • Metrics include:
     • Performance data (CPU, memory, SQL queries)
     • Alerts (threshold breaches, critical errors)
     • Job statuses (backups, patches)
3. Heartbeat Mechanism
   • OMA sends periodic heartbeats to OEM to confirm availability.
   • If OEM doesn’t receive a heartbeat, it marks the agent as unreachable.

C. Job Execution and Remote Operations

1. Job Dispatch from OEM → Agent
   • When an admin schedules a job (e.g., backup, script execution) in OEM, it sends the command to OMA via HTTPS.
   • The agent executes the job and sends back status logs.
2. Real-Time Response Handling
   • Results are streamed back to OEM in near real-time.
   • Example: A SQL script execution on a target database is relayed via OMA to OEM.

D. High Availability and Load Balancing

• Multiple OMS (Management Servers) can be configured for failover.
• Agents automatically switch to a backup OMS if the primary fails.

3. Advantages Over SNMP (Oracle 8i Style)

• ✅ Better Security – HTTPS + TLS encryption vs. SNMP’s weak authentication.
• ✅ Real-Time Data – Push model reduces latency compared to SNMP polling.
• ✅ Dynamic and Scalable – Auto-discovery of targets, cloud-friendly.
• ✅ Extensible – Plugin architecture allows custom monitoring.

Summary of OMA-OEM 19c Communication Flow

1. Agent installed → Registers with OEM via HTTPS.
2. Collects metrics via plugins → Pushes to OEM periodically.
3. Receives jobs from OEM → Executes and reports back.
4. Heartbeat checks ensure connectivity.

In Oracle 19c, the Oracle Management Agent (OMA) serves as a critical component for monitoring and managing database environments by facilitating communication with Oracle Enterprise Manager Cloud Control (OEM 13c/19c). The OMA employs a push-based mechanism to transmit data, meaning it actively sends information such as performance metrics, alerts, and system health updates to the OEM without waiting for explicit requests. This push-based approach ensures that the OEM receives real-time or near-real-time updates from the managed targets, enabling administrators to respond promptly to issues or changes in the environment. The communication primarily leverages HTTP or HTTPS, with the latter being the default and preferred method due to its inherent security features, ensuring that data is transmitted efficiently and reliably across the network.
Security is a cornerstone of the OMA’s communication with OEM 19c, and the use of HTTPS establishes a secure channel through encryption and authentication. When the OMA is installed and configured, it registers itself with the OEM using a secure handshake process, during which certificates are exchanged to validate the identities of both the agent and the management server. This ensures that only authorized agents can communicate with the OEM, preventing unauthorized access or data interception. Data transmitted over HTTPS is encrypted using protocols like TLS, safeguarding sensitive information such as database performance statistics or configuration details from potential eavesdropping or tampering during transit. Additionally, the bidirectional nature of the protocol allows the OEM to send commands or configuration updates back to the OMA, such as deploying patches or adjusting monitoring thresholds, all within the same secure framework.
The bidirectional capability of the OMA-OEM communication protocol enhances its flexibility and responsiveness. While the OMA primarily pushes data to the OEM, the management server can also initiate communication to query the agent for additional details or instruct it to perform specific tasks, such as running diagnostic scripts or collecting logs. This two-way interaction is facilitated through the same HTTP/HTTPS connection, maintaining a persistent and efficient link between the agent and the OEM. The push-based model, combined with secure bidirectional communication, allows for a robust monitoring and management system where the OEM can maintain a centralized view of the enterprise environment while dynamically interacting with distributed agents. This architecture supports scalability and ensures that administrators have both proactive insights and control over their Oracle 19c deployments.

Oracle uses the Simple Network Management Protocol (SNMP) to enable communication between the Intelligent Agents and the Event Manager. SNMP is a standard Internet protocol enabling certain nodes in a network via the management stations or managing nodes, to query other network components or applications for information concerning their status and activities. Management stations are the OEM data collectors from the intelligent agents. The managing nodes are the Remote servers that are running an instance of intelligent agent. Traditionally, managed elements have been limited to network components such as bridges and routers, but recently the definition has been extended to include mission-critical applications such as databases.
An Intelligent Agent resides on the same node as the services it supports. However, the agent can support more than one service on a particular node. For example, if two databases are installed on one machine, a single agent can support both databases. The agents perform OEM tasks such as running jobs and monitoring events.
The next lesson looks at how an Intelligent Agent is installed and configured.