SQL Tutorial

Oracle Internal & Oracle Academy Use Only
Oracle Enterprise Manager

Cloud Control 12c: Install &
Upgrade
Student Guide
D73067GC11
Edition 1.1
November 2012
D79616
Authors Copyright © 2012, Oracle and/or its affiliates. All rights reserved.
Veerabhadra Rao Putrevu Disclaimer
Lachlan Williams This document contains proprietary information and is protected by copyright and
other intellectual property laws. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modified or altered
Technical Contributors in any way. Except where your use constitutes "fair use" under copyright law, you
and Reviewers may not use, share, download, upload, copy, print, display, perform, reproduce,
publish, license, post, transmit, or distribute this document in whole or in part without
Jeff Anderson the express authorization of Oracle.
Adam Crosby
The information contained in this document is subject to change without notice. If you
Akanksha Sheoran Kaler find any problems in the document, please report them in writing to: Oracle University,
500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
David Parker warranted to be error-free.
Werner de Gruyter
Restricted Rights Notice
Steven Lemme
Peter Wallace If this documentation is delivered to the United States Government or anyone using
the documentation on behalf of the United States Government, the following notice is

Wilson Yeung applicable:
U.S. GOVERNMENT RIGHTS

Editor The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
Raj Kumar license agreement and/or the applicable U.S. Government contract.
Trademark Notice
Graphic Designer
Maheshwari Krishnamurthy Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
may be trademarks of their respective owners.
Publishers
Syed Imtiaz Ali
Pavithran Adka
Contents
1 Introduction
Course Goals 1-2
Lesson Objectives 1-3
Oracle Enterprise Manager Cloud Control 12c 1-4
Cloud Control 12c Major Themes 1-5
Oracle VM Server in the Classroom 1-6

Summary 1-8
Practice 1-1 Overview: Getting to Know Your Classroom Environment 1-9
2 Architecture and Implementation Options

Objectives 2-2
Cloud Control Components 2-3
Oracle Management Service 2-4
Oracle Management Repository 2-5
Oracle Management Agent 2-6
Communication Flow Between Components 2-8
Agent Installation 2-9
Target Discovery 2-10
Key Differences Between Versions 2-11
Implementation Options 2-12
Single-Server Installation Process 2-14
Starting and Stopping Cloud Control 12c 2-17
Quiz 2-18
Summary 2-19
Practice 2-1 Overview: Installing Cloud Control in a Single-Server Topology 2-20
Practice 2-2 Overview: Exploring the Cloud Control Console 2-21
3 Upgrade Paths
Objectives 3-2
Upgrade Paths 3-3
Upgrade Console 3-4
A Choice of Two Upgrade Processes 3-5
1-System Upgrade Process 3-7
1-System Upgrade Process: Steps 1 and 2 3-8
1-System Upgrade Process: Step 3 3-10
iii
Quiz 3-18
Practice 3-1 Overview: 1-System Upgrade (10g to 12c) 3-21
2-System Upgrade Process 3-23
2-System Upgrade Process: Steps 1 and 2 3-24

Quiz 3-32
Post-Upgrade Console 3-34
1-System Versus 2-System Upgrade: Summary 3-36
Summary 3-38
4 Implementation Planning
Objectives 4-2
Enterprise Manager Implementation Lifecycle 4-3
The Implementation Plan 4-5
Infrastructure Growth 4-7
An Enterprise Manager Site 4-9
One Site Managing the Entire IT Enterprise 4-10
Multiple Sites Managing the IT Enterprise 4-11
Sizing the Repository 4-12
OMR Lifecycle and Security 4-14
OMS Lifecycle and Security 4-15
Elements of High Availability 4-16
Four Levels of High Availability 4-18
High-Availability Sample Designs Level 2: Standby OMS and Repository 4-20
High-Availability Sample Designs Level 3: Recovery via Redundant
Components 4-21
iv
High-Availability Sample Designs Level 4: Active and Passive Recovery 4-22
The Availability Continuum 4-23
Summary 4-24
v
Introduction

Copyright © 2012, Oracle and/or its affiliates. All rights reserved.
Course Goals
After completing this course, you should be able to:

• Describe the architecture of Cloud Control 12c
• Describe various topology options for deploying Cloud
Control 12c
• Install Cloud Control 12c in a single-server topology
• Map the upgrade paths from earlier versions of Grid

Control
• Describe and perform the 1-System upgrade
• Describe and perform the 2-System upgrade
• Describe Cloud Control implementation planning
considerations
This course is designed to give you hands-on experience in installing Enterprise Manager
Cloud Control 12c and upgrading from earlier versions. You are introduced to the general
architecture of an Enterprise Manager Cloud Control 12c installation and topologies within
which it can be deployed, as well as considerations to be taken into account when planning a
Cloud Control implementation.
Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 1 - 2

Lesson Objectives
After completing this lesson, you should be able to:

• Describe the key features of Oracle Enterprise Manager
Cloud Control 12c
• Describe the classroom environment that is used for the
practice activities
• Start, log in to, and stop a virtual machine on your student

desktop

Oracle Enterprise Manager Cloud Control 12c
Customers Business Users
User Experience
Business Transactions
...OTHER Business-Driven
WEB PRODUCT ORDER BUSINESS Application
PORTAL CATALOG ENTRY SERVICES Management
Business Services

Applications
Cloud
Services Middleware
Oracle
Apps, PaaS, Databases Support
DBaaS, IaaS.. OS, VM, Servers
Storage, Networks
Complete Cloud Integrated Cloud

Lifecycle Management Stack Management
Managing Your Whole IT Enterprise

Oracle Enterprise Manager Cloud Control 12c helps you manage your IT enterprise at all
levels.
Business-Driven Application Management
• Manage IT from a business perspective
• Create application-aware clouds that understand and adapt to business
Integrated Cloud Stack Management
• Applications, middleware, database, hardware
• Engineered systems (Exadata, Exalogic)
Complete Cloud Lifecycle Management
• Create agile IT for dynamic business
• Manage all phases of a cloud lifecycle and all cloud services from a single product

Cloud Control 12c Major Themes
Enterprise-
Ready
Framework
Applications Cloud
Management Management
Chargeback and
Middleware
Capacity
Management
Planning

Exadata and
Database
Exalogic
Management
Management
Application
Configuration
Quality
Management
Management
Provisioning
and Patching
Oracle Enterprise Manager Cloud Control 12c has been built around ten major themes. Some
of the key aspects of each theme are listed here:
• Enterprise Ready Framework: Plug-in-based management of targets, user interface
redesign, named credentials
• Cloud Management: OVM server and server pool management, cloud topology viewer
• Chargeback and Capacity Planning: Chargeback based on selected target types,
reporting on usage and trends
• Exadata and Exalogic Management: InfiniBand monitoring, real-time and historical
system views
• Configuration Management: Configuration tracking, comparisons, compliance
checking
• Provisioning and Patching: Separation of provisioning design and execution, self-
update, mass database patching
• Application Quality Management: Application replay, real application testing, data
masking
• Database Management: Database creation and upgrade via Cloud Control
• Middleware Management: Improved discovery, monitoring, provisioning, diagnostics
• Applications Management: Fusion Applications management improvements

Oracle VM Server in the Classroom
Classroom PC
em12.example.com em10g.example.com em11g.example.com
em12 em10gp31 em11gp32

dbtarget.example.com

dbtarget
dom0 em10g.example.com em12upg.example.com em11g.example.com
em10gp33 em12upg em11gp34

Oracle VM Server
Self-Contained Multihost Environment

The student machine is running Oracle VM Server and has the capacity to run up to three
guest virtual machines at the same time, as well as a guest called dom0 that is always
running and provides you with an interface to Oracle VM Server. As illustrated, seven guest
virtual machines have been prepared for you, and these are used as required to work through
the practice activities:
• Guest em12 running host em12.example.com
• Guest em10gp31 running host em10g.example.com
• Guest em12upg running host em12upg.example.com
• Guest dbtarget running host dbtarget.example.com
Guests running on your machine can communicate with each other, but only dom0 can
access the network outside the classroom PC.

Out-of-the-box, Oracle VM Server does not offer a GUI front-end; however, your dom0 guest
has been modified to include the Gnome interface so that when you log in to the machine, you
are presented with a familiar graphical interface that can also act as an X-server for your guests.
Logging in to Your Machine
Log in to your classroom PC as user vncuser. This logs you in to dom0 and the Gnome GUI.
After you are logged in, the simplest way to control and interact with your guest virtual machines
is from terminal sessions initiated from the Gnome desktop.
Starting Your Guests
Your Activity Guide tells you which VMs are required to be running for each practice exercise,
and scripts are provided to start the VMs required for each practice. Note that the name of a VM
does not necessarily have to be the same as the hostname of the server that runs within the
VM. For example, the guest called em10gp31 runs a virtual machine with hostname
em10g.example.com.

Starting, Stopping, and Listing Guests
After you are logged in to dom0, you can switch to root in a terminal session and use the xm
command-line tool to manually manage guests on the machine by using the following
commands.
Note: You identify guests to the xm command by using the guest name rather than the
hostname of the virtual machine running in that guest.
• xm list: Lists all the currently active guests, including dom0 itself
• xm create <VM name>: Creates a running instance of the specified guest (for example,
xm create em10gp31)
• xm shutdown –w <VM name>: Shuts down the specified guest and waits for the action
to complete before returning control to you (for example, xm shutdown –w em10gp31)
Your Activity Guide specifies which guests are required for each practice, and scripts are
provided to ensure they are started. You do not need to create and shut down individual guests.
Connecting to Guests and Running GUI Utilities
Use secure shell (SSH) to create a connection as the oracle user from dom0 to your guests
using the hostname of the guest virtual machine. Supply the –X switch so that any GUI utilities
such as the Oracle Installer and Database Configuration Assistant will display in the dom0
Gnome window.
Example:
ssh –X oracle@em12.example.com
When you are logged in, you can test the X-server connection back to dom0 by running xclock
in the guest SSH session.
Viewing Web Pages Served by Guests
You can use the browser built into the Gnome interface on dom0 to view web pages served by
your guests, such as the Cloud Control Console. To do so, enter a URL that refers to the guest
virtual machine hostname, such has https://em12.example.com:7799/em.

