Sample Self-Study Course Enterprise...Narration Transcript for Oracle Enterprise Manager Cloud Control 12 c Sample Self-Study Course . ... Feel free to skip this slide and start the

Narration Transcript for

Oracle Enterprise Manager Cloud Control 12c

Sample Self-Study Course

Slide 1

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

<Insert Picture Here>

A sample excerpt from

Oracle Enterprise Manager Cloud Control 12c:

Enterprise Ready Framework

Hello, and welcome to this excerpt of the online self-paced course entitled Oracle Enterprise Manager Cloud Control 12c : Enterprise Ready Framework. My name is Jenny Tsai-Smith, and I am part of Oracle Corporation's Server Technologies Curriculum Development team. This course is a part of the Enterprise Manager Cloud Control 12c New Features Self-Study series. In this short excerpt from the course, I’ll be discussing new functionality related to incident management, and introduce you to a brand new feature called self update.

Slide 2


Using the Player

Course Outline

Player Controls

Attachments

Bookmark

Full Screen 2x

Using The Player Script Before we begin, now might be a good time to take a look at some of the features of this Flash-based course player. Feel free to skip this slide and start the lecture if you’ve attended similar Oracle eStudy courses in the past. To your left, you will find a hierarchical course outline. This course enables and even encourages you to go at your own pace, which means you are free to skip over topics you already feel confident on, or jump right to a feature that really interests you, or go back and review topics that were already covered. Simply click on a course section to expand its contents and then select an individual slide. However, note that by default we will automatically walk you through the entire course without requiring you to use the outline. To the right of the course outline tab is the transcripts tab, which contains any additional reference notes for the current slide. Feel free to read these reference notes at the conclusion of the course. Or if you prefer you can read them as we go along. The third tab in the left panel is where you can search for content in this course. Standard Flash player controls are also found at the bottom of the player, including pause, previous, and next buttons. There is also an interactive progress bar to fast

forward or rewind the current slide. Interactive slides may have additional controls and buttons along with instructions on how to use them. To the right of the standard Flash player controls is the Full Screen control. Click on it once to hide the course ouline panel, and click it again to maximize the course display. This may be useful when viewing videos and demos embedded in the course. Various handouts may be available from the Attachments button, including the audio narration scripts for this course. The course will now pause, so feel free to take some time and explore the interface. Then when you’re ready to continue, click the next button below or alternatively click the Lesson 1 slide in the course outline at left.

Slide 3

PROPERTIES

Allow user to leave interaction: After viewing all the steps

Show ‘Next Slide’ Button: Show upon completion

Completion Button Label: Next Slide

Let’s start off by looking at the objectives for this session. At the end of this course, you should be able to: • Describe the use of events, incidents and problems in Enterprise Manager Cloud Control 12c • Access Incident Manager to manage events, incidents, and problems • Understand the purpose of incident rule sets • Explain how notification rules from previous releases are migrated to rule sets • Understand the user requirements that have driven the design of the self update functionality • Describe the self update functionality in the 12.1 release • List the user profiles that are involved in the self update process • Explain the workflows that are used in self update This course is meant for: Experienced Enterprise Manager Grid Control 11g users Prerequisite skills include: Using Enterprise Manager Grid Control 11g

Slide 4


Enterprise Manager 12c Major Themes

ApplicationsManagement

Enterprise Ready Framework

Cloud Management

Chargeback and Capacity Planning

Middleware Management

Database Management

Application Quality

Management

Configuration Management

Exadata and Exalogic

Management

Provisioning and Patching

Before we drill into the details of incident management, let’s look at the major themes of Enterprise Manager Cloud Control 12c. The 12c release is designed around 3 major objectives – the creation of a next generation management framework, the enhancement of application-to-disk management, and the provision of complete lifecycle management for enterprise private cloud solutions. These objectives are further subdivided into the major themes you see displayed here, and these also form the module breakdown in this Enterprise Manager Cloud Control 12c New Features Self-Study Series. Incident management is part of the Enterprise Ready Framework area, so let’s look at incident management now in more detail.

Slide 5


Road Map

• Incident Management

– Key Concepts

– Incident Manager

– Recommendations

– Backward Compatibility

• Self Update

First, we’re going to spend some time describing the use of events, incidents and problems to monitor and resolve service disruptions in Enterprise Manager Cloud Control 12c. Next, we’ll look at how you access the Incident Manager user interface and use this UI to manage events, incidents and problems. Then we’ll examine the functionality of incident rule sets, and finally we’ll explain how notification rules from earlier releases of Enterprise Manager are migrated to incident rule sets in this release.

Slide 6


