Thursday Mar 01, 2012

Sushil Kumar, VP,Product Strategy and Business development,Oracle shares highlights of new Oracle Enterprise Manager 12c update

Yesterday ( Feb. 29, 2012), Oracle announced the Oracle Enterprise Manager 12c Bundle patch 1 and 12.1.0.2 Plug-in updates. The new "Bundle Patch" contains numerous bug fixes, performance improvements and new features to improve Oracle Enterprise Manager Cloud Control 12c customer experience . 

Sushil Kumar, VP, Product Strategy and Business development, Oracle Enterprise Manager, shared the highlights of the new "Bundle Patch" with me earlier today. In this blog, I captured my discussion with Sushil.

The new “Bundle Patch” is a pretty significant update to Oracle Enterprise Manager 12c bits released at Oracle Open World in October, 2012. It contains over 3000 bug fixes and includes some brand new functionality such as Weblogic and Fusion Apps Patching, Exadata out of place patching, etc. We recommend customers, who are considering to go live with EM 12c in production in the next few months, to pick up this mandatory update. 


Even though we are calling this update a "Bundle Patch", an updated Enterprise Manager Base Platform Full Installer is made available for download on Oracle Technology Network (OTN).  Any customer who downloads the 12c bit as of February 29, 2012, will automatically get these updates as a part of the base install. In another words, if you download the EM 12c product by clicking on “for Linux x86 (64 bit) (With Bundle Patch)” link from the OTN Download center (see the screen shot below) and do a fresh install, you will have all the updates required and no additional patches need to be applied to get these updates. 


The revised installation media is only available for Linux right now. The updated installer will be released on other operating systems in the coming weeks/months.

If you have not already discovered a large number of targets, defined admin groups and monitoring templates or defined compliance policies and rules, etc. with previously released Oracle Enterprise Manager 12c bit, then a fresh install with the updated installer is the way to go. The option of “patching” a site running on previously released EM bits exists , but, it may be worth the pain only if you have already put in a lot of time and effort setting up your EM 12c environment based on the previously released bits.

We are working closely with the early adopter customers of Oracle Enterprise Manager 12c to make sure that they can update in a smoothest possible manner. If you were not part of the EM 12c early adopter program, please work with your Oracle support .


The other exciting announcement with the release of EM 12c iPhone app that Scott blogged about yesterday. This is in response to the strong customer demand to make EM accessible from mobile devices. The new app primarily exposes the incident management functionality but we will add more features to it moving forward.


Finally, we want to highlight that the only supported version of Oracle BI Publisher with EM 12c is 11.1.1.5 and it is linked from the EM 12c download page.  Please do not use the latest version 11.1.1.6 of BI publisher with EM 12c since that may render your environment unusable. We do have plans to support 11.1.1.6 in the near future, but, as of now, please download the BI publisher version that is linked off the EM 12c download page on OTN.

Please share your feedback by providing your comments on this blog, using #em12c tag on twitter and other social media channel following the links below.


Stay Connected:
Twitter |
Facebook | YouTube | Linkedin | Newsletter

Enterprise Manager 12C Agent Home Page

My first blog focused on the new architecture of the Oracle Enterprise Manager 12c agent. Now I will start a series of blogs that discuss various issues. This current entry will discuss the numerous tools available for the end user to self-diagnose issues and keep track of key performance metrics of the agent.

To start with, the agent maintains detailed statistics around each operation being performed and can report on these automatically in a top 'N' style report hourly. This is called the Top Metric Report and can be enabled via the property topMetricReporter=true in the emd.properties file. Once enabled, reports are automatically produced hourly and can also be requested on demand. Reports are maintained for a period of 24 hours.

The reports are stored in xml inside of the agent state home (available in $EMSTATEDIR/sysman/emd/topMetrics). They are also available from the agent metric browser, where a report can be requested to be generated as well.

The report provides detailed information regarding the top consuming cpu targets and/or metrics enabling customers to decide if collections are occurring too frequently. Customers can then modify the Oracle default collection frequencies.


The agent home page in the enterprise manager console has been redesigned to provide specific performance information about the agent. There are three main panels to be review.


The first is the performance panel. It contains 3 key performance indicators (KPI's) of the agent. They are:

  • Upload transfer time for 1KB measured in milliseconds (this metric is the graphed values)

  • Time spent on average per collection as a percentage of the declared collection interval

  • Agent heartbeat round trip time measured in milliseconds.


An example is shown below.


The upload transfer time is simply a measure of how long on average its taking to perform the round trip between the agent and loading sub-system. The time includes not only the http communication time but the time to load into the repository.


The % of collection measures on average how long metrics are taking to collect as a percentage of their declared interval. For instance, if a metric takes 1 second to collect and its interval was to be collected every 30 seconds, then the percentage is 1/30 or about 3%. The rolled up number is computed across all metrics running and is re-evaluated by the agent every minute. The expectation is that the overall percentage will be low.If targets experience issues causing collections to take longer or the agent itself is not performing well, the expectation is that the percentage would increase.


Finally the heartbeat round trip is a measure similar to the upload in concept – a measurement of how long it's taking to send a certain amount of data; but given that these heartbeats (or pings) are typically constant in size, the measure is just the total round trip time.


If either the upload or ping times are increasing, then this could be an indicator of a network performance issue or the oracle management server itself experiencing some performance issue.


The second panel is the usage panel. It also contains 3 KPI's:

  • Number of requests made by the console of the agent (called Dispatched Actions) (this is the graphed data set)

  • Number of collections scheduled to be run for the next hour.

  • Number of jobs currently running on the agent


The usage panel reflects work being requested of the agent, either from console actions (real-time metric requests for example or jobs being submitted) as well as the work queue of the agent (i.e. the number of collections to be run for the next hour).


 


 

The final panel is the resource panel. There are 5 KPI's here:

  • percentage of the java heap in use (graphed)

  • approximate cpu usage (graphed)

  • current megabytes of the java heap in use

  • the maximum number of megabytes of the java heap used

  • a rolling load average of the cpu usage


First, let me explain the java heap statistics. The heap is sized to a specified maximum. The percentage of the heap used is a measure against that maximum. Current represents the current amount used and the maximum is the highest recorded value (not the absolute declared maximum). For instance, if the declared maximum is 100MB and the maximum ever observed is 80MB, then at some point in time 80% of the available heap was in use. Its fully expected that the percentage of the heap would follow the classic 'saw-tooth' pattern seen below.Java virtual machines allocate memory from the heap and then run garbage collection (GC) to free up space. If the trend line is flat, then no leaks would be evident. Its recommended that the maximum ever observed is no greater than 95% of the declared maximum, as that would potentially lead to either excessive GC or out of memory exceptions.


The cpu statistics are a representation of the current cpu being used and the 'load average' – a rolling weighted average of the last 15 minutes of cpu consumed.



My next blog will continue on the theme of using additional services to diagnosis current and/or potential issues with the agent.

About

Latest information and perspectives on Oracle Enterprise Manager.

Related Blogs




Search

Archives
« March 2012 »
SunMonTueWedThuFriSat
    
3
4
5
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
       
Today