Oracle Enterprise Manager Cloud Control Upgrade Guide, 12c Release 2 (12.1.0.2)

12c Release 2 (12.1.0.2)

E22625-11

Contents

Title and Copyright Information

Preface

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

Part I Introduction

1 Introduction to Upgrade Approaches

- Upgrading 12c Release 1 (12.1.0.1) [With or without Bundle Patch 1] to 12c Release 2 (12.1.0.2)

- Overview of the Upgrade Approach

- Overview of the Upgrade Utilities

- Installation Wizard

- Upgrade Agents Console

- Overview of the Upgrade Process

- Upgrading 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

- Overview of the Upgrade Approaches

- Differences Between the Upgrade Approaches

- Overview of the Upgrade Utilities

- Preupgrade Console

- Installation Wizard

- Postupgrade Console

- Overview of the Upgrade Processes

- 1-System Upgrade Process

- 2-System Upgrade Process

- 1-System Upgrade Process on a Different Host

2 Things to Know

- Supported Upgrade Paths

- Supported Upgrade Approaches

- Supported Platforms for Upgrade

- Upgrade Scope

- Reusing Existing Ports

- Upgrading Plug-Ins

- Upgrading Plug-Ins While Upgrading 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2)

- Upgrading Plug-Ins While Upgrading Oracle Management Agent 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2)

- Upgrading Plug-Ins While Upgrading Oracle Management Service 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2)

- Upgrading Plug-Ins While Upgrading 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

- Installing Plug-Ins While Upgrading Oracle Management Agent 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

- Installing Plug-Ins While Upgrading Oracle Management Service 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

- Using Oracle Software Library

- Using Connectors

- Updating PDP Configuration File

- Managing Notification, Alerts, Jobs, Deployment Procedure Runs, Metrics, EM CLI Clients, Oracle Exadata Targets

- Managing Notification

- Managing Alerts

- Migrating Alerts

- Creating Incidents and Events for Different Types of Open Alerts

- Creating Incidents and Events for Different Types of Closed Alerts

- Managing Jobs

- Managing Deployment Procedure Runs

- Collecting Metrics

- Upgrading EM CLI Clients

- Upgrading Oracle Exadata Targets

Part II Upgrading 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2)

3 Getting Started

4 Upgrading OMS and Management Repository

- Upgrading OMS and Management Repository in Graphical Mode

- Advanced Installer Options for Graphical Mode

- Limitations

- Deleting Unwanted Management Agents

- Upgrading OMS and Management Repository in Silent Mode

- Advanced Installer Options for Silent Mode

- Installing Software Now and Upgrading Later in Graphical Mode

- Installing Software Binaries

- Running allroot.sh Script

- Configuring and Upgrading

- Advanced Script Options for Software-Only Mode

- Installing Software Now and Upgrading Later in Silent Mode

- Installing Software Binaries

- Editing Response File for Installing Software Binaries

- After You Install

- Configuring and Upgrading

- Upgrading Multi-OMS Environment

5 Upgrading Oracle Management Agents

- Overview

- Before You Begin

- Prerequisites

- Upgrade Procedure

- Upgrading Management Agents

- Additional Parameters for Management Agent Upgrade

- Viewing Management Agents That Cannot Be Upgraded

- After You Upgrade

- Performing Postupgrade Verification Tasks

- Viewing Management Agent Upgrade Jobs

- Viewing Management Agent Upgrade Job Status and Progress

- Troubleshooting

6 Upgrading ADP and JVMD in Graphical Mode

- Upgrading or Redeploying JVMD and ADP Managers in Graphical Mode

- Upgrading or Redeploying Diagnostic Agents in Graphical Mode

- Overview of Manage Diagnostic Agents Wizard

- Deploying Diagnostics Agents On All the Monitored WebLogic Domains (Multi-Domain Deployment)

- Upgrading Diagnostics Agents On All the Monitored WebLogic Domains

Part III Upgrading 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

7 Getting Started

- Getting Started with 1-System Upgrade Approach

- Getting Started with 2-System Upgrade Approach

- Getting Started with 1-System Approach on a Different Host

8 Meeting Preupgrade Requirements

- Configuring Postupgrade Tasks

- Identifying Host for Enterprise Manager Cloud Control

- Managing Software

- Analyzing Your Environment

- Identifying Management Agents with Valid Inventory

- Identifying Management Agents with Invalid Inventory

- Checking the Upgradability Status of Oracle Management Agents

- Checking the Upgradability Status of Targets

- Identifying Problematic Oracle Management Agents

- Identifying Management Agents That Need to Be Reconfigured

- Identifying Management Agents That are Not Supported in Enterprise Manager 12c

- Identifying Management Agents That are Installed after Repository Back-Up

- Identifying Broken Targets

- Providing Repository Backup Details

9 Upgrading Oracle Management Agents

- Deploying and Configuring Oracle Management Agent

- Generating Health Report of Deployed Oracle Management Agents

- Verifying and Signing Off the Health Report of Deployed Oracle Management Agents

- Switching Over to Oracle Management Agent 12c

- Important Points to Keep in Mind

- Monitoring Targets That Were Monitored by the Central Agent

10 Upgrading OMS and Management Repository

- Upgrading OMS and Management Repository in Graphical Mode

- Upgrading with 1-System Upgrade Approach in Graphical Mode

- Upgrading with 2-System Upgrade Approach in Graphical Mode

- Upgrading OMS and Management Repository in Silent Mode

- Upgrading with 1-System Upgrade Approach in Silent Mode

- Upgrading with 2-System Upgrade Approach in Silent Mode

- Installing Software Now and Upgrading Later in Graphical Mode

- Upgrading in Software-Only Mode with 1-System Upgrade Approach in Graphical Mode

- Installing Software Binaries

- Running allroot.sh Script

- Configuring and Upgrading

- Upgrading in Software-Only Mode with 2-System Upgrade Approach in Graphical Mode

- Installing Software Binaries

- Running allroot.sh Script

- Configuring and Upgrading

- Installing Software Now and Upgrading Later in Silent Mode

- Upgrading in Software-Only Mode with 1-System Upgrade Approach in Silent Mode

- Upgrading in Software-Only Mode with 2-System Upgrade Approach in Silent Mode

- Installing Software Binaries

- Running allroot.sh Script

- Configuring and Upgrading

- Upgrading OMS and Management Repository for 1-System on Different Host Approach

- Upgrading Multi-OMS Environment

11 Performing Postupgrade Tasks

- Creating Link to Upgraded Oracle Management Repository

- Reconfiguring Oracle Software Library

- Checking Agent Upgrade Status

- Performing General Postupgrade Tasks

- Performing General Postupgrade Steps

- Upgrading Oracle Database Plug-Ins

- Upgrading Oracle Exalogic System Targets

- Restarting Central Agent When Additional OMS Is Upgraded

- Stopping OCM Scheduler

- Deleting Obsolete Targets

- Disabling Incident Rule Sets

- Resolving Metric Collection Errors for SOA Target

- Enabling Linux Patching After Enterprise Manager Upgrade

- Configuring DownloadLatestPackages Job

- Configuring UpdateHostPackages Job

- (Optional) Deleting the Old OMS Home

- Tracking the Status of Deferred Data Migration Jobs

- Overview of Deferred Data Migration

- Tracking the Status of Deferred Data Migration Jobs

- Tracking the Status of Accrued Data Migration Jobs

- Overview of Accrued Data Migration

- Tracking the Status of Accrued Data Migration Jobs

- Generating and Viewing Diff Reports

- Overview of Diff Reports

- Generating and Viewing Diff Reports

- Viewing Inactive Targets in the Upgraded Enterprise Manager System

- Signing Off Agent Migration Process

- Updating Incident Rules

- Why Update Incident Rules

- Updating Incident Rules for Moved Metrics

- Updating Incident Rules for Renamed Metrics

- Deleting Incident Rules

Part IV Appendixes

A Editing Response File for Upgrading OMS and Management Repository in Silent Mode

B Overview of Notification in Enterprise Manager Cloud Control

- Understanding Events, Incidents, and Incident Rulesets

- Accessing Incident Rulesets

- Migrating Notification Rules to Incident Rulesets

- Working with Notification Methods and Actions

C Overview of Metric Changes in Enterprise Manager Cloud Control

- Oracle SOA Infrastructure

- Oracle SOA Composite

- Oracle Service Bus

- Oracle WebLogic Server

- JBoss Application Server

- Siebel Enterprise

- Siebel Server

- Setting Preferred Credentials for Siebel Server

- Setting Preferred Credentials for Siebel Gateway Server

- Setting Preferred Credentials for Siebel Database Repository

D Identifying Jobs That Will Not Run in the Enterprise Manager for 2-System Upgrade Approach

- Identifying Jobs That Will Not Run in the New, Upgraded Enterprise Manager System

- Identifying Jobs That Will Not Run in the Existing Enterprise Manager System

E Meeting Prerequisites for Installing Oracle Management Agent

F Updating Server Load Balancer Configuration Settings

G Setting Preferred Credentials Using EM CLI

H Searching and Adding Oracle Management Agents

I Securing Oracle Management Agents After Backing Up Oracle Management Repository

J Recovering Database 11.1.0.7/10.2.0.5 from Microsoft Windows 32 to Microsoft Windows 64

- On Source Host (Microsoft Windows 32)

- On Destination Host (Microsoft Windows 64)

- Final Steps

- Microsoft Windows 32

- Microsoft Windows 64

- Troubleshooting

K Deleting Unwanted Oracle Management Agents

L Deleting Old OMS Home

- Deinstalling in Graphical Mode

- Deinstalling in Silent Mode

Index

Oracle® Enterprise Manager

Cloud Control Upgrade Guide

12c Release 2 (12.1.0.2)

E22625-11

October 2012

Oracle Enterprise Manager Cloud Control Upgrade Guide, 12c Release 2 (12.1.0.2)

E22625-11

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

Primary Author:  Aravind Jayaraaman

Contributing Author: Namrata Bhakthavatsalam, Pradeep Gopal, Genevieve D'Souza

Contributor: Anu Vale, Smitha Vishwanathan, Abhishek Suresh Kumar, Srilatha Uravakonda, Shachi Sanklecha, Sarun Saseendran, Shilpa Thergaonkar, Palem Naga Maheshwara Reddy, Ranjit Madampath, Rajesh Parasuraman, Mohammed Nazim, Maria Teresa Gil Lucientes, Revathy Subburaja, Amitabh Khare, Suman Kumar Pramanik, Sanjay Ediga, Bala Kuchibhotla, Raghu Patti, Magesh Marthandam, Robert Abbott, Raj Aggarwal, Ashwin Karkala, Rahul Goyal, Akanksha Sheoran, Bhavin Desai, David Eschliman, Patrick Combs, Courtney Llamas, Qiang Chen, Laiju Raghuvaran.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Preface

Oracle Enterprise Manager Cloud Control Upgrade Guide describes how you can upgrade the following to Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2):

- Enterprise Manager 10g Grid Control Release 5 (10.2.0.5)

- Enterprise Manager 11g Grid Control Release 1 (11.1.0.1)

- Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1]

Audience

Oracle Enterprise Manager Cloud Control Upgrade Guide is meant for system administrators who want to upgrade an existing Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), or Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1].

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related Documents

For more information, see the following books in the Enterprise Manager Cloud Control documentation library:

- Oracle Enterprise Manager Cloud Control Basic Installation Guide

- Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide

For the latest releases of these and other Oracle documentation, check the Oracle Technology Network at the following URL:

http://www.oracle.com/technetwork/indexes/documentation/index.html

Enterprise Manager also provides extensive online Help. Click Help at the top-right corner of any Cloud Control page to display the online help window.

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

Part I

Introduction

This part introduces you to the upgrade approaches offered by Oracle for upgrading your Enterprise Manager system, and describes some key facts you must know before you upgrade your Enterprise Manager system.

In particular, this part covers the following:

- Chapter 1, "Introduction to Upgrade Approaches"

- Chapter 2, "Things to Know"

1 Introduction to Upgrade Approaches

Enterprise Manager has had many releases in the past, but Enterprise Manager Cloud Control is the latest release that has significant changes over all its earlier releases. Unlike the earlier releases that were called Enterprise Manager Grid Control, this release is called Enterprise Manager Cloud Control.

Enterprise Manager Cloud Control offers a variety of new features and enhancements, including improved user interface, stability, reliability, and performance. In addition, Enterprise Manager Cloud Control offers seamless access to My Oracle Support from within its console for managing service requests, deploying patches, and reviewing knowledge base articles.

This chapter describes how you can upgrade your existing, earlier releases of Enterprise Manager Grid Control or Enterprise Manager Cloud Control to 12c Release 2 (12.1.0.2). Oracle understands that with the option of deploying Enterprise Manager across the enterprise and in any number of permutations, upgrading your entire environment becomes a very complex activity, particularly when it involves updating of software and configurations in different levels (tiers) located in different hosts. In addition, there are challenges of upgrading the environment with near-zero downtime or minimal monitoring loss.

Considering these challenges, Oracle provides upgrade options that offer the flexibility to select the approach that best suits your requirement. The upgrade options also aim at simplifying the entire upgrade operation with the intent of making it seamless and error-free.

This chapter provides an overview of the different upgrade approaches that are offered, the utilities to be used for each approach, and the overall process to be followed for each approach for upgrading your existing Enterprise Manager system. In particular, this chapter covers the following:

- Upgrading 12c Release 1 (12.1.0.1) [With or without Bundle Patch 1] to 12c Release 2 (12.1.0.2)

- Upgrading 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

Upgrading 12c Release 1 (12.1.0.1) [With or without Bundle Patch 1] to 12c Release 2 (12.1.0.2)

This section provides an overview of the upgrade approach offered for upgrading Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1], and describes the utilities to be used and the overall process to be followed for this upgrade approach. In particular, this section covers the following:

- Overview of the Upgrade Approach

- Overview of the Upgrade Utilities

- Overview of the Upgrade Process

Note:
For information on the releases Enterprise Manager Cloud Control has had so far, refer to Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

Note:
For instructions to upgrade from 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1] to 12c Release 2 (12.1.0.2), see Part II.

Overview of the Upgrade Approach

Oracle offers only the 1-system upgrade approach for upgrading Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1].

Note:
For upgrading 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2), only 1-system upgrade approach is offered. 2-system upgrade approach is NOT supported.

The 1-system upgrade approach upgrades your Enterprise Manager Cloud Control on the same host—upgrades Oracle Management Service (OMS) on the same host and Oracle Management Repository (Management Repository) in the existing database. Since the upgrade happens on the same host, there is a reasonable downtime involved.

In this upgrade approach, the Enterprise Manager system may be either a single instance or multi-OMS implementation (required by larger enterprises). In either case, the new OMS will be upgrading the original OMS on the same host, but only one system, the new or the original, can be active at any point. To learn about upgrading a multi-OMS environment, see Upgrading Multi-OMS Environment.

Note:
The installer does NOT upgrade your existing Management Agents. After upgrading the OMS, you must upgrade the Management Agent separately using the Upgrade Agents Console. Upgrade Agents Console is a GUI-rich console that you see in the Enterprise Manager Cloud Control Console after you upgrade the OMS. For more information, refer to Upgrade Agents Console.

Table 1-1 describes the compatibility between 12.1.0.1 and 12.1.0.2 releases of OMS and Management Agent.

Table 1-1 Compatibility Between 12.1.0.1 and 12.1.0.2 Releases of OMS and Management Agent

Oracle Management Agent 12c Release 1 (12.1.0.1)

Oracle Management Agent 12c Release 2 (12.1.0.2)

Oracle Management Service 12c Release 1 (12.1.0.1)

Yes

No

Oracle Management Service 12c Release 2 (12.1.0.2)

Yes

Yes

Overview of the Upgrade Utilities

This section describes the utilities to be used for upgrading Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1). In particular, this section describes the following:

- Installation Wizard

- Upgrade Agents Console

Installation Wizard

The Enterprise Manager Cloud Control Installation Wizard is the primary user interface that enables you to select the 1-system upgrade approach, and upgrade your existing OMS and Management Repository.

The following diagram clearly illustrates the features it offers.

Upgrade Agents Console

The Upgrade Agents Console is a graphical user interface built into Enterprise Manager Cloud Control that enables you to select one or more Oracle Management Agents 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1] and upgrade them to 12c Release 2 (12.1.0.2). In addition, you can track the progress of ongoing upgrade operations, and also view a list of Management Agents that cannot be upgraded.

Note:
All OMS instances must be upgraded in a multi-OMS environment, before you can use the Upgrade Agents Console to upgrade your Management Agents.

Overview of the Upgrade Process

The following illustration describes the high-level flow or sequence of steps you must perform when you choose to upgrade Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) using the 1-system upgrade approach:

Note:
Oracle Management Service 12c communicates only with Oracle Management Agent 12c (12.1.0.1 or 12.1.0.2). Therefore, unlike the earlier releases, you must first upgrade the OMS and the Management Repository, and then upgrade the Management Agents using the Upgrade Agents Console. Upgrade Agents Console is a GUI-rich console that you see in the Enterprise Manager Cloud Control Console after you upgrade the OMS. For more information, refer to Upgrade Agents Console.

When you upgrade the OMS and the Management Repository using the installer, the installer does the following by default:

- Installs the following components in the Middleware home location you enter in the installer:

- Java Development Kit (JDK) 1.6 v24 and Oracle WebLogic Server 11g Release 1 (10.3.5) if they are not already available in the Middleware home you specify.

- Oracle Management Service 12 c Release 2 (12.1.0.2).

- Oracle JRF 11g Release (11.1.1.6.0), which includes oracle_common directory.

- Oracle Web Tier 11g Release (11.1.1.6.0), which includes Oracle_WT directory.

- Upgrades or carries over the already deployed plug-ins:

- Upgrades the deployed plug-ins if newer versions are available in the Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2.0) software.

- Carries over the deployed plug-ins without upgrading them in the following cases:
(a) If newer versions are not available in the Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2.0) software.

(b) If the deployed plug-ins are already of the higher or same version as the ones in the Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2.0) software.

- Creates a new Oracle WebLogic domain and Node Manager with the same Administration Server configuration details (same Administration Server, same port, and so on).

- Creates an Oracle Management Service Instance Base directory (gc_inst) for storing all configuration details related to Oracle Management Service 12c.

- Upgrades the Management Repository in the existing certified database.

- Runs the following configuration assistants to configure the installed or upgraded components:

- Stop Admin Server Configuration Assistant

- Stopping APM Engines Configuration Assistant

- Plugins Prerequisites Check Configuration Assistant

- Repository Upgrade Configuration Assistant

- MDS Schema Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Oracle Configuration Manager for OMS Configuration Assistant

- Plugins Inventory Migration Configuration Assistant

Note:
The installer does NOT upgrade your existing Management Agent that was installed with the OMS. You must upgrade it (and all other Management Agents) using the Upgrade Agents Console. For more information, see Upgrade Agents Console.

Upgrading 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

This section provides an overview of the upgrade approaches, clearly differentiates the three upgrade approaches, and describes the utilities to be used and the overall process to be followed for upgrading Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) and Enterprise Manager 11g Grid Control Release 1 (11.1.0.1). In particular, this section covers the following:

- Overview of the Upgrade Approaches

- Differences Between the Upgrade Approaches

- Overview of the Upgrade Utilities

- Overview of the Upgrade Processes

Note:
For instructions to upgrade from 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2), see Part III.

Overview of the Upgrade Approaches

Oracle offers the following upgrade approaches for upgrading Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) and Enterprise Manager 11g Grid Control Release 1 (11.1.0.1):

- 1-System Upgrade Approach: This approach enables you to upgrade to Enterprise Manager Cloud Control on the same host where your earlier release of Enterprise Manager is running. This approach also upgrades the Oracle Management Repository (Management Repository) in the existing database. Since the upgrade happens on the same host, there is a reasonable downtime involved.
This approach does not refer to upgrading of an Enterprise Manager system in an environment with one Oracle Management Service (OMS). It refers to upgrading of an Enterprise Manager system on the same host as the old one, and having only one Enterprise Manager system existing at any point. To learn about upgrading a multi-OMS environment, see Upgrading Multi-OMS Environment.

- 2-System Upgrade Approach: This approach enables you to install Enterprise Manager Cloud Control on a host that is different from the host where your existing Enterprise Manager system is running.
This approach does not upgrade the Management Repository in the existing database, but upgrades the one in the backed up database, thus enabling two Enterprise Manager systems to exist. Since a new Enterprise Manager system coexists with the old one, there is no or near zero downtime involved.

- 1-System Upgrade Approach on a Different Host: This approach enables you to install Enterprise Manager Cloud Control on a host different from where the existing Enterprise Manager is running.
This approach is similar to the 2-System upgrade approach, but unlike the 2-System upgrade approach, this approach upgrades the Management Repository in the existing database itself. Since only one Enterprise Manager system exists at any point, there is a reasonable downtime involved.

Differences Between the Upgrade Approaches

Table 1-2 lists the differences between the three upgrade approaches that are offered for upgrading Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) and Enterprise Manager 11g Grid Control Release 1 (11.1.0.1). Understand the differences and select the approach that best suits your requirement.

Table 1-2 Differences Between the Upgrade Approaches

1-System Upgrade Approach

2-System Upgrade Approach

1-System Upgrade Approach on Different Host

Involves predeployment and switch over of Management Agents prior to upgrading the OMS and the Management Repository, unlike the traditional approach that focussed on upgrading only the OMS and the Management Repository.

Resembles fresh installation.

Has the same impact as 1-system upgrade approach, but with a different host for Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2.0).

Requires a reasonable downtime.

(Essentially, the downtime lasts from the time you switch over the Management Agents till the time you upgrade the OMS.)

Requires minimum or zero downtime.

Requires a reasonable downtime.

Upgrades to Enterprise Manager Cloud Control on the same host where your earlier release of Enterprise Manager is running.

Installs Enterprise Manager Cloud Control on a host that is different from the host where your existing Enterprise Manager system is running.

Installs Enterprise Manager Cloud Control on a host different from where the existing Enterprise Manager is running, but upgrades the Management Repository in the existing database itself.

Does not require an additional hardware resource because it upgrades on the same host.

Requires an additional hardware resource because it installs on a different host.

Requires an additional hardware resource because it installs on a different host.

Existing Enterprise Manager system must be shut down so that the configuration information can be copied and carried over to the upgraded Enterprise Manager system.

Existing Enterprise Manager system can continue to run until you switch over all your earlier releases of Management Agents to the newly upgraded environment.

Existing Enterprise Manager system must be shut down so that the configuration information can be copied and carried over to the new system.

Management Agents must be deployed and configured before upgrading the OMS and the Management Repository.

Management Agents can be deployed and configured before or after upgrading the OMS and the Management Repository.

Management Agents must be deployed and configured before upgrading the OMS and the Management Repository.

Management Agents can be deployed and configured in an incremental or phased manner, that is, in groups.

Management Agents can be deployed and configured in an incremental or phased manner, that is, in groups.

Management Agents can be deployed in an incremental or phased manner, that is, in groups.

Management Agents must be switched over before upgrading the OMS and the Management Repository.

Management Agents must be switched over after upgrading the OMS and the Management Repository.

Management Agents must be switched over before upgrading the OMS and the Management Repository.

Upgrades the Management Repository in the existing, certified database.

Upgrades the Management Repository in the backed up database. Therefore, as a prerequisite, you are required to back up your existing Oracle Database.

Upgrades the Management Repository in the existing, certified database.

Requires no changes to the ports and firewall settings. The upgraded Management Agents and the OMS use the same ports used earlier.

Requires some changes to the ports and firewall settings. The upgraded Management Agents use the same ports used earlier. However, the Management Agent and the OMS installed on the remote host might use new ports.

In a multi-OMS environment, if you have a Server Load Balancer (SLB), then you can either open up new ports for the new Management Agent and the OMS in the same SLB, or configure a completely new SLB for them.

Requires some changes to the ports and firewall settings. The upgraded Management Agents use the same ports used earlier. However, the Management Agent and the OMS installed on the remote host might use new ports.

In a multi-OMS environment, if you have a Server Load Balancer (SLB), then you can either open up new ports for the new Management Agent and the OMS in the same SLB, or configure a completely new SLB for them.

All deployment procedures must be finished before the upgrade is started. Otherwise, the scheduled procedures will be canceled, and you will have to re-create them.

All deployment procedures must be finished before the upgrade is started. Otherwise, the scheduled procedures will be canceled, and you will have to re-create them.

All deployment procedures must be finished before the upgrade is started. Otherwise, the scheduled procedures will be canceled, and you will have to re-create them.

Running jobs will be aborted at the start of the downtime.

Running jobs will continue to run on the existing Enterprise Manager system after the start of the backup. In Enterprise Manager Cloud Control, these jobs will appear to be aborted or failed.

Running jobs will be aborted at the start of the downtime.

Scheduled jobs will run after the downtime is over if their grace period allows them. Otherwise, they will be skipped.

Scheduled jobs will run on the existing Enterprise Manager system from the time of the backup until the point where the Management Agent for that target is migrated to Enterprise Manager Cloud Control. Once the Management Agent is migrated, the jobs will run in Enterprise Manager Cloud Control.

Scheduled jobs will run after the downtime is over if their grace period allows them. Otherwise, they will be skipped.

Repeating jobs will run at their next scheduled time after the downtime. If repeating jobs fall within the downtime, they may be skipped.

Repeating jobs will continue to run according to their schedule on the existing Enterprise Manage system. Once the Management Agent is migrated, subsequent runs will be in Enterprise Manager Cloud Control.

Repeating jobs will run at their next scheduled time after the downtime. If repeating jobs fall within the downtime, they may be skipped.

Note:
Jobs run either in the existing Enterprise Manager system or in Enterprise Manager Cloud Control, and not on both systems. The true status of a job must be viewed only on the system where it actually ran. For more information, see Appendix D. Also, job executions with multiple targets will not run on either system unless all Management Agents for all targets are migrated at the same time.

Overview of the Upgrade Utilities

This section describes the utilities to be used for upgrading Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) and Enterprise Manager 11g Grid Control Release 1 (11.1.0.1). These utilities enable you to select one of the upgrade approaches, orchestrate the entire upgrade operation seamlessly, and also track the post-upgrade activities. In particular, this section describes the following:

- Preupgrade Console

- Installation Wizard

- Postupgrade Console

Preupgrade Console

The Preupgrade Console acts as the primary user interface and is indeed the starting point for upgrading your Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1).

The Preupgrade Console enables you to select an appropriate upgrade approach, predeploy the Oracle Management Agent 12c software, and switch over the earlier releases of Management Agents to the newly predeployed Management Agents.

Note:
Oracle Management Service 12c communicates only with Oracle Management Agent 12c (12.1.0.1 or 12.1.0.2). Therefore, unlike the earlier releases, you must first upgrade the Management Agents in your system before upgrading your existing OMS. Hence, the Preupgrade Console acts as a starting point to the upgrade process.

To access the Preupgrade Console, apply the preupgrade console patch on all your OMS instances. For information about the patch you need to download and apply for your platform, access the following URL:

http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

After downloading the patch, follow the instructions outlined in the ReadMe, which is provided with the patch. Ensure that you use the latest release of OPatch to apply the patch.

After applying the patch, log in to Enterprise Manager Grid Control with super administrator privileges, click the Deployments tab, then click Enterprise Manager 12c Upgrade Console.

IMPORTANT:

- You must apply the preupgrade console patch on all the OMS instances.

- You will have to shut down your OMS to apply the patch, and as a result, your Enterprise Manager system will be down until you complete the patching operation. In addition, you must apply the patch on all your OMS instances, and therefore, the downtime can be more.

- Despite applying the patch, in the Enterprise Manager Grid Control console, in the Deployments tab, if you do not see the hyperlink Enterprise Manager 12c Upgrade Console, then do the following:

1. Move the jsp_servlet directory out of the following location:
$<OMS_INSTANCE_BASE>/user_user_projects/domains/GCDomain/generated_classes

2. Stop the OMS from the OMS home:
$<OMS_HOME>/bin/emctl stop oms

3. Restart the OMS from the OMS home:
$<OMS_HOME>/bin/emctl start oms

The following diagram clearly illustrates the features it offers.

Note:
The supported earlier releases for upgrade include: Oracle Management Agent 10g Release 2 (10.2.x.x.x), Oracle Management Agent 11g Release 1 (11.1.0.1), Oracle Management Service 10g Release 5 (10.2.0.5), and Oracle Management Service 11g Release 1 (11.1.0.1).

Installation Wizard

The Enterprise Manager Cloud Control Installation Wizard is the primary user interface that enables you to select the type of upgrade approach you want to perform, and upgrade your existing OMS and Management Repository.

The following diagram clearly illustrates the features it offers.

Postupgrade Console

The Postupgrade Console is the primary user interface for tracking all post-upgrade activities, including accrued data migration jobs and deferred data migration jobs. In addition, you can generate diff reports and view a list of targets that are currently inactive in the upgraded Enterprise Manager system.

The following diagram clearly illustrates the features it offers.

Note:
For more information about these jobs, refer to Tracking the Status of Deferred Data Migration Jobs, Tracking the Status of Accrued Data Migration Jobs, Generating and Viewing Diff Reports, Viewing Inactive Targets in the Upgraded Enterprise Manager System, and Signing Off Agent Migration Process.

Overview of the Upgrade Processes

This section describes the high-level flow or sequence of steps to be followed for each of the upgrade approaches. In particular, this section describes the following:

- 1-System Upgrade Process

- 2-System Upgrade Process

- 1-System Upgrade Process on a Different Host

1-System Upgrade Process

The following illustration describes the high-level flow or sequence of steps you must perform when you choose to upgrade using the 1-system upgrade approach:

Using the Preupgrade Console, you can deploy the Oracle Management Agent 12c software and switch over the old Management Agents to the newly deployed Management Agents. You will notice that Deploy and Switch Over are two different operations, although they deal with installing and upgrading Management Agents.

Note:
As a best practice, Oracle recommends you to complete the Deploy operation well before you start the Switch Over operation.

While the Deploy operation involves copying of software binaries of the Management Agent and configuring them on the hosts, the Switch Over operation involves stopping the old Management Agents and starting the new Management Agents to work with Enterprise Manager Cloud Control.

The two operations are separated and treated as different entities to ensure that your existing Enterprise Manager system is not shut down or disturbed in any way while the software binaries are copied and configured on the hosts. Once the software binaries are copied and configured, you can switch them over with much less time because the time taken is only for stopping the old Management Agents and starting the new Management Agents.

Once you have switched over the Management Agents, you can upgrade the OMS and the Management Repository.

Note:
As a best practice, Oracle also recommends you to upgrade all the OMS instances immediately after you complete the Switch Over operation. Note that the downtime in 1-system upgrade approach essentially lasts from the time you switch over the Management Agent till the time you upgrade all your OMS instances. So the more you delay your upgrade operation, the more the downtime. During this downtime, none of the targets are monitored and no monitoring data is uploaded to the OMS instances.

When you upgrade to Enterprise Manager Cloud Control on the host using the installer, the installer does the following by default:

- Installs the following components in the Middleware home location you enter in the installer:

- Oracle Management Service 12c.

- Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24 (JDK).

Note:
Oracle WebLogic Server 11g Release 1 (10.3.5) and JDK 1.6 v24 are installed only if they do not exist in your environment. If they already exist (supported version or higher version), then the installer detects them and displays the Middleware home where they are installed. In this case, you only need to validate the path to this Middleware home.

- Oracle JRF 11g Release (11.1.1.6.0), which includes the oracle_common directory, and Oracle Web Tier 11g Release (11.1.1.6.0), which includes the Oracle_WT directory.

- Plug-ins:

- Oracle Database Management Plug-In

- Oracle Fusion Middleware Management Plug-In

- Oracle My Oracle Support Management Plug-In

- Oracle Exadata Management Plug-In

- Other plug-ins you installed while predeploying Oracle Management Agent 12c using the Preupgrade Console (that is, if these plug-ins are available in the software kit)

- Creates or reuses the Oracle WebLogic domain, the Admin Server, the Node Manager, and the Managed Server, depending on the earlier release of the Enterprise Manager system from which you are upgrading.

- If you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then by default, the following are created:

- An Oracle WebLogic domain called GCDomain is automatically created during the configuration of Enterprise Manager Cloud Control. For this WebLogic Domain, a default user account, weblogic, is used as the administrative user. You can choose to change this, if you want, in the installer.

- A Node Manager user account called nodemanager is automatically created during the configuration of Enterprise Manager Cloud Control. A Node Manager enables you to start, shut down, or restart an Oracle WebLogic Server instance remotely, and is recommended for applications with high availability requirements.

- If you are upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then a new Oracle WebLogic domain and Node Manager are created with the same Admin Server configuration (same Admin Server, same port, and so on).

- Creates the OMS instance base directory (gc_inst) in the Middleware home you enter in the wizard, and stores all configuration information related to the OMS.

- Upgrades the Management Repository in the existing certified database.

- Runs the following configuration assistants to configure the installed or upgraded components:

- Plugins Prerequisites Check Configuration Assistant

- Repository Upgrade Configuration Assistant

- MDS Schema Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Oracle Configuration Manager for OMS Configuration Assistant

- Plugins Inventory Migration Configuration Assistant

Note:
The installer does NOT upgrade your existing Management Agent because it is predeployed by the Preupgrade Console.

2-System Upgrade Process

The following illustration describes the high-level flow or sequence of steps you must perform when you choose to upgrade using the 2-System upgrade approach:

When you install and configure Enterprise Manager Cloud Control on the target host using the installer, the installer does the following by default:

- Installs the following components in the Middleware home location you enter in the installer:

- Java Development Kit (JDK) 1.6 v24

- Oracle WebLogic Server 11g Release 1 (10.3.5)

- Oracle Management Service 12c

- Oracle JRF 11g Release (11.1.1.6.0), which includes oracle_common directory

- Oracle Web Tier 11g Release (11.1.1.6.0), which includes Oracle_WT directory

- Oracle Management Plug-Ins

- Oracle Database Management Plug-In

- Oracle Fusion Middleware Management Plug-In

- Oracle My Oracle Support Management Plug-In

- Oracle Exadata Management Plug-In

- Other plug-ins you installed while predeploying Oracle Management Agent 12c using the Preupgrade Console (that is, if these plug-ins are available in the software kit)

Note:
Oracle WebLogic Server 11g Release 1 (10.3.5) and JDK 1.6 v24 are installed only if they do not exist in your environment. If they already exist (supported version or higher version), then the installer detects them and displays the Middleware home where they are installed. In this case, you only need to validate the path to this Middleware home.

- Installs Oracle Management Agent 12c in the agent base directory you specify (outside the Middleware home).

- Creates an Oracle WebLogic domain called GCDomain. For this WebLogic Domain, a default user account, weblogic, is used as the administrative user. You can choose to change this, if you want, in the installer.

- Creates a Node Manager user account called nodemanager. A Node Manager enables you to start, shut down, or restart an Oracle WebLogic Server instance remotely, and is recommended for applications with high availability requirements.

- Configures an OMS Instance Base location (gc_inst) in the Middleware home, for storing all configuration details related to Oracle Management Service 12c. You can choose to change this, if you want, in the installer.
For example, if the Middleware home is /u01/app/Oracle/Middleware/, then the instance base location is /u01/app/Oracle/Middleware/gc_inst. You can choose to change this, if you want, in the installer.

- Runs the following configuration assistants to configure the installed or upgraded components:

- Plugins Prerequisites Check Configuration Assistant

- Repository Upgrade Configuration Assistant

- MDS Schema Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Assistant

- Plugins Inventory Migration Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Oracle Configuration Manager for OMS Configuration Assistant

- Agent Configuration Assistant

- Secures the OMS by generating a password internally. This password is generated by the OMS Configuration Assistant, and the password expires in 30 days from the time it is generated.
If the OMS Configuration Assistant or the Plugins Deployment and Configuration Assistant fails, then ensure that you resolve the issue within the 30-day period. Otherwise, you will face an error in securing the Management Agent while running the Agent Configuration Assistant.

If you are unable to resolve the issue within the 30-day period, run the following command from the Management Agent home:

$<AGENT_HOME>/sysman/install/agentDeploy.sh OMS_HOST=<oms_host_name> EM_UPLOAD_PORT=<oms_upload_https_port> AGENT_REGISTRATION_PASSWORD=<agent_reg_password>

1-System Upgrade Process on a Different Host

The following illustration describes the high-level flow or sequence of steps you must perform when you choose to upgrade using the 1-system upgrade approach on a different host:

As you can see in the illustration, this approach is a combination of 1-system upgrade approach and 2-System upgrade approach. Much like 1-system upgrade approach, you start the upgrade process by predeploying and switching over the Management Agents. Then, like the 2-System upgrade approach, you install Enterprise Manager Cloud Control on a remote host. However, the difference is, you upgrade the same Management Repository that you have been using for the earlier release of the Enterprise Manager, and then decommission the earlier release. This way, only one Enterprise Manager system exists at a given time.

You install the software binaries of Enterprise Manager Cloud Control on the remote host, then upgrade the existing Management Repository, and then, configure the software binaries to complete the installation.

While installing the software binaries, the installer does the following:

- Creates Oracle homes and install the following components in the Middleware home location:

- Java Development Kit (JDK) 1.6 v24

- Oracle WebLogic Server 11g Release 1 (10.3.5)

- Oracle Management Service 12c

- Oracle JRF 11g Release (11.1.1.6.0), which includes oracle_common directory

- Oracle Web Tier 11g Release (11.1.1.6.0), which includes Oracle_WT directory

- Oracle Management Plug-Ins

- Oracle Database Management Plug-In

- Oracle Fusion Middleware Management Plug-In

- Oracle My Oracle Support Management Plug-In

- Oracle Exadata Management Plug-In

- Installs Oracle Management Agent 12c in the agent base directory you specify (outside the Middleware home).

While configuring the software binaries, the installer does the following:

- Creates an Oracle WebLogic domain called GCDomain. For this WebLogic Domain, a default user account, weblogic, is used as the administrative user. You can choose to change this, if you want, in the installer.

- Creates a Node Manager user account called nodemanager. A Node Manager enables you to start, shut down, or restart an Oracle WebLogic Server instance remotely, and is recommended for applications with high availability requirements.

- Configures an Oracle Management Service Instance Base location (gc_inst) in the Middleware home, for storing all configuration details related to Oracle Management Service 12c.
For example, if the Middleware home is /u01/app/Oracle/Middleware/, then the instance base location is /u01/app/Oracle/Middleware/gc_inst.

- Runs the following configuration assistants to configure the installed or upgraded components:

- Plugins Prerequisites Check Configuration Assistant

- Repository Upgrade Configuration Assistant

- MDS Schema Configuration Assistant

- OMS Configuration Assistant

- Plugins Deployment and Configuration Assistant

- Plugins Inventory Migration Configuration Assistant

- Start Oracle Management Service Configuration Assistant

- Oracle Configuration Manager for OMS Configuration Assistant

- Agent Configuration Assistant

2 Things to Know

Before you use the upgrade approaches to upgrade to Enterprise Manager Cloud Control, keep these points in mind:

- Supported Upgrade Paths

- Supported Upgrade Approaches

- Supported Platforms for Upgrade

- Upgrade Scope

- Reusing Existing Ports

- Upgrading Plug-Ins

- Using Oracle Software Library

- Using Connectors

- Updating PDP Configuration File

- Managing Notification, Alerts, Jobs, Deployment Procedure Runs, Metrics, EM CLI Clients, Oracle Exadata Targets

Supported Upgrade Paths

The following upgrade paths are supported:

Table 2-1 Supported Upgrade Paths

From

To

12c Release 1 (12.1.0.1) without Bundle Patch 1 applied

12c Release 2 (12.1.0.2)

12c Release 1 (12.1.0.1) patched with Bundle Patch 1

12c Release 2 (12.1.0.2)

12c Release 1 (12.1.0.1) with Bundle Patch 1 included by default

12c Release 2 (12.1.0.2)

11g Release 1 (11.1.0.1)

12c Release 2 (12.1.0.2)

10g Release 5 (10.2.0.5)

12c Release 2 (12.1.0.2)

10g Release 4 (10.2.0.4) or lower

First upgrade to 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1), then upgrade to 12c Release 2 (12.1.0.2)

10g Release 1 (10.1)

First upgrade to 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1), then upgrade to 12c Release 2 (12.1.0.2)

Supported Upgrade Approaches

To upgrade from Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1] directly to Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), only 1-system upgrade approach is supported.

To upgrade from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1) to Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), all three upgrade approaches—1-system, 2-system, and 1-system on a different host—are supported.

Supported Platforms for Upgrade

The following platforms are supported:

- 1-System upgrade, understandably, must always be done on the same platform as the earlier release of the Enterprise Manager system because you are upgrading on the same host.

- 2-System upgrade is possible on the same platform as the earlier release of the Enterprise Manager system, and across the following platforms because you are upgrading on a remote host.

- Linux (32-bit) to Linux (64-bit) (or vice versa, even in a virtual environment)

- HP PA-RISC to Linux (32-bit) or Linux (64-bit) (or vice versa)

- HP-UX Itanium to Linux (32-bit) or Linux (64-bit) (or vice versa)

- 1-System upgrade on a different host is possible on the same platform as the earlier release of the Enterprise Manager system, and across the following platforms because you are upgrading on a remote host, much like 2-System upgrade approach.
Linux (32-bit) to Linux (64-bit) (or vice versa) and Microsoft Windows (32-bit) to Microsoft Windows (64-bit) (or vice versa).

- Linux (32-bit) to Linux (64-bit) (or vice versa, even in a virtual environment)

- Microsoft Windows (32-bit) to Microsoft Windows (64-bit) (or vice versa)

- HP PA-RISC to Linux (32-bit) or Linux (64-bit) (or vice versa)

- HP-UX Itanium to Linux (32-bit) or Linux (64-bit) (or vice versa)

Upgrade Scope

The following are some facts about the upgrade approaches:

- You can choose to use either 1-System, 2-System, or 1-System upgrade approach on a different host. However, regardless of the approach you choose, the upgrade operation is always an out-of-place upgrade where you see new Oracle homes of Oracle Management Service (OMS) and Oracle Management Agent (Management Agent).

- The upgrade approaches do NOT upgrade your existing database where the Management Repository is configured.
To upgrade such databases, use the database upgrade tool. For more information, on the upgrade tool, see the Oracle Database Upgrade Guide available in the Oracle Database documentation library at:

http://www.oracle.com/technetwork/indexes/documentation/index.html

- Oracle Management Service 12c communicates only with Oracle Management Agent 12c. Therefore, if you are upgrading Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) and Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then ensure that you first upgrade your Management Agents and then upgrade your OMS.
However, if you are upgrading Enterprise Manager Cloud Control12c Release 1 (12.1.0.1), then ensure that you first upgrade your OMS and then upgrade your Management Agents.

- You can upgrade any Management Agent as long as the Oracle Management Agent 12c software for that platform is available.

- You must not upgrade to Enterprise Manager Cloud Control in a Middleware home that is on an NFS-mounted drive. Upgrading on an NFS-mounted drive causes the Oracle HTTP Server to restart frequently, which in turn makes the OMS inaccessible. If you are forced to upgrade on such a shared drive, then ensure that the OMS instance base directory (gc_inst) is created in a non-NFS-mounted location.

- The Enterprise Manager Cloud Control Installation Wizard installs Java Development Kit (JDK) 1.6 v24 and Oracle WebLogic Server 11g Release 1 (10.3.5) if they do not exist in your environment.

- If Oracle WebLogic Server 11g Release 1 (10.3.5) does not exist, then Oracle recommends you to allow the installation wizard to install it for you. However, if you want to manually install it, then ensure that you install it using JDK 1.6 v24+ (64-bit version for 64-bit platforms and 32-bit version for 32-bit platforms).

- Download JDK 1.6 v24+ for your platform from the platform vendor's Web site.
For example, download SUN JDK 1.6 v24+ for Linux platforms from the following Oracle Web site URL:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

- If you already have JDK, then verify its version by navigating to the <JDK_Location>/bin directory and running the following command:
"./java -fullversion"

To verify whether it is a 32-bit or a 64-bit JDK, run the following command:

"file *"

- JROCKIT is not supported.

- If you want to manually install Oracle WebLogic Server 11g Release 1 (10.3.5) on Linux 64-bit platforms, first install the 64-bit JDK for your platform, and then download and use the wls1035_generic.jar file to install Oracle WebLogic Server.
For example,

<JDK home>/bin/java -d64 -jar <absolute_path _to_wls1035_generic.jar>

- If you want to manually install Oracle WebLogic Server 11g Release 1 (10.3.5) on Linux 32-bit platforms, then download and use either the wls1035_linux32.bin file or the wls1035_generic.jar file.
For example,

<JDK home>/bin/java -jar <absolute_path _to_wls1035_generic.jar>

- You must follow the instructions outlined in the Oracle® Fusion Middleware Installation Guide for Oracle WebLogic Server to install Oracle WebLogic Server. The guide is available in the Fusion Middleware documentation library available at:
http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.html

- You must ensure that the Oracle WebLogic Server installation is a typical installation, and even if you choose to perform a custom installation, ensure that components chosen for custom installation are the same as the ones associated with a typical installation.

- You must ensure that the user installing the WebLogic Server is the same as the one installing Enterprise Manager Cloud Control.

- You must ensure that the Oracle WebLogic Server 11g Release 1 (10.3.5) installed by the Enterprise Manager Cloud Control Installation Wizard or by you is dedicated for Enterprise Manager Cloud Control. You must not have any other Oracle Fusion Middleware product installed in that Middleware home.
Enterprise Manager Cloud Control cannot coexist with any Oracle Fusion Middleware product in the same Middleware home because the ORACLE_COMMON property is used by both the products.

Reusing Existing Ports

When you upgrade your Management Agents, the ports used by the earlier release of the Management Agents are carried over to the upgraded Management Agents. Therefore, your firewall settings are not affected in any way.

When you upgrade your OMS, the following ports are assigned:

- For 2-System upgrade approach, the Enterprise Manager Cloud Control Installation Wizard assigns default ports to all the core components.

- For 1-System upgrade approach, the following is the behavior:

- If you are upgrading 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2), then the ports used by all the core components of the earlier release are carried over.

- If you are upgrading 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1), then the ports used by the following core components of the earlier release are carried over. For the rest of the core components, the Enterprise Manager Cloud Control Installation Wizard assigns default ports, unless other values are provided in the wizard.

- Enterprise Manager Upload HTTP Port

- Enterprise Manager Upload HTTP SSL Port

- Enterprise Manager Central Console HTTP Port

- Enterprise Manager Central Console HTTP SSL Port

- Oracle Management Agent

Note:
For information about the core components, the range within which a port is selected, and the free port that is assigned, see the chapter on installation basics in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

Upgrading Plug-Ins

This section describes the following:

- Upgrading Plug-Ins While Upgrading 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2)

- Upgrading Plug-Ins While Upgrading 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

Upgrading Plug-Ins While Upgrading 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2)

This section describes how plug-ins are upgraded while upgrading Oracle Management Agents 12c Release 1 (12.1.0.1) and Oracle Management Service 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2).

In particular, this section describes the following:

- Upgrading Plug-Ins While Upgrading Oracle Management Agent 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2)

- Upgrading Plug-Ins While Upgrading Oracle Management Service 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2)

Upgrading Plug-Ins While Upgrading Oracle Management Agent 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2)

While upgrading Oracle Management Agents 12c Release 1 (12.1.0.1) using the Upgrade Agents Console, all plug-ins of the earlier release are upgraded by default. No manual effort is required.

Upgrading Plug-Ins While Upgrading Oracle Management Service 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2)

While upgrading Oracle Management Service 12c Release 1 (12.1.0.1) using the Enterprise Manager Cloud Control Installation Wizard, plug-ins are automatically upgraded, migrated, or deployed under the following circumstances:

- Plug-ins are upgraded when newer versions exist

- Plug-ins are migrated when newer versions do not exist

- Plug-ins are deployed when the plug-ins being upgraded have new dependencies

In addition, the installation wizard provides a Plug-In Deployment screen that enables selection of the optional plug-ins you want to deploy in addition to the plug-ins that will automatically be upgraded, migrated, or deployed.

If you want to install plug-ins that are not listed on the Plug-In Deployment screen, then follow these steps:

- Manually download the plug-ins from the Enterprise Manager download page on Oracle Technology Network (OTN), and store them in an accessible location:
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

- Invoke the installer with the following option, and pass the location where the plug-ins you want to install are available:
For UNIX Platforms:

./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

For Microsoft Windows Platforms:

setup.exe -pluginLocation <absolute_path_to_plugin_software_location>

Upgrading Plug-Ins While Upgrading 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

To identify the plug-ins required for upgrade, in the Preupgrade Console, in the Preupgrade Steps section, click Manage Software. On the Manage Software page, view the plug-ins that are required for upgrading your system.

The plug-ins listed on the Manage Software page are based on the targets monitored by the old Management Agents in your existing system, and also based on the new plug-in requirement Enterprise Manager Cloud Control has. You need only the plug-ins listed on this page to successfully upgrade your existing system.

This section describes how you can download and install the required plug-ins while upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1), and Oracle Management Service 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1). In particular, this section covers the following:

- Installing Plug-Ins While Upgrading Oracle Management Agent 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

- Installing Plug-Ins While Upgrading Oracle Management Service 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

Installing Plug-Ins While Upgrading Oracle Management Agent 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

To install the required plug-ins while upgrading the Management Agents, follow these steps:

1. Access the following URL:
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Download the Management Agent software to an accessible location. Do NOT extract the contents of the software ZIP file. The Management Agent software is platform-specific, so ensure that you copy the software for the platform on which you want to install.

3. Download all the required plug-ins to the same location. Plug-ins are generic, so they are common for all platforms.
Ensure that you download all the plug-ins listed as required plug-ins on the Manage Software page, whether or not you want to monitor a target with them. You may feel that a few plug-ins are not required because you do not have targets to be monitored by them, but those plug-ins may be required for upgrading your system. Therefore, download all the plug-ins listed on the Manage Software page. Ensure that you download these plug-ins before backing up the database that contains the Management Repository.

Note:
You can also download these plug-ins from the <software_kit>/plugins directory, but Oracle recommends you to download them from OTN so that you always procure the latest plug-ins and the plug-ins for all platforms.

Note:
To identify what plug-ins are required, in the Preupgrade Console, in the Preupgrade Steps section, from the table, click Manage Software. On the Manage Software page, in the Plug-In Software section, see the required plug-ins.
Download all the plug-ins listed as required plug-ins on the Manage Software page, whether or not you want to monitor a target with them. You may feel that a few plug-ins are not required because you do not have targets to be monitored by them, but those plug-ins may be required for upgrading your system. Therefore, download all the plug-ins listed on the Manage Software page. And ensure that you download these plug-ins before backing up the database that contains the Management Repository.

4. In the Preupgrade Console, on the Manage Software page (Preupgrade Steps section), in the Provide Software Location section, enter the absolute path to the directory where the plug-in is present, and click Validate to register that location with the Management Repository.

See:
For information about registering and validating the plug-in location, see Managing Software.

Installing Plug-Ins While Upgrading Oracle Management Service 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

To install the required plug-ins while upgrading the OMS, invoke the Enterprise Manager Cloud Control Installation Wizard, and proceed to the Plug-In Deployment screen. The screen lists all the required plug-ins you registered via the Preupgrade Console while upgrading the Management Agents. The mandatory ones are selected by default.

Note:
If you had missed registering some required plug-ins, then the wizard prompts you to visit the Preupgrade Console to register them before proceeding with the upgrade.

Ensure that the software for the plug-ins listed on this screen are available in the Enterprise Manager Cloud Control software kit (DVD or downloaded software). If the software for the required plug-ins are not available, then do the following:

- Manually download the plug-ins from the Enterprise Manager download page on Oracle Technology Network (OTN), and store them in an accessible location:
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

- Invoke the installer with the following option, and pass the location where the plug-ins you want to install are available:
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

Using Oracle Software Library

The following is the status of Oracle Software Library (Software Library) after the Enterprise Manager is upgraded:

- For 1-System upgrade approach, the Software Library is functional the moment the Enterprise Manager is upgraded. No manual effort is required to make it functional.

- For 2-System upgrade approach, the Software Library is functional only when it is reconfigured after the Enterprise Manager is upgraded.
To understand the 2-System upgrade approach workflow and to know when you must reconfigure the Software Library, see Getting Started with 2-System Upgrade Approach. For information about reconfiguring the Software Library, see Reconfiguring Oracle Software Library.

- For 1-System upgrade approach on a different host, the Software Library is functional the moment the Enterprise Manager is upgraded.

Using Connectors

After upgrading the entire Enterprise Manager system, the connectors that were configured with your old Enterprise Manager system will continue to work in Enterprise Manager Cloud Control. However, the ones that were not configured will not work.

Updating PDP Configuration File

Enterprise Manager supports Privilege Delegation Providers (PDP) such as SUDO and PowerBroker that enable administrators to restrict certain users from running certain commands. If you have such restrictive PDP configuration setting, then you must ideally enter the location of nmosudo in your configuration file. Management Agent uses nmosudo to run Trusted Jobs in Enterprise Manager.

In Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1], nmosudo was located in the agent instance directory. For example, /u01/oracle/agent/agent_inst/bin/nmosudo.

In Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), this location has changed. Now, nmosudo is present in the sbin directory, which is in the agent base directory. For example, /u01/oracle/agent/sbin/nmosudo.

Therefore, when you install or upgrade to Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), you must modify the PDP configuration files to update the new location of nmosudo.

For example, if you use SUDO as your PDP, the configuration file for sudo is typically /etc/sudoers. In this file, update the following entry with the new location to nmosudo.

sudouser ALL : oracle /eminstall/basedir/sbin/nmosudo *

Managing Notification, Alerts, Jobs, Deployment Procedure Runs, Metrics, EM CLI Clients, Oracle Exadata Targets

Note:
This section is applicable only for upgrade from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1).
You can ignore this section if you are upgrading from Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1).

This section describes some of the critical changes in Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2) that you might see when you upgrade from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1).

In particular, this section describes the following:

- Managing Notification

- Managing Alerts

- Managing Jobs

- Managing Deployment Procedure Runs

- Collecting Metrics

- Upgrading EM CLI Clients

- Upgrading Oracle Exadata Targets

Managing Notification

After upgrade, all notification rules and alerts will continue to work in Enterprise Manager Cloud Control. However, note that they have been enhanced and subsumed into a larger and newer concept—Notification Rules are now called Incident Rulesets, and Alerts are now called Events in Enterprise Manager Cloud Control.

For information about Incident Rulesets and how they map to notification rules, and for information about Events and how they map to alerts, see Appendix B.

Managing Alerts

During upgrade, the alerts from the earlier release are migrated as Events in Enterprise Manager Cloud Control in the following manner. For 1-System upgrade approach, the alerts are migrated while upgrading the Management Repository. For 2-System upgrade approach, the alerts are migrated while backing up the Management Repository to the remote host.

This section covers the following:

- Migrating Alerts

- Creating Incidents and Events for Different Types of Open Alerts

- Creating Incidents and Events for Different Types of Closed Alerts

Migrating Alerts

The following are the ways in which the alerts are migrated:

- All open alerts are migrated.
Table 2-2 shows how and when incidents and events are created for different types of open alerts.

- All alerts that were closed 180 days prior to upgrading or backing up the Management Repository are migrated as part of the Deferred Data Migration Process. This period of 180 days can be changed by the administrator.
Table 2-3 shows how and when incidents and events are created for different types of closed alerts. Also note that if a closed alert had an associated ticket, then that information is not captured as part of the event migration.

- All open statefull alerts, and open stateless alerts created within 7 days prior to upgrading or backing up the Management Repository are migrated.

Note:
In case of 2-System upgrade approach, if an alert is created in the earlier release of the Enterprise Manager system after the Management Repository is backed up, then that open alert is migrated as part of the Accrued Data Migration Process (see Table 2-2). In addition, all availability records are also migrated as part of the Accrued Data Migration Process.

Creating Incidents and Events for Different Types of Open Alerts

Table 2-2 shows how and when incidents and events are created for different types of open alerts.

Table 2-2 Incidents and Events Created for Different Types of Open Alerts

Open Alert Type

Incident Created

Event Created

Critical Alert

Yes

Yes

Warning Alert

No

Yes

Critical Alert with Ticket

Yes

Yes (with Ticket)

Warning Alert with Ticket

Yes

Yes (with Ticket)

Warning Alert with Notification Pending

Yes

Yes

Warning Alert without Notification Pending

No

Yes

Critical Alert with Acknowledgement

Yes

Yes

Warning Alert with Acknowledgement

Yes

Yes

Creating Incidents and Events for Different Types of Closed Alerts

Table 2-3 shows how and when incidents and events are created for different types of closed alerts. Also note that if a closed alert had an associated ticket, then that information is not captured as part of the event migration.

Table 2-3 Incidents and Events Created for Different Types of Closed Alerts

Closed Alert Type

Incident Created

Event Created

Critical Alert

No

Yes

Warning Alert

No

Yes

Critical Alert with Ticket

No

Yes (without Ticket)

Warning Alert with Ticket

No

Yes (without Ticket)

Warning Alert with Notification Pending

No

Yes

Warning Alert without Notification Pending

No

Yes

Critical Alert with Acknowledgement

No

Yes

Warning Alert with Acknowledgement

No

Yes

Managing Jobs

For 1-System upgrade approach, jobs can run more or less as expected. During the downtime, jobs do not run, and any job that is running during the downtime is aborted or failed. In addition, all the scheduled jobs continue as they were planned.

For 2-System upgrade approach, there are some restrictions and caveats on how jobs run. Firstly, since a Management Agent is monitored only by one particular Enterprise Manager system at any point, jobs can run only in the system that monitors the Management Agent. Until a Management Agent is migrated, all jobs against targets monitored by that Management Agent are run in the old Enterprise Manager system. This also means that only one Enterprise Manager system has the true status of a job because the Management Agent communicates only with one of the systems at a given time, so only that Enterprise Manager system knows what the actual status is.

- If a Management Agent is not migrated, then a future job appears as a scheduled job in the old Enterprise Manager system, but appears as a suspended job on the Management Agent unavailable in Enterprise Manager Cloud Control.

- A job running in the old Enterprise Manager system at the time of the backup either aborts or fails in Enterprise Manager Cloud Control. Once the Management Agent is migrated, a future job appears as a suspended job on the Management Agent unavailable in the old Enterprise Manager system, but appears as a scheduled job in Enterprise Manager Cloud Control. If the Management Agent is subsequently removed from the old Enterprise Manager system, then that job is removed as well.
If the backup of the old Enterprise Manager system did not require a downtime, then the jobs running at the time of the backup continue to run. (If the backup required a downtime, then the job may abort due to the downtime.) Such jobs appear as aborted, failed, or skipped jobs in Enterprise Manager Cloud Control.

- Repeating jobs continue to run in the old Enterprise Manager system according to their schedule. In Enterprise Manager Cloud Control, such jobs appear to be aborted, failed, or skipped. Once the Management Agent is migrated, such jobs start to run in Enterprise Manager Cloud Control. In the old Enterprise Manager system, such jobs are suspended on the Management Agent unavailable.

- Jobs submitted in the old Enterprise Manager system after the backup do NOT appear in Enterprise Manager Cloud Control. Jobs submitted in Enterprise Manager Cloud Control do NOT appear in the old Enterprise Manager system. Usually, jobs are created only in the system that is currently monitoring the target.

- Jobs created in the old Enterprise Manager system before the Management Agent of its targets is migrated run in the old Enterprise Manager system as expected.

- Repeating jobs run until the Management Agent is migrated at which point they are stuck as suspended jobs on the Management Agent unavailable.

- If jobs are created in the old Enterprise Manager system after the target is migrated, then they never run; they remain stuck as suspended jobs on the Management Agent unavailable. So do not create a job in the old Enterprise Manager system after the Management Agent is migrated.

- Jobs created in Enterprise Manager Cloud Control on targets for which the Management Agent has already been migrated behave normally and run as expected.

- Jobs can be created in Enterprise Manager Cloud Control before the Management Agent for its target is migrated, but they will be in suspended mode on Management Agent unavailable until the Management Agent is migrated.
This is particularly useful when a new job is created in the old Enterprise Manager system and a copy of it is desired in Enterprise Manager Cloud Control for use after the target is migrated. Usually, this will be a repeating job.

- If the Management Agent is migrated before the scheduled time of the job, then the job runs in Enterprise Manager Cloud Control.

- If the Management Agent is migrated after the scheduled time of the job, then the job is skipped. This is to prevent a case where the job runs on both the systems.

- If the job has a repeating schedule, then the times before the migration are skipped, while the times after the migration are run.

- A job with an immediate schedule does not run in Enterprise Manager Cloud Control and is eventually skipped. So do not create an immediate job on a target that is not migrated.

- For jobs with multiple executions, one job per target, some targets may be suspended, while others run.
Consider a job against two databases, dbA monitored by Management Agent A, and dB monitored by Management Agent B. If only Management Agent B is migrated, then the execution for dbA is suspended, while the execution for dB runs when it reaches its scheduled time. If this is a repeating job, then the execution for dbA is skipped. Once the Management Agent A is migrated, then both executions are run as usual.

This behavior is important for jobs with many targets, such as those submitted to a group. Those executions for targets monitored by the old Enterprise Manager system run in the old Enterprise Manager system, while those for targets monitored by Enterprise Manager Cloud Control run in Enterprise Manager Cloud Control. The corresponding executions on the other systems are suspended or skipped.

- For jobs on multiple targets, one job for many targets, the jobs can neither run in the old Enterprise Manager system nor in Enterprise Manager Cloud Control unless the Management Agents for all the targets are migrated at one time. To determine the correct set of Management Agents to migrate at one time to address this, run the SQL queries described in Appendix D.
The alternative is to migrate the Management Agents independently, and then, once the last Management Agent is migrated, the job may run if the grace period allows it to run or if the scheduled time was after the last agent migration.

Managing Deployment Procedure Runs

After upgrading the entire Enterprise Manager system, none of the old deployment procedure runs will be available in the upgraded Enterprise Manager. If you want to reference any of the old runtime data, then you must use the following EM CLI verb to export all of the runtime data as an XML file.

get_instance_data_xml

Collecting Metrics

Some metrics related to the Oracle Fusion Middleware targets have been renamed in Enterprise Manager Cloud Control. In addition, a few have been introduced. The following are the targets for which the metrics have undergone some changes. For information about the metric changes, see Appendix C.

- Oracle SOA Infrastructure

- Oracle SOA Composite

- Oracle Service Bus

- Oracle WebLogic Server

- JBoss Application Server

- Siebel Enterprise

- Siebel Server

In general, do not modify the metric thresholds after deploying and configuring the Management Agents.

Upgrading EM CLI Clients

You must upgrade all existing EM CLI clients of the earlier release to 12c Release 1 so that they can work with Enterprise Manager Cloud Control. This means, you must discard the old one and set up a new one.

For information about setting up a new EM CLI client, see the Enterprise Manager Command Line Interface Download page within the Cloud Control console. To access that page, in Cloud Control, from the Setup menu, select My Preferences, then select Command Line Interface.

Upgrading Oracle Exadata Targets

Oracle Exadata targets on your existing Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1) are not upgraded by default. You must manually discover them in Enterprise Manager Cloud Control. As a result, you will lose all historical data related to these targets.

Part II

Upgrading 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2)

This part describes how you can upgrade Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1] to Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2).

This part covers the following chapters:

- Chapter 3, "Getting Started"

- Chapter 4, "Upgrading OMS and Management Repository"

- Chapter 5, "Upgrading Oracle Management Agents"

- Chapter 6, "Upgrading ADP and JVMD in Graphical Mode"

3 Getting Started

To upgrade your Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) to Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), follow these steps:

WARNING:

Do not upgrade Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) while it is undergoing a 2-system upgrade from its earlier release. Wait until the upgrade completes fully because there might be some standalone Management Agents in status pending state while the upgrade is in progress.

Table 3-1 Upgrading Enterprise Manager Grid Control with 1-System Upgrade Approach

Step No.

Step

Procedure

Step 1

Prepare Yourself

(a)

Learn about the 1-System upgrade approach.

Upgrading 12c Release 1 (12.1.0.1) [With or without Bundle Patch 1] to 12c Release 2 (12.1.0.2)

(b)

Review the important facts you need to know before you begin.

Chapter 2

Step 2

Upgrade Oracle Management Service and Oracle Management Repository

(a)

Meet the following prerequisites:

- Meet the Oracle Management Service-related prerequisites described in the chapter on installing Enterprise Manager Cloud Control, in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- Ensure that you are upgrading only on the supported platforms as listed in Supported Platforms for Upgrade.

- If you have BI Publisher 11.1.1.5 installed to run on Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1), then stop the BI Publisher Managed Server named BIP using the WebLogic Administration Console. For instructions, refer to the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

- Back up the OMS (the middleware home and the inventory), the Management Repository, and the Software Library. In case the upgrade fails, you can always restore using the backup.
For instructions to back up, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

(b)

Check for any outstanding database service instance creation requests. If there are any requests in progress, allow them to complete. For requests that are scheduled, suspend them.

To do so, follow these steps.

1. In Cloud Control, from the Enterprise menu, select Infrastructure Cloud, then select Self Service Portal.

2. On the Infrastructure Cloud Self Service Portal page, right under the page title, select My Databases to view only database requests.

3. In the Requests table, for requests that are in progress, allow them to complete. For requests that are scheduled, suspend them.
To suspend the scheduled requests, click the request name. Click the Deployment tab. Click the deployment procedure listed there, and suspend it.

(c)

Ensure that the tables in the Management Repository do not have any snapshots created.

To verify this, log in to the Management Repository and run the following SQL query as SYSMAN user:

select master , log_table from all_mview_logs where log_owner='<EM_REPOS_USER>

For example,

select master , log_table from all_mview_logs where log_owner='SYSMAN'

If there are snapshots created in a table, then the query displays the master table and the snapshot details. For example,

SQL> master log_table

em-violations em$violation_log

If there are snapshots, then drop them by running the following command as SYSMAN user:

SQL> Drop snapshot log on <master>

For example,

SQL> Drop snapshot log on em-violations

(d)

Copy the emkey from the existing OMS to the existing Management Repository. To do so, run the following command on the old OMS home you are trying to upgrade:

$<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>]

To verify whether the emkey is copied, run the following command:

<OMS_HOME>/bin/emctl status emkey

If the emkey is copied, then you will see the following message:

The EMKey  is configured properly, but is not secure.
Secure the EMKey by running "emctl config emkey -remove_from_repos".

(e)

Stop the OMS you are about to upgrade and also the other OMS instances that connect to it.

- If you are upgrading in graphical mode, then you can stop the OMS later as described in Step (12) of Upgrading OMS and Management Repository in Graphical Mode.

- If you are installing software only and upgrading later in graphical mode, then you can stop the OMS later as described in Step (4) in Configuring and Upgrading.

- If you are upgrading in silent mode, then stop the OMS now:
First, on the OMS you are upgrading, run the following command to stop the OMS. This command stops only the OMS, and not the Admin Server or any of its associated components. The Admin Server and other associated components must be running so that the WebLogic Server credentials can be validated.

$<OMS_HOME>/bin/emctl stop oms

Then, on all other additional OMS instances, run the following command. This command stops the OMS and other components such as the node manager, which must be down for the upgrade to end successfully.

$<OMS_HOME>/bin/emctl stop oms -all

(f)

Shut down the Management Agent that monitors the Management Services and Repository target.

(g)

Upgrade the OMS and the Management Repository. You can choose to upgrade in graphical or silent mode. You can also choose to install the software binaries at one point and upgrade them later in graphical or silent mode.

If you see an error message stating that you have not copied the emkey, then follow these steps:

1. Copy the emkey from the old OMS to the old Management Repository. To do so, run the following command from the old OMS home you are trying to upgrade:
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc <conndesc> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

Note: Here, the Management Repository details are the details of the existing Management Repository you are trying to upgrade. And <OMS_HOME> is the OMS home you are trying to upgrade.

2. Try upgrading the OMS and the Management Repository again.

IMPORTANT: Upgrade the Management Agent that was installed with the old OMS (that is, central agent) immediately after upgrading the old OMS.

Upgrading OMS and Management Repository in Graphical Mode, Upgrading OMS and Management Repository in Silent Mode, Installing Software Now and Upgrading Later in Graphical Mode, or Installing Software Now and Upgrading Later in Silent Mode

(h)

If you had BI Publisher 11.1.1.5.0 installed to run on Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1), which you had stopped in Step 2 (a), then it is necessary to install and upgrade to BI Publisher 11.1.1.6.0. For instructions, refer to Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

Step 3

Upgrade Oracle Management Agent

(a)

Review the important facts you need to know before you begin upgrading the Management Agents.

Before You Begin

(b)

Meet the prerequisites.

Prerequisites

(c)

Upgrade the Management Agents.

IMPORTANT: Upgrade the Management Agent that was installed with the old OMS (that is, central agent) immediately after upgrading the old OMS

Upgrade Procedure

Step 4

Perform Postupgrade Task

(a)

Perform postupgrade tasks.

Performing General Postupgrade Steps

(b)

Track the status of deferred data migration jobs.

Tracking the Status of Deferred Data Migration Jobs

(c)

(Applicable if you upgrade from 12c Release 1 (12.1.0.1) released in February 2012, April 2012, and July 2012 to 12c Release 2 (12.1.0.2))

Upgrade the existing database plug-in revisions to the latest revision.

Upgrading Oracle Database Plug-Ins

(d)

Upgrade Application Dependency and Performance (ADP) engines and JVM Diagnostics (JVMD) engines

Chapter 6

4 Upgrading OMS and Management Repository

This chapter describes the different ways of upgrading Oracle Management Service 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1] and Oracle Management Repository 12c Release 1 (12.1.0.1). Select the one that best suits your requirement, and follow the instructions outlined in the respective section.

This chapter describes the following:

- Upgrading OMS and Management Repository in Graphical Mode

- Upgrading OMS and Management Repository in Silent Mode

- Installing Software Now and Upgrading Later in Graphical Mode

- Installing Software Now and Upgrading Later in Silent Mode

- Upgrading Multi-OMS Environment

Note:
Oracle Management Agent (Management Agent) that was installed with the Oracle Management Service (OMS) is not upgraded by default. You must upgrade it (along with other Management Agents) using the Upgrade Agents Console. This is an expected behavior. For instructions to use the Upgrade Agents Console to upgrade Management Agents, see Chapter 5.

WARNING:

Do not upgrade Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) while it is undergoing a 2-system upgrade from its earlier release. Wait until the upgrade completes fully because there might be some standalone Management Agents in status pending state while the upgrade is in progress.

Upgrading OMS and Management Repository in Graphical Mode

To upgrade your Oracle Management Service 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1] and Oracle Management Repository 12c Release 1 (12.1.0.1) in graphical mode, follow these steps:

WARNING:

Do not upgrade Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) while it is undergoing a 2-system upgrade from its earlier release. Wait until the upgrade completes fully because there might be some standalone Management Agents in status pending state while the upgrade is in progress.

Note:
While upgrading, you might see an error message stating that some Management Agents are still in Activation Pending state, or that the Deferred Data Migration Process (DDMP) or Accrued Data Migration Process (ADMP) is not complete. This indicates that the earlier release of the Enterprise Manager system is still undergoing a 2-system upgrade to 12c Release 1 (12.1.0.1).
To resolve this issue, wait until the DDMP and ADMP jobs are complete, and all Management Agents are switched over from the earlier release to 12c Release 1 (12.1.0.1). Then upgrade 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2).

If you are sure you do not want to switch over some Management Agents from the earlier release to 12c Release 1 (12.1.0.1), then delete such unwanted Management Agents as described in Deleting Unwanted Management Agents, before you start the upgrade process.

Note:
If you see an error message stating that you have not copied the emkey, run the following command.
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <repository_host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

(Here, the Management Repository details are details of the existing or old Management Repository. And when you run this command, you might be prompted for the admin server password.)

Caution:
Ensure that you use VNC Server to connect to the remote host while upgrading the OMS and the Management Repository. Other tools, such as cygwin, putty, and so on, sometimes time out or do not allow new Xdisplay connections, thus resulting in upgrade failures.

1. Invoke the Enterprise Manager Cloud Control Installation Wizard on the host where your existing OMS is running.
<Software_Location>/runInstaller [-invPtrLoc <absolute_path_to_oraInst.loc>]

In this command, <Software_Location> refers to the location where you have extracted the software kit.

Note:

- For information about the additional, advanced options you can pass while invoking the installer, refer to Advanced Installer Options for Graphical Mode.

- To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

- When you invoke runInstaller or setup.exe, if the Enterprise Manager Cloud Control Installation Wizard does not appear, then it is possible that you do not have access to the /stage directory.
There is a classpath variable that the installation wizard computes for OPatch as ../stage/Components/, and when the TEMP variable is set to /tmp, the installation wizard tries to look for the opatch JAR file in the /tmp/../stage directory, which is equivalent to /stage. However, if you do not have the permission on /stage, then the installation wizard can hang. Under such circumstances, verify if you have access to the /stage directory. If you do not have access to it, then set the TEMP variable to a location where the install user has access, and then relaunch the installation wizard.

2. (Optional) On the My Oracle Support Details screen, enter your My Oracle Support credentials to enable Oracle Configuration Manager. If you do not want to enable Oracle Configuration Manager now, go to Step (3).
If the host from where you are running the installation wizard does not have a connection to the Internet, then enter only the e-mail address and leave the other fields blank. After you complete the installation, manually collect the configuration information and upload it to My Oracle Support.

3. Click Next.

4. On the Software Updates screen, select one of the following sources from where the software updates can be installed while the Enterprise Manager system gets upgraded. If you do not want to apply them now, then select Skip.

- (Recommended) Select Search for Updates, and then, select Local Directory if you have already manually downloaded the software updates to an accessible local or remote location.
Enter the location where the updates are available, and click Search for Updates. To search the computer and select the location, click Browse. Once the search results appear with patch numbers and their details, click the patch number to view the ReadMe associated with that patch.

- If the updates have been downloaded to the default location, then select or enter the full path to the scratch path location. For example, if the scratch path location is /scratch/OracleHomes and if the software updates are available in /scratch/OracleHomes/Updates, then enter /scratch/OracleHomes/Updates.

- If the software updates have been downloaded to a custom location, then select or enter the full path to the custom location. For example, if the custom location is /home/john and if the software updates are available in /home/john/Updates, then enter /home/john/Updates.

- Select Search for Updates, and then, select My Oracle Support if you want the installer to connect to My Oracle Support and automatically download the updates from there.
Enter the My Oracle Support account user name and password, and click Search for Updates. Once the search results appear with patch numbers and their details, click the patch number to view the ReadMe associated with that patch

Note:
If you choose to skip installing the software updates during installation by not providing the My Oracle Support credentials, you can always register the credentials later using the Enterprise Manager Cloud Control console and view the recommended security patches. To do so, log in to Enterprise Manager Cloud Control, and from the Setup menu, select My Oracle Support, and then, click Set Credentials. On the My Oracle Support Preferred Credentials page, enter the credentials and click Apply.

5. Click Next.

6. On the Prerequisite Checks screen, check the status of the prerequisite checks run by the installation wizard, and verify whether your environment meets all the minimum requirements for a successful upgrade.
The installation wizard runs the prerequisite checks automatically when you come to this screen. It checks for the required operating system patches, operating system packages, and so on.

The status of the prerequisite check can be either Warning, Failed, or Succeeded.

If some checks result in Warning or Failed status, then investigate and correct the problems before you proceed with the upgrade. The screen provides details on why the prerequisites failed and how you can resolve them. After you correct the problems, return to this screen and click Rerun to check the prerequisites again.

If you prefer to hide the successful checks and view only the ones with Warning or Failed status, then click Hide Successful Checks.

7. Click Next.

8. On the Installation Types screen, select Upgrade an Existing Enterprise Manager System, then select One System Upgrade. Then, select the OMS home you want to upgrade.

9. Click Next.

10. On the Installation Details screen, do the following:

1. Enter or validate the Middleware home.

Note:

- Upgrade to 12c Release 2 (12.1.0.2) is an out-of-place upgrade, therefore you must either select an existing middleware home (where Enterprise Manager is not already installed) or enter a new middleware home where Oracle WebLogic Server and Java Development Kit are installed.

- If you do not have Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24+ installed, then enter the absolute path to a directory where you want the installer to install them. For example, /oracle/software/. Ensure that the directory you enter does not contain any files or subdirectories.

- If you have Oracle WebLogic Server and JDK already installed, then ensure that they are of the supported releases—Oracle WebLogic Server 11g Release 1 (10.3.5) and JDK 1.6 v24+. In this case, the installer detects them and displays the Middleware home where they are installed. Validate the path to this Middleware home. The installer detects and displays only those Middleware homes where Enterprise Manager is not already configured.

2. Validate the host name. By default, the host name is the name of the host where the existing, earlier release of Enterprise Manager was installed. This is a non-editable field.

11. Click Next.

12. On the Database Connection Details screen, enter the passwords for the SYS and SYSMAN user accounts of the database that houses the Management Repository for the selected OMS.

Note:

- If a prerequisite check fails stating that you must check if there are any outstanding database service instance creation requests or cleanup executions, follow these steps:

1. In Cloud Control, from the Enterprise menu, select Infrastructure Cloud, then select Self Service Portal.

2. On the Infrastructure Cloud Self Service Portal page, right under the page title, select My Databases to view only database requests.

3. In the Requests table, for requests that are in progress, allow them to complete. For requests that are scheduled, suspend them.
To suspend the scheduled requests, click the request name. Click the Deployment tab. Click the deployment procedure listed there, and suspend it.

- Before you proceed to the next screen, stop all the associated OMS instances.
First, on the OMS you are upgrading, run the following command to . This command stops only the OMS, and not the Admin Server or any of its associated components. The Admin Server and other associated components must be running so that the credentials collected in Step (18) can be validated.

$<OMS_HOME>/bin/emctl stop oms

Then, on all other additional OMS instances, run the following command. This command stops the OMS and other components such as the node manager, which must be down for the upgrade to end successfully.

$<OMS_HOME>/bin/emctl stop oms -all

13. Click Next.

Note:
If you encounter a Provisioning Archive Framework (PAF) prerequisite check error, then exit the installer, stop all the running and scheduled deployment procedures in your existing Enterprise Manager system, invoke the installer all over again, and retry the upgrade process.

14. On the Plug-In Upgrade screen, review the plug-ins that will be automatically:

- Upgraded when newer versions exist

- Migrated when newer versions do not exist

- Deployed when the plug-ins being upgraded have new dependencies

Here, newer versions refer to the newer versions of plug-ins available in the Enterprise Manager software (DVD, or downloaded software) that you are using to install.

Note:
If the newer versions do not exist in the Enterprise Manager software that you are using, but exist on Oracle Technology Network (OTN), then you can choose to manually download them from OTN and upgrade your existing plug-ins, instead of having them automatically migrated by default. To do so, follow these steps:

1. Manually download the plug-ins from the Enterprise Manager download page on OTN, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the installer with the following option, and pass the location where the plug-ins you downloaded are available:
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

Once the newer versions of the plug-ins are made available, this screen lists those plug-ins as plug-ins that will automatically be upgraded.

15. Click Next.

16. On the Plug-In Deployment screen, select the optional plug-ins you want to deploy in addition to the plug-ins that will automatically be upgraded while upgrading the OMS.

Note:
If you want to install some plug-ins that are not listed on this screen, then follow these steps:

1. Manually download the plug-ins from the Enterprise Manager download page on OTN, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the installer with the following option, and pass the location where the plug-ins you downloaded are available:
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

17. Click Next.

18. On the Extend WebLogic Server Domain screen, do the following to create a new WebLogic domain and a new OMS instance base directory for the upgraded OMS:

- Validate the AdminServer host name and its port, and the WebLogic user name, and enter the WebLogic user account password. This is required to create a new WebLogic domain (GCDomain) on the same port and host name as the AdminServer used by the earlier release of the OMS you are upgrading.

Note:
If you are upgrading an additional OMS, then enter the host name and port of the AdminServer configured for the first OMS that you have already upgraded, and then, enter the credentials for the existing WebLogic Server user account.
The host name is the name of the host where the first OMS is running. To identify the port, check the value set to the parameter AS_HTTPS_PORT in the following file:

<ORACLE_HOME>/gc_inst/em/EMGC_OMS<n>/emgc.properties

- Enter the absolute path to the new OMS instance base directory (gc_inst), which will be created for storing the configuration information related to the upgraded OMS. Make sure the path you enter leads up to the instance base directory. You can maintain this directory inside or outside the middleware home. However, Oracle recommends that you maintain this directory inside the middleware home.
For example, /u01/app/Oracle/Middleware/gc_inst.

19. Click Next.

20. On the Review screen, review the details you have provided for the upgrade.

1. If you want to change the details, click Back repeatedly until you reach the screen where you want to make the changes.

2. After you verify the details, if you are satisfied, click Install to begin the upgrade.

21. On the Install Progress screen, view the overall progress (in percentage) of the upgrade operation and the status of each of the Configuration Assistants.

Note:
If a Configuration Assistant fails, the installer stops and none of the subsequent Configuration Assistants are run until the issue related to the failed Configuration Assistant is resolved. In this case, diagnose the issue, resolve it, and then, click Retry on the Install Progress screen to rerun the Configuration Assistants starting from the Configuration Assistant that failed.
However, if you accidently exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script from the OMS home to rerun the Configuration Assistant in silent mode:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, raise a service request and contact Oracle Support.

22. Once the software binaries are copied and configured, you are prompted to run the allroot.sh script. Open another window, log in as root, and manually run the scripts.
If you are installing on Microsoft Windows operating system, then you will NOT be prompted to run this script.

23. On the Finish screen, you should see information pertaining to the upgrade of Enterprise Manager. Review the information and click Close to exit the wizard.

24. If you upgraded an additional OMS (11.1.0.1 or 12.1.0.1), then note that the OMS name changes and the configuration changes are made to the Oracle WebLogic domain that hosts Enterprise Manager. However, these configuration changes are not reflected in the Enterprise Manager Cloud Control Console until you refresh the WebLogic domain configuration within the console.
To refresh the WebLogic domain, follow these steps:

1. Navigate to the home page of the Oracle WebLogic domain that hosts Enterprise Manager.

2. From the WebLogic Domain menu, select Refresh WebLogic Domain. The Refresh WebLogic Domain page appears.

3. Follow the instructions on the Refresh WebLogic Domain page to refresh the WebLogic domain.

WARNING:

If you do not refresh the WebLogic domain, you will see the old OMS target on the WebLogic domain home page.

If you have a JVM Agent deployed, then you will see the old OMS target even on the Deploy/Upgrade Diagnostic Agent : Select Targets page while upgrading the JVM Agent.

Make sure you follow this step to clear the old OMS target from the Enterprise Manager Cloud Control Console.

Caution:
If you have any JVM targets associated with the old OMS, then even after you refresh the WebLogic domain, on the WebLogic domain home page, you will continue see the JVM target that was associated with the old OMS. This is an expected behavior.
If you choose to either retain it for viewing historical data or delete it. To delete it, right-click the orphaned JVM target, and select Remove Target.

25. Ensure that you upgrade the Management Agent that was installed with the old OMS (that is, central agent) immediately after upgrading the old OMS. For more information, refer to Chapter 5.

Advanced Installer Options for Graphical Mode

The following are some additional, advanced options you can pass while invoking the installer in graphical mode:

- (Applicable only for when you upgrade 10.2.0.5), When you upgrade 10g Release 5 (10.2.0.5), a new WebLogic domain named GCDomain is created by default. If you want to override this with a custom name, then invoke the installer with the WLS_DOMAIN_NAME option, and enter a unique custom name.
For example, if you want to use the custom name EMDomain, then run the following command:

./runInstaller WLS_DOMAIN_NAME=EMDomain

- By default, a Provisioning Advisor Framework (PAF) staging directory is created for copying the Software Library entities related to the deployment procedures. By default, this location is the scratch path location (/tmp). The location is used only for provisioning activities—entities are copied for a deployment procedure, and then, deleted once the deployment procedure ends.
If you want to override this location with a custom location, then invoke the installer with the EM_STAGE_DIR option, and enter a unique custom location.

For example,

./runInstaller EM_STAGE_DIR=/home/john/software/oracle/pafdir

- During upgrade, if you want to install some plug-ins that are not in the software kit (DVD, downloaded software), then follow these steps:

1. Manually download the plug-ins from the following URL, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the installer with the following option, and pass the location where the plug-ins you want to install are available:
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

This displays a list of plug-ins available in the software kit (DVD, downloaded software) as well as the plug-ins available in this custom location. You can choose the ones you want to install.

- After the upgrade operation ends successfully, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the installer with START_OMS and b_startAgent options, and set them to true or false depending on what you want to control.
For example, if you do not want the Management Agent to start automatically, then run the following command:

./runInstaller START_OMS=true b_startAgent=false

To understand the limitations involved with this advanced option, see Limitations.

Limitations

When you use START_OMS and b_startAgent as advanced options to control the way the OMS and the Management Agent start up automatically, sometimes the Management Agent and the host on which it was installed do not appear as targets in the Cloud Control console.

Table 4-1 lists the different combinations of these advanced options, and describes the workaround to be followed for each combination:

Table 4-1 Advanced Options and Workarounds

Advanced Option

Workaround

START_OMS=false

b_startAgent=false

1. Start the OMS:
$<OMS_HOME>/bin/emctl start oms

2. Secure the Management Agent:
$<AGENT_HOME>/bin/emctl secure agent

3. Start the Management Agent:
$<AGENT_HOME>/bin/emctl start agent

4. Add the targets:
$<AGENT_HOME>/bin/emctl config agent addinternaltargets

5. Upload the targets:
$<AGENT_HOME>/bin/emctl upload agent

6. Manually configure the EM CLI tool in the $<ORACLE_HOME>/bin directory. To do so, refer to the Oracle Enterprise Manager Command Line Interface Guide.

START_OMS=true

b_startAgent=false

Start the Management Agent:

$<AGENT_HOME>/bin/emctl start agent

START_OMS=false

b_startAgent=true

1. Start the OMS:
$<OMS_HOME>/bin/emctl start oms

2. Secure the Management Agent:
$<AGENT_HOME>/bin/emctl secure agent

3. Add the targets:
$<AGENT_HOME>/bin/emctl config agent addinternaltargets

4. Upload the targets:
$<AGENT_HOME>/bin/emctl upload agent

5. Manually configure the EM CLI tool in the $<ORACLE_HOME>/bin directory. To do so, refer to the Oracle Enterprise Manager Command Line Interface Guide.

Deleting Unwanted Management Agents

While upgrading, you might see an error message stating that some Management Agents are still in Activation Pending state, or that the Deferred Data Migration Process (DDMP) or Accrued Data Migration Process (ADMP) is not complete. This indicates that the earlier release of the Enterprise Manager system is still undergoing a 2-system upgrade to 12c Release 1 (12.1.0.1).

To resolve this issue, wait until the DDMP and ADMP jobs are complete, and all Management Agents are switched over from the earlier release to 12c Release 1 (12.1.0.1). Then upgrade 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2).

If you are sure you do not want to switch over some Management Agents from the earlier release to 12c Release 1 (12.1.0.1), then delete such unwanted Management Agents before you start the upgrade process.

To delete these unwanted Management Agents, follow these steps:

1. Identify the unwanted Management Agents, which you have not switched over, by running the following query:

select mt.target_name from sysman.mgmt_targets mt, sysman.em_current_availability eca, sysman.PRE_UPGC_AGT_STAT_MGMT puasm
where mt.target_guid = eca.target_guid
and eca.current_status = 4
and eca.current_sub_status = 1
and mt.target_type='oracle_emd'
and puasm.target_guid = mt.target_guid and puasm.UPGRADE_STATUS != 'IGNORE_UPGRADE'
and mt.emd_url not in (select emd_url from PRE_UPGC_TGT_SW where target_type='oracle_emrep')
and mt.emd_url not in (select emd_url from mgmt_targets where target_name in(select value from mgmt_oms_parameters where name = 'HOST_NAME'))
and mt.emd_url not in (select distinct emd_url from mgmt_targets where target_name like 'EnterpriseManager%home' or target_name like '%GCD omain_EMGC_OMS%')

2. Delete the unwanted Management Agents:

1. On the upgrade OMS host, from the OMS home, log in to the EM CLI client. EM CLI Client is available by default with every OMS installation, so you need not install the client separately.
$<OMS_HOME>/bin/emcli login -username=SYSMAN -password=<sysman-passwd>

2. Synchronize EM CLI:
$<OMS_HOME>/bin/emcli sync

3. Delete the unwanted Management Agents. Here, agentName is the name of the Management Agent you want to delete.
$<OMS_HOME>/bin/emcli delete_target -name = <agentName> -type=oracle_emd -delete_monitored_targets

3. Proceed with the upgrade to 12c Release 2 (12.1.0.2).

Note:
If, for some reason, you are unable to delete the unwanted Management Agents, then turn off the sanity check that checks for Managements Agents with Activation Pending state. This enables you to proceed with the upgrade process without encountering any such warning. To turn off the sanity check, run the query as described in Appendix K.

Upgrading OMS and Management Repository in Silent Mode

To upgrade your Oracle Management Service 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1] and Oracle Management Repository 12c Release 1 (12.1.0.1) in silent mode, follow these steps:

WARNING:

Do not upgrade Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) while it is undergoing a 2-system upgrade from its earlier release. Wait until the upgrade completes fully because there might be some standalone Management Agents in status pending state while the upgrade is in progress.

Note:
While upgrading, you might see an error message stating that some Management Agents are still in Activation Pending state, or that the Deferred Data Migration Process (DDMP) or Accrued Data Migration Process (ADMP) is not complete. This indicates that the earlier release of the Enterprise Manager system is still undergoing a 2-system upgrade to 12c Release 1 (12.1.0.1).
To resolve this issue, wait until the DDMP and ADMP jobs are complete, and all Management Agents are switched over from the earlier release to 12c Release 1 (12.1.0.1). Then upgrade 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2).

If you are sure you do not want to switch over some Management Agents from the earlier release to 12c Release 1 (12.1.0.1), then delete such unwanted Management Agents as described in Deleting Unwanted Management Agents, before you start the upgrade process.

Note:
If you see an error message stating that you have not copied the emkey, run the following command.
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <repository_host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

(Here, the Management Repository details are details of the existing or old Management Repository. And when you run this command, you might be prompted for the admin server password.)

Caution:
Ensure that you use VNC Server to connect to the remote host while upgrading the OMS and the Management Repository. Other tools, such as cygwin, putty, and so on, sometimes time out or do not allow new Xdisplay connections, thus resulting in upgrade failures.

1. Copy the following response file to an accessible location on your local host:
<Software_Location>/response/upgrade.rsp

In this command, <Software_Location> refers to the location where you have extracted the software kit (DVD, or downloaded software).

2. Edit the response file and enter appropriate values for the variables described in Appendix A.

3. Invoke the installer:
./runInstaller -silent -responseFile <absolute_path>/upgrade.rsp

Note:

- To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

- For information about the additional, advanced options you can pass while invoking the installer, refer to Advanced Installer Options for Silent Mode.

4. If you upgraded an additional OMS (11.1.0.1 or 12.1.0.1), then note that the OMS name changes and the configuration changes are made to the Oracle WebLogic domain that hosts Enterprise Manager. However, these configuration changes are not reflected in the Enterprise Manager Cloud Control Console until you refresh the WebLogic domain configuration within the console.
To refresh the WebLogic domain, follow these steps:

1. Navigate to the home page of the Oracle WebLogic domain that hosts Enterprise Manager.

2. From the WebLogic Domain menu, select Refresh WebLogic Domain. The Refresh WebLogic Domain page appears.

3. Follow the instructions on the Refresh WebLogic Domain page to refresh the WebLogic domain.

WARNING:

If you do not refresh the WebLogic domain, you will see the old OMS target on the WebLogic domain home page.

(Applicable only for 12.1.01 to 12.1.0.2 Upgrade) If you have a JVM Agent deployed, then you will see the old OMS target even on the Deploy/Upgrade Diagnostic Agent : Select Targets page while upgrading the JVM Agent.

Make sure you follow this step to clear the old OMS target from the Enterprise Manager Cloud Control Console.

Caution:
(Applicable only for 12.1.01 to 12.1.0.2 Upgrade) If you have any JVM targets associated with the old OMS, then even after you refresh the WebLogic domain, on the WebLogic domain home page, you will continue see the JVM target that was associated with the old OMS. This is an expected behavior.
If you choose to either retain it for viewing historical data or delete it. To delete it, right-click the orphaned JVM target, and select Remove Target.

5. Ensure that you upgrade the Management Agent that was installed with the old OMS (that is, central agent) immediately after upgrading the old OMS. For more information, refer to Chapter 5.

Advanced Installer Options for Silent Mode

The following are some additional, advanced options you can pass while invoking the installer in silent mode:

- (Applicable only for 2-system upgrade from 10.2.0.5 or 11.1.0.1) If you are upgrading on a host that has multiple host names (for examle, virtual host), then pass the fully qualified host name using the ORACLE_HOSTNAME argument while invoking the installer.
For example:

./runInstaller ORACLE_HOSTNAME=example.com -silent -responseFile <absolute_path>/upgrade.rsp

- After the installation ends successfully, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the installer with START_OMS and b_startAgent options, and set them to true or false depending on what you want to control.
For example, if you do not want the Management Agent to start automatically, then run the following command:

./runInstaller START_OMS=true b_startAgent=false -silent -responseFile <absolute_path>/upgrade.rsp

To understand the limitations involved with this advanced option, see Limitations.

Installing Software Now and Upgrading Later in Graphical Mode

This section describes how you can install only the software binaries of Enterprise Manager 12c Cloud Control in graphical mode at one point, and upgrade them at a later point. In particular, this section covers the following:

- Installing Software Binaries

- Running allroot.sh Script

- Configuring and Upgrading

WARNING:

Do not upgrade Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) while it is undergoing a 2-system upgrade from its earlier release. Wait until the upgrade completes fully because there might be some standalone Management Agents in status pending state while the upgrade is in progress.

Note:
While upgrading, you might see an error message stating that some Management Agents are still in Activation Pending state, or that the Deferred Data Migration Process (DDMP) or Accrued Data Migration Process (ADMP) is not complete. This indicates that the earlier release of the Enterprise Manager system is still undergoing a 2-system upgrade to 12c Release 1 (12.1.0.1).
To resolve this issue, wait until the DDMP and ADMP jobs are complete, and all Management Agents are switched over from the earlier release to 12c Release 1 (12.1.0.1). Then upgrade 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2).

If you are sure you do not want to switch over some Management Agents from the earlier release to 12c Release 1 (12.1.0.1), then delete such unwanted Management Agents as described in Deleting Unwanted Management Agents, before you start the upgrade process.

Note:
If you see an error message stating that you have not copied the emkey, run the following command.
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <repository_host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

(Here, the Management Repository details are details of the existing or old Management Repository. And when you run this command, you might be prompted for the admin server password.)

Caution:
Ensure that you use VNC Server to connect to the remote host while upgrading the OMS and the Management Repository. Other tools, such as cygwin, putty, and so on, sometimes time out or do not allow new Xdisplay connections, thus resulting in upgrade failures.

Installing Software Binaries

To install the software binaries of Enterprise Manager Cloud Control, follow these steps:

1. Invoke the Enterprise Manager Cloud Control Installation Wizard on the host where your existing OMS is running.
<Software_Location>/runInstaller [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- In this command, <Software_Location> refers to the location where you have extracted the software kit.

- To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

- The central inventory location you enter must NOT be on a shared file system.

Note:
When you invoke runInstaller or setup.exe, if the Enterprise Manager Cloud Control Installation Wizard does not appear, then it is possible that you do not have access to the /stage directory.
There is a classpath variable that the installation wizard computes for OPatch as ../stage/Components/, and when the TEMP variable is set to /tmp, the installation wizard tries to look for the opatch JAR file in the /tmp/../stage directory, which is equivalent to /stage. However, if you do not have the permission on /stage, then the installation wizard can hang. Under such circumstances, verify if you have access to the /stage directory. If you do not have access to it, then set the TEMP variable to a location where the install user has access, and then relaunch the installation wizard.

2. (Optional) On the My Oracle Support Details screen, enter your My Oracle Support credentials to enable Oracle Configuration Manager. If you do not want to enable Oracle Configuration Manager now, go to Step (3).
If the host from where you are running the installation wizard does not have a connection to the Internet, then enter only the e-mail address and leave the other fields blank. After you complete the installation, manually collect the configuration information and upload it to My Oracle Support.

3. Click Next.

4. On the Software Updates screen, select one of the following sources from where the software updates can be installed while the Enterprise Manager system gets upgraded. If you do not want to apply them now, then select Skip.

- (Recommended) Select Search for Updates, and then, select Local Directory if you have already manually downloaded the software updates to an accessible local or remote location.
Enter the location where the updates are available, and click Search for Updates. To search the computer and select the location, click Browse. Once the search results appear with patch numbers and their details, click the patch number to view the ReadMe associated with that patch.

- If the updates have been downloaded to the default location, then select or enter the full path to the scratch path location. For example, if the scratch path location is /scratch/OracleHomes and if the software updates are available in /scratch/OracleHomes/Updates, then enter /scratch/OracleHomes/Updates.

- If the software updates have been downloaded to a custom location, then select or enter the full path to the custom location. For example, if the custom location is /home/john and if the software updates are available in /home/john/Updates, then enter /home/john/Updates.

- Select Search for Updates, and then, select My Oracle Support if you want the installer to connect to My Oracle Support and automatically download the updates from there.
Enter the My Oracle Support account user name and password, and click Search for Updates. Once the search results appear with patch numbers and their details, click the patch number to view the ReadMe associated with that patch

Note:
If you choose to skip installing the software updates during installation by not providing the My Oracle Support credentials, you can always register the credentials later using the Enterprise Manager Cloud Control console and view the recommended security patches. To do so, log in to Enterprise Manager Cloud Control, and from the Setup menu, select My Oracle Support, and then, click Set Credentials. On the My Oracle Support Preferred Credentials page, enter the credentials and click Apply.

5. Click Next.

6. On the Prerequisite Checks screen, check the status of the prerequisite checks run by the installation wizard, and verify whether your environment meets all the minimum requirements for a successful upgrade.
The installation wizard runs the prerequisite checks automatically when you come to this screen. It checks for the required operating system patches, operating system packages, and so on.

The status of the prerequisite check can be either Warning, Failed, or Succeeded.

If some checks result in Warning or Failed status, then investigate and correct the problems before you proceed with the upgrade. The screen provides details on why the prerequisites failed and how you can resolve them. After you correct the problems, return to this screen and click Rerun to check the prerequisites again.

If you prefer to hide the successful checks and view only the ones with Warning or Failed status, then click Hide Successful Checks.

7. Click Next.

8. On the Installation Types screen, select Install software only.

9. Click Next.

10. On the Installation Details screen, do the following:

1. Enter or validate or enter the Middleware home.

Note:

- Upgrade to 12c Release 2 (12.1.0.2) is an out-of-place upgrade, therefore you must either select an existing middleware home or enter a new middleware home where Oracle WebLogic Server and Java Development Kit are installed.

- If you do not have Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24+ installed, then enter the absolute path to a directory where you want the installer to install them. For example, /oracle/software/. Ensure that the directory you enter does not contain any files or subdirectories.

- If you have Oracle WebLogic Server and JDK already installed, then ensure that they are of the supported releases—Oracle WebLogic Server 11g Release 1 (10.3.5) and JDK 1.6 v24+. In this case, the installer detects them and displays the Middleware home where they are installed. Validate the path to this Middleware home. The installer detects and displays only those Middleware homes where Enterprise Manager is not already configured.

2. Enter the absolute path to the agent base directory, a location outside the Oracle Middleware home where the Management Agent can be installed. For example, /oracle/agent. Ensure that this location is empty and has write permission. Also ensure that it is always maintained outside the Oracle Middleware home.

Note:
This is a mandatory field although the Management Agent installed with the OMS is not required, and must be deinstalled as described in Step (15).

3. Validate the host name. By default, the host name is the name of the host where the existing, earlier release of Enterprise Manager was installed. This is a non-editable field.

11. Click Next.

12. On the Review screen, review the details you provided for the selected installation type.

- If you want to change the details, click Back repeatedly until you reach the screen where you want to make the changes.

- After you verify the details, if you are satisfied, click Install to begin the installation process.

13. On the Install Progress screen, view the overall progress (in percentage) of the installation.

14. On the Finish screen, you should see information pertaining to the installation of Enterprise Manager. Review the information and click Close to exit the installation wizard.

15. Deinstall the Management Agent. For instructions, refer to the chapter on deinstalling a Management Agent in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

Note:
The Management Agent installed with the OMS is a fresh installation, and therefore is not required.

- If you are upgrading from 12c Release 1 (12.1.0.1), then you must upgrade your Management Agent using the Upgrade Agents Console. For instructions to use the Upgrade Agents Console to upgrade Management Agents, see Chapter 5 .

- If you are upgrading 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1), then you already have the Management Agent predeployed by the Preupgrade Console.

Running allroot.sh Script

(For UNIX Only) After you install the software binaries, log in as a root user in a new terminal and run the allroot.sh script from the OMS home:

$<OMS_HOME>/allroot.sh

Configuring and Upgrading

To configure the software binaries of Enterprise Manager Cloud Control, follow these steps:

1. Invoke the installation wizard by running the following script:
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- On Microsoft Windows, run ConfigureGC.bat.

- While installing the software binaries as described in Installing Software Binaries, if you had passed the argument -invPtrLoc, then pass the same argument here as well.

- For information about the additional, advanced options you can pass while invoking the script, refer to Advanced Script Options for Software-Only Mode.

2. On the Install Types screen, do the following:

1. Select Upgrade an Existing Enterprise Manager System, and then, select One System Upgrade.

2. Select the OMS home you want to upgrade.

3. Click Next.

4. On the Database Connection Details screen, enter the passwords for the SYS and SYSMAN user accounts of the database that houses the Management Repository for the selected OMS.

Note:

- If a prerequisite check fails stating that you must check if there are any outstanding database service instance creation requests or cleanup executions, follow these steps:

1. In Cloud Control, from the Enterprise menu, select Infrastructure Cloud, then select Self Service Portal.

2. On the Infrastructure Cloud Self Service Portal page, right under the page title, select My Databases to view only database requests.

3. In the Requests table, for requests that are in progress, allow them to complete. For requests that are scheduled, suspend them.
To suspend the scheduled requests, click the request name. Click the Deployment tab. Click the deployment procedure listed there, and suspend it.

- Before you proceed to the next screen, stop all the associated OMS instances.
First, on the OMS you are upgrading, run the following command to . This command stops only the OMS, and not the Admin Server or any of its associated components. The Admin Server and other associated components must be running so that the credentials collected in Step (10) can be validated.

$<OMS_HOME>/bin/emctl stop oms

Then, on all other additional OMS instances, run the following command. This command stops the OMS and other components such as the node manager, which must be down for the upgrade to end successfully.

$<OMS_HOME>/bin/emctl stop oms -all

5. Click Next.

Note:
If you see an error about missing plug-ins, then do the following:

1. Make a note of the plug-in version and plug-in update as shown in the missing plug-ins error message. The plug-ins displayed in the error message have the following format:
PluginID:PluginVersion:PluginUpdate

2. Manually download the same plug-in version and the same or higher plug-in update as shown in the missing plug-ins error message, from the following URL.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

Store the plug-ins in an accessible location, and ensure that the location is meant only for these missing plug-ins.

3. Invoke the ConfigureGC.sh script in the following way to install the downloaded plug-ins:
<OMS_HOME>/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_sw>

Proceed to the next step only after you have installed these missing plug-ins.

6. On the Plug-In Upgrade screen, review the plug-ins that will be automatically:

- Upgraded when newer versions exist

- Migrated when newer versions do not exist

- Deployed when the plug-ins being upgraded have new dependencies

Here, newer versions refer to the newer versions of plug-ins available in the Enterprise Manager software (DVD, or downloaded software) that you are using to install.

Note:
If the newer versions do not exist in the Enterprise Manager software that you are using, but exist on OTN, then you can choose to manually download them from OTN and upgrade your existing plug-ins, instead of having them automatically migrated by default. To do so, follow these steps:

1. Manually download the plug-ins from the Enterprise Manager download page on OTN, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the installer with the following option, and pass the location where the plug-ins you downloaded are available:
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_software_location>

Once the newer versions of the plug-ins are made available, this screen lists those plug-ins as plug-ins that will automatically be upgraded.

7. Click Next.

8. On the Plug-In Deployment screen, select the optional plug-ins you want to deploy in addition to the plug-ins that will automatically be upgraded while upgrading the OMS.

Note:
If you want to install any additional plug-ins that are not listed on this screen, then follow these steps:

1. Manually download the plug-ins from the Enterprise Manager download page on OTN, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the installer with the following option, and pass the location where the plug-ins you downloaded are available:
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_software_location>

9. Click Next.

10. On the Extend WebLogic Server Domain screen, do the following to create a new WebLogic domain and a new OMS instance base directory for the upgraded OMS:

- Validate the AdminServer host name and its port, and the WebLogic user name, and enter the WebLogic user account password. This is required to create a new WebLogic domain (GCDomain) on the same port and host name as the AdminServer used by the earlier release of the OMS you are upgrading.

Note:
If you are upgrading an additional OMS, then enter the host name and port of the AdminServer configured for the first OMS that you have already upgraded, and then, enter the credentials for the existing WebLogic Server user account.
The host name is the name of the host where the first OMS is running. To identify the port, check the value set to the parameter AS_HTTPS_PORT in the following file:

<ORACLE_HOME>/gc_inst/em/EMGC_OMS<n>/emgc.properties

- Enter the absolute path to the new OMS instance base directory (gc_inst), which will be created for storing the configuration information related to the upgraded OMS. Make sure the path you enter leads up to the instance base directory. You can maintain this directory inside or outside the middleware home. However, Oracle recommends that you maintain this directory inside the middleware home.
For example, /u01/app/Oracle/Middleware/gc_inst.

11. Click Next.

12. On the Review screen, review the details you provided for the selected installation type.

- If you want to change the details, click Back repeatedly until you reach the screen where you want to make the changes.

- After you verify the details, if you are satisfied, click Configure to begin the installation process.

13. On the Install Progress screen, view the overall progress (in percentage) of the installation.

Note:
If a Configuration Assistant fails, the installer stops and none of the subsequent Configuration Assistants are run until the issue related to the failed Configuration Assistant is resolved. In this case, diagnose the issue, resolve it, and then, click Retry on the Install Progress screen to rerun the Configuration Assistants starting from the Configuration Assistant that failed.
However, if you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script from the OMS home to rerun the Configuration Assistant in silent mode:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, raise a service request and contact Oracle Support.

14. On the Finish screen, you should see information pertaining to the installation of Enterprise Manager. Review the information and click Close to exit the installation wizard.

15. If you upgraded an additional OMS (11.1.0.1 or 12.1.0.1), then note that the OMS name changes and the configuration changes are made to the Oracle WebLogic domain that hosts Enterprise Manager. However, these configuration changes are not reflected in the Enterprise Manager Cloud Control Console until you refresh the WebLogic domain configuration within the console.
To refresh the WebLogic domain, follow these steps:

1. Navigate to the home page of the Oracle WebLogic domain that hosts Enterprise Manager.

2. From the WebLogic Domain menu, select Refresh WebLogic Domain. The Refresh WebLogic Domain page appears.

3. Follow the instructions on the Refresh WebLogic Domain page to refresh the WebLogic domain.

WARNING:

If you do not refresh the WebLogic domain, you will see the old OMS target on the WebLogic domain home page.

If you have a JVM Agent deployed, then you will see the old OMS target even on the Deploy/Upgrade Diagnostic Agent : Select Targets page while upgrading the JVM Agent.

Make sure you follow this step to clear the old OMS target from the Enterprise Manager Cloud Control Console.

Caution:
If you have any JVM targets associated with the old OMS, then even after you refresh the WebLogic domain, on the WebLogic domain home page, you will continue see the JVM target that was associated with the old OMS. This is an expected behavior.
If you choose to either retain it for viewing historical data or delete it. To delete it, right-click the orphaned JVM target, and select Remove Target.

16. Ensure that you upgrade the Management Agent that was installed with the old OMS (that is, central agent) immediately after upgrading the old OMS. For more information, refer to Chapter 5.

Advanced Script Options for Software-Only Mode

The following are some additional, advanced options you can pass while invoking the configureGC.sh script:

- By default, GCDomain is the default name used for creating the WebLogic Domain. To override this and use a custom WebLogic Domain name, invoke the script with the WLS_DOMAIN_NAME option, and enter a unique custom name.
For example, if you want to use the custom name EMDomain, then run the following command:

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh WLS_DOMAIN_NAME=EMDomain

- After the configuration ends successfully, the OMS and the Management Agent start automatically. If you do not want them to start automatically, then invoke the script with START_OMS and b_startAgent options, and set them to true or false depending on what you want to control.
For example, if you do not want the Management Agent to start automatically, then run the following command:

$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh START_OMS=true b_startAgent=false

To understand the limitations involved with this advanced option, see Limitations.

Installing Software Now and Upgrading Later in Silent Mode

This section explains how you can install only the software binaries of Enterprise Manager 12c Cloud Control in silent mode at one point, and upgrade them at a later point:

- Installing Software Binaries

- After You Install

- Configuring and Upgrading

WARNING:

Do not upgrade Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) while it is undergoing a 2-system upgrade from its earlier release. Wait until the upgrade completes fully because there might be some standalone Management Agents in status pending state while the upgrade is in progress.

Note:
While upgrading, you might see an error message stating that some Management Agents are still in Activation Pending state, or that the Deferred Data Migration Process (DDMP) or Accrued Data Migration Process (ADMP) is not complete. This indicates that the earlier release of the Enterprise Manager system is still undergoing a 2-system upgrade to 12c Release 1 (12.1.0.1).
To resolve this issue, wait until the DDMP and ADMP jobs are complete, and all Management Agents are switched over from the earlier release to 12c Release 1 (12.1.0.1). Then upgrade 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2).

If you are sure you do not want to switch over some Management Agents from the earlier release to 12c Release 1 (12.1.0.1), then delete such unwanted Management Agents as described in Deleting Unwanted Management Agents, before you start the upgrade process.

Note:
If you see an error message stating that you have not copied the emkey, run the following command.
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <repository_host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

(Here, the Management Repository details are details of the existing or old Management Repository. And when you run this command, you might be prompted for the admin server password.)

Caution:
Ensure that you use VNC Server to connect to the remote host while upgrading the OMS and the Management Repository. Other tools, such as cygwin, putty, and so on, sometimes time out or do not allow new Xdisplay connections, thus resulting in upgrade failures.

Installing Software Binaries

To install the software binaries of Enterprise Manager 12c Cloud Control, follow these steps:

1. Copy the following response file to an accessible location on your local host:
<Software_Location>/response/software_only.rsp

In this command, <Software_Location> refers to the location where you have extracted the software kit.

2. Edit the response file and enter appropriate values for the variables described in Table 4-2.

3. Invoke the installer:
./runInstaller -silent -responseFile <absolute_path>/software_only.rsp [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

- For information about the additional, advanced options you can pass while invoking the installer, refer to Advanced Installer Options for Silent Mode.

- The central inventory location you enter must NOT be on a shared file system.

4. Deinstall the Management Agent. For instructions, refer to the chapter on deinstalling a Management Agent in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

Note:
The Management Agent installed with the OMS is a fresh installation, and therefore is not required.

- If you are upgrading from 12c Release 1 (12.1.0.1), then you must upgrade your Management Agent using the Upgrade Agents Console. For instructions to use the Upgrade Agents Console to upgrade Management Agents, see Chapter 5 .

- If you are upgrading 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1), then you already have the Management Agent predeployed by the Preupgrade Console.

Editing Response File for Installing Software Binaries

Table 4-2 describes what variables you must edit and how you must edit them in the software_only.rsp response file for installing the software binaries of Enterprise Manager Cloud Control.

Table 4-2 Editing Response File for Installing Software Binaries

Parameter

Description

INSTALL_UPDATES_SELECTION

By default, this variable is set to "skip" indicating that the software updates will not be installed during installation.

- If you want to install the software updates from My Oracle Support, then set this variable to "download". Then, enter the credentials for the following variables:
MYORACLESUPPORT_USERNAME_FOR_SOFTWAREUPDATES

MYORACLESUPPORT_PASSWORD_FOR_SOFTWAREUPDATES

- If you want to install the software updates from a staged location, then set this variable to "staged". Then, for the STAGE_LOCATION parameter, enter the absolute path, which leads to the Updates directory, where the software updates are available.

ORACLE_MIDDLEWARE_HOME_LOCATION

Upgrade to 12c Release 2 (12.1.0.2) is an out-of-place upgrade, therefore you must specify an existing middleware home or enter a new middleware home where Oracle WebLogic Server and Java Development Kit are installed.

Enter the location where you have installed Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24. If you do not already have them installed, then enter the location where you want the installer to install them.

For example, u01/app/Oracle/Middleware.

Ensure that the middleware location has write permission to create the Oracle homes for OMS and Management Agent.

Note: Ensure that the Middleware home you enter here is used only for Enterprise Manager Cloud Control. Ensure that no other Oracle Fusion Middleware products or components are installed in the same Middleware home.

ORACLE_HOSTNAME

(Applicable only for 2-system upgrade of 10.2.0.5 or 11.1.0.1)

By default, the fully qualified name of the host on which you have invoked the installer, is considered.

- To accept the default value, leave it blank.

- To install with a different host name, then enter another host name.

AGENT_BASE_DIR

Enter the absolute path to the agent base directory, a location outside the Oracle Middleware home where the Management Agent can be installed.

For example, u01/app/Oracle/Middleware/agent. Ensure that this location is empty and has write permission. Also ensure that it is always maintained outside the Oracle Middleware home.

After You Install

(For UNIX Only) After you install the software binaries, log in as a root user in a new terminal and run the allroot.sh script from the OMS home:

$<OMS_HOME>/allroot.sh

Configuring and Upgrading

To configure the software binaries of Enterprise Manager Cloud Control, follow these steps:

1. Copy the following response file to an accessible location on the host where you copied the software binaries of Enterprise Manager Cloud Control:
<Software_Location>/response/upgrade.rsp

In this command, <Software_Location> refers to the location where you have extracted the software kit.

2. Edit the response file and enter appropriate values for the variables described in Appendix A.

3. Configure the software binaries by invoking the ConfigureGC.sh script passing the response you edited in the previous step:
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -silent -responseFile <absolute_path>/upgrade.rsp [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- While installing the software binaries as described in Installing Software Binaries, if you had passed the argument -invPtrLoc, then pass the same argument here as well.

- For information about the additional, advanced options you can pass while invoking the script, refer to Advanced Script Options for Software-Only Mode.

Note:
If you see an error about missing plug-ins, then do the following:

1. Make a note of the plug-in version and plug-in update as shown in the missing plug-ins error message. The plug-ins displayed in the error message have the following format:
PluginID:PluginVersion:PluginUpdate

2. Manually download the same plug-in version and the same or higher plug-in update as shown in the missing plug-ins error message, from the following URL.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

Store the plug-ins in an accessible location, and ensure that the location is meant only for these missing plug-ins.

3. Invoke the ConfigureGC.sh script in the following way to install the downloaded plug-ins:
<OMS_HOME>/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_sw>

4. If you upgraded an additional OMS (11.1.0.1 or 12.1.0.1), then note that the OMS name changes and the configuration changes are made to the Oracle WebLogic domain that hosts Enterprise Manager. However, these configuration changes are not reflected in the Enterprise Manager Cloud Control Console until you refresh the WebLogic domain configuration within the console.
To refresh the WebLogic domain, follow these steps:

1. Navigate to the home page of the Oracle WebLogic domain that hosts Enterprise Manager.

2. From the WebLogic Domain menu, select Refresh WebLogic Domain. The Refresh WebLogic Domain page appears.

3. Follow the instructions on the Refresh WebLogic Domain page to refresh the WebLogic domain.

WARNING:

If you do not refresh the WebLogic domain, you will see the old OMS target on the WebLogic domain home page.

(Applicable only for 12.1.01 to 12.1.0.2 Upgrade) If you have a JVM Agent deployed, then you will see the old OMS target even on the Deploy/Upgrade Diagnostic Agent : Select Targets page while upgrading the JVM Agent.

Make sure you follow this step to clear the old OMS target from the Enterprise Manager Cloud Control Console.

Caution:
(Applicable only for 12.1.01 to 12.1.0.2 Upgrade) If you have any JVM targets associated with the old OMS, then even after you refresh the WebLogic domain, on the WebLogic domain home page, you will continue see the JVM target that was associated with the old OMS. This is an expected behavior.
If you choose to either retain it for viewing historical data or delete it. To delete it, right-click the orphaned JVM target, and select Remove Target.

5. Ensure that you upgrade the Management Agent that was installed with the old OMS (that is, central agent) immediately after upgrading the old OMS. For more information, refer to Chapter 5.

Upgrading Multi-OMS Environment

To upgrade an Enterprise Manager system of 12c Release 1 (12.1.0.1) that has multiple OMS, follow these steps:

WARNING:

Do not upgrade Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) while it is undergoing a 2-system upgrade from its earlier release. Wait until the upgrade completes fully because there might be some standalone Management Agents in status pending state while the upgrade is in progress.

Caution:
Ensure that you use VNC Server to connect to the remote host while upgrading the OMS and the Management Repository. Other tools, such as cygwin, putty, and so on, sometimes time out or do not allow new Xdisplay connections, thus resulting in upgrade failures.

1. Upgrade the first OMS (where the Admin Server is running). You can use any of the upgrade approaches described in this guide — Upgrading OMS and Management Repository in Graphical Mode, Upgrading OMS and Management Repository in Silent Mode, Installing Software Now and Upgrading Later in Graphical Mode, or Installing Software Now and Upgrading Later in Silent Mode.

Note:
Always start the upgrade process with the first OMS, where the Admin Server is running, and not with any of the additional OMS instances.
To identify the OMS where the Admin Server is running, run the following command on the OMS home and verify if the output displays the Admin Server details.

$<OMS_HOME>/bin/emctl status oms -details

You should see a similar output:

Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.2.0
Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host : myhost.example.com
.
.
.
WLS Domain Information
Domain Name : GCDomain
Admin Server Host: myhost.example.com
.
.
.

2. After upgrading the first OMS in your system, on every other host where an additional OMS is running, invoke the Enterprise Manager Cloud Control Installation Wizard, and on the Installation Types screen, select Upgrade an Existing Enterprise Manager System, and then, select One System Upgrade. Then, select the additional OMS home you want to upgrade.

5 Upgrading Oracle Management Agents

This chapter describes how you can upgrade your Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) or later Oracle Management Agents. This chapter contains the following sections:

- Overview

- Before You Begin

- Prerequisites

- Upgrade Procedure

- After You Upgrade

Overview

If you are using Enterprise Manager Cloud Control 12c Release 2 to manage your enterprise, Oracle strongly recommends that you upgrade all your Oracle Management Agents (Management Agents) to 12c Release 2 (12.1.0.2).

To upgrade your Management Agents, use the Upgrade Agents page, which is a part of the Enterprise Manager Cloud Control console.

The Upgrade Agents page acts as a single-window solution to mass-upgrade your existing Management Agents to the latest version for which the software is available in Oracle Software Library. To access this page, from the Setup menu, select Manage Cloud Control, then select Upgrade Agents.

Clicking Not Upgradable Agents on the Upgrade Agents page displays the Management Agents that cannot be upgraded, and other details about these Management Agents, such as why they cannot be upgraded, what you can do to upgrade them, and so on. For more information on these Management Agents, see Viewing Management Agents That Cannot Be Upgraded.

Clicking Agent Upgrade Results displays the Management Agent upgrade jobs that succeeded, the upgrade jobs that failed, and the upgrade jobs that are presently running. For more information on Management Agent upgrade jobs, see Viewing Management Agent Upgrade Jobs and Viewing Management Agent Upgrade Job Status and Progress.

Figure 5-1 shows the Upgrade Agents page.

Figure 5-1 Upgrade Agents Page

Using the Upgrade Agents page, you can also:

- Add or remove Management Agents from the list of Management Agents selected for upgrade.

- Specify custom scripts to run before and after the upgrade.

- Customize the upgrade by passing additional parameters.

Upgrading a Management Agent modifies its installation base directory structure. The following is an example of the Management Agent installation base directory structure before and after upgrading it to 12c Release 2 (12.1.0.2):

Before Upgrade

<agent_base_directory>
|_____sbin
|_____core
|_____12.1.0.1.0
|_____plugins
|_____plugins.txt
|_____plugins.txt.status
|_____agent_inst
|_____agentimage.properties

After Upgrade

<agent_base_directory>
|_____sbin
|_____backup_<TIMESTAMP>
|_____core
|_____12.1.0.1.0
|_____12.1.0.2.0
|_____plugins
|_____plugins.txt
|_____plugins.txt.status
|_____plugins_upgrade.txt
|_____plugins_upgrade.txt.status
|_____agent_inst
|_____agentimage.properties

Note:

- When you upgrade a Management Agent, you cannot change the location of the agent base directory.

- When you upgrade a Management Agent, the plug-ins installed on the Management Agent host are also upgraded by default, as long as the latest versions of these plug-ins exist in Oracle Software Library (Software Library). If the latest versions of these plug-ins do not exist in the Software Library, their old versions are retained.

- If you upgrade a 12c Release 1 (12.1.0.1) Management Agent installed on a Microsoft Windows host to 12c Release 2 (12.1.0.2), and you want to install another Management Agent on the same host, ensure that you install the Management Agent after downloading the Management Agent software, and specifying the s_agentSrvcName parameter, as described in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

Before You Begin

Before you upgrade your Management Agents, you must be aware of the following:

- You can use the Upgrade Agents page to upgrade only 12c Management Agents to 12c Release 2 (12.1.0.2).

- You must upgrade the central agent installed along with the old Oracle Management Service (OMS). This Management Agent is not upgraded automatically while upgrading to Enterprise Manager Cloud Control 12c Release 2.

Important:
Ensure that you upgrade the central agent installed along with the old OMS immediately after upgrading the old OMS.

- You can upgrade a Management Agent even when you do not have preferred privileged credentials set in your Enterprise Manager console, or are not aware of the Management Agent credentials. The credentials are required only to run root.sh scripts post-upgrade.
If you upgrade a Management Agent as a user who does not have root privileges, or you upgrade a Management Agent without having preferred privileged credentials, a warning appears. You can ignore this warning during the upgrade. Later, you can log in to the Management Agent host as the root user, and run the $<AGENT_BASE_DIR>/core/12.1.0.2.0/root.sh script. After running this script, ensure that you also run the $<AGENT_BASE_DIR>/core/12.1.0.2.0/replacebins.sh script on the host.

- If you select a Management Agent installed on a cluster, or a shared Management Agent for upgrade, the set of related Management Agents, that is, the other Management Agents of the cluster or the shared Oracle Home are selected for upgrade automatically.

- You cannot upgrade a Management Agent in the following scenarios:

- The Management Agent is not up and running

- The Management Agent is not secure

- The new Management Agent software is not present in Oracle Software Library

Prerequisites

Before you upgrade your Management Agents, meet the following prerequisites:

- If you want to upgrade a Management Agent running on a platform different from the OMS platform, ensure that the latest Management Agent software for the platform is applied, using the Self Update Console.
To access the Self Update Console, from the Setup menu, select Extensibility, then select Self Update. To check whether the latest Management Agent software for a platform is applied, click Agent Software, then check the Status column. If the latest software is not downloaded and applied, select the software, then click Download to download it. After downloading the software, click Apply to apply the software. If the software has been downloaded, but not applied, click Apply to apply the software.

For more information on using the Self Update Console to download and apply the latest software, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

- Ensure that the Management Agents you want to upgrade are up and running.
To verify if a Management Agent is up and running, from the Setup menu, select Manage Cloud Control, then select Agents. Check the Status column of the required Management Agent.

If the Management Agent is unreachable, click the Management Agent name to navigate to the Management Agent home page. Click the Agent Unreachable icon, and perform the recommended actions.

- Ensure that the Management Agents you want to upgrade are secure.
To verify if a Management Agent is secure, from the Setup menu, select Manage Cloud Control, then select Agents. Click the required Management Agent name to navigate to the Management Agent home page.

If the Management Agent is not secure, from the Agent menu, select Secure to secure it.

Also, you can run the following command to verify if a Management Agent is secure:

<EMSTATE>/bin/emctl status agent

If the Management Agent is secure, the Management Agent URL displayed is a HTTPS URL. However, if the Management Agent URL displayed is a HTTP URL, secure the Management Agent by running the following command:

<EMSTATE>/bin/emctl secure agent

- If the temporary directory (that is, the stage location) you specify and the agent base directory of the Management Agent you want to upgrade are present on the same disk, then ensure that the disk has at least 3 GB of free space. If they are present on different disks, ensure that the temporary directory has at least 2 GB of free space, and the agent base directory has at least 750 MB of free space.

Upgrade Procedure

This section describes the actions involved in upgrading Management Agents. It consists of the following:

- Upgrading Management Agents

- Additional Parameters for Management Agent Upgrade

- Viewing Management Agents That Cannot Be Upgraded

Upgrading Management Agents

To upgrade 12c Management Agents to the latest available version, follow these steps:

1. From the Setup menu, select Manage Cloud Control, then select Upgrade Agents. Click Add, select the Management Agents you want to upgrade, then click Select.

2. On the Upgrade Agents page, do the following:

1. Click Add to add Management Agents for the upgrade job.

2. For Job Name, accept the default job name, or enter a unique job name.
A unique job name enables you to identify the upgrade job, know details of its execution, and track its progress on the Agent Upgrade Status page.

The job name can have a maximum length of 64 characters. It can contain alphabets, numerals, and special characters, and can begin with any of these.

3. For Stage Location, accept the default stage location, or enter a custom location.
For example, /tmp/software/oracle/EMStage.

Ensure that the Management Agent install user has write permissions on the custom location you enter. The custom location you enter can be a shared, NFS-mounted location.

Note:
Ensure that the Management Agent host user has write permission in the custom location.

The stage location is used to store temporary Management Agent upgrade files.

4. (Optional) For Pre-upgrade Script and Post-upgrade Script, enter the absolute path of the script you want to run before and after the upgrade, respectively.
For example, /scratch/software/oracle/configure.sh.

The scripts you want to run must be present at the location you specify, on the Oracle Management Service (OMS) host, or on all the Management Agent hosts selected for upgrade. They can reside in a shared, NFS-mounted location accessible by the Management Agent hosts selected for upgrade.

If the script you want to run is present only on the OMS host, and not on the Management Agent hosts selected for upgrade, then select Script on OMS Host. The scripts you specify are first copied to the stage location you specified earlier, then run, and then deleted from the stage location.

Note:

- You can specify only one pre-upgrade script and one post-upgrade script per session.

- Only shell scripts (.sh) and batch (.bat) scripts are supported. You should run only shell scripts while upgrading Management Agents installed on Unix platforms, and only batch scripts while upgrading Management Agents installed on Microsoft Windows platforms.

- If you want to upgrade a Management Agent installed on a Unix platform and a Management Agent installed on a Microsoft Windows platform in the same session, ensure that you do not specify a pre-upgrade or a post-upgrade script. If you want to specify a pre-upgrade or a post-upgrade script for upgrading these Management Agents, upgrade the Management Agents in different sessions.

5. (Optional) For Additional Parameters, enter the additional options you want to use for the upgrade.
For example, specify -ignorePrereqs to skip running the prerequisite checks, and directly perform the Management Agent upgrade.

Refer Additional Parameters for Management Agent Upgrade for a list of parameters you can specify.

3. Click Submit.

Note:
If you encounter an error which mentions that Root.sh cannot be run for the following agents, and specifies the reason as Oracle Home Property Missing, do one of the following:

- Click OK. After the upgrade, log in to the Management Agent host as the root user, and run the $<AGENT_BASE_DIR>/core/12.1.0.2.0/root.sh script on the host. After running this script, run the $<AGENT_BASE_DIR>/core/12.1.0.2.0/replacebins.sh script on the host.

- Click Cancel, then do the following:

1. Run the following command on the Management Agent host from <AGENT_INSTANCE_HOME>/bin:
emctl control agent runCollection <ORACLE_HOME_TARGET_NAME>:oracle_home oracle_home_config

To obtain <ORACLE_HOME_TARGET_NAME>, refer the targets.xml file present in <AGENT_INSTANCE_HOME>/sysman/emd.

2. Upgrade the Management Agent using the Upgrade Agents page.

Note:
If you encounter an error which mentions that Root.sh cannot be run for the following agents, and specifies the reason as Preferred Credentials for Oracle Home not set, do one of the following:

- Click OK. After the upgrade, log in to the Management Agent host as the root user, and run the $<AGENT_BASE_DIR>/core/12.1.0.2.0/root.sh script on the host. After running this script, run the $<AGENT_BASE_DIR>/core/12.1.0.2.0/replacebins.sh script on the host.

- Click Cancel, then do the following:

1. Set the preferred privileged credentials for the Oracle Home target of the Management Agent.
For information on how to set the preferred privileged credentials for the Oracle Home target of a Management Agent, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

2. Configure privilege delegation settings on the Management Agent host.
For information on how to configure privilege delegation settings on the Management Agent host, refer to the Setting Up Database as a Service chapter of the Oracle Enterprise Manager Cloud Administration Guide.

3. Upgrade the Management Agent using the Upgrade Agents page.

If you do not want to set the preferred privileged credentials for the Oracle Home target of the Management Agent, click Cancel, and do the following:

1. Select Override Privileged Credentials, and create a new credential by clicking the displayed icon. If the credential you create is not a root credential, select Sudo or PowerBroker for Run Privilege, and enter root for Run as.

2. Configure privilege delegation settings on the Management Agent host.

3. Upgrade the Management Agent using the Upgrade Agents page.

If the root.sh job step fails after the upgrade, log in to the Management Agent host as the root user, and run the $<AGENT_BASE_DIR>/core/12.1.0.2.0/root.sh and $<AGENT_BASE_DIR>/core/12.1.0.2.0/replacebins.sh scripts manually.

Note:
If the Management Agent upgrade fails for some reason, you can diagnose the problem by following these steps:

1. View the output logs of the failed Management Agent upgrade job steps.
To view the output log of a Management Agent upgrade job step, on the Upgrade Agents page, click Agent Upgrade Results. Click the name of the Management Agent upgrade job, and select the required Management Agent. Click the name of the required job step.

2. View the Management Agent deployment log available at the following location:

$<AGENT_BASE_DIRECTORY>/core/12.1.0.2.0/cfgtoollogs/agentDeploy/agentDeploy_<TIMESTAMP>.log

3. View the plug-in upgrade configuration log available at the following location:

$<AGENT_INSTANCE_HOME>/install/logs/agentplugindeploy_<TIMESTAMP>.log

Additional Parameters for Management Agent Upgrade

Table 5-1 describes the additional parameters you can enter while upgrading 12c Management Agents. You can enter more than one parameter, using a whitespace as a separator.

Table 5-1 List of Additional Parameters for Management Agent Upgrade

Parameter

Description

-ignorePrereqs

Skips running the prerequisite checks.

Specify this parameter when you have already verified the prerequisites, and only want to perform the rest of the upgrade process.

-debug

Logs debug messages useful for debugging and resolving errors.

Viewing Management Agents That Cannot Be Upgraded

You may not be able to upgrade certain Management Agents using the Upgrade Agents page. Table 5-2 describes the reasons for this.

Table 5-2 Why Some Management Agents Cannot Be Upgraded

Reason

Description and Recommended Action

Latest Agent Software Missing

The latest Management Agent software is not available in Oracle Software Library.

To upgrade a Management Agent for which the latest Management Agent software is not available, you need to first download and apply the latest software using the Self Update Console, then use the Upgrade Agents page.

To access the Self Update Console, from the Setup menu, select Extensibility, then select Self Update. To download the latest Management Agent software, click Agent Software, select the required software, then click Download. For information on using the Self Update Console to download and apply the latest software, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

Agent Unsecured

The Management Agent is not secure.

To upgrade a Management Agent which is not secure, you need to first secure the Management Agent, then use the Upgrade Agents page.

To secure the Management Agent, from the Setup menu, select Manage Cloud Control, then select Agents. Click the required Management Agent name. From the Agent menu, click Secure.

You can also run the following command to secure the Management Agent:

<EMSTATE>/bin/emctl secure agent

Agent Unreachable

The Management Agent is not reachable, that is, the Oracle Management Service (OMS) cannot communicate with the Management Agent.

A Management Agent is generally unreachable when it is down, when it is blocked by the OMS, or when the Management Agent host is down. A Management Agent may also be unreachable due to network problems or certain other issues.

To upgrade a Management Agent that is unreachable, you need to first ensure that the Management Agent is reachable, then use the Upgrade Agents page.

To restore communication between the OMS and the Management Agent, from the Setup menu, select Manage Cloud Control, then select Agents. Click the required Management Agent name to navigate to the Management Agent home page. Click the Agent Unreachable icon, and perform the recommended actions.

Agent Pending Activation

The Management Agent version is not 12c Release 1 (12.1.0.1) or later.

You cannot upgrade 10g or 11g Management Agents using the Upgrade Agents page. Deinstall these Management Agents and install fresh Management Agents on the hosts.

For information on deinstalling Management Agents, refer to Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide. For information on installing fresh Management Agents, refer to Oracle Enterprise Manager Cloud Control Basic Installation Guide.

You can use the Not Upgradable Agents page to search for and view a set of Management Agents that currently cannot be upgraded. To search for and view these Management Agents, follow these steps:

1. From the Setup menu, select Manage Cloud Control, then select Upgrade Agents.

2. Click Not Upgradable Agents.

3. Enter or select values for parameters you want to use to search for Management Agents. You can search for Management Agents using the Management Agent name, version, platform, and the reason why the Management Agent cannot be upgraded.

4. For Match, select All or Any to search for results that match all the search parameters, or any of the search parameters, respectively.

5. Click Search.

After You Upgrade

This section describes the various tasks you can perform after upgrading your Management Agents. It consists of the following:

- Performing Postupgrade Verification Tasks

- Viewing Management Agent Upgrade Jobs

- Viewing Management Agent Upgrade Job Status and Progress

Performing Postupgrade Verification Tasks

After you upgrade your Management Agents, follow these methods to verify the upgrade:

- From the Setup menu, select Manage Cloud Control, then select Upgrade Agents. Click Agent Upgrade Results. Verify that the job you created to upgrade the Management Agents succeeded.

- From the Setup menu, select Manage Cloud Control, then select Agents. Click the name of a Management Agent you have upgraded, and verify the Management Agent version. The version number must be higher than what it was before the upgrade.

Viewing Management Agent Upgrade Jobs

You use the Upgrade Agents page to mass-upgrade your Management Agents. Once you enter the required upgrade details on this page and click Submit, a Management Agent upgrade job is created, which is sent to the Enterprise Manager job system.

You can use the Agent Upgrade Results page to search for and view a particular set of Management Agent upgrade jobs. To search for and view these jobs, follow these steps:

1. From the Setup menu, select Manage Cloud Control, then select Upgrade Agents.

2. Click Agent Upgrade Results.

3. Enter or select values for parameters you want to use to search for Management Agent upgrade jobs. You can search for Management Agent upgrade jobs using the job name, the Management Agents that were upgraded by the job, the status of the job, and the date when the job was started.

4. For Match, select All or Any to search for results that match all the search parameters, or any of the search parameters, respectively.

5. Click Search.

You can view the status and progress of a Management Agent upgrade job by accessing the Agent Upgrade Status page. To access this page from the Agent Upgrade Results page, click the required job name. For information on this page, refer Viewing Management Agent Upgrade Job Status and Progress.

Viewing Management Agent Upgrade Job Status and Progress

A Management Agent upgrade job consists of a series of job steps. The Agent Upgrade Status page informs you about the job steps that succeeded, failed, and are in progress for a particular Management Agent. To view the progress of the job steps involved in upgrading a particular Management Agent, do the following:

1. From the Setup menu, select Manage Cloud Control, then select Upgrade Agents.

2. Click Agent Upgrade Results.

3. Enter or select values for parameters you want to use for the Management Agent upgrade job search. You can search for Management Agent upgrade jobs using the job name, the Management Agents that were upgraded by the job, the date when the job was started, and the status of the job.

4. For Match, select All or Any to search for results that match all the search parameters, or any of the search parameters, respectively. Click Search.

5. Click the name of the required Management Agent upgrade job.

6. Click the Management Agent name.

On this page, you can select a Management Agent and click on a job step to view the output log for the Management Agent upgrade job step. Output logs are useful for diagnosing Management Agent upgrade failures.

Troubleshooting

This section describes how to troubleshoot certain errors you may encounter while upgrading your Management Agents.

You may encounter the following error while upgrading your Management Agents:

The Management Agent cannot be upgraded as the 32-bit Management Agent software for the host platform is not present in Oracle Software Library.

You may encounter this error while upgrading Management Agents that run on the Oracle Enterprise Linux 4.x, Red Hat Enterprise Linux 4.x, and SUSE Linux Enterprise 10 64-bit platforms. If you encounter this error, click OK. Download and apply the latest 32-bit Management Agent software for these platforms, using the Self Update Console, then upgrade the Management Agent using the Upgrade Agents page.

For information on using the Self Update Console to download and apply the latest Management Agent software, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

6 Upgrading ADP and JVMD in Graphical Mode

While upgrading Enterprise Manager, all the Application Dependency and Performance (ADP) engines and JVM Diagnostics (JVMD) engines are stopped as a part of the preupgrade process. Once the Enterprise Manager is successfully upgraded to 12c Release 2 (12.1.0.2), the ADP and JVMD Managers that were part of your enterprise before the upgrade must be re-created.

Note:
For information about deploying the JVMD Managers and JVMD Agents with basic and advanced options, see the following guides:

- Oracle Enterprise Manager Cloud Control Basic Installation Guide

- Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide

For information about deploying ADP Managers and ADP Agents with basic and advanced options, see the following guides:

- Oracle Enterprise Manager Cloud Control Basic Installation Guide

- Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide

Note:
The ADP engines and the JVMD engines are both part of Application Performance Management (APM). In this document, we may refer to either of the engines as APM engines.

To do upgrade or redeploy APM engines in graphical mode, follow the steps listed in each of these sections:

- Upgrading or Redeploying JVMD and ADP Managers in Graphical Mode

- Upgrading or Redeploying Diagnostic Agents in Graphical Mode

Upgrading or Redeploying JVMD and ADP Managers in Graphical Mode

To re-create all the ADP and JVMD Managers in graphical mode after an Enterprise Manager 12c upgrade process, follow these steps:

1. In Cloud Control, from Setup menu, select Application Performance Management.

The Application Performance Management screen is displayed.

2. On the Application Performance Management screen, use the Upgrade icon shown in the following graphic to upgrade or redeploy an APM engine.

3. To upgrade the JVMD Diagnostics engine, select JVM Diagnostics Engine, and perform the following steps:

1. On the Redeploy/Upgrade JVMD Engines screen, do the following:
- Select the JVMD engines from local or existing WebLogic Servers that are part of the WebLogic Domain.

- Specify the Host Credentials, which are the credentials for the host machine where the Managed Server is created.

Note:
If each of the Managed Servers are running on a different host, then select the row and apply the corresponding credential for the selected host. When applying credentials for a selected engine, the credentials are automatically applied to all engines that are on the same host.

- Specify the Administrator WebLogic Credentials, which are the credentials for the WebLogic Domain where the Cloud Control OMS is deployed.

- Click Apply.

2. Click Upgrade.
A job is submitted, click the job link to verify the status of the job to completion.

After successful completion of the job, you can go back to the Application Performance Management page to view the status of the engines.

4. To upgrade the ADP engines, select ADP Engines, and perform the following steps:

1. On the Redeploy/Upgrade ADP Engines screen, do the following:
- Select the ADP engines from local or existing WebLogic Servers that are part of the WebLogic Domain.

- Specify the Host Credentials, which are the credentials for the host machine where the Managed Server is created.

Note:
If each of the Managed Servers are running on a different host, then select the row and apply the corresponding credential for the selected host. However, if all the Managed Servers are on the same host, then, select all the rows, and apply the same host credentials for all of them.

- Specify the Administrator WebLogic Credentials, which are the credentials for the Weblogic domain where the Cloud Control OMS is deployed.

- Click Apply.

2. Click Upgrade.
A job is submitted, click the job link to verify the status of the job to completion.

After successful completion of the job, you can go back to the Application Performance Management page to view the status of the engines.

Upgrading or Redeploying Diagnostic Agents in Graphical Mode

This section describes the following:

- Overview of Manage Diagnostic Agents Wizard

- Deploying Diagnostics Agents On All the Monitored WebLogic Domains (Multi-Domain Deployment)

- Upgrading Diagnostics Agents On All the Monitored WebLogic Domains

Note:
After an upgrade, if you have multiple OMS's, some of the Oracle WebLogic Server managed servers that an OMS is deployed to may be re-created or renamed by the upgrade process. If this occurs, you will need to deploy the JVMD Agent to those new servers directly, since they will not have old agents that the JVMD agent upgrade UI can pick up.

Overview of Manage Diagnostic Agents Wizard

For the upgrade process and the bulk deployment process, JVMD and ADP Agents use the new Manage Diagnostic Agents Wizard. The new wizard described in Figure 6-0 enables bulk deployment of Diagnostic Agents, which means you can now deploy any number of Diagnostic Agents on all the monitored WebLogic Domains using a single Wizard. In addition to deploying the agents, you can upgrade any of the existing Diagnostic Agents in the domains available in your Enterprise Manager.

Figure 6-1 Manage Diagnostic Agents Wizard

Note:
Using Application Performance Management UI for upgrading the Non-Weblogic Server targets are not supported in Enterprise Manager 12c. To do so, you must use the manual upgrade approach.
For example, if your enterprise contains 10 Management Agents that require an upgrade (8 of which are WebLogic Server targets, and two of which are Non-WebLogic Server targets), then after performing a bulk upgrade, you will notice that only 8 agents have been successfully upgraded, while two of them still appear as non-upgraded. This is an expected behavior, and to fix this issue Oracle recommends using manual approach to upgrade the remaining Non-WebLogic Server targets.

Deploying Diagnostics Agents On All the Monitored WebLogic Domains (Multi-Domain Deployment)

Follow these steps to deploy and upgrade the Diagnostic Agents:

1. In Cloud Control, from Setup menu, select Application Performance Management (APM).
The Application Performance Management screen is displayed. The Application Performance Management Agent displays the number of Agents deployed.

2. On the Application Performance Management screen, click Manage Diagnostic Agents.
The Deploy/Upgrade Diagnostic Agents Wizard appears.

3. From the Select Targets screen, select Deploy.
If you select Expand All from the View menu, you will be able to see information about all the discovered WebLogic Targets along with their host, Operating System platform, and Status.

Select the targets on which the ADP and JVMD Agents are to be deployed as follows, and click Next.

4. On the Target Credentials screen, you need to select one or more WebLogic Domains and set the following credentials:

- Oracle WebLogic Administration Server Host Credentials: Provide the host credentials where the Management Agent that is monitoring WebLogic Domain is running.

- Oracle WebLogic Domain Credentials: Provide the WebLogic Domain credentials.

Click Apply to apply the credentials to the selected WebLogic Domains, and then click Next.

5. On the ADP Agents Configurations screen, select one or more WebLogic Domain from the table. All the corresponding ADP Engines will appear in the Available ADP Engine drop down list. From the menu, select the ADP Engine to which the ADP Agents will report, and click Apply. This will ensure that the selected ADP Engines are applied to the respective WebLogic Domains.

6. Click Next.

7. On the JVMD Agents Configurations screen, select one or more WebLogic Domain from the table. All the corresponding JVMD Engines will appear in the Available JVMD Engine drop down list. From the menu, select the JVMD Engine to which the JVMD Agents will report. You can alternatively select Other to connect to a load Balancer in case of multiple engines. Click Apply to apply the selected JVMD Engines to the respective WebLogic Domains.

8. Click Next.

9. On the Enterprise Manager Credentials screen, you will need to provide some additional credentials for updating, and restarting the ADP engines:

- Oracle Enterprise Manager WebLogic Administration Server Host Credentials: Provide the Enterprise Manager OMS Host credentials.

- Oracle Enterprise Manager WebLogic Domain Credentials: Provide the Enterprise Manager OMS WebLogic Domain credentials.

Click Save to save the credential information.

10. Click Next.

11. On the Review screen, review all the target credentials, and the engine details, and then click Deploy.
Separate jobs are created for bulk APD and bulk JVMD agents deployment. Click the links to view the progress of the jobs. Only after the first job is executed will the second job start execution, until then, it remains in suspended state.

Once the JVMD Agent deployment is successful, you can verify if the agents are deployed by going back to the APM page, and checking under the Application Performance Management Agents section, as follows:

Upgrading Diagnostics Agents On All the Monitored WebLogic Domains

Follow these steps to deploy and upgrade the Diagnostic Agents:

1. In Cloud Control, from Setup menu, select Application Performance Management (APM).
The Application Performance Management screen is displayed. The Application Performance Management Agents section displays the number of Agents that requires upgrade:

2. On the Application Performance Management screen, either click the upgrade icon displayed in the earlier graphic or, click Manage Diagnostic Agents.
The Deploy/Upgrade Diagnostic Agents Wizard appears.

3. On the Select Targets screen, select Upgrade. All the Diagnostic Agents that are at an older revision and require upgrade appear preselected. You can select the targets on which Diagnostic Agent upgrade needs to be performed.

Click Next.

4. On the Target Credentials screen, you need to select one or more WebLogic Domains and set the following credentials:

- Oracle WebLogic Administration Server Host Credentials: Provide the host credentials where the Management Agent that is monitoring WebLogic Domain is running.

- Oracle WebLogic Domain Credentials: Provide the WebLogic Domain credentials.

Click Apply to apply the credentials to the selected WebLogic Domains, and then click Next.

5. On the ADP Agents Configurations screen, select one or more WebLogic Domain from the table. All the corresponding ADP Engines will appear in the Available ADP Engine drop down list. From the menu, select the ADP Engine to which the ADP Agents will report, and click Apply. This will ensure that the selected ADP Engines are applied to the respective WebLogic Domains.

6. Click Next.

7. On the JVMD Agents Configurations screen, select one or more WebLogic Domain from the table. All the corresponding JVMD Engines will appear in the Available JVMD Engine drop down list. From the menu, select the JVMD Engine to which the JVMD Agents will report. You can alternatively select Other to connect to a load Balancer in case of multiple engines. Click Apply to apply the selected JVMD Engines to the respective WebLogic Domains.

8. Click Next.

9. On the Enterprise Manager Credentials screen, you will need to provide some additional credentials for updating, and restarting the ADP engines:

- Oracle Enterprise Manager WebLogic Administration Server Host Credentials: Provide the Enterprise Manager OMS Host credentials.

- Oracle Enterprise Manager WebLogic Domain Credentials: Provide the Enterprise Manager OMS WebLogic Domain credentials.

Click Save to save the credential information.

10. Click Next.

11. On the Review screen, review all the target credentials, and the engine details, and then click Upgrade.

Once the JVMD Upgrade deployment is successful, you can verify by going back to the APM page, and checking under the Application Performance Management Agents section, as follows:

Part III

Upgrading 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

This part describes how you can upgrade Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) and Enterprise Manager 11g Grid Control Release 1 (11.1.0.1) to Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2).

This part covers the following chapters:

- Chapter 7, "Getting Started"

- Chapter 8, "Meeting Preupgrade Requirements"

- Chapter 9, "Upgrading Oracle Management Agents"

- Chapter 10, "Upgrading OMS and Management Repository"

- Chapter 11, "Performing Postupgrade Tasks"

7 Getting Started

This part describes the high-level process you must follow for each of the upgrade approaches. Oracle strongly recommends you to read the chapters covered in this part, and consider this part to be the starting point for upgrading your existing Enterprise Manager system. In particular, this chapter describes the following:

- Getting Started with 1-System Upgrade Approach

- Getting Started with 2-System Upgrade Approach

- Getting Started with 1-System Approach on a Different Host

Getting Started with 1-System Upgrade Approach

To upgrade your Enterprise Manager Grid Control to Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2) with 1-system upgrade approach, follow these steps:

Table 7-1 Upgrading Enterprise Manager Grid Control with 1-System Upgrade Approach

Step No.

Step

Procedure

Step 1

Prepare Yourself

(a)

Learn about the 1-System upgrade approach.

Upgrading 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

(b)

Review the important facts you need to know before you begin.

Chapter 2

Step 2

Perform Preupgrade Tasks

(a)

Apply the preupgrade console patch on all your OMS instance to get access to the Preupgrade Console.

Preupgrade Console

(b)

Manually download the following software, and stage them to an accessible location:

- Oracle Management Agent 12c

- All the required plug-ins

Installing Plug-Ins While Upgrading Oracle Management Agent 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

(c)

Provide information about the location of the software you manually downloaded and staged in Step 2 (b)

Managing Software

(d)

Analyze your environment to identify Oracle Management Agents (Management Agent) with valid and invalid inventory, check their upgradability status, and identify the problematic Management Agents. If a required software is missing, then repeat Step (b) and Step (c).

Analyzing Your Environment

(e)

Meet the prerequisites for upgrading the Management Agents.

Appendix E

Step 3

Upgrade Oracle Management Agent

(a)

Deploy and configure the software binaries of Oracle Management Agent 12c.

Deploying and Configuring Oracle Management Agent

(b)

Generate a health report and check the readiness of the predeployed Management Agents.

Generating Health Report of Deployed Oracle Management Agents

(c)

Verify and sign off the health check report.

Verifying and Signing Off the Health Report of Deployed Oracle Management Agents

(d)

Switch over the old Management Agents to the newly deployed ones so that they can communicate with Enterprise Manager Cloud Control.

Note: If you have a large number of agents, then you can choose to upgrade one set of Oracle Management Agents in one attempt, and the next set in the subsequent attempt. In this case, you can repeat Step 3 (a) to Step 3 (d) for each attempt.

Switching Over to Oracle Management Agent 12c

(e)

If you have a Server Load Balancer (SLB) configured, then modify the settings of your monitors.

Appendix F

Step 4

Upgrade Oracle Management Service and Oracle Management Repository

(a)

Meet the following prerequisites:

- Meet the Oracle Management Service-related prerequisites described in the chapter on installing Enterprise Manager Cloud Control, in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- Meet the Management Agent-related prerequisites described in Appendix E.

- Ensure that you are upgrading only on the supported platforms as listed in Supported Platforms for Upgrade.

- Back up the OMS, the Management Repository, and the Software Library. In case the upgrade fails, you can always restore using the backup.
For instructions to back up, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

(b)

On the Management Repository, meet the following prerequisites:

- Ensure that the MGMT_CONNECTOR_CONFIG table does not have any NULL rows. To verify this, run the following SQL query.
select * from mgmt_cntr_config where connector_type_guid IS NULL and connector_guid IS null;

Typically, the command must not return any rows. If it does return any rows, then run the following SQL query to clean the table:

delete from mgmt_cntr_config where connector_guid IS NULL or connector_type_guid IS NULL;

commit;

- Ensure that there are no custom-created materialized views in the Management Repository. To verify this, run the following SQL query. Typically, the command must not return any rows. If it does return any rows, then contact Oracle Support.
select count(1) from ALL_MVIEW_LOGS where log_owner=<EM_REPOS_USER>

- Ensure that the tables do not have any snapshots created. To verify this, log in to the Management Repository and run the following SQL query as SYSMAN user:
select master , log_table from all_mview_logs where log_owner='<EM_REPOS_USER>

For example,

select master , log_table from all_mview_logs where log_owner='SYSMAN'

If there are snapshots created in a table, then the query displays the master table and the snapshot details. For example,

SQL> master log_table

em-violations em$violation_log

If there are snapshots, then drop them by running the following command as SYSMAN user:

SQL> Drop snapshot log on <master>

For example,

SQL> Drop snapshot log on em-violations

(c)

Stop all running and scheduled deployment procedures in your existing Enterprise Manager system before upgrading the system.

(d)

(Only if you have Application Dependency and Performance (ADP) or JVM Diagnostics (JVMD) installed)

1. Take an inventory of the JVMs and WebLogic Domains being monitored by JVMD and/or ADP.

2. Deinstall the JVMD and ADP applications from your inventory by logging into the WebLogic Administration Console for each monitored domain and removing the jamagent and Acsera application deployments.

3. Shut down all of your ADP and JVMD managers.

4. Remove all ADP and JVMD managed servers from the GCDomain using the WebLogic Administration Console.

5. Run purge scripts for JVMD:
(a) Navigate to the following location:

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

(b) Extract the file jvmd.zip.

(c) Run the script jvmd_monitoringupgrade11_12.sql.

(d) Run the script jvmd_traceupgrade11_12.sql if there are existing Thread Snapshots from Enterprise Manager 11g Grid Control Release 1 (11.l.0.1).

(e)

Copy the emkey from the existing OMS, either the Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), to the existing Management Repository. To do so, run the following command on the old OMS home you are trying to upgrade. The following command is applicable for both releases.

$<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>]

Note: When the following command is run on Enterprise Manager 11g Grid Control (11.1.0.1), you will be prompted for an admin password.

To verify whether the emkey is copied, run the following command:

<OMS_HOME>/bin/emctl status emkey

If the emkey is copied, then you will see the following message:

The EMKey  is configured properly, but is not secure.
Secure the EMKey by running "emctl config emkey -remove_from_repos".

(f)

Stop the OMS you are about to upgrade and also the other OMS instances that connect to it.

- If you are upgrading in graphical mode, then you can stop the OMS later as described in Step (12) of Upgrading with 1-System Upgrade Approach in Graphical Mode.

- If you are installing software only and upgrading later in graphical mode, then you can stop the OMS later as described in Step (4) in Configuring and Upgrading.

- If you are upgrading in silent mode, then stop the OMS now:

- If you are upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then first run this command on the first OMS you are upgrading. This command stops only the OMS, and not the Admin Server or any of its associated components. The Admin Server and other associated components must be running so that the WebLogic Server credentials can be validated.
$<OMS_HOME>/bin/emctl stop oms

Then, on all other additional OMS instances, run the following command. This command stops the OMS and other components such as the node manager, which must be down for the upgrade to end successfully.

$<OMS_HOME>/bin/emctl stop oms -all

- If you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then run this command from the OMS home:
$<OMS_HOME>/opmn/bin/opmnctl stopall

(g)

Shut down the Management Agent that monitors the Management Services and Repository target.

(h)

Upgrade the OMS and the Management Repository. You can choose to upgrade in graphical or silent mode. You can also choose to install the software binaries at one point and upgrade them later in graphical or silent mode.

If you see an error message stating that you have not copied the emkey, then do the following:

1. Copy the emkey from the old OMS to the old Management Repository. To do so, run the following command from the old OMS home you are trying to upgrade:
For 11g Release 1 (11.1.0.1)

$<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc <conndesc> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

For 10g Release 5 (10.2.0.5)

$<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman password>]

Note: Here, the Management Repository details are the details of the existing Management Repository you are trying to upgrade. <OMS_HOME> is the OMS home you are trying to upgrade. When you upgrade from 11.1.0.1, you will be prompted for the Admin Server password.

2. Try upgrading the OMS and the Management Repository again.

Upgrading with 1-System Upgrade Approach in Graphical Mode, Upgrading with 1-System Upgrade Approach in Silent Mode, Upgrading in Software-Only Mode with 1-System Upgrade Approach in Graphical Mode, or Upgrading in Software-Only Mode with 1-System Upgrade Approach in Silent Mode

Step 5

Perform Postupgrade Task

(a)

Perform the general post-upgrade tasks.

Performing General Postupgrade Tasks

(b)

Track the status of deferred data migration jobs.

Tracking the Status of Deferred Data Migration Jobs

(c)

Sign off agent migration process.

Signing Off Agent Migration Process

(d)

Update the incident rules for metrics associated with the OMS.

Updating Incident Rules

(e)

(Only if you have Application Dependency and Performance (ADP) or JVM Diagnostics (JVMD) installed)

1. If you have not deinstalled the JVMD and ADP applications from your inventory by logging into the WebLogic Administration Console for each monitored domain and removing the jamagent and Acsera application deployments, then do so now.

2. Delete all ad4jTarget targets:
(a) Navigate to the following location:

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

(b) Extract the file jvmd.zip.

(c) Run the script jvmd_targetupgrade11_12.sql.

3. Delete all OCAMM Manager targets:
(a) Navigate to the following location:

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/ocamm/

(b) Extract the file ADPManager.zip.

(c) Run the script adp_targetupgrade11_12.sql.

4. Deploy new JVMD and ADP managers.

5. Deploy new JVMD and ADP agents based on your inventory.

Getting Started with 2-System Upgrade Approach

To upgrade your Enterprise Manager Grid Control to Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2) with 2-system upgrade approach, follow these steps:

Table 7-2 Upgrading Enterprise Manager Grid Control with 2-System Upgrade Approach

Step No.

Step

Procedure

Step 1

Prepare Yourself

(a)

Learn about the 2-System upgrade approach.

Upgrading 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

(b)

Review the important facts you need to know before you begin.

Chapter 2

Step 2

Perform Preupgrade Tasks

(a)

Apply the preupgrade console patch on all your OMS instances to get access to the Preupgrade Console.

Preupgrade Console

(b)

Provide information about the host where you plan to upgrade your existing OMS.

Identifying Host for Enterprise Manager Cloud Control

(c)

Manually download the following software, and stage them to an accessible location:

- Oracle Management Agent 12c

- All the required plug-ins

Installing Plug-Ins While Upgrading Oracle Management Agent 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

(d)

Provide information about the location of the software you manually downloaded and staged in Step 2 (c)

Managing Software

(e)

Analyze your environment to identify Oracle Management Agents (Management Agent) with valid and invalid inventory, check their upgradability status, and identify the problematic Management Agents. If a required software is missing, then repeat Step (c) and Step (d).

Analyzing Your Environment

(f)

Meet the prerequisites for upgrading the Management Agents.

Appendix E

Step 3

Upgrade Oracle Management Service and Oracle Management Repository

Note: Optionally, you can choose to deploy and configure your Oracle Management Agents before upgrading the Oracle Management Service and Oracle Management Repository. In this case, perform Step 4 (a) before Step 3 (a) to Step 3 (l).

(a)

On the remote host where you plan to install Enterprise Manager Cloud Control, meet the following prerequisites:

- Meet the Oracle Management Service-related prerequisites described in the chapter on installing Enterprise Manager Cloud Control, in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- Meet the Management Agent-related prerequisites described in Appendix E.

- Ensure that you are upgrading only on the supported platforms as listed in Supported Platforms for Upgrade.

(b)

Stop all running and scheduled deployment procedures in your existing Enterprise Manager system before upgrading the system.

(c)

(Only if you have Application Dependency and Performance (ADP) or JVM Diagnostics (JVMD) installed)

1. Take an inventory of the JVMs and WebLogic Domains being monitored by JVMD and/or ADP.

2. Deinstall the JVMD and ADP applications from your inventory by logging into the WebLogic Administration Console for each monitored domain and removing the jamagent and Acsera application deployments.

3. Shut down all of your ADP and JVMD managers.

4. Remove all ADP and JVMD managed servers from the GCDomain using the WebLogic Administration Console.

5. Run purge scripts for JVMD:
(a) Navigate to the following location:

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

(b) Extract the file jvmd.zip.

(c) Run the script jvmd_monitoringupgrade11_12.sql.

(d) Run the script jvmd_traceupgrade11_12.sql if there are existing Thread Snapshots from Enterprise Manager 11g Grid Control Release 1 (11.l.0.1) .

(d)

Copy the emkey from the existing OMS, either the Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), to the existing Management Repository before creating a backup of the Management Repository. To do so, run the following command on the old OMS home you are trying to upgrade. The following command is applicable for both releases.

$<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>]

Note: When the following command is run on Enterprise Manager 11g Grid Control (11.1.0.1), you will be prompted for an admin password.

To verify whether the emkey is copied, run the following command:

<OMS_HOME>/bin/emctl status emkey

If the emkey is copied, then you will see the following message:

The EMKey  is configured properly, but is not secure.
Secure the EMKey by running "emctl config emkey -remove_from_repos".

(e)

(Only if your old Enterprise Manager system has Oracle Software Library configured)

If you have Oracle Software Library (Software Library) configured, then back up each of the configured Software Library directories to a location accessible from the remote host where you plan to install Enterprise Manager Cloud Control.

The location to which you back up the directories is required for reconfiguring the Software Library [as described in Step 3 (l)] once you install Enterprise Manager Cloud Control.

For example, if your Software Library was configured in /programs/swlib and /software/swlib, then create two separate archives, one for each configured directory. In this case, create programs_swlib.zip and software_swlib.zip, respectively.

(f)

Back up your existing database, which houses the Management Repository, using the RMAN utility, to a host that can be either a completely new host or the host where your existing OMS is running.

Choose to back up the repository on the host where your existing OMS is running only if you have sufficient space to accommodate it.

Then, create a new database instance out of it so that the repository configured in it can be upgraded.

Note:

- Before backing up the database, ensure that you stop all the running and scheduled deployment procedures in your existing Enterprise Manager system.

- Oracle recommends using the RMAN utility to back up the database.

- If you back up the database using DBCA, then ensure that you unlock all the user accounts, except for MGMT_VIEW user, before installing Enterprise Manager Cloud Control.

- Do not back up the repository using the DB cloning feature in the Enterprise Manager console. If you do, then you will not see the cloned database discovered in the Enterprise Manager console.

- Do not backup while you are in the daylight saving window.

- Any Management Agent or target added to the existing Enterprise Manager system after backing up the Management Repository will not be upgraded and will need to be manually added to the upgraded Enterprise Manager system. To identify the targets that need to be manually added to the upgraded system, see the diff report as described in . Generating and Viewing Diff Reports.

(g)

On the backed up Management Repository, meet the following prerequisites:

- Ensure that the MGMT_CONNECTOR_CONFIG table does not have any NULL rows. To verify this, run the following SQL query.
select * from mgmt_cntr_config where connector_type_guid IS NULL and connector_guid IS null;

Typically, the command must not return any rows. If it does return any rows, then run the following SQL query to clean the table:

delete from mgmt_cntr_config where connector_guid IS NULL or connector_type_guid IS NULL;

commit;

- Ensure that there are no custom-created materialized views in the Management Repository. To verify this, run the following SQL query. Typically, the command must not return any rows. If it does return any rows, then contact Oracle Support.
select count(1) from ALL_MVIEW_LOGS where log_owner=<EM_REPOS_USER>

- Ensure that the tables do not have any snapshots created. To verify this, log in to the Management Repository and run the following SQL query as SYSMAN user:
select master , log_table from all_mview_logs where log_owner='<EM_REPOS_USER>

For example,

select master , log_table from all_mview_logs where log_owner='SYSMAN'

If there are snapshots created in a table, then the query displays the master table and the snapshot details. For example,

SQL> master log_table

em-violations em$violation_log

If there are snapshots, then drop them by running the following command as SYSMAN user:

SQL> Drop snapshot log on <master>

For example,

SQL> Drop snapshot log on em-violations

(h)

Ensure that the character set in the backed up Management Repository is the same as the one in the original Management Repository.

If they are different, you will see the following error:

ERROR emschema.wpxegn6m8wkg - ERROR:ORA-06502: PL/SQL: numeric or value error: character to number conversion error
ORA-06512: at "SYSMAN.EM_CRYPTO", line 62
ORA-06512: at "SYSMAN.EM_CRYPTO", line 229
ORA-06512: at line 1
ORA-06512: at line 24

To verify if the character set is the same, run the following query on the Management Repository:

select * from nls_database_parameters where parameter like '%CHARACTERSET'

If the character set is not the same, then make them identical.

(i)

Remove the emkey from the old Management Repository by running the following command from the old OMS home, either Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1):

$<OMS_HOME>/bin/emctl config emkey -remove_from_repos [-sysman_pwd <pwd>]

(j)

Provide the date and time when the Management Repository was backed up.

Note: Any Management Agent or target added to the existing Enterprise Manager system after backing up the Management Repository will not be upgraded and will need to be manually added to the upgraded Enterprise Manager system. To identify the targets that need to be manually added to the upgraded system, see the diff report as described in . Generating and Viewing Diff Reports.

Providing Repository Backup Details

(k)

Install Enterprise Manager Cloud Control on the remote host and upgrade the Management Repository in the database you backed up in Step 3 (f). You can choose to install in graphical or silent mode. You can also choose to install the software binaries at one point and upgrade them later in graphical or silent mode.

If you see an error message that states that you cannot upgrade your OMS because the host on which you are performing the 2-system upgrade does not match with the host name you have entered in the Preupgrade Console, go to the Prepgrade Console and provide the correct host name.

(Note: If you had chosen to deploy your Management Agents before upgrading the OMS, and if you see this error, fix the error in the Preupgrade Console, and then dploy your Management Agents again, before upgrading the OMS.)

If you see an error message stating that you have not copied the emkey, then do the following:

For 11g Release 1 (11.1.0.1)

1. Copy the emkey from the old OMS to the cloned Management Repository, the one you backed up in Step 3 (f). To do so, run the following command from the old OMS home you are trying to upgrade:
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc <conndesc> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

Note: Here, the Management Repository details are the details of the cloned Management Repository, the one you backed up in Step 3 (f). <OMS_HOME> is the OMS home you are trying to upgrade. You will be prompted for the Admin Server password.

$<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman password>]

2. Try upgrading the OMS and the Management Repository again.

For 10g Release 5 (10.2.0.5)

1. Copy the emkey from the old OMS to the old Management Repository. To do so, run the following command from the old OMS home you are trying to upgrade:
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman password>]

2. Back up the Management Repository as described in Step 3 (f).

3. Meet the prerequisites on the backed up Management Repository as described in Step 3 (g).

4. Remove the emkey from the old Management Repository as described in Step 3 (i).

5. Try upgrading the OMS and the Management Repository again.

(Note: If you had chosen to deploy your Management Agents before upgrading the OMS, and if you see this error, then after running the previous command, make sure you deploy all the Management Agents again. However, after running the command, and before re-deploying the Management Agents, Oracle recommends that you run the installer to ensure that the error about emkey does not reoccur.)

Upgrading with 2-System Upgrade Approach in Graphical Mode, Upgrading with 2-System Upgrade Approach in Silent Mode, Upgrading in Software-Only Mode with 2-System Upgrade Approach in Graphical Mode, or Upgrading in Software-Only Mode with 2-System Upgrade Approach in Silent Mode

(l)

Link the ealier release of the Management Repository with the upgraded Management Repository.

Creating Link to Upgraded Oracle Management Repository

(m)

(Only if your old Enterprise Manager had Software Library configured)

Reconfigure the Software Library in Enterprise Manager Cloud Control so that it is independent of the Software Library configured for the old Enterprise Manager system.

Reconfiguring Oracle Software Library

Step 4

Upgrade Oracle Management Agent

(a)

Deploy and configure the software binaries of Oracle Management Agent 12c.

Deploying and Configuring Oracle Management Agent

(b)

Generate a health report and check the readiness of the predeployed Management Agents.

Generating Health Report of Deployed Oracle Management Agents

(c)

Verify and sign off the health check report.

Verifying and Signing Off the Health Report of Deployed Oracle Management Agents

(d)

Switch over the old Management Agents to the newly deployed ones so that they can communicate with Enterprise Manager Cloud Control.

Note: If you have a large number of agents, then you can choose to upgrade one set of Oracle Management Agents in one attempt, and the next set in the subsequent attempt. In this case, you can repeat Step 4 (a) to Step 4 (d) for each attempt.

Switching Over to Oracle Management Agent 12c

Step 5

Perform Postupgrade Task

(a)

Check the agent upgrade status

Checking Agent Upgrade Status

(b)

Perform the general post-upgrade tasks.

Performing General Postupgrade Tasks

(c)

Track the status of deferred data migration jobs.

Tracking the Status of Deferred Data Migration Jobs

(d)

Track the status of accrued data migration jobs.

Tracking the Status of Accrued Data Migration Jobs

(e)

Generate diff reports to identify all configuration or setup-related changes that were manually made to the earlier release of the Enterprise Manager system while it was being upgraded.

Generating and Viewing Diff Reports

(f)

View a list of targets that are currently inactive in the upgraded Enterprise Manager system.

Viewing Inactive Targets in the Upgraded Enterprise Manager System

(g)

Sign off agent migration process.

Signing Off Agent Migration Process

(h)

Update the incident rules for metrics associated with the OMS.

Updating Incident Rules

(i)

(Only if you have Application Dependency and Performance (ADP) or JVM Diagnostics (JVMD) installed)

1. If you have not deinstalled the JVMD and ADP applications from your inventory by logging into the WebLogic Administration Console for each monitored domain and removing the jamagent and Acsera application deployments, then do so now.

2. Delete all ad4jTarget targets:
(a) Navigate to the following location:

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

(b) Extract the file jvmd.zip.

(c) Run the script jvmd_targetupgrade11_12.sql.

3. Delete all OCAMM Manager targets:
(a) Navigate to the following location:

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/ocamm/

(b) Extract the file ADPManager.zip.

(c) Run the script adp_targetupgrade11_12.sql.

4. Deploy new JVMD and ADP managers.

5. Deploy new JVMD and ADP agents based on your inventory.

Getting Started with 1-System Approach on a Different Host

To upgrade your Enterprise Manager Grid Control to Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2) with 1-system upgrade approach on a different host, follow these steps:

Table 7-3 Upgrading Enterprise Manager Grid Control with 1-System Upgrade Approach on a Different Host

Step No.

Step

Procedure

Step 1

Prepare Yourself

(a)

Learn about the 1-System upgrade approach on a different host.

Upgrading 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

(b)

Review the important facts you need to know before you begin.

Chapter 2

Step 2

Perform Preupgrade Tasks

(a)

Apply the preupgrade console patch on all your OMS instances to get access to the Preupgrade Console.

Preupgrade Console

(b)

Provide information about the host where you plan to upgrade your existing OMS.

Identifying Host for Enterprise Manager Cloud Control

(c)

Manually download the following software, and stage them to an accessible location:

- Oracle Management Agent 12c

- All the required plug-ins

Installing Plug-Ins While Upgrading Oracle Management Agent 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2)

(d)

Provide information about the location of the software you manually downloaded and staged in Step 2 (c).

Managing Software

(e)

Analyze your environment to identify Oracle Management Agents (Management Agent) with valid and invalid inventory, check their upgradability status, and identify the problematic Management Agents. If a required software is missing, then repeat Step (c) and Step (d).

Analyzing Your Environment

(f)

Meet the prerequisites for upgrading the Management Agents.

Appendix E

Step 3

Upgrade Oracle Management Agent

(a)

Deploy and configure the software binaries of Oracle Management Agent 12c.

Deploying and Configuring Oracle Management Agent

(b)

Generate a health report and check the readiness of the predeployed Management Agents.

Generating Health Report of Deployed Oracle Management Agents

(c)

Verify and sign off the health check report.

Verifying and Signing Off the Health Report of Deployed Oracle Management Agents

(d)

Switch over the old Management Agents to the newly deployed ones so that they can communicate with Enterprise Manager Cloud Control.

Note: If you have a large number of agents, then you can choose to upgrade one set of Oracle Management Agents in one attempt, and the next set in the subsequent attempt. In this case, you can repeat Step 3 (a) to Step 3 (d) for each attempt.

Switching Over to Oracle Management Agent 12c

Step 4

Upgrade Oracle Management Service and Oracle Management Repository

(a)

On the remote host where you plan to install Enterprise Manager Cloud Control, meet the following prerequisites:

- Meet the Oracle Management Service-related prerequisites described in the chapter on installing Enterprise Manager Cloud Control, in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- Meet the Management Agent-related prerequisites described in Appendix E.

- Ensure that you are upgrading only on the supported platforms as listed in Supported Platforms for Upgrade.

- Back up the OMS, the Management Repository, and the Software Library. In case the upgrade fails, you can always restore using the backup.
For instructions to back up, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

- Oracle recommends that you identify the deployment size (small, medium, or large) of your Enterprise Manager system, and fine-tune the database parameters as required for your deployment size. For instructions to identify the deployment size and set these database parameters, refer to the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
While upgrading the OMS and the Management Repository using the Enterprise Manager Installation Wizard, the EM Prerequisite Kit is run automatically to verify if the database parameters are set as required for your deployment size. If they are not set to the desired values, then the EM Prerequisite Kit displays a warning against such prerequisite checks. There is a possibility that you might not notice these warnings, or you might notice them but choose to ignore them for a reason—this will increase the upgrade time exponentially. Therefore, Oracle recommends that you set these database parameters as required for your deployment size beforehand.

(b)

On the Management Repository, meet the following prerequisites:

- Ensure that the MGMT_CONNECTOR_CONFIG table does not have any NULL rows. To verify this, run the following SQL query.
select * from mgmt_cntr_config where connector_type_guid IS NULL and connector_guid IS null;

Typically, the command must not return any rows. If it does return any rows, then run the following SQL query to clean the table:

delete from mgmt_cntr_config where connector_guid IS NULL or connector_type_guid IS NULL;

commit;

- Ensure that there are no custom-created materialized views in the Management Repository. To verify this, run the following SQL query. Typically, the command must not return any rows. If it does return any rows, then contact Oracle Support.
select count(1) from ALL_MVIEW_LOGS where log_owner=<EM_REPOS_USER>

- Ensure that the tables do not have any snapshots created. To verify this, log in to the Management Repository and run the following SQL query as SYSMAN user:
select master , log_table from all_mview_logs where log_owner='<EM_REPOS_USER>

For example,

select master , log_table from all_mview_logs where log_owner='SYSMAN'

If there are snapshots created in a table, then the query displays the master table and the snapshot details. For example,

SQL> master log_table

em-violations em$violation_log

If there are snapshots, then drop them by running the following command as SYSMAN user:

SQL> Drop snapshot log on <master>

For example,

SQL> Drop snapshot log on em-violations

(c)

Stop all running and scheduled deployment procedures in your existing Enterprise Manager system before upgrading the system.

(d)

(Only if you have Application Dependency and Performance (ADP) or JVM Diagnostics (JVMD) installed)

1. Take an inventory of the JVMs and WebLogic Domains being monitored by JVMD and/or ADP.

2. Deinstall the JVMD and ADP applications from your inventory by logging into the WebLogic Administration Console for each monitored domain and removing the jamagent and Acsera application deployments.

3. Shut down all of your ADP and JVMD managers.

4. Remove all ADP and JVMD managed servers from the GCDomain using the WebLogic Administration Console.

5. Run purge scripts for JVMD:
(a) Navigate to the following location:

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

(b) Extract the file jvmd.zip.

(c) Run the script jvmd_monitoringupgrade11_12.sql.

(d) Run the script jvmd_traceupgrade11_12.sql if there are existing Thread Snapshots from Enterprise Manager 11g Grid Control Release 1 (11.l.0.1).

(e)

Copy the emkey from the existing OMS, either the Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), to the existing Management Repository. To do so, run the following command on the old OMS home you are trying to upgrade. The following commands are applicable for both releases.

$<OMS_HOME>/bin/emctl config emkey -copy_to_repos [-sysman_pwd <sysman_pwd>]

Note: When the following command is run on Enterprise Manager 11g Grid Control (11.1.0.1), you will be prompted for an admin password.

To verify whether the emkey is copied, run the following command:

<OMS_HOME>/bin/emctl status emkey

If the emkey is copied, then you will see the following message:

The EMKey  is configured properly, but is not secure.
Secure the EMKey by running "emctl config emkey -remove_from_repos".

(f)

If you have a Server Load Balancer (SLB) configured, then make changes to your monitors.

Appendix F

(g)

If your old Enterprise Manager has Oracle Software Library (Software Library) configured on a shared, NFS-mounted drive, then ensure that the shared drive is accessible from the remote host where you plan to install Enterprise Manager Cloud Control.

However, if the Software Library is configured on the local system where the existing, earlier release of Enterprise Manager is running, then copy the Software Library to the remote host where you plan to install Enterprise Manager Cloud Control, in the same directory path as the one maintained in the old Enterprise Manager system.

(h)

Install Enterprise Manager Cloud Control on the remote host and upgrade the Management Repository in the existing database.

Upgrading OMS and Management Repository for 1-System on Different Host Approach

Step 5

Perform Postupgrade Task

(a)

Check the agent upgrade status.

Checking Agent Upgrade Status

(b)

Perform the general post-upgrade tasks.

Performing General Postupgrade Tasks

(c)

Track the status of deferred data migration jobs.

Tracking the Status of Deferred Data Migration Jobs

(d)

Sign off agent migration process.

Signing Off Agent Migration Process

(e)

Update the incident rules for metrics associated with the OMS.

Updating Incident Rules

(f)

(Only if you have Application Dependency and Performance (ADP) or JVM Diagnostics (JVMD) installed)

1. If you have not deinstalled the JVMD and ADP applications from your inventory by logging into the WebLogic Administration Console for each monitored domain and removing the jamagent and Acsera application deployments, then do so now.

2. Delete all ad4jTarget targets:
(a) Navigate to the following location:

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

(b) Extract the file jvmd.zip.

(c) Run the script jvmd_targetupgrade11_12.sql.

3. Delete all OCAMM Manager targets:
(a) Navigate to the following location:

<middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/ocamm/

(b) Extract the file ADPManager.zip.

(c) Run the script adp_targetupgrade11_12.sql.

4. Deploy new JVMD and ADP managers.

5. Deploy new JVMD and ADP agents based on your inventory.

8 Meeting Preupgrade Requirements

This chapter describes the preupgrade requirements you must meet. In particular, this part covers the following:

- Configuring Postupgrade Tasks

- Identifying Host for Enterprise Manager Cloud Control

- Managing Software

- Analyzing Your Environment

- Providing Repository Backup Details

Configuring Postupgrade Tasks

Note:
Follow these instructions only if you are upgrading using the 1-System upgrade approach. Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

By default, soon after the upgrade, Enterprise Manager Cloud Control automatically runs the deferred data migration process (DDMP) jobs. These jobs migrate historical data such as metrics, configuration, and so on from the format stored in the earlier release of Enterprise Manager to the format compatible with Enterprise Manager Cloud Control. For more information DDMP jobs, see Overview of Deferred Data Migration.

Depending on the size of your Enterprise Manager system, these jobs consume a high amount of Management Repository resources and take longer time to complete. In particular, when you upgrade using the 1-System upgrade approach, you might face resource contention as all the Management Agents will be up and running soon after the upgrade.

For better control on these jobs, you may choose to disable the auto-run of these DDMP jobs. If you do so, you must run these jobs later explicitly from the Post Upgrade Tasks page within the Enterprise Manager Cloud Control console.

To disable the auto-run of DDMP jobs, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Select Upgrade Type section, select 1-System.
Enterprise Manager Grid Control refreshes the page and displays a table with a list of tasks you need to perform for the upgrade approach you selected.

4. In the Preupgrade Steps section, from the table, click Configure Postupgrade Tasks.

5. On the Configure Postupgrade Tasks page, select Disable automatic DDMP jobs.

6. Click Save.
Enterprise Manager Grid Control saves the information you provided and returns to the Upgrade Console page that shows a list of tasks to perform for the upgrade approach you selected.

Note:
If you want to run the DDMP jobs explicitly after upgrading to Enterprise Manager Cloud Control, perform Step (3) as described in Tracking the Status of Deferred Data Migration Jobs—select each component and click Start.

Identifying Host for Enterprise Manager Cloud Control

Note:
Follow these instructions only if you are upgrading using the 2-System upgrade approach or the 1-System upgrade approach on a different host. Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

To identify and provide information about the host where you plan to install Enterprise Manager Cloud Control, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Select Upgrade Type section, select one of the following.

- To upgrade your Enterprise Manager system with "near zero" downtime (even if you manually install Management Agents), select 2-System.

- To upgrade your Enterprise Manager system with downtime on a different host, select 1-System on a Different Host.

Enterprise Manager Grid Control refreshes the page and displays a table with a list of tasks you need to perform for the upgrade approach you selected.

4. In the Preupgrade Steps section, from the table, click Identify Host and Port for New Enterprise Manager System.

5. On the Identify Host and Port for New Enterprise Manager System page, enter the following:

- The fully qualified name of the host where you plan to install Enterprise Manager Cloud Control. For example, example.com.

- The secure port and the unsecure upload port you plan to assign for that Enterprise Manager Cloud Control console. For example, 1768.
In case of a multi-OMS environment, if the host on which you plan to install Oracle Management Service 12c is managed by a Server Load Balancer (SLB), then select Click if you wish to have Server Load Balancer (SLB) configured for your Oracle Management Service 12c Release 2 (12.1.0.2.0). Then, enter the fully qualified name, and the secure and unsecure upload ports of the host where the SLB is running.

Note:

- For 2-System upgrade approach and 1-System upgrade approach on a different host, understandably, the host referred to here is any host other than the one where your existing OMS is running. In a Multi-OMS environment this means that a new virtual host name must be used and a new SLB configuration created for this virtual host name.

- Ensure that you install Oracle Management Service 12c on the host entered here, and ensure that you use the same HTTPS and HTTP upload ports entered here. In the installation wizard, on the Port Configuration Details screen, enter the HTTPS upload port for the component Enterprise Manager Upload Http SSL Port, and the HTTP upload port for the component Enterprise Manager Upload Http Port.
If you have already installed Oracle Management Service 12c, then retrieve the values from the emgc.properties file, which is available in the OMS home. For HTTPS upload port, look for the value assigned to the parameter EM_UPLOAD_HTTPS_PORT, and for HTTP upload port, look for the value assigned to the parameter EM_UPLOAD_HTTP_PORT.

- Once you enter the secure and unsecure upload ports here, avoid changing them once the deployment starts.

6. In the Configure Postupgrade Tasks section, select one of the following options:

- Disable automatic DDMP jobs, if you want to prevent the DDMP jobs from running automatically. This option is applicable for 1-System upgrade approach as well as 1-System upgrade approach on a different host.
If you want to run the DDMP jobs explicitly after upgrading to Enterprise Manager Cloud Control, perform Step (3) as described in Tracking the Status of Deferred Data Migration Jobs—select each component and click Start.

Note:
If you disable the DDMP jobs, the ADMP jobs are also disabled by default.

- Disable automatic ADMP jobs, if you want to prevent the ADMP jobs from running automatically. This option is applicable only for 1-System upgrade approach.
If you want to run the DDMP jobs explicitly after upgrading to Enterprise Manager Cloud Control, perform Step (3) as described in Tracking the Status of Accrued Data Migration Jobs.

7. Click Save.
Enterprise Manager Grid Control saves the information you provided and returns to the Upgrade Console page that shows a list of tasks to perform for the upgrade approach you selected.

Managing Software

Note:
Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

To manage information about the location of the core Management Agent software and its associated plug-ins, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Select Upgrade Type section, select one of the following. For information about these upgrade approaches, see "Understanding Upgrade Approaches".

- To upgrade your Enterprise Manager system with downtime (even if you manually install Management Agents), select 1-System.

- To upgrade your Enterprise Manager system with "near zero" downtime (even if you manually install Management Agents), select 2-System.

- To upgrade your Enterprise Manager system with downtime on a different host, select 1-System on a Different Host.

Enterprise Manager Grid Control refreshes the page and displays a table with a list of tasks you need to perform for the upgrade approach you selected.

4. In the Preupgrade Steps section, from the table, click Manage Software.

5. On the Manage Software page, in the Agent Upgradability and Target Upgradability pie charts, click the hyperlinks in the respective legends and identify the Management Agents and targets that can be upgraded, and that cannot be upgraded due to unavailability of the Management Agent software or the plug-in software.

6. In the Provide Software Location section, enter the absolute path to the directory where the core Management Agent software and the plug-in software are present for the required platforms.
For example, /john/software/oracle/em/.

And then, click Validate to register that location with the Enterprise Manager system.

Note:

- The absolute path you enter must be to a staging location that contains both the Management Agent software and the plug-in software.
To download the Management Agent software and the plug-ins, follow these steps

(a) Access the following URL:

http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

(b) Download the Management Agent software to an accessible location. Do NOT extract the contents of the software ZIP file. The Management Agent software is platform-specific, so ensure that you copy the software for the platform on which you want to install.

(c) Download all the required plug-ins to the same location. Plug-ins are generic, so they are common for all platforms.

Ensure that you download all the plug-ins listed as required plug-ins on the Manage Software page, whether or not you want to monitor a target with them. You may feel that a few plug-ins are not required because you do not have targets to be monitored by them, but those plug-ins may be required for upgrading your system. Therefore, download all the plug-ins listed on the Manage Software page. Ensure that you download these plug-ins before backing up the database that contains the Management Repository.

- Ensure that the core Management Agent software and the plug-in software you provide have read permission, and ensure that the location in which they are present has read and write permission.

- If you plan to install multiple Oracle Management Services (OMS instances), then ensure that the location you enter is writable and accessible to all the OMS instances.

- If you have a plug-in version deployed to the earlier release of Enterprise Manager that is not supported in Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), for example, EBS 2.0 and 3.0 plug-in versions, then do NOT provide the software of the higher version of that plug-in even if its available for download. This ensures that the unsupported version is removed while upgrading to 12c Release 2 (12.1.0.2). After you upgrade, you can deploy the higher version directly from the Plug-In Manager.

- After registering the locations of the Management Agent software and the plug-in software, if you download some more plug-ins at a later stage in the same or a different location, then register the location of those recently downloaded plug-ins as well.

- The validation and registration process might take some time to complete, so after you click Validate, wait for some time for the process to end. Once the process ends, you should see a message confirming that the location has been successfully registered.

Note:
If you are deploying Oracle Management Agent 12c on platforms such as Red Hat Enterprise Linux 4.x, Oracle Linux 4.x, or SUSE Linux Enterprise 10, then ensure that you deploy only the 32-bit version of the Management Agent software. Do not deploy the 64-bit version because it is not supported on these platforms.
However, despite using the 32-bit version, while validating the software on the Manage Software page, if you see an error stating that the 32-bit version is not supported, then follow these steps to resolve the issue:

1. Run the following SQL query in the old Management Repository as a sysman user. Ensure that the Management Repository is not already upgraded at this point.
update PRE_UPGC_AGT_STAT_MGMT set PLATFORM_ID='46', PLATFORM_NAME='Linux x86-64' where OS_VERSION like '%Enterprise Linux%elease%4%' and PLATFORM_ID='226';

update PRE_UPGC_AGT_STAT_MGMT set PLATFORM_ID='46', PLATFORM_NAME='Linux x86-64' where OS_VERSION like '%SUSE%10%' and PLATFORM_ID='226';

commit;

2. On the Manage Software page, enter the absolute path to the location where the 32-bit version of the Management Agent software is available, and click Validate.

3. In the Agent Upgradability pie chart, verify if the Management Agent appears as an upgradable target.

Analyzing Your Environment

This chapter describes how you can analyze your existing Oracle Management Agents (Management Agent) and prepare yourself to upgrade them. In particular, this chapter covers the following:

- Identifying Management Agents with Valid Inventory

- Identifying Management Agents with Invalid Inventory

- Checking the Upgradability Status of Oracle Management Agents

- Checking the Upgradability Status of Targets

- Identifying Problematic Oracle Management Agents

- Identifying Management Agents That Need to Be Reconfigured

- Identifying Management Agents That are Not Supported in Enterprise Manager 12c

- Identifying Management Agents That are Installed after Repository Back-Up

- Identifying Broken Targets

Note:
Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

Identifying Management Agents with Valid Inventory

Every Oracle software product, including Oracle Management Agent (Management Agent) installed on a host is registered with the central inventory (oraInventory). Every Oracle software product has an entry in the inventory.xml file, which is present in the oraInventory directory. If a Management Agent is registered with the central inventory, then it is a Management Agent with valid inventory.

To identify Management Agents with valid inventory, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Agent Upgrade Status section, view the count displayed against Agents with Valid Inventory.
To drill down and view more information about each of the Management Agents, click the count value.

Enterprise Manager Grid Control displays the Upgrade Status page that provides information such as the platform on which the Management Agents are running; their versions; their old and new Oracle home locations; and their deployment, configuration, health check, and switch over status.

Note:

- The count displayed here does not include the Management Agents with invalid inventory and the Management Agents that were installed after the count was determined.

- To consider the Management Agents that have an invalid inventory, first resolve the issue with such Management Agents. Ensure that there are no such faulty Management Agents. For information on how to identify such Management Agents and resolve them, see Identifying Management Agents with Invalid Inventory. Once you have resolved the issue, click Refresh Agents and Targets List.

- To consider the Management Agents that were installed after the count was determined, refresh the list by clicking Refresh Agents and Targets List.

Identifying Management Agents with Invalid Inventory

Every Oracle software product, including Management Agent installed on a host is registered with the central inventory (oraInventory). Every Oracle software product has an entry in the inventory.xml file, which is present in the oraInventory directory.

However, there may be circumstances when an entry for a Management Agent might be missing, incomplete, or corrupt, or the entry might be existing with an incorrect syntax. In addition, there is also a possibility that the host configuration was not refreshed and the latest configuration was not collected. If a Management Agent is not registered with the central inventory for such reasons, then it is a Management Agent with invalid inventory.

Management Agents with invalid inventory do not appear in the Preupgrade Console, and as a result, you will not be able to upgrade them until the issues are fixed.

To identify Management Agents with invalid inventory, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Agent Upgrade Status section, view the count displayed against Agents with Invalid Inventory.
To drill down and view more information about each of the Management Agents, click the count value.

Note:
To resolve this issue, follow these steps:

1. Check the entry for these Management Agents in the inventory.xml file.
The inventory.xml file is present in the oraInventory directory (central inventory). The location of the oraInventory directory is mentioned in the oraInst.loc file that you pass while invoking the installer in silent mode. Ensure that the entry is present with the correct syntax.

2. Refresh the host configuration in one of the following ways:
(a) Go to the home page of the host. Click the Configuration tab. On the Configuration page, click Refresh.

(b) Go to the Deployments page. In the Configuration section, click Refresh Host Configuration.

If Step 2 (a) or Step 2 (b) fail, then run the following command from the Management Agent home:

$<AGENT_HOME>/bin/emctl control agent runCollection

3. Refresh the agent list in the Preupgrade Console.
Go to the Preupgrade Console. In the Agent Upgrade Status section, click Refresh Agents and Targets List.

Checking the Upgradability Status of Oracle Management Agents

To check the upgradability status of the Management Agents, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Preupgrade Steps section, from the table, click Manage Software.

4. On the Manage Software page, view the Agent Upgradability pie chart. The pie chart graphically shows the following information:

- Completely Upgradable - Number of Management Agents that can be fully upgraded because the Management Agent software and all the associated, target-specific management plug-in software are available.

- Missing Plug-Ins Software - Number of Management Agents that can be partially upgraded because the Management Agent software and only a few of the associated, target-specific management plug-in software are available. Some management plug-in software are either missing or unsupported in the upgraded Enterprise Manager system.

- Missing Agent Software - Number of Management Agents that cannot be upgraded because the Management Agent software is not available. The associated, target-specific management plug-in software might be available, but the core Management Agent software is not available.

- Not Supported - Number of Management Agents that are not supported in the upgraded Enterprise Manager system because Oracle Management Agent 12c has not been released for a particular platform. The targets monitored by those Management Agents can no longer be monitored in the upgraded Enterprise Manager system.

Checking the Upgradability Status of Targets

To check the upgradability status of the targets, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, do one of the following:

- In the Other Links section, click Targets Upgradability Status.
On the Targets Upgradability Status page, use the search functionality to search and identify the targets that can either be monitored or not monitored in the upgraded Enterprise Manager system.

For example, to list the targets that cannot be monitored in the upgraded Enterprise Manager system, from the Upgrade Status list, select Not Upgradable. Similarly, to list the target that can be monitored, select Upgradable.

- In the Preupgrade Steps section, from the table, click Manage Software.
On the Manage Software page, view the Target Upgradability pie chart. The pie chart graphically shows the following information:

- Upgradable - Number of targets that can be monitored in the upgraded Enterprise Manager system because the Management Agent software and the associated, target-specific management plug-in software are available.

- Missing Agent/Plug-In Software - Number of targets that cannot be monitored in the upgraded Enterprise Manager system because either the Management Agent software is missing or the associated management plug-in software is missing.

- Not Supported - Number of targets that cannot be monitored in the upgraded Enterprise Manager system because either Oracle Management Agent 12c has not been released for the platforms on which the targets are running, or the management plug-ins for those targets are not supported in the upgraded Enterprise Manager system.

- Plug-In Software Not Certified - Number of targets that cannot be monitored in the upgraded Enterprise Manager system because the management plug-ins for those targets are not certified.

Identifying Problematic Oracle Management Agents

There may be Management Agents that cannot be upgraded due to technical issues such as missing host target, association with multiple host targets, unreachable state, invalid inventory, and so on.

To identify such problematic Management Agents, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Other Links section, click Problematic Agents.

4. On the Problematic Agents page, view the Management Agents that cannot be upgraded.

- To search for a particular Management Agent, enter the Management Agent name in the Agent field, and click Search.

- To filter the Management Agents based on a particular technical reason, select one of the following reasons from the Reason list, and click Search:

- Missing Repository Inventory - Lists the Management Agents that are not registered with the central inventory (oraInventory).

- Multiple Host Target - Lists the Management Agents that are either associated with or monitoring more than one host.

- Agent Unreachable - Lists the Management Agents that are down.

- Host Target Missing - Lists the Management Agents whose hosts are not discovered and monitored in the Enterprise Manager Grid Control console. The Management Agents themselves may be monitored but their hosts may not be monitored for some reason.

- All - Lists all the Management Agents that have one or more issues listed in the Reason list.

Identifying Management Agents That Need to Be Reconfigured

You might have to reconfigure the Management Agents for one of the following reasons:

- If the OMS host and port with which you deployed a Management Agent do not match with the OMS host and port with which you deployed the other Management Agents.

- You have either deleted one or more targets monitored by this Management Agent, or added new targets to be monitored by this Management Agent. To resolve this issue, reconfigure this Management Agent so that the new configuration can take effect.

- The versions of the plug-ins you deployed with this Management Agent are different from the versions of the plug-ins you deployed with the other Management Agents. To resolve this issue, deploy this Management Agent again with the correct plug-in versions.

To identify the Management Agents that need to be reconfigured, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Other Links section, click Agents Needing Reconfiguration.

4. On the Agents Needing Reconfiguration page, view the Management Agents that need to be reconfigured. The table not only lists the Management Agents but also provides the following reasons for you to reconfigure them.

- OMS Host and Port Mismatch
Indicates that the OMS host and port with which you deployed the Management Agent do not match with the OMS host and port with which you deployed the other Management Agents. To resolve this issue, access the Identify Host and Port for New Enterprise Manager System page, correct the OMS host and port, and deploy this Management Agent again.

- Targets Deleted or Added
Indicates that you have either deleted one or more targets monitored by this Management Agent, or added new targets to be monitored by this Management Agent. To resolve this issue, reconfigure this Management Agent so that the new configuration can take effect.

- Plug-In Version Mismatch
Indicates that the versions of the plug-ins you deployed with this Management Agent are different from the versions of the plug-ins you deployed with the other Management Agents. To resolve this issue, deploy this Management Agent again with the correct plug-in versions.

Identifying Management Agents That are Not Supported in Enterprise Manager 12c

If the core agent software has not been released for the platforms on which the Management Agents run, then these Management Agents will not be supported in Enterprise Manager 12c. Technically, the target or target monitored by those agents can no longer be monitored in the upgraded Enterprise Manager system.

To identify the Management Agents that are not supported in Enterprise Manager 12c, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Other Links section, click Agents Not Supported in Enterprise Manager 12c.

4. On the Agents Not Supported in Enterprise Manager 12c page, view the Management Agents that are not supported in Enterprise Manager 12c.

Identifying Management Agents That are Installed after Repository Back-Up

When upgrading Management Agents to Enterprise Manager 12c using the 2-system approach, if agents are installed after Repository Back-Up, then these agents will not be able to migrate to Enterprise Manager 12c system. You will have to push these 12c Management Agents from the 12c system and rediscover these targets.

To identify the Management Agents that are not supported in Enterprise Manager 12c, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Other Links section, click Agents Installed after Repository Back-Up.

4. On the Agents Installed after Repository Back-Up page, view the Management Agents that are installed after Repository-Back-Up.

Identifying Broken Targets

A broken target indicates that the deployed Management Agent from the Enterprise Manager 12c system is not in a position to monitor the target that was monitored earlier by the old Management Agent.

To identify the broken targets, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Other Links section, click Broken Targets.

4. On the Broken Targets page, view the list of broken targets. The table not only lists the broken targets but also provides the reason for the broken target, the type of target, the name of the Agent, the name of the Plug-In, and the Platform.

Providing Repository Backup Details

Note:
Follow these instructions only if you are upgrading using the 2-System upgrade approach. Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

To provide information on when you backed up your Oracle Management Repository, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Select Upgrade Type section, select 2-System. For information about these upgrade approaches, see "Understanding Upgrade Approaches".
Enterprise Manager Grid Control refreshes the page and displays a table with a list of tasks you need to perform for the upgrade approach you selected.

4. In the OMS and Repository Upgrade Steps section, from the table, click Provide Repository Backup Details.

5. On the Provide Repository Backup Details page, provide the date and time when you backed up your Oracle Management Repository.

6. Click Save.

9 Upgrading Oracle Management Agents

This chapter describes how you can upgrade your Oracle Management Agents. In particular, this part covers the following:

- Deploying and Configuring Oracle Management Agent

- Generating Health Report of Deployed Oracle Management Agents

- Verifying and Signing Off the Health Report of Deployed Oracle Management Agents

- Switching Over to Oracle Management Agent 12c

Deploying and Configuring Oracle Management Agent

To deploy Oracle Management Agent 12c, follow these steps:

Note:

- Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

- You cannot deploy and configure Oracle Management Agent 12c for problematic Management Agents. To identify the problematic Management Agents, see Identifying Problematic Oracle Management Agents.

- You must deploy and configure Oracle Management Agent 12c only on existing Management Agents that are completely upgradable. To identify whether the Management Agents are completely upgradable, see Checking the Upgradability Status of Oracle Management Agents.

- For 2-system upgrade, do NOT deploy Oracle Management Agent 12c on the remote OMS host because the Enterprise Manager installer will take care of installing it while installing Oracle Management Service 12c.

- For 2-system upgrade and 1-system upgrade on a different host, do NOT deploy Oracle Management Agent 12c for the central agent. Central agent is the Management Agent installed with the old OMS.

- To deploy and configure Oracle Management Agent 12c, the existing connectivity between the old Management Agent and the OMS is used; SSH is not used.

- For 2-system upgrade, if your old Management Agent was running in secure (or unsecure) mode before backing up the Management Repository, then ensure that it continues to run in the same mode while you deploy and configure the new Management Agent for it. Do not resecure the Management Agents after backing up the Management Repository. If you do so, the ping test might fail while performing the healthcheck because of a mismatch between the configuration stored in the repository and the actual configuration of the Management Agent. You will see a KEY_MISMATCH error in gcagent.log. For information on this error and to know how to secure the Management Agents without facing this issue, see Appendix I.

- If the agent configuration has changed after backup, then you must redeploy and reconfigure the Management Agents. If this is already done after the configuration changes, but you still see an error during the switchover process, then log out and log in to the Enterprise Manager Grid Control Console (old EM Console) and retry the switchover process.

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Select Upgrade Type section, select one of the following. For information about these upgrade approaches, see "Understanding Upgrade Approaches".

- To upgrade your Enterprise Manager system with downtime (even if you manually install Management Agents), select 1-System.

- To upgrade your Enterprise Manager system with "near zero" downtime (even if you manually install Management Agents), select 2-System.

- To upgrade your Enterprise Manager system with downtime on a different host, select 1-System on a Different Host.

Enterprise Manager Grid Control refreshes the page and displays a table with a list of tasks you need to perform for the upgrade approach you selected.

4. In the Preupgrade Steps section, from the table, click Deploy and Configure Agents.

5. On the Deploy and Configure Agents page, for Operation Name, enter a unique name for the deployment operation you are about to perform. The custom name you enter can be any intuitive name, and need not necessarily be in the same format as the default name.
For example, Deploy_Agents_Phase1_2010_12_23.

Note:
The operation name you enter here is only a logical name and will be used for saving the details of the operation you are about to perform. After deploying the software binaries of Oracle Management Agent 12c, at a later point in time, if you want to check the health of the deployed Management Agents or switch over from old to newly deployed and configured Management Agents, then you can use the operation name to identify and track the Management Agents selected as part of this operation.

6. In the Select Operation Type section, select Deploy Agent and Plug-In Software and Configure Agent and Plug-In Software.

Note:
If you had already deployed the software binaries of the Management Agent, then you can choose to only configure them now. In this case, select only Configure Agent and Plug-In Software.

7. In the Search Agents section, search and add the existing, old Management Agents for which you want to deploy the software. To understand how to search and add Management Agents, see Appendix H.

Note:

- If you had already deployed the software binaries of the Management Agent, and if you are only configuring them at this point, then search (or add) and select the Management Agents for which you had already manually deployed the software.

- If you are adding a Shared Agent, then ensure that you add the Master Agent to which it communicates, and all the Shared Agents that communicate with this Master Agent.

- When you return to this screen to retry the deploy operation, you will see the Management Agents selected as part of the previous deploy operation. This is an expected behavior. You can choose to redeploy the software binaries for them, or remove them from the list and add a fresh set of Management Agents.

8. In the table that lists the Management Agents, enter an installation base directory and an instance home directory for each of the Management Agents.

Note:

- Ensure that the installation base directory you enter here is NOT inside the Middleware home.

- Ensure that the installation base directory has at least 1 GB of free disk space.

- If you had already deployed the software binaries of the Management Agent, and if you are only configuring them at this point, then enter the same installation base directory and the instance home directory where you had deployed the software binaries.

- Ensure that the installing user owns the agent base directory. Ensure that the installing user or the root user owns all the parent directories. Ensure that the root user owns the root directory. And ensure that all of these directories have read and execute permissions for group and other users.
For example, if the agent base directory is /scratch/OracleHomes/agent, and if oracle is the installing user, then the /scratch/OracleHomes/agent directory must be owned by oracle, directories scratch and OracleHomes must be owned by either oracle or root user, and the root directory (/) must be owned by root user. And directories /, scratch, and OracleHomes have read and execute permissions.

If you want the paths to the installation base directory and the instance home directory to be the same across Management Agents, then select Use Same Paths for All Agents, and enter the absolute path for installation base directory and instance home directory, just once, for the first Management Agent listed in the table. Enterprise Manager Grid Control will consider the same paths for other Management Agents listed in the table.

Note:
You cannot select Use Same Paths for All Agents with the installation base directory mentioned for one Management Agent and the instance home directory mentioned for another Management Agent in the table. Only the paths specified for the first Management Agent will be considered as the same paths for other Management Agents in the table.

If the agent base directory or the agent instance home directory specified by you already exists, and if you want to overwrite them, then select Overwrite Any Existing Directories. Typically, you will select this option when you choose to redeploy the software binaries in the same base directory.

9. After you add the Management Agents, select each of them from the Select column.

10. In the Agent Credentials section, retain the default selection, that is, Use Oracle Home Preferred Credentials, so that the preferred credentials stored in the Management Repository can be used for this job.

Note:
Ensure that the preferred credentials were registered with the Enterprise Manager system using the Enterprise Manager Command Line Interface (EM CLI). For more information, see Setting Preferred Credentials Using EM CLI.

You can optionally override these preferred credentials. To do so, select Override Oracle Home Preferred Credentials and enter one set of credentials that can be used for all Oracle homes.

Note:
Ensure that you use the same credentials that you used for the existing, earlier release of the Management Agent

11. In the Run Privilege section, by default, None is selected assuming that the credentials you have provided in the previous step have the privileges to run this job.
However, if those credentials do not have the privileges to run this job, and if you want to switch over as another user for this purpose, then select either SUDO or Power Broker, depending on the authentication utility you want to use, and provide the user account name and profile.

12. (Applicable Only for 2-System Upgrade) In the OMS Host and Port section, validate the name and the secure port of the host where you plan to install Oracle Management Service 12c. To change the values, click Edit.

Note:
If you had already upgraded your existing OMS to Oracle Management Service 12c, then ensure that the port you enter here matches with the Enterprise Manager Upload HTTP SSL Port you selected or specified in the installer while upgrading the OMS.

13. Click Next.

14. On the Optional Details page, in the Pre-Deploy Options section, select Run Pre-Command/Script if you want to run any script before deploying the software binaries of the Management Agents.
Enter the absolute path to a location on the destination host where the script is available. The script can also be in a shared location, but you must have execute privileges on it to run the script.

Note:
By default, the credentials provided in Step (10) are used for running the script. And by default, None is selected assuming that the credentials have the privileges to run the script.
However, if those credentials do not have the privileges to run the script, and if you want to switch over as another user for this purpose, then select either SUDO or Power Broker, depending on the authentication utility you want to use, and provide the user account name and profile.

15. In the Post-Config Options section, select Run Post-Command/Script if you want to run any script after configuring the deployed Management Agents.
Enter the absolute path to a location on the destination host where the script is available. The script can also be in a shared location, but you must have execute privileges on it to run the script.

Note:
By default, the credentials provided in Step (10) are used for running the script. And by default, None is selected assuming that the credentials have the privileges to run the script.
However, if those credentials do not have the privileges to run the script, and if you want to switch over as another user for this purpose, then select either SUDO or Power Broker, depending on the authentication utility you want to use, and provide the user account name and profile.

16. (Only for UNIX) In the Root Credentials section, enter the credentials of a user account to run the root.sh script.

Note:
By default, None is selected assuming that the credentials have the privileges to run the script. However, if those credentials do not have the privileges to run the script, and if you want to switch over as another user for this purpose, then select either SUDO or Power Broker, depending on the authentication utility you have, and provide the user account name and profile.
If you do not have root credentials, then enter the agent credentials. In this case, the root.sh script is not run, but the deployment succeeds. Ensure that you manually run this script after deployment. Otherwise, you will not be able to run jobs on the Management Agent.

17. Click Submit.

Note:

- After you submit the operation, if you see the following error, then first run root.sh from the old Management Agent home, and then, resubmit this operation.

ERROR: NMO not setuid-root (Unix-only)

- If you see the following error, then verify the credentials entered in Step (10).

Local Authentication Failed...Attempt PAM authentication...PAM failed . . .

- If the deployment operation fails at some point, you can choose to only reconfigure the Management Agents, and not copy the software binaries all over again. To only reconfigure the Management Agents, repeat the instructions outlined in this procedure, but for Step (6) ensure that you select only Configure Agent and Plug-In Software.

- When the operation is in progress, if a Management Agent being deployed and configured becomes unavailable for some reason, you may see the status Suspended on Event. Once the Management Agent becomes available, the status automatically changes to show the current state. This is an expected behavior.

- If the credentials entered in Step (10) are incorrect, then the step for running the root.sh script fails in the predeployment job, but the job as such shows that it is successful. In this case, manually run the root.sh script using the correct root credentials. Otherwise, the Management Agent will result in NMO errors.

Generating Health Report of Deployed Oracle Management Agents

Before you switch over from your old, existing Management Agent to the newly deployed and configured Oracle Management Agent 12c, generate a report to check the health and the readiness of the deployed Management Agents so that any issues with the deployment can be identified beforehand.

For all the Management Agents to switch over successfully and function properly in the upgraded Enterprise Manager system, you must ensure that the Management Agents are in a position to contact the upgraded Oracle Management Service, monitor all the targets they monitored before, and collect all the metrics details they collected before. The health report helps in identifying any issues related to these requirements so that you can resolve them beforehand.

Note:
Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

Note:
You can generate health reports only for Management Agents that have been successfully deployed and configured.

To generate a health report of the deployed Management Agents and check their readiness, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Agent Upgrade Steps section, from the table, click Generate Health Report of Deployed Agents.

4. On the Generate Health Report for Deployed Agents page, in the Provide Inputs section, do the following:

1. Enter a unique name for the deployment operation you are about to perform. The custom name you enter can be any intuitive name, and need not necessarily be in the same format as the default name.
For example, CheckHealth_Agents_Phase1_2010_12_23.

Note:
The operation name you enter here is only a logical name and will be used for saving the details of the operation you are about to perform. After checking the health of the deployed Management Agents, at a later point in time, if you want to switch over from old to newly deployed and configured Management Agents, then you can use the operation name to identify and track the Management Agents selected as part of this operation.

2. If you want to perform the readiness check for the Management Agents you had previously deployed, then click the torch icon against Load Agents from Previous Operations, and select the operation you had submitted for deploying those Management Agents, click Go.
Enterprise Manager Grid Control populates the table in the Search Agents section with a list of Management Agents that are associated with the operation you selected.

5. In the Search Agents section, search and add the Management Agents for which you want to perform the readiness check:

- If you specified a readiness operation name as described in Step 4 (a), then search (or add) and select the existing, old Management Agents for which you have already deployed the software and for which you want to check the health now. To understand how to search and add Management Agents, see Appendix H.

- If you selected a deployment operation as described in Step 4 (b), then review the Management Agents that are displayed based on the operation you selected.

6. After you add the Management Agents, select each of them from the Select column.

7. In the Agent Credentials section, retain the default selection, that is, Use Oracle Home Preferred Credentials, so that the preferred credentials stored in the Management Repository can be used for this job.

Note:
Ensure that the preferred credentials were registered with the Enterprise Manager system using the Enterprise Manager Command Line Interface (EM CLI). For more information, see Appendix G.

You can optionally override these preferred credentials. To do so, select Override Oracle Home Preferred Credentials and enter one set of credentials that can be used for all Oracle homes.

Note:
Ensure that you use the same credentials that you used for the existing, earlier release of the Management Agent

8. Click Submit.

Note:

- After you submit the operation, if you see the following error, then first run root.sh from the old Management Agent home, and then, resubmit this operation.

ERROR: NMO not setuid-root (Unix-only)

- If you see the following error, then verify the credentials entered in Step (10).

Local Authentication Failed...Attempt PAM authentication...PAM failed . . .

- When the operation is in progress, if a Management Agent for which you are performing a readiness check becomes unavailable for some reason, you may see the status Suspended on Event. Once the Management Agent becomes available, the status automatically changes to show the current state. This is an expected behavior.

- If you were monitoring a SOA target in your earlier release of Enterprise Manager, then in the health report, you might see metric collection errors for the following metrics:

- Top SOA SQL Queries

- Dehydration Store Tables

As this stage, you can ignore these errors and proceed further. However, ensure that you provide the database credentials for this target as described in Performing General Postupgrade Tasks.

Verifying and Signing Off the Health Report of Deployed Oracle Management Agents

Before you switch over from your old, existing Management Agent to the newly deployed and configured Oracle Management Agent 12c, verify and sign off the health report of deployed Management Agents.

For all the Management Agents to switch over successfully and function properly in Enterprise Manager Cloud Control, you must ensure that the Management Agents are in a position to contact the upgraded Oracle Management Service (OMS), monitor all the targets they monitored before, and collect all the metrics details they collected before. The health report helps in identifying any issues related to these requirements so that you can resolve them beforehand.

Note:
Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

To verify and sign off the health report, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Agent Upgrade Steps section, from the table, click Sign Off Health Report for Deployed Agents.

4. On the Sign Off Health Report for Deployed Agents page, view the health and the readiness details for each of the Management Agents.

- Verify the Ping Test column, which indicates whether or not the deployed Oracle Management Agent 12c will be able to contact the upgraded OMS.

Note:

For 1-System upgrade, in the Ping Test column, you will see the value N/A.

For 2-System upgrade, you will see either Passed or Failed. The status Passed indicates that the ping test was successful, and the status Failed indicates that the test was unsuccessful. If you see the status Failed for any Management Agent, then do the following:

- Verify the OMS host name and OMS port entered in the Identify Host and Port for New Enterprise Manager System page.
Alternatively, verify the REPOSITORY_URL parameter in the following file. Here, <Agent_Instance_Home> refers to the 12c agent home.

<Agent_Instance_Home>/sysman/config/emd.properties

If the OMS host name and port are correct, then check for errors in the following log file:

<Agent_Instance_Home>/sysman/log/gcagent.log

- If any Management Agent is in unsecure mode, and if you have already upgraded the OMS, then run these commands on the upgraded OMS (12c OMS), generate the health check report again, and then switch over:
$<OMS_HOME>/bin/emctl secure unlock -console

$<OMS_HOME>/bin/emctl secure unlock -upload

Caution:
If your old Management Agent was running in secure (or unsecure) mode before backing up the Management Repository in case of the 2-System upgrade approach, then ensure that it continues to run in the same mode while you deploy and configure the new Management Agent for it. Otherwise, the ping test can fail due to a mismatch between the configuration stored in the repository and the actual configuration of the Management Agent.

- Verify the Broken Targets column, which indicates whether or not the deployed Oracle Management Agent 12c will be in a position to monitor all the targets that were monitored earlier by the old Management Agent. The numeric value you see in the column indicates the number of targets that cannot be monitored in the upgraded system.
If you see any value other than 0, then view the detailed report (as described in the next step) to see a list of broken targets and the reasons why they are broken.

- Verify the Failed Metrics column, which indicates whether or not the deployed and configured Oracle Management Agent 12c will be able to collect all the metrics in the upgraded Enterprise Manager system. The numeric value you see in the column indicates the number of metrics that have an issue.
If you see any value other than 0, then view the detailed report (as described in the next step) to see a list of failed metrics and the reasons for their failure.

- Verify the Sign-Off User column and the User Verified Column, which indicate whether or not the health report was signed off for a Management Agent. If you do not see any value in these columns, then formally sign off the report as described in Step (6).

5. If you want to view a detailed report, select the Management Agent for which you want to view a detailed report, and click View Detailed Report.

6. After checking the report, click Verify and Sign Off Report to sign off. Ensure that the Management Agent for which you viewed a detailed report is selected.

Note:

- After you submit the operation, if you see the following error, then first run root.sh from the old Management Agent home, and then, resubmit this operation.

ERROR: NMO not setuid-root (Unix-only)

- If you see the following error, then verify the credentials entered in Step (10).

Local Authentication Failed...Attempt PAM authentication...PAM failed . . .

- If you were monitoring a SOA target in your earlier release of Enterprise Manager, then in the health report, you might see metric collection errors for the following metrics:

- Top SOA SQL Queries

- Dehydration Store Tables

As this stage, you can ignore these errors and proceed further. However, ensure that you provide the database credentials for this target as described in Performing General Postupgrade Tasks.

Switching Over to Oracle Management Agent 12c

To switch over the existing, earlier release of Oracle Management Agents (Management Agent) to the newly deployed Management Agents, so that they can communicate with Enterprise Manager Cloud Control, follow these steps:

Note:
Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

Note:
If you are upgrading using the 2-system upgrade approach or the 1-system upgrade approach on a different host, then do NOT select the old central agent, that is, the Management Agent installed with the old OMS, for switchover.
If you want to continue monitoring the targets that were monitored by the central agent, adopt one of the approaches described in Monitoring Targets That Were Monitored by the Central Agent.

Note:
If the agent configuration has changed after backup, then you must redeploy and reconfigure the Management Agents. If this is already done after the configuration changes, but you still see an error during the switchover process, then log out and log in to the Enterprise Manager Grid Control Console (old EM Console) and retry the switchover process

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Agent Upgrade Steps section, from the table, click Switch Agents.

4. On the Switch Agents page, in the Provide Inputs section, do the following:

1. Enter a unique name for the switchover operation you are about to perform. The custom name you enter can be any intuitive name, and need not necessarily be in the same format as the default name.
For example, Switch_Agents_Phase1_2010_12_23

Note:
The operation name you enter here is only a logical name and will be used for saving the details of the operation you are about to perform. After submitting this operation, if you want to track its status, then you can use the operation name.

2. If you want to switch over the Management Agents for which you had previously performed a readiness check, then click the torch icon against Load Agents from Previous Operations, and select the operation you had submitted for performing the readiness check for those Management Agents, click Go.
Enterprise Manager Grid Control populates the table in the Search Agents section with a list of Management Agents that are associated with the operation you selected.

5. In the Search Agents section, search and add the Management Agents you want to switch over:

- If you specified a switchover operation name as described in Step 4 (a), then search (or add) and select the deployed Management Agents that you want to switch over now. To understand how to search and add Management Agents, see Appendix H.

- If you selected an operation name as described in Step 4 (b), then review the Management Agents that are displayed based on the operation you selected.

6. After you add the Management Agents, select each of them from the Select column.

7. In the Agent Credentials section, retain the default selection, that is, Use Oracle Home Preferred Credentials, so that the preferred credentials stored in the Management Repository can be used for this job.

Note:
Ensure that the preferred credentials were registered with the Enterprise Manager system using the Enterprise Manager Command Line Interface (EM CLI). For more information, see Appendix G.

You can optionally override these preferred credentials. To do so, select Override Oracle Home Preferred Credentials and enter one set of credentials that can be used for all Oracle homes.

Note:
Ensure that you use the same credentials that you used for the existing, earlier release of the Management Agent

8. Click Submit.

Important Points to Keep in Mind

Keep these points in mind:

- After you submit the operation, if you see the following error, then first run root.sh from the old Management Agent home, and then, resubmit this operation.

ERROR: NMO not setuid-root (Unix-only)

- If you see the following error, then verify the credentials entered in Step (10).

Local Authentication Failed...Attempt PAM authentication...PAM failed . . .

- When the operation is in progress, if a Management Agent being deployed and configured becomes unavailable for some reason, you may see the status Suspended on Event. Once the Management Agent becomes available, the status automatically changes to show the current state, and eventually gets switched over. This is an expected behavior.

- In the 2-System upgrade approach, all the old Management Agents you selected are switched over, and the upgraded Management Agents are started so that they can communicate with the upgraded OMS.

- In the 1-System upgrade approach, if you missed switching over any Management Agent and upgraded the OMS inadvertently, then you must manually switch over those Management Agents by first stopping the old Management Agents and then starting the new ones:
(a) Stop the old Management Agent home:

$<AGENT_HOME>/bin/emctl stop agent

(b) Start the deployed Oracle Management Agent 12c from its instance home:

$<AGENT_INSTANCE_DIR>/bin/emctl start agent

- Even after switching over a Management Agent, if the status shows that it is down, then manually start it:
$<AGENT_INSTANCE_DIR>/bin/emctl start agent

- While switching over a deployed Management Agent to the new Enterprise Manager system, the switchover job might fail at the uploadAgent step. If the step fails with that error, then do the following:

1. On the Management Agent host, run the following command:
cat /dev/null > access_log

2. From the Management Agent instance home, run the following command and verify if the upload operation succeeds. Repeat this command until the upload operation succeeds.
$<AGENT_INSTANCE_HOME>/bin/emctl upload agent

3. Once the upload operation succeeds, access the Preupgrade Console from your Enterprise Manager Grid Control console, and in the Agent Upgrade Steps section, click Switch Agents.

4. On the Switch Agents page, select the Management Agent that had the error, and submit the switchover job again.

Monitoring Targets That Were Monitored by the Central Agent

If you are upgrading using the 2-system upgrade approach or the 1-system upgrade approach on a different host, then do NOT select the old central agent, that is, the Management Agent installed with the old OMS, for switchover.

If you want to continue monitoring the targets that were monitored by the central agent, then adopt one of the approaches:

- Approach 1

1. Install a Management Agent of the earlier release on the central agent host.

2. Relocate the targets running on the central agent host to the Management Agent installed in the previous step.
To do so, in Grid Control, click Setup. Click the Management Services and Repository tab. In the Alerts section, in the table, click Number of Duplicate Targets. Select the target you want to relocate, and click Change the monitoring Agent.

3. Upgrade the Management Repository and switch over all the standalone Management Agents, including the newly installed Management Agent. Do not upgrade the central agent.

4. Decommission the old OMS and the old central agent.

- Approach 2

1. Upgrade the Management Repository and switch over all the standalone Management Agents (except for the central agent).

2. Delete the targets running on the central agent host, from the upgraded Management Repository. You can delete them using the Enterprise Manager Cloud Control Console

3. Decommission the old OMS and the old central agent.

4. Install a fresh Oracle Management Agent 12c using the Add Host Targets Wizard from the new OMS, on the old central agent host.

5. Discover all the targets running on that host so that they can be monitored in the new OMS.

10 Upgrading OMS and Management Repository

This chapter describes the different ways of upgrading Oracle Management Service (OMS) and Oracle Management Repository (Management Repository) of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1). Select the one that best suits your requirement, and follow the instructions outlined in the respective section.

This chapter describes the following:

- Upgrading OMS and Management Repository in Graphical Mode

- Upgrading OMS and Management Repository in Silent Mode

- Installing Software Now and Upgrading Later in Graphical Mode

- Installing Software Now and Upgrading Later in Silent Mode

- Upgrading OMS and Management Repository for 1-System on Different Host Approach

- Upgrading Multi-OMS Environment

Upgrading OMS and Management Repository in Graphical Mode

This section describes how you can upgrade your existing OMS and Management Repository of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) in graphical mode using one of the upgrade approaches.

In particular, this section describes the following:

- Upgrading with 1-System Upgrade Approach in Graphical Mode

- Upgrading with 2-System Upgrade Approach in Graphical Mode

Note:
You can find the OMS and Management Agent entries in the /etc/oragchomelist file for all UNIX platforms except HPUNIX, HPia64, Solaris Sparc. On HPUNIX, HPia64, Solaris Sparc platforms, the entries are present in /var/opt/oracle/oragchomelist.

Note:
If you see an error message stating that you have not copied the emkey, run the following command.
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <repository_host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

(Here, the Management Repository details are details of the existing or old Management Repository. And when you run this command, you might be prompted for the admin server password.)

Upgrading with 1-System Upgrade Approach in Graphical Mode

Note:
When you upgrade using the 1-System upgrade approach, the Enterprise Manager Cloud Control Installation Wizard neither installs a new Management Agent with the OMS it installs, nor upgrades the existing Management Agent. The Management Agent is predeployed using the Preupgrade Console. This is an expected behavior.

To upgrade your existing OMS and Management Repository with 1-System upgrade approach in graphical mode, follow these steps:

1. Invoke the Enterprise Manager Cloud Control Installation Wizard on the host where your existing OMS is running.
<Software_Location>/runInstaller

In this command, <Software_Location> refers to the location where you have extracted the software kit.

Note:

- For information about the additional, advanced options you can pass while invoking the installer, refer to Advanced Installer Options for Graphical Mode.

- To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

- When you invoke runInstaller or setup.exe, if the Enterprise Manager Cloud Control Installation Wizard does not appear, then it is possible that you do not have access to the /stage directory.
There is a classpath variable that the installation wizard computes for OPatch as ../stage/Components/, and when the TEMP variable is set to /tmp, the installation wizard tries to look for the opatch JAR file in the /tmp/../stage directory, which is equivalent to /stage. However, if you do not have the permission on /stage, then the installation wizard can hang. Under such circumstances, verify if you have access to the /stage directory. If you do not have access to it, then set the TEMP variable to a location where the install user has access, and then relaunch the installation wizard.

2. (Optional) On the My Oracle Support Details screen, enter your My Oracle Support credentials to enable Oracle Configuration Manager. If you do not want to enable Oracle Configuration Manager now, go to Step (3).
If the host from where you are running the installation wizard does not have a connection to the Internet, then enter only the e-mail address and leave the other fields blank. After you complete the installation, manually collect the configuration information and upload it to My Oracle Support.

3. Click Next.

4. On the Software Updates screen, select one of the following sources from where the software updates can be installed while the Enterprise Manager system gets upgraded. If you do not want to apply them now, then select Skip.

- (Recommended) Select Search for Updates, and then, select Local Directory if you have already manually downloaded the software updates to an accessible local or remote location.
Enter the location where the updates are available, and click Search for Updates. To search the computer and select the location, click Browse. Once the search results appear with patch numbers and their details, click the patch number to view the ReadMe associated with that patch.

- If the updates have been downloaded to the default location, then select or enter the full path to the scratch path location. For example, if the scratch path location is /scratch/OracleHomes and if the software updates are available in /scratch/OracleHomes/Updates, then enter /scratch/OracleHomes/Updates.

- If the software updates have been downloaded to a custom location, then select or enter the full path to the custom location. For example, if the custom location is /home/john and if the software updates are available in /home/john/Updates, then enter /home/john/Updates.

- Select Search for Updates, and then, select My Oracle Support if you want the installer to connect to My Oracle Support and automatically download the updates from there.
Enter the My Oracle Support account user name and password, and click Search for Updates. Once the search results appear with patch numbers and their details, click the patch number to view the ReadMe associated with that patch

Note:
If you choose to skip installing the software updates during installation by not providing the My Oracle Support credentials, you can always register the credentials later using the Enterprise Manager Cloud Control console and view the recommended security patches. To do so, log in to Enterprise Manager Cloud Control, and from the Setup menu, select My Oracle Support, and then, click Set Credentials. On the My Oracle Support Preferred Credentials page, enter the credentials and click Apply.

5. Click Next.

6. On the Prerequisite Checks screen, check the status of the prerequisite checks run by the installation wizard, and verify whether your environment meets all the minimum requirements for a successful upgrade.
The installation wizard runs the prerequisite checks automatically when you come to this screen. It checks for the required operating system patches, operating system packages, and so on.

The status of the prerequisite check can be either Warning, Failed, or Succeeded.

If some checks result in Warning or Failed status, then investigate and correct the problems before you proceed with the upgrade. The screen provides details on why the prerequisites failed and how you can resolve them. After you correct the problems, return to this screen and click Rerun to check the prerequisites again.

If you prefer to hide the successful checks and view only the ones with Warning or Failed status, then click Hide Successful Checks.

7. Click Next.

8. On the Install Types screen, select Upgrade an Existing Enterprise Manager System, then select One System Upgrade. Then select the OMS home you want to upgrade.

9. Click Next.

10. On the Installation Details screen, do the following:

1. Enter or validate or enter the Middleware home.

Note:

- If you do not have Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24+ installed, then enter the absolute path to a directory where you want the installer to install them. For example, /oracle/software/. Ensure that the directory you enter does not contain any files or subdirectories.

- If you have Oracle WebLogic Server and JDK already installed, then ensure that they are of the supported releases—Oracle WebLogic Server 11g Release 1 (10.3.5) and JDK 1.6 v24+. In this case, the installer detects them and displays the Middleware home where they are installed. Validate the path to this Middleware home. The installer detects and displays only those Middleware homes where Enterprise Manager is not already configured.

- If you want to install Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24 yourself, then follow the guidelines outlined in Chapter 2.

2. Validate the host name. By default, the host name is the name of the host where the existing, earlier release of Enterprise Manager was installed. This is a non-editable field.

11. Click Next.

12. On the Database Connection Details screen, enter the passwords for the SYS and SYSMAN user accounts of the database that houses the Management Repository for the selected OMS.

Note:
Before you proceed to the next screen, stop all the associated OMS instances. To do so, run the following command on each of the OMS hosts:

- If you are upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then run this command on the first OMS you are upgrading. This command stops only the OMS, and not the Admin Server or any of its associated components. The Admin Server and other associated components must be running so that the credentials collected in Step (16) can be validated.
$<OMS_HOME>/bin/emctl stop oms

Then, on all other additional OMS instances, run the following command. This command stops the OMS and other components such as the node manager, which must be down for the upgrade to end successfully.

$<OMS_HOME>/bin/emctl stop oms -all

- If you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then run this command from the OMS home:
$<OMS_HOME>/opmn/bin/opmnctl stopall

13. Click Next.

Note:
If you encounter a Provisioning Archive Framework (PAF) prerequisite check error, then exit the installer, stop all the running and scheduled deployment procedures in your existing Enterprise Manager system, invoke the installer all over again, and retry the upgrade process.

14. On the Plug-In Deployment screen, select the optional plug-ins you want to deploy in addition to the plug-ins that will automatically be installed while upgrading the OMS.

Note:
The pre-selected rows might also include the plug-ins you installed while predeploying Oracle Management Agent 12c using the Preupgrade Console.
However, if the pre-selected rows do not include the plug-ins you installed then, it means that those plug-ins are not available in the software kit (DVD, downloaded software).

If you want to install the plug-ins that are not listed on this screen, then follow these steps:

1. Manually download the plug-ins from the Enterprise Manager download page on OTN, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the installer with the following option, and pass the location where the plug-ins you downloaded are available:
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

You might have a plug-in version deployed to the earlier release of Enterprise Manager that is not supported in Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), for example, EBS 2.0 and 3.0 plug-in versions. In this case, when you invoke the installer with -pluginLocation argument, make sure you do NOT provide the software of the higher version of the unsupported plug-in even if the higher version is available for download. This ensures that the unsupported version is removed while upgrading to 12c Release 2 (12.1.0.2). After you upgrade, you can deploy the higher version directly from the Plug-In Manager.

15. Click Next.

16. Provide WebLogic Server Configuration Details

- If you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then on the WebLogic Server Configuration Details screen, enter the credentials for the WebLogic Server user account and the Node Manager user account, and validate the path to the OMS instance base location.

Note:
Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

By default, the WebLogic Domain name is GCDomain, and the Node Manager name is nodemanager. These are non-editable fields. The installer uses this information for creating Oracle WebLogic Domain and other associated components such as the admin server, the managed server, and the node manager. A Node Manager enables you to start, shut down, or restart an Oracle WebLogic Server instance remotely, and is recommended for applications with high availability requirements.

- If you are upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then validate the AdminServer host name and its port, and the WebLogic user name, and enter the WebLogic user account password. This is required to create a new WebLogic domain (GCDomain) on the same port and host name as the AdminServer used by the earlier release of the OMS you are upgrading.

- If you are upgrading an additional OMS from 10g Release 5 (10.2.0.5) or from 11g Release 1 (11.1.0.1), then enter the host name and port of the AdminServer configured for the first OMS that you have already upgraded, and then, enter the credentials for the existing WebLogic Server user account.

17. Click Next.

18. On the Tablespace Location screen, validate the location where the data file (mgmt_ad4j.dbf ) for JVM Diagnostics data tablespace can be stored. You can choose to edit it if you want. In that case, ensure that the path leads up to the file name. Enterprise Manager Cloud Control requires this data file to store monitoring data related to JVM Diagnostics and Application Dependency Performance (ADP).

Note:
This screen appears only if you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5).

19. Click Next.

20. Provide the port configuration details:

- If you are upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then you will NOT see the Port Configuration Details screen because the ports used by the old OMS will be reused by the upgraded OMS. Hence, go to Step (22).

- If you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then on the Port Configuration Details screen, customize the ports to be used for various components.

Note:

- By default, this screen lists the default ports for all the core components. However, if you are upgrading an additional OMS, then the screen does not list the Admin Server HTTP SSL port because you will reuse the Admin Server configured for the first OMS.

- If all the ports on this screen appear as -1, then it indicates that the installer is unable to bind the ports on the host. To resolve this issue, exit the installer, verify the host name and the IP configuration of this host (ensure that the IP address of the host is not being used by another host), restart the installer, and try again.

You can enter a free custom port that is either within or outside the port range recommended by Oracle.

To verify if a port is free, run the following command:

On Unix:

netstat -anp | grep <port no>

On Microsoft Windows:

netstat -an|findstr <port_no>

However, the custom port must be greater than 1024 and lesser than 65535. Alternatively, if you already have the ports predefined in a staticports.ini file and if you want to use those ports, then click Import staticports.ini File and select the file.

Note:
If the staticports.ini file is passed during installation, then by default, the ports defined in the staticports.ini file are displayed. Otherwise, the first available port from the recommended range is displayed.
The staticports.ini file is available in the following location:

<Software_Extracted_Location>/response

21. Click Next.

22. On the Review screen, review the details you have provided for the upgrade.

1. If you want to change the details, click Back repeatedly until you reach the screen where you want to make the changes.

2. After you verify the details, if you are satisfied, click Install to begin the upgrade.

23. On the Install Progress screen, view the overall progress (in percentage) of the upgrade operation and the status of each of the Configuration Assistants.

Note:
If the OMS Configuration Assistant fails with an exception, particularly when you are upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then stop the AdminServer and try again. To stop the AdminServer, run the following command on each of the OMS hosts:
$<OMS_HOME>/bin/emctl stop oms -all

Note:
If a Configuration Assistant fails, the installer stops and none of the subsequent Configuration Assistants are run until the issue related to the failed Configuration Assistant is resolved. In this case, diagnose the issue, resolve it, and then, click Retry on the Install Progress screen to rerun the Configuration Assistants starting from the Configuration Assistant that failed.
However, if you accidently exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script from the OMS home to rerun the Configuration Assistant in silent mode:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, raise a service request and contact Oracle Support.

24. Once the software binaries are copied and configured, you are prompted to run the allroot.sh script. Open another window, log in as root, and manually run the scripts.
If you are installing on Microsoft Windows operating system, then you will NOT be prompted to run this script.

25. On the Finish screen, you should see information pertaining to the upgrade of Enterprise Manager. Review the information and click Close to exit the wizard.

26. If you upgraded an additional OMS (11.1.0.1), then note that the OMS name changes and the configuration changes are made to the Oracle WebLogic domain that hosts Enterprise Manager. However, these configuration changes are not reflected in the Enterprise Manager Cloud Control Console until you refresh the WebLogic domain configuration within the console.

Note:
This issue does not occur when you upgrade from 10g Release 5 (10.2.0.5).

To refresh the WebLogic domain, follow these steps:

1. Navigate to the home page of the Oracle WebLogic domain that hosts Enterprise Manager.

2. From the WebLogic Domain menu, select Refresh WebLogic Domain. The Refresh WebLogic Domain page appears.

3. Follow the instructions on the Refresh WebLogic Domain page to refresh the WebLogic domain.

WARNING:

If you do not refresh the WebLogic domain, you will see the old OMS target on the WebLogic domain home page. Make sure you follow this step to clear the old OMS target from the Enterprise Manager Cloud Control Console.

Upgrading with 2-System Upgrade Approach in Graphical Mode

To upgrade your existing OMS and Management Repository with 2-System upgrade approach in graphical mode, follow these steps:

1. Invoke the Enterprise Manager Cloud Control Installation Wizard on the host where you plan to install Oracle Management Service 12c:
<Software_Location>/runInstaller [ALLOW_ONLY_SECURE_ACCESS_TO_CONSOLE=FALSE LOCK_ORACLE_MANAGEMENT_SERVICE=FALSE]

In this command, <Software_Location> refers to the location where you have downloaded the software kit.

Note:

- For information about the additional, advanced options you can pass while invoking the installer, refer to Advanced Installer Options for Graphical Mode.

- To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

- Ensure that the host on which you are invoking the installer matches with the host you entered in the Preupgrade Console.
If you are invoking the installer on a different host, and if you choose to modify the host name in the Preupgrade Console, then follow these steps:

1. Exit the installer.

2. Discard the backed up database.

3. Access the Preupgrade Console:
(a) On the Identify Host and Port for New Enterprise Manager System page, change the host name. For instructions, see Identifying Host for Enterprise Manager Cloud Control.

(b) On the Deploy and Configure Agents page, reconfigure the Management Agents that have already been deployed. For instructions, see Deploying and Configuring Oracle Management Agent.

Important: On the Deploy and Configure Agents page, in the Select Operation Type section, ensure that you deselect Deploy Agent and Plug-In Software.

4. Take a fresh backup of the database now.

5. Invoke the installer all over again, and retry the upgrade process.

Note:
When you invoke runInstaller or setup.exe, if the Enterprise Manager Cloud Control Installation Wizard does not appear, then it is possible that you do not have access to the /stage directory.
There is a classpath variable that the installation wizard computes for OPatch as ../stage/Components/, and when the TEMP variable is set to /tmp, the installation wizard tries to look for the opatch JAR file in the /tmp/../stage directory, which is equivalent to /stage. However, if you do not have the permission on /stage, then the installation wizard can hang. Under such circumstances, verify if you have access to the /stage directory. If you do not have access to it, then set the TEMP variable to a location where the install user has access, and then relaunch the installation wizard.

2. (Optional) On the My Oracle Support Details screen, enter your My Oracle Support credentials to enable Oracle Configuration Manager. If you do not want to enable Oracle Configuration Manager now, go to Step (3).
If the host from where you are running the installation wizard does not have a connection to the Internet, then enter only the e-mail address and leave the other fields blank. After you complete the installation, manually collect the configuration information and upload it to My Oracle Support.

3. Click Next.

4. On the Software Updates screen, select one of the following sources from where the software updates can be installed while the installation of the Enterprise Manager system is in progress. If you do not want to apply them now, then select Skip.

- (Recommended) Select Search for Updates, and then, select Local Directory if you have already manually downloaded the software updates to an accessible local or remote location.
Enter the location where the updates are available, and click Search for Updates. To search the computer and select the location, click Browse. Once the search results appear with patch numbers and their details, click the patch number to view the ReadMe associated with that patch.

- If the updates have been downloaded to the default location, then select or enter the full path to the scratch path location. For example, if the scratch path location is /scratch/OracleHomes and if the software updates are available in /scratch/OracleHomes/Updates, then enter /scratch/OracleHomes/Updates.

- If the software updates have been downloaded to a custom location, then select or enter the full path to the custom location. For example, if the custom location is /home/john and if the software updates are available in /home/john/Updates, then enter /home/john/Updates.

- Select Search for Updates, and then, select My Oracle Support if you want the installer to connect to My Oracle Support and automatically download the updates from there.
Enter the My Oracle Support account user name and password, and click Search for Updates. Once the search results appear with patch numbers and their details, click the patch number to view the ReadMe associated with that patch

Note:
If you choose to skip installing the software updates during installation by not providing the My Oracle Support credentials, you can always register the credentials later using the Enterprise Manager Cloud Control console and view the recommended security patches. To do so, log in to Enterprise Manager Cloud Control, and click Preferences from the top-right corner of the screen. On the General page, from the left menu bar, click Preferred Credentials. On the Preferred Credentials page, from the My Oracle Support Preferred Credentials section, click Set Credentials. On the My Oracle Support Preferred Credentials page, specify the credentials and click Apply.

5. Click Next.
If Enterprise Manager Cloud Control is the first Oracle product you are installing on the host that is running on UNIX operating system, then the Oracle Inventory screen appears. For details, see step (6). Otherwise, the Check Prerequisites screen appears. For details, see step (8).

If Enterprise Manager Cloud Control is the first Oracle product you are installing on the host that is running on Microsoft Windows operating system, then the Oracle Inventory screen does not appear. On Microsoft Windows, the following is the default inventory directory:

<system drive>\Program Files\Oracle\Inventory

6. On the Oracle Inventory screen, do the following. You will see this screen only if this turns out to be your first ever installation of an Oracle product on the host.

1. Enter the full path to a directory where the inventory files and directories can be placed.

Note:

- The central inventory location you enter must NOT be on a shared file system. If it is already on a shared file system, then switch over to a non-shared file system.

- If this is the first Oracle product on the host, then the default central inventory location is <home directory>/oraInventory. However, if you already have some Oracle products on the host, then the central inventory location can be found in the oraInst.loc file. The oraInst.loc file is located in the /etc directory for Linux and AIX, and in the /var/opt/oracle directory for Solaris, HP-UX, and Tru64.

2. Select the appropriate operating system group name that will own the Oracle inventory directories. The group that you select must have write permissions on the Oracle Inventory directories.

7. Click Next.

8. On the Prerequisite Checks screen, check the status of the prerequisite checks run by the installation wizard, and verify whether your environment meets all the minimum requirements for a successful upgrade.
The installation wizard runs the prerequisite checks automatically when you come to this screen. It checks for the required operating system patches, operating system packages, and so on.

The status of the prerequisite check can be either Warning, Failed, or Succeeded.

If some checks result in Warning or Failed status, then investigate and correct the problems before you proceed with the upgrade. The screen provides details on why the prerequisites failed and how you can resolve them. After you correct the problems, return to this screen and click Rerun to check the prerequisites again.

If you prefer to hide the successful checks and view only the ones with Warning or Failed status, then click Hide Successful Checks.

9. Click Next.

10. On the Installation Types screen, select Upgrade an Existing Enterprise Manager System, then select Two System Upgrade.

11. Click Next.

12. On the Installation Details screen, do the following:

1. Enter or validate or enter the Middleware home where you want to install the OMS and other core components.

Note:

- If you have Oracle WebLogic Server and Java Development Kit already installed, then ensure that they are of the supported releases—Oracle WebLogic Server 11g Release 1 (10.3.5) and JDK 1.6 v24+. If you have the supported releases, the installer automatically detects them and displays the absolute path to the Middleware home where they are installed. In this case, validate the Middleware home. If the location is incorrect, then enter the path to the correct location. Ensure that the Middleware home you select or enter is a Middleware home that does not have any Oracle homes for Oracle Management Service and Oracle Management Agent.

- If you do not have Oracle WebLogic Server 11g Release 1 (10.3.5) and JDK 1.6 v24+, then the installer automatically installs them for you while installing the Enterprise Manager system. In this case, enter the absolute path to a directory where you want to have them installed. For example, /oracle/software/. Ensure that the directory you enter does not contain any files or subdirectories.

- If you want to install Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24 yourself, then follow the guidelines outlined in Chapter 2.

2. Enter the absolute path to the agent base directory, a location outside the Oracle Middleware home where the Management Agent can be installed. For example, /oracle/agent. Ensure that this location is empty and has write permission. Also ensure that it is always maintained outside the Oracle Middleware home.

3. Validate the name of the host where you want to configure the OMS.
The host name appears as a fully qualified name. The host name can also appear as a virtual host name if your host is configured with virtual machine.

You can choose to accept the default host name and proceed with the installation. Alternatively, you can change the name if it is incorrect, or enter another host name of the same host. Ensure that the host name you enter is accessible from other hosts in the network (other hosts must be able to ping this host).

13. On the Database Connection Details screen, enter the fully qualified name of the host where the backed up database resides, its listener port and its service name or system ID (SID), and the SYS and SYSMAN user account passwords.

Note:
Oracle Real Application Cluster (Oracle RAC) nodes are referred to by their virtual IP (vip) names. The service_name parameter is used instead of the system identifier (SID) in connect_data mode, and failover is turned on. For more information, refer to Oracle Database Net Services Administrator's Guide.

The installer uses this information to connect to the backed up database for upgrading the SYSMAN schema. SYSMAN schema holds most of the relational data used in managing Enterprise Manager Cloud Control.

14. Click Next.

Note:

- If you are connecting to an Oracle RAC database, and if you have entered the virtual IP address of one of its nodes, then the installation wizard prompts you with a Connection String dialog and requests you to update the connection string with information about the other nodes that are part of the cluster. Update the connection string and click OK. If you want to test the connection, click Test Connection.

- Oracle Real Application Cluster (Oracle RAC) nodes are referred to by their virtual IP (vip) names. The service_name parameter is used instead of the system identifier (SID) in connect_data mode, and failover is turned on. For more information, refer to Oracle Database Net Services Administrator's Guide.

- If you encounter a Provisioning Archive Framework (PAF) prerequisite check error, then do the following:

- Exit the installer, run the following SQL command on the backed up database, invoke the installer all over again, and retry the upgrade process.

UPDATE MGMT_PAF_STATES
SET status = 6
WHERE state_type = 0
AND status IN (0, 1);

- Exit the installer, discard the backed up database, stop all the running and scheduled deployment procedures in your existing Enterprise Manager system, take a fresh backup of the database now, invoke the installer all over again, and retry the upgrade process.

- If you encounter any validation error, then follow these steps:

1. Exit the installer.

2. Discard the backed up database.

3. Resolve the issue in the Preupgrade Console.

4. Take a fresh backup of the database now.

5. Invoke the installer all over again, and retry the upgrade process.

- If you see a warning asking you to unlock the MGMT_VIEW user account and change the password, ignore it because the installer automatically unlocks it for you.

15. On the Plug-In Deployment screen, select the optional plug-ins you want to install from the software kit (DVD, downloaded software) while installing the Enterprise Manager system.
The pre-selected rows are mandatory plug-ins that will be installed by default. Select the optional ones you want to install or upgrade.

Note:
The pre-selected rows might also include the plug-ins you installed while predeploying Oracle Management Agent 12c using the Preupgrade Console.
However, if the preselected rows do not include the plug-ins you installed then, it means that those plug-ins are not available in the software kit (DVD, downloaded software).

If you want to install the plug-ins that are not listed on this screen, then follow these steps:

1. Manually download the plug-ins from the Enterprise Manager download page on OTN, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the installer with the following option, and pass the location where the plug-ins you downloaded are available:
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

You might have a plug-in version deployed to the earlier release of Enterprise Manager that is not supported in Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), for example, EBS 2.0 and 3.0 plug-in versions. In this case, when you invoke the installer with -pluginLocation argument, make sure you do NOT provide the software of the higher version of the unsupported plug-in even if the higher version is available for download. This ensures that the unsupported version is removed while upgrading to 12c Release 2 (12.1.0.2). After you upgrade, you can deploy the higher version directly from the Plug-In Manager.

16. Click Next.

17. On the WebLogic Server Configuration Details screen, enter the credentials for the WebLogic Server user account and the Node Manager user account, and validate the path to the Oracle Management Service instance base location.

Note:
Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

By default, the WebLogic Domain name is GCDomain, and the Node Manager name is nodemanager. These are non-editable fields. The installer uses this information for creating Oracle WebLogic Domain and other associated components such as the admin server, the managed server, and the node manager. A Node Manager enables you to start, shut down, or restart an Oracle WebLogic Server instance remotely, and is recommended for applications with high availability requirements.

18. Click Next.

WARNING:

Verify the value set to the GLOBAL_NAMES parameter on both the databases:

- If the GLOBAL_NAMES parameter is set to FALSE on both the databases, then ensure that you do not change this value until the upgrade is complete, and all the Management Agents are switched over.

- If the GLOBAL_NAMES parameter is set to TRUE on even one of the databases, and if both the databases have the same value for the GLOBAL_NAME parameter, then change the value of the GLOBAL_NAME parameter set on the new, cloned database to a value that is different from the one set on the old database.

19. On the Old Repository Details screen, validate the connect string and enter the SYSMAN password of the old Management Repository.
The details are used to connect to the old Management Repository, check for accrued data, and seamlessly transfer it to the upgraded Management Repository. Accrued data refers to the data that was uploaded to the old Management Repository from the time it was backed up till the time it was upgraded.

Note:
Typically, the connect string is prepopulated. However, if it is not prepopulated, then enter it in the following format:

- With SID
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SID=<sid>)))

- With Service Name
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SERVICE_NAME=<service_name>)))

20. Click Next.

21. On the Tablespace Location screen, validate the location where the data file (mgmt_ad4j.dbf ) for JVM Diagnostics data tablespace can be stored. You can choose to edit it if you want. In that case, ensure that the path leads up to the file name. Enterprise Manager Cloud Control requires this data file to store monitoring data related to JVM Diagnostics and Application Dependency Performance (ADP).

Note:
This screen appears only if you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5).

22. Click Next.

23. On the Port Configuration Details screen, customize the ports to be used for various components.

- Ensure that the ports you enter for Enterprise Manager Upload Http Port and Enterprise Manager Upload Http SSL Port match with the unsecure and secure ports you entered in the Preupgrade Console.

Note:
If the ports mentioned in this screen are different from the ports you had entered in the Preupgrade Console, and if you decide to change the ports in the Preupgrade Console, then follow these steps:

1. Exit the installer.

2. Discard the backed up database.

3. Change the ports in the Preupgrade Console.

4. Take a fresh backup of the database now.

5. Invoke the installer all over again, and retry the upgrade process.

- For other components, you can enter a free custom port that is either within or outside the port range recommended by Oracle. However, the custom port must be greater than 1024 and lesser than 65535.
To verify if a port is free, run the following command:

On Unix:

netstat -anp | grep <port no>

On Microsoft Windows:

netstat -an|findstr <port_no>

- Alternatively, if you already have the ports predefined in a staticports.ini file and if you want to use those ports, then click Import staticports.ini File and select the file.

Note:
If the staticports.ini file is passed during installation, then by default, the ports defined in the staticports.ini file are displayed. Otherwise, the first available port from the recommended range is displayed. If you do pass this file, then ensure that the ports you enter for Enterprise Manager Upload Http Port and Enterprise Manager Upload Http SSL Port match with the unsecure and secure ports you entered in the Preupgrade Console.

Note:
If all the ports on this screen appear as -1, then it indicates that the installer is unable to bind the ports on the host. To resolve this issue, exit the installer, verify the host name and the IP configuration of this host (ensure that the IP address of the host is not being used by another host), restart the installer, and try again.

24. Click Next.

25. On the Review screen, review the details you provided for the selected installation type.

- If you want to change the details, click Back repeatedly until you reach the screen where you want to make the changes.

- After you verify the details, if you are satisfied, click Install to begin the installation process.

26. On the Install Progress screen, view the overall progress (in percentage) of the installation and the status of each of the Configuration Assistants. Configuration Assistants are run for configuring the installed components of Enterprise Manager Cloud Control.

Note:
If a Configuration Assistant fails, the installer stops and none of the subsequent Configuration Assistants are run until the issue related to the failed Configuration Assistant is resolved. In this case, diagnose the issue, resolve it, and then, click Retry on the Install Progress screen to rerun the Configuration Assistants starting from the Configuration Assistant that failed.
However, if you accidently exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script from the OMS home to rerun the Configuration Assistant in silent mode:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

27. Once the software binaries are copied and configured, you are prompted to run the allroot.sh script, and the oraInstRoot.sh script if this is the first Oracle product installation on the host. Open another window, log in as root, and manually run the scripts.
If you are installing on Microsoft Windows operating system, then you will NOT be prompted to run this script.

28. On the Finish screen, you should see information pertaining to the installation of Enterprise Manager. Review the information and click Close to exit the installation wizard.
For more information about this installation, refer to the following file available in the OMS home:

$<OMS_HOME>/install/setupinfo.txt

Upgrading OMS and Management Repository in Silent Mode

This section describes how you can upgrade your existing OMS and Management Repository of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) in silent mode using one of the upgrade approaches.

In particular, this section describes the following:

- Upgrading with 1-System Upgrade Approach in Silent Mode

- Upgrading with 2-System Upgrade Approach in Silent Mode

Note:
You can find the OMS and Management Agent entries in the /etc/oragchomelist file for all UNIX platforms except HPUNIX, HPia64, Solaris Sparc. On HPUNIX, HPia64, Solaris Sparc platforms, the entries are present in /var/opt/oracle/oragchomelist.

Note:
If you see an error message stating that you have not copied the emkey, run the following command.
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <repository_host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

(Here, the Management Repository details are details of the existing or old Management Repository. And when you run this command, you might be prompted for the admin server password.)

Upgrading with 1-System Upgrade Approach in Silent Mode

Note:
When you upgrade using the 1-System upgrade approach, the Enterprise Manager Cloud Control Installation Wizard neither installs a new Management Agent with the OMS it installs, nor upgrades the existing Management Agent. The Management Agent is predeployed using the Preupgrade Console. This is an expected behavior.

To upgrade your existing OMS and Management Repository with 1-System upgrade approach in silent mode, refer to Upgrading OMS and Management Repository in Silent Mode.

Upgrading with 2-System Upgrade Approach in Silent Mode

To upgrade your existing OMS and Management Repository using 2-System upgrade approach in silent mode, follow these steps:

1. Copy the following response file to an accessible location on your local host:
<Software_Location>/response/upgrade.rsp

In this command, <Software_Location> refers to the location where you have downloaded the software kit.

2. Edit the response file and enter appropriate values for the variables described in Appendix A.

3. Invoke the installer:

- If this is the first Oracle product you are installing on the host, then run the following command on the host where you plan to install Oracle Management Service 12c:
./runInstaller -silent -responseFile <absolute_path>/upgrade.rsp [-invPtrLoc <absolute_path_to_inventory_directory>] -staticPortsIniFile <absolute_path_to_staticports.ini_file> [ALLOW_ONLY_SECURE_ACCESS_TO_CONSOLE=FALSE LOCK_ORACLE_MANAGEMENT_SERVICE=FALSE]

Note:
The central inventory location you enter must NOT be on a shared file system.

- Otherwise, run the following command:
./runInstaller -silent -responseFile <absolute_path>/upgrade.rsp -staticPortsIniFile <absolute_path_to_file>

Note:
For information about the additional, advanced options you can pass while invoking the installer, refer to Advanced Installer Options for Silent Mode.
To invoke the installation wizard on UNIX platforms, run runInstaller. To invoke on Microsoft Windows platforms, run setup.exe.

Note:

- Ensure that the host on which you are invoking the installer matches with the host you entered in the Preupgrade Console.
If you are invoking the installer on a different host, and if you choose to modify the host name in the Preupgrade Console, then follow these steps:

1. Exit the installer.

2. Discard the backed up database.

3. Access the Preupgrade Console, and change the host name in the Identify Host and Port for New Enterprise Manager System page.

4. Take a fresh backup of the database now.

5. Invoke the installer all over again, and retry the upgrade process.

In this case, you must ensure that all the Management Agents, which were already deployed and configured through the Preupgrade Console before upgrading the OMS, are reconfigured with the new host name.

- In the staticports.ini file, ensure that the ports you enter for Enterprise Manager Upload Http Port and Enterprise Manager Upload Http SSL Port match with the unsecure and secure ports you entered in the Preupgrade Console.
If you decide to change the ports in the Preupgrade Console instead, then follow these steps:

1. Exit the installer.

2. Discard the backed up database.

3. Change the ports in the Preupgrade Console.

4. Take a fresh backup of the database now.

5. Invoke the installer all over again, and retry the upgrade process.

Installing Software Now and Upgrading Later in Graphical Mode

This section explains how you can install only the software binaries of Enterprise Manager 12c Cloud Control in graphical mode at one point, and upgrade them at a later point.

In particular, this section describes the following:

- Upgrading in Software-Only Mode with 1-System Upgrade Approach in Graphical Mode

- Upgrading in Software-Only Mode with 2-System Upgrade Approach in Graphical Mode

Note:
You can find the OMS and Management Agent entries in the /etc/oragchomelist file for all UNIX platforms except HPUNIX, HPia64, Solaris Sparc. On HPUNIX, HPia64, Solaris Sparc platforms, the entries are present in /var/opt/oracle/oragchomelist.

Note:
If you see an error message stating that you have not copied the emkey, run the following command.
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <repository_host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

(Here, the Management Repository details are details of the existing or old Management Repository. And when you run this command, you might be prompted for the admin server password.)

Upgrading in Software-Only Mode with 1-System Upgrade Approach in Graphical Mode

This section describes how you can upgrade your OMS and Management Repository in software-only mode with 1-System upgrade approach. In particular, this section covers the following:

- Installing Software Binaries

- Running allroot.sh Script

- Configuring and Upgrading

Installing Software Binaries

To install the software binaries of Enterprise Manager Cloud Control, refer to Installing Software Binaries.

Running allroot.sh Script

To run the allroot.sh script, refer to Running allroot.sh Script.

Configuring and Upgrading

To configure the software binaries of Enterprise Manager Cloud Control, follow these steps:

1. Invoke the installation wizard by running the following script:
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- While installing the software binaries as described in Installing Software Binaries, if you had passed the argument -invPtrLoc, then pass the same argument here as well.

- For information about the additional, advanced options you can pass while invoking the script, refer to Advanced Script Options for Software-Only Mode.

2. On the Install Types screen, do the following:

1. Select Upgrade an Existing Enterprise Manager System, and then, select One System Upgrade.

2. Select the OMS home you want to upgrade.

3. Click Next.

4. On the Database Connection Details screen, enter the passwords for the SYS and SYSMAN user accounts of the database that houses the Management Repository for the selected OMS.

Note:
Before you proceed to the next screen, stop all the associated OMS instances. To do so, run the following command on each of the OMS hosts:

- If you are upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then run this command on the first OMS you are upgrading. This command stops only the OMS, and not the Admin Server or any of its associated components. The Admin Server and other associated components must be running so that the credentials collected in Step (8) can be validated.
$<OMS_HOME>/bin/emctl stop oms

Then, on all other additional OMS instances, run the following command. This command stops the OMS and other components such as the node manager, which must be down for the upgrade to end successfully.

$<OMS_HOME>/bin/emctl stop oms -all

- If you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then run this command from the OMS home:
$<OMS_HOME>/opmn/bin/opmnctl stopall

5. Click Next.

Note:
If you see an error about missing plug-ins, then do the following:

1. Make a note of the plug-in version and plug-in update as shown in the missing plug-ins error message. The plug-ins displayed in the error message have the following format:
PluginID:PluginVersion:PluginUpdate

2. Manually download the same plug-in version and the same or higher plug-in update as shown in the missing plug-ins error message, from the following URL.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

Store the plug-ins in an accessible location, and ensure that the location is meant only for these missing plug-ins.

3. Invoke the ConfigureGC.sh script in the following way to install the downloaded plug-ins:
<OMS_HOME>/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_sw>

Proceed to the next step only after you have installed these missing plug-ins.

You might have a plug-in version deployed to the earlier release of Enterprise Manager that is not supported in Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), for example, EBS 2.0 and 3.0 plug-in versions. In this case, when you invoke the installer with -pluginLocation argument, make sure you do NOT provide the software of the higher version of the unsupported plug-in even if the higher version is available for download. This ensures that the unsupported version is removed while upgrading to 12c Release 2 (12.1.0.2). After you upgrade, you can deploy the higher version directly from the Plug-In Manager.

6. On the Plug-In Deployment screen, select the optional plug-ins you want to deploy in addition to the plug-ins that will automatically be upgraded while upgrading the OMS.

Note:
If you want to install any additional plug-ins that are not listed on this screen, then follow these steps:

1. Manually download the plug-ins from the Enterprise Manager download page on OTN, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the installer with the following option, and pass the location where the plug-ins you downloaded are available:
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_software_location>

7. Click Next.

8. Provide WebLogic Server configuration details:

- If you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then on the WebLogic Server Configuration Details screen, enter the credentials for the WebLogic Server user account and the Node Manager user account, and validate the path to the OMS instance base location.

Note:
Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

By default, the WebLogic Domain name is GCDomain, and the Node Manager name is nodemanager. These are non-editable fields. The installer uses this information for creating Oracle WebLogic Domain and other associated components such as the admin server, the managed server, and the node manager. A Node Manager enables you to start, shut down, or restart an Oracle WebLogic Server instance remotely, and is recommended for applications with high availability requirements.

- If you are upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then validate the AdminServer host name and its port, and the WebLogic user name, and enter the WebLogic user account password. This is required to create a new WebLogic domain (GCDomain) on the same port and host name as the AdminServer used by the earlier release of the OMS you are upgrading.

- If you are upgrading an additional OMS from 10g Release 5 (10.2.0.5) or from 11g Release 1 (11.1.0.1), then enter the host name and port of the AdminServer configured for the first OMS, and then, enter the credentials for the existing WebLogic Server user account.

9. Click Next.

10. On the Tablespace Location screen, validate the location where the data file (mgmt_ad4j.dbf ) for JVM Diagnostics data tablespace can be stored. You can choose to edit it if you want. In that case, ensure that the path leads up to the file name. Enterprise Manager Cloud Control requires this data file to store monitoring data related to JVM Diagnostics and Application Dependency Performance (ADP).

Note:
This screen appears only if you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5).

11. Click Next.

12. On the Port Configuration Details screen, customize the ports to be used for various components.

- If you are upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then you will NOT see the Port Configuration Details screen because the ports used by the old OMS will be reused by the upgraded OMS. Hence, go to Step (14).

- If you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then on the Port Configuration Details screen, customize the ports to be used for various components.

Note:
If all the ports on this screen appear as -1, then it indicates that the installer is unable to bind the ports on the host. To resolve this issue, exit the installer, verify the host name and the IP configuration of this host (ensure that the IP address of the host is not being used by another host), restart the installer, and try again.

You can enter a free custom port that is either within or outside the port range recommended by Oracle.

To verify if a port is free, run the following command:

On Unix:

netstat -anp | grep <port no>

On Microsoft Windows:

netstat -an|findstr <port_no>

However, the custom port must be greater than 1024 and lesser than 65535. Alternatively, if you already have the ports predefined in a staticports.ini file and if you want to use those ports, then click Import staticports.ini File and select the file.

Note:
If the staticports.ini file is passed during installation, then by default, the ports defined in the staticports.ini file are displayed. Otherwise, the first available port from the recommended range is displayed.
The staticports.ini file is available in the following location:

<Software_Extracted_Location>/response

13. Click Next.

14. On the Review screen, review the details you provided for the selected installation type.

- If you want to change the details, click Back repeatedly until you reach the screen where you want to make the changes.

- After you verify the details, if you are satisfied, click Configure to begin the installation process.

15. On the Install Progress screen, view the overall progress (in percentage) of the installation.

Note:
If a Configuration Assistant fails, the installer stops and none of the subsequent Configuration Assistants are run until the issue related to the failed Configuration Assistant is resolved. In this case, diagnose the issue, resolve it, and then, click Retry on the Install Progress screen to rerun the Configuration Assistants starting from the Configuration Assistant that failed.
However, if you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script from the OMS home to rerun the Configuration Assistant in silent mode:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, raise a service request and contact Oracle Support.

16. On the Finish screen, you should see information pertaining to the installation of Enterprise Manager. Review the information and click Close to exit the installation wizard.

17. If you upgraded an additional OMS (11.1.0.1), then note that the OMS name changes and the configuration changes are made to the Oracle WebLogic domain that hosts Enterprise Manager. However, these configuration changes are not reflected in the Enterprise Manager Cloud Control Console until you refresh the WebLogic domain configuration within the console.

Note:
This issue does not occur when you upgrade from 10g Release 5 (10.2.0.5).

To refresh the WebLogic domain, follow these steps:

1. Navigate to the home page of the Oracle WebLogic domain that hosts Enterprise Manager.

2. From the WebLogic Domain menu, select Refresh WebLogic Domain. The Refresh WebLogic Domain page appears.

3. Follow the instructions on the Refresh WebLogic Domain page to refresh the WebLogic domain.

WARNING:

If you do not refresh the WebLogic domain, you will see the old OMS target on the WebLogic domain home page. Make sure you follow this step to clear the old OMS target from the Enterprise Manager Cloud Control Console.

Upgrading in Software-Only Mode with 2-System Upgrade Approach in Graphical Mode

This section describes how you can upgrade your OMS and Management Repository in software-only mode with 2-System upgrade approach. In particular, this section covers the following:

- Installing Software Binaries

- Running allroot.sh Script

- Configuring and Upgrading

Installing Software Binaries

To install the software binaries, follow the steps outlined in Installing Software Binaries.

Running allroot.sh Script

To run the allroot.sh script, Running allroot.sh Script.

Configuring and Upgrading

To configure and upgrade your existing Enterprise Manager system, follow these steps:

1. Invoke the installation wizard by running the following script:
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- While installing the software binaries as described in Installing Software Binaries, if you had passed the argument -invPtrLoc, then pass the same argument here as well.

- For information about the additional, advanced options you can pass while invoking the script, refer to Advanced Script Options for Software-Only Mode.

2. On the Install Types screen, select Upgrade an Existing Enterprise Manager System, and then, select Two System Upgrade.

3. Click Next.

4. On the Database Connection Details screen, enter the fully qualified name of the host where the backed up database resides, its listener port and its service name or system ID (SID), and the SYS and SYSMAN user account passwords.

Note:
Oracle Real Application Cluster (Oracle RAC) nodes are referred to by their virtual IP (vip) names. The service_name parameter is used instead of the system identifier (SID) in connect_data mode, and failover is turned on. For more information, refer to Oracle Database Net Services Administrator's Guide.

The installer uses this information to connect to the backed up database for upgrading the SYSMAN schema. SYSMAN schema holds most of the relational data used in managing Enterprise Manager Cloud Control.

5. Click Next.

Note:

- If you are connecting to an Oracle RAC database, and if you have entered the virtual IP address of one of its nodes, then the installation wizard prompts you with a Connection String dialog and requests you to update the connection string with information about the other nodes that are part of the cluster. Update the connection string and click OK. If you want to test the connection, click Test Connection.

- Oracle Real Application Cluster (Oracle RAC) nodes are referred to by their virtual IP (vip) names. The service_name parameter is used instead of the system identifier (SID) in connect_data mode, and failover is turned on. For more information, refer to Oracle Database Net Services Administrator's Guide.

- If you encounter a Provisioning Archive Framework (PAF) prerequisite check error, then do the following:

- Exit the installer, run the following SQL command on the backed up database, invoke the installer all over again, and retry the upgrade process.

UPDATE MGMT_PAF_STATES
SET status = 6
WHERE state_type = 0
AND status IN (0, 1);

- Exit the installer, discard the backed up database, stop all the running and schedule deployment procedures in your existing Enterprise Manager system, take a fresh backup of the database now, invoke the installer all over again, and retry the upgrade process.

- If you see a warning asking you to unlock the MGMT_VIEW user account and change the password, ignore it because the installer automatically unlocks it for you.

Note:
If you see an error about missing plug-ins, then do the following:

1. Make a note of the plug-in version and plug-in update as shown in the missing plug-ins error message. The plug-ins displayed in the error message have the following format:
PluginID:PluginVersion:PluginUpdate

2. Manually download the same plug-in version and the same or higher plug-in update as shown in the missing plug-ins error message, from the following URL.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

Store the plug-ins in an accessible location, and ensure that the location is meant only for these missing plug-ins.

3. Invoke the ConfigureGC.sh script in the following way to install the downloaded plug-ins:
<OMS_HOME>/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_sw>

Proceed to the next step only after you have installed these missing plug-ins.

You might have a plug-in version deployed to the earlier release of Enterprise Manager that is not supported in Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), for example, EBS 2.0 and 3.0 plug-in versions. In this case, when you invoke the installer with -pluginLocation argument, make sure you do NOT provide the software of the higher version of the unsupported plug-in even if the higher version is available for download. This ensures that the unsupported version is removed while upgrading to 12c Release 2 (12.1.0.2). After you upgrade, you can deploy the higher version directly from the Plug-In Manager.

6. On the Plug-In Deployment screen, select the optional plug-ins you want to deploy in addition to the plug-ins that will automatically be upgraded while upgrading the OMS.

Note:
If you want to install any additional plug-ins that are not listed on this screen, then follow these steps:

1. Manually download the plug-ins from the Enterprise Manager download page on OTN, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the installer with the following option, and pass the location where the plug-ins you downloaded are available:
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

7. Click Next.

8. On the WebLogic Server Configuration Details screen, enter the credentials for the WebLogic Server user account and the Node Manager user account, and validate the path to the Oracle Management Service instance base location.

Note:
Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

By default, the WebLogic Domain name is GCDomain, and the Node Manager name is nodemanager. These are non-editable fields. The installer uses this information for creating Oracle WebLogic Domain and other associated components such as the admin server, the managed server, and the node manager. A Node Manager enables you to start, shut down, or restart an Oracle WebLogic Server instance remotely, and is recommended for applications with high availability requirements.

9. Click Next.

WARNING:

Verify the value set to the GLOBAL_NAMES parameter on both the databases:

- If the GLOBAL_NAMES parameter is set to FALSE on both the databases, then ensure that you do not change this value until the upgrade is complete, and all the Management Agents are switched over.

- If the GLOBAL_NAMES parameter is set to TRUE on even one of the databases, and if both the databases have the same value for the GLOBAL_NAME parameter, then change the value of the GLOBAL_NAME parameter set on the new, cloned database to a value that is different from the one set on the old database.

10. On the Old Repository Details screen, validate the connect string and enter the SYSMAN password of the old Management Repository.
The details are used to connect to the old Management Repository, check for accrued data, and seamlessly transfer it to the upgraded Management Repository. Accrued data refers to the data that was uploaded to the old Management Repository from the time it was backed up till the time it was upgraded.

Note:
Typically, the connect string is prepopulated. However, if it is not prepopulated, then enter it in the following format:

- With SID
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SID=<sid>)))

- With Service Name
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SERVICE_NAME=<service_name>)))

11. Click Next.

12. On the Tablespace Location screen, validate the location where the data file (mgmt_ad4j.dbf ) for JVM Diagnostics data tablespace can be stored. You can choose to edit it if you want. In that case, ensure that the path leads up to the file name. Enterprise Manager Cloud Control requires this data file to store monitoring data related to JVM Diagnostics and Application Dependency Performance (ADP).

Note:
This screen appears only if you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5).

13. Click Next.

14. On the Port Configuration Details screen, customize the ports to be used for various components.

- Ensure that the ports you enter for Enterprise Manager Upload Http Port and Enterprise Manager Upload Http SSL Port match with the unsecure and secure ports you entered in the Preupgrade Console.

- For other components, you can enter a free custom port that is either within or outside the port range recommended by Oracle. However, the custom port must be greater than 1024 and lesser than 65535.
To verify if a port is free, run the following command:

On Unix:

netstat -anp | grep <port no>

On Microsoft Windows:

netstat -an|findstr <port_no>

- Alternatively, if you already have the ports predefined in a staticports.ini file and if you want to use those ports, then click Import staticports.ini File and select the file.

Note:
If the staticports.ini file is passed during installation, then by default, the ports defined in the staticports.ini file are displayed. Otherwise, the first available port from the recommended range is displayed. If you do pass this file, then ensure that the ports you enter for Enterprise Manager Upload Http Port and Enterprise Manager Upload Http SSL Port match with the unsecure and secure ports you entered in the Preupgrade Console.

15. Click Next.

16. On the Review screen, review the details you provided for the selected installation type.

- If you want to change the details, click Back repeatedly until you reach the screen where you want to make the changes.

- After you verify the details, if you are satisfied, click Configure to begin the installation process.

17. On the Install Progress screen, view the overall progress (in percentage) of the installation.

Note:
If a Configuration Assistant fails, the installer stops and none of the subsequent Configuration Assistants are run until the issue related to the failed Configuration Assistant is resolved. In this case, diagnose the issue, resolve it, and then, click Retry on the Install Progress screen to rerun the Configuration Assistants starting from the Configuration Assistant that failed.
However, if you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script from the OMS home to rerun the Configuration Assistant in silent mode:

$<OMS_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_OMS_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}

If the runConfig.sh script fails, then clean up your environment and redo the installation.

18. On the Finish screen, you should see information pertaining to the installation of Enterprise Manager. Review the information and click Close to exit the installation wizard.

Installing Software Now and Upgrading Later in Silent Mode

This section explains how you can install only the software binaries of Enterprise Manager 12c Cloud Control in silent mode at one point, and upgrade them at a later point.

This section covers the following:

- Upgrading in Software-Only Mode with 1-System Upgrade Approach in Silent Mode

- Upgrading in Software-Only Mode with 2-System Upgrade Approach in Silent Mode

Note:
You can find the OMS and Management Agent entries in the /etc/oragchomelist file for all UNIX platforms except HPUNIX, HPia64, Solaris Sparc. On HPUNIX, HPia64, Solaris Sparc platforms, the entries are present in /var/opt/oracle/oragchomelist.

Note:
If you see an error message stating that you have not copied the emkey, run the following command.
$<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_host <repository_host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

(Here, the Management Repository details are details of the existing or old Management Repository. And when you run this command, you might be prompted for the admin server password.)

Upgrading in Software-Only Mode with 1-System Upgrade Approach in Silent Mode

To upgrade in software-only mode with 1-System upgrade approach, refer to Installing Software Now and Upgrading Later in Silent Mode.

Note:
You might have a plug-in version deployed to the earlier release of Enterprise Manager that is not supported in Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), for example, EBS 2.0 and 3.0 plug-in versions. In this case, when you invoke the installer with -pluginLocation argument, make sure you do NOT provide the software of the higher version of the unsupported plug-in even if the higher version is available for download. This ensures that the unsupported version is removed while upgrading to 12c Release 2 (12.1.0.2). After you upgrade, you can deploy the higher version directly from the Plug-In Manager.

Upgrading in Software-Only Mode with 2-System Upgrade Approach in Silent Mode

This section describes how you can upgrade in software-only mode with 2-System upgrade approach. In particular, this section covers the following:

- Installing Software Binaries

- Running allroot.sh Script

- Configuring and Upgrading

Installing Software Binaries

To install the software binaries of Enterprise Manager Cloud Control, follow the steps outlined in Installing Software Binaries.

Running allroot.sh Script

To run the allroot.sh script, After You Install.

Configuring and Upgrading

To configure the software binaries of Enterprise Manager Cloud Control, follow these steps:

1. Copy the following response file to an accessible location on your local host:
<Software_Location>/response/upgrade.rsp

In this command, <Software_Location> refers to the location where you have downloaded the software kit.

2. Edit the response file and enter appropriate values for the variables described in Appendix A.

3. Configure the software binaries by invoking the ConfigureGC.sh script passing the response you edited in the previous step:
$<MIDDLEWARE_HOME>/oms/sysman/install/ConfigureGC.sh -silent -responseFile <absolute_path>/upgrade.rsp -staticPortsIniFile <absolute_path_to_staticports.ini_file> [-invPtrLoc <absolute_path_to_inventory_directory>]

Note:

- While installing the software binaries as described in Installing Software Binaries, if you had passed the argument -invPtrLoc, then pass the same argument here as well.

- For information about the additional, advanced options you can pass while invoking the script, refer to Advanced Script Options for Software-Only Mode.

- The staticports.ini file is available at the following location of the software kit (DVD, downloaded software, and so on):
<software_kit>/response/staticports.ini

- In the staticports.ini file, ensure that the ports you enter for Enterprise Manager Upload Http Port and Enterprise Manager Upload Http SSL Port match with the unsecure and secure ports you entered in the Preupgrade Console.

Note:
If you see an error about missing plug-ins, then do the following:

1. Make a note of the plug-in version and plug-in update as shown in the missing plug-ins error message. The plug-ins displayed in the error message have the following format:
PluginID:PluginVersion:PluginUpdate

2. Manually download the same plug-in version and the same or higher plug-in update as shown in the missing plug-ins error message, from the following URL.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

Store the plug-ins in an accessible location, and ensure that the location is meant only for these missing plug-ins.

3. Invoke the ConfigureGC.sh script in the following way to install the downloaded plug-ins:
<OMS_HOME>/sysman/install/ConfigureGC.sh -pluginLocation <absolute_path_to_plugin_sw>

Note:
If you encounter any validation error, then follow these steps:

1. Discard the backed up database.

2. Resolve the issue in the Preupgrade Console.

3. Take a fresh backup of the database now.

4. Invoke the installer all over again, and retry the upgrade process.

Upgrading OMS and Management Repository for 1-System on Different Host Approach

To upgrade your existing OMS and Management Repository of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) with 1-System on a Different Host approach, follow these steps:

1. On the remote host, install only the software binaries of Enterprise Manager Cloud Control.

- For instructions to install only the software binaries in graphical mode, see Installing Software Binaries.

- For instructions to install them in silent mode, see Installing Software Now and Upgrading Later in Silent Mode.

Note that Step(15) in Installing Software Binaries (graphical mode) and Step (4) in Installing Software Now and Upgrading Later in Silent Mode (silent mode) instruct you to deinstall the Management Agent. However, in the case of a 1-system upgrade on a different host, DO NOT deinstall the Management Agent. You need the Management Agent installed on the OMS host during the 1-system upgrade on a different host to monitor the Enterprise Manager components.

Note:
This remote host must be different from the host where your existing, earlier release of Enterprise Manager is running.

2. Deploy the plug-ins:
$<OMS_HOME>/sysman/install/PluginInstall.sh

On the Plug-In Deployment screen, select the optional plug-ins you want to install.

The screen displays only those plug-ins that were available in the software kit (DVD, downloaded software) you used in the previous step for installing the software binaries.

The pre-selected rows on this screen are mandatory plug-ins that will be installed by default. Select the optional ones you want to install or upgrade.

Note:

- On Microsoft Windows, run PluginInstall.bat.

- If you want to install some plug-ins that are not in the software kit, then follow these steps:

1. Manually download the plug-ins from the Enterprise Manager Download page on OTN, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Invoke the script with the following option, and pass the location where the plug-ins you want to install are available:
$<OMS_HOME>/sysman/install/PluginInstall.sh -pluginLocation <absolute_path_to_plugin_software_location>

The Plug-In Deployment screen displays a list of plug-ins that were available in the software kit as well as the downloaded plug-ins available in this custom location. You can choose the ones you want to install.

3. On the host where your existing, earlier release of Enterprise Manager is running, stop the OMS. To do so, run the following command from the OMS home:
$<OMS_HOME>/bin/emctl stop oms -all

Note:
On Microsoft Windows, run the following command:
%OMS_HOME%\bin\emctl stop oms -all

4. On the remote host where you installed the software binaries of Enterprise Manager Cloud Control as described in Step (1), set the environment variable ORACLE_HOME to the OMS home, and MW_HOME to the Middleware home.

- In bash terminal, run the following command:
export ORACLE_HOME=<absolute_path_to_oms_home>

export MW_HOME=<absolute_path_to_middleware_home>

- In other terminals, run the following command:
setenv ORACLE_HOME <absolute_path_to_oms_home>

setenv MW_HOME <absolute_path_to_middleware_home>

Note:
On Microsoft Windows, run the following commands:
set ORACLE_HOME=<absolute_path_to_middleware_home>

set MW_HOME=<absolute_path_to_middleware_home>

5. Run the Management Repository-related prerequisite checks to verify if the Oracle Management Repository (Management Repository) its ready for upgrade:

1. Create a directory for storing prerequisite results:
mkdir <prereq_result_location>

For example, on UNIX platforms, run this:

mkdir $ORACLE_HOME/prerequisiteResults

Note:
Example for Microsoft Windows:
mkdir %ORACLE_HOME%\prerequisiteResults

2. Run the prerequisite checks:
$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLLoc $ORACLE_HOME/install/requisites/list -prereqResultLoc <prereq_result_location> -dbHost <REPOSITORY_HOST> -dbPort <PORT> -dbSid <REPOSITORY_SID> -dbUser SYS -dbPassword <db_password> -dbRole sysdba -configurationType <MINI/SMALL/MEDIUM/LARGE> -runPrerequisites

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLLoc %ORACLE_HOME%\install\requisites\list -prereqResultLoc <prereq_result_location> -dbHost <REPOSITORY_HOST> -dbPort <PORT> -dbSid <REPOSITORY_SID> -dbUser SYS -dbPassword <db_password> -dbRole sysdba -configurationType <MINI/SMALL/MEDIUM/LARGE> -runPrerequisites

For example,

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLLoc $ORACLE_HOME/install/requisites/list -prereqResultLoc $ORACLE_HOME/prerequisiteResults -dbHost example.com -dbPort 1521 -dbSid dbview -dbUser SYS -dbPassword dbpass -dbRole sysdba -configurationType SMALL -runPrerequisites

Note:
Example for Microsoft Windows:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLLoc %ORACLE_HOME%\install\requisites\list -prereqResultLoc %ORACLE_HOME%\prerequisiteResults -dbHost example.com -dbPort 1521 -dbSid dbview -dbUser SYS -dbPassword dbpass -dbRole sysdba -configurationType SMALL -runPrerequisites

Note:

- If you do not pass the argument -configurationType, then by default, the deployment size MEDIUM is honored. For more information on deployment sizes, the prerequisite checks that are run, the database parameters that are set, and and how you can modify the deployment size after installation, refer to Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

- The output of this step confirms the prerequisite checks that passed and failed. You will see the status Pass or Fail.

6. If the Management Repository-related prerequisite checks fail, run the auto-corrective actions to automatically correct the issues:
$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLLoc $ORACLE_HOME/install/requisites/list -prereqResultLoc <prereq_result_location> -dbHost <REPOSITORY_HOST> -dbPort <PORT> -dbSid <REPOSITORY_SID> -dbUser SYS -dbPassword <db_password> -dbRole sysdba -useHistory -runCorrectiveActions

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLLoc %ORACLE_HOME%\install\requisites\list -prereqResultLoc <prereq_result_location> -dbHost <REPOSITORY_HOST> -dbPort <PORT> -dbSid <REPOSITORY_SID> -dbUser SYS -dbPassword <db_password> -dbRole sysdba -useHistory -runCorrectiveActions

For example,

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLLoc $ORACLE_HOME/install/requisites/list -prereqResultLoc $ORACLE_HOME/prerequisiteResults -dbHost example.com -dbPort 1521 -dbSid dbview -dbUser SYS -dbPassword dbpass -dbRole sysdba -useHistory -runCorrectiveActions

Note:
Example for Microsoft Windows:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLLoc %ORACLE_HOME%\install\requisites\list -prereqResultLoc %ORACLE_HOME%\prerequisiteResults -dbHost example.com -dbPort 1521 -dbSid dbview -dbUser SYS -dbPassword dbpass -dbRole sysdba -useHistory -runCorrectiveActions

Note:
The output of this step confirms whether or not corrective actions were taken by the script. If corrective actions were taken by the script, then you will see the status Pass. Otherwise, you will see the status NA.
If the status of the prerequisite check was Fail in the output of Step (4), and if it changed to NA in the output of Step (5), do the following:

1. Access the following file:
On UNIX platforms:

$ORACLE_HOME/prerequisiteResults/log/LATEST/emprereqkit.out

On Microsoft Windows platforms:

%ORACLE_HOME%\prerequisiteResults\log\LATEST\emprereqkit.out

2. Review the passed and failed tests and their corresponding corrective actions.

3. For the failed tests, manually take corrective actions.

7. Run the plug-in configuration assistant in prerequisite mode:
$ORACLE_HOME/bin/pluginca -oracleHome $ORACLE_HOME -middlewareHome $MW_HOME -action prereqCheck -plugins <list_of_plugins> -oldOracleHome <old_oms_home> -installMode gcUpgrade -client gcinstaller -customParams "connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>))),username=sysman"

Note:
The plug-ins to be mentioned for the <pluginslist> argument can be found in the following file:
$ORACLE_HOME/sysman/install/plugins_installed.txt

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\bin\pluginca -oracleHome %ORACLE_HOME% -middlewareHome %MW_HOME% -action prereqCheck -plugins <list_of_plugins> -oldOracleHome <old_oms_home> -installMode gcUpgrade -client gcinstaller -customParams "connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>))),username=sysman"

For example,

$ORACLE_HOME/bin/pluginca -oracleHome $ORACLE_HOME -middlewareHome $MW_HOME -action prereqCheck -plugins "oracle.sysman.db=12.1.0.1.0,oracle.sysman.xa=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.em.sat=12.1.0.1.0,oracle.em.sidb=12.1.0.1.0,oracle.em.smdn=12.1.0.1.0,oracle.em.smad=12.1.0.1.0,oracle.em.smss=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.empa=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.em.ssad=12.1.0.1.0" -oldOracleHome <old_oms_home> -installMode gcUpgrade -client gcinstaller -customParams "connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview))),username=sysman"

Note:
Ensure that the old OMS home is accessible from the remote host where you are running this command.

Note:
Example for Microsoft Windows:
%ORACLE_HOME%\bin\pluginca -oracleHome %ORACLE_HOME% -middlewareHome %MW_HOME% -action prereqCheck -plugins "oracle.sysman.db=12.1.0.1.0,oracle.sysman.xa=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.em.sat=12.1.0.1.0,oracle.em.sidb=12.1.0.1.0,oracle.em.smdn=12.1.0.1.0,oracle.em.smad=12.1.0.1.0,oracle.em.smss=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.empa=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.em.ssad=12.1.0.1.0" -oldOracleHome \\oldem\c$\EM\oms10g -installMode gcUpgrade -client gcinstaller -customParams "connectString=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview))),username=sysman"

8. Run Management Repository-related preupgrade checks:
$ORACLE_HOME/sysman/admin/emdrep/bin/RepManager -doPurging yes <REPOSITORY_HOST> <PORT> <REPOSITORY_SID> -action preupgrade -dbUser SYS -reposName sysman -mwHome $MW_HOME -mwOraHome $ORACLE_HOME -oracleHome $ORACLE_HOME

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\sysman\admin\emdrep\bin\RepManager -doPurging yes <REPOSITORY_HOST> <PORT> <REPOSITORY_SID> -action preupgrade -dbUser SYS -reposName sysman -mwHome %MW_HOME% -mwOraHome %ORACLE_HOME% -oracleHome %ORACLE_HOME%

For example,

$ORACLE_HOME/sysman/admin/emdrep/bin/RepManager -doPurging yes example.com 1521 dbview -action preupgrade -dbUser SYS -reposName sysman -mwHome $MW_HOME -mwOraHome $ORACLE_HOME -oracleHome $ORACLE_HOME

Note:
Example for Microsoft Windows:
%ORACLE_HOME%\sysman\admin\emdrep\bin>RepManager -doPurging yes example.com 1521 dbview -action preupgrade -dbUser SYS -reposName sysman -mwHome %MW_HOME% -mwOraHome %ORACLE_HOME% -oracleHome %ORACLE_HOME%

9. Upgrade the Management Repository:
$ORACLE_HOME/sysman/admin/emdrep/bin/RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY SID>)))" -action upgrade -dbUser SYS -reposName sysman -mwHome $MW_HOME -mwOraHome $ORACLE_HOME -oracleHome $ORACLE_HOME

If the preceding command fails, then run the following:

$ORACLE_HOME/sysman/admin/emdrep/bin/RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY SID>)))" -resume retry -checkpointLocation $ORACLE_HOME/sysman/log/schemamanager -dbUser SYS -reposName sysman -mwHome $MW_HOME -mwOraHome $ORACLE_HOME -oracleHome $ORACLE_HOME

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\sysman\admin\emdrep\bin\RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY SID>)))" -action upgrade -dbUser SYS -reposName sysman -mwHome %MW_HOME% -mwOraHome %ORACLE_HOME% -oracleHome %ORACLE_HOME%

If the preceding command fails, then run the following:

%ORACLE_HOME%\sysman\admin\emdrep\bin\RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY SID>)))" -resume retry -checkpointLocation $ORACLE_HOME/sysman/log/schemamanager -dbUser SYS -reposName sysman -mwHome %MW_HOME% -mwOraHome %ORACLE_HOME% -oracleHome %ORACLE_HOME%

For example,

$ORACLE_HOME/sysman/admin/emdrep/bin/RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<example.com> )(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -action upgrade -dbUser SYS -reposName sysman -mwHome $MW_HOME -mwOraHome $ORACLE_HOME -oracleHome $ORACLE_HOME

Note:
Example for Microsoft Windows:
%ORACLE_HOME%\sysman\admin\emdrep\bin\RepManager -doPurging yes -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -action upgrade -dbUser SYS -reposName sysman -mwHome %MW_HOME% -mwOraHome %ORACLE_HOME% -oracleHome %ORACLE_HOME%

10. Revert the corrective actions that were automatically taken in Step (5):
$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLLoc $ORACLE_HOME/install/requisites/list -prereqResultLoc <prereq_result_location> -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>)))" -dbUser SYS -dbPassword <db_password> -dbRole sysdba -useHistory -runPostCorrectiveActions

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLLoc %ORACLE_HOME%\install\requisites\list -prereqResultLoc <prereq_result_location> -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST> )(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>)))" -dbUser SYS -dbPassword <db_password> -dbRole sysdba -useHistory -runPostCorrectiveActions

For example,

$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade -prerequisiteXMLLoc $ORACLE_HOME/install/requisites/list -prereqResultLoc $ORACLE_HOME/prerequisiteResults -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -dbRole sysdba -useHistory -runPostCorrectiveActions

Note:
Example for Microsoft Windows:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat -executionType upgrade -prerequisiteXMLLoc %ORACLE_HOME%\install\requisites\list -prereqResultLoc %ORACLE_HOME%\prerequisiteResults -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -dbRole sysdba -useHistory -runPostCorrectiveActions

11. Set the environment variable JAVA_HOME to the JDK location:
For UNIX Platforms:

setenv JAVA_HOME <MIDDLEWARE_HOME>/jdk16/jdk

For example,

setenv JAVA_HOME /u01/oracle/middleware/jdk16/jdk

For Microsoft Windows Platforms:

set JAVA_HOME=<MIDDLEWARE_HOME>\jdk16\jdk

For example,

set JAVA_HOME=C:\Oracle\Middlware\jdk16\jdk

Note:
If you had installed JDK in a different location, then specify the absolute path to that location. Also ensure that it is JDK 1.6 v24+ (64-bit version for 64-bit platforms and 32-bit version for 32-bit platforms).

12. Create MDS schema in the Management Repository:
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/sysman/admin/emdrep/bin/mdsschemamanager.pl -action=-createRepository -connectString=<REPOSITORY_HOST>:<PORT>:<REPOSITORY_SID> -dbUser=SYS -dbPassword=<db_password> -mdsPassword=<new_mds_user_password> -mwHome=$MW_HOME

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\perl\bin\perl %ORACLE_HOME%\sysman\admin\emdrep\bin\mdsschemamanager.pl -action=-createRepository -connectString=<REPOSITORY_HOST>:<PORT>:<REPOSITORY_SID> -dbUser=SYS -dbPassword=<db_password> -mdsPassword=<new_mds_user_password> -mwHome=%MW_HOME%

For example,

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/sysman/admin/emdrep/bin/mdsschemamanager.pl -action=-createRepository -connectString=example.com:1521:dbview -dbUser=SYS -dbPassword=dbpass -mdsPassword=mdspass -mwHome=$MW_HOME

Note:
Example for Microsoft Windows:
%ORACLE_HOME%\perl\bin\perl %ORACLE_HOME%\sysman\admin\emdrep\bin\mdsschemamanager.pl -action=-createRepository -connectString=example.com:1521:dbview -dbUser=SYS -dbPassword=dbpass -mdsPassword=mdspass -mwHome=%MW_HOME%

13. Create OPS schema in the Management Repository:
$ORACLE_HOME/sysman/admin/emdrep/bin/SecurityRepManager -action createRepository -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>)))" -dbUser SYS -dbPassword <db_password> -schemaPrefix sysman -schemaPassword <sysman_user_password> -component opss

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\sysman\admin\emdrep\bin\SecurityRepManager -action createRepository -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>)))(CONNECT_DATA=(SID=<REPOSITORY_SID>)))" -dbUser SYS -dbPassword <db_password> -schemaPrefix sysman -schemaPassword <sysman_user_password> -component opss

For example,

$ORACLE_HOME/sysman/admin/emdrep/bin/SecurityRepManager -action createRepository -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -schemaPrefix sysman -schemaPassword sysmanpass -component opss

Note:
Example for Microsoft Windows:
%ORACLE_HOME%\sysman\admin\emdrep\bin\SecurityRepManager -action createRepository -connectString "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -schemaPrefix sysman -schemaPassword sysmanpass -component opss

14. Configure the OMS:
$ORACLE_HOME/bin/omsca NEW -lock_console -lock_upload -CONFIGURE_REPEATER true -nostart [-RESPONSE_FILE <absolute_location_to_response_file>]

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\bin\omsca NEW -lock_console -lock_upload -CONFIGURE_REPEATER true -nostart [-RESPONSE_FILE <absolute_location_to_response_file>]

Note:
The argument -RESPONSE_FILE <absolute_location_to_response_file> is optional.

The response file must contain the following variables:

-AS_HOST=<hostname>
-AS_USERNAME=<admin serverr username>
-AS_HTTPS_PORT=<admin server https port>
-MSPORT=<managed server http port>
-MS_HTTPS_PORT=<managed server https port>
-EM_INSTANCE_HOME=<MW_HOME/gc_inst by default>
-EM_NODEMGR_PORT=<node manager https port>
-WEBTIER_ORACLE_HOME=<MW_HOME/Oracle_WT>
-REP_USER=SYSMAN
-REP_CONN_STR=<connection string>
-NM_USER=<node manager username>
-EM_DOMAIN_NAME=<domain name>
-EM_INSTANCE_HOST=<hostname where the instance home will reside>
-EM_UPLOAD_PORT=<upload http port>
-EM_UPLOAD_HTTPS_PORT=<upload https port>
-EM_CONSOLE_PORT=<console http port>
-EM_CONSOLE_HTTPS_PORT=<console https port>

Example 10-1 Reponse File Format for UNIX

-AS_HOST=example.com
-AS_USERNAME=weblogic
-AS_HTTPS_PORT=7101
-MSPORT=7201
-MS_HTTPS_PORT=7301
-EM_INSTANCE_HOME=/home/john/oracle/em/middleware/gc_inst
-EM_NODEMGR_PORT=7401
-WEBTIER_ORACLE_HOME=/home/john/oracle/em/middleware/Oracle_WT
-REP_USER=SYSMAN
-REP_CONN_STR=(DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=example.com)(PORT\=1521)))(CONNECT_DATA\=(SID\=dbview)))
-NM_USER=nodemanager
-EM_DOMAIN_NAME=GCDomain
-EM_INSTANCE_HOST=example.com
-EM_UPLOAD_PORT=4889
-EM_UPLOAD_HTTPS_PORT=1159
-EM_CONSOLE_PORT=7788
-EM_CONSOLE_HTTPS_PORT=7799

Example 10-2 Reponse File Format for Microsoft Windows

-AS_HOST=example.com
-AS_USERNAME=weblogic
-AS_HTTPS_PORT=7101
-MSPORT=7201
-MS_HTTPS_PORT=7301
-EM_INSTANCE_HOME=C\:\\Oracle\\Middleware\\gc_inst
-EM_NODEMGR_PORT=7401
-WEBTIER_ORACLE_HOME=C\:\\Oracle\\Middleware\\Oracle_WT
-REP_USER=SYSMAN
-REP_CONN_STR=(DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=example.com)(PORT\=1521)))(CONNECT_DATA\=(SID\=dbview)))
-NM_USER=nodemanager
-EM_DOMAIN_NAME=GCDomain
-EM_INSTANCE_HOST=example.com
-EM_UPLOAD_PORT=4889
-EM_UPLOAD_HTTPS_PORT=1159
-EM_CONSOLE_PORT=7788
-EM_CONSOLE_HTTPS_PORT=7799

15. Configure the plug-ins:
$ORACLE_HOME/bin/pluginca -oracleHome $ORACLE_HOME -middlewareHome $MW_HOME -action deploy -plugins <pluginlist> -oldOracleHome <old_oms_home> -installMode gcupgrade

Note:
The plug-ins to be mentioned for the <pluginslist> argument can be found in the following file:
$ORACLE_HOME/sysman/install/plugins_installed.txt

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\bin\pluginca -oracleHome %ORACLE_HOME% -middlewareHome %MW_HOME% -action deploy -plugins "<pluginlist>" -oldOracleHome <old_oms_home> -installMode gcupgrade

For example,

$ORACLE_HOME/bin/pluginca -oracleHome $ORACLE_HOME -middlewareHome $MW_HOME -action deploy -plugins "oracle.sysman.db=12.1.0.1.0,oracle.sysman.xa=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.em.sat=12.1.0.1.0,oracle.em.sidb=12.1.0.1.0,oracle.em.smdn=12.1.0.1.0,oracle.em.smad=12.1.0.1.0,oracle.em.smss=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.empa=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.em.ssad=12.1.0.1.0" -oldOracleHome /u02/app/Oracle/Middleware/oms11g -installMode gcupgrade

Note:
Ensure that the old OMS home is accessible from the remote host where you are running this command.

Note:
Example for Microsoft Windows:
%ORACLE_HOME%\bin\pluginca -oracleHome %ORACLE_HOME% -middlewareHome %MW_HOME% -action deploy -plugins "oracle.sysman.db=12.1.0.1.0,oracle.sysman.xa=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.em.sat=12.1.0.1.0,oracle.em.sidb=12.1.0.1.0,oracle.em.smdn=12.1.0.1.0,oracle.em.smad=12.1.0.1.0,oracle.em.smss=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.empa=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.em.ssad=12.1.0.1.0" -oldOracleHome \\comp1\c$\EM\oms10g -installMode gcupgrade

16. Migrate the plug-in inventory from old tables to the new Plug-In Lifecycle Application (PLA) inventory table:

1. Log in to the upgraded Management Repository as SYSMAN user:
From the Old OMS

Navigate to the $DB_HOME\bin directory.

For example (UNIX), /scratch/aime/DB/db/bin. For example (Microsoft Windows), C:\DB\db\bin.

Run the following, where HOST is where the Management Repository resides:

sqlplus sysman/<password _for_sysman_user>@"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<REPOSITORY_SID>)))

For example,

sqlplus sysman/mypwd@"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=dbview)))

From the New OMS

Navigate to the $MW_HOME\oms\bin directory.

Run the following:

sqlplus sysman/<password _for_sysman_user>@"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<REPOSITORY_HOST>)(PORT=<PORT>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<REPOSITORY_SID>)))"

For example,

sqlplus sysman/mypwd@"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=dbview)))"

2. Run the following SQL query

SET SERVEROUTPUT ON SIZE 100000
DECLARE
PLUGIN_BITS_TYPE     CONSTANT NUMBER := 1;
DISCOVERY_BITS_TYPE    CONSTANT NUMBER := 2;
AGENT_DEST_TYPE      CONSTANT NUMBER := 3;
err_num NUMBER;
err_msg VARCHAR2(100);

BEGIN
FOR rec in ( select plugin_id, plugin_version, target_guid, plugin_home,  plugin_type from PRE_UPGC_DEP_PLUGINS )
LOOP

BEGIN

IF rec.plugin_type = 'discoveryplugin' THEN
EM_PLUGIN_INVENTORY.add_to_plugin_inventory(rec.plugin_id, rec.plugin_version, DISCOVERY_BITS_TYPE, AGENT_DEST_TYPE, rec.target_guid, rec.plugin_home);
ELSE
EM_PLUGIN_INVENTORY.add_to_plugin_inventory(rec.plugin_id, rec.plugin_version, PLUGIN_BITS_TYPE, AGENT_DEST_TYPE, rec.target_guid, rec.plugin_home);
END IF;

EXCEPTION
WHEN DUP_VAL_ON_INDEX THEN
-- ALTER SESSION CLOSE DATABASE LINK PREUPGTO_NG_LINK;
DBMS_OUTPUT.PUT_LINE('Records already exists.');
WHEN OTHERS THEN
-- ALTER SESSION CLOSE DATABASE LINK PREUPGTO_NG_LINK;
err_num := SQLCODE;
err_msg := SUBSTR(SQLERRM, 1, 100);
DBMS_OUTPUT.PUT_LINE('Found exception Error Message :' || err_msg || ' Error Number ;' || err_num);

END;

END LOOP;
commit;
END;

/

17. Start the OMS:
$ORACLE_HOME/bin/emctl start oms

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\bin\emctl start oms

18. While installing the software binaries in Step (1), if you had chosen to configure the security updates, then configure Oracle Configure Manager (OCM):
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/sysman/install/RunOMSOCMConfig.pl $ORACLE_HOME $ORACLE_HOME/perl/bin/perl

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\perl\bin\perl %ORACLE_HOME%\sysman\install\RunOMSOCMConfig.pl %ORACLE_HOME% %ORACLE_HOME%\perl\bin\perl

19. Configure the Management Agent. To do so, run the following command from the Management Agent home:
$ORACLE_HOME/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<absolute_path_to_agentbasedir> OMS_HOST=<oms_host> EM_UPLOAD_PORT=<secure_oms_upload_port> AGENT_REGISTRATION_PASSWORD=<agent_reg_password> -configOnly

Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\sysman\install\agentDeploy.bat AGENT_BASE_DIR=<absolute_path_to_agentbasedir> OMS_HOST=<oms_host> EM_UPLOAD_PORT=<secure_oms_upload_port> AGENT_REGISTRATION_PASSWORD=<agent_reg_password> -configOnly

For example,

/u01/app/Oracle/Middleware/agent/core/12.1.0.1.0/sysman/install/agentDeploy.sh AGENT_BASE_DIR=/u01/app/Oracle/Middleware/agent OMS_HOST=example.com EM_UPLOAD_PORT=1159 AGENT_REGISTRATION_PASSWORD=2bornot2b -configOnly

Note:
Ensure that you enter the secure (HTTPS) upload port number for the argument EM_UPLOAD_PORT.

Note:
Example for Microsoft Windows:
C:\Oracle\Middleware\agent\core\12.1.0.1.0\sysman\install\agentDeploy.bat AGENT_BASE_DIR=C:\Oracle\Middleware\agent OMS_HOST=example.com EM_UPLOAD_PORT=1159 AGENT_REGISTRATION_PASSWORD=2bornot2b -configOnly

Upgrading Multi-OMS Environment

To upgrade an Enterprise Manager system of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) that has multiple OMS, follow these steps:

1. Upgrade the first OMS. You can use any of the upgrade approaches described in this guide — Upgrading OMS and Management Repository in Graphical Mode, Upgrading OMS and Management Repository in Silent Mode, Installing Software Now and Upgrading Later in Graphical Mode, or Installing Software Now and Upgrading Later in Silent Mode.

Note:
Always start the upgrade process with the first OMS, where the Admin Server is running, and not with any of the additional OMS instances.
To identify the OMS where the Admin Server is running, run the following command on the OMS home and verify if the output displays the Admin Server details.

$<OMS_HOME>/bin/emctl status oms -details

You should see a similar output:

Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.2.0
Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved
Enter Enterprise Manager Root (SYSMAN) Password :
Console Server Host : myhost.example.com
.
.
.
WLS Domain Information
Domain Name : GCDomain
Admin Server Host: myhost.example.com
.
.
.

2. After upgrading the first OMS in your system, do the following:

- If you upgraded the first OMS with 2-System upgrade approach, then for every other host where an additional OMS of the earlier release is running, install a new Oracle Management Service 12c using the Add Management Service deployment procedure available in the Enterprise Manager Cloud Control console.
For information about installing an additional OMS using the Add Management Service deployment procedure, refer to the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

- If you upgraded the first OMS with 1-System upgrade approach, then for every other host where an additional OMS of the earlier release is running, invoke the Enterprise Manager Cloud Control Installation Wizard, and on the Install Types screen, select Upgrade an Existing Enterprise Manager System, and then, select One System Upgrade. Then, select the OMS home you want to upgrade.

11 Performing Postupgrade Tasks

This chapter describes the postinstallation tasks you must perform. In particular, this part covers the following:

- Creating Link to Upgraded Oracle Management Repository

- Reconfiguring Oracle Software Library

- Checking Agent Upgrade Status

- Performing General Postupgrade Tasks

- Tracking the Status of Deferred Data Migration Jobs

- Tracking the Status of Accrued Data Migration Jobs

- Generating and Viewing Diff Reports

- Viewing Inactive Targets in the Upgraded Enterprise Manager System

- Signing Off Agent Migration Process

- Updating Incident Rules

Creating Link to Upgraded Oracle Management Repository

Note:
Follow these instructions only if you are upgrading using the 2-System upgrade approach. Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

As a prerequisite for upgrading your Enterprise Manager system using the 2-System upgrade approach, you are required to back up your existing database first, and then upgrade the Oracle Management Repository (Management Repository) that is configured in it. This is to ensure that the upgraded Management Repository coexists with the earlier release of the Management Repository.

However, after you upgrade the Management Repository in the backed up database, link it to your earlier release of the Management Repository so that the two repositories are linked with each other, and any operations on the upgraded repository can be directly done from the old repository.

WARNING:

Verify the value set to the GLOBAL_NAMES parameter on both the databases:

- If the GLOBAL_NAMES parameter is set to FALSE on both the databases, then ensure that you do not change this value until the upgrade is complete, and all the Management Agents are switched over.

- If the GLOBAL_NAMES parameter is set to TRUE on even one of the databases, and if both the databases have the same value for the GLOBAL_NAME parameter, then change the value of the GLOBAL_NAME parameter set on the new, cloned database to a value that is different from the one set on the old database.

To link the earlier release of the repository to the upgraded repository, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, in the Select Upgrade Type section, select 2-System. For information about these upgrade approaches, see "Understanding Upgrade Approaches".
Enterprise Manager Grid Control refreshes the page and displays a table with a list of tasks you need to perform for the upgrade approach you selected.

4. In the OMS Upgrade Steps section, from the table, click Create Link to Upgraded Repository.

5. On the Create Upgraded Oracle Management Repository Link page, in the Repository Link Details section, do the following:

1. Enter the connect string to connect to the upgraded Management Repository that will be used by Enterprise Manager Cloud Control.

Note:
You will find the connect string set as a value to the EM_REPOS_CONNECTDESCRIPTOR parameter of the emgc.properties file. This file is present in the OMS Instance Base directory (gc_inst). When you enter this value as the connect string, remove all backslashes (\) and white spaces if any.
For example, the value in the emgc.properties file might be:

(DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=example.com)(PORT\=1521)))(CONNECT_DATA\=(SID\=emrep)))

When you enter this value as the connect string, it must look like this:

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=emrep)))

If you connect using service name instead of SID, then replace SID in the syntax with SERVICE_NAME.

2. Enter the SYSMAN password of the upgraded Management Repository that will be used by Enterprise Manager Cloud Control.

3. Enter the SYS password of the old Management Repository.

6. Click Create DB Link.

Note:
If you had already provided these details and linked the two repositories, and if you are updating the connect descriptor or the SYSMAN password, then click Re-create DB Link.

Reconfiguring Oracle Software Library

Note:
Follow these instructions only if you are upgrading using the 2-System upgrade approach.

To reconfigure an upgraded Software Library in a two-system upgrade, perform these steps:

Note:

- In a one-system upgrade, where the upgraded Enterprise Manager 12c comes up on the same host, reconfiguration is not required as the upgraded Software Library becomes functional when the system starts.
For a one system upgrade, where the upgraded Enterprise Manager 12c comes up on a different host, all the location(s) configured in the earlier, existing Enterprise Manager system for Software Library should be accessible from the new host.

- In a two-system upgrade, and sometime in a one-system upgrade on a different host, if the location configured in the earlier, existing Enterprise Manager system is a local file system path, then follow the instructions outlined in Getting Started with 1-System Upgrade Approach for more information.

1. In Cloud Control, from Setup menu, select Provisioning and Patching and then, click Software Library.

2. If the Software Library has been upgraded, then on the Software Library home page, the following notification will appear:
Software Library has been upgraded recently and has not been reconfigured yet. Software Library will be usable only after the reconfiguration has been performed. To initiate the reconfiguration process, click Post Upgrade Reconfiguration.

Click Post Upgrade Reconfiguration, to reconfigure the Software Library.

3. On the Software Library Reconfigure Locations page, enter the new file system location that is to be configured, corresponding to the location configured in the earlier, existing Enterprise Manager system.

The archive of the location which was configured for the old Enterprise Manager system must be unzipped in the corresponding location on the new file system. Also, ensure that the new location, and all its unarchived files and directories have read/write permissions for the 12c OMS process owner.

For example:

In the earlier, existing Enterprise Manager system, lets assume that the Software Library was configured to use the following file system locations:

/shared/swlib1
/shared/swlib2

Figure 11-1 Two-System Reconfiguration

After an upgrade, on the Reconfigure Locations page, you will see:

migrated1, /shared/swlib1
migrated2, /shared/swlib2

where, migrated1 and migrated2 are names automatically assigned to the upgraded locations.

Note:
Since the new locations are only reconfiguring the OMS Shared File System storage locations, you must ensure that these new locations are either NFS-mounted shared locations or OCFS2 shared locations.

You should then provide an alternate file system path for each of the existing locations. For example, as follows:

migrated1, /shared/swlib1, /vol/newswlib1
migrated2, /shared/swlib2, /vol/newswlib2

Before confirming this configuration, you must ensure that the new locations have the corresponding back ups of the configured Software Library directories unarchived, which means, /vol/newswlib1 should have the same content as /shared/swlib1, /vol/newswlib2 should have the same content as /shared/swlib2 had when the backup was taken.

1. Click Validate to submit a validation job that performs exhaustive validation checks on the entities being migrated. Ensure that you track this job to completion. If there are any validation errors, then it will appear on the job step. Some of the common validation errors are:
- The new location specified for reconfiguration does not exist.

- The new location specified for reconfiguration does not have read/write permissions for the OMS process owner.

- The content of the location(s) configured in the old Enterprise Manager Software Library is not restored in the corresponding new location specified for reconfiguration.

2. After a successful validation, click Confirm to reconfigure the Software Library. A job is submitted which must be tracked to successful completion, following which you should initiate any patching or provisioning tasks.

Checking Agent Upgrade Status

Note:
Perform these steps in the Enterprise Manager Grid Control console of the earlier release.

To check the status of the agent upgrade operations, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Upgrade section, click Enterprise Manager 12c Upgrade Console.

3. On the Upgrade Console page, do the following:

- For macro-level details, in the Agent Upgrade Status section, view the count displayed against the following:

- Successful, to identify the Management Agents that have been successfully upgraded.

- Failed, to identify the Management Agents that failed to get upgraded.

- In Progress, to identify the Management Agents that are currently being upgraded.

- Not Started, to identify the Management Agents that are yet to be upgraded.

- Not Supported, to identify the Management Agents that are not supported in the upgraded Enterprise Manager system because Oracle Management Agent 12c is not released for a particular platform.
To drill down and view more information, click the count value. Enterprise Manager Grid Control displays the Agent Upgrade Status page that provides information.

- For micro-level details, in the Other Links section, click Agent Upgrade Status.
On the Agent Upgrade Status page, do the following:

- To filter the list according to your needs and view only the upgrade operations that interest you, use the search functionlity.
For example, to view only the deployment operations that have failed, select Deployment from the Operation Type list, and select Failed from the Operation Status list, and click Search.

Note:
An Operation Type refers to a job submitted for a particular agent upgrade step such as Deployment, Configuration, Health Check, Upgrade, or Switch Over. An operation name refers to the operation name you specified while submitting any of these jobs. And each of these operations can have a status such as Not Started, In Progress, Success, Not Supported, Failed, or Pending Report Verification.

- To deploy the agent software, select one or more Management Agent from the table, and click Deploy and Configure Agent.

Note:
You cannot deploy and configure Oracle Management Agent 12c for problematic Management Agents. To identify problematic Management Agents, see Identifying Problematic Oracle Management Agents.
Also, you can deploy and configure Oracle Management Agent 12c only on existing Management Agents that are either completely upgradable or upgradable with missing plug-ins. To identify the upgradability status of the Management Agents, see Checking the Upgradability Status of Oracle Management Agents.

- To check the health and readiness of the deployed Management Agent, select one or more Management Agents, and click Check Agent Readiness.

- To view the readiness check details, select one or more Management Agents, and click View and Verify Health Check Reports.
On the Agent Readiness Check Details page, review the reports one by one. If you want to confirm that you have verified the report, then select the Management Agent and click Verify and Sign Off Report. If you want to view more details about the readiness check, then select the Management Agent and click View Detailed Report.

- To switch over the agents, select one or more Management Agents, which have successfully been deployed, configured, and health-checked, and click Switch Agent.

Performing General Postupgrade Tasks

This section describes the postupgrade steps you must follow after upgrading to Enterprise Manager Cloud Control. In particular, this section describes the following postupgrade steps:

- Performing General Postupgrade Steps

- Upgrading Oracle Database Plug-Ins

- Upgrading Oracle Exalogic System Targets

- Restarting Central Agent When Additional OMS Is Upgraded

- Stopping OCM Scheduler

- Deleting Obsolete Targets

- Disabling Incident Rule Sets

- Resolving Metric Collection Errors for SOA Target

- Enabling Linux Patching After Enterprise Manager Upgrade

- (Optional) Deleting the Old OMS Home

Performing General Postupgrade Steps

Perform the following general postupgrade tasks:

1. Follow the postupgrade steps outlined in the chapter that describes how to install a new Enterprise Manager system, in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

2. As a sanity check, ensure that all the database parameters are reset to their original values that existed before you started the upgrade operation, particularly for the job_queue_process parameter.

3. Restart the Management Agent that monitors the Management Services and Repository target.

Upgrading Oracle Database Plug-Ins

Note:
This section is applicable only when you upgrade from 12c Release 1 (12.1.0.1) with Bundle Patch 1 to 12c Release 2 (12.1.0.2).

Ensure that you upgrade the existing database plug-in revisions to the latest revision by applying the required patches on the database plug-in homes of the OMS. Table 11-1 lists the patches required for various database plug-in revisions.

Table 11-1 Upgrading Oracle Database Plug-Ins

Source Version

Target Version

Patch to Apply

12.1.0.2

12.1.0.2 [u120804]

14340329

12.1.0.2 [u120427]

12.1.0.2 [u120804]

14340329

12.1.0.2 [u120704]

12.1.0.2 [u120804]

14340329

Make sure you apply this patch to the DB plug-in home of the OMS. For instructions to apply the patch, refer to the ReadMe that is released with the patch.

Caution:
While applying patch 14340329, you might see the following message if there are any patch conflicts.

Conflicts/Supersets for each patch are:
Patch : 14336159
Bug Conflict with 12361589
Conflicting bugs are:
14171309
Patch : 14340329
Bug Superset of 14089634
Super set bugs are:
13713877,14089634
Following patches have conflicts: [12361589 14336159]

To resolve this issue, first apply the MLR patch14546154, and then apply the patch 14340329. For instructions to apply the MLR patch, refer to the ReadMe that is released with the patch.

Note:
In future, if you see patch conflict with any other patch, then raise a service request for an MLR patch.

Upgrading Oracle Exalogic System Targets

Ensure that you upgrade your Oracle Exalogic System targets.

1. To do so, from the Enterprise menu, select Job, then select Library.

2. On the Job Library page, select the job name UPGRADE EXALOGIC SYSTEMS TO FUSION MIDDLEWARE 12.1.0.3.0 MODEL, and click Submit.

For the job to run successfully and upgrade the Oracle Exalogic System targets, you should have already upgraded the Management Agents, which are monitoring these targets, to 12c Release 2 (12.1.0.2) so that they contain the 12.1.0.3 Oracle Fusion Middleware plugin.

If one or more such Management Agents are not upgraded yet to 12c Release 2 (12.1.0.2), then the job fails and does not upgrade the Oracle Exalogic System targets. Under such circumstances, to resolve the issue, first upgrade those Management Agents, and then try submitting this job to upgrade the Oracle Exalogic System targets.

Restarting Central Agent When Additional OMS Is Upgraded

After you upgrade an additional OMS of 10g Release 5 (10.2.0.5) to 12c Release 2 (12.1.0.2) using 1-system upgrade approach, the targets that begin with /EMGC_GCDomain/GCDomain might appear as if they are down (see Example 11-1).

To resolve this issue, restart the upgraded central agent (that is, the Management Agent installed with the OMS).

Example 11-1 Targets Beginning with /EMGC_GCDomain/GCDomain That Are Down

/EMGC_GCDomain/GCDomain/EMGC_OMS2
/EMGC_GCDomain/GCDomain/EMGC_OMS2/emgc
/EMGC_GCDomain/GCDomain/EMGC_OMS2/empbs
/EMGC_GCDomain/GCDomain/EMGC_OMS2/OCMRepeater
/EMGC_GCDomain/GCDomain/EMGC_OMS2/oracle.security.apm(11.1.1.3.0)

Stopping OCM Scheduler

If OCM was installed in the Enterprise Manager system that you upgraded, then follow these steps:

- If you upgraded from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then follow these steps:

1. Set the environment variable ORACLE_HOME to the Oracle Management Service (OMS) home.

- In bash terminal, run the following command:
export ORACLE_HOME=<absolute_path_to_oms_home>

- In other terminals, run the following command:
setenv ORACLE_HOME <absolute_path_to_oms_home>

2. Stop the OCM scheduler:
$ORACLE_HOME/ccr/bin/emCCR stop

Note:
If you have the OCM scheduler installed on Oracle Management Agent, then repeat these steps on the Management Agent home as well. In this case, set the environment variable ORACLE_HOME to the Management Agent home as described in Step (1), and perform Step (2) from its home.

- If you upgraded from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then

1. Set the environment variable ORACLE_CONFIG_HOME to the OMS instance home:

- In bash terminal, run the following command:
export ORACLE_CONFIG_HOME=<absolute_path_to_gc_inst>

- In other terminals, run the following command:
setenv ORACLE_CONFIG_HOME <absolute_path_to_gc_inst>

2. Set the environment variable ORACLE_HOME to the OMS home:
setenv ORACLE_HOME <absolute_path_to_oms_home>

3. Stop the OCM scheduler:
$ORACLE_HOME/ccr/bin/emCCR stop

Note:
If you have the OCM scheduler installed on Oracle Management Agent, then repeat these steps on the Management Agent home as well. In this case, skip Step (1), set the environment variable ORACLE_HOME to the Management Agent home as described in Step (2), and perform Step (3) from its home.

Deleting Obsolete Targets

The following targets from the earlier release of Enterprise Manager are not deleted automatically. This is because you might have created notification rules, metric threshold settings, compliance standard settings, jobs, and so on for these targets, and you might want to copy them to the new Oracle WebLogic Server targets of Enterprise Manager Cloud Control. After copying them, manually delete these targets.

- While upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), the following targets are not deleted automatically. You must delete them manually.

- EM Website

- EM Website System

- The following targets of each old OMS. You can delete these by deleting the top-level Oracle Application Server target of each old OMS.

- Oracle Application Server

- OC4J

- Oracle HTTP Server

- Web Cache

- While upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), the following targets are not deleted automatically. You must delete them manually.

- EM Website

- EM Website System

- The following targets of each old OMS. You can manually delete these by deleting the top-level farm target secFarm_GCDomain.

- Oracle Fusion Middleware Farm

- Oracle Weblogic Domain

- Application Deployment

- Metadata Repository

Note:
After you upgrade your Enterprise Manager using the 1-System upgrade approach, these targets might appear as if they are up and running. This status is false. In any case, do not investigate to resolve the status issue. Manually delete the targets as they are no longer needed in the Enterprise Manager Cloud Control.

Disabling Incident Rule Sets

If you upgraded using the 2-System upgrade approach, then disable the default incident rule sets. If you do not disable them, the incidents are automatically created for all critical metric alerts.

To disable the default incident rule sets, follow the steps:

1. In Cloud Control, from the Setup menu, select Incidents, and then select Incident Rules.

2. On the Incident Rules - All Enterprise Rules page, scroll down the table, and expand Incident management Ruleset for all targets.

3. Select the row for the rule set you want to disable.

4. From the Actions menu, click Disable.

5. On the pop-up window, click OK.

6. Repeat Step (3) to Step (5) for every rule set you want to disable.

7. Once all the rule sets are disabled, ensure that the Enabled column of the table shows No with a warning icon next to it.

Resolving Metric Collection Errors for SOA Target

If you were monitoring a SOA target in your earlier release of Enterprise Manager, then in the health report you generated as described in Generating Health Report of Deployed Oracle Management Agents, you might have seen metric collection errors for the metrics Top SOA SQL Queries and Dehydration Store Tables.

To resolve that issue, access the Monitoring Configuration page of the SOA target, and provide the database credentials.

Enabling Linux Patching After Enterprise Manager Upgrade

Note:
This section is applicable only when you upgrade from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1) to Enterprise Manager Cloud Control 12c.

After upgrading Enterprise Manager, you must stop all active jobs for Linux patching that were submitted prior to the upgrade, and resubmit them on the same targets. This section describes how you can achieve this.

In particular, this section covers the following:

- Configuring DownloadLatestPackages Job

- Configuring UpdateHostPackages Job

Configuring DownloadLatestPackages Job

To configure the DownloadLatestPackages job, follow these steps:

1. Stop active jobs which were scheduled prior to upgrade as follows:

1. From the Enterprise menu, select Job and then Activity. The Job Activity page is displayed.

2. In the Job Activity page, click the Advanced Search link.

3. In the Advanced Search options, select Job Type as DownloadLatestPkgs, Target Type as Host, Status as Active, Scheduled Start as All, and then click Go.

4. In the Advanced Search result, select each job listed in the table and click Stop.

2. For each host target on which an active DownloadLatestPkgs job was stopped, resubmit a new DownloadLatestPkgs job on it as follows:

1. From the Setup menu, select Provisioning and Patching and then Linux Patching. The Patching Setup page is displayed.

2. In the Patching Setup page, click Setup RPM Repository.

3. In the Setup RPM Repository page, select the Host target and set Normal Host Credentials and Privileged Host Credentials for this host target.

4. Click Apply to submit the new job.

Configuring UpdateHostPackages Job

To configure the UpdateHostPackages job, follow these steps:

1. Stop active jobs which were scheduled prior to upgrade as follows:

1. From the Enterprise menu, select Job and then Activity. The Job Activity page is displayed.

2. In the Job Activity page, click the Advanced Search link.

3. In the Advanced Search options, select Job Type as UpdateHostPackages, Target Type as All Target Types against which jobs were submitted, Status as Active, Scheduled Start as All, and then click Go.

4. In the Advanced Search result, select each job listed in the table and click Stop.

2. For each group target on which an active UpdateHostPackages job was stopped, resubmit a new UpdateHostPackages job on it as follows:

1. From the Setup menu, select Provisioning and Patching and then Linux Patching.

2. In the Patching Setup page, click Setup Groups. The Setup Groups page is displayed.

3. In the Setup Groups page, select the group on which you stopped an active UpdateHostPackages job and click Edit. The Edit Group wizard is displayed.

4. In the Edit Group: Properties page, click Next.

5. In the Edit Group: Package Repositories page, click Next.

6. In the Edit Group: Credentials page, either use Host Preferred Credentials or Override Preferred Credentials and specify Normal Host Credentials and Privileged Host Credentials. Click Next.

Note:
Before editing this step, ensure that the host Preferred credentials are set already or the appropriate Named Credentials have been created already. If not, from the Setup menu, select Security and then Named Credentials to create Named Credentials or Preferred Credentials to set the Preferred Credentials for the host targets contained in the Linux Patching group.

7. In the Edit Group: Review page, click Finish to submit the new job.

(Optional) Deleting the Old OMS Home

After upgrading your Enterprise Manager system completely, you can choose to delete your old OMS home. To do so, follow these steps:

- If you upgraded from 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2), then:

- If you upgraded a full release of 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2), then follow the instructions outlined in Appendix L.

- If you upgraded an additional OMS of 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2), then follow the instructions outlined in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

- If you upgraded from 11g Release 1 (11.1.0.1) to 12c Release 2 (12.1.0.2), either full release or an additional OMS, then follow the instructions outlined in the Oracle Enterprise Manager Grid Control Advanced Installation and Configuration Guide.

- If you upgraded from 10g Release 5 (10.2.0.5) to 12c Release 2 (12.1.0.2), either full release or an additional OMS, then follow the instructions outlined in the Oracle Enterprise Manager Grid Control Installation and Configuration Guide.

Tracking the Status of Deferred Data Migration Jobs

This section describes the following:

- Overview of Deferred Data Migration

- Tracking the Status of Deferred Data Migration Jobs

Overview of Deferred Data Migration

Deferred Data Migration is a post-upgrade activity to migrate the format of the data stored in an earlier release of Enterprise Manager to the format compatible with the upgraded Enterprise Manager system. The migration activity is essentially a job in Enterprise Manager that is submitted when the Oracle Management Repository gets upgraded and is scheduled to run in the background when the upgraded Enterprise Manager system starts functioning.

The format of the data stored in Enterprise Manager Cloud Control is different from the format in which the data was stored in any earlier release of Enterprise Manager.

When you upgrade from an earlier release of Enterprise Manager to Enterprise Manager Cloud Control, the data format gets automatically converted or migrated to the format that is compatible with Enterprise Manager Cloud Control.

However, the time taken to migrate the data format depends on the volume of data available in your earlier release of Enterprise Manager. Therefore, if you have a large amount of data, then it takes longer to migrate, and as a result, the upgrade process takes more time to complete. Unfortunately, until the upgrade process completes, your existing Enterprise Manager system might be unavailable, particularly when you use a 1-System upgrade approach (either on the local host or on a different, remote host).

Considering this, Oracle has fine-tuned its upgrade process to migrate the data format in two distinct phases.

In the first phase, when the Enterprise Manager system is shut down and upgraded, the most critical data relevant to the functioning of Enterprise Manager Cloud Control is migrated within a short time so that the new system can start functioning without much downtime. At this point, only some historical data is unavailable, but you can start monitoring the targets in the upgraded Enterprise Manager system, and see new alerts generated by the upgraded Oracle Management Agent.

In the second phase, after the upgraded Enterprise Manager system starts functioning, the remaining data is migrated.

The data whose format is migrated in the second phase, after Enterprise Manager Cloud Control starts functioning, is called the Deferred Data, and this process of migrating from old to new format is called the Deferred Data Migration.

Note:
If you want to prevent the DDMP jobs from running immediately by default, then see Configuring Postupgrade Tasks and Identifying Host for Enterprise Manager Cloud Control (Step 6).

Tracking the Status of Deferred Data Migration Jobs

To track the status of deferred data migration jobs, follow these steps:

1. In Cloud Control, from the Setup menu, select Manage Cloud Control and then, click Post Upgrade Tasks.

2. On the Post Upgrade Tasks page, click the Deferred Data Migration tab.
The tab provides a list of data migration jobs with their status, start date and time, and end date and time.

3. In this tab, you can do the following:

- To start a data migration job for a component, select that component and click Start. By default, the job starts immediately. You cannot change this behavior.

- To rerun a failed job, click the status icon to reach the Job Run page. On the Job Run page, click Edit. On the Edit <JobName> Job page, click Submit to rerun the job.

- To hide or unhide the table columns, from the View list, select an appropriate option.

- To detach the table from the screen, click Detach.

Tracking the Status of Accrued Data Migration Jobs

Note:
This section is applicable only for 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

This section describes the following:

- Overview of Accrued Data Migration

- Tracking the Status of Accrued Data Migration Jobs

Overview of Accrued Data Migration

Accrued Data Migration is a post-upgrade activity to migrate the accrued data stored in an earlier release of Oracle Management Repository (Management Repository) to the upgraded Management Repository. The accrued data relates to functional areas such as blackouts, alerts, events, metrics, and so on.

Note:
The Accrued Data Migration Process does not migrate any manually created data such as new job type, user-defined metrics, Software Library-related changes, and so on.

The migration activity is essentially a job in Enterprise Manager that runs in the background immediately after the earlier releases of Oracle Management Agents (Management Agents) are switched over to Oracle Management Agent 12c, particularly in the case of 2-System upgrade approach.

As part of the upgrade process, when you switch over the earlier releases of Oracle Management Agents to Oracle Management Agent 12c, the new Management Agents start communicating with Enterprise Manager Cloud Control, and start uploading data to the upgraded Oracle Management Repository (Management Repository).

In the 1-System upgrade approach, the entire Enterprise Manager system is upgraded, and therefore, all the Management Agents are switched over at a given time. In this approach, earlier releases of Management Agents cannot coexist with the upgraded ones, and once they are switched over, the upgraded Management Agents upload data only to one Management Repository at any given point, which is the upgraded repository. Therefore, there is no scope for accrued data.

However, in the 2-System upgrade approach, you can choose to switch over your Management Agents in phases. When one set of Management Agents are switched over, they start uploading data about their hosts and targets to the upgraded Management Repository, whereas the ones that are not switched over yet, continue to upload data about their hosts and targets to the old Management Repository. Therefore, the earlier releases of Management Agents coexist with the upgraded ones when only some of them are switched over, and under such circumstances, the data is uploaded to the old Management Repository as well as the new one at a given point. However, note that only one Management Agent represents a host at any given time, so the coexistence does not indicate two Management Agents on the same host. It only indicates an earlier release of Management Agent monitoring a host that coexists with an upgraded Management Agent monitoring another host.

When you swtich over the next set of Management Agents in the next phase, although they start uploading data to the upgraded Management Repository, the data uploaded to the old Management Repository before being switched over continues to exist in the old Management Repository. This data is called the Accrued Data, and the process of migrating this accrued data from the old Management Repository to the new one is called the Accrued Data Migration Process.

Note:
The accrued data migration jobs migrate ECM history data with the following exceptions:

- If the ECM history data is associated with a target that is no longer part of the Enterprise Manager system, then the ECM history data for that target is not migrated to Enterprise Manager Cloud Control.

- For Oracle WebLogic Server targets, the WebLogic configuration data is not migrated. This configuration data has changed significantly in Enterprise Manager Cloud Control.

- As part of the data migration process, summary counts are now calculated and displayed in the ECM Summary region. For migrated data, the summary counts are only calculated for the last seven days.

If you do not see key values that you saw in the past, or if you see new values as key values, then note that this is an expected behavior. Some snapshots have had metadata changes in the last release and key values have changed. If metadata keys were removed from the metadata, those values will no longer be displayed in the Enterprise Manager Cloud Control as key columns, though the data is still present in the migrated database. If existing columns are now flagged as key columns, those columns will start appearing as key columns for newly collected data only. For new columns that are added either as key columns or non key columns, data will start appearing for newly collected data only.

Note:
If you want to prevent the ADMP jobs from running immediately by default, then see Identifying Host for Enterprise Manager Cloud Control (Step 6).

Tracking the Status of Accrued Data Migration Jobs

Note:
This section is applicable only for 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

To track the status of accrued data migration jobs, follow these steps:

1. In Cloud Control, from the Setup menu, select Manage Cloud Control and then, click Post Upgrade Tasks.

2. On the Post Upgrade Tasks page, click the Accrued Data Migration tab.
The Accrued Data Migration page displays information about the accrued data migration jobs related to all the targets available in your Enterprise Manager system. By default, for every target, the accrued data migration job migrates the ECM history details as well as the metric details.

3. In this tab, you can do the following:

- To control the data being migrated for all the targets, from the Run accrued data migration for list, select one of the following options:

- ECM HISTORY MIGRATION, to migrate only the ECM history details.

- METRIC DATA MIGRATION, to migrate only the metric details.

- All, to migrate the ECM history details as well as the metric details.

- To view different types of data, from the View Targets list, select one of the following options:

- All, to view all the accrued data migration jobs for all the targets in your Enterprise Manager system.

- Active, to view the accrued data migration jobs that either failed or are currently running.

- History, to view the accrued data migration jobs that succeeded.

- Not Started, to view the accrued data migration jobs that have not started yet.

- To retry a failed job, select the target for which the job failed and click Retry.

- To stop a running job, select the target for which you want to stop the job and click Stop.

Generating and Viewing Diff Reports

Note:
This section is applicable only for 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

This section describes the following:

- Overview of Diff Reports

- Generating and Viewing Diff Reports

Overview of Diff Reports

Diff Reports provide information about the configuration or setup-related changes that were manually made to the earlier release of Enterprise Manager while it was being upgraded to Enterprise Manager Cloud Control using the 2-System upgrade approach.

In the 2-System upgrade approach, the earlier release of Enterprise Manager coexists with Enterprise Manager Cloud Control until the upgrade operation ends. In some production environments, the upgrade operation might take a long time to complete due to a large volume of data, and during this period, you might make some changes to the functional areas in the earlier release. For example, you might configure an additional location for the software library.

Such changes must be carried over to Enterprise Manager Cloud Control so that the upgraded system is identical to the earlier release. The Diff Reports show a summary of such changes so that you can manually redo those changes in Enterprise Manager Cloud Control.

Generating and Viewing Diff Reports

Note:
This section is applicable only for 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

To generate and view diff reports, follow these steps:

1. In Cloud Control, from the Setup menu, select Manage Cloud Control and then, click Post Upgrade Tasks.

2. On the Post Upgrade Tasks page, click the Diff Report tab.
The Diff Report page lists the reports that were generated in the past for various components. However, when you visit this page the first time, you will not see any reports.

3. On this page, you can do the following:

- To generate the reports for various components, click Regenerate Report.

Note:
On clicking Regenerate Report, the status in the Status column changes to In Progress. Keep refreshing the page manually until the status changes to Completed.

- To view a report of a particular component, select a component (row) from the table, and click Show Report.

- To refresh a report and view the latest changes related to a component, select a component (row) from the table, and click Regenerate Report.

- To hide or unhide the table columns, or to reorder the table columns, from the View list, select an appropriate option.

- To detach the table from the screen, click Detach.

Viewing Inactive Targets in the Upgraded Enterprise Manager System

Note:
This section is applicable only for 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

Targets available in the existing Enterprise Manager system are active (monitored) in the upgraded Enterprise Manager system only when the Oracle Management Agents that were monitoring those targets are switched over to the upgraded Enterprise Manager system using Oracle Management Agent 12c.

To view a list of targets that are currently inactive in the upgraded Enterprise Manager system, follow these steps:

1. In Cloud Control, from the Setup menu, select Manage Cloud Control and then, click Post Upgrade Tasks.

2. On the Post Upgrade Tasks page, click the Targets with Pending Activation tab.

3. In this tab, you can view a list of inactive targets.
To search for targets of your choice, enter a keyword or a part of the target name (or target type) in the search text box placed right above the Target Name column (or Target Type column).

Alternatively, you can click the links in the Refine Search pane to filter the table and list the targets of your choice.

Note:
To convert these inactive targets to active targets, switch over the Management Agents that are monitoring these targets in the existing Enterprise Manager system to the upgraded Enterprise Manager system. For information about switching over the Management Agents, see Switching Over to Oracle Management Agent 12c.

Signing Off Agent Migration Process

Note:
This section is applicable only for 1-system upgrade, 2-system upgrade, and 1-system upgrade on a different host for 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) of Enterprise Manager system.

After you switch over the Oracle Management Agents (Management Agent) to the Enterprise Manager Cloud Control, you can deinstall the earlier release of Management Agents. Instead of manually deinstalling the Management Agents, you can formally sign off the Agent Migration Process for each of the Management Agents and have the Post Upgrade Console automatically deinstall them for you.

To sign off the Agent Migration process for each of the Management Agents, follow these steps:

1. In Cloud Control, from the Setup menu, select Manage Cloud Control and then, click Post Upgrade Tasks.

2. On the Post Upgrade Tasks page, click the Sign Off tab.

3. In this page, you can do the following:

- To search Management Agents for which you have signed off the Agent Migration process, for which you are yet to sign off, or for which you are in the process of signing off, do the following:
(i) From the Search Criteria list, select an appropriate option.

(ii) In the Agent field, enter the name of the Management Agent. You can leave this blank if you want to search all Management Agents with a particular sign-off status. Alternatively, you can enter a part of the name and use wildcards to search for Management Agents with a similar name.

(iii) Click Search.

Note:
If you have not run the accrued data migration job for a Management Agent, then you cannot search and sign off that Management Agent. You will not find that Management agent even if you try searching for it using the search conditions.

- To select Management Agents and formally sign off the Agent Migration process for each of them, do the following:
(i) In the table, select the Management Agents you want to sign off. To select all the Management Agents, select Select All.

(ii) Click Sign Off Migration.

(iii) Provide credentials to access the hosts on which the selected Management Agents were running.

(iv) Click OK.

Note:
Once you sign off, the selected old Management Agents will automatically be deinstalled and removed, and they cannot be recovered in any way. Therefore, before you sign off, ensure that your Management Agents have switched over successfully and they are fully functional, and their targets are successfully being monitored in Enterprise Manager Cloud Control.

- To hide or unhide the table columns, from the View list, select an appropriate option.

- To detach the table from the screen, click Detach.

Updating Incident Rules

During upgrade, all Notification Rules created in the earlier release of Enterprise Manager are automatically migrated to corresponding Incident Rulesets that act on the targets originally defined in the Notification Rule. For more information about Incident Rulesets, see Appendix B.

However, for situations where the target type modeling has changed in Enterprise Manager Cloud Control, you must manually adjust the rules. This appendix describes how you can manually adjust the rulesets.

In particular, it covers the following:

- Why Update Incident Rules

- Updating Incident Rules for Moved Metrics

- Updating Incident Rules for Renamed Metrics

- Deleting Incident Rules

Why Update Incident Rules

In the earlier releases of Enterprise Manager, OMS and Repository was a common target type defined for all the OMS instances in your environment. And the metrics collected for the different OMS instances were shown within this common target type.

However, in Enterprise Manager Cloud Control, in addition to the target type OMS and Repository, a new target type Oracle Management Service has been introduced to represent each of the OMS instances in your environment. Therefore, if you have five OMS instances in your environment, you will see one target type OMS and Repository and five instances of the target type Oracle Management Service - one for each OMS.

While the target type OMS and Repository captures metrics that are common to all the OMS instances in your environment, the target type Oracle Management Service captures metrics specific to an OMS.

Table 11-2 lists the metrics and describes the changes done to them due to the introduction of a new target type Oracle Management Service, and the actions you must take for each change.

Table 11-2 Changes to Metrics and Updates to Be Done

Change Type

Change Description

Affected Metrics

Action to Be Taken by You

Retained

Some metrics have been retained for the same target type —OMS and Repository.

The following metrics havebeen retained:

- Collections Waiting To Run

- DBMS Job Invalid Schedule

- DBMS Job Processing Time (% of Last Hour)

- DBMS Job UpDown

- Dequeue Status

- Enqueue Status

- Job Step Backlog

- Notification UpDown

- Number of Active Agents

- Overall Files Pending Load - Agent

- Overall Rows Processed by Loader in the Last Hour

- Number of Agent Restarts

- Target Addition Rate (Last Hour)

- User Addition Rate (Last Hour)

No changes required.

Moved

Some metrics have been moved to the individual target type—Oracle Management Service.

The following metrics havebeen moved:

- Loader Throughput (rows per second)

- Total Loader Runtime in the Last Hour (seconds)

- Management Service Status

- Job Dispatcher Processing Time, (% of Last Hour)

- Service Status

- Repository Session Count
[Note: This metric has moved under the child targets OMS Console and OMS Platform]

Set up new incident rules to respond to the metrics that have been moved to different target types.

See Updating Incident Rules for Moved Metrics

Renamed

Some metrics have been renamed for easy undersanding.

The following metrics havebeen renamed:

- Average Notification Delivery Time (ms) Per Method [Renamed to Average Notification Time (seconds)]

- Notifications Waiting [Renamed to Pending Notifications Count]

Update the incident rules set to the metrics that have been renamed.

See Updating Incident Rules for Renamed Metrics

Decommissioned

Some metrics have been decommissioned due to lack of support in Enterprise Manager Cloud Control.

The following metrics have been decommissioned:

- Number of Duplicate Targets

- Notification Processing Time (% of Last Hour)

- Overall Files Pending Load - Loader

- Notifications Waiting
(Note: This is different from the Notifications Waiting metric that is renamed. This one does not have objects, while the one renamed has objects.)

Remove decommissioned metrics from the incident rules.

See Deleting Incident Rules

Updating Incident Rules for Moved Metrics

To update the incident rules set to the metrics that have been moved to the individual target type Oracle Management Service in Enterprise Manager Cloud Control, follow these steps:

1. In Cloud Control, from the Setup menu, select Incidents, and then, click Incident Rules.

2. On the Incident Rules page, from the table, select an incident rule created for Oracle Management Service (OMS), click Edit.

3. On the Edit Rule Set page, in the Rules tab, select the event rule that operates on the moved metrics, and click Edit.
Enterprise Manager displays the Edit Rule Wizard where you can edit the incident rule for the selected incident rule set.

4. In the Edit Rule Wizard, do the following:

1. On the Select Events page, select the metrics listed in the second row of Table 11-2, and click Remove.

2. Click Next.

3. On the Add Actions page and the Specify Name and Description page, click Next without making any change.

4. On the Review page, click Continue.

5. Click Save.
Enterprise Manager displays the Incident Rules page.

6. On the Incident Rules page, click Create Rule Set.

7. On the Create Rule Set page, enter a unique name for the rule set.

8. In the Targets tab, select All targets of types, and select Oracle Management Service.

9. In the Rules tab, click Create.

10. In the Select Type of Rule to Create dialog, select Event Rule, and click Continue.
Enterprise Manger displays the Create New Rule Wizard where you can create a new incident rule set.

11. In the Create New Rule Wizard, do the following:

1. On the Select Events page, from the Event Type list, select Metric Alert.

Note:
For the metric Management Service Status, select Target Availability from the Event Type list.

2. Select Specific metric alerts, and click Add.

3. In the Select Specific Metric Alert dialog, do the following:

1. In the Search region, from the Target Type list, select Oracle Management Service, and then, click Search.

2. From the table, select the moved metrics listed in the second row of Table 11-2.

3. In the Severity and Corrective Action Status region, from the Severity list, select an appropriate severity level.

4. Click OK.

4. Click Next.

5. On the Add Actions page and the Specify Name and Description page, click Next without making any change.

6. On the Review page, click Continue.

12. Click Save.
Enterprise Manager displays the Incident Rules page.

Note:
Repeat the procedure for all other incident rules created for the OMS.

Updating Incident Rules for Renamed Metrics

To update the incident rules set to the metrics that have been renamed in Enterprise Manager Cloud Control, follow these steps:

1. In Cloud Control, from the Setup menu, select Incidents, and then, click Incident Rules.

2. On the Incident Rules page, from the table, select an incident rule created for Oracle Management Service (OMS), click Edit.

3. On the Edit Rule Set page, in the Rules tab, select the event rule that operates on the renamed metrics, and click Edit.
Enterprise Manager displays the Edit Rule Wizard where you can edit the incident rule for the selected incident rule set.

4. In the Edit Rule Wizard, do the following:

1. On the Select Events page, select the metrics listed in the third row of Table 11-2, and click Remove.

2. Click Add.

3. In the Select Specific Metric Alert dialog, do the following:

1. In the Search region, from the Target Type list, select OMS and Repository, and then, click Search.

2. From the table, select the renamed metrics listed in the third row of Table 11-2.

3. In the Severity and Corrective Action Status region, from the Severity list, select an appropriate severity level.

4. Click OK.

4. Click Next.

5. On the Add Actions page and the Specify Name and Description page, click Next without making any change.

6. On the Review page, click Continue.

Note:
Repeat the procedure for all other incident rules created for the OMS.

Deleting Incident Rules

To remove the decommissioned metrics from the the incident rules, follow these steps:

1. In Cloud Control, from the Setup menu, select Incidents, and then, click Incident Rules.

2. On the Incident Rules page, from the table, select an incident rule created for Oracle Management Service (OMS), click Edit.

3. On the Edit Rule Set page, in the Rules tab, select the rule Metric Alerts Event Rule, and click Edit.
Enterprise Manager displays the Edit Rule Wizard where you can edit the incident rule for the selected incident rule set.

4. In the Edit Rule Wizard, do the following:

1. On the Select Events page, select the metrics listed in the last row of Table 11-2, and click Remove.

2. Click Next.

3. On the Add Actions page and the Specify Name and Description page, click Next without making any change.

4. On the Review page, click Continue.

Note:
Repeat the procedure for all other incident rules created for the OMS.

Part IV

Appendixes

This part contains the following appendixes:

- Appendix A, "Editing Response File for Upgrading OMS and Management Repository in Silent Mode"

- Appendix B, "Overview of Notification in Enterprise Manager Cloud Control"

- Appendix C, "Overview of Metric Changes in Enterprise Manager Cloud Control"

- Appendix D, "Identifying Jobs That Will Not Run in the Enterprise Manager for 2-System Upgrade Approach"

- Appendix E, "Meeting Prerequisites for Installing Oracle Management Agent"

- Appendix F, "Updating Server Load Balancer Configuration Settings"

- Appendix G, "Setting Preferred Credentials Using EM CLI"

- Appendix H, "Searching and Adding Oracle Management Agents"

- Appendix I, "Securing Oracle Management Agents After Backing Up Oracle Management Repository"

- Appendix J, "Recovering Database 11.1.0.7/10.2.0.5 from Microsoft Windows 32 to Microsoft Windows 64"

- Appendix K, "Deleting Unwanted Oracle Management Agents"

- Appendix L, "Deleting Old OMS Home"

A Editing Response File for Upgrading OMS and Management Repository in Silent Mode

Table A-1 describes what variables you must update and how you must update them in the upgrade.rsp response file for upgrading your OMS and Management Repository in silent mode.

Table A-1 Editing Response File for Upgrading OMS and Management Repository in Silent Mode

Variable

Description

UNIX_GROUP_NAME

(Required only when central inventory does not exist) Enter the name of the UNIX group you belong to.

For example, "dba"

INVENTORY_LOCATION

(Required only when central inventory does not exist) Enter the absolute path to the Central Inventory.

For example, /scratch/oracle/oraInventory

SECURITY_UPDATES_VIA_MYORACLESUPPORT

- Enter true if you want to download and install security updates. Then, enter the credentials for the following variables:
MYORACLESUPPORT_USERNAME

MYORACLESUPPORT_PASSWORD

- Enter false if you do not want to download and install security updates:

Important: If you are performing a software-only upgrade, then comment out this variable.

DECLINE_SECURITY_UPDATES

- Enter true if you want to decline the security updates. In this case, you should have entered FALSE for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

- Enter false if you do not want to decline the security updates. In this case, you should have entered TRUE for SECURITY_UPDATES_VIA_MYORACLESUPPORT.

Important: If you are performing a software-only upgrade, then comment out this variable.

INSTALL_UPDATES_SELECTION

By default, this variable is set to "skip" indicating that the software updates will not be installed during installation.

- If you want to install the software updates from My Oracle Support, then set this variable to "download". Then, enter the credentials for the following variables:
MYORACLESUPPORT_USERNAME_FOR_SOFTWAREUPDATES

MYORACLESUPPORT_PASSWORD_FOR_SOFTWAREUPDATES

- If you want to install the software updates from a staged location, then set this variable to "staged". Then, for the STAGE_LOCATION variable, enter the absolute path, which leads to the Updates directory, where the software updates are available.

Important: If you are performing a software-only upgrade, then comment out this variable.

ORACLE_MIDDLEWARE_HOME_LOCATION

Upgrade to 12c Release 2 (12.1.0.2) is an out-of-place upgrade, therefore you must specify an existing middleware home or enter a new middleware home where Oracle WebLogic Server and Java Development Kit are installed.

Enter the location where you have installed Oracle WebLogic Server 11g Release 1 (10.3.5) and Java Development Kit 1.6 v24. If you do not already have them installed, then enter the location where you want the installer to install them.

For example, u01/app/Oracle/Middleware.

Ensure that the middleware location has write permission.

If you have already installed them manually, then enter the location where you have installed them.

Note: Ensure that the Middleware home you enter here is used only for Enterprise Manager Cloud Control. Ensure that no other Oracle Fusion Middleware products or components are installed in the same Middleware home.

Important: If you are performing a software-only upgrade, then comment out this variable.

ORACLE_INSTANCE_HOME_LOCATION

By default, gc_inst is considered as the OMS Instance Base directory for storing all OMS-related configuration files, and by default, it is created in the Middleware home.

- To accept the default location and the directory name, then leave it blank.

- To have a custom location and a custom directory name, then enter the absolute path to the custom location leading up to the custom directory name.

OLD_BASE_DIR

(Applicable only for 1-system upgrade)

Enter the base directory of the OMS you want to upgrade.

Important: If you are performing a 2-system upgrade, then comment out this variable.

ORACLE_HOSTNAME

(Applicable only for 2-system upgrade)

By default, the fully qualified name of the host on which you have invoked the installer, is considered.

- To accept the default value, leave it blank.

- To install with a different host name, then enter another host name.

Important: If you are performing a 1-system upgrade, then comment out this variable.

ONE_SYSTEM

By default, this variable is set to true, which indicates that you are performing a 1-system upgrade.

- If you are indeed performing a 1-system upgrade, retain this value.

- If you are performing a 2-system upgrade, then set it to false.

AGENT_BASE_DIR

(Applicable only for 2-system upgrade)

Enter the absolute path to the agent base directory, a location outside the Oracle Middleware home where the Management Agent can be installed.

For example, u01/app/software/agent. Ensure that this location is empty and has write permission. Also ensure that it is always maintained outside the Oracle Middleware home.

Important: If you are performing a 1-system upgrade, then comment out this variable.

OLD_DATABASE_CONNECTION_DESCRIPTION

(Applicable only for 2-system upgrade)

By default, the connect string of the old Management Repository you entered in the Preupgrade Console is considered. However, if you had not entered there, then you can enter here in the following format:

- To connect using SID, enter the connect string in the following forma:
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SID=<sid>)))

For example,

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SID=emrep)))

- To connect using the service name, enter the connect string in the following format:
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_name>)(PORT=<port>)))(CONNECT_DATA=(SERVICE_NAME=<service_name>)))

For example,

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=emrep)))

The connect string is used to connect to the old Management Repository, check for accrued data, and seamlessly transfer it to the upgraded Management Repository. Accrued data refers to the data that was uploaded to the old Management Repository from the time it was backed up till the time it was upgraded.

IMPORTANT: Verify the value set to the GLOBAL_NAMES parameter on both the databases.

- If the GLOBAL_NAMES parameter is set to FALSE on both the databases, then ensure that you do not change this value until the upgrade is complete, and all the Management Agents are switched over.

- If the GLOBAL_NAMES parameter is set to TRUE on even one of the databases, and if both the databases have the same value for the GLOBAL_NAME parameter, then change the value of the GLOBAL_NAME parameter set on the new, cloned database to a value that is different from the one set on the old database.

Important: If you are performing a 1-system upgrade, then comment out this variable.

OLD_DATABASE_SYSMAN_PASSWORD

(Applicable only for 2-system upgrade)

Enter the SYSMAN password of the old Management Repository.

The password is used to connect to the old Management Repository using the connect string entered either in the Preupgrade Console or in the previous variable; check for accrued data; and seamlessly transfer it to the upgraded Management Repository. Accrued data refers to the data that was uploaded to the old Management Repository from the time it was backed up till the time it was upgraded

Important: If you are performing a 1-system upgrade, then comment out this variable.

WLS_ADMIN_SERVER_USERNAME

(Applicable only for 1-system upgrade of 10g Release 5 (10.2.0.5), and 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1))

By default, weblogic is the name assigned to the default user account that is created for the Oracle WebLogic Domain.

- To accept the default name, leave this variable blank.

- To have a custom name, then enter the name of your choice.

Important: If you are performing a 1-system upgrade of 11g Release 1 (11.1.0.1) or 12c Release 1 (12.1.0.1), or if you are upgrading an additional OMS from 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1), or 12c Release 1 (12.1.0.1), then comment out this variable.

WLS_ADMIN_SERVER_PASSWORD

(Applicable only for 1-system upgrade of 10g Release 5 (10.2.0.5), and 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1))

Enter a password for the WebLogic user account.

Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

Important: If you are performing a 1-system upgrade of 11g Release 1 (11.1.0.1) or 12c Release 1 (12.1.0.1), or if you are upgrading an additional OMS from 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1), or 12c Release 1 (12.1.0.1), then comment out this variable.

WLS_ADMIN_SERVER_CONFIRM_PASSWORD

(Applicable only for 1-system upgrade of 10g Release 5 (10.2.0.5), and 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1))

Confirm the password for the WebLogic user account.

Important: If you are performing a 1-system upgrade of 11g Release 1 (11.1.0.1) or 12c Release 1 (12.1.0.1), or if you are upgrading an additional OMS from 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1), or 12c Release 1 (12.1.0.1), then comment out this variable.

NODE_MANAGER_PASSWORD

(Applicable only for 1-system upgrade of 10g Release 5 (10.2.0.5), and 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1))

By default, nodemanager is the name assigned to the default user account that is created for the node manager. Enter a password for this node manager user account.

Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

Important: If you are performing a 1-system upgrade of 11g Release 1 (11.1.0.1) or 12c Release 1 (12.1.0.1), or if you are upgrading an additional OMS from 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1), or 12c Release 1 (12.1.0.1), then comment out this variable.

NODE_MANAGER_CONFIRM_PASSWORD

(Applicable only for 1-system upgrade of 10g Release 5 (10.2.0.5), 2-system upgrade of 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1))

Confirm the password for the node manager user account.

Important: If you are performing a 1-system upgrade of 11g Release 1 (11.1.0.1) or 12c Release 1 (12.1.0.1), or if you are upgrading an additional OMS from 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1), or 12c Release 1 (12.1.0.1), then comment out this variable.

WLS_ADMIN_SERVER_PASSWORD

(Applicable only for 1-system upgrade of 11g Release 1 (11.1.0.1) and 12c Release 1 (12.1.0.1))

Enter the password for the WebLogic user account you had created for the old Enterprise Manager system.

Important: If you are upgrading 10g Release 5 (10.2.0.5), or if you are upgrading an additional OMS from 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1), or 12c Release 1 (12.1.0.1), then comment out this variable.

ADMIN_SERVER_HOSTNAME

(Applicable only for 1-system upgrade)

Enter the host name of the AdminServer that is configured for the first OMS. This is required for creating a new WebLogic domain (GCDomain) for the upgraded OMS on the same host as the Admin Server used by the earlier release of the OMS you are upgrading.

Important: If you are upgrading the first OMS of 10g Release 5 (10.2.0.5), then comment out this variable.

ADMIN_SERVER_PORT

(Applicable only for 1-system upgrade)

Enter the port of the AdminServer that is configured for the first OMS. This is required for creating a new WebLogic domain (GCDomain) for the upgraded OMS on the same port as the Admin Server used by the earlier release of the OMS you are upgrading.

Important: If you are upgrading the first OMS of 10g Release 5 (10.2.0.5), then comment out this variable.

WLS_ADMIN_SERVER_USERNAME

(Applicable only for 1-system upgrade)

By default, weblogic is the name assigned to the default user account that is created for the Oracle WebLogic Domain.

- To accept the default name, then leave it blank.

- To have a custom name, then enter the name of your choice.

Important: If you are upgrading the first OMS of 10g Release 5 (10.2.0.5), then comment out this variable.

WLS_ADMIN_SERVER_PASSWORD

(Applicable only for 1-system upgrade)

Enter a password for the WebLogic user account.

Ensure that your password contains at least 8 characters without any spaces, begins with a letter, and includes at least one numeric value.

Important: If you are upgrading the first OMS of 10g Release 5 (10.2.0.5), then comment out this variable.

JVM_DIAGNOSTICS_TABLESPACE_LOCATION

(Applicable for 1-system upgrade and 2-system upgrade)

(Applicable only if you are upgrading 10g Release 5 (10.2.0.5))

During upgrade, an additional tablespace called JVM diagnostics data tablespace is created for storing all JVM-related monitoring data. Enter the absolute path to a location where the data file (mgmt_ad4j.dbf) for this tablespace can be stored. Ensure that the entered path leads up to the file name.

For example, /home/john/oradata/mgmt_ad4j.dbf

Important: If you are upgrading 11g Release 1 (11.1.0.1) or 12c Release 1 (12.1.0.1), then comment out this variable.

DATABASE_HOSTNAME

(Applicable only for 2-system upgrade)

Enter the fully qualified name of the host where the existing database resides.

For example, example.com

If you are connecting to an Oracle RAC Database, and if the nodes have virtual host names, then enter the virtual host name of one of its nodes.

The connection to the database is established with a connect string that is formed using only this virtual host name, and the installation ends successfully.

However, if you want to update the connect string with other nodes of the cluster, then after the installation, do the following:

1. Open the following file:
<OMS_Instance_Home>/em/EMGC_OMS#/emgc.properties

2. Enter the other nodes for the variable EM_RESPOS_CONNECTDESCRIPTOR.

Important: If you are performing a 1-system upgrade, then comment out this variable.

LISTENER_PORT

(Applicable only for 2-system upgrade)

Enter the listener port to connect to the existing database.

For example, 1532

Important: If you are performing a 1-system upgrade, then comment out this variable.

SERVICENAME_OR_SID

(Applicable only for 2-system upgrade)

Enter the service name or the system ID (SID) of the existing database.

For example, orcl

Important: If you are performing a 1-system upgrade, then comment out this variable.

SYS_PASSWORD

Enter the SYS user account's password.

SYSMAN_PASSWORD

Enter the SYSMAN user account's password.

PLUGIN_SELECTION

By default, mandatory plug-ins such as Oracle Database Management Plug-In, Oracle Fusion Middleware Management Plug-In, Oracle My Oracle Support Management Plug-In, and Oracle Exadata Management Plug-In get automatically installed when you upgrade your Enterprise Manager.

However, if you want to install any of the other optional plug-ins that are available in the software kit (DVD or downloaded software), then enter the names of those plug-ins for this variable. The plug-ins are available in the Disk1/plugins directory.

For example,

If you want to install 12.1.0.2.0_oracle.sysman.empa_2000_0.opar and 12.1.0.2.0_oracle.sysman.vt_2000_0.opar, then enter the plug-in IDs in the following way:

PLUGIN_SELECTION={"oracle.sysman.empa","oracle.sysman.vt"}

If you want to install any plug-in that is not available in the software kit, then do the following:

1. Manually download the plug-ins from the following URL, and store them in an accessible location.
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html

2. Update this variable (PLUGIN_SELECTION) to the names of those plug-ins you downloaded.

3. Invoke the installer with the following option, and pass the location where you downloaded the plug-ins:
./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

You might have a plug-in version deployed to the earlier release of Enterprise Manager that is not supported in Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), for example, EBS 2.0 and 3.0 plug-in versions. In this case, when you invoke the installer with -pluginLocation argument, make sure you do NOT provide the software of the higher version of the unsupported plug-in even if the higher version is available for download. This ensures that the unsupported version is removed while upgrading to 12c Release 2 (12.1.0.2). After you upgrade, you can deploy the higher version directly from the Plug-In Manager.

B Overview of Notification in Enterprise Manager Cloud Control

Note:
This appendix is applicable only if you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1).

Prior to Enterprise Manager Cloud Control, the notification system notified administrators of target availability status changes, metric alerts, and status changes of job executions. In addition to notifying the administrators, the notification system performed actions such as running operating system commands, including scripts, and PL/SQL procedures when an alert was triggered.

This appendix describes how the notification system has changed significantly in Enterprise Manager Cloud Control. In particular, this appendix covers the following:

- Understanding Events, Incidents, and Incident Rulesets

- Accessing Incident Rulesets

- Migrating Notification Rules to Incident Rulesets

- Working with Notification Methods and Actions

Understanding Events, Incidents, and Incident Rulesets

In the earlier releases of Enterprise Manager, the notification system operated using Notification Rules, which were a set of predetermined rules or conditions indicating when a notification had to be sent and what actions had to be taken.

In Enterprise Manager Cloud Control, this concept of Notification Rules has been enhanced and subsumed into a much larger and newer concept called Incident Rulesets.

Before discussing Incident Rulesets, understand the concept of Events and Incidents.

- Events are significant and interesting occurrences in your managed environment. Target availability status changes, metric alerts, and status changes of job executions are examples of the types of events that Enterprise Manager detects. Users may be interested in getting notified about these events and responding accordingly to resolve the underlying issues. By formalizing the concept of events, Enterprise Manager extends the monitoring functionality to additional occurrences in the enterprise that might be of interest, such as metric evaluation errors or compliance standard violations.

- Incidents are a subset of related events that may indicate potential or actual disruption to the dependent IT services, and require attention from an administrator or a team. Incidents can be created for such events, which can then be assigned to an administrator and tracked to completion.

Incident Ruleset is a set of rules that typically operate on a set of targets, and include individual rules to notify appropriate personnel and take appropriate action on events, incidents, and problems.

Note:
For information about the problems, refer to the Oracle Enterprise Manager Administrator's and User's Guide available in the Enterprise Manager documentation library at:
http://www.oracle.com/technetwork/indexes/documentation/index.html

A rule can operate on events to send notifications as well as create incidents. It can also operate on specific incidents, so you can auto-assign, prioritize, or even escalate them via time-based conditions.

Incident Rulesets are further classified into enterprise and private rulesets.

- Enterprise Rulesets are used to automate and enforce enterprise level behavior such as notifying one or more users, sending notifications using advanced notification methods, raising tickets in external ticketing systems, creating and updating incidents. Only administrators with the Create Enterprise Ruleset privilege can create these rulesets.

- Private Rulesets are useful for administrators to e-mail themselves about specific changes. They can be created by any administrator and can only be used to send e-mails to the owner of the ruleset.

All Incident Rulesets can be edited by the owner of the ruleset and any super administrator. In addition, the owners can designate other users as coauthors of Enterprise Rulesets. This enables shared management of the ruleset.

Accessing Incident Rulesets

To view all Incident Rulesets, in Enterprise Manager Cloud Control, from the Setup menu, click Incidents, and then, select Incident Rules. Figure B-1 shows the Incident Ruleset page:

Figure B-1 Viewing Incident Rulesets

Migrating Notification Rules to Incident Rulesets

During upgrade, all Notification Rules created in the earlier release of Enterprise Manager are automatically migrated to corresponding Incident Rulesets that act on the targets originally defined in the Notification Rule.

The following Notification Rules are migrated to Enterprise Rulesets:

- Notification Rules that send e-mails to owners who have not created the rules

- Notification Rules that invoke an advanced notification method

The following Notification Rules are migrated to Private Rulesets:

- Notification Rules that have no actions.

- Notification Rules that send e-mails to owners who have created the rules.

Each of the three possible criteria—availability, metrics, jobs—defined in an old Notification Rule are migrated to three individual rules that operate on appropriate events. The action defined at the Notification Rule level is copied over to each of these rules.

One exception is that the concept of Policy Violations is being withdrawn in Enterprise Manager Cloud Control, and therefore, all policy-specific criteria are ignored and none of the rules that solely operate on policies are migrated.

The owners of Notification Rules, which were created in the earlier release of Enterprise Manager, become the owners of the corresponding Incident Rulesets in Enterprise Manager Cloud Control. These owners can edit the Enterprise Rulesets and Private Rulesets. In addition, all administrators can create Private Rulesets to send e-mails to themselves.

Going forward, the super administrators should determine which administrators can create Enterprise Rulesets by granting the Create Enterprise Ruleset resource privilege.

Note:
For situations where the target type modeling has changed in Enterprise Manager Cloud Control, you must manually adjust the rules as described in Updating Incident Rules.

Working with Notification Methods and Actions

Notification methods and actions defined in earlier releases of Enterprise Manager will continue to work in Enterprise Manager Cloud Control, and the input to these original notification methods are backward compatible in Enterprise Manager Cloud Control. So if you had an OS command or a PL/SQL notification method that operated on metric alerts, you will continue to receive the same input after upgrade. However, all new notification methods you create in Enterprise Manager Cloud Control will accept input based on the new event and incident model.

Note:
Oracle strongly recommends you to replace the Notification Methods created in the earlier releases of Enterprise Manager with the new Enterprise Manager Cloud Control-specific notification methods that operate on the new event model. With the next major release of Enterprise Manager Cloud Control, the older notification methods will no longer function.

C Overview of Metric Changes in Enterprise Manager Cloud Control

This appendix describes the changes to the metrics of the following targets:

- Oracle SOA Infrastructure

- Oracle SOA Composite

- Oracle Service Bus

- Oracle WebLogic Server

- JBoss Application Server

- Siebel Enterprise

- Siebel Server

Oracle SOA Infrastructure

The following are the changes to the metrics related to Oracle SOA Infrastructure:

- The old metric SOA Infrastructure - Service Engine Detail Metrics appears on the All Metrics page to show historical data. However, there is no further collection for this metric.

- The new metric SOA Infrastructure - Service Engine Detail Metrics has now moved under the target component type SOA Infrastructure Engine.

- In addition, the following metrics have been introduced:

- Top SOA SQL Queries

- Dehydration Store Tables

- In the Preupgrade Console, when you generate a health report, you might see metric collection errors for the new metrics. You can ignore these errors and proceed further. However, ensure that you provide the database credentials for this target as described in Chapter 11.

Oracle SOA Composite

The following are the changes to the metrics related to Oracle SOA Composite:

- The old metrics SOA Composite - Component Detail Metrics and SOA Composite - Services/References Detail Metrics appear on the All Metrics page to show historical data. However, there is no further collection for this metric.

- The new metric SOA Composite - Component Detail Metrics has now moved under the target component type SOA Composite Component.

- The new metric SOA Composite - Services/References Detail Metrics has now been divided into the following metrics:

- SOA Composite Service Metric that appears under the target component type SOA Composite Service.

- SOA Composite Reference Metric that appears under the target component type SOA Composite Reference.

Oracle Service Bus

- The old metric OSB Service Metrics appears on the All Metrics page to show historical data. However, there is no further collection for this metric.

- The new metric OSB Service Metrics has now been divided into the following metrics:

- OSB Proxy Service Metrics that appears under the target component type OSB Proxy Service.

- OSB Business Service Metrics that appears under the target component type OSB Business Service.

Oracle WebLogic Server

- The following configuration metrics are collected for the J2EE Application target, and not for the Oracle WebLogic Server target.

- General

- Web Services

- Web Service Ports

- JRF Web Services

- JRF Web Services Ports

- JRF Web Services Operations

- JRF Web Services Policy References

- Web Modules

- EJB Modules

- The following configuration metrics are available for Oracle WebLogic Server version 7, 8, and 9 and higher:

- General

- Web Modules

- EJB Modules

- The following configuration metrics are available for Oracle WebLogic Server version 9 and higher:

- Web Services

- Web Service Ports

- The configuration metric JDBC Datasource is now available for all Oracle WebLogic Server targets.

- The data for JDBC Multi Datasource was earlier collected by the metric JDBC Datasource. Now the data is collected by the metric JDBC Multi Datasource.

- The data for JDBC Connection Pool was earlier collected by the metric JDBC Connection Pool. However, this metric is no longer available. All the data collected by that metric has now been moved to the metric JDBC Datasource.

These are configuration metrics, and therefore, they do not appear on the All Metrics page. Instead, they appear on the Last Collected page of the J2EE application.

JBoss Application Server

In the earlier releases of Enterprise Manager, for monitoring JBoss Application Server, the Management Agent required some JAR files listed in the following file of the agent home:

$<AGENT_HOME>/sysman/config/classpath.lst

This file was populated during discovery, and the Management Agent had to restart to honor the JAR files location and append to its classpath.

In Enterprise Manager Cloud Control, the classpath.lst file is not used because there is a dynamic classloader that loads the classes specific to the target after discovery. So the Management Agent need not restart.

There is a new target instance property Library Path that is added to the target metadata. This property is needed by the monitoring logic to differentiate between the case of local and remote monitoring (target monitored by a local or remote agent).

In the case of local monitoring, this property is null.

In the case of remote monitoring, this property is set to the library path location you provide during discovery, which contains the JAR files required for discovering and monitoring JBoss.

During upgrade, ignore this error.

After upgrade, the monitored target status shows as down and no metrics are collected. So set the Library path instance property on the Monitoring Configuration page of the target. Set it to the JAR files location.

Siebel Enterprise

All the metrics available for Siebel Enterprise target have been moved to Siebel Gateway target in Enterprise Manager Cloud Control. As a result, to view the ECM metrics, access the Siebel Gateway target.

Siebel Server

In the earlier releases of Enterprise Manager, for SARM reports, event log, server process control, and workflow processes, you were required to set only the preferred credentials of the hosts on which Siebel Server and Siebel Gateway Server were running. However, in Enterprise Manager Cloud Control, for these features, you must set several other credentials, besides the host credentials. This section describes the different credentials you must set for various Siebel target types.

This section covers the following:

- Setting Preferred Credentials for Siebel Server

- Setting Preferred Credentials for Siebel Gateway Server

- Setting Preferred Credentials for Siebel Database Repository

Setting Preferred Credentials for Siebel Server

For Siebel Server, set the following credentials:

Host Preferred Credentials

To do so, in Cloud Control, from the Setup menu, select Security, and then, click Preferred Credentials. On the Preferred Credentials page, select Host and click Manage Preferred Credentials. On the Host Preferred Credentials page, set the operating system credentials of the host on which the Siebel Server is running.

Host Credentials for Siebel Server

To do so, in Cloud Control, from the Setup menu, select Security, and then, click Preferred Credentials. On the Preferred Credentials page, select Siebel Server and click Manage Preferred Credentials. On the Siebel Server Preferred Credentials page, in the Target Preferred Credentials section, select the credential set Host Credentials, and click Set to set the operating system credentials of the host on which the Siebel Server is running.

Server Manager Credentials for Siebel Server

To do so, in Cloud Control, from the Setup menu, select Security, and then, click Preferred Credentials. On the Preferred Credentials page, select Siebel Server and click Manage Preferred Credentials. On the Siebel Server Preferred Credentials page, in the Target Preferred Credentials section, select the credential set Server Manager Credentials, and click Set to set the server manager credentials.

Setting Preferred Credentials for Siebel Gateway Server

For Siebel Gateway Server, set the following credentials:

Host Preferred Credentials

To do so, in Cloud Control, from the Setup menu, select Security, and then, click Preferred Credentials. On the Preferred Credentials page, select Host and click Manage Preferred Credentials. On the Host Preferred Credentials page, set the operating system credentials of the host on which the Siebel Gateway Server is running.

Host Credentials for Siebel Gateway Server

To do so, in Cloud Control, from the Setup menu, select Security, and then, click Preferred Credentials. On the Preferred Credentials page, select Siebel Gateway Server and click Manage Preferred Credentials. On the Siebel Gateway Server Preferred Credentials page, in the Target Preferred Credentials section, select the credential set Host Credentials, and click Set to set the operating system credentials of the host on which the Siebel Gateway Server is running.

Server Manager Credentials for Siebel Gateway Server

To do so, in Cloud Control, from the Setup menu, select Security, and then, click Preferred Credentials. On the Preferred Credentials page, select Siebel Gateway Server and click Manage Preferred Credentials. On the Siebel Gateway Server Preferred Credentials page, in the Target Preferred Credentials section, select the credential set Manage Preferred Credentials, and click Set to set the server manager credentials.

Setting Preferred Credentials for Siebel Database Repository

For Siebel Database Repository, set the Siebel DBStore Credentials.

To do so, in Cloud Control, from the Setup menu, select Security, and then, click Preferred Credentials. On the Preferred Credentials page, select Siebel Database Repository and click Manage Preferred Credentials. On the Siebel Database Repository Preferred Credentials page, in the Target Preferred Credentials section, select the credential set Siebel DBStore Credentials, and click Set to set the credentials.

D Identifying Jobs That Will Not Run in the Enterprise Manager for 2-System Upgrade Approach

This appendix describes how you can identify the jobs that will not run in the existing Enterprise Manager system and in the upgraded Enterprise Manager system.

- Identifying Jobs That Will Not Run in the New, Upgraded Enterprise Manager System

- Identifying Jobs That Will Not Run in the Existing Enterprise Manager System

Identifying Jobs That Will Not Run in the New, Upgraded Enterprise Manager System

The following SQL query will help identify any jobs that are currently blocked from running if only certain Oracle Management Agents for their targets are migrated. Run the query in Enterprise Manager Cloud Control.At the end of the query, is an optional query for modifications that can be used to give a list of Oracle Management Agents that need to be migrated.

For more information on the need for identifying jobs that will not run in the upgraded or new Enterprise Manager System, refer to Chapter 2, "Things to Know"

SET TRIMSPOOL ON
SET VERIFY   OFF
SET LINESIZE  80
SET PAGESIZE 500

PROMPT ======================
PROMPT Valid on "new" 12.1 EM
PROMPT ======================
PROMPT List jobs that will not be run on either system
PROMPT due to a partially migrated target list
PROMPT ======================

WITH
-- list of migrated targets
migrated_targets AS
(
SELECT   target_guid
FROM     EM_CURRENT_AVAILABILITY
WHERE    current_status     = 4 -- G_STATUS_UNREACHABLE
AND      current_sub_status = 1 -- G_SUB_STATUS_UNMIGRATED
),
-- list of job related migrated targets
migrate_job_targets AS
(
SELECT   job_id, execution_id, target_guid
FROM     MGMT$JOB_EXECUTION_HISTORY JOIN
migrated_targets           USING(target_guid)
WHERE    STATE_CYCLE NOT IN ('FINISHED', 'RUNNING')
),
-- list of jobs against the migrate job targets
effected_jobs AS
(
SELECT  count(1) migrated_target_count, job_id, execution_id
FROM    migrate_job_targets
GROUP BY job_id, execution_id
),
-- list of jobs with some unmigrated targets and some migrate targets
partly_migrated_jobs AS
(
SELECT je.job_id,
je.execution_id,
je.job_name,
je.job_owner,
je.job_type,
je.target_name,
je.target_type,
je.target_guid
FROM   MGMT$JOB_EXECUTION_HISTORY je,
effected_jobs              ej
WHERE  je.job_id       = ej.job_id
AND    je.execution_id = ej.execution_id
AND    target_guid     NOT IN
( SELECT target_guid
FROM   migrate_job_targets
)
)
-- list jobs, targets and agents
SELECT job_name, target_name, target_type
FROM   partly_migrated_jobs
ORDER BY job_name, target_type, target_name;

/*
Could change the last select to
SELECT DISTINCT job_name, job_owner
or
SELECT DISTINCT target_guid

to get the distinct list of jobs or target guids.

or
SELECT DISTINCT emd_url
FROM   partly_migrated_jobs JOIN
MGMT_TARGETS         USING (target_guid)

to get the distinct list of agents
*/

Identifying Jobs That Will Not Run in the Existing Enterprise Manager System

The following SQL query will help identify any jobs that are currently blocked from running if only certain Oracle Management Agents for their targets are migrated. Run the query in Enterprise Manager Cloud Control.At the end of the query, is an optional query for modifications that can be used to give a list of Oracle Management Agents that need to be migrated.

For more information on the need for identifying jobs that will not run in the existing Enterprise Manager System, refer to Chapter 2, "Things to Know"

SET TRIMSPOOL ON
SET VERIFY   OFF
SET LINESIZE  80
SET PAGESIZE 500

PROMPT ======================
PROMPT Valid on "original" EM
PROMPT ======================
PROMPT List jobs that will not be run on either system
PROMPT due to a partially migrated target list
PROMPT ======================
PROMPT Enter a quoted, comma separated list of agent guids about to be
migrated
PROMPT OR any quoted character to list currently stuck jobs
PROMPT ======================

WITH
-- list of targets the user is about to migrate
migrating_targets AS
(
SELECT   target_name, target_type, target_guid
FROM     MGMT_TARGETS t
WHERE    t.emd_url IN ( SELECT emd_url
FROM   MGMT_TARGETS
WHERE  target_guid IN (&p_agent_guid_list)
AND    target_type = 'oracle_emd') --MGMT_GLOBAL.G_AGENT_TARGET_TYPE )
),
-- list of already migrated targets
migrated_targets AS
(
SELECT   target_name, target_type, target_guid
FROM     PRE_UPGC_TGT_SW
WHERE    STATUS  =  'AVAILABLE'
-- NOTE: neither system will monitor targets <> 'AVAILABLE'
--       How to treat them here?
--       For now, treat them as unmigrated
AND      emd_url IN ( SELECT emd_url
FROM   PRE_UPGC_AGT_STAT_MGMT JOIN
MGMT_TARGETS           USING(target_guid)
WHERE  SWITCH_STATUS='STATUS_SUCCESS'
OR     SWITCH_STATUS='STATUS_IN_PROGRESS')
),
-- list of job related targets (either migrating or already migrated)
migrate_job_targets AS
(
SELECT   -- use DISTINCT to cover target overlap case
DISTINCT job_id, execution_id, target_guid
FROM     MGMT$JOB_EXECUTION_HISTORY JOIN
( SELECT target_guid FROM migrating_targets
UNION ALL
SELECT target_guid FROM migrated_targets
) USING(target_guid)
WHERE    status  NOT IN ('Error',
'Failed',
'Succeeded',
'Skipped',
'Stopped')
),
-- list of jobs against the migrate job targets
effected_jobs AS
(
SELECT  count(1) migrated_target_count, job_id, execution_id
FROM    migrate_job_targets
GROUP BY job_id, execution_id
),
-- list of jobs with some unmigrated targets and some migrate targets
partly_migrated_jobs AS
(
SELECT je.job_id,
je.execution_id,
je.job_name,
je.job_owner,
je.job_type,
je.target_name,
je.target_type,
je.target_guid
FROM   MGMT$JOB_EXECUTION_HISTORY je,
effected_jobs              ej
WHERE  je.job_id       = ej.job_id
AND    je.execution_id = ej.execution_id
AND    target_guid     NOT IN
( SELECT target_guid
FROM   migrate_job_targets
)
)
-- list jobs, targets and agents
SELECT job_name, target_name, target_type
FROM   partly_migrated_jobs
ORDER BY job_name, target_type, target_name;

/*
Could change the last select to
SELECT DISTINCT job_name, job_owner
or
SELECT DISTINCT target_guid

to get the distinct list of jobs or target guids.

or
SELECT DISTINCT emd_url
FROM   partly_migrated_jobs JOIN
MGMT_TARGETS         USING (target_guid)

to get the distinct list of agents
*/

/*
to test already migrated target part, do
update PRE_UPGC_AGT_STAT_MGMT set SWITCH_STATUS ='STATUS_SUCCESS' where target_guid = (select target_guid from mgmt_targets where target_type = 'oracle_emd' and emd_url = (select emd_url from mgmt_targets where target_name = 'db.us.oracle.com'));

but DO NOT COMMIT
rollback when done.
*/

E Meeting Prerequisites for Installing Oracle Management Agent

Table E-1 lists the prerequisites you must meet before installing Oracle Management Agent (Management Agent).

Table E-1 Prerequisites for Upgrading Oracle Management Agent

Requirement

Description

Hardware Requirements

Ensure that you meet the hard disk space and physical memory requirements. For more information, see the chapter on hardware requirements in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Operating System Requirements

Ensure that you install Enterprise Manager Cloud Control only on certified operating systems as mentioned in the Enterprise Manager Certification Matrix available on My Oracle Support.

To access this matrix, follow these steps:

1. Log in to My Oracle Support, and click the Certifications tab.

2. On the Certifications page, in the Certification Search region, from the Product list, select Enterprise Manager Base Platform - OMS.

3. From the Release list, select 12.1.0.2.0, and click Search.

Package Requirements

Ensure that you install all the operating system-specific packages. For more information, see the chapter on package requirements in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

User and Operating System Group Requirement

Ensure that the destination host where you want to install the Management Agent has the appropriate users and operating system groups created.

For more information, see the chapter on creating operating system groups and users in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Destination Host Requirements

Ensure that the destination hosts are accessible from the host where the Preupgrade Console is being used.

Permission Requirements

- Ensure that the installation base directory you specify is empty and has write permission.

- Ensure that the instance directory is empty and has write permission.

- Ensure that the installing user owns the agent base directory. Ensure that the installing user or the root user owns all the parent directories. Ensure that the root user owns the root directory. And ensure that all of these directories have read and execute permissions for group and other users.
For example, if the agent base directory is /scratch/OracleHomes/agent, and if oracle is the installing user, then the /scratch/OracleHomes/agent directory must be owned by oracle, directories scratch and OracleHomes must be owned by either oracle or root user, and the root directory (/) must be owned by root user. And directories /, scratch, and OracleHomes have read and execute permissions.

Path Validation Requirements

Validate the path to all command locations. For more information, see the appendix on validating command locations in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Temporary Directory Space Requirements

Ensure that you allocate 400 MB of space for a temporary directory where the executables can be copied.

By default, the temporary directory location set to the environment variable TMP or TEMP is honored. If both are set, then TEMP is honored. If none of them are set, then the following default values are honored: /tmp on UNIX hosts and c:\Temp on Microsoft Windows hosts.

Installing User Requirements

- If the central inventory owner and the user installing the Management Agent are different, then ensure that they are part of the same group.

- Also ensure that the inventory owner and the group to which the owner belongs have read and write permissions on the inventory directory.
For example, if the inventory owner is abc and the user installing the Management Agent is xyz, then ensure that abc and xyz belong to the same group, and they have read and write access to the inventory.

Central Inventory (oraInventory) Requirements

- Ensure that you allocate 100 MB of space for the Central Inventory.

- Ensure that the central inventory directory is not in a shared file system. If it is already in a shared file system, then create a new inventory in a non-shared file system. You can optionally migrate the products that were previously installed in the shared file system to this new inventory in the non-shared file system

- Ensure that you have read, write, and execute permissions on oraInventory on all remote hosts. If you do not have these permissions on the default inventory (typically at /etc/oraInst.loc) on any remote host, then ensure that you specify the path to an alternative inventory location by using one of the following options in the Additional Parameters field of the Add Host Targets Wizard:
INVENTORY_LOCATION=<absolute_path_to_inventory_directory>

-invPtrLoc <absolute_path_to_oraInst.loc>

Default SSH Port Requirements

Ensure that the SSH daemon is running on the default port (that is, 22) on all the destination hosts. To verify the port, run the following command.

netstat -anp | grep <port_no>

If the port is a non-default port, that is, any port other than 22, then update the SSH_PORT property in the following file that is present in the OMS home:

$<OMS_HOME>/oui/prov/resources/Paths.properties

Ping Requirements

If a firewall configured in your environment does not allow any ping traffic, then ensure that you do the following:

1. Access the following file from the OMS home:
For Linux Platforms:

$<OMS_HOME>/oui/prov/resources/sPaths.properties

For Other Platforms:

$<OMS_HOME>/oui/prov/resources/ssPaths_<platform>.properties

For example, ssPaths_aix.properties if the OMS is on AIX platform.

2. Change PING_PATH=/bin/ping to PING_PATH=/bin/true.

PATH Environment Variable Requirements

On the destination host, ensure the following:

- (For Microsoft Windows) Ensure that the Cygwin software location appears before other software locations in the PATH environment variable. After making it the first entry, restart the SSH daemon (sshd) on both the hosts.

- (For UNIX) Ensure that the SCP binaries (for example, /usr/local/bin/scp) are in the PATH environment variable.

F Updating Server Load Balancer Configuration Settings

If you have a Server Load Balancer (SLB) configured, make the changes described in Table F-1 to your monitors

Table F-1 SLB-Specific Changes to Monitors

Monitor Name

Configuration

Associated With

Type

Interval

Timeout

Send String

Receive String

mon_gcsu1159

https

60

181

GET /empbs/upload

Http Receiver Servlet active!

HostA:1159 HostB:1159

mon_gcar4889

http

60

181

GET /empbs/genwallet

GenWallet Servlet activated

HostA:4889 HostB:4889

mon_gcsc7799

https

5

16

GET /em/console/home HTTP/1.0\n

/em/login.jsp

HostA:7799 HostB:7788

mon_gcuc7788 (optional)

https

5

16

GET /em/console/home HTTP/1.0\n

/em/login.jsp

HostA:7788 HostB:7788

If you have SSO configured, then use the alternate definitions described in Table F-2 for the mon_gcsc7799 and mon_gcuc7788 monitors.

Table F-2 SLB-Specific Changes to Monitors with SSO Configured

Monitor Name

Configuration

Associated With

Type

Interval

Timeout

Send String

Receive String

mon_gcsc7799

https

5

16

GET /empbs/genwallet

GenWallet Servlet activated

HostA:7799 HostB:7788

mon_gcuc7788 (optional)

https

5

16

GET /empbs/genwallet

GenWallet Servlet activated

HostA:7788 HostB:7788

G Setting Preferred Credentials Using EM CLI

When you provide the agent credentials, you can choose to enter the preferred credentials registered with the Enterprise Manager system. However, ensure that the credentials were registered using EM CLI.

- To register the credentials as preferred credentials for one host at a time, run the following command on the host where the Management Agent is running:
emcli set_credential -target_type=host -target_name="<host_name>" -credential_set=OHCreds -column="OHUsername:<em_job_user>;OHPassword:<em_job_pwd>" -oracle_homes="<agent_home>"

For example,

emcli set_credential -target_type=host -target_name="example.com" -credential_set=OHCreds -column="OHUsername:myuser;OHPassword:2bornot2b" -oracle_homes="/home/john/programs/EM/agent10g"

- To register the credentials as default preferred credentials for all hosts at a time, run the following command on one of the hosts where the Management Agent is running. Ensure that the user is a shared user on all the hosts.
emcli set_credential -target_type=host -credential_set=OHCreds -column="OHUsername:<em_job_user>;OHPassword:<em_job_pwd>" -oracle_homes="<agent_home>"

For example,

emcli set_credential -target_type=host -credential_set=OHCreds -column="OHUsername:myuser;OHPassword:2bornot2b"

Note:
To run these commands, you must have the EM CLI Client installed on the hosts. If you do not have EM CLI, install one following the instructions outlined in Oracle Enterprise Manager Command Line Interface Guide.

H Searching and Adding Oracle Management Agents

To search and add Oracle Management Agents (Management Agent) on the Deploy and Configure Agents page, Generate Health Report of Deployed Agents page, and on the Switch Agents page, follow these steps:

- To search Management Agents, select the platform and the version of the Management Agents you are searching for, from the Platform and Version lists, respectively. Then, click Search.
Alternatively, if you know the name of the Management Agent, then enter the name in Agent, and click Search. If you have created a logical group of Management Agents in Enterprise Manager Grid Control, and if you want to list the Management Agents of that group, then from the Group list, select the name of that group, and click Search.

- The search results in a list of Management Agents discovered in your environment. If you do not want to deploy the software now for some of the Management Agents, then select those Management Agents and click Remove.

- In case the search result does not list the Management Agents you are searching for, then click Add and manually add the Management Agents of your choice.

- The Management Agent you have added might be part of multiple groups (an Enterprise Manager group), systems (an Enterprise Manager system), or clusters of Management Agents, or it might be associated with multiple shared Management Agents.
In such cases, if you want to select and add the Management Agents of all the groups and clusters, and also the associated shared Management Agents, then click Add Related Agents.

Note:
If you are adding a Shared Agent, then ensure that you add the Master Agent to which it communicates, and all the Shared Agents that communicate with this Master Agent.

I Securing Oracle Management Agents After Backing Up Oracle Management Repository

Before you deploy and configure Oracle Management Agents 12c (Management Agent) as described in Deploying and Configuring Oracle Management Agent, you must ensure that the old Management Agents remain in the same mode as they were before the Management Repository was backed up. In other words, if your old Management Agents were running in secure (or unsecure) mode before the Management Repository was backed up, then they must continue to run in the same mode while you deploy and configure the new Management Agents for them.

Do not resecure the Management Agents after backing up the Management Repository. If you do so, the ping test might fail while performing the healthcheck because of a mismatch between the configuration stored in the repository and the actual configuration of the Management Agent. You will see the following KEY_MISMATCH error in the gcagent.log file.

gcagent.log:2011-09-28 05:41:46,192 [82:B5BF5C12:GC.Executor.1 (Ping OMS)] WARN - Received response status KEY_MISMATCH
gcagent.log:2011-09-28 05:42:16,231 [89:D485F18E:GC.Executor.5 (Ping OMS)] WARN - Received response status KEY_MISMATCH
gcagent.log:2011-09-28 05:42:29,232 [1:3305B9] WARN - Received response status KEY_MISMATCH

If you still want to resecure the Management Agents for some reason, then follow these steps:

1. Disable the health check by running the following SQL query against the old Management Repository.

BEGIN PRE_UPG_UTL.set_param('bypass_hc', '1'); END;
/
commit;

2. Switch over the Management Agent as described in Switching Over to Oracle Management Agent 12c.

3. Secure the new Management Agents.
$<AGENT_INSTANCE_DIR>/bin/emctl secure agent

4. Start the new Management Agents.
$<AGENT_INSTANCE_DIR>/bin/emctl start agent

5. Enable the health check.

BEGIN PRE_UPG_UTL.set_param('bypass_hc', '0'); END;
/
commit;

J Recovering Database 11.1.0.7/10.2.0.5 from Microsoft Windows 32 to Microsoft Windows 64

This appendix is based on note:

How To Change Oracle 11g Wordsize from 32-bit to 64-bit. [ID 548978.1]

For information on repository recovery, refer to How To Change Oracle 11g Wordsize from 32-bit to 64-bit [ID 548978.1].

In case of some olap data in win32, at the end of step 0, follow the steps mentioned in Note [ID 386990.1].

This appendix contains the following sections:

- On Source Host (Microsoft Windows 32)

- On Destination Host (Microsoft Windows 64)

- Final Steps

On Source Host (Microsoft Windows 32)

To recover Database 11.1.0.7/10.2.0.5 from Microsoft Windows 32 to Microsoft Windows 64, on source host follow these steps:

1. Go to DB Oracle Home <DB_HOME>\bin\sqlplus /NOLOG

2. Run the following command:
SQL> CONNECT / AS SYSDBA :

Note:
If you are using 10.2.0.5 Database, go to <DB HOME>/admin/<SID>/udump and make a backup of this in your local system.

3. Run the following command:

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Note:
If you are using 10.2.0.5 Database, the trace file will be generated in <DB HOME>/admin/<SID>/udump. Now compare the files with the backed up <DB HOME>/admin/<SID>/udump. You will find some new trace files. One of the new trace files will contain the steps which will be performed later in Win64 host.

Note:
If you are using 11.1 Database, the command creates a new <sid>_ora_XX.trc file in <DB_BASE>\diag\rdbms\<SID>\<SID>\trace\<sid>_ora_xx.trc. For example:
C:\DB\diag\rdbms\orcl\orcl\traceorcl_ora_3832.trc

This file can be used to create the control file in the destination host.

This file can be identified by the <DB_BASE>\diag\rdbms\<SID>\<SID>\trace\alert_<Sid>.log

For information about the generated trace file, go to the last few lines.

Next, go to the console, where you were following the steps for upgrade. Select "Provide Repository Back up details" and then provide the date and time of creation of the trace file which you just identified.

4. Perform a full offline database backup (optional).

Note:
If you are using 10.2.0.5 Database, run the following command:
<OMS_HOME>\bin>

emctl config emkey -copy_to_repos -sysman_pwd <sysman_password>

For example:

C:\Oracle\Middleware\oms11g\BIN>emctl config emkey -copy_to_repos -sysman_pwd Welcome1

5. Run the following command:
SQL> SHUTDOWN IMMEDIATE;

STARTUP;

Note:
STARTUP command should also be run after Step 6 on the destination host.

On Destination Host (Microsoft Windows 64)

To recover Database 11.1.0.7/10.2.0.5 from Microsoft Windows 32 to Microsoft Windows 64, on the destination host follow these steps:

1. Install only the software on the computer.

Note:
Please make sure that the Database being installed here has the same path name as the Database on win32 host. This ensures speedy recovery.

2. Copy the entire <DB_Base>\oradata directory from Microsoft Windows 32 to <DB_Base>\ directory.

3. Run the following command:
<DB_HOME>\bin\oradim -new -sid <SID> -maxusers <no. of users> -startmode auto -pfile <DB_HOME>\database\init<SID>.ora

Note:
MAXUSERS may not work with Database 10.2.0.5

For example:

C:\DB\db\BIN>oradim.exe -new -sid orcl -maxusers 3 -startmode auto -pfile C:\DB\db\database\initorcl.ora

Note:
You may see an error here. This error can be ignored. However, make sure Instance is created. Also, init<SID>.ora will not be created now.

4. Copy the entire <DB_Base>\admin directory from win32 to the <DB_Base>\ directory.

5. Copy the entire <DB_Base>\fast_recovery_area directory from win32 to the <DB_Base>\ directory of win64.

6. Copy <DBHOME>\database\*.* files from win32 to <DBHOME>\database\ of win64.

Note:
If you are using Database 10.2.0.5, copy <DB_HOME>\dbs\SPFILE<SID>.ORA from win32 to the same location on win64. An example of this file is as follows:
C:\DB\db\dbs\SPFILEORCL.ORA

STARTUP;

7. Set the following environment variables:

- set ORACLE_HOME=<DB_home>

- set ORACLE_SID=<SID>

8. Go to the 64-bit DB_HOME\rdbms\admin directory.

Note:
If you cannot find sqlplus inside this, then go to <DB_HOME>\bin

9. Run the following command:
sqlplus /NOLOG

10. Connect /as sysdba.

11. Run the following command:
SQL> create pfile from spfile;

Note:
: If you are using Database10.2.0.5, run the following command:
create pfile='<DB_HOME>\database\init<SID>.ora' from SPFILE='<DB_HOME>\dbs\SPFILE<SID>.ORA';

For example:
create pfile='C:\DB\db\database\initorcl.ora' from SPFILE='C:\DB\db\dbs\SPFILEORCL.ORA';

Note:
If you are using Database 11.1.0.7, run the following command:
create pfile='<DB_HOME>\database\init<SID>.ora' from SPFILE='<DB_HOME>\database\SPFILE<SID>.ORA';

For example:
create pfile='C:\DB\db\database\initorcl.ora' from SPFILE='C:\DB\db\database\SPFILEORCL.ORA';

12. Edit <DB_HOME>\database\init<SID>.ora by adding _SYSTEM_TRIG_ENABLED=FALSE.

13. Run the following command:
SQL> create spfile from pfile

The spfile gets created in the same directory.

14. Run the following command:
SQL> startup nomount

The Instance starts as nomount.

Note:
You may receive a failure message as follows:
ORA-00119: invalid specification for system parameter LOCAL_LISTENER

ORA-00132: syntax error or unresolved network name '<listener name>'

To correct this you may need to edit pfile, spfile;

To edit the pfile and spfile, open '<DB_HOME>\database\init<SID>.ora' and delete the following line:

LOCAL_LISTENER

Next, run the following command:

Sql> create spfile from pfile

15. Go to the file <sid>_ora_xx.trc as identified in 0 of Microsoft Windows 32. Steps 15, 16 and 17 are to be carried out from this file. For your reference, example of these steps are as follows:

SQL > CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS  NOARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 'C:\DB\ORADATA\ORCL\REDO01.LOG'  SIZE 50M BLOCKSIZE 512,
GROUP 2 'C:\DB\ORADATA\ORCL\REDO02.LOG'  SIZE 50M BLOCKSIZE 512,
GROUP 3 'C:\DB\ORADATA\ORCL\REDO03.LOG'  SIZE 50M BLOCKSIZE 512
DATAFILE
'C:\DB\ORADATA\ORCL\SYSTEM01.DBF',
'C:\DB\ORADATA\ORCL\SYSAUX01.DBF',
'C:\DB\ORADATA\ORCL\UNDOTBS01.DBF',
'C:\DB\ORADATA\ORCL\USERS01.DBF',
'C:\DB\ORADATA\ORCL\MGMT_ECM_DEPOT1.DBF',
'C:\DB\ORADATA\ORCL\MGMT.DBF',
'C:\DB\ORADATA\ORCL\MGMT_AD4J.DBF'
CHARACTER SET WE8MSWIN1252;

Note:
: In case you find an error here, try the following command:
SQL> RECOVER DATABASE;

16. Run the following command:
SQL>ALTER DATABASE OPEN;

17. Run the following command:
SQL>ALTER TABLESPACE TEMP ADD TEMPFILE 'C:\DB\ORADATA\ORCL\TEMP01.DBF' SIZE 20971520 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;

This command updates the temp table space.

18. Run the following command:
SQL> SHUTDOWN IMMEDIATE;

19. Run the following command:
SQL> startup upgrade;

20. Run the following command:
SQL> SPOOL mig32-64.log;

21. Run the following command:

SQL> SET ECHO ON;

22. Run the following command:
SQL> @utlirp.sql;

Note:
If you are using sqlplus from <DB_HOME>\bin\ then run the following command:
SQL> @ <DB_HOME>\RDBMS\ADMIN\utlirp.sql

or

SQL> @ ?/RDBMS/ADMIN?utlirp.sql

23. Run the following command:
SQL> spool off;

24. Run the following command:
SQL> shutdown immediate;

25. Run the following command:
SQL> startup

26. Run the following script. To run the script paste it in SQL>prompt and press Enter.

begin
update obj$ set status=5 where obj#=(select obj# from obj$,javasnm$
where owner#=0 and type#=29 and short(+)=name and
nvl(longdbcs,name)='oracle/aurora/rdbms/Compiler');
commit;
declare
cursor C1 is select
'DROP JAVA DATA "' || u.name || '"."' || o.name || '"'
from obj$ o,user$ u where o.type#=56 and u.user#=o.owner#;

ddl_statement varchar2(200);
iterations number;
previous_iterations number;
loop_count number;
my_err     number;
begin
previous_iterations := 10000000;
loop
-- To make sure we eventually stop, pick a max number of iterations
select count(*) into iterations from obj$ where type#=56;
exit when iterations=0 or iterations >= previous_iterations;
previous_iterations := iterations;
loop_count := 0;
open C1;
loop
begin
fetch C1 into ddl_statement;
exit when C1%NOTFOUND or loop_count > iterations;
exception when others then
my_err := sqlcode;
if my_err = -1555 then -- snapshot too old, re-execute fetch query
exit;
else
raise;
end if;
end;
initjvmaux.exec(ddl_statement);
loop_count := loop_count + 1;
end loop;
close C1;
end loop;
end;
commit;
initjvmaux.drp('delete from java$policy$shared$table');
update obj$ set status=1 where obj#=(select obj# from obj$,javasnm$
where owner#=0 and type#=29 and short(+)=name and
nvl(longdbcs,name)='oracle/aurora/rdbms/Compiler');
commit;
end;
/
create or replace java system;
/

27. Run the following command:
SQL> @utlrp.sql

Note:
If you are using sqlplus from <DB_HOME>\bin\ then, run the following command:
SQL> @ <DB_HOME>\RDBMS\ADMIN\utlrp.sql

or

SQL> @ ?/RDBMS/ADMIN?utlrp.sql

If it succeeds, then continue to 0 Else, if you receive an error, do the following:

1. Run the following command:
SQL> alter system reset "_system_trig_enabled" scope = spfile;

If you see errrors, ignore them and continue to the next step.

2. Remove olap by running the following commands:
SQL> @?/olap/admin/catnoamd.sql

Note:
If you get an error related to files not found then, for each of those files, use the following command:
SQL>@C:\DB\db\olap\admin\<filename>.sql;

However, even if you receive errors, you can just continue.

SQL> @?/olap/admin/catnoaps.sql

SQL> @?/olap/admin/catnoaps.sql

SQL> @?/olap/admin/olapidrp.plb

3. Add olap by running the following commands:
SQL> connect SYS as SYSDBA

SQL> spool olap.log

SQL> @?/olap/admin/olap.sql SYSAUX TEMP;

4. Reenter the following command:
SQl> @utlrp.sql

Note:
: If you are using sqlplus from <DB_HOME>\bin\ then, run the following command:
SQL> @ <DB_HOME>\RDBMS\ADMIN\utlrp.sql

or

SQL> @ ?/RDBMS/ADMIN?utlrp.sql

5. Check for the following (optional):
- Invalid OLAPSYS objects, by running the following command:

SQL> select owner, object_name, object_type, status from dba_objects where status = 'INVALID' and OWNER = 'OLAPSYS' ;

- OLAP components in the DBA_REGISTRY, by running the following commands:

SQL> column comp_name format a35

SQL> SELECT comp_name, status, substr(version,1,10) as version from dba_registry;

SQL> Spool Off

28. Delete the line _SYSTEM_TRIG_ENABLED=FALSE in init<SID>.ora in step 11 and run the following commands:

SQL> ALTER SYSTEM RESET "_system_trig_enabled" SCOPE=SPFILE sid='*';

commit;

shutdown immediate;

startup;

Final Steps

To finalize the process, do the following:

Microsoft Windows 32

On Microsoft Windows 32 computer, do the following:

1. Go to <DB_HOME>\bin.
sqlplus "/as sysdba"

SQL>startup;

2. Run the following command:
<OMS_HOME>\bin>emctl config emkey -remove_from_repos

For example:

C:\Oracle\Middleware\oms11g\BIN>emctl config emkey -remove_from_repos

3. Go to <DB_HOME>\bin.
sqlplus "/as sysdba"

shutdown immediate;

startup;

Microsoft Windows 64

On Microsoft Windows 64 computer, do the following:

1. Start the listener, by running the following command:
<DB_HOME>\bin\listener.exe start

Alternatively, you can start the listener, by running the following command:

<DB_HOME>\bin\netca

This can be done before or after recovery.

2. If the listener does not start, perform the following commands with <SID>:
<DB_HOME>\bin\sqlplus "/as sysdba"

SQL>alter system register;

SQL>commit;

SQL>shutdown immediate;

SQL>startup;

Troubleshooting

If you still face any issues, follow these steps:

Note:
These steps have been tested with Database 10.2.0.5.

1. Run the following command:
<DB_HOME>\BIN\orapwd file=<DB_HOME>\database\PWDorcl.ora password=<enter_password> entries=30 FORCE=Y

2. You may need to add an entry in tnsnames.ora. An example of the entry is as follows:

ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = adc2111519.us.oracle.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl.us.oracle.com)
)
)

Where, orcl is the SID.

3. Bounce the database from SQLPlus by running the following commands:
<DB_HOME>\bin\sqlplus "/as sysdba"

SQL>shutdown immediate;

SQL>startup;

4. Bounce the listener by running the following commands:
<DB_HOME>\bin\listener.exe stop

<DB_HOME>\bin\listener.exe start

<DB_HOME>\bin\listener.exe status (to be repeated till you see the service name)

K Deleting Unwanted Oracle Management Agents

While upgrading from 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2), you might see an error message stating that some Management Agents are still in Activation Pending state, or that the Deferred Data Migration Process (DDMP) or Accrued Data Migration Process (ADMP) is not complete. This indicates that the earlier release of the Enterprise Manager system is still undergoing a 2-system upgrade to 12c Release 1 (12.1.0.1).

To resolve this issue, wait until the DDMP and ADMP jobs are complete, and all Management Agents are switched over from the earlier release to 12c Release 1 (12.1.0.1). Then upgrade 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2).

If you are sure you do not want to switch over some Management Agents from the earlier release to 12c Release 1 (12.1.0.1), then delete these unwanted Management Agents as described in Deleting Unwanted Management Agents, before you start the upgrade process.

However, for some reason, if you are unable to delete the unwanted Management Agents, then turn off the sanity check that checks for Managements Agents with Activation Pending state. This enables you to proceed with the upgrade process without encountering any such warning. To turn off the sanity check, run the following query on your 12c Release 1 (12.1.0.1) Management Repository.

MERGE INTO PRE_UPGC_MASTER_INFO DEST
USING dual
ON (DEST.property_name =  'ignore_upg_pending_activation_check')
WHEN MATCHED THEN
UPDATE SET DEST.property_value = 'TRUE'
WHEN NOT MATCHED THEN
INSERT (property_name, property_value) VALUES( 'ignore_upg_pending_ activation_check', 'TRUE' );

L Deleting Old OMS Home

This chapter describes how you can delete the old OMS home after upgrading your Enterprise Manager system (full release) from 12c Release 1 (12.1.0.1) to 12c Release 2 (12.1.0.2). In particular, this chapter covers the following:

- Deinstalling in Graphical Mode

- Deinstalling in Silent Mode

Deinstalling in Graphical Mode

To deinstall the old OMS home in graphical mode, follow these steps:

Note:
Deinstall the components in the order described in this procedure. Otherwise, the installation wizard displays an error.

1. Invoke the installer from the OMS home by running the following command:
$<OMS_HOME>/oui/bin/runInstaller -deinstall ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles -invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- You can invoke the installer even from the directory where you downloaded the software. For example, <software_location>/.

- The -invPtrLoc parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

- When you run runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

Note:
When you invoke runInstaller or setup.exe, if the Enterprise Manager Cloud Control Installation Wizard does not appear, then it is possible that you do not have read and write access to the /stage subdirectory, which a subdirectory in the Disk1 directory of the Enterprise Manager software.
There is a classpath variable that the installation wizard computes for OPatch as ../stage/Components/, and when the TEMP variable is set to /tmp, the installation wizard tries to look for the opatch JAR file in the /tmp/../stage directory, which is equivalent to /stage. However, if you do not have read and write permission on /stage, then the installation wizard can hang. Under such circumstances, verify if you have read and write access to the /stage directory. If you do not have, then set the TEMP variable to a location where the install user has access to, and then relaunch the installation wizard.

2. In the installation wizard, on the My Oracle Support Details screen, click Installed Products.

3. On the Inventory screen, select only the OMS-related plug-in homes, and click Remove.

4. On the Inventory screen, select the Java Development Kit (JDK) home, and click Remove.

Note:
Deinstall JDK only if it was installed by the installation wizard while installing the Enterprise Manager system. Otherwise, you can skip this step.

Note:
After deinstalling JDK, do NOT exit the installer. If you exit the installer inadvertently, then follow these steps:

1. Manually download and install JDK 1.6 v24+ on the OMS host. If you already have this supported version, then you can reuse it.

2. Invoke the installer again and pass the absolute path to the location where you have JDK:
$<OMS_HOME>/oui/bin/runInstaller -deinstall -jreLoc <JDK_HOME> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

5. On the Inventory screen, select the Oracle WebTier home, and click Remove.

6. On the Inventory screen, select the following, and click Remove.

- OMS home

- Oracle Common directory

7. On the Inventory screen, click Close to exit the wizard.

Deinstalling in Silent Mode

To deinstall the old OMS home in silent mode, follow these steps:

Note:
Deinstall the components in the order described in this procedure. Otherwise, the installation wizard displays an error.

1. Deinstall the plug-in homes:
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_oms_plug-in_home}" ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles -invPtrLoc <absolute_path_to_oraInst.loc>]

Note:

- You can invoke the installer even from the directory where you downloaded the software. For example, <software_location>/.
If you invoke the installer from here, then do NOT pass -removeAllFiles.

- When you run runInstaller -help, you will see the option -nowarningonremovefiles listed. This option is currently not supported and has no effect even if you use it.

- To deinstall multiple plug-ins, enter the plug-in homes separated by a comma.

- The -invPtrLoc parameter is supported only on UNIX platforms, and not on Microsoft Windows platforms.

For example,

$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/plugins/oracle.sysman.ssa.oms.plugin_12.1.0.2.0}" ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

2. Deinstall the Java Development Kit (JDK) home:
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_jdk_home}" ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

For example,

$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/jdk16}" ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

Note:
Deinstall JDK only if it was installed by the installation wizard while installing the Enterprise Manager system. Otherwise, you can skip this step.

3. Manually download and install JDK 1.6 v24+ on the OMS host. If you already have this supported version, then you can reuse it.
You must reinstall JDK because the installer has a dependency on it. The new JDK can be installed anywhere on the OMS host, not necessarily in the same location where it existed before. However, ensure that you pass the -jreLoc parameter (as described in the following steps) while invoking the installer to indicate the location where you have installed the JDK.

4. Deinstall the Oracle WebTier home:
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_web_tier}" -jreLoc <JDK_HOME> ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

For example,

$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/Oracle_WT}" -jreLoc </home/oracle/jdk> ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

5. Deinstall the OMS and the Oracle Common directory:
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={absolute_path_to_oms_oracle_home_and_common_directory_to_be_deinstalled}" -jreLoc <JDK_HOME> ORACLE_HOME=<absolute_path_to_oms_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_oraInst.loc>]

Note:
The argument REMOVE_HOMES accepts more than one path separated by a comma.

For example,

$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_HOMES={/home/oracle/middleware/oms,/home/oracle/middleware/oracle_common}" -jreLoc </home/oracle/jdk> ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc /home/oracle/oraInst.loc

Index

A  C  D  E  F  G  H  I  J  L  M  N  O  P  R  S  T  U  V  W

Numerics

1-system upgrade approach

default ports assigned, 2.5

in graphical mode, 10.1.1

in silent mode, 10.2.1

installing software-only

in graphical mode, 10.3.1

in silent mode, 10.4.1

overview, 1.2.1 process, 7.1, 7.3 using Oracle Software Library, 2.7 1-system upgrade approach on a different host

in graphical mode, 10.5

overview, 1.2.1, 2.3

using Oracle Software Library, 2.7

2-system upgrade approach

default ports assigned, 2.5

in graphical mode, 10.1.2

in silent mode, 10.2.2

installing software-only

in silent mode, 10.4.2

process, 7.2

A

accrued data, 11.6.1

accrued data migration, 11.6.1

accrued data migration jobs

migrating ECM history data, 11.6.1

overview, 11.6.1

signing off, 11.9

tracking, 11.6.2

alerts, 2.10.1, 2.10.2

closed alerts, 2.10.2.1

creating incidents and events, 2.10.2.3

migration methods, 2.10.2.1 open alerts

creating incidents and events, 2.10.2.2

migration, 2.10.2.1

allroot.sh script, 4.1, 10.1.1 Application Dependency and Performance, 7.1, 7.2, 7.3, 7.3

C

central inventory, 8.4.1, E

commands

Enterprise Manager commands

deinstalling in GUI mode, L.1, L.1

deinstalling in silent mode, L.2

configuration assistants, 1.1.3, 1.2.4.1, 1.2.4.2, 1.2.4.3 connectors, 2.8 critical data migration, 11.5.1

D

data format migration, 11.5.1

database

backing up database, 7.2

backing up with DBCA, 7.2

providing repository backup details, 8.5

database upgrade, 2.4 deferred data migration jobs

deferred data migration, 11.5.1

overview, 11.5.1

tracking, 11.5.2

deploy operations, 1.2.4.1 deployment procedures, 1.2.2, 1.2.2, 1.2.2, 7.1, 7.2 destination host, J diff reports

generating and viewing, 11.7.2

overview, 11.7.1

downtime

minimum or zero downtime, 1.2.2

reasonable, 1.2.2

reasonable downtime, 1.2.2

E

EM CLI, G

EM CLI clients, 2.10.6

EM_UPLOAD_HTTP_PORT parameter, 8.2

EM_UPLOAD_HTTPS_PORT parameter, 8.2

emgc.properties file, 8.2

emkey, 3, 7.2

copying

before backing up repository, 4.1, 4.2, 4.3, 4.4

before upgrading OMS, 7.1, 7.3

before uprading OMS, 7.2

handling errors, 7.1, 7.2 removing emkey from the repository, 7.2 verifying if emkey is copied, 7.3 verifying whether emkey is copied, 7.1, 7.2 Enterprise Manager Cloud Control

accessing preupgrade console, 1.2.3.1

deinstallation

silent mode, L.2

installation wizard, 1.1.2.1, 1.2.3.2 postupgrade console, 1.2.3.3 postupgrade steps, 11.4 preupgrade console, 1.2.3.1 supported platforms for upgrade, 2.3 supported upgrade paths, 2.1 upgrade approaches, 1.2.1 upgrade scope, 2.4 upgrade utilities, 1.2.3 upgrading multi-OMS environment, 10.6 Enterprise Manager Cloud Control Installation Wizard, 1.1.2.1, 1.2.3.2 enterprise rulesets, B.1 events, 2.10.1, B.1

overview, B.1

F

failed jobs, 2.10.3

firewall settings, 1.2.2, 1.2.2, 1.2.2, 2.5

G

gc_inst directory, 1.2.4.1, 2.4

GCDomain, 1.2.4.1

H

health report, 9.2

generating, 9.2

signing off, 9.3

verifying, 9.3

I

identifying host for upgrade, 8.2

inactive targets, 11.8

incident rule sets

deleting rule sets, 11.4.7

incident rules, 11.10

deleting, 11.10.4

overview, 11.10.1

updating for moved metrics, 11.10.2

updating for renamed metrics, 11.10.3

incident rulesets, 2.10.1, 11.10, B.1

accessing, B.2

classification, B.1

migrating notification rules, B.3

Incident rulesets, B.1 incidents, B.1

overview, B.1

incidents and events, 2.10.2.2 installation base directory, 9.1, 9.1, E instance directory, E inventory.xml file, 8.4.1, 8.4.2, 8.4.2

J

Java Development Kit, 1.2.4.1

default version, 1.2.4.2, 1.2.4.3

default version installed, 2.4

manual download, 2.4

JDK, 1.2.4.1 jobs

1-system upgrade approach, 2.10.3

2-system upgrade approach, 2.10.3

aborted jobs, 2.10.3

jobs on multiple targets, 2.10.3

management, 2.10.3

repeating jobs, 1.2.2, 1.2.2, 1.2.2, 2.10.3, 2.10.3

running, 1.2.2, 1.2.2, 1.2.2

scheduled jobs, 1.2.2, 1.2.2, 1.2.2, 2.10.3

suspended jobs, 2.10.3

JROCKIT, 2.4 JVM Diagnostics, 7.1, 7.2, 7.3, 7.3

L

linux patching, 11.4.9

lockd account

using locked account, 9.1

locked account

power broker, 9.1

SUDO, 9.1

M

managed server, 1.2.4.1

management repository

creating link to upgraded repository, 11.1

managing software, 8.3 master agents, 9.1 metric changes, C metric collection errors, 9.2, 11.4.8 metrics

changes, 11.10.1

collecting metrics, 2.10.5

decommissioned, 11.10.1

moved, 11.10.1

renamed, 11.10.1

renamed metrics, 2.10.5

retained, 11.10.1

thresholds, 2.10.5

migration activity, 11.5.1, 11.6.1 minimal monitoring loss, 1 missing agent or plug-in software, 8.4.4 multi-OMS environment, 8.2, 10.6

N

near-zero downtime, 1

NFS-mounted drive, 2.4

node manager, 1.2.4.1

not supported, 8.4.3, 8.4.4

notification, 2.10.1

notification methods, B.4

notification rules, 2.10.1, 11.10, B.1

notifications, B

O

obsolete targets, 11.4.6

OCM scheduler, 11.4.5

operating system groups, E

operating system users, E

operation name, 9.1

Oracle HTTP Server, 2.4

Oracle JRF, 1.2.4.3

Oracle Management Agent

agent upgradability, 8.3

analyzing environment, 8.4

checking agent upgradability status, 8.4.3

configuring, 9.1

deploying, 9.1

generating health report, 9.2

manual download, 8.3

prerequisites, E

problematic agents, 8.4.5

reconfiguring, 9.1

target upgradability, 8.3

upgradable, 8.4.3

upgrade status, 11.3

upgrading

installing plug-ins, 2.6.2.1

with invalid inventory, 8.4.2 with valid inventory, 8.4.1 Oracle Management Repository

upgrading

in graphical mode, 10.1

in silent mode, 10.2

Oracle Management Service

installing software-only

in graphical mode, 10.3

in silent mode, 10.4

stopping OMS instances, 4.1 stopping OMSes, 4.3.3, 10.1.1 upgrading

in graphical mode, 10.1

in silent mode, 10.2

installing plug-ins, 2.6.2.2

Oracle Software Library, 2.7

backing up software library, 7.2

NFS-mounted drive accessible, 7.3

reconfigure software library, 7.2

using the library

1-system upgrade approach, 2.7

1-system upgrade approach on a different host, 2.7

2-system upgrade approach, 2.7

Oracle Software Library Reconfigure Locations page, 11.2 Oracle Web Tier, 1.2.4.1, 1.2.4.3 Oracle WebLogic domain, 1.2.4.1 Oracle WebLogic Server, 1.2.4.2, 1.2.4.3

default version installed, 1.2.4.1, 2.4

manual installation, 2.4, 2.4, 2.4

typical installation, 2.4

oracle_common directory, 1.2.4.1, 1.2.4.2, 1.2.4.3 ORACLE_COMMON property, 2.4 Oracle_WT directory, 1.2.4.1, 1.2.4.2, 1.2.4.3 oraInst.loc file, 8.4.2 out-of-place upgrade, 2.4

P

packages, E

pie charts, 8.3

ping, 9.3, E

ping test, 9.1, 9.3

plug-ins

downloading required plug-ins, 2.6.2.1, 8.3

identifying required plug-ins, 2.6.2

installed by default, 1.2.4.2, 1.2.4.3

installing, 2.6

installing while upgrading Management Agent, 2.6.2.1

installing while upgrading OMS, 2.6.2.2

manual download, 4.1.1

manual installation, 4.1.1

selecting plug-ins, 10.1.2, 10.5

ports

default ports assigned, 2.5

HTTP upload ports, 8.2

HTTPs upload ports, 8.2

reusing existing ports, 2.5

secure, 8.2, 8.2

unsecure, 8.2, 8.2

Post Upgrade Reconfiguration, 11.2 post-config options, 9.1 post-upgrade activity, 11.6.1 postupgrade console, 1.2.3.3 postupgrade steps

disabling incident rule sets, 11.4.7

enabling linux patching, 11.4.9

general, 11.4.1

resolving metric collection errors, 11.4.8

stopping OCM scheduler, 11.4.5

postupgrade tasks, 11.4 power broker, 9.1 pre-deploy options, 9.1 preferred credentials, 9.1, G

default selection, 9.1

overriding preferred credentials, 9.1

registering

as default credentials, G

as preferred credentials, G

registering with EMCLI, 9.1 preupgrade console

applying patch, 7.1, 7.2, 7.3

private rulesets, B.1 problematic agents, 8.4.5 process

1-system upgrade approach, 7.1, 7.3

2-system upgrade approach, 7.2

processes

1-system upgrade, 1.2.4.1, 1.2.4.1

1-system upgrade on a different host, 1.2.4.3

2-system upgrade, 1.2.4.2

R

readiness check, 9.2

reconfiguration Software Library validation errors, 11.2

reconfiguring Oracle Software Library, 11.2

confirmation step, 11.2

validation step, 11.2

recovering database

destination host, J.2

source host, J, J.1

registering, 8.3 repository backup details, 8.5 root.sh script, 9.1, 9.1

S

secure ports, 8.2

securing the OMS, 1.2.4.2

server load balancer

changes to monitors, F

changes to monitors with SSO configured, F

updating configuration, F

server load balancers, 7.3 shared agents, 9.1 signing off accrued data migration jobs, 11.9 skipped jobs, 2.10.3 SOA targets, 9.2, 9.3 software library

See Oracle Software Library, 2.7

software location

validating, 8.3

software updates

installing, 4.1, 10.1.1, 10.1.2

installing from custom location, 10.1.2

skip installing, 4.1, 10.1.1, 10.1.2

SSH ports, E stage location, 8.3 status pending state, 3, 4, 4.1, 4.2, 4.3, 4.4, 4.5 SUDO, 9.1 supported upgrade paths, 2.1 suspended on event, 9.1, 9.2 switch over operations, 1.2.4.1 switchover

generating health report, 9.2

signing off health report, 9.3

switching over, 9.4

verifying health report, 9.3

-system upgrade approach

using Oracle Software Library, 2.7

T

target types added, 11.10.1

targets

checking the upgradability status, 8.4.4

upgradable, 8.4.4

temporary directory, E two-system upgrade

reconfiguring Oracle Software Library, 11.2

two-system reconfiguration, 11.2

U

unsecure upload ports, 8.2

upgrade

1-system upgrade in graphical mode, 10.1.1

1-system upgrade in silent mode, 10.2.1

1-system upgrade on a different host in graphical mode, 10.5

2-system upgrade in graphical mode, 10.1.2

2-system upgrade in silent mode, 10.2.2

agent upgrade status, 11.3

installing software-only

1-system upgrade in graphical mode, 10.3.1

1-system upgrade in silent mode, 10.4.1

2-system upgrade in graphical mode, 10.3.2

2-system upgrade in silent mode, 10.4.2

Upgrade Agents page, 5.1

Agent Upgrade Results, 5.1, 5.5.2

Not Upgradable Agents, 5.1, 5.4.3

upgrade approaches, 1.2.1

1-system upgrade approach, 1.2.1

1-system upgrade approach on a different host, 1.2.1

1-system upgrade process on a different host, 1.2.4.3

2-system upgrade approach, 1.2.1

2-system upgrade process, 1.2.4.2

differences, 1.2.2

overview, 1.2.1

upgrade options, 1 upgrade scope, 2.4 upgrade.rsp file, 4.2 Upgrading 12c Management Agents

additional parameters, 5.4.2

post upgrade tasks, 5.5.1

procedure, 5.4, 5.5.2

upgrade job status and progress, 5.5.1

user accounts

SYS, 4.1, 10.1.1

SYSMAN, 4.1, 10.1.1

V

valid inventory, 8.4.1

W

with missing agents software, 8.4.3

with missing plug-ins, 8.4.3

WLS_DOMAIN_NAME option, 4.1.1

wls1035_generic.jar file, 2.4

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