Introduction to Incident Management

• Monitor and resolve service disruptions quickly and

efficiently

• Instead of managing numerous discrete events,

manage fewer, meaningful incidents:

– By business priority

– Across their lifecycle

• Centralized incident console for incident

management

• Identify, resolve and eliminate root causes of

disruptions

• Integrated Oracle expertise to accelerate incident and

problem diagnosis and resolution

• Support for incident lifecycle operations

– Assign, acknowledge, prioritize, track status, escalate, suppress

The goal of incident management is to enable administrators to monitor and resolve service disruptions that may be occurring in their data center as quickly and efficiently as possible. Instead of managing the numerous discrete events that may be raised as the result of any of these service disruptions, we want to manage a smaller number of more meaningful incidents, and to manage them based on business priority across the lifecycle of those incidents. To do this, we provide a centralized incident console called Incident Manager that will enable the administrator to track, diagnose, and resolve these incidents, as well as providing features to help eliminate the root causes of recurrent incidents. Incident Manager also includes features to tie in to Oracle expertise via relevant My Oracle Support knowledge base articles and documentation to enable administrators to accelerate the process of diagnosing and resolving incidents and problems. Finally, Incident Manager also offers the ability to do lifecycle operations for incidents, so you can assign ownership of an incident to a specific user, acknowledge an incident, set priority for an incident, track an incident’s status, escalate an incident or suppress it so you can defer it to a later time. You can also raise notifications on an incident or open a helpdesk ticket via the helpdesk connectors.

Slide 7


Events and Incidents

Performance Space Target Down

Metric

Alerts

Job

Events

Standards

Violations

Availability

EventsOther

Events

Events

Incidents

• Manage by incidents

– Significant events

– Combination of events

related to the same

issue (e.g., events

raised from database,

host, storage indicating

lack of space)

EM Admin

Let’s take a look at events and incidents in more detail. Enterprise Manager continues to be the primary tool for managing and monitoring the Oracle data center, so it manages and monitors Oracle applications as well as the application stack from application servers to databases to hosts and the operating system. When Enterprise Manager detects issues in any of this infrastructure, it raises events. The events might be • Metric alerts (for example, CPU utilization or tablespace usage alerts) where a

critical threshold you set has been crossed • Job events – this could be caused by using the job system and there’s a failure in

the job. An event is then raised to signal the failure of that particular job. • Standards violations – if you are using compliance standards and any of the targets

that are being monitored violate any of the compliance standards, then a standards violation event could be raised.

• Availability events – if a target is down and Enterprise Manager detects that, an availability event that the target is down can be raised

• Other events – there are other types of events that occur as well All these events signal particular issues have occurred in the Oracle data center. Across all these events, you really want to be able to determine which of these events are significant and, from these significant events, be able to correlate events that are related to the same underlying issue. At the end of the day what you as an administrator want to manage is a smaller number of significant incidents. You may

have a performance incident that amalgamates a number of performance events, another incident related to space, and a different incident based on availability problems. The goal for incident management is therefore to not manage by individual numerous events but the smaller set of more meaningful incidents. An incident could then be a significant event (such as a target being down, for example) or it could be a combination of events that all relate to the same issue (for example, running out of space could be detected by Enterprise Manager as separate events raised from the database, host and storage target types)

Slide 8

PROPERTIES

Allow user to leave interaction: Anytime

Show ‘Next Slide’ Button: Show always


Events are significant occurrences in your IT infrastructure and that Enterprise Manager detects and raises. Each event has the set of attributes you see here – what type of event it is, the severity (fatal, critical and so on), the object or entity on which the event is raised (typically a target but it can also be a job or some other object), the message associated with the event, the timestamp at which it occurred, as well as the functional category (such as availability, security etc.) Here are some examples of the different types of events. Target availability is the event raised when a target is down or has gone into an agent unreachable state. Metric alert events are raised when a metric crosses its threshold. A job status change event is raised, for example, when a job fails. When there is a violation of a compliance standard, you can have a compliance standard violation event being raised. If there is an error with the evaluation of a metric, the metric evaluation error event type is raised. Other events such as SLA Alert, High Availability and Connector External Class can also be raised, and of course, users can define their own event types and cause an event to be raised. Associated with these event types are event severities. The first of these, “Fatal”, is a new severity level in Enterprise Manager specifically associated with the target availability event type for when the target is down. Critical and warning events have the same meaning as they had in previous releases, and then we have the Advisory level. Typically, this is associated with compliance standard violation events. The

informational level is an event severity used to indicate simply that an event has occurred, but there is no need to do anything about it.

Slide 9