Summary
In this lesson, you should have learned how to:

• Identify the purpose of Cloud Control 12c
• List the major design themes of Cloud Control 12c
• Log in to your classroom PC
• Control the guest VMs on your classroom PC
• Log in to the guest VMs on your classroom PC

• Run GUI utilities on the guest VMs on your classroom PC

Practice 1-1 Overview:
Getting to Know Your Classroom Environment
This practice covers the following topics:
• Logging in to dom0
• Opening a terminal session
• Exploring the OVM directory structure
• Starting a VM
• Connecting to the VM

• Initiating a GUI utility on the VM
• Listing running VMs
• Stopping a running VM
This practice familiarizes you with the Oracle VM Server environment installed on the student
machine that you use for all subsequent practices in the course.


Architecture and Implementation Options

Objectives

• Identify the main components of Cloud Control
• Use the Add Host Wizard to start managing hosts and their
targets
• Describe implementation topologies at a high level
• Install Cloud Control in a simple single-server topology


Cloud Control Components
Oracle Management Target-Specific

Agent Plug-In
Managed
Hosts

Oracle Management
Service
Grid Control
Console
Oracle Management
Repository
Grid Control comprises four main components as illustrated in the slide:

• Oracle Management Repository (OMR)
• Oracle Management Service (OMS)
• Oracle Management Agent (OMA or agent) with target-specific plug-ins
• Cloud Control Console
The Oracle Management Agent runs on hosts, gathering metric data about those host
environments as well as using plug-ins to monitor availability, configuration, and performance
and to manage targets running on the host. The agents communicate with the Oracle
Management Service to upload metric data collected by them and their plug-ins. In turn, the
OMS stores the metric data in the Oracle Management Repository where it can be accessed
by the OMS for automated and manual reporting and monitoring. The OMS also
communicates with the agents to orchestrate the management of their monitored targets. As
well as coordinating the agents, the OMS runs the Cloud Control Console web pages that are
used by administrators and users to view reports on, to monitor, and to manage the
computing environment that is visible to Cloud Control via the agents and their plug-ins.

Oracle Management Service
Cloud Control Applications

PBS Console
OCMRepeater
Oracle Management
WebLogic Server Administrator
Agent(s)
OMS

Oracle Management Repository
As the illustration shows, the OMS is actually composed of J2EE applications deployed on
Oracle WebLogic Server:
• The Console serves up all the /em URLs. It can be considered to be the Cloud Control
Console.
• PBS (Platform Background Services) serves up all the /empbs URLs. It is where agents
upload their metrics.
• OCMRepeater is the link between EM CC and My Oracle Support for consolidating
configuration data collected from agents.
The OMS communicates with the agents deployed throughout the enterprise, receiving
uploaded metric data from them and storing it in the Oracle Management Repository for future
reference. The OMS also applies built-in and user-defined rules against received metrics to
determine whether a condition exists that needs to be raised as an alert. There is also
communication from the OMS to the agents of instructions to execute against their monitored
targets, as a result of either a job within the OMS or the actions of an administrator. Cloud
Control administrators and users interact with the OMS via the Cloud Control Console web
pages.

The Oracle Management Repository (OMR):

• Resides in an Enterprise Edition Oracle database
• Includes schema objects belonging to SYSMAN
• Is installed in a certified database instance that has been
created prior to installation
• Can be installed in a RAC database

• Should be the only application schema present in the
database
The OMR is installed in an Enterprise Edition Oracle database as a group of approximately

4,000 schema objects belonging to the SYSMAN user stored in three tablespaces:
MGMT_ECM_DEPOT_TS, MGMT_TABLESPACE, and MGMT_AD4J_TS. These schema objects
contain information about Cloud Control users and administrators, targets and applications
that are monitored and managed by Cloud Control, and groups, systems, incidents, and other
Cloud Control artifacts. The OMR is created during installation in a database that you create
prior to running the installer, and for scalability requirements it can be installed in a Real
Application Clusters (RAC) database.
The database that is used to house the OMR should not be used for any other applications,
including an RMAN catalog, for the following reasons:
• Cloud Control’s usage of the database should not have to compete with any other
usage.
• Using the OMR database for other applications may restrict your ability to upgrade and
patch the OMR schema and database as required.
• Cloud Control comes with a restricted-use single-instance database license that can be
used for the OMR only.
Information about the restricted-use license is detailed in the documentation set in Oracle
Enterprise Manager Licensing Information.

Oracle Management Agent
Server A Host Target Information

Oracle Management
Third-Party Service
Applications
Oracle
Management HTTP/
Agent HTTPS
E-Business
Suite Plug-ins Plug-ins

Application Oracle
Servers Listeners Databases Management
Repository
The Oracle Management Agent is a Java application that runs on a host, gathering metric
data about the host environment as well as using plug-ins to discover, monitor, and manage
targets running on that host. The plug-ins gather configuration information from their targets
and monitor their availability and performance, as well as managing those targets as directed
by the OMS.
A target is any software or system for which there is a plug-in. The list of targets includes
entities such as Oracle Database, Oracle Database Listener, Oracle Application Server and
Oracle WebLogic Server, E-Business Suite, SOA, Exadata, and Exalogic. Using the Oracle
Enterprise Manager Extensibility Framework, plug-ins can be developed by third party
software vendors to monitor and manage their products, and even by individual organizations
to monitor and manage in-house built applications. Only one agent is required on a host to be
able to monitor and manage all the targets running on that host.
Each agent plug-in is specific to a particular target type and offers special management
capabilities customized to suit that target type. To discover, monitor, and manage any given
target, the agent must have the appropriate plug-in installed. However, only the plug-ins that
are required by the installed targets need to be installed on any given agent.

Plug-ins have components that reside in both the agent and the OMS. The OMS plug-in
determines the management options and behavior that is exposed through the Cloud Control
Console. The Oracle Database and Oracle Fusion Middleware plug-ins are installed in the OMS
by default, and other plug-ins can be installed if required. Plug-ins are added to the agent as
relevant targets are discovered. Plug-ins can be updated independently of the agent and other
plug-ins, allowing for simplified maintenance to add improvements and corrections, and to align
with new versions of the target.
The agent communicates via clear HTTP or secured HTTPS traffic with the Oracle Management
Service to upload metric data collected by it and its plug-ins and to receive instructions from the
OMS.
Agents are installed in their own ORACLE_HOME as an instance of a shared binary
ORACLE_HOME, although typically there is a one-to-one mapping of agent instance to agent
binaries (unless you are using a shared NFS-mounted agent binaries location).

Communication Flow Between Components
Oracle
Management
Server
4889 / 4900
7788 / 7799
HTTP / HTTPS
HTTP / HTTPS
3872 / 3872
Oracle Management
Cloud Control

Agent JDBC 1521 Console User
Oracle
Management
Repository
The communication flow between the Cloud Control components is illustrated using
directional arrows to indicate the initiator of the communication. All the ports shown and listed
below are default values that can be changed during installation, either by the installer as it
searches for available ports, or explicitly by you. You can also change ports after installation.
• The agent uploads data to the OMS via HTTP on port 4889 or via HTTPS on port 4900.
• The OMS communicates with the agent via HTTP or HTTPS on port 3872, depending
on whether the agent is unsecured or secured respectively.
• The OMS communicates with the OMR via JDBC on port 1521.
• Cloud Control Console users access the Cloud Control web pages via HTTPS on port
7799 or via HTTP on port 7788.
Knowing the ports used in your Cloud Control installation is important, especially should you
be managing hosts behind firewalls or where other network restrictions apply, because
communication will need to be allowed on these ports and in the directions shown.

Agent Installation
Oracle Management
Service
Add-Host Wizard Add-Host Wizard

on Specified Host on Discovered
server.example.com Host ?.example.com

Clone Agent
Between
Hosts
Installation from
Software Distribution
The Transition from Host to Managed Host

Cloud Control administrators can use the OMS to start managing any host that complies with
the general agent prerequisites that can be accessed from the OMS server using a secure
shell (SSH). Once connected using authentication credentials supplied through the Cloud
Control Console, the agent image is sent in compressed form and then uncompressed and
installed. You specify the installation directories in the Cloud Control Console when initiating
the add-host job. The agent can be added to hosts that are:
• Known to the Cloud Control Administrator as a host on the network yet to be managed
by Cloud Control
• Discovered by Cloud Control as an unmanaged host
You can also use Cloud Control to clone the agent from one host to one or more other hosts
of the same operating system. This clones not just the software but also the configuration of
the agent.
If you do not have SSH access to a host, possibly because it is on the other side of a firewall
or the user credentials available to you do not allow SSH, use another process such as
installing the agent from distribution media or a staged location. The OMS can also generate
an agent RPM or ZIP file that can be copied to the target host for installation.

Target Discovery
Server A Host Target Information Auto

Discovery
Third-Party
Applications
Oracle
Management
Agent
E-Business
Suite

Guided
Application
Listeners Databases Discovery
Servers
Once the agent has been installed on a host, it needs to look for targets that it can manage.
As a Cloud Control administrator, you can guide that process using the Cloud Control
Console Add Non-Host Wizard. Guided discovery allows you to nominate a family of target
types to search for, such as database and listeners, and then the agents where you want that
search to be executed. When any new targets are discovered, the appropriate plug-in is
pushed from the OMS if required, the target is recorded in the OMR, and monitoring
commences.
You can also configure auto discovery to run at regular intervals and get agents to search for
known targets unattended, allowing you to review the results at a later stage and promote
discovered targets to become managed targets.

