Overview of Oracle Agents

Oracle Intelligent Agent (OIA) was officially sunset and replaced by the Oracle Management Agent (OMA)^[1] starting with Oracle Enterprise Manager 10g.
📜 Timeline of Sunset:

• Oracle 9i and earlier:
  • Still used Oracle Intelligent Agent (OIA) for remote monitoring and job execution.
  • Configuration was manual and dependent on local OS services.
• Oracle 10g (circa 2003–2004):
  • Introduced Oracle Management Agent (OMA) as part of the Enterprise Manager Grid Control architecture.
  • More scalable, secure, and flexible than the old OIA model.
  • OIA was deprecated in favor of OMA in this release.
• Oracle 11g and beyond:
  • The Intelligent Agent is no longer supported. All new Enterprise Manager functionality requires the Management Agent.

🔄 Key Differences Between OIA and OMA

Feature	Oracle Intelligent Agent (OIA)	Oracle Management Agent (OMA)
Introduced in	Oracle 7/8/9	Oracle 10g
Communication	SNMP-based	HTTPS (secure, encrypted)
Architecture	Standalone agents	Part of Grid Control framework
Scripting	Tcl-based events	Uses plug-ins and targets
Status	Deprecated after 9i	Actively supported and evolved

Upgrading from "Oracle Intelligent Agent (OIA)" to the modern Oracle Management Agent (OMA) is not a direct in-place upgrade. Instead, it’s a migration process where you replace legacy configurations and monitoring scripts with a Grid Control or Cloud Control based monitoring system using Oracle Management Agents.
Here’s a high-level guide on how to upgrade:
🔁 Migration Process: From Intelligent Agent to Management Agent

1. Assess Your Environment
   • List all databases and servers using Oracle Intelligent Agent.
   • Check for:
     • Custom Tcl scripts and OraTcl-based events in use.
     • Job schedules and event handlers in the legacy OEM Console.
     • Version of OEM (9i or earlier), Oracle Database, and OS.
   • 📌 Note: Oracle Management Agent requires at least Oracle 10g for full compatibility.
2. Decommission the Intelligent Agent
   • Stop the Intelligent Agent service on each server:

             lsnrctl dbsnmp_stop
             

   • Disable any scheduled jobs or events using the legacy OEM Console.
   • Backup any custom Tcl scripts you want to preserve or rewrite.
3. Install Oracle Management Agent
   • Download and install the correct Management Agent version compatible with your Enterprise Manager Cloud Control or Grid Control.
   • Install the agent on each monitored server:

             ./AgentInstall.sh --silent
             

   • During installation, you’ll be prompted to provide:
     • OMS (Oracle Management Server) hostname
     • Port and credentials
     • Agent registration keys
4. Secure and Configure the Agent
   • Use the emctl utility to manage and secure the agent:

             emctl secure agent
             emctl start agent
             

   • Confirm agent connectivity with the OMS:

             emctl status agent
             

5. Discover Targets
   • Login to Enterprise Manager Cloud Control Console.
   • Navigate to:

     Setup → Add Target → Auto Discovery Results

   • From there, promote discovered targets, including:
     • Oracle databases
     • Listeners
     • ASM
     • Host-level metrics
6. Recreate Events and Jobs
   • Recreate monitoring thresholds and corrective actions using Cloud Control metrics.
   • Replace any Tcl-based scripts with:
     • Metric extensions
     • Corrective Actions written in Python, Shell, or SQL
     • Incident Rules and Notification Rules
7. Validate and Tune Monitoring
   • Monitor agent upload frequency:

             emctl upload agent
             

   • Check logs:

             $AGENT_HOME/sysman/log/emd.log
             

   • Confirm your environment replicates the monitoring you had under Intelligent Agent—but now it's centralized, secure, and extensible.

Step	Action
1	Audit Intelligent Agent setup
2	Stop and decommission OIA
3	Install Oracle Management Agent
4	Secure and validate agent
5	Discover and promote targets
6	Recreate events using new tools
7	Test and fine-tune monitoring

The Oracle Enterprise Manager enables you to centralize your DBA monitoring and create pre-defined corrective actions. Because the work is done by the Intelligent Agents on the remote servers, the corrective actions are local. This is an important point. You do not want a lost network connection to interfere with the monitoring and corrective processing. The OEM Event Manager allows for the definition of an almost infinite number of Oracle thresholds as illustrated below.

• Creating Customized Events in the Event Manager
  Unfortunately, it is quite difficult to create customized events in Event Manager unless you are proficient in Tcl, OraTcl and Application Programming Interface (API) management. If you purchase the Oracle product "Performance Pack", you receive several pre-written Tool command language (Tcl) scripts that may be used to monitor your Oracle database.

• System Events System events, like LOGON and SHUTDOWN, provide a mechanism for tracking system changes. With Oracle, this tracking can be combined with database event notification. Database event notification provides a simple and elegant method of delivering asynchrononous messaging to an application.
  
  1. various events on which triggers can be created.
  2. list of event attribute functions.

A threshold is a pre-defined value that will trigger an alert to be reported to the OEM console. For example, a tablespace_full threshold might be set for 95 percent, such that the OEM console will receive an alarm whenever any tablespace exceed the 95 percent full threshold. OEM Event Manager comes with three default UpDown thresholds, illustrated below. One indicates the server status; one corresponds to each Oracle database on the server; and the third indicates the Intelligent Agent.

The next lesson looks at how the Intelligent Agents communicate with the OEM Event Manager.

[1]Oracle Management Agent (OMA): In Oracle 19c, the Oracle Management Agent (OMA) is a crucial component of Oracle Enterprise Manager Cloud Control, responsible for monitoring and managing Oracle database instances and other targets. It facilitates communication between the managed targets and the central management server, enabling tasks like performance monitoring, job scheduling, and configuration management. OMA remains essential in 19c for proactive database administration and maintaining optimal system performance.