EventDB1 is down

Time: 3-10-11, 8:54 am

Severity: Fatal

Incident

Incident With a Single Event

Manage

and Track

Resolution

Details of …

[Availability

event]

Incident

Owner: Scott

Status: Work in Progress

Severity: Fatal

Priority: High

Comment: I’m working on it

As we discussed previously, an incident can contain one or more events. Let’s look at the details of an incident with one event. For example, this event is an availability event. The event signals that the database DB1 is down and includes a timestamp of when the event was raised. Because this is a target availability event and the database is down, the severity is marked as Fatal. An incident can be created for that event, so the incident contains only one event. In order to manage and track the resolution of the incident, the incident has other attributes such as owner (the Enterprise Manager user that is working on the incident), status, incident severity (which is based on the event severity), priority and a comment field.

Slide 10


Event Event

MEMORY Util is 85% on host1

Time: 3-10-11, 11:54 am

Severity: Warning

CPU Util is 99% on host1

Time: 3-10-11, 12:03 pm

Severity: Critical

Incident

Incident with Multiple Events

Manage

and Track

Resolution

Details of …

[Metric Alert

event]

Incident

Owner: SAM

Status: New

Severity: Critical

Summary: Machine Load is high

Owner: HELPDESK

Status: New

Severity: Critical

Summary: Machine Load is high

Ticket : 12345 (Assigned)

HelpdeskIncident integrated with

helpdesk ticket

Incidents can also contain multiple events, where those events are related and pointed to the same underlying cause. In the example shown here, we have two metric alert events on a host target – a memory utilization metric alert event and a CPU utilization metric alert event because the host is starting to suffer from heavy load. We have a warning severity memory utilization metric alert event, and a short time later a critical severity CPU utilization metric alert event. An incident can be created containing both events in order to manage and track the resolution of the incident. Again, we have additional attributes associated with the incident like we had in the previous example. Enterprise Manager automatically assigns the incident severity, based on the worst case event severity of all the events contained in the incident. Since the worst event severity is Critical, the incident severity is also set to Critical. Finally, the incident has a summary which is a short description of what the incident is about. The individual events are indicating the machine load is high so you can set the summary to that. Alternatively, you can set the incident summary to be the same as the event messages as the incident summary. If you are using one of the helpdesk connectors to interface to a helpdesk system, an incident might also result in a helpdesk ticket which can allow the helpdesk analyst to work on the ticket. Within Enterprise Manager, we’ll be able to track both the ticket number and the status of that particular ticket

Slide 11


What are Problems?

• Underlying root cause of incidents

• Facilitate resolution of Oracle

software ‘problems’

1. Auto-creation of problem based

on ADR incidents

2. Package diagnostic data

3. Open Oracle SR

Enterprise Manager

Problem

Oracle Service

Request

A problem is the underlying root cause of an incident. In Enterprise Manager terms, a problem is specifically related to an Automatic Diagnostic Repository (ADR) incident or Oracle software incident. Enterprise Manager will automatically create a problem whenever it detects an ADR incident has been raised. An ADR incident can be thought of as a critical Oracle software problem where the resolution of the software problem typically involves contacting Oracle Support, opening a service request and possibly receiving a patch for that problem.

Slide 12


Relationship of Incidents and Problems

• As with Incidents, you can manage Problems in

Incident Manager:

– Track status (assign ownership, etc.)

– View diagnostic information (via Support

Workbench)

– Open service request (via Support Workbench)

– Status of diagnostic activity visible in UI:

– Diagnostic data packaged (yes/no)

– SR #

– Bug #

Incident Problem

Whenever an ADR incident is raised, one incident is generated in Enterprise Manager for that ADR incident. A problem object is also automatically generated. All the ADR incidents that have the same problem signature (that is, the same root cause) will be linked into a single problem object. You can manage the problem in Incident Manager in the same way as you would manage an incident, so you can assign an owner to the problem, track the resolution and so on. In addition, there are in-context links to Support Workbench functionality which allows the administrator to package the diagnostic material, open a service request and view the status of diagnostic activity such as the SR number and ultimately bug number (if one is generated) within the user interface.

Slide 13


Incident Incident

ORA-600[ktcrcm…] on DB1

Time: 3-12-11, 7:03 am

Severity: Critical

ORA-600[ktcrcm…] on DB1

Time: 3-12-11, 8:03 am

Severity: Critical

Problem

Example of a Problem with 2 Incidents

Manage

and Track

Resolution

Owner: MARY

Status: New

Severity: Critical

Summary: Problem: ORA-600…

SR Number : ####

My Oracle

Support

ADR