Key Differences Between Versions
• WebLogic Server (WLS) installation:

– 11g required a pre-existing WLS installation; 12c does not.
– An additional 12c OMS including WLS can be installed from
the Cloud Control Console.
• Redesigned user interface
• Metrics collection:

– 10g and 11g metrics are gathered by the agent.
– 12c metrics are gathered by agent plug-ins.
Prior to installation of 11g Grid Control, you had to install Oracle WebLogic Server 10.3.2.
Now, the installer for Cloud Control 12c installs WebLogic Server 10.3.5 for you if you do not
already have it installed. A consequence of this is that you can initiate the installation of an
additional OMS on another host from within Cloud Control itself rather than having to run the
Universal Installer on that host as was the case in 11g.
Enterprise Manager Cloud Control 12c represents a complete redesign of the product. Where
the earlier agents contained the metrics collection and management logic for all possible
targets, the 12c agent comprises a core that uses target-specific plug-ins to monitor and
manage targets. These plug-ins can be delivered by Oracle or by third parties using the
Extensibility Framework. Furthermore, plug-ins can be updated using the auto-update feature
and this can be done independently of the core agent and vice versa, thus ensuring that the
maintenance required to keep up to date with enhancements in the core and the plug-ins is
streamlined.

Implementation Options
Cloud Control can be implemented in a variety of topologies to

suit all sizes of enterprise and availability requirements, as in
these examples:

Single Server Active/Passive Multiple OMS Fronted
by Load Balancer with
RAC OMR
One Size Does Not Fit All

Consideration should be given to a number of criteria when deciding how and where to deploy
Enterprise Manager Cloud Control 12c.
Single-Server Deployment
This is the simplest topology, in which all components are installed on the same server.
Advantages:
• Simple installation
• Ease of maintenance
Disadvantages:
• Can scale only within the limitations of the server resources
• Server becomes a single point of failure
Multi-Server Deployment
The OMS and the OMR can be separated onto their own servers, and in turn can both be
installed in multi-server topologies fronted by load balancers in active-passive or active-active
modes, physically co-located or geographically distributed, and the OMR can use Data Guard
technology to replicate data between sites.

Examples of such topologies include:
• Multiple OMS servers fronted by a load balancer for scalability and availability of the Cloud
Control application
• Multiple OMS servers fronted by a load balancer with a RAC OMR for scalability and
availability end-to-end
• Multiple OMS servers geographically distributed fronted by multiple load balancers with a
Data Guard enabled OMR for Maximum Availability
Advantages:
• High to maximum availability
• No single point of failure
• Cloud Control maintenance is possible without an outage
• Because virtual host names are used to front the OMS and the OMR, both tiers can be
relocated with ease.

Disadvantages:
• Cost and maintenance of extra hardware
• Complex topology may impede troubleshooting.
• Complex topology requires careful planning and phased rollout.
Deployment planning is covered further in the lesson titled “Implementation Planning.”

Single-Server Installation Process
1. Read the documentation and release notes.

2. Check hardware and software compliance with
prerequisites.
3. Prepare the database for the OMR.
4. Run the installer and choose Simple or Advanced
installation.

5. Execute any post-installation steps.
Prevention Is Better Than a Cure

Before installing any software, it is important to read the release notes and installation guide
to become familiar with the full process, taking care to note and check compliance with
prerequisites, as well as any post-installation steps that may be required. Anecdotal evidence
from Oracle Support suggests that many Oracle Enterprise Manager Cloud Control
installation attempts end unhappily because one or more prerequisites were not met.
Prerequisite Checks
The documentation lists comprehensive requirements for the system on which Cloud Control
is to be installed, including:
• Hardware and operating system requirements
• Operating system groups and users and their setup
• Networking requirements
• Certified Oracle Database versions for the Management Repository
Prepare Your Oracle Database for the OMR
The Cloud Control distribution includes a command-line utility, EM Prerequisite Utility Kit
(emprereqkit), that you can run against the database that you intend to use as a repository.

emprereqkit makes recommendations if required, and can also make some configuration
changes to the database for you. emprereqkit can also be used to reverse some of the
changes after installation if they were only temporary installation requirements.
Run the Installer
Start the installer process, choose Simple or Advanced installation, and enter information as
required. Keeping a record of the values entered on each screen for future reference is easier
than examining logs after installation. Some administrators go one step further by taking
screenshots of each installer screen before moving to the next step. During the installation
process you will need to make some decisions.
• Hostname
If you are installing on a multihomed machine, you can nominate the hostname that
Enterprise Manager Cloud Control 12c will be associated with. This input parameter
should not be changed from the servername if you do or intend to have a load balancer in
front on your Cloud Control installation—that is achieved with a postinstallation

configuration operation.
• Deployment Size
In an Advanced installation, you nominate a deployment size to use for building the
repository. This essentially indicates the number of targets, Management Agents, and
concurrent user sessions you plan to have. The installer provides three choices:
- Small: To monitor up to 999 targets, with up to 99 Management Agents and up to 10
concurrent user sessions
- Medium: To monitor about 1000 to 9999 targets, with about 100 to 999 Management
Agents and about 10 to 24 concurrent user sessions
- Large: To monitor 10,000 or more targets, with 1000 or more Management Agents,
and with about 25 to 50 concurrent user sessions
• Central Agent Base Directory
Previous versions of Enterprise Manager Grid Control and Cloud Control installed the so-
called central agent (the agent installed on the OMS server) under the Enterprise Manager
home. The Cloud Control installer now allows you to nominate a separate directory for the
central agent, allowing the agent to be patched and upgraded like any other management
agent.
Enterprise Manager Cloud Control 12c is installed under the middleware home that you specify
using the following structure:
<middleware_home>
|__wlserver_10.3
|__jdk16
|__oms
|____bin
|____cfgtoollogs
|____install
|__plugins

|__gc_inst
|____em
|______EMGC_OMS1
|________sysman
|__________log
|__Oracle_WT
|__oracle_common
|__utils
|__logs
|__modules
|__ocm.rsp

