Here is how to discover the EM 12c Repository Database

Discover EM12c Repository Database after Installation

The Provision Oracle Database Deployment Procedure takes care of all of this, so installing the Grid Infrastructure software and configuration, installing the Oracle Database software and the creation of the Database!

Provision Oracle Database using EM 12c

In the example I describe the creation of a Single Instance Database version 11.2.0.3, using the Grid Infrastructure.

Creating Oracle Database using EM 12c

I have been using the creation of a “Clusterware Clone” for the example, but creation of any other type will be a simular process.

Creating Golden Images in EM 12c Software Library

Configuring Oracle VM Manager in EM 12c

For instance, Administration Group “All Production Databases” would have automatically assigned a Database Target on the moment Target Property “Deployment Type” for this Database is set to “Production”.

In EM 11 (and earlier releases) we could use User Defined Metrics to extend the “out-of-box” monitoring capabilities. One of the drawbacks of User Defined Metrics in pre 12c releases is that they only applied to the Host and Database (Instance and Cluster Database) Target types.

EM 12c introduces Metric Extensions for the same goal, however supports any Target type.

Metric Extension Library

In EM 11 (and earlier releases) there isn’t a central location to store and maintain User Defined Metrics. A User Defined Metric could only be created as a Target related object, meaning you had to pick a certain Target (Host or Database) and create your UDM. Then by including your UDM in a Monitoring Template you would be able to deploy the UDM to other Targets.

By identifying one specific Host and one specific Database we would simulate a Library for our UDM’s. Normally this would be the OMS (Management Service) Server (or 1 of them when using multiple OMS’s) for Host UDM’’s and the OMR (Management Repository) Database Target for Database related UDM’s.

In EM 12c, a Metric Extension Library has been introduced for this purpose!

Events

An event is a single occurrence detected by EM and related to a single entity (well that is what the Administrator Guide tells us). Such a single entity could be: a Target, a Configuration File, a Job etc. Examples of an event include: Database Instance is down, Configuration File has been changed, Job executions ended in failure, Host exceeded a given percentage of CPU, Tablespace Space is exhausted etc.
No doubt this immediately makes the comparison with Metric Alerts in EM 11 (and before).

Incidents

When working in an IT environment that uses the ITIL (Information Technology Infrastructure Library) Best Practice processes and procedures, the term Incident does ring a bell doesn’t it? When searching for a definition of “Incidents” according ITIL in Wikipedia, you will find: “Incidents are the result of failures or errors in the IT infrastructure. The cause of Incidents may be apparent and the cause may be addressed without the need for further investigation, resulting in a repair, a Work-around or a request for change (RFC) to remove the error.”

EM 12c now allows us to make a definition of an Incident as a single or closely correlated set of events that identify a disturbance within our Data Center. So an Incident Definition might be as simple as the relation with a single Event “Available space in Tablespace has gone down a specified limit” or as more complex as an Incident “Server is running out of resources” that would be related to a set of Events relating to the usage of CPU, I/O and Memory Resources.

Integration with 3rd Party Helpdesk systems
Like we were used in EM 11 (and earlier release) EM 12c allows you to integrate with 3rd Party systems to for instance create a Ticket as result of an Incident occurrence.

Incident Rule Sets

As in EM 11 (and earlier) we used Notification Rules to initiate notification as a result of Alert creation for specific Events and specific Targets, EM 12c now provides us with Incident Rules and Incident Rule Sets to do so.

Incident Rules

Incident Rules actually perform the same role as Notification Rules

Incident Rule Sets

An Incident Rule Set allows you to combine multiple Incident Rules to a more extended control on Incident situations. As Incident Rules apply to objects like: databases, hosts, groups, jobs, web applications etc., by combining them in a Incident Rule Set you are able to take specific actions on a combination of objects and criteria.

Rules within a Rule Set can have a specific order in which each of them must be performed.

This example (based on an example in the Administrators Guide) shows the usage of Incident Rule Sets. The Set applies to a Group of Targets (of different types) and initiates multiple actions based on different criteria.

Out-of-Box Rule Sets

After installation of EM 12c the following “out-of-box” Rules Sets are available:

Incident Management Rule Sets for All Targets

• Incident creation Rule for target down.
• Incident creation Rule for target unreachable (for Agents and hosts).
• Incident creation Rule for metric alerts (for critical severity only).
• Out-of-box Incident creation rule for Service Level Agreement Alerts.
• Incident creation rule for compliance score violation
• Incident creation rule for high-availability events.
• Auto-clear Rule for metric alerts older than 7 days.
• Auto clear Rule for job status change terminal status events older than 7 days.
• Clear Application Dependency and Performance (ADP) alerts after without incidents after 7 days.

The Rules that are part of an Incident Rules Set are made out of two parts:

• Criteria
  The events/incidents/problems on which the Rule applies
• Action
  The Actions that should be performed in case the Criteria are met

The Administrators Guide gives some example Rule Set possibilities:
Rule Set:

• Applies to Target: Group Target G
• Rules in the Rule Set:
1. Rule(s) to create Incidents for specified Events
2. Rule(s) that send Notifications on the Incidents
3. Rule(s) that escalate Incidents based on some condition (e.g. length of time the Incident is open)

Rule Set (Details)
• Rule Set for Production Group G
• Target: Production Group G
• Rule 1: Create Incident for all Target down Events
• Rule 2: Create Incident for specific DB, Host or WLS Metric alert events of critical or warning severity
• Rule 3: Create Incident for any problem Job events
• Rule 4: For all critical Incidents, send page, for all warning Incidents send e-mail
• Rule 5: If Fatal Incident is op for more than 12 hours set escalation level to 1 and e-mail Manager

Event prioritizing

We all know that when using EM in a large IT landscape, having hundreds to thousands of targets, a heavy load of Incidents might be the result.

In such a case we would want to be able to prioritize. To allow such prioritizing EM 12c introduces: Target Life-cycle Status and Incident/Event Type.

Target Life-cycle

• Mission Critical (Highest priority)
• Production
• Stage
• Test
• Development (Lowest priority)

Incident/Event Type

• Availability (Highest priority)
• All Events/Incidents (Fatal severity)
• All Events/Incidents (Warning and Critical severity’s)
• All Events/Incidents (Informational) (Lowest priority)

I’ll be back….

See you next year at OOW 2012

• One ORACLE_HOME in which installed the most recent release of Oracle DB, for instance 11.2.0.2
• Several Database Instances running on the Oracle Software installed

If we want to apply a Patch to an environment like this we need to follow a scenario like this:

1. Download the Patch manually from MOS
2. Study the documentation
3. Check if the proper version of OPatch is available and upgrade if necessary
4. Clone the current ORACLE_HOME (you might be using a Golden Image in the EM Software Library for this)
5. Install the Patch on the cloned ORACLE_HOME
6. Stop database per database and copy necessary files (<oracle_home>/dbs/…)
7. Modify /etc/oratab to modify the path to the cloned ORACLE_HOME
8. Startup the database in the clone ORACLE_HOME
9. Execute necessary sql scripts

10. Check and document

Indeed an intensive and error prone scenario.

EM 10.2.0.5 and 11.1 provided us with a Patching procedure that was unable to cover this scenario.

EM 12c however now provide us with a procedure that takes care of this “Out-of-place” Patching procedure.

Starting with the support of Single Instances and RAC on Exadata, the support for RAC on clustered Servers is soon to follow (obviously as this is a more or less same procedure as the support for Exadata).

By this IT departments are able to perform a robust, complete patching procedure in which databases will be patched one by one with a minimum of down time.

Cheers