Incidents

Problem

Here’s a diagrammatic example of how incidents and problems are related. Two ADR incidents have occurred. They are ORA-600 errors in a database. Both of these incidents are of critical severity. Enterprise Manager Cloud Control automatically creates a problem object containing those incidents. Using the Incident Manager, a graphical console within Oracle Enterprise Manager Cloud Control 12c , you can link to the Support Workbench to open a service request. The service request can also be tracked in the Incident Manager.

Slide 14


Incident Manager

Next, let's watch three brief demonstrations on using the Incident Manager for managing and tracking incidents and problems.

Slide 15

PROPERTIES




Slide 16

PROPERTIES




Slide 17

PROPERTIES




Slide 18


Introduction to Incident Rule Sets

• Replace notification rules

• Automate actions related to

events, incidents, problems

– Creation of incident based on

an event

– Notification actions (including

ticketing)

– Operations to manage

incident workflow

Page

Execute Rules

Create

Incident,

Assign

ownerEmail

Let’s move on and talk about incident rule sets. Incident rule sets are the replacement of and an enhancement to notification rules. They are a way to automate actions related to events, incidents or problems. Some of the common scenarios or use cases for incident rule sets include creating an incident based on an event, send notifications such as emails or pages as well as opening helpdesk tickets, or automate incident workflow actions, such as automatically assign the owner of an incident or escalating an incident after it has been open for some time).

Slide 19

PROPERTIES




What are Rule Sets? A rule set is defined as a set of one or more rules that are applied to a common set of objects such as targets (including groups) or jobs. Within a group, you can specify a set of heterogeneous targets (that is, a group of different target types) for a rule set to be applied to. The idea of a rule set is to enable you to logically combine different rules that relate to the same object into a single manageable unit. This is one of the enhancement requests that we have heard many times for notification rules in earlier releases, where administrators have often created multiple notification rules based on the target type that at the end of the day operate on the same group. Logically combining these rules into one unit is a natural progression from the earlier functionality to make it easier to track and manage these multiple rules. The rules within a particular rule set are executed in a specific order. By default, the rules are executed in the order they are created, but you can change that at any time. The rule sets themselves can also be executed in a specific order. Again, by default this is the order in which the rule sets are created, but that can be changed as well. There are some out-of-the-box rule sets that are provided with Enterprise Manager Cloud Control 12.1 that automatically create incidents for what Oracle Corporation believes are meaningful events as well as automating event deletion. You can use these rule sets as is, but you can’t edit them. You can, however, create your own

versions using Create Like functionality, and the originals can be disabled if they do not meet your requirements. There are two types of incident rule sets in Enterprise Manager Cloud Control 12.1 – one is an enterprise rule set and the other is a private rule set. An enterprise rule set is meant to be used to implement your operational practices when it comes to managing events and incidents. All the actions we discussed earlier, such as creating an incident, sending a notification, and opening a ticket, are supported within an enterprise rule set type. Since these are actions that affect all types of incidents and problems, the user that creates these rule sets requires the “Rule Set” resource privilege. Once an enterprise type rule set is created, it is visible to all Enterprise Manager users. When you create a rule set, further development of that rule set can be done in a collaborative manner, so each rule set can basically have multiple authors (that is, multiple Enterprise Manager users) that can edit that particular rule set. A private rule set, on the other hand, is designed only to send email notifications to yourself. As a result, there are no special privileges that are required to create a private rule set. What are Rules? Rules are part of rule sets. A rule is basically an instruction to Enterprise Manager Cloud Control that give instructions on how to automate actions when an event, incident or problem occurs. Rules do not operate retroactively, so a rule only operates on events, incidents or problems that occur after the rule is created. A rule consists of two parts – the criteria part and the action part. The criteria area is where you specify the events, incidents or problems that the rule applies to. The action tells Enterprise Manager Cloud Control what operations you want it to perform on those specified events, incidents or problems. Each operation in turn can have some additional conditions. Let’s look at a couple of examples of how this works: • If the rule criteria is a specific metric alert (for example, CPU utilization or tablespace

percent used crosses a certain threshold of either warning or critical severity), the action could be create an incident.

• Another rule could operate on incidents that are of either warning or critical severity, and the action is to send a notification. In this case, there could be an additional condition that if the rule condition is severity=critical then the action is notify by page, while if the severity=warning the action is notify by email.

• Another example of a rule might be for incidents that have been open longer than 7 days, where the rule action is to set the escalation level to 1.

Example of a Rule Set: Let’s now look at an example of a rule set. In this example, I have an enterprise rule