|__registry.dat
|__domain-registry.xml
|__registry.xml
The central agent is installed under the home that you specify using the following structure:
<agent_base_directory>
|__core
|____12.1.0.2.0
|______sysman
|__plugins
|__agent_inst
|____sysman
|______log
Configuration log files are in various locations:
<middleware_home>/oms/cfgtoollogs/cfgfw/CfmLogger_<timestampe>.log
<middleware_home>/oms/cfgtoollogs/cfgfw/*
<agent_base_directory>/core/12.1.0.2.0/cfgtoollogs/cfgfw/*
Component specific logs are in the following locations:
<middleware_home>/oms/cfgtoollogs/omsca/* for the OMS Configuration Assistant
<middleware_home>/oms/cfgtoollogs/pluginca/* for the PlugIn Configuration
Assistant
<middleware_home>/oms/sysman/log/schemamanger/latest/* for the Repository
Configuration Assistant
Execute Post-Installation Steps
Be sure to execute any post-installation steps, either as directed by the installer or as
described in documentation and release notes. If not specified, you should include backing up
the initial configuration of the OMS by using the emctl exportconfig oms command.

Starting and Stopping Cloud Control 12c
• Start, stop, and check status of the OMS with emctl.

$ORACLE_HOME/bin/emctl start oms
$ORACLE_HOME/bin/emctl stop oms [-all][-force]
$ORACLE_HOME/bin/emctl status oms [-detail]
• Start, stop, and check status of an agent with emctl.

$AGENT_INST_HOME/bin/emctl start|stop|status agent

• Enterprise Manager startup sequence:
1. OMR listener and database instance
2. OMS
3. Agent on OMS server
• Shutdown is in the reverse order.
Enterprise Manager Control

Enterprise Manager Control (emctl) is used to control the OMS and all agents, although it
must be invoked from the appropriate directory to be able to control the desired component.
OMS Log Files
Log files for the OMS are primarily in the following locations:
<middleware_home>/gc_inst/em/EMGC_OMS1/sysman/log
<middleware_home>/gc_inst/user_projects/domains/GCDomain/servers/EMG
C_OMS1/sysman/log
<middleware_home>/gc_inst/user_projects/domains/GCDomain/servers/EMG
C_OMS1/logs
Agent Log Files
Log files for the central agent (the agent installed on the OMS server) are in this location:
<agent_base_directory>/agent_inst/sysman/log

Quiz
How will you prepare for installing Enterprise Manager Cloud

Control 12c? (Select all that apply.)
a. Getting comfortable at your desk
b. Reading the installation documentation and release notes
c. Making a cup of tea
d. Ensuring your environment meets all prerequisites

e. You don’t need to prepare. What could possibly go wrong?
Answer: b, d
Although it is important to be relaxed and well hydrated, it is vital that you are familiar with the
installation process before embarking upon an installation of Enterprise Manager Cloud
Control 12c. This includes checking the environment where you propose to install Enterprise
Manager Cloud Control 12c against all documented prerequisites and addressing any
deficiencies that are found before starting the installation.

Summary

• Describe the main components of Cloud Control and their
relationship with each other
• Install the agent on a host and discover targets on that
host
• Differentiate between available topologies

• Install Cloud Control in a simple single-server topology

Installing Cloud Control in a Single-Server Topology
• Checking system prerequisites
• Creating a database instance for the OMR
• Checking the database instance prerequisites
• Installing Oracle Enterprise Manager Cloud Control 12c
• Cloud Control Console first-time login

• Discovering targets on a host by using the Add Host and
Add Non-Host wizards
In this practice, you install a database instance to be used for the OMR, and you then install
Oracle Enterprise Manager Cloud Control 12c onto the same server as the OMR instance.
Then you log in to the Cloud Control Console and use guided discovery to install the Oracle
Management Agent on a host and discover the targets running on that host.

Exploring the Cloud Control Console
• Home page selection
• Exploring the Enterprise Manager Cloud Control 12c
Console

In this practice, you look at the various home pages available for selection and then explore
the Cloud Control Console.

Upgrade Paths

Objectives

• Describe the upgrade paths that can be used when
upgrading from earlier releases
• Describe the 1-System upgrade process


Upgrade Paths
12c
11.1
10.2.0.5

10.2.0.4
Earlier
Releases
Good Planning Results in Successful Upgrades

Before starting an upgrade to Enterprise Manager Cloud Control 12c from an earlier version,
consider your starting point, because this will determine which upgrade path you select.
As illustrated, it is possible to upgrade directly from Enterprise Manager 11g Grid Control
version 11.1, or from Enterprise Manager 10g Grid Control version 10.2.0.5.
If you are currently running an earlier version, you first need to upgrade to one of those two
versions. This involves one or more updates through the intervening versions between your
starting point and 10.2.0.5 or 11.1, including upgrading your OMR repository to a version of
the database that is supported with 12c.

Upgrade Console
• Is installed on your current OMS as a patch

• Appears as a link on the Deployments tab
• Guides you through the upgrade steps
• Drives all agent-related tasks

The Upgrade Console is installed into your current OMS by applying Patch 14375077 and is
primarily used to coordinate and control the deployment of and switchover to the 12c agents.
It also provides a guide to the overall upgrade processes and reports the progress of your
upgrade.
You provide the Upgrade Console with the location of your 12c agent software, and it checks
whether you have all the platform versions and plug-ins required to upgrade your currently
deployed agents.
When your agent software is in a good state, you use the Upgrade Console to install the 12c
agent onto your managed hosts alongside the current agent, and then to perform the actual
switchover.

A Choice of Two Upgrade Processes
• 1-System upgrade
– An upgrade of current Grid Control OMR and agents to
Cloud Control 12c
– A migration of OMR and agents from the current Grid Control
to Cloud Control 12c
• Agent/OMS compatibility across versions:

– 10g and 11g agents cannot communicate with 12c OMS.
– 12c agent cannot communicate with 10g and 11g OMS.
– Both upgrade processes handle this in different ways.
The Upgrade Console guides you through the two possible upgrade processes: a 1-System
upgrade or a 2-System upgrade.
1-System Upgrade
• Current OMS is shut down prior to 12c installation.
• The current OMR is upgraded.
• Agents must all be switched over together, because the OMR has been upgraded and
can only be used by EM Cloud Control 12c.
• The upgrade is an “all-or-nothing” upgrade where the success or failure of the upgrade
is immediately apparent.
2-System Upgrade
• Current OMS is still running while 12c is installed elsewhere.
• A copy of the current OMR is upgraded.
• Agents can be switched over in a rolling fashion.
• The upgrade can be thought of as a migration between versions.
Detailed steps for each process are outlined in the following slides.

Agent/OMS Incompatibility Across Versions
To achieve maximum benefit from the redesign of the Cloud Control 12c agent, the decision
was made not to build in backward compatibility between the 12c agent and earlier OMS
versions, and conversely not to build in forward compatibility between the earlier agents and the
12c OMS. Therefore, every upgrade to Cloud Control 12c also involves installing the 12c agent
on every currently managed host. The Upgrade Console guides you through this process for
both the 1-System and 2-System upgrade processes, and the switchover steps have been
designed so that there is no loss of metric data.

1-System Upgrade Process
1. Install the 12c Upgrade Console patch on the current OMS.

2. Configure the Upgrade Console and manage the 12c agent
software.
3. Deploy the 12c agents.
4. Run a health check on the 12c agents.
5. Switch over to 12c agents.

6. Back up the OMR.
7. Shut down the current OMS.
8. Install 12c OMS on the current server or a new server, and
upgrade the current OMR.
9. Start the 12c OMS.
10.12c OMS starts accepting 12c agent connections.
The steps of the 1-System upgrade process are described in detail on the following pages.

1-System Upgrade Process:
Steps 1 and 2
Install the 12c Upgrade Current Current
Console patch on the Agent Agent
current OMS, configure it,
and manage the 12c agent
software.
12c

Current Upgrade
OMS Console
Current
OMR
Apply Upgrade Console Patch, Configure, and Manage 12c Agent Software
The first step in the 1-System upgrade process (and also in the 2-System upgrade process) is
to install the 12c Upgrade Console into the current OMS by applying Patch 14375077 for
10.2.0.5 or 11.1.0.1.0 Enterprise Manager Grid Control. Once installed, the Upgrade Console
serves as a reference point for the steps in all upgrade processes as well as the point from
which the agent upgrade is controlled.
Before proceeding further, you need to provide the Upgrade Console with details of your
planned Enterprise Manager 12c installation if you are installing Cloud Control 12c on a new
server.
Next, you must manage the 12c agent and plug-in software. This involves downloading and
staging the 12c agent and plug-in software in a location that the current Grid Control owner
can read and write to. The software can be downloaded from the Oracle Technology Network
(OTN) for any platform; however, the Cloud Control 12c distribution includes that platform’s
plug-in software in the Disk1/plugins directory. Use the Upgrade Console to validate the
12c agent and plug-in software, which checks that the distribution is intact.
The validation also checks that all plug-ins are available that are required by the currently
managed targets, and reports any missing plug-ins that must be downloaded and staged
alongside the standard 12c agent distribution (the distribution will include only the database
and middleware plug-ins).

The validation results are displayed in the form of two pie charts and two tables. One pie chart
represents agent upgradability, split into three categories:
• Upgradable: Agents for which platform-specific core software and all target plugins are
available in the specified location
• Upgradable with missing plug-in software: Agents for which platform-specific core
software is available, but the plug-ins required for one or more current targets associated
with those agents are not available in the specified location. Such agents are upgradable
but the targets will be removed from the agent during the upgrade.
• Not supported: Agents for which no platform-specific core software is available because
that platform is no longer supported or for which the core agent has not yet been released
The second pie chart represents target upgradability, also split into three categories:
• Upgradable: Targets for which plug-in software is available in the specified location
• Missing plug-in software: Targets for which plug-in software is not available in the

specified location
• Not supported: Targets for which there is no plug-in software, meaning they cannot be
monitored and managed by Cloud Control 12c
The legends on the pie charts are also links to a more detailed report on that slice of the pie.
The same reports can also be accessed from the main page of the Upgrade Console.
At the bottom of the Manage Software page are two tables that report overall validation
information on the core 12c agent software and the plug-ins.

Step 3
Use the Upgrade Console
to deploy the 12c agents on
currently managed hosts.
12c

Current Upgrade
OMS Console
Current
OMR
Deploy 12c Agent to Currently Managed Hosts

Although it may seem premature, the third step in the 1-System upgrade process is to deploy
the 12c agent to your managed hosts. This is done using the Upgrade Console in your current
environment, and you specify the installation base, instance directories, and the credentials to
be used for the deployments. You can deploy to more than one host at the same time of
mixed or of the same operating systems, and choose to use the same or specific directories
for each deployment. You have to specify credentials to be used by the Upgrade Console for
authentication and authorization on the hosts, and these can be preferred credentials if they
are already defined for the hosts in question, or you can override the preferred credentials
and supply them explicitly. Only one set of override credentials can be provided, so if this
option is chosen, the credentials must be valid for every selected host.

Step 4
to run a health check on the
12c agents.
12c

Current Upgrade
OMS Console
Current
OMR
Check the Result of the Deployment

The fourth step in the 1-System upgrade process is to use the Upgrade Console to run a
health check against the newly deployed 12c agents. When the checks are complete, you can
view the results. In fact, this is a compulsory step prior to switching over to the 12c agents
(Step 5), enforced by the necessity to explicitly sign-off the report before the agent can be
switched over. You can generate the health check reports against one or more agents
altogether or in batches, but all agents must be checked and subsequently switched over
before you can perform the OMS upgrade.

Step 5
to switch over to the 12c
agents. The Upgrade
Console will:
• Quiesce the current
agent queues
12c

• Shut down the current Current Upgrade
agents OMS Console
• Start the 12c agents
Current
OMR
Shut Down the Current Agents, Start Up the 12c Agents

The fifth step in the 1-System upgrade is to switch over all managed hosts from the current
agents to the 12c agents, including the agent on the OMS server. To be able to do so, you
need to have viewed and signed off the health check reports for the deployed 12c agents.
You initiate the switchover from the Upgrade Console in the current OMS. Each current agent
that you select will be queisced while any metric data yet to be uploaded is uploaded, after
which the current agent is shut down and the 12c agent is started. At this stage, the 12c agent
is only gathering metrics from its targets, because there is no 12c OMS to which it can upload
data.
Agents can be switched over singly, altogether, or in batches. However, it is recommended to
time the switchover to occur shortly before the OMS upgrade to minimize the amount of
gathered metrics for the 12c agents to record and then to upload once the 12c OMS is
available.

Step 6
Back up the repository.

Current
OMS
Current Current
OMR OMR
Backup
Take a Precautionary Backup

The sixth step in the 1-System upgrade process is to take a backup of the current OMR using
your preferred tools and techniques. This is nothing more than a precaution in case you must
revert to the current OMS, and the backup will not be used in any other steps. Because the
important outcome of this step is that the backup is accessible and usable, use a reliable and
tested backup process.

Step 7
Shut down the current OMS.

Current
OMS
Current Current
OMR OMR
Backup
Downtime
Step 7 in the 1-System upgrade is where you shut down the current OMS. At this point your
current Enterprise Manager Grid Control system is unavailable. The recently deployed 12c
agents are still gathering metric data, but your current Grid Control Console cannot be
accessed, nor will Grid Control be issuing any alerts. It is important that you are aware of this
downtime when you plan your upgrade, and that you ensure that all interested parties are
aware that there will be a system outage when the upgrade takes place.

Step 8
Install the 12c OMS and
upgrade the current OMR.

Current 12c
OMS OMS
12c Current
OMR OMR
Backup
Install the 12c OMS

Step 8 in the 1-System upgrade process is installing the 12c OMS and upgrading the current
OMR. The slide illustrates the 12c OMS being installed on a different server than the current
OMS, but it is just as valid to install it on the same server as the current OMS. Start the
installer. After electing whether or not to be informed of security updates and whether or not to
check for software updates, choose the 1-System upgrade option. After you have completed
all the installer’s interrogation screens and the installation has started, you can monitor the
progress in the normal way: through the installer itself or by examining installation logs.
If you had to download plug-ins that are not included in the software distribution when
performing the manage software task (Step 2), you need to make those available to the
installer by using the pluginLocation switch:
./runInstaller –pluginLocation
<absolute_path_to_plugin_software_location>

Step 9
Start the 12c OMS.

Current 12c
OMS OMS
12c Current
OMR OMR
Backup
Start the 12c OMS If It Is Not Already Started

The installer should actually start the 12c OMS and leave it in a running state. However, if that
is not the case or if you have restarted the server hosting the OMS, now is the time to start the
12c OMS.

Step 10
12c OMS starts accepting
12c agent connections.

Current 12c
OMS OMS
12c Current
OMR OMR
Backup
12c Agents Commence Uploading Metrics

When the 12c agents detect that the 12c OMS is up and running, they start uploading all the
metric data collected since the switchover in Step 5.
At this point, your Enterprise Manager 12c Cloud Control System can be considered
available.

Quiz
In a 1-System upgrade, when do you deploy the 12c agents?

(Select all that apply.)
a. Before shutting down the current agent.
b. After shutting down the current agent.
c. Whenever it suits your upgrade plan.
d. Before installing the 12c OMS.

e. After installing the 12c OMS.
Answer: a, d
Deploying the 12c agent before shutting down the current agent is an easily understood
concept, because it makes sense to keep the current agent up and running for as long as
possible while we prepare the 12c agent.
On the other hand, deploying the 12c agent before installing the 12c OMS appears
counterintuitive at first glance, because the 12c agent will not have anywhere to upload its
data. However this does not mean that the 12c agent will not be collecting data, and because
the current OMR is going to be reused as the 12c OMR, we must shut down the current OMS
before performing the OMS/OMR upgrade, which in turn means that the current agent will no
longer have anywhere to upload data.

Quiz
When undertaking a 1-System upgrade, which of the following

should you tell your end users and administrators?
a. There will be no disruption to service.
b. Grid Control will be unavailable for the entire process.
c. It is anybody’s guess as to what their targets are doing
during the upgrade.

d. Nothing. They don’t need to know about the upgrade.
e. Anything. They will believe any explanation.
Answer: b
Strictly speaking, you should consider the current Grid Control unavailable for the entire
1-System upgrade process, not only because this sets a firm expectation in the minds of all
those who use and rely on Grid Control, but also because contingency plans for monitoring
and management need to be put in place as the managed hosts and targets continue to
operate and be used even though Grid Control will be temporarily unavailable.
Communication with your “customer base” is an important aspect of any operation of this
type, and should be given serious consideration from the start of the upgrade planning
process, alongside the technical aspects.

Quiz
In the 1-System upgrade, why don’t you really need to back up

the current OMR?
a. Nothing ever goes wrong, and all your practice upgrades
on your test system went without a hitch.
b. The daily backup will be good enough.
c. You do not have the disk space.

d. Your CV is up to date.
e. Of course you will take a backup.
Answer: e
You’re not going to use the backup of the OMR as part of the upgrade, so why do it? Because
it mitigates against the unforeseeable, and taking a backup at a specific point in time will give
you the confidence to proceed safe in the knowledge that you can revert if you have to.
Including a possible reinstatement of the current OMS in your upgrade plan is vital. Even if
your site does not impose change control processes that strictly require and enforce a change
window that includes a point in time at which the call must be made to roll back, planning for
failure is one of the keys to avoiding it.
Furthermore, be sure to use the same backup process in your upgrade tests that will be used
in the production upgrade, and also include a rollback as part of your upgrade tests to ensure
that the backup is usable.

1-System Upgrade (10g to 12c)
• Patching the current OMS to the latest version
• Installing the Upgrade Console
• Managing the 12c agent software
• Deploying the 12c agent
• Generating a health check report

• Switching over to the 12c agent
• Backing up the 10g OMR
• Shutting down the 10g OMS
• Installing the 12c OMS and upgrading the OMR
• Verifying the switchover in the Cloud Control 12c Console
In this practice, you perform a 1-System upgrade on a single-server installation of Oracle

Enterprise Manager 10g Grid Control with one managed host. You step through the entire
upgrade process including installing the Upgrade Console into the 10g OMS and then using
the Upgrade Console to manage the 12c software, deploy the 12c agent, generate a health
check on the deployed agent, and then switch over to the 12c agent. Next you shut down the
10g OMS and perform the precautionary backup of the 10g OMR before installing the 12c
OMS and upgrading the 10g OMR, after which you verify the switchover in the Cloud Control
12c Console.

• Managing the 12c agent software

• Backing up the 11g OMR
• Shutting down the 11g OMS
In this practice, you perform a 1-System upgrade on a single-server installation of Oracle

the Upgrade Console to manage the 12c software, deploy the 12c agent, generate a health
check on the deployed agent, and then switch over to the 12c agent. Next you shut down the
11g OMS and perform the precautionary backup of the 11g OMR before installing the 12c
OMS and upgrading the 11g OMR, after which you verify the switchover in the Cloud Control
12c Console.

2-System Upgrade Process
1. Install the 12c Upgrade Console patch on the current

OMS.
2. Configure the Upgrade Console and manage the12c agent
software.
3. Copy the current OMR.
4. Install 12c OMS and upgrade the copied OMR.

5. Deploy the 12c agents.
6. Run a health check on the 12c agents.
7. Use the Upgrade Console to shut down the current agents
incrementally and activate the 12c agents.
8. When all agents are successfully switched over,
decommission the current OMS and OMR.
The steps of the 2-System upgrade process are described in detail on the following pages.

Steps 1 and 2
Install the 12c Upgrade Current Current
Console on the current Agent Agent
OMS, configure it, and
manage the 12c agent
software.
12c

Current Upgrade
OMS Console
Current
OMR
Apply Upgrade Console Patch, Configure, and Manage 12c Agent Software
As with the 1-System upgrade process, the first step in the 2-System upgrade process is to
install the 12c Upgrade Console into the current OMS by applying Patch 14375077 for
10.2.0.5 or 11.1.0.1.0 Enterprise Manager Grid Control. Just as in the 1-System upgrade
process, the Upgrade Console serves as a reference point for the steps in all upgrade
processes as well as the point from which the agent upgrade is controlled.
Before proceeding further, you need to provide the Upgrade Console with details of your
planned Enterprise Manager 12c installation.
Next you must manage the 12c agent and plug-in software. The method and steps you need
to undertake are the same as for the 1-System upgrade process. This involves downloading
and staging the 12c agent and plug-in software in a location that the current Grid Control
owner can read and write to. The software can be downloaded from Oracle Technology
Network (OTN) for any platform. However, the Cloud Control 12c distribution includes that
platform’s plug-in software in Disk1/plugins directory. Use the Upgrade Console to
validate the 12c agent and plug-in software, which checks that the distribution is intact.
The validation also checks that all plug-ins are available that are required by the currently
managed targets, and reports on any missing plug-ins that need to be downloaded and
staged alongside the standard 12c agent distribution (the distribution will include only the
database and middleware plug-ins).

The validation results are displayed in the form of two pie charts and two tables. One pie chart
represents agent upgradability, split into three categories:
• Upgradable: Agents for which platform-specific core software and all target plugins are
available in the specified location
• Upgradable with missing plug-in software: Agents for which platform-specific core
software is available, but the plug-ins required for one or more current targets associated
with those agents are not available in the specified location. Such agents are upgradable
but the targets will be removed from the agent during the upgrade
• Not supported: Agents for which there is no platform-specific core software is available
because that platform is no longer supported or for which the core agent has not yet been
released
The second pie chart represents target upgradability, also split into three categories:
• Upgradable: Targets for which plug-in software is available in the specified location

• Missing plug-in software: Targets for which plug-in software is not available in the
specified location
• Not supported: Targets for which there is no plug-in software, meaning they cannot be
monitored and managed by Cloud Control 12c
The legends on the pie charts are also links to a more detailed report on that slice of the pie.
The same reports can also be accessed from the main page of the Upgrade Console.
At the bottom of the Manage Software page are two tables that report overall validation
information on the core 12c agent software and the plug-ins.

Step 3
Copy the current OMR.

Current
OMS
Current Copy of
OMR Current
OMR
Copy the OMR

Because the 2-System upgrade process sees the current OMS and 12c OMS running
simultaneously, you must create a copy of the current OMR that will be upgraded to 12c later
in the process. The technique used to replicate the database instance is entirely in your
hands, but can be as simple as using DBCA to create a template from the current OMR,
copying that template to the 12c OMR Server, and using it to create a new database instance.
Your site’s DBA will most likely have a preferred technique and should be consulted with and
involved in this step.

Step 4
Install 12c OMS and upgrade
the copy of the current OMR.

Current 12c
OMS OMS
Current 12c
OMR OMR
Install the 12c OMS

In contrast to the 1-System upgrade (where installation is performed in Step 8), in the
2-System upgrade process you install the 12c OMS and upgrade the copy of the current OMR
in Step 4. After starting the installer, you elect whether or not to be informed of security
updates and whether or not to check for software updates, and then choose the 2-System
upgrade option. After you have completed all the installer’s interrogation screens and the
install has started, you can monitor the progress in the normal way: through the installer itself
or by examining installation logs.
If you had to download plug-ins that are not included in the software distribution when
performing the manage software task, you need to make those available to the installer by
using the pluginLocation switch:
./runInstaller –pluginLocation
<absolute_path_to_plugin_software_location>

Step 5
Use the Upgrade Console to
deploy the 12c agents.
12c

Current Upgrade
OMS Console
Current
OMR
Deploy 12c Agent to Currently Managed Hosts

The fifth step in the 2-System upgrade process is to deploy the 12c agent to your managed
hosts. This is done using the Upgrade Console in your current environment and is the same
as in the 1-System upgrade. You specify the installation base, instance directories, and the
credentials to be used for the deployments. You can deploy to more than one host at the
same time of mixed or of the same operating systems, and choose to use the same or specific
directories for each deployment. You have to specify credentials to be used by the Upgrade
Console for authentication and authorization on the hosts, and these can be preferred
credentials if they are already defined for the hosts in question, or you can override the
preferred credentials and supply them explicitly. Only one set of override credentials can be
provided, so if this option is chosen the credentials need to be valid for every selected host.

Step 6
to run a health check on
the 12c agents.
12c

Current Upgrade
OMS Console
Current
OMR
Check the Result of the Deployment

The sixth step in the 2-System upgrade process is to use the Upgrade Console to run a health
check against one or more of the newly deployed 12c agents. When the check is complete,
you can view the results. In fact, this is a compulsory step before switching over to the 12c
agents (Step 7), enforced by the necessity to explicitly sign off the report before the agent can
be switched over.

Step 7
Use the Upgrade Console to
incrementally shut down the
current agents and activate
the 12c agents.

12c Current 12c
Upgrade OMS OMS
Console
Current 12c
OMR OMR
Metrics
Delta
Switch Over to 12c Agents and Backfill the Metric Collection Gap
The seventh step in the 2-System upgrade is to switch over one or more managed hosts from
the current agents to the 12c agents. You must view and sign off its health check report
before you can switch over an agent.
You initiate the switchover from the Upgrade Console in the current OMS. Each current agent
that you selected will be queisced. Then any metric data yet to be uploaded gets uploaded.
Then the current agent is shut down and the 12c agent is started and begins uploading data
to the 12c OMS.
Unlike the 1-System upgrade process, you do not need to switch over all your current agents
at the same time as the current OMS and its agents are still operating.
Also in contrast to the 1-System upgrade, the 12c OMR will have a metrics gap from the time
that Step 2 was performed (copy the OMR) to the time the 12c agent is started. However,
unlike the 1-System upgrade process, the current OMS has still been receiving data from the
current agent and storing it in the current OMR since the copy was made, so after the agent is
switched over, the Upgrade Console sends across all the metric data collected by the current
agent to fill the gap.

Step 8
When all agents are
successfully switched over,
decommission the current
OMS and OMR.

Current 12c
OMS OMS
Current 12c
OMR OMR
Shut Down and Decommission Current OMS

When all your current agents have been switched over to the 12c agents, you can shut down
and decommission the current OMS and OMR environment(s).

Quiz
In a 2-System upgrade, when do you deploy the 12c agents?

(Select all that apply.)
a. Before shutting down the current agent
b. After shutting down the current agent
c. Whenever it suits your upgrade plan
d. Before installing the 12c OMS

e. After installing the 12c OMS
Answer: a, e
Unlike the 1-System upgrade, there are no conceptual difficulties in the 2-System upgrade.
It makes sense to deploy the 12c agent before shutting down the current agent, and to do so
after the 12c OMS is installed and available for the 12c agent to immediately start working
with.

Quiz
In the 2-System upgrade, why don’t you need to back up the

current OMR?
a. That is part of the 1-System upgrade rather than the
2-System upgrade.
b. The backup will add time to the upgrade.
c. You will be using the OMR backup as the 12c OMR.

d. You are going on holiday on the day after the upgrade.
e. Of course you will take a backup.
Answer: e
Although the current OMR is effectively backed up as part of the 2-System upgrade process,
you should still formally include keeping a separate copy of the current OMR as part of your
upgrade plan. This may seem unnecessary given that the 2-System upgrade allows for both
the current and Cloud Control 12c environments to run in parallel thereby implying no
downtime or loss of service. However, you should still include the “usual” precautions and
rollback steps in your upgrade plan.

Post-Upgrade Console
• The Post-Upgrade Console is accessed from the Cloud

Control 12c Console.
• The tabs in the console vary depending on the upgrade
process:
– Targets with Pending Activation (2-System)
– Accrued Data Migration (2-System)

– Deferred Data Migration (1-System and 2-System)
– Diff Report (2-System)
– Sign off (2-System)
Post-Upgrade Tasks
The Post-Upgrade Console and associated tasks are viewed from the Cloud Control 12c
Console by navigating to Setup … Manage Cloud Control … Post Upgrade Tasks.
A variety of tabs are available depending on the type of upgrade process that you have
followed.
Targets with Pending Activation
This tab is specific to the 2-System upgrade, and lists all targets that have not yet been
switched over to be managed by the 12c OMS. Initially, the list is the complete set of targets
that were recorded in the current OMR, minus the central agent. The central agent is not
considered to be an agent that needs to be migrated, given that the current OMS and OMR
will be decommissioned at the end of the process, and in the meantime can be monitored by
the current OMS.
Accrued Data Migration
This tab is specific to the 2-System upgrade, and shows the status of the jobs that migrate
data accumulated by the current OMS in the time between taking the copy of the current OMR
and finally switching over to the 12c agent. The jobs are listed by target, and you can drill
down to see information about the job, as well as retry or stop the job. Accrued Data Migration
jobs are executed as database jobs.

Deferred Data Migration
This tab is common to both the 1-System and 2-System upgrades, and lists jobs that are used
to migrate non-critical data from the current OMR schema to the 12c OMR schema. All the data
required to ensure on-going monitoring and management of current targets will have been
migrated to the 12c OMR schema during the installation process. The jobs are listed by data
type, and you can drill down to see information about the job and retry if necessary. Deferred
Data Migration jobs are executed as Enterprise Manager Cloud Control 12c jobs.
Diff Report
This tab is specific to the 2-System upgrade, and shows you any changes that have occurred in
your current OMS since taking the copy of the current OMR for use in the 12c upgrade. These
changes could include OMS configuration changes or target additions. Based on the report, you
can make the same changes to your Cloud Control 12c system.
Sign off

This tab is specific to the 2-System upgrade, and allows you to effectively sign off the accrued
data migration jobs for the current agents. Selecting an agent and clicking the Sign Off Migration
button initiates a job that uninstalls the earlier (pre-12c) agent.

1-System Versus 2-System Upgrade:
Summary
– 12c agents are deployed and started before OMS upgrade.
– 12c OMS is installed on the same server or different
server(s) as the current version, and the current OMR is
upgraded and reused.
– Involves Grid Control Console down time during the upgrade
– Current agents and OMS cannot be used after OMR is

upgraded.
– 12c OMS and OMR are installed on new server(s).
– This is a rolling upgrade of OMR, then OMS, then agents.
– Minimal down time occurs during switchover.
– Current installation and 12c co-exist and are active until all
agents are upgraded.
Two Processes Compared

Each upgrade process has its advantages and disadvantages. As was the case with the
decision on which upgrade path to follow, you should consider which upgrade process is best
for your site and requirements.
1-System Upgrade
There are actually two 1-System upgrade processes to choose from. The first involves
performing the upgrade on the server hosting the current OMS. The second involves an
“out-of-place” upgrade in which the 12c OMS is installed on a different server. Both of the
1-System upgrade processes involve upgrading and reusing the existing OMR; therefore, the
current OMS cannot be started after the OMR upgrade, and consequently the current agents
can no longer be used, resulting in the need to switch over all agents at the same time.
Advantages:
• No extra hardware is necessary.
• The upgrade is an “all-or-nothing” upgrade where the success or failure of the upgrade
is immediately apparent.
• The same ports are used as the current version, so there is no need to change network
device configuration.

Disadvantages:
• You must upgrade all environments at the same time.
• Grid Control will be unavailable during the upgrade, because the OMR cannot be used by
the current OMS while and after it is upgraded, although information will continue to be
collected by the 12c agent.
• The upgrade will probably affect performance when 12c OMS is started, because all the
12c agents start uploading the data collected during the upgrade period.
• Rollback involves a restore of OMR.
2-System Upgrade
The 2-System upgrade process provides for managed hosts to be visible throughout the
duration of the upgrade, because both the 12c and current OMS continue to operate until all
agents are switched over to 12c. For this reason, the 2-System upgrade can be thought of as a
migration process between versions rather than a strict upgrade.

Advantages:
• Managed hosts and targets can still be monitored and controlled in the current OMS while
the upgrade is in progress.
• Agents can be switched over to 12c as desired/planned.
Disadvantages:
• New hardware for the 12c environment is required.
• The process is more complex than the 1-System upgrade.

Summary

• Identify the starting point for an upgrade to
Enterprise Manager Cloud Control 12c
• Identify applicable upgrade paths


• Managing the 12c software
• Copying the 10g OMR and creating the 12c OMR instance

In this practice, you perform a 2-System upgrade of a single-server installation of Oracle

the Upgrade Console to manage the 12c software. Then you copy the 10g OMR and use that
copy to create the 12c OMR database instance on the second server, where you install the
12c OMS and upgrade the newly created OMR. Back in the Upgrade Console, you deploy the
12c agent, generate a health check on the deployed agent, and then switch over to the 12c
agent, after which you verify the switchover in the Cloud Control 12c Console.

• Managing the 12c software
• Copying the 11g OMR and creating the 12c OMR instance

In this practice, you perform a 2-System upgrade of a single-server installation of Oracle

the Upgrade Console to manage the 12c software. Then you copy the 11g OMR and use that
copy to create the 12c OMR database instance on the second server, where you install the
12c OMS and upgrade the newly created OMR. Back in the Upgrade Console, you deploy the
12c agent, generate a health check on the deployed agent, and then switch over to the 12c
agent, after which you verify the switchover in the Cloud Control 12c Console.

Implementation Planning

Objectives
After completing this lesson, you should be able to describe:

• The Enterprise Manager implementation lifecycle
• Implementation planning considerations
• Post-implementation activities
• Enterprise Manager high-availability topologies


Enterprise Manager Implementation Lifecycle
Plan Initial Rollout Short Term Long Term

A Lifecycle of Continuous Growth

The lifecycle of an Enterprise Manager implementation ideally starts with:
• The appointment of an Enterprise Manager administrator/owner
• A design of the installation topology
• A plan of the implementation starting with the initial rollout and looking to future
expansion
Initial Rollout
Your initial rollout will of course include the Enterprise Manager Cloud Control installation
itself, but will also include the initial set of managed hosts and targets, how they will be
monitored, and who will administer them. Consideration should be given to how many hosts
and targets you want to initially manage, especially if this is your first exposure to Enterprise
Manager. For example, you may simply want to start by managing a handful of databases.
Short-Term Growth
After the initial rollout, you can expect to simply add more managed hosts and targets in the
short term.

Long-Term Growth
After Enterprise Manager has been in use for some time, you will see an increase in the number
of managed hosts and types of targets, and also a probable increase in your user base as you
expand beyond the initial scope. You may also consider adding more infrastructure to your
implementation for scalability and/or high availability.

The Implementation Plan
• Appoint an Enterprise Manager owner.

• Think long-term and ensure that the foundation is solid.
• Take other business units’ requirements into consideration.
• Have a test site.

The Implementation Plan Is Crucial to Success

The implementation plan is probably the most important element of an Enterprise Manager
Cloud Control rollout because it maps out what you are going to do and when, what resources
you have available, what you are monitoring, and how you will monitor it. Controlling the
expansion of Cloud Control through your environment is vital to ensure that the
implementation is successful.
The Role of the Enterprise Manager Owner
The Enterprise Manager owner is given (and takes) responsibility for the Enterprise Manager
implementation meeting its success criteria and serving the needs of its user base. Oracle
Enterprise Manager, by its very nature, can touch all parts of a business, so the incumbent in
this role is someone who has a vision of the entire IT enterprise. The owner should know all
the key technical people and business stakeholders for every system that is being monitored
and managed.

Think Long-Term and Ensure That the Foundation Is Solid
• Plan what is going to be monitored, how it will be administered, and by whom.
• Determine initial size, scope, and the growth plan of everything: administrators, targets,
management servers, and so on.
• Phase the rollout and use logical milestones to track progress. Rome wasn’t built in a day!
• Consider site availability and disaster recovery.
Take Other Business Units into Consideration
• Understand what your business users want so you can deliver what they need, because
they are the owners of the systems that you are monitoring and managing.
• Consider:
- Security and access: Administrators, groups, and privileges
- Business requirements: Availability, monitoring, administration, and reports

Have a Test Site
• It is very important to have a non-production site where you can experiment with metrics
extensions, patch updates, and so on.
• You want to test changes and discover possible performance hits before rolling them out
to production.
• A test site provides an internal proof-point to showcase additional features.

Infrastructure Growth
• Initial rollout size: Your reason for getting started

(Now)
• Projected growth: What is projected to be added in the
near future
(Next Quarter)
• Long-term growth: Opportunities and potential additional
usage

(Next Year)
Growth Is Inevitable
An enterprise-wide management system such as Cloud Control is considered because the
enterprise is large enough to dictate it, so growth is inevitable in the managed hosts and
targets that fall under the scope of Cloud Control. As such, your Cloud Control infrastructure
may need to grow too.
Initial Rollout Size
There is no hard and fast rule for determining the size of the infrastructure that should be
placed under Cloud Control, although you can estimate the volume of metric data that will be
gathered by the agents and hence the potential growth of your OMR. As long as you plan
carefully, you can always grow the infrastructure as your Cloud Control enterprise expands. In
particular, you can provide for future growth by:
• Using RAC for your OMR, even if it is just a single-node cluster, to give it the potential to
scale
• Avoiding communicating directly from the agents to an OMS. Instead, use the
abstracted management server or load balancer hostname.
• Using non-local (shared) storage for your software library to ease the transition to
multiple OMSes in the future

Projected Growth
Think in terms of the next quarter after rollout or the very short-term future. After Enterprise
Manager Cloud Control is in place, you will want to add more targets, and people will also start
wanting you to add their systems as targets. What, if any, down time of Cloud Control will the
owners of your targets tolerate? Will you need to start allowing business groups to administer
and monitor their own targets?
Long-Term Growth
Long-term growth is something for the Enterprise Manager administrator to map out and see
coming in the future. There might be other groups or geographically distant sites in the
organization that can be brought into the Enterprise Manager fold. There may be internally
developed systems that could be monitored through custom plug-ins. It may be appropriate to
duplicate the Enterprise Manager hardware at this point to scale up the infrastructure.

An Enterprise Manager Site
A site is a distinct set of Enterprise Manager components and

supporting infrastructure:
• Oracle Management Repository
– Instance, storage, RAC, Data Guard
• Oracle Management Server(s)
– Firewalls, load balancer(s), shared storage

• Oracle Management Agents
– Communications to/from OMS
– Proxy monitoring (off-host targets)
Considerations for an Enterprise Manager Site

In planning your implementation, give consideration to the performance, configuration and
accessibility of each component to optimize your end users’ experience of Enterprise
Manager Cloud Control.
Your Oracle Management Server(s) must be able to insert data into and retrieve data from the
OMR as efficiently and quickly as possible. The performance of your OMR will be sensitive to
the underlying CPU, memory, and storage capability and capacity of the OMR server.
Oracle Management Server(s)
As Cloud Control’s view of your IT enterprise grows, so too will the amount of data being
uploaded by agents that in turn needs to be stored in the OMR. Therefore, the OMS is
sensitive to network latency between it and the OMR. You must also take into account any
firewalls between the OMS and its agents, and any load balancers fronting your OMSes.
Oracle Management Agents
Agents can reside anywhere on your network, so the only requirement is that the agent
should be able to access the OMS upload port and, conversely, that the OMS should be able
to access the agent URL.

One Site Managing the Entire IT Enterprise

EM CC
Having one Enterprise Manager site to monitor and manage your entire enterprise implies:
• One set of hardware
• A centralized infrastructure
• Global network access to all machines
• Global security requirements
Advantages:
• A centralized global view of the entire IT enterprise
• Security controlled at one point
• One monitoring standard enforceable at a single point
Disadvantages:
• An increased requirement for high availability because your site may be utilized across
multiple time zones and the International Dateline

Multiple Sites Managing the IT Enterprise

EM CC EM CC EM CC
Using multiple Enterprise Manager sites to monitor and manage your enterprise implies:
• Multiple sets of hardware for each site
• Multiple localized infrastructures for each site
• Localized network access to the managed hosts is all that is required.
• Local security requirements can be enforced and are all that need to be adhered to.
Advantages:
• Restricted access to only local targets for local administrators
• Allows specialized management setup per site (SLA, notifications, monitoring)
Disadvantages:
• There is no centralized overview of entire enterprise.
Because of the complexities involved, you should only consider using multiple sites if the
business requirements demand it. Regardless of your implementation plan, it is
recommended that your initial rollout consist of just a single site to remove a layer of
complexity and potential problems in the short term.

Sizing the Repository
• Repository size is based on:

– The number of discovered targets
– The amount of retained historical data
– The number of administration tasks defined and used
• Start with the documented recommendations.
• Use advanced install and choose from preconfigured

small, medium, and large sizes.
Repository Size Can Be Estimated

Although the size of your repository cannot be accurately calculated in advance, the size can
be estimated based on the initial rollout and projected growth predicted for your installation.
The documentation contains recommendations for small, medium, and large deployments and
these are ideal starting points.
Discovered Targets
The agent will upload a certain amount of metric data in each 24 hour period for each
discovered target. The quantity of data depends on the target type. The OMS also stores
configuration data for each target, which we can estimate to be 10% to 30% of the size of that
target’s metric data.
Retained Historical Data
Historical data contributes to the size of the repository. By default, the OMS applies the
following retention periods:
• Weekly, monthly and yearly metric data rollups
• Keeping state information for six months
• Keeping configuration data for one year

Administration Tasks
Each administration task involves some overhead in terms of configuration and state
information, which you can estimate at around 1KB per task. These tasks include:
• Cloud Control jobs
• Patching and Provisioning jobs (and patches in the patch cache)
• Templates

OMR Lifecycle and Security
• Maintain the OMR database.

– Patch as you would any other production database.
– Apply patches to your test environment first.
• Apply security measures.
– Secure communications between OMS and OMR.
– Restrict SQL access to only OMS servers and Enterprise

Manager administrators.
• Back up the OMR.
– Use your site’s standard backup regime.
Maintain and Secure the OMR Database

The OMR database should be treated like any other database in your enterprise and kept
current by applying Enterprise Manager patches and database patches as they become
available. For this reason, the Enterprise Manager test environment takes on renewed
importance as the site where you can test patches prior to applying them to your production
environment. If you are using a multi-node RAC cluster, rolling patches can be applied without
any outage to your OMR.
Use the network security feature of the database Oracle Advanced Security Option (AOS) to
secure communication between the OMR and OMS. AOS combines network encryption,
database encryption, and strong authentication.
You can further restrict access to the OMR so that the database accepts connections from
only those servers that are hosting the OMS.
The OMR is a production database and should be protected with your standard production
database backup regime. Make sure that the backups are valid and can be used to perform a
restore operation.

OMS Lifecycle and Security
• Maintain the middle tier.

– Apply WLS and OMS PSUs as per Oracle Support
recommendations.
– Apply patches to your test environment first.
• Apply security measures.
– Lock OMS in secure mode to disable unsecure access.

– Secure the Console with an SSL certificate from a trusted
authority.
– Do not allow the installation owner to log in directly to the
operating system.
• Back up the OMS configuration.
– Back up after installation and after every infrastructure
change.
Maintain and Secure the OMS

The OMS and its underlying WLS installation should be treated like any other middle-tier
application in your enterprise and kept current by applying Enterprise Manager and WLS
patches as they become available. As with OMR maintenance, the Enterprise Manager test
environment takes on renewed importance as the site where you can test patches prior to
applying them to your production environment.
Assuming that you use the default secure communications between the agents and the OMS,
disable unsecure communications with the emctl command: emctl secure lock.
Enterprise Manager Cloud Control, out of the box, uses an SSL certificate that is a self-signed
“demonstration” certificate and is not issued by a valid certificate authority. Replacing this with
a certificate issued by a trusted authority increases the security of the Cloud Control Console.
The user who owns the middleware home should not be able to log in directly to the operating
system, but instead access should only be through impersonation utilities such as sudo and
pbrun.
Back up the OMS configuration after installation and again after every change in infrastructure
with the emctl command: emctl exportconfig oms.

Elements of High Availability
• High availability
– Eliminating single points of failure
• Disaster recovery
– Recovering from failure
• Maximum availability architecture
– Combining HA and DR elements

• Downtime
– How much time you can tolerate your system being
unavailable
– Includes maintenance window unavailability
Pieces of the Same Puzzle

Designing a highly available system involves taking various elements and combining them to
suit your needs and requirements.
High Availability
Strictly speaking, high availability gives consideration to the single points of failure in your
system and eliminates them through redundancy. Examples are RAC databases, ASM
storage, and multiple OMSes fronted by a load balancer.
Disaster Recovery
Disaster recovery extends the concept of high availability beyond single points of failure by
providing secondary elements that can be brought into play when the primary elements fail.
Examples are active/passive middleware clusters and standby databases.
Maximum Availability Architecture
Implementing high availability to address single points of failure and disaster recovery to
address system failure leads down the path of maximum availability architecture (MAA).

Down Time
The key to determining which elements of high availability are appropriate for your site is how
much down time you can tolerate; this includes unexpected as well as planned down time.
Availability is commonly expressed as a percentage, but is often more meaningful when
expressed as hours. For example, a 99.9% availability is roughly equivalent to 8 hours and 45
minutes of down time per year.

Four Levels of High Availability
• Level 0: Out-of-the-box
• Level 1: Storage-level protection
• Level 2: Standby OMS and Repository
• Level 3: Recovery via redundant components
• Level 4: Active and passive recovery

Building Levels of Availability

The levels of availability build on each other, expanding the redundancy and recovery options
of the previous level.
Level 0: Out-of-the-box
Level 0 availability is the out-of-the-box configuration of Enterprise Manager Cloud Control
with no specific high-availability elements. Even with no action taken other than installing the
product, availability is considered to be around 95%.
Level 1: Storage-Level Protection
Level 1 availability involves using an 11.1.0.7 or higher database instance with protected
storage (ASM). This provides an element of protection against a storage-level failure, but
there is no redundancy for any of the Enterprise Manager components.
Level 2: Standby OMS and Repository
Level 2 availability may consist of a Cold Failover Cluster (CFC) at the same physical location
employing Data Guard to replicate the OMR to the failover hardware. Some down time is
incurred during the failover to the redundant system.

Level 3: Recovery via Redundant Components
Level 3 availability introduces true redundancy of live components, with multiple OMS
installations fronted by a load balancer and multi-node RAC used for the OMR, all hosted at the
same physical location.
Level 4: Active and Passive Recovery
Level 4 availability is compliant with Maximum Availability Architecture (MAA) principles and
would see Level 3 extended with a passive failover installation located at a physically remote
site using Data Guard to replicate the RAC OMR to a failover RAC OMR.

High-Availability Sample Designs
Level 2: Standby OMS and Repository

Active OMS Standby OMS
Shared Storage
Active OMR Physical Standby
This Level 2 design consists of the following:

• An active OMS
• An active OMR
• A standby OMS
• A physical standby OMR
• Shared storage for the Oracle Inventory, Oracle Homes, and software library
• Software installed against virtual hostnames
• Agent and Cloud Control Console connections made to the virtual hostname
• Failover performed at the DNS level
Level 2 does result in some level of disruption of service during recovery.

Level 3: Recovery via Redundant Components
Load Balancer

Active OMS Active OMS
Shared Storage
OMR RAC Cluster
This Level 3 design is a single-site solution and consists of the following:

• Two active OMS fronted by a load balancer
• Shared storage for the software library
• Agent and Cloud Control Console connections made to the load balancer hostname
• OMS failover performed by a load balancer
• OMR protected locally by RAC cluster, Data Guard, or both

Level 4: Active and Passive Recovery
Primary Secondary
Site Site
Load
Balancer

Shared
Storage
Physical
Standby
This Level 4 design is a multiple-site solution and consists of the following:

• A Level 3–design primary site
• A remote secondary site with a physical standby instance of the OMR
• Shared storage for the software library, accessible from both sites
• Agent and Grid Control Console connections made to the load balancer hostname
• Site failover performed by DNS between load balancers
• Network infrastructure and device redundancy within and between sites
• Power redundancy

The Availability Continuum
100.0
99.5
99.0
98.5
Availability* %
98.0
97.5
97.0
96.5

96.0
95.5
95.0
94.5
Level 0 Level 1 Level 2 Level 3 Level 4
CFC with
Out-of-the- 11g+ RDBMS Primary site Remote Data
local Data
box with ASM on RAC Guard
Guard
* Note: Percentages shown are not based on actual data but are for illustrative purposes only.
The Illustrated Availability Continuum

The graph depicts the increases in availability that can be gained with the progression
between levels of availability. It is not based on empirical data, and the percentage values
used are for illustrative purposes only.
Another way to interpret the y-axis scale is as a measure of acceptable down time—the lower
end of the axis represents a reasonable amount of down time as tolerable, whereas the upper
end of the axis represents even the smallest amount of down time as being intolerable.
Yet another way to think of the y-axis is in terms of costs. If the demanded availability is
higher and if down time becomes accordingly less acceptable, there will be higher costs in
achieving the desired level of availability.

Summary

• Plan your initial Enterprise Manager Cloud Control
implementation
• Prepare for your Enterprise Manager Cloud Control
implementation to grow
• Maintain your Enterprise Manager Cloud Control

implementation
Refer to http://www.oracle.com/technetwork/oem/arch-deploy/index.html
for the latest information.

SQL Tutorial

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SQL Tutorial

Încărcat de

Drepturi de autor:

Formate disponibile

Oracle Internal & Oracle Academy Use Only

Oracle Enterprise Manager

Veerabhadra Rao Putrevu Disclaimer

Oracle Internal & Oracle Academy Use Only

U.S. GOVERNMENT RIGHTS

Oracle Internal & Oracle Academy Use Only

2 Architecture and Implementation Options

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

Oracle Internal & Oracle Academy Use Only

After completing this course, you should be able to:

Oracle Internal & Oracle Academy Use Only

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

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 1 - 2

After completing this lesson, you should be able to:

Oracle Internal & Oracle Academy Use Only

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

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 1 - 3

Customers Business Users

Oracle Internal & Oracle Academy Use Only

Complete Cloud Integrated Cloud

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

Managing Your Whole IT Enterprise

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 1 - 4

Oracle Internal & Oracle Academy Use Only

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

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 1 - 5

em12 em10gp31 em11gp32

Oracle Internal & Oracle Academy Use Only

em10gp33 em12upg em11gp34

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

Self-Contained Multihost Environment

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 1 - 6

Oracle Internal & Oracle Academy Use Only

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 1 - 7

In this lesson, you should have learned how to:

Oracle Internal & Oracle Academy Use Only

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

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 1 - 8

Oracle Internal & Oracle Academy Use Only

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

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 1 - 9

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 1 - 10

Oracle Internal & Oracle Academy Use Only

After completing this lesson, you should be able to:

Oracle Internal & Oracle Academy Use Only

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 2 - 2

Oracle Management Target-Specific

Oracle Internal & Oracle Academy Use Only

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

Grid Control comprises four main components as illustrated in the slide:

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 2 - 3

Cloud Control Applications

Oracle Internal & Oracle Academy Use Only

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

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 2 - 4

The Oracle Management Repository (OMR):

Oracle Internal & Oracle Academy Use Only

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

The OMR is installed in an Enterprise Edition Oracle database as a group of approximately

Oracle Enterprise Manager Cloud Control 12c: Install & Upgrade 2 - 5

Server A Host Target Information

Oracle Internal & Oracle Academy Use Only

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