Provisioning of an Oracle Database using EM 12c

In my previous post I described the creation of an Oracle Database. This procedure assumes the presence of both the Grid Infrastructure and Oracle Database software.

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

 

EM 12c is taking care of Group organization

An Administration Group can be seen as a “Dynamic” Group. Dynamic, because based on Membership Criteria assigned to the Administration Group, Targets will be assigned to the Group automatically on the moment they meet the Criteria.

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”.

Metric Extensions to replace User Defined Metrics

Metric Extensions

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!

Incident management, EM’s close encounter with ITIL

EM 11 and earlier releases provided us an alerting framework based on Metrics and Thresholds. EM 12c introduces a complete revised framework based on Incidents and Events.

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.

Continue reading

Why I think Out-of-Place Patching is a very nice new feature in EM 12c

When working with shared Oracle Homes you environment will look like this:

  • 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

Enterprise Manager Consolidation Planner

Again I will do my post in the form of a summary of features. Simply need some more time to revise these posts, so stay tuned. For now this is what I wanted to share with you guys.

Yes these are my notes in Stagato Style, sorry guys.

For planning the consolidation of multiple server to one server

Plans based on collected resource history data for a certain time interval

Cloud Consolidation Planning Workflow

  • Collect data from source servers
  • Select resources to be analyzed
  • Define constraints
  • Specify Target Servers
  • Review Consolidation Plan Results

User creates consolidation project and defines:

Type of consolidation P2P P2V

Source servers

After source data collection you can analyze the gathered data and resource usage trends.

Consolidation Analysis

  • Consolidation scenario specifies which metrics will be analyzed for the purpose of the consolidation exercise
  • Resource requirements fir each source server calculated
  • Each resource aggregated to 24-hour patterns based on specified formula
    • Conservative
    • Medium
    • Aggressive

Consolidation constraints

Use constraints to specify which server workloads can be placed together and which workloads must be kept apart for business or technical reasons

Consolidation planner uses SPECint data related to specific processor types

Policies for existing servers – Fewest Servers, Even distribution

Specify Maximum Resource Utilization % on Target Servers

Exadata Target Planning, to use Exadata as a Target platform

Server Mapping (the actual running of the consolidation)

Automatic Mapping of Source Servers onto Target Servers

Manual Mapping can be used on existing servers

Reporting

Consolidation scenario report available after running scenario

KEY BENEFITS

  • Identify under-utilized and over-utilized servers
  • Help admins determines candidates for consolidation
  • Work physical and virtual

METERING AND CHARGEBACK

  • Metering and Chargeback enable cloud consumers to take control of their costs
  • Cloud empowers end-users to provision resources onto shared infrastructure using self-service
  • Without chargeback there can be a perception that cloud resources are ‘ free’
  • Without metering charges will be flat regardless of usage

Chargeback – Key Concepts

  • Charge Item
    • Targets that are chargeable
    • Charge Plan
      • Defines the charge items and associated rates that will be used for charge calculations
      • Cost Center
        • Organization unit that will be charged for the costs
        • Reporting Cycle

Chargeback Workflow

Select targets for metering

Define charge plans

Define cost center hierarchy

Assign charge items to charge plan

Target metering dedicated and shared mode

Dedicated mode consumers using the target are from the same cost center

Shared mode: consumers using the target are from different cost centers

Setup charge Plan

  • Simplest way to leverage chargeback
  • Contains 3 universal charge items
    • CPU
    • Memory
    • Storage
    • Can be assigned to any type of supported chargeback target
    • Extended charge plan
      • Target specific charges
        • VM machine size
        • Database Option
        • Host OS
        • WebLogic User Requests
  • Supports fixed, configuration and usage based rates
  • Can leverage the universal plan with universal rate adjustment
  • Extended Plan conditions
    • Under specific conditions

Define Cost Centers

  • Used in aggregation in Charge reports
  • Import from LDAP option
    • OID
    • AD
    • Open LDAP
    • Novel EDirectory
    • SUN IPlanet
    • Default cost center sued for unassigned targets

Charge Plan and Cost Center Assignment

Chargeback admin uses target and plan assignment

Reports

  • Daily job calculates all charges for current reporting cycle
  • Ad-hoc reports available from chargeback reports tab
  • Chargeback tab in self-service portal provide summary
  • Trending shows charge and utilization trend over specific period
  • BI Publisher – Generate Reports in variety of formats
  • Email reports to recipients

Chargeback – MRB integration

Integrate with oracle billing and revenue management