set that operates on my Production group, PROD-GROUP. This heterogeneous group consists of a set of targets that includes hosts, databases and WebLogic servers. In this rule set, there are two rules. The first is a target down rule where

the criteria for the rule are any database or WebLogic servers that are down. In this case, the action is to automatically create an incident and set its priority to high. The second rule within this rule set has to do with the sending of notifications. The criteria for this rule are for any incident on the targets within PROD-GROUP that has a severity of Fatal, Critical, or Warning. The actions here are the sending of an email only if the severity is set to Warning, or to send a page if the severity is set to either Fatal or Critical.

Slide 20

PROPERTIES




In terms of recommendations for rule sets, let’s start off with some more general recommendations. Firstly, it is strongly recommended to use a group as the target for a rule set. Once you use a group as the target for a rule set, you want to put together all the rules that pertain to members of that group in the same rule set. Then as much as possible, take advantage of the fact that you can control the execution order of the rules within the rule set. When you create a rule in a rule set within Enterprise Manager Cloud Control, you’ll notice there are three different types of rules so now let’s look at more specific recommendations on how you would use these different types of rules. For rules that operate on events, the use case is to create incidents for the alerts or events that are managed in Enterprise Manager. If you want to use a ticketing connector in Enterprise Manager to create tickets for these incidents, then use rules on events to do so by using the rule actions to first create an incident on the event and then create a ticket for the incident. Another use case for rules on events would be to simply send events to third party management systems using event connectors. The final scenario would be to only send notifications on events rather than creating incidents, as you could in earlier releases. For rules that operate on incidents, one of the primary use cases is to automate operations that pertain to incident workflow, such as automatically assign owners to incidents, set priority for an incident or set its escalation level, or to send notifications for

incidents. You can also as another use case create tickets based on incident conditions, such as creating a ticket when an incident is escalated to level 2. Rules are used on problems to automate the management of problem workflows in much the same way to incidents, such as automatically assign owners to problems, set priority for an problem or set its escalation level, or to send notifications for problems.

Slide 21

PROPERTIES




In certain scenarios, your Enterprise Manager Cloud Control site might be under heavy load. In these scenarios, we want to be able to process the more important events and incidents ahead of others. There are two factors that are taken into account when determining the processing priority. The first is the lifecycle status of the target, with the priority based on the order shown here where Mission Critical targets have the highest priority and Development targets have the lowest. As an administrator, one of the responsibilities you have is to set the lifecycle status of each target appropriately. The statuses shown here are the ones shipped out-of-the-box with the product. The second factor is the type of event or incident. Any events or incidents that have to do with availability such as target down are always set as highest priority. Next, any events or incidents that are for critical or warning severities are handled, and finally any events that are informational only are treated as the lowest priority. This prioritization is only taken into account when the system is under heavy load. When the system is under normal load, events and incidents are handled as they arrive.

Slide 22


Backward Compatibility

• Existing notification methods (PL/SQL, OS scripts,

SNMP traps) will continue to work in Enterprise

Manager Cloud Control 12.1

• To leverage new features, create new versions of these

notification methods

– Use new event model

• Existing notification rules will be migrated to incident

rule sets

As far as backward compatibility is concerned, when you migrate from earlier releases to Enterprise Manager Cloud Control 12.1, backward compatibility for notifications is provided. If you have created any notifications based on PL/SQL, operating system scripts or SNMP traps, these notification methods will be migrated and continue to work in Enterprise Manager Cloud Control 12.1. However, we do encourage you to create new versions of these notification methods using the new event model so you can leverage the new features we have been discussing. If you have created notification rules in earlier releases, we will migrate those to incident rule sets in the new release.

Slide 23


Notification Rule - Incident Rule Set Mapping

11.1 Notification Rule

Notification Rule : Rule for PROD-GROUP

Applies to: PROD-GROUP

Target Type: DB

Availability tab

Criteria: DB down

Action: email user1 and user2

Metrics tab

Criteria: Selected metrics, severities

12.1 Incident Rule set

Event Rule#1: “Target Availability” rule

Criteria: Event Type = Target Availability

Target Type = “DB”

Target Status = “Down”

Action: email user1 and user2 and

Create Incident

Event Rule#2: “Metric Alert” rule

Criteria: Event Type = Metric Alert

Target Type = “DB”

Metric Alert specific criteria

Action: email user1 and user2 and

Create Incident

Rule Set: Rule for PROD-GROUP

Applies to: PROD-GROUP

Type: Enterprise

