With the latest release of Enterprise Manager 12c, Release 4 (12.1.0.4) the EM development team has added new functionality to assist the EM Administrator to monitor the health of the EM infrastructure. Taking feedback delivered from customers directly and through customer advisory boards some nice enhancements have been made to the “Manage Cloud Control” sections of the UI, commonly known in the EM community as “the MTM pages” (MTM stands for Monitor the Monitor). This part of the EM Cloud Control UI is viewed by many as the mission control for EM Administrators.
In this post we’ll highlight some of the new information that’s on display in these redesigned pages and explain how the information they present can help EM administrators identify potential bottlenecks or issues with the EM infrastructure. The first page we’ll take a look at is the newly designed Repository information page. You can get to this from the main Setup menu, through Manage Cloud Control, then Repository.
Once this page loads you’ll see the new layout that includes 3 tabs containing more drill-down information.
The Repository Tab
The first tab, Repository, gives you a series of 6 panels or regions on screen that display key information that the EM Administrator needs to review from time to time to ensure that their infrastructure is in good health.
Rather than go through every panel let’s call out a few and let you explore the others later yourself on your own EM site. Firstly, we have the Repository Details panel.
At a glance the EM Administrator can see the current version of the EM repository database and more critically, three important elements of information relating to availability and reliability :-
Is the database in Archive Log mode ?
Is the database using Flashback ?
When was the last database backup taken ?
In this test environment above the answers are not too worrying, however, Production environments should have at least Archivelog mode enabled, Flashback is a nice feature to enable prior to upgrades (for fast rollback) and all Production sites should have a backup. In this case the backup information in the Control file indicates there’s been no recorded backups taken.
The next region of interest to note on this page shows key information around the Repository configuration, specifically, the initialisation parameters (from the spfile).
If you’re storing your EM Repository in a Cluster Database you can view the parameters on each individual instance using the Instance Name drop-down selector in the top right of the region.
Additionally, you’ll note there is now a check performed on the active configuration to ensure that you’re using, at the very least, Oracle minimum recommended values. Should the values in your EM Repository not meet these requirements it will be flagged in this table with a red X for non-compliance. You can of-course change these values within EM by selecting the Database target and modifying the parameters in the spfile (and optionally, the run-time values if the parameter allows dynamic changes).
The last region to call out on this page before moving on is the new look Repository Scheduler Job Status region.
This region is an update of a similar region seen on previous releases of the MTM pages in Cloud Control but there’s some important new functionality that’s been added that customers have requested.
First-up - Restarting Repository Jobs. As you can see from the graphic, you can now optionally select a job (by selecting the row in the UI table element) and click on the Restart Job button to take care of any jobs which have stopped or stalled for any reason. Previously this needed to be done at the command line using EMDIAG or through a PL/SQL package invocation. You can now take care of this directly from within the UI.
Next, you’ll see that a feature has been added to allow the EM administrator to customise the run-time for some of the background jobs that run in the Repository. We heard from some customers that ensuring these jobs don’t clash with Production backups, etc is a key requirement. This new functionality allows you to select the pencil icon to edit the schedule time for these more resource intensive background jobs and modify the schedule to avoid clashes like this.
Moving onto the next tab, let’s select the Metrics tab.
The Metrics Tab
There’s some big changes here, this page contains new information regions that help the Administrator understand the direct impact the in-bound metric flows are having on the EM Repository. Many customers have provided feedback that they are in the dark about the impact of adding new targets or large numbers of new hosts or new target types into EM and the impact this has on the Repository. This page helps the EM Administrator get to grips with this. Let’s take a quick look at two regions on this page.
First-up there’s a bubble chart showing a comprehensive view of the top resource consumers of metric data, over the last 30 days, charted as the number of rows loaded against the number of collections for the metric. The size of the bubble indicates a relative volume. You can see from this example above that a quick glance shows that Host metrics are the largest inbound flow into the repository when measured by number of rows. Closely following behind this though are a large number of collections for Oracle Weblogic Server and Application Deployment. Taken together the Host Collections is around 0.7Mb of data. The total information collection for Weblogic Server and Application Deployments is 0.38Mb and 0.37Mb respectively.
If you want to get this information breakdown on the volume of data collected simply hover over the bubble in the chart and you’ll get a floating tooltip showing the information.
Clicking on any bubble in the chart takes you one level deeper into a drill-down of the Metric collection.
Doing this reveals the individual metric elements for these target types and again shows a representation of the relative cost - in terms of Number of Rows, Number of Collections and Storage cost of data for each Metric type.
Looking at another panel on this page we can see a different view on this data.
This view shows a view of the Top N metrics (the drop down allows you to select 10, 15 or 20) and sort them by volume of data. In the case above we can see the largest metric collection (by volume) in this case (over the last 30 days) is the information about OS Registered Software on a Host target.
Taken together, these two regions provide a powerful tool for the EM Administrator to understand the potential impact of any new targets that have been discovered and promoted into management by EM12c. It’s a great tool for identifying the cause of a sudden increase in Repository storage consumption or Redo log and Archive log generation.
Using the information on this page EM Administrators can take action to mitigate any load impact by deploying monitoring templates to the targets causing most load if appropriate.
The last tab we’ll look at on this page is the Schema tab.
The Schema Tab
Selecting this tab brings up a window onto the SYSMAN schema with a focus on Space usage in the EM Repository. Understanding what tablespaces are growing, at what rate, is essential information for the EM Administrator to stay on top of managing space allocations for the EM Repository so that it works as efficiently as possible and performs well for the users. Not least because ensuring storage is managed well ensures continued availability of EM for monitoring purposes.
The first region to highlight here shows the trend of space usage for the tablespaces in the EM Repository over time. You can see the upward trend here showing that storage in the EM Repository is being consumed on an upward trend over the last few days here. This is normal as this EM being used here is brand new with Agents being added daily to bring targets into monitoring. If your Enterprise Manager configuration has reached a steady state over a period of time where the number of new inbound targets is relatively small, the metric collection settings are fairly uniform and standardised (using Templates and Template Collections) you’re likely to see a trend of space allocation that plateau’s.
The table below the trend chart shows the Top 20 Tables/Indexes sorted descending by order of space consumed. You can switch the trend view chart and corresponding detail table by choosing a different tablespace in the EM Repository using the drop-down picker on the top right of this region.
The last region to highlight on this page is the region showing information about the Purge policies in effect in the EM Repository.
This information is useful to illustrate to EM Administrators the default purge policies in effect for the different categories of information available in the EM Repository. Of course, it’s also been a long requested feature to have the ability to modify these default retention periods. You can also do this using this screen. As there are interdependencies between some data elements you can’t modify retention policies on a feature by feature basis. Instead, retention policies take categories of information and bundles them together in Groups. Retention policies are modified at the Group Level. Understanding the impact of this really deserves a blog post all on it’s own as modifying these can have a significant impact on both the EM Repository’s storage footprint and it’s performance. For now, we’re just highlighting the features visibility on these new pages.
As a user of EM12c we hope the new features you see here address some of the feedback that’s been given on these pages over the past few releases. We’ll look out for any comments or feedback you have on these pages !
