What's new in Oracle Enterprise Manager 12c Agents

After the Oracle Enterprise Manager 12c was announced, you may have seen a lot of collateral, documents and demos on various new functionality introduced with this major release. In my first blog, I thought of sharing what's new in agent land for Oracle Enterprise Manager 12c?

The enterprise manager agent has been entirely rewritten to meet the following goals:

  • plug-in life cycle support

  • first failure diagnostics built-in

  • robustness

  • scales to 10,000 targets

  • improved manageability

In this first blog of a blog series, we will focus on how Oracle Enterprise Manager 12c meets these goals. Subsequent blogs will go into further details about each of the areas above.

By and far the biggest change is the plug-in model. Plug-ins offer the following advantages over the previous target modeling supported by the agent:

  • independent life cycle from the agent

  • can be installed/updated without bouncing the agent

  • simple registration of user supplied libraries as needed

  • scheduled based or on-demand discovery of targets

A plug-in consists of two pieces; the discovery component and the monitoring the component. Plug-in upgrades currently require the agent to be restarted for the new plug-in version to take affect although the install of the new plug-in can be performed while the agent is still running. There is one exception to this – the first time a plug-in is deployed and installed the agent is not required to be stopped.

The discovery component of the plug-in works with the new discovery framework .Discovery can now be performed by on-demand and scheduled with the typical schedule occurring daily. As the discovery process finds additional targets to monitor, the administrator is prompted if they wish to monitor those targets. Once the decision is made, the management server ensures that the agent has the proper monitoring plug-in and then proceeds to add those targets to the agent.

The monitor component of the plug-in contains the metric definitions, the non-static properties, the default collection schedule and any additional scripts/libraries required by the plug-in to monitor. Also new in 12c are metric extensions which allows user/administrators to add additional metrics to a target with user supplied scripts.

Diagnosis of issues is always a difficult process, but the new agent, being written from the ground up has put in a significant amount of diagnostic tools. Even in the face of all that additional processing, the new code base consumes less CPU on average than the previous versions and is capable of scaling to large number of targets. To date, we've successfully measured target counts of approximately 5000 targets being monitored with near linear scaling. We therefore believe that 10,000 targets is realistic.

Below is a graph comparing the average CPU consumption of the 12c version of the agent (in green) against the 11g version (in red) for database targets.

The rewrite of the agent also includes an improved EM agent home page as well as a much enhanced agent side metric browser. There are numerous enhancements to enable the agent to continue functioning in the face of 'failures', such as three strikes suspension based policies for collections, as well as more control services available to the administrator.

My next next blog will focus on some of the diagnostic tools that are available for both administrators and Oracle personnel.

For more information, please go to Oracle Enterprise Manager  web page or  follow us at : 

Twitter | Facebook | YouTube | Linkedin | Newsletter


It's good that 12c agent now requires less CPU for more 100 targets.

But who really hosts 100 targets in a single machine? And would you want such high risk of single point of failure for so many targets.

Posted by Vishal Gupta on February 01, 2012 at 01:19 AM PST #


We've seen easily 50-75 db targets (which translates into 100-150 agent side targets) in many existing installations already. And when we move into the world of fusion monitoring, we've seen upwards of 4000 targets in real sites.


Posted by guest on February 01, 2012 at 07:14 AM PST #


Can you expand on the "user supplied scripts" and "additional metrics" perhaps in a separate blog post.

Specifically, I am very much interested in how 12c can help us integrate our custom shell script monitoring framework into EM:

1) What hooks do we have to work with to tie our custom monitoring shell scripts to EM?

2) What is the format of data output our scripts have to produce to be digested by the EM? And how are events triggered (ON|OFF)?

3) How can we tie into the "plug-in deployment" mechanism in order to save us from manually copying all shell-scripts to each target?

A simple example of a custom ground-up plug-in development and deployment would be much appreciated.

Thank you,
- Vitaliy

Posted by Vitaliy on February 01, 2012 at 10:46 AM PST #


Sure. I'll expand upon user created metric extensions in a future blog. But please understand that these are user created. Its not clear from your comment, but it would appear that your describing building your own monitoring plugin. If so, then you would need to review the integrators guides for building plugins.

Jonathan Klein

Posted by Jonathan Klein on February 01, 2012 at 10:51 AM PST #


I take it that you are talking about these database targets locally on agent's server.

I would love to see who is able successfully run 50-75 database on a single host. Is their hardware really that robust that they feel confident of hosting 75 application on a single server? I can already see the panic and hyperactivity in that company when their server fails and business people and users from 75 business application start ringing their support line to complain that system is down.

Vishal Gupta

Posted by guest on February 01, 2012 at 12:57 PM PST #

There are numerous customers running 50-75 databases already (I can provide such references if needed). The point is the agent architecture has been redesigned to both reduce cpu and memory consumption (I did not provide similar charts showing for different workloads the memory reductions we've seen). Our goal was to be able to scale - the previous versions of the agent had serious scalability issues that limited customers in the past, and would limit fusion deployments currently being developed.


Posted by Jonathan Klein on February 01, 2012 at 01:34 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

Latest information on Oracle Enterprise Manager and Oracle Management Cloud.

Related Blogs


« December 2016