Let’s look at an example of how this notification rule to incident rule set mapping is done. In the example shown here, we have an Enterprise Manager 11.1 notification rule that applies to my group PROD-GROUP and the database target in that group. If you’re familiar with notification rules in the earlier release, you’ll be aware of the tabs in the notification rule setup. In our example, on the availability tab we have the criteria of database down chosen, while on the metric tabs we have selected metrics of interest and their severity. Finally, the action is set to email two users, user 1 and user 2. When this is migrated to an incident rule set in Enterprise Manager Cloud Control 12.1, the rule set is applied to the same target (the group PROD-GROUP) and it will be of type Enterprise. An event rule will be created in the rule set to cover the criteria for the target availability specified in the notification rule. In the notification rule, the criteria are database down. In the incident rule set that translates to criteria where the event type is target availability, the target type is database and the target status is down, and because the action in the notification rule is to email the users we carry that action over into the incident rule set as well. In addition, we will create an incident object for this particular event. For the metrics you may have selected on the metrics tab in your notification rule, we create a metric alert rule where the criteria is event type being metric alert, target type is database and specific criteria are set for the metric alerts as well. The action here again is carried over to email the users, and in addition we create an incident for this event.

Slide 24

PROPERTIES

On passing, 'Finish' button: Goes to Next Slide

On failing, 'Finish' button: Goes to Next Slide

Allow user to leave quiz: After user has completed quiz

Slide 25


Road Map


• Self Update

– Key Concepts

– Self Update Home Page

– Self Update Workflow

Next, we’ll examine the user requirements that have driven the design of the self update functionality. Next, we’ll describe the self update functionality, looking at the concepts behind self update and the user interface that implements it. Then we’ll look at the user profiles that are involved in the self update process, before finally explaining the workflows that are used in self update.

Slide 26

PROPERTIES




Self update is a unified delivery mechanism for different entity types (what these types are we will cover shortly), which delivers both updates to existing functionality as well as new functionality in Oracle Enterprise Manager Cloud Control 12c. Let’s start by looking at the user requirements for self update. The first thing that users have asked for is a way for Oracle to deliver updates to existing features as well as new features, even after the product has been shipped. There has always been a lag between Enterprise Manager releases and new product releases. For example when Oracle Database 11.2.0.2 was released, there was a gap before the new version of Enterprise Manager became available to provide support for this release. There was a need for this to become much more seamless and quicker. The second requirement was for an easy, standardized mechanism of deploying third party and custom built updates. A good example of this is plug-ins. There are many partner built plug-ins, as well as those built by customers. The third requirement was for a way to transfer entities from one Enterprise Manager deployment to another. Many of our customers have multiple Enterprise Manager deployments, so transferring objects between those is a key requirement.

Finally, since we are dealing with a lot of entities in Enterprise Manager, we need to have a centralized location for maintaining history and inventory of all these updates. After reviewing these user requirements, Oracle has introduced new functionality in this release of Enterprise Manager called self update. Self update is a unified delivery mechanism for different entity types (what these types are we will cover shortly), which delivers both updates to existing functionality as well as new functionality. It provides common workflows that allow administrators to receive notification about updates to existing functionality, to view information about the new update functionality, and then choose to download and apply these updates to self update entities. Both online and offline modes are supported, so these updates can be applied through an active Internet connection to My Oracle Support (MOS), or via a staging area when there is no active Internet connection to MOS. We allow the updating of non-Oracle entities such as third party plug-ins, and finally we maintain inventory and history for all updates that have been downloaded or applied.

Slide 27


Self Update Home

• Central console to manage self update entities

– Check for updates

– View updates

– Download updates (immediately or scheduled)

– Apply updates

– Remove updates

– Export updates

• Guided workflow for online / offline modes

Accessing the self update feature is done via the Self Update Home page. All of the functionality we just discussed is available through this interface. It allows you to check for updates, view details about update so you can decide if you want the update or not, download the available updates (either immediately or at some later scheduled time), apply the updates to the self update entities, remove existing installed updates, or export updates if required. Guided workflows are available for both online and offline modes of self update (we’ll cover these in more detail later in this module).

Slide 28


Menu Navigation and Permissions

• Accessible only to

‘Super Administrator’

users

• Menu option hidden

from other users

Access to the self update home page is provided through the Setup menu, once you are logged into Enterprise Manager. The menu option appears under the Extensibility option, but only for users that have the super administrator privilege. For other users, the self update menu option is not available.

Slide 29


Self Update Home Page

The self update home page looks like the screenshot you are currently viewing. The first point to note on this screen is the status area. This will tell you the connection mode (whether you are in online or offline mode), as well as details such as when was the last successful refresh time, last download time and entity type downloaded, and last apply time and entity type applied. If you are in online mode, self update automatically checks for new updates, but you also have the Check Updates button to manually check for new updates since the last automatic refresh. The middle of the screen gives you more details on all the entity types we have been discussing, including the number of available, downloaded and applied updates, while the bottom part of the screen is in master detail form. What that means is that if I select the entity type “Plug-in”, the bottom part of the screen shows me more information on activity details for all the plug-ins that have been downloaded or applied via self update.

Slide 30


Self Update Entity Types

The different entity types that we support in this release of Enterprise Manager Cloud Control 12.1 are shown here. Enterprise Manager supports multiple platforms, and each platform has its own agent code. The self update functionality provides a unified way of downloading the agent software for each platform, both 32 bit and 64 bit. This provides a single location from which you can download all these different versions of the agent code. Similarly, you can download profiles and gold images for both middleware and database provisioning. You can also download compliance content (new definitions for compliance frameworks like SOX), as well as diagnostic checks and Enterprise Manager deployment pre-requisite checks. In addition, you can of course download new updates for management connectors and plug-ins that have been built by Oracle Corporation. Finally, if you use the provisioning feature in Enterprise Manager, there is a new entity called a provisioning bundle that can provide updates for database provisioning and patching deployment procedures. The entity types shown are the entities supported in the first release of self update; as we go forward with new releases, more and more entities will be supported with self update.

Slide 31


Self Update Entity Details

Once I have select an entity type (in this case the plug-in example I used on the previous screenshot), I get to the entity details page where I get to see specific details about what is available or applied. In the example shown here, you can see that mostly plug-ins from Oracle Corporation are listed. Some of these plug-ins have already been applied. If I wanted to apply the first entry which is still in the downloaded state, once I have selected it, I can then click on the highlighted Deploy On button to deploy the entity to the management server. Again, the lower half of the screen shows more details for the entity I have chosen.

Slide 32


Inventory and History

• All inventory and history stored in repository

• History includes actions like available, download and

apply

• Updates are tracked irrespective of their origin – EM

Store, out of box, third party

The lower section of both the self update screens has a dedicated section for recent activities which shows the inventory and history information stored in the repository. The history includes the different states that the updates go through - available, download and apply. As you can see from the screenshot, you can see the action for the update, its status (success or failure), the entity name, platform, and a number of attributes for that update like the version number. Irrespective of the origin of the update (i.e. third party, out of the box and so on), updates are all tracked through this mechanism.

Slide 33


Import / Export

• Import

– For third party updates

– EDK to create update archives

– Import using EMCLI verb

$ emcli import_update

• Export

– Any update in download or apply state can be exported

– Exported update can be imported into another site

– Export using EMCLI verb

$ emcli export_update

Import and export for self updates are supported by the command line interface for Enterprise Manager, EMCLI. You can import third party entities or any custom created entity using the “emcli import_update” command. Similarly, you can use the “emcli export_update” command to choose any entity that is visible in self update and export it. The import mechanism is also used in offline mode. We’ll see more details of that coming up soon.

Slide 34


User Profiles

• Self Update Publisher (At Oracle)

– Supplies the entity type definition

– Registers the definition with Self Update

– Publishes self update entities to EM Store

– Currently this is Oracle development team

• Site Administrator (At Customer)

– Sets up Enterprise Manager Cloud Control

– Maintains the Cloud Control infrastructure

– Manages Enterprise Manager users

• Functional Expert (Super User At Customer)

– Sets up Self Update

– Reviews, downloads and applies self update entities

from the Self Update Home page

There are three different user profiles that are involved in self update functionality. The first user is the self update publisher which currently is someone in the development or release management team at Oracle Corporation. This user is responsible for publishing the entity, so they supply the entity type definition, register that definition with self update, and then publish the update on the Enterprise Manager store (the automatic download location). The second user is the site administrator. The site administrator is responsible for setting up Enterprise Manager Cloud Control, including maintaining the infrastructure and managing the different users defined in Enterprise Manager. This is not a new role like the others. The third user is the functional expert at the customer site. This is a super user kind of account that sets up the self update functionality and then has responsibility for reviewing, downloading and applying self update entities from the self update home page.

Slide 35

PROPERTIES




Now that we’ve defined the different users that are involved, let’s look at how they interact as part of the workflows for self update. Firstly, a user at Oracle Corporation publishes self update entities. This user publishes both the archive (which is the payload or content) and the manifest (which contains metadata about what’s in the archive). Both these parts of the self update entity are published to what we are calling the Enterprise Manager Store, which is a repository for self update entities hosted at Oracle. At the customer site, we have a daily job called “Refresh from EM Store” which automatically checks for and downloads new manifest files from the EM store. Alternatively, the functional expert user can click a Check Updates button from the console to retrieve new manifests. In either case, these manifests are stored locally at the customer site. From the local store, the manifests are loaded into the Enterprise Manager repository. At this point, we have certain rules, checks and balances built into the Self Update engine which processes the manifests for applicability for this installation (these rules are defined as part of the setup for self update at the site). The data is massaged and if it is applicable a message is sent to the functional experts for the site to notify them that a new update is available.

Finally, looking at the end user interaction, the functional expert reviews these updates on the update console. If they decide the update is applicable for their site, they trigger the actual download from the EM store, which in turn results in the archive being downloaded to the local store which in this case is the software library (note the earlier download was for the metadata or manifest only). The last step is to trigger the actual apply of the self update entity. This is the step where new functionality finally becomes available at your site.

Slide 36


Online and Offline Modes

Operation Online Mode Offline Mode

Download

Catalog

• Automatic download of

catalog every day

• On demand download of

catalog

1. Download master catalog from My

Oracle Support (MOS)

2. Place catalog on OMS or on any

managed host (i.e. with Agent)

3. Import into EM using EMCLI

Review Review list of updates

Download

Archive

Download update archive 1. Download update archive from MOS

2. Place archive on OMS or on any

managed host (i.e. with Agent)

3. Import into EM using EMCLI

Apply Apply Update

Note: Each update has its own apply mechanism

Earlier we mentioned that we support both online and offline modes for self update. The workflows we have just covered are the online mode which is all driven from the self update console. For some sites, their installations are secured in such a way as to not have access to the EM store. In that case, the self update functionality needs to be used in offline mode and the process is a little more involved as it requires you to download the master catalog (the collection of all the manifests) from My Oracle Support. The master catalog can be loaded either on the OMS or any other managed host (that is, any host with an agent installed), from where it can be imported into Enterprise Manager using EMCLI as discussed earlier. The functional expert then reviews the updates, and needs to download the archives for the updates they want to apply, and also load these via EMCLI. Coming up next is a short demonstration of using Self Update in online mode.

Slide 37

PROPERTIES




Slide 38

PROPERTIES

On passing, 'Finish' button: Goes to Next Slide

On failing, 'Finish' button: Goes to Next Slide

Allow user to leave quiz: After user has completed quiz

Slide 39


Course Review

In this course, we talked about some of the new features

and enhancements in Enterprise Manager 12c:


– Use Incident Manager to effectively manage and track incidents

and problems

– Implement incident rule sets to automate notifications and

actions

– Map notification rules to incident rules and rule sets

• Self Update

– Use Self Update Home Page to view and track update inventory

and history

– Use Self Update workflow in online mode

– Use EMCLI to import Self Update catalogs in offline mode

In this course, we talked about some of the new features and enhancements in Enterprise Manager 12c: Incident Management Use Incident Manager to effectively manage and track incidents and problems Implement incident rule sets to automate notifications and actions Map notification rules to incident rules and rule sets

Self Update Use Self Update Home Page to view and track update inventory and history Use Self Update workflow in online mode Use EMCLI to import Self Update catalogs in offline mode

Slide 40

PROPERTIES




Oracle Enterprise Manager Cloud Control 12c Self-Study training is aimed specifically at administrators who are familiar with the current releases of Enterprise Manager. It is designed to bring existing users up to speed on the new features of Oracle Enterprise Manager Cloud Control 12c.

The series is broken into a number of tracks, each based around one of the major themes of the new release, and is available from

• Oracle University • Oracle Enterprise Manager 12c: Introduction • Oracle Enterprise Manager 12c: Enterprise Ready Framework • Oracle Enterprise Manager 12c: Database Managementl • Oracle Enterprise Manager 12c: Configuration Management • Oracle Enterprise Manager 12c: Provisioning and Patching • Oracle Enterprise Manager 12c: Application Quality Management • Oracle Enterprise Manager 12c: Middleware Management Several instructor-led courses are also included in the Oracle Enterprise Manager Cloud Control 12c curriculum, available through Oracle University:

• Using Oracle Enterprise Manager Cloud Control 12c • Oracle Enterprise Manager Cloud Control 12c: Install and Upgrade

The Oracle Learning Library offers many free demonstrations and tutorials. Of course, the Oracle Enterprise Manager Cloud Control 12c documentation and online help embedded within the product are also valuable resources.

Documents

Sample Self-Study Course Enterprise...Narration Transcript for Oracle Enterprise Manager Cloud Control 12 c Sample Self-Study Course . ... Feel free to skip this slide and start the