Download Report

[1]
Oracle®
Enterprise Manager
Cloud Control Upgrade Guide
12c Release 4 (12.1.0.4)
E22625-34
January 2015
Oracle Enterprise Manager Cloud Control Upgrade Guide, 12c Release 4 (12.1.0.4)
E22625-34
Copyright © 2014, 2015, Oracle and/or its affiliates. All rights reserved.
Primary Author:
Aravind Jayaraaman
Contributing Author: Pradeep Gopal, Namrata Bhakthavatsalam, Genevieve D'Souza
Contributor: Enterprise Manager Cloud Control Development Teams, Quality Assurance Teams, Customer
Support Teams, and Product Management Teams.
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, then 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.
Contents
Preface ............................................................................................................................................................... xiii
Audience.....................................................................................................................................................
Documentation Accessibility ...................................................................................................................
Related Documents ...................................................................................................................................
Conventions ...............................................................................................................................................
xiii
xiii
xiii
xiv
What’s New in This Book Revision .................................................................................................. xv
Changes Incorporated in the Latest Revision (Published) ..................................................................
Changes Incorporated in the Previous Revisions (Archived).............................................................
Part I
xv
xv
Introduction to Upgrading an Enterprise Manager System
1 What’s New in This Product Release
2 Overview of the Upgrade Approaches Offered for Upgrading an Enterprise
Manager System
2.1
2.1.1
2.1.2
2.1.3
2.2
2.2.1
2.2.2
2.2.3
Upgrading Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3
(12.1.0.3) to 12c Release 4 (12.1.0.4) 2-1
Overview of the Upgrade Approaches Offered for Upgrading Enterprise Manager
Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4)
2-2
Overview of the Upgrade Utilities Offered for Upgrading Enterprise Manager Cloud
Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4) 2-4
Overview of the 1-System Upgrade Approach Offered for Upgrading Enterprise
Manager Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4
(12.1.0.4) 2-5
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1
(11.1.0.1) to 12c Release 4 (12.1.0.4) 2-8
Overview of the Upgrade Approaches Offered for Upgrading Enterprise Manager
Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4
(12.1.0.4) 2-8
Differences Between the Upgrade Approaches Offered for Upgrading Enterprise
Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release
4 (12.1.0.4) 2-9
Overview of the Upgrade Utilities Offered for Upgrading Enterprise Manager Cloud
Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) 2-11
iii
2.2.4
Overview of the 1-System, 2-System, and 1-System on a Different Host Upgrade
Processes Offered for Upgrading Enterprise Manager Cloud Control 10g Release 5
(10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) 2-16
3 Things to Know About Upgrading an Enterprise Manager System
3.1
3.2
3.3
3.4
3.5
3.6
3.6.1
3.6.2
3.7
3.8
3.9
3.10
3.10.1
3.10.2
3.10.3
3.10.4
3.10.5
3.10.6
3.10.7
3.11
3.12
3.13
3.14
3.15
3.16
Supported Upgrade Paths and Supported Upgrade Approaches for Upgrading an
Enterprise Manager System 3-2
Platforms Supported for Upgrading an Enterprise Manager System................................. 3-3
Upgrade Scope Offered for Upgrading an Enterprise Manager System ............................ 3-3
Modified or Customized Data After Repository Backup That Are Not Migrated Via ADMP
3-5
Ports Used by an Upgraded Enterprise Manager System .................................................... 3-6
Upgrading Plug-Ins While Upgrading an Enterprise Manager System............................. 3-7
Upgrading Plug-Ins While Upgrading Enterprise Manager Cloud Control 12c Release
3 (12.1.0.3), 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4) 3-7
Upgrading Plug-Ins While Upgrading Enterprise Manager Cloud Control 10g Release
5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) 3-8
Status of Oracle Software Library After Upgrading an Enterprise Manager System.... 3-10
Connectors in an Upgraded an Enterprise Manager System ............................................ 3-11
Updating the PDP Configuration File After Upgrading an Enterprise Manager System........
3-11
Notification, Alerts, Jobs, Deployment Procedure Runs, Metrics, EM CLI Clients, and
Oracle Exadata Targets in an Upgraded an Enterprise Manager System 3-11
Notification in an Upgraded an Enterprise Manager System.................................... 3-12
Alerts in an Upgraded an Enterprise Manager System .............................................. 3-12
Jobs in an Upgraded Enterprise Manager System ....................................................... 3-14
Deployment Procedures in an Upgraded Enterprise Manager System ................... 3-15
Metrics Renamed in an Upgraded Enterprise Manager System ............................... 3-16
Upgrading EM CLI Clients After Upgrading an Enterprise Manager System........ 3-16
Upgrading Oracle Exadata Targets After Upgrading an Enterprise Manager System.....
3-16
Custom Certificates Configured for OMS and Management Agent Are Reused in an
Upgraded Enterprise Manager System 3-16
Redoing Customization on Oracle WebLogic Server After Upgrading an Enterprise
Manager System 3-16
Redoing Customization on Deployment Procedures After Upgrading an Enterprise
Manager System 3-17
XML DB Feature in the Database After Upgrading an Enterprise Manager System .... 3-17
Manually Restarting the OMS and the Management Agent After Upgrading an Enterprise
Manager System 3-17
Enabling Force Logging When Oracle Data Guard Is Configured with the Standby
Database for an Upgraded Enterprise Manager System 3-17
Part II Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or
12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
iv
4 Getting Started with Upgrading Enterprise Manager Cloud Control 12c
Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
4.1
4.2
4.2.1
4.2.2
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2
(12.1.0.2) to 12c Release 4 (12.1.0.4) in a Single-OMS or Multi-OMS Non-HA Environment
4-2
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2
(12.1.0.2) to 12c Release 4 (12.1.0.4) in an HA Environment (Primary and Standby Sites)
4-10
Upgrading Primary and Standby OMS Instances When the Standby OMS Is Created
Using Storage Replication 4-11
Upgrading Primary and Standby OMS Instances When the Standby OMS Is Created
Using Standby WebLogic Domain 4-11
5 Upgrading Oracle Management Service and Oracle Management Repository
12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.2
5.2.1
5.3
5.3.1
5.3.2
5.3.3
5.4
5.4.1
5.4.2
5.4.3
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c
Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4) in Graphical Mode 5-2
Advanced Installer Options Supported for Installing an Enterprise Manager System in
Graphical Mode 5-13
Limitations with the Advanced Installer Options Supported for Installing an
Enterprise Manager System in Graphical Mode 5-14
Deleting Unwanted Standalone Management Agents Before Upgrading from 12.1.0.3,
12.1.0.2 to 12.1.0.4 5-15
Moving Lock Files from an NFS-Mounted Drive to a Local File System Location. 5-16
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c
Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4) in Silent Mode 5-17
Advanced Installer Options Supported for Installing an Enterprise Manager System in
Silent Mode 5-21
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the
Software-Only Method in Graphical Mode 5-22
Installing the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software
Binaries Now in Graphical Mode 5-24
Running the allroot.sh Script .......................................................................................... 5-28
Configuring the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software
Binaries in Graphical Mode 5-28
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the
Software-Only Method in Silent Mode 5-34
Installing the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software
Binaries in Silent Mode 5-36
Running the allroot.sh Script .......................................................................................... 5-41
Configuring the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software
Binaries in Silent Mode 5-41
6 Upgrading Oracle Management Agents
6.1
6.2
6.3
6.4
Overview of 12c Management Agent Upgrade......................................................................
Before You Begin Upgrading 12c Management Agents........................................................
Prerequisites for Upgrading 12c Management Agents .........................................................
Upgrading 12c Management Agents .......................................................................................
6-1
6-3
6-4
6-6
v
6.4.1
6.4.2
6.4.3
6.4.4
6.4.5
6.5
6.5.1
6.5.2
6.6
Upgrading 12c Management Agents ................................................................................ 6-6
Additional Parameters for 12c Management Agent Upgrade ................................... 6-10
Viewing 12c Management Agents That Cannot Be Upgraded .................................. 6-11
Performing Postupgrade Clean Up of Old Management Agents ............................. 6-13
Viewing 12c Management Agent Upgrade Clean Up Jobs ........................................ 6-15
After Upgrading 12c Management Agents .......................................................................... 6-17
Verifying 12c Management Agent Upgrade................................................................. 6-17
Moving Central Agent Base Directory Outside Oracle Middleware Home (After
Upgrading 12c Central Agent) 6-18
Troubleshooting 12c Management Agent Upgrade ........................................................... 6-18
7 Upgrading or Redeploying ADP and JVMD
7.1
7.1.1
7.1.2
7.1.3
7.1.4
7.2
7.2.1
7.2.2
7.2.3
7.3
Upgrading or Redeploying JVMD and ADP Engine............................................................. 7-1
Upgrading JVMD Engine ................................................................................................... 7-2
Redeploying JVMD Engine ................................................................................................ 7-4
Upgrading ADP Engine...................................................................................................... 7-4
Redeploying ADP Engine................................................................................................... 7-6
Upgrading or Redeploying JVMD and ADP Agents............................................................. 7-7
Upgrading or Redeploying JVMD and ADP Agents Using Application Performance
Management Page 7-7
Upgrading or Redeploying JVMD Agents Manually Using deploy_jvmdagent.pl .. 7-9
Upgrading or Redeploying ADP Agents Manually Using deploy_adpagent.pl .... 7-10
After Upgrading or Redeploying ADP and JVMD............................................................. 7-10
Part III Upgrading Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
8 Getting Started with Upgrading Enterprise Manager Grid Control 10g Release
5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
8.1
8.2
8.3
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1
(11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade Approach 8-1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1
(11.1.0.1) to 12c Release 4 (12.1.0.4) with 2-System Upgrade Approach 8-9
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1
(11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade Approach on a Different Host
8-21
9 Meeting the Preupgrade Requirements for Upgrading Enterprise Manager
Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
(12.1.0.4)
9.1
9.2
9.3
9.4
9.5
vi
Applying the Preupgrade Console Patch................................................................................ 9-1
Identifying a Host and Port for the New Enterprise Manager System............................... 9-1
Disabling the Auto-Runs of DDMP Jobs ................................................................................. 9-3
Managing and Validating the Location of the Management Agent Software and Its
Associated Plug-ins 9-4
Cloning (or Backing Up) Your Existing Database Before Upgrading an Enterprise Manager
System 9-7
9.6
9.6.1
9.6.2
9.6.3
9.6.4
9.6.5
9.6.6
9.6.7
9.6.8
9.6.9
9.7
Analyzing Your Environment Before Upgrading an Enterprise Manager System........... 9-7
Identifying Oracle Management Agents with Valid Inventory.................................... 9-8
Identifying Oracle Management Agents with Invalid Inventory................................. 9-9
Checking the Upgradability Status of Oracle Management Agents ............................ 9-9
Checking the Upgradability Status of Targets ............................................................. 9-10
Identifying Problematic Oracle Management Agents................................................. 9-11
Identifying Oracle Management Agents That Need to Be Reconfigured................. 9-11
Identifying Oracle Management Agents That are Not Supported in Enterprise
Manager 12c 9-12
Identifying Oracle Management Agents That are Installed after Repository Backup ......
9-13
Identifying Broken Targets.............................................................................................. 9-13
Providing Repository Backup Details for Upgrading an Enterprise Manager System . 9-13
10 Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
10.1
Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4) ........ 10-1
10.1.1
Before You Begin Deploying and Configuring Oracle Management Agents 12c Release
4 (12.1.0.4) 10-1
10.1.2
Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4). 10-3
10.2
Generating a Health Report of Deployed Oracle Management Agents 12c Release 4
(12.1.0.4) 10-9
10.3
Verifying and Signing Off the Health Report of Deployed Oracle Management Agents 12c
Release 4 (12.1.0.4) 10-12
10.4
Switching Over to Oracle Management Agent 12c Release 4 (12.1.0.4)......................... 10-15
10.4.1
Switching Over to Oracle Management Agent 12c Release 4 (12.1.0.4).................. 10-15
10.4.2
Troubleshooting Issues Related to Switching Over to Oracle Management Agent 12c
Release 4 (12.1.0.4) 10-18
11 Upgrading Oracle Management Service and Oracle Management Repository
10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
11.1
11.1.1
11.1.2
11.2
11.2.1
11.2.2
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) in Graphical Mode 11-1
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade Approach in
Graphical Mode 11-2
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 2-System Upgrade Approach in
Graphical Mode 11-11
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) in Silent Mode 11-22
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade Approach in
Silent Mode 11-23
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 2-System Upgrade Approach in
Silent Mode 11-23
vii
11.3
11.3.1
11.3.2
11.4
11.4.1
11.4.2
11.5
11.6
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only Upgrade Method in
Graphical Mode 11-26
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only Upgrade
Method for 1-System Upgrade Approach in Graphical Mode 11-26
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only Upgrade
Method for 2-System Upgrade Approach in Graphical Mode 11-32
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only Upgrade Method in
Silent Mode 11-40
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only Upgrade
Method for 1-System Upgrade Approach in Silent Mode 11-40
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only Upgrade
Method for 2-System Upgrade Approach in Silent Mode 11-41
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade Approach on a
Different Host 11-44
Upgrading a Multi-OMS Environment of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1)
to 12c Release 4 (12.1.0.4) 11-59
12 Performing Postupgrade Tasks After Upgrading to Enterprise Manager
Cloud Control 12c Release 4 (12.1.0.4)
Verifying the Host on Which Enterprise Manager Is Installed ......................................... 12-1
Creating a Link to the Upgraded Management Repository .............................................. 12-3
Discovering the Database Where the Management Repository Was Upgraded............ 12-4
Reconfiguring the Software Library...................................................................................... 12-5
Checking the Agent Upgrade Status..................................................................................... 12-7
Performing General Postupgrade Tasks............................................................................... 12-9
Performing General Postupgrade Steps After Upgrading to Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4) 12-9
12.6.2
Patching Oracle WebLogic Server................................................................................ 12-10
12.6.3
Upgrading Oracle Exalogic System Targets ............................................................... 12-10
12.6.4
Restarting the Central Agent When Additional OMS Is Upgraded ....................... 12-11
12.6.5
Stopping the OCM Scheduler ...................................................................................... 12-11
12.6.6
Deleting Obsolete Targets ............................................................................................. 12-12
12.6.7
Cleaning Up Stale Compliance Standards of Deleted Targets ................................ 12-13
12.6.8
Updating Incident Rules................................................................................................ 12-14
12.6.9
Disabling Incident Rule Sets ......................................................................................... 12-18
12.6.10
Resolving Metric Collection Errors for SOA Target .................................................. 12-19
12.6.11
Enabling Linux Patching After Upgrading Enterprise Manager............................. 12-19
12.6.11.1.1
Resubmitting DownloadLatestPackages Jobs After Stopping them and
Resetting their Credentials 12-20
12.6.11.1.2
Resubmitting UpdateHostPackages Jobs After Stopping Them and Resetting
their Credentials 12-20
12.6.12
Updating the Console URL ........................................................................................... 12-21
12.6.13
Redoing the Customization on Deployment Procedures ......................................... 12-22
12.1
12.2
12.3
12.4
12.5
12.6
12.6.1
viii
Reconfiguring Oracle WebLogic Server with Custom Certificates ......................... 12-22
Restarting the Management Agent After Upgrading an Additional OMS ............ 12-22
Enabling the Compliance Standards That Were Disabled in the Previous Release...........
12-23
12.7
Tracking the Status of Deferred Data Migration Jobs....................................................... 12-23
12.7.1
About Deferred Data Migration Jobs........................................................................... 12-23
12.7.2
Tracking the Status of Deferred Data Migration Jobs .............................................. 12-24
12.8
Tracking the Status of Accrued Data Migration Jobs ....................................................... 12-24
12.8.1
About Accrued Data Migration Jobs ........................................................................... 12-25
12.8.2
Tracking the Status of Accrued Data Migration Jobs ................................................ 12-27
12.9
Generating and Viewing Diff Reports ................................................................................ 12-28
12.9.1
About Diff Reports ......................................................................................................... 12-28
12.9.2
Generating and Viewing Diff Reports ......................................................................... 12-28
12.10 Viewing Inactive Targets in the Upgraded Enterprise Manager System ...................... 12-29
12.11 Signing Off the Accrued Data Migration Process ............................................................. 12-30
12.12 Signing Off the Migration Processes and Exiting the Upgrade Mode ........................... 12-31
12.13 Deleting Old Central Agents and the Associated Targets ............................................... 12-31
12.13.1
Deleting Unwanted Central Agents After Upgrading from 10.2.0.5/11.1.0.1 to 12.1.0.4 .
12-32
12.13.2
Deleting Unwanted Central Agents After Upgrading from 12.1.0.2/12.1.0.3 to 12.1.0.4 .
12-33
12.14 (Optional) Monitoring Targets That Were Monitored by the Deleted Central Agent. 12-34
12.15 (Optional) Deleting the Old OMS Home............................................................................ 12-34
12.16 Migrating the SYSMAN Schema to a Database Configured with CDB and PDB ........ 12-34
12.17 Resolving Custom Roles Issue When Custom Roles Do Not Appear in the Console . 12-35
12.6.14
12.6.15
12.6.16
Part IV Appendixes
A Editing the Response File for Upgrading Oracle Management Service and
Oracle Management Repository in Silent Mode
B Overview of the Notification System in Enterprise Manager Cloud Control
B.1
B.2
B.3
B.4
About Events, Incidents, and Incident Rulesets................................................................... B-1
Accessing Incident Rulesets in Enterprise Manager 12c ...................................................... B-2
Notification Rules Migrated to Incident Rulesets After Upgrading to Enterprise Manager
12c B-3
Notification Methods and Actions After Upgrading to Enterprise Manager 12c ............ B-4
C Overview of the Metric Changes in Enterprise Manager Cloud Control
C.1
C.2
C.3
C.4
C.5
C.6
C.7
Changes to Oracle SOA Infrastructure Metrics in Enterprise Manager Cloud Control..
Changes to Oracle SOA Composite Metrics in Enterprise Manager Cloud Control .......
Changes to Oracle Service Bus Metrics in Enterprise Manager Cloud Control ...............
Changes to Oracle WebLogic Server Metrics in Enterprise Manager Cloud Control .....
Changes to JBoss Application Server Metrics in Enterprise Manager Cloud Control ....
Changes to Siebel Enterprise Metrics in Enterprise Manager Cloud Control ..................
Changes to Siebel Server Metrics in Enterprise Manager Cloud Control .........................
C-1
C-1
C-2
C-2
C-3
C-3
C-4
ix
C.7.1
C.7.2
C.7.3
Setting Preferred Credentials for Siebel Server .............................................................. C-4
Setting Preferred Credentials for Siebel Gateway Server ............................................. C-4
Setting Preferred Credentials for Siebel Database Repository..................................... C-5
D Identifying the Jobs That Will Not Run in Enterprise Manager for 2-System
Upgrade Approach
D.1
D.2
Identifying the Jobs That Will Not Run in the New, Upgraded Enterprise Manager System
D-1
Identifying the Jobs That Will Not Run in the Existing Enterprise Manager System ..... D-3
E Updating Server Load Balancer Configuration Settings
F Setting Preferred Credentials Using EM CLI
G Moving the Central Agent Base Directory Outside Oracle Middleware Home
H Searching and Adding Oracle Management Agents
I Securing Oracle Management Agents After Backing Up Oracle Management
Repository
J Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows
32-bit Host to Microsoft Windows 64-bit Host
J.1
J.2
J.3
J.3.1
J.3.2
J.3.3
Steps to Perform on the Source Host (Microsoft Windows 32-bit) for Recovering Oracle
Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft Windows
64-bit Host J-1
Steps to Perform on the Destination Host (Microsoft Windows 64-bit) for Recovering
Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft
Windows 64-bit Host J-3
Final Steps to Perform for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft
Windows 32-bit Host to Microsoft Windows 64-bit J-8
Final Steps to Perform on the Microsoft Windows 32-bit Host for Recovering Oracle
Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft
Windows 64-bit Host J-8
Final Steps to Perform on the Microsoft Windows 64-bit Host for Recovering Oracle
Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft
Windows 64-bit Host J-9
Troubleshooting Issues with Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from
Microsoft Windows 32-bit Host to Microsoft Windows 64-bit Host J-9
K Deleting the Old OMS Home
K.1
K.2
Deinstalling the Old OMS Home in Graphical Mode .......................................................... K-1
Deinstalling the Old OMS Home in Silent Mode.................................................................. K-3
L Correcting the Database Domain Name to Avoid or Resolve Database Link
Error
L.1
x
Avoiding the Database Link Error Before Starting the Upgrade Process .......................... L-1
L.2
Resolving the Database Link Error That Appears While the Upgrade Process Is in Progress
L-2
M Reviewing Log Files Related to the Upgrade of an Enterprise Manager
System
Index
xi
xii
Preface
Oracle Enterprise Manager Cloud Control Upgrade Guide describes how you can upgrade
the following to Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4):
■
Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3)
■
Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2)
■
Enterprise Manager 11g Grid Control Release 1 (11.1.0.1)
■
Enterprise Manager 10g Grid Control Release 5 (10.2.0.5)
Note: If you have 12c Release 1 (12.1.0.1), them first upgrade it to
either 12c Release 2 (12.1.0.2) or 12c Release 3 (12.1.0.3). Then upgrade
to 12c Release 4 (12.1.0.4).
Audience
Oracle Enterprise Manager Cloud Control Upgrade Guide is meant for system
administrators who want to upgrade an existing 12c Release 3 (12.1.0.3), 12c Release 2
(12.1.0.2), 11g Release 1 (11.1.0.1), or 10g Release 5 (10.2.0.5) Enterprise Manager
system.
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
xiii
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:
xiv
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.
What’s New in This Book Revision
In addition updating the books for an incremental software release or a patch set
release, Oracle revises its books regularly to incorporate bug fixes and value-added
feedback from customers, product managers, support teams, and other key
stakeholders. Every time a book is revised, the revision number of the book is
increased by one and then published on Oracle Technology Network (OTN).
This chapter lists the changes incorporated in the latest revision (E22625-34) and all the
previous revisions of Oracle Enterprise Manager Cloud Control Upgrade Guide (this book).
Note that the latest revision (E22625-34) is the current revision published on OTN, and
the latest revision always contains all the changes incorporated in its previous
revisions.
In particular, this chapter covers the following:
■
Changes Incorporated in the Latest Revision (Published)
■
Changes Incorporated in the Previous Revisions (Archived)
Changes Incorporated in the Latest Revision (Published)
The following are the changes incorporated in the latest revision (E22625-34) that is
published on OTN.
Part, Chapter, or Section
Change Description
Several Chapters and
Sections
Incorporated minor comments from reviewers.
Changes Incorporated in the Previous Revisions (Archived)
The following sections describe the changes incorporated in the previous revisions.
These revisions have been archived, and therefore are not currently available on OTN.
Changes Incorporated in E22625-33
Part, Chapter, or Section
Change Description
Several Sections
Incorporated feedback from reviewers.
xv
Changes Incorporated in E22625-32
Part, Chapter, or Section
Change Description
Several Sections
Incorporated feedback from reviewers.
Changes Incorporated in E22625-31
Part, Chapter, or Section
Change Description
Section 3.16
Introduced this section to highlight that you must enable force
logging when Oracle Data Guard is configured with the standby
database.
Section 4.2
Split this section into the following subsections:
■
■
Section 4.2.1 - To describe how you can upgrade the primary
and standby OMS instances when the standby OMS is
created using storage replication.
Section 4.2.2 - To describe how you can upgrade the primary
and standby OMS instances when the standby OMS is
created using standby WebLogic Domain.
Section 5.1.4
Updated point# 3 to clarify that the path to the LockFile
parameter must lead up to the directory name, and not to the
lock file name. And if the directory does not already exist, it must
be created beforehand. Provided an example to clarify this.
Appendix G
Added this appendix. This appendix describes how to move the
agent base directory of the central agent outside the Oracle
Middleware home.
Chapter 4, Chapter 8
Removed references to Oracle Database 12c Release X (12.1.0.X).
Changes Incorporated in E22625-30
Part, Chapter, or Section
Change Description
Section 4.1
Updated Step 2 (h) to indicate that the OMS instances need not be
shut down if you are performing a software-only upgrade.
Updated Step 2 (i) to indicate that the central agent need not be
shut down if you are performing a software-only upgrade.
xvi
Section 4.2
Deleted this section (Upgrading Enterprise Manager in a
Multi-OMS Non-HA Environment) and updated the title of
Section 4.1 to cater to both single-OMS and multi-OMS
environments.
Section 5.3, Section 5.4
Highlighted that the software-only upgrade approach is best
suited for multi-OMS environments.
Section 5.3.1
Added Step (16) to indicate that the software binaries can be
copied on the additional OMS hosts as well.
Section 5.3.2
Added a note to indicate that the script can be run on the
additional OMS hosts as well.
Section 5.3.3
Added Step (15) to indicate that the additional OMS instances
can be upgraded as well.
Section 5.4.1
Added Step (5) to indicate that the software binaries can be
copied on the additional OMS hosts as well.
Section 5.4.2
Changed the section title and added a note to indicate that the
script can be run on the additional OMS hosts as well.
Part, Chapter, or Section
Change Description
Section 5.4.3
Added Step (4) to indicate that the additional OMS instances can
be upgraded as well.
Section 5.5
Deleted this section (Upgrading a Multi-OMS Environment).
Section 12.17
Added this new section to highlight the issue with missing
custom roles in the Enterprise Manager Cloud Control Console,
and to provide a workaround to resolve the issue
Section 3.11
Added this new section to highlight that all custom certificates
configured for the OMS and the Management Agent can be
reused without any changes or further reconfiguration after you
upgrade to 12c Release 4 (12.1.0.4).
xvii
xviii
Part I
Part I
Introduction to Upgrading an Enterprise
Manager System
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, "What’s New in This Product Release"
Chapter 2, "Overview of the Upgrade Approaches Offered for Upgrading an
Enterprise Manager System"
Chapter 3, "Things to Know About Upgrading an Enterprise Manager System"
1
What’s New in This Product Release
1
Table 1–1 provides links to published documents on Oracle Technology Network
(OTN) for various What’s New topics related to Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4). Review the information available in these URLs, and understand
why you must upgrade to 12c Release 4 (12.1.0.4).
Table 1–1
What’s New in 12c Release 4 (12.1.0.4)
What’s New Topic
Reference URL
What’s New in 12c Release 4
(12.1.0.4)?
Oracle Enterprise Manager Cloud Control Introduction Guide
What’s New in 12c Release 4
(12.1.0.4) Installation Process,
Agent Deployment Process,
and Upgrade Process?
Published Documents on Oracle Technology Network
What Are the Key Known
Issues in 12c Release 4
(12.1.0.4)?
Oracle Enterprise Manager Cloud Control Release Notes
Are My Bugs Fixed in 12c
Release 4 (12.1.0.4)?
If you noticed a few bugs in the previous release, and if you
want to know if those bugs have been fixed in 12c Release 4
(12.1.0.4), then raise a Service Request with Oracle Support.
http://docs.oracle.com/cd/E24628_
01/doc.121/e25353/toc.htm
http://www.oracle.com/technetwork/oem/install-upgrade/i
ndex.html
http://docs.oracle.com/cd/E24628_01/nav/relnotes.htm
What’s New in This Product Release 1-1
1-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
2
Overview of the Upgrade Approaches Offered
for Upgrading an Enterprise Manager System
2
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
4 (12.1.0.4).
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 Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), 12c Release
3 (12.1.0.3) to 12c Release 4 (12.1.0.4)
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release
1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
2.1 Upgrading Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2),
12c Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4)
This section describes the following:
Overview of the Upgrade Approaches Offered for Upgrading an Enterprise Manager System
2-1
Upgrading Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4)
■
■
■
Overview of the Upgrade Approaches Offered for Upgrading Enterprise Manager
Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4
(12.1.0.4)
Overview of the Upgrade Utilities Offered for Upgrading Enterprise Manager
Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4
(12.1.0.4)
Overview of the 1-System Upgrade Approach Offered for Upgrading Enterprise
Manager Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c
Release 4 (12.1.0.4)
Note:
■
If you have Oracle Management Service 12c Release 1 (12.1.0.1)
[with or without Bundle Patch 1], then first upgrade it to either
12c Release 2 (12.1.0.2) or 12c Release 3 (12.1.0.3), and then
upgrade to 12c Release 4 (12.1.0.4).
For instructions to upgrade to 12c Release 2 (12.1.0.2) or 12c
Release 3 (12.1.0.3), refer to the Oracle Enterprise Manager Cloud
Control Upgrade Guide for the respective release, available in the
Enterprise Manager documentation library:
http://docs.oracle.com/cd/E24628_01/index.htm
■
If you have Oracle Management Agent 12c Release 1 (12.1.0.1) that
communicates with Oracle Management Service 12c Release 2
(12.1.0.2) or 12c Release 3 (12.1.0.3), then before upgrading the
Oracle Management Service to 12c Release 4 (12.1.0.4), make sure
you upgrade your Oracle Management Agent 12c Release 1
(12.1.0.1) to either 12c Release 2 (12.1.0.2) or 12c Release 3 (12.1.0.3)
using the Agent Upgrade Console present within the Enterprise
Manager Cloud Control Console.
This is a prerequisite for upgrading your Oracle Management
Service 12c Release 2 (12.1.0.2) or 12c Release 3 (12.1.0.3) to 12c
Release 4 (12.1.0.4).
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:
2.1.1 Overview of the Upgrade Approaches Offered for Upgrading Enterprise Manager
Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4
(12.1.0.4)
Oracle offers only 1-system upgrade approach for upgrading 12c Release 2 (12.1.0.2) or
12c Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4). 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.
2-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4)
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.
The installer does NOT upgrade your existing Management
Agents. After upgrading the OMS, you must upgrade the
Management Agent separately using the Agent Upgrade Console. Agent
Upgrade 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 Section 2.1.2.2.
Note:
Table 2–1 describes the compatibility between OMS and Management Agents across
12c releases.
Table 2–1
Compatibility Between OMS and Management Agents Across 12c Releases
Oracle
Management
Agent 12c
Release 1
(12.1.0.1) +
Bundle Patch 1
Oracle
Management
Agent 12c
Release 2
(12.1.0.2)
Oracle
Management
Agent 12c
Release 3
(12.1.0.3)
Oracle
Management
Agent 12c
Release 4
(12.1.0.4)
No
No
No
Yes
No
No
Oracle
Yes
Yes
Management
(Only
Service 12c Release
Management
3 (12.1.0.3)
Agents released in
January 2012 [with
Bundle Patch 1])
Yes
No
Oracle
No
Management
Service 12c Release
4 (12.1.0.4)
Yes
Yes
(Refers to agents
and their plug-ins
patched or
upgraded to, or
installed with
Bundle Patch 1)
Oracle
Management
Service 12c Release
1 (12.1.0.1) +
Bundle Patch 1
Yes
(includes
Management
Agents with and
without Bundle
Patch 1)
Oracle
Yes
Management
(includes
Service 12c Release
Management
2 (12.1.0.2)
Agents with and
without Bundle
Patch 1)
Yes
Overview of the Upgrade Approaches Offered for Upgrading an Enterprise Manager System
2-3
Upgrading Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4)
2.1.2 Overview of the Upgrade Utilities Offered for Upgrading Enterprise Manager
Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4
(12.1.0.4)
This section describes the utilities to be used for upgrading 12c Release 2 (12.1.0.2) or
12c Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4). In particular, this section describes
the following:
■
Overview of the Enterprise Manager Cloud Control Installation Wizard
■
Overview of the Agent Upgrade Console
2.1.2.1 Overview of the Enterprise Manager Cloud Control 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.
2.1.2.2 Overview of the Agent Upgrade Console
The Agent Upgrade Console is a graphical user interface built into Enterprise Manager
Cloud Control 12c. The console built into Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4) enables you to upgrade one or more Oracle Management Agents of
the following releases:
■
12c Release 3 (12.1.0.3)
■
12c Release 2 (12.1.0.2)
2-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4)
The Agent Upgrade Console was available with Enterprise
Manager Cloud Control 12c Release 3 (12.1.0.3) and 12c Release 2
(12.1.0.2). However, the console available with Enterprise Manager
Cloud Control 12c Release 4 (12.1.0.4) upgrades only the Management
Agent releases mentioned in this section.
Note:
If you have any Oracle Management Agents of 12c Release 1 (12.1.0.1),
then before upgrading the Oracle Management Service, make sure
you upgrade the Oracle Management Agents to either 12c Release 3
(12.1.0.3) or 12c Release 2 (12.1.0.2) using the Agent Upgrade Console.
After that, you can upgrade to 12c Release 4 (12.1.0.4).
Note: All OMS instances must be upgraded in a multi-OMS
environment, before you can use the Agent Upgrade Console to
upgrade your Management Agents.
2.1.3 Overview of the 1-System Upgrade Approach Offered for Upgrading Enterprise
Manager Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release
4 (12.1.0.4)
The following illustration describes the high-level flow or sequence of steps you must
perform when you choose to upgrade 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2)
to 12c Release 4 (12.1.0.4) using the 1-system upgrade approach:
Overview of the Upgrade Approaches Offered for Upgrading an Enterprise Manager System
2-5
Upgrading Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4)
Note: Oracle Management Service 12c communicates only with
Oracle Management Agent 12c (12.1.0.4, 12.1.0.3, 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 Agent Upgrade Console. Agent Upgrade 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
Section 2.1.2.2.
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.0.43.0 and Oracle WebLogic Server 11g
Release 1 (10.3.6) if they are not already available in the Middleware home you
specify.
–
Oracle Management Service 12 c Release 4 (12.1.0.4).
–
Oracle JRF 11g Release (11.1.1.7.0), which includes oracle_common directory.
–
Oracle Web Tier 11g Release (11.1.1.7.0), which includes Oracle_WT directory.
–
Oracle BI Publisher 11g (11.1.1.7.0), which includes Oracle_BI1 directory.
Although Oracle BI Publisher 11g (11.1.1.7) is installed by
default, it is not configured. To configure it post installation or
upgrade an earlier version, follow the instructions in Oracle Enterprise
Manager Cloud Control Administrator’s Guide.
Note:
–
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 4 (12.1.0.4) software.
2-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4)
*
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 4 (12.1.0.4) 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 4 (12.1.0.4)
software.
*
Deploys new plug-ins when the plug-ins being upgraded have new
dependencies, or when there are any new default plug-ins introduced
with a release.
Note: Oracle Cloud Framework Plug-In is an additional default
plug-in introduced with 12c Release 4 (12.1.0.4), so this plug-in is
deployed automatically.
■
■
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, outside
the middleware home.
For example, if the Middleware home is /u01/app/Oracle/Middleware/, then the
instance base location is /u01/app/Oracle/gc_inst.
■
■
Upgrades the Management Repository in the existing certified database.
Runs the following configuration assistants to configure the installed or upgraded
components:
–
Stopping APM Engines
–
Stop Admin Server
–
Plugins Prerequisites Check
–
Repository Upgrade
–
MDS Schema Configuration
–
OMS Configuration
–
Plugins Deployment and Configuration
–
Start Oracle Management Service
–
Oracle Configuration Manager Repeater Configuration
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 Agent Upgrade Console. For more
information, see Section 2.1.2.2.
Note:
Overview of the Upgrade Approaches Offered for Upgrading an Enterprise Manager System
2-7
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
2.2 Upgrading Enterprise Manager Cloud Control 10g Release 5
(10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
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 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1)
to 12c Release 4 (12.1.0.4).
In particular, this section covers the following:
■
■
■
■
Overview of the Upgrade Approaches Offered for Upgrading Enterprise Manager
Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4
(12.1.0.4)
Differences Between the Upgrade Approaches Offered for Upgrading Enterprise
Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c
Release 4 (12.1.0.4)
Overview of the Upgrade Utilities Offered for Upgrading Enterprise Manager
Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4
(12.1.0.4)
Overview of the 1-System, 2-System, and 1-System on a Different Host Upgrade
Processes Offered for Upgrading Enterprise Manager Cloud Control 10g Release 5
(10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Note: For instructions to upgrade from 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4), see Part III.
2.2.1 Overview of the Upgrade Approaches Offered for Upgrading Enterprise Manager
Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4
(12.1.0.4)
Oracle offers the following upgrade approaches for upgrading 10g Release 5 (10.2.0.5)
or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4):
■
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 refers to upgrading 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 Section 11.6.
■
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.
2-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
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.
2.2.2 Differences Between the Upgrade Approaches Offered for Upgrading Enterprise
Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release
4 (12.1.0.4)
Table 2–2 lists the differences between the three upgrade approaches that are offered
for upgrading 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
(12.1.0.4). Understand the differences and select the approach that best suits your
requirement.
Table 2–2
Differences Between the Upgrade Approaches
1-System Upgrade
Approach
2-System Upgrade
Approach
1-System Upgrade Approach
on Different Host
Involves predeployment and Resembles fresh installation.
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.
Has the same impact as
1-system upgrade approach,
but with a different host for
Enterprise Manager Cloud
Control 12c Release 4
(12.1.0.4).
Requires a reasonable
downtime.
Requires a reasonable
downtime.
Requires minimum or zero
downtime.
(Essentially, the downtime lasts
from the time you start
switching over the Management
Agents till the time you upgrade
the OMS.)
(Essentially, the downtime lasts
from the time you start switching
over the Management Agents till
the time you install the OMS.)
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.
Overview of the Upgrade Approaches Offered for Upgrading an Enterprise Manager System
2-9
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 2–2 (Cont.) Differences Between the Upgrade Approaches
1-System Upgrade
Approach
2-System Upgrade
Approach
1-System Upgrade Approach
on Different Host
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.
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.
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.
For more information, see
Section 3.5.
For more information, see
Section 3.5.
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 Running jobs will be aborted
run on the existing Enterprise at the start of the downtime.
Manager system after the start
of the backup. In Enterprise
Manager Cloud Control, these
jobs will appear to be aborted
or failed.
2-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 2–2 (Cont.) Differences Between the Upgrade Approaches
1-System Upgrade
Approach
2-System Upgrade
Approach
1-System Upgrade Approach
on Different Host
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 in 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.
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.
Note:
2.2.3 Overview of the Upgrade Utilities Offered for Upgrading Enterprise Manager
Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4
(12.1.0.4)
This section describes the utilities to be used for upgrading 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4). 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:
■
Overview of the Preupgrade Console
■
Overview of the Enterprise Manager Cloud Control Installation Wizard
■
Overview of the Postupgrade Console
2.2.3.1 Overview of the Preupgrade Console
The Preupgrade Console acts as the primary user interface and is the starting point for
upgrading your 10g Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) to 12c Release 4
(12.1.0.4).
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.
Overview of the Upgrade Approaches Offered for Upgrading an Enterprise Manager System 2-11
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Note: Oracle Management Service 12c communicates only with
Oracle Management Agent 12c (12.1.0.4, 12.1.0.3, 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, do the following:
■
(Optional) Apply the latest PSU patches on your OMS as described in the My
Oracle Support note 822485.1. To access My Oracle Support, access the following
URL:
https://support.oracle.com/
For 10g Release 5 (10.2.0.5), make sure you have at least PSU 3
(9282397) or later applied. For 11g Release 1 (11.1.0.1), make sure you
have at least PSU 1 (10065631) or later applied.
Note:
■
(Mandatory) 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-upgrad
e-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.
2-12 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
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
Here, <OMS_INSTANCE_BASE> is the OMS
Instance Base Directory, which is gc_inst by
default, outside the middleware home. For
example, if the middleware home is
/u01/app/Oracle/Middleware/, then the
instance base location is
/u01/app/Oracle/gc_inst.
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.
Overview of the Upgrade Approaches Offered for Upgrading an Enterprise Manager System 2-13
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
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).
Note:
2.2.3.2 Overview of the Enterprise Manager Cloud Control 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.
2-14 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
2.2.3.3 Overview of the 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.
For more information about these jobs, refer to Section 12.7,
Section 12.8, Section 12.9, Section 12.10, and Section 12.11.
Note:
Overview of the Upgrade Approaches Offered for Upgrading an Enterprise Manager System 2-15
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
2.2.4 Overview of the 1-System, 2-System, and 1-System on a Different Host Upgrade
Processes Offered for Upgrading Enterprise Manager Cloud Control 10g Release 5
(10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
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:
■
■
■
Overview of the 1-System Upgrade Process Offered for Upgrading Enterprise
Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c
Release 4 (12.1.0.4)
Overview of the 2-System Upgrade Process Offered for Upgrading Enterprise
Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c
Release 4 (12.1.0.4)
Overview of the 1-System on a Different Host Upgrade Process Offered for
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release
1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
2.2.4.1 Overview of the 1-System Upgrade Process Offered for Upgrading
Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1)
to 12c Release 4 (12.1.0.4)
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.
2-16 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
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.
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.
Note:
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.6) and Java Development Kit
1.6.0.43.0 (JDK).
Note: Oracle WebLogic Server 11g Release 1 (10.3.6) and JDK
1.6.0.43.0 are installed only if you do not specify the use of existing
installations. Oracle strongly recommends using the 12c installation
process to install the JDK and Oracle WebLogic Server for use with
Enterprise Manager 12c.
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.7.0), which includes the oracle_common
directory, and Oracle Web Tier 11g Release (11.1.1.7.0), which includes the
Oracle_WT directory.
–
Oracle BI Publisher 11g (11.1.1.7.0), which includes the Oracle_BI1 directory.
Overview of the Upgrade Approaches Offered for Upgrading an Enterprise Manager System 2-17
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Although Oracle BI Publisher 11g (11.1.1.7) is installed by
default, it is not configured. To configure it post installation, follow
the instructions in Oracle Enterprise Manager Cloud Control
Administrator’s Guide.
Note:
–
■
*
Oracle Database Management Plug-In
*
Oracle Fusion Middleware Management Plug-In
*
Oracle My Oracle Support Management Plug-In
*
Oracle Exadata Management Plug-In
*
Oracle Cloud Framework 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.
–
–
■
Plug-ins:
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) outside the middleware home,
and stores all configuration information related to the OMS.
For example, if the Middleware home is /u01/app/Oracle/Middleware/, then the
instance base location is /u01/app/Oracle/gc_inst.
■
■
Upgrades the Management Repository in the existing certified database.
For information about the configuration assistants that run to configure the
installed or upgraded components, see Oracle Enterprise Manager Cloud Control
Advanced Installation and Configuration Guide.
The installer does NOT upgrade your existing Management
Agent because it is predeployed by the Preupgrade Console.
Note:
2-18 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
2.2.4.2 Overview of the 2-System Upgrade Process Offered for Upgrading
Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1)
to 12c Release 4 (12.1.0.4)
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.0.43.0
–
Oracle WebLogic Server 11g Release 1 (10.3.6)
–
Oracle Management Service 12c
–
Oracle JRF 11g Release (11.1.1.7.0), which includes oracle_common directory
–
Oracle Web Tier 11g Release (11.1.1.7.0), which includes Oracle_WT directory
–
Oracle BI Publisher 11g (11.1.1.7.0), which includes Oracle_BI1 directory.
Although Oracle BI Publisher 11g (11.1.1.7) is installed by
default, it is not configured. To configure it post installation, follow
the instructions in Oracle Enterprise Manager Cloud Control
Administrator’s Guide.
Note:
Overview of the Upgrade Approaches Offered for Upgrading an Enterprise Manager System 2-19
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
–
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
*
Oracle Cloud Framework 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.6) and JDK
1.6.0.43.0 are installed only if you do not specify the use of existing
installations. Oracle strongly recommends using the 12c installation
process to install the JDK and Oracle WebLogic Server for use with
Enterprise Manager 12c.
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) for storing all configuration
details related to Oracle Management Service 12c, outside the middleware home.
For example, if the Middleware home is /u01/app/Oracle/Middleware/, then the
instance base location is /u01/app/Oracle/gc_inst.
■
■
For information about the configuration assistants that run to configure the
installed or upgraded components, see Oracle Enterprise Manager Cloud Control
Advanced Installation and Configuration Guide.
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:
2-20 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
$<AGENT_HOME>/sysman/install/agentDeploy.sh OMS_HOST=<oms_host_name>
EM_UPLOAD_PORT=<oms_upload_https_port> AGENT_REGISTRATION_
PASSWORD=<agent_reg_password>
2.2.4.3 Overview of the 1-System on a Different Host Upgrade Process Offered for
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release
1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
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.0.43.0
–
Oracle WebLogic Server 11g Release 1 (10.3.6)
–
Oracle Management Service 12c
–
Oracle JRF 11g Release (11.1.1.7.0), which includes oracle_common directory
Overview of the Upgrade Approaches Offered for Upgrading an Enterprise Manager System 2-21
Upgrading Enterprise Manager Cloud Control 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
–
Oracle Web Tier 11g Release (11.1.1.7.0), which includes Oracle_WT directory
–
Oracle BI Publisher 11g (11.1.1.7.0), which includes Oracle_BI1 directory.
Although Oracle BI Publisher 11g (11.1.1.7) is installed by
default, it is not configured. To configure it post installation, follow
the instructions in Oracle Enterprise Manager Cloud Control
Administrator’s Guide.
Note:
–
■
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
*
Oracle Cloud Framework 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)
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) for
storing all configuration details related to Oracle Management Service 12c, outside
the middleware home.
For example, if the Middleware home is /u01/app/Oracle/Middleware/, then the
instance base location is /u01/app/Oracle/gc_inst.
■
For information about the configuration assistants that run to configure the
installed or upgraded components, see Oracle Enterprise Manager Cloud Control
Advanced Installation and Configuration Guide.
2-22 Oracle Enterprise Manager Cloud Control Upgrade Guide
3
Things to Know About Upgrading an
Enterprise Manager System
3
Before you use the upgrade approaches to upgrade to Enterprise Manager Cloud
Control, keep these points in mind:
■
Supported Upgrade Paths and Supported Upgrade Approaches for Upgrading an
Enterprise Manager System
■
Platforms Supported for Upgrading an Enterprise Manager System
■
Upgrade Scope Offered for Upgrading an Enterprise Manager System
■
Modified or Customized Data After Repository Backup That Are Not Migrated
Via ADMP
■
Ports Used by an Upgraded Enterprise Manager System
■
Upgrading Plug-Ins While Upgrading an Enterprise Manager System
■
Status of Oracle Software Library After Upgrading an Enterprise Manager System
■
Connectors in an Upgraded an Enterprise Manager System
■
■
■
■
■
■
■
■
Updating the PDP Configuration File After Upgrading an Enterprise Manager
System
Notification, Alerts, Jobs, Deployment Procedure Runs, Metrics, EM CLI Clients,
and Oracle Exadata Targets in an Upgraded an Enterprise Manager System
Custom Certificates Configured for OMS and Management Agent Are Reused in
an Upgraded Enterprise Manager System
Redoing Customization on Oracle WebLogic Server After Upgrading an Enterprise
Manager System
Redoing Customization on Deployment Procedures After Upgrading an
Enterprise Manager System
XML DB Feature in the Database After Upgrading an Enterprise Manager System
Manually Restarting the OMS and the Management Agent After Upgrading an
Enterprise Manager System
Enabling Force Logging When Oracle Data Guard Is Configured with the Standby
Database for an Upgraded Enterprise Manager System
Things to Know About Upgrading an Enterprise Manager System
3-1
Supported Upgrade Paths and Supported Upgrade Approaches for Upgrading an Enterprise Manager System
3.1 Supported Upgrade Paths and Supported Upgrade Approaches for
Upgrading an Enterprise Manager System
Table 3–1 lists the supported upgrade paths, and the upgrade approach supported for
each upgrade path.
Table 3–1 Supported Upgrade Paths and Supported Upgrade Approaches for Upgrading
an Enterprise Manager System
Upgrade From
Upgrade To
12c Release 3 Plug-in Upgrade 12c Release 4 (12.1.0.4)
1 (12.1.0.3)
Supported Upgrade
Approach
1-System Upgrade
(12c Release 3 (12.1.0.3) software
with plug-ins released in
October)
12c Release 3 (12.1.0.3)
12c Release 4 (12.1.0.4)
1-System Upgrade
12c Release 2 Plug-in Update
1 (12.1.0.2)
12c Release 4 (12.1.0.4)
1-System Upgrade
12c Release 2 (12.1.0.2)
12c Release 4 (12.1.0.4)
1-System Upgrade
12c Release 1 (12.1.0.1)
patched with Bundle Patch 1
First upgrade to either 12c
Release 2 (12.1.0.2) or 12c
Release 3 (12.1.0.3), and then
upgrade to 12c Release 4
(12.1.0.4).
N/A
12c Release 1 (12.1.0.1)
containing Bundle Patch 1
(included by default)
First upgrade to either 12c
Release 2 (12.1.0.2) or 12c
Release 3 (12.1.0.3), and then
upgrade to 12c Release 4
(12.1.0.4).
N/A
12c Release 1 (12.1.0.1) (base
release)
First upgrade to either 12c
Release 2 (12.1.0.2) or 12c
Release 3 (12.1.0.3), and then
upgrade to 12c Release 4
(12.1.0.4).
N/A
11g Release 1 (11.1.0.1)
12c Release 4 (12.1.0.4)
(12c Release 2 (12.1.0.2) software
with plug-ins released in
February 2013)
■
1-System Upgrade
■
2-System Upgrade
■
10g Release 5 (10.2.0.5)
12c Release 4 (12.1.0.4)
1-System Upgrade on a
Different Host
■
1-System Upgrade
■
2-System Upgrade
■
1-System Upgrade on a
Different Host
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 3 (12.1.0.3)
N/A
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 3 (12.1.0.3)
N/A
3-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrade Scope Offered for Upgrading an Enterprise Manager System
3.2 Platforms Supported for Upgrading an Enterprise Manager System
The following platforms are supported for upgrading an Enterprise Manager system:
■
■
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 and 1-System upgrade on a different host are possible on the
same platform as the earlier release of the Enterprise Manager system, or any
platform that is supported for Enterprise Manager Cloud Control 12c. For
information on the certified platforms, see the Enterprise Manager certification
matrix as described in Oracle Enterprise Manager Cloud Control Basic Installation
Guide.
3.3 Upgrade Scope Offered for Upgrading an Enterprise Manager System
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).
As a best practice, back up your old and new homes regularly.
■
■
For upgrading an additional OMS, always choose to use only 1-System upgrade
approach.
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 can communicate only with the following
versions of Oracle Management Agent 12c:
Table 3–2
Compatibility Between OMS and Management Agents Across 12c Releases
Oracle
Management
Agent 12c
Release 1
(12.1.0.1) +
Bundle Patch 1
Oracle
Management
Agent 12c
Release 2
(12.1.0.2)
Oracle
Management
Agent 12c
Release 3
(12.1.0.3)
Oracle
Management
Agent 12c
Release 4
(12.1.0.4)
(Refers to agents
and their plug-ins
patched or
upgraded to, or
installed with
Bundle Patch 1)
Things to Know About Upgrading an Enterprise Manager System
3-3
Upgrade Scope Offered for Upgrading an Enterprise Manager System
Table 3–2 (Cont.) Compatibility Between OMS and Management Agents Across 12c
No
No
No
Yes
No
No
Oracle
Yes
Yes
Management
(Only
Service 12c Release
Management
3 (12.1.0.3)
Agents released in
January 2012 [with
Bundle Patch 1])
Yes
No
Oracle
No
Management
Service 12c Release
4 (12.1.0.4)
Yes
Yes
Oracle
Management
Service 12c Release
1 (12.1.0.1) +
Bundle Patch 1
Yes
(includes
Management
Agents with and
without Bundle
Patch 1)
Oracle
Yes
Management
(includes
Service 12c Release
Management
2 (12.1.0.2)
Agents with and
without Bundle
Patch 1)
■
■
■
Yes
You can upgrade any Management Agent on any platform as long as the Oracle
Management Agent 12c software for that platform is available.
The Enterprise Manager Cloud Control Installation Wizard installs Java
Development Kit (JDK) 1.6.0.43.0 and Oracle WebLogic Server 11g Release 1
(10.3.6) if they do not exist in your environment.
If Oracle WebLogic Server 11g Release 1 (10.3.6) 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.0.43.0
(64-bit version for 64-bit platforms and 32-bit version for 32-bit platforms).
–
Download JDK 1.6.0.43.0 for your platform from the platform vendor’s Web
site.
For example, download SUN JDK 1.6.0.43.0 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.6)
on Linux 64-bit platforms, first install the 64-bit JDK for your platform, and
then download and use the wls1036_generic.jar file to install Oracle
WebLogic Server.
For example,
3-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Modified or Customized Data After Repository Backup That Are Not Migrated Via ADMP
<JDK home>/bin/java -d64 -jar <absolute_path _to_wls1036_
generic.jar>
–
If you want to manually install Oracle WebLogic Server 11g Release 1 (10.3.6)
on Linux 32-bit platforms, then download and use either the wls1036_
linux32.bin file or the wls1036_generic.jar file.
For example,
<JDK home>/bin/java
–
-jar <absolute_path _to_wls1036_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.
–
After installing Oracle WebLogic Server, as a postinstall step, apply the
patches 14482558, 13349651, and 16080294 on it. Without these patches, the
additional OMS installation will fail. However, these patches are required only
if you are manually installing the Oracle WebLogic Server.
For instructions to apply these patches, see the following URL:
http://docs.oracle.com/cd/E14759_
01/doc.32/e14143/intro.htm#CHDCAJFC
For more information on Oracle WebLogic Server downloads and demos,
access the following URL:
http://www.oracle.com/technology/products/weblogic/index.html
■
You must ensure that the Oracle WebLogic Server 11g Release 1 (10.3.6) 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.
3.4 Modified or Customized Data After Repository Backup That Are Not
Migrated Via ADMP
After upgrading from 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release
X (12.1.0.X) using the 2-system upgrade approach, a post-upgrade activity called
Accrued Data Migration is run to migrate all accrued data stored in the old Management
Repository to the upgraded Management Repository. The accrued data relates to
functional areas such as blackouts, alerts, events, metrics, and so on. For more
information on Accrued Data Migration, see Section 12.8.1.
Things to Know About Upgrading an Enterprise Manager System
3-5
Ports Used by an Upgraded Enterprise Manager System
However, this Accrued Data Migration process does not migrate any of the following
changes if they were done after the Management Repository was backed up. If you
want these changes in the upgraded Enterprise Manager system, you must manually
redo these changes after upgrade.
■
Security data (new users created, passwords changed)
■
Jobs created, deleted, or submitted
■
Customized deployment procedures
■
Patches
■
Targets added or deleted
■
Reports created, modified, or deleted
■
Software Library configuration changes
■
Templates created, modified, or deleted
■
User-defined metrics
3.5 Ports Used by an Upgraded Enterprise Manager System
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, new ports that you accept or specify in the
installer are assigned to all the core components.
For 1-System upgrade approach, the following is the behavior:
–
If you are upgrading 12c Release 3 (12.1.0.3) or 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, new ports that you accept or
specify in the installer are assigned.
*
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
For 1-System upgrade approach on a different host, new ports that you pass in a
response file while configuring the OMS are assigned to all the core components.
3-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Plug-Ins While Upgrading an Enterprise Manager System
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.
Note:
For information about what URLs should be made available through a
firewall, when a firewall is configured for the OMS, see Oracle
Enterprise Manager Cloud Control Advanced Installation and Configuration
Guide.
3.6 Upgrading Plug-Ins While Upgrading an Enterprise Manager System
This section describes the following:
■
■
Upgrading Plug-Ins While Upgrading Enterprise Manager Cloud Control 12c
Release 3 (12.1.0.3), 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Upgrading Plug-Ins While Upgrading Enterprise Manager Cloud Control 10g
Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
3.6.1 Upgrading Plug-Ins While Upgrading Enterprise Manager Cloud Control 12c
Release 3 (12.1.0.3), 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
This section describes how plug-ins are upgraded while upgrading Oracle
Management Agents and Oracle Management Service of 12c Release 3 (12.1.0.3) or 12c
Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4).
In particular, this section describes the following:
■
■
Upgrading Plug-Ins While Upgrading Oracle Management Agent 12c Release 3
(12.1.0.3), 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Upgrading Plug-Ins While Upgrading Oracle Management Service 12c Release 3
(12.1.0.3), 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
3.6.1.1 Upgrading Plug-Ins While Upgrading Oracle Management Agent 12c
Release 3 (12.1.0.3), 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
While upgrading Oracle Management Agents 12c Release 3 (12.1.0.3) or 12c Release 2
(12.1.0.2) to 12c Release 4 (12.1.0.4) using the Agent Upgrade Console, all plug-ins of
the earlier release are upgraded by default. No manual effort is required.
3.6.1.2 Upgrading Plug-Ins While Upgrading Oracle Management Service 12c
Release 3 (12.1.0.3), 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
While upgrading Oracle Management Service 12c Release 3 (12.1.0.3) or 12c Release 2
(12.1.0.2) to 12c Release 4 (12.1.0.4) 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,
or when there are any new default plug-ins introduced with a release.
Things to Know About Upgrading an Enterprise Manager System
3-7
Upgrading Plug-Ins While Upgrading an Enterprise Manager System
Oracle Cloud Framework Plug-In is an additional default
plug-in introduced with 12c Release 4 (12.1.0.4), so this plug-in is
deployed automatically.
Note:
In addition, the installation wizard provides a Select Plug-ins 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 Select Plug-ins screen, then
follow these steps:
1.
Access the following Enterprise Manager download page on Oracle Technology
Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrad
e-console-502238.html
2.
Expand the section that lists the software binaries and plug-ins for your upgrade
path.
3.
From the Download Plug-ins section, manually download the plug-ins and store
them in an accessible location.
4.
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>
3.6.2 Upgrading Plug-Ins While Upgrading Enterprise Manager Cloud Control 10g
Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
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), 11g Release 1 (11.1.0.1),
and Oracle Management Service 10g Release 5 (10.2.0.5), 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 4 (12.1.0.4)
Installing Plug-Ins While Upgrading Oracle Management Service 10g Release 5
(10.2.0.5) and 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
3-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Plug-Ins While Upgrading an Enterprise Manager System
3.6.2.1 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 4 (12.1.0.4)
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-upgrad
e-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.
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.
Note:
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 Section 9.4.
3.6.2.2 Installing Plug-Ins While Upgrading Oracle Management Service 10g
Release 5 (10.2.0.5) and 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
To install the required plug-ins while upgrading the OMS, invoke the Enterprise
Manager Cloud Control Installation Wizard, and proceed to the Select Plug-ins 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.
Things to Know About Upgrading an Enterprise Manager System
3-9
Status of Oracle Software Library After Upgrading an Enterprise Manager System
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.
Note:
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:
1.
Access the following Enterprise Manager download page on Oracle Technology
Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrad
e-console-502238.html
2.
Expand the section that lists the software binaries and plug-ins for your upgrade
path.
3.
From the Download Plug-ins section, manually download the plug-ins and store
them in an accessible location.
4.
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>
3.7 Status of Oracle Software Library After Upgrading an Enterprise
Manager System
(This section is applicable only if Software Library was configured in the earlier release of
Enterprise Manager)
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 Section 8.2. For information about
reconfiguring the Software Library, see Section 12.4.
■
For 1-System upgrade approach on a different host, the Software Library is
functional the moment the Enterprise Manager is upgraded. This is however true
only when all the files in the Software Library file system location configured for
the old Enterprise Manager system is accessible for read/write from the new host.
If not, the upgrade fails.
3-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Notification, Alerts, Jobs, Deployment Procedure Runs, Metrics, EM CLI Clients, and Oracle Exadata Targets in an Upgraded an
3.8 Connectors in an Upgraded an Enterprise Manager System
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.
3.9 Updating the PDP Configuration File After Upgrading an Enterprise
Manager System
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) or higher, 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 12c Release 1 (12.1.0.1) [with or without
Bundle Patch 1] to 12c Release 2 (12.1.0.2) or higher, 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 *
3.10 Notification, Alerts, Jobs, Deployment Procedure Runs, Metrics, EM
CLI Clients, and Oracle Exadata Targets in an Upgraded an Enterprise
Manager System
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) to 12c Release X (12.1.0.X).
Note:
You can ignore this section if you are upgrading within the 12c release,
for example, from 12c Release 2 (12.1.0.2) or 12c Release 3 (12.1.0.3) to
12c Release 4 (12.1.0.4).
This section describes some of the critical changes in Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4) 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:
■
Notification in an Upgraded an Enterprise Manager System
Things to Know About Upgrading an Enterprise Manager System 3-11
Notification, Alerts, Jobs, Deployment Procedure Runs, Metrics, EM CLI Clients, and Oracle Exadata Targets in an Upgraded an
■
Alerts in an Upgraded an Enterprise Manager System
■
Jobs in an Upgraded Enterprise Manager System
■
Deployment Procedures in an Upgraded Enterprise Manager System
■
Metrics Renamed in an Upgraded Enterprise Manager System
■
Upgrading EM CLI Clients After Upgrading an Enterprise Manager System
■
Upgrading Oracle Exadata Targets After Upgrading an Enterprise Manager
System
3.10.1 Notification in an Upgraded an Enterprise Manager System
During upgrade, the out-of-box rule sets are re-registered, and as a result, you will lose
e-mail subscriptions made to them. Therefore, before starting the upgrade process,
Oracle strongly recommends that you make a copy (using the Create Like action) of the
out-of-box rule sets.
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.
3.10.2 Alerts in an Upgraded an Enterprise Manager System
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:
■
■
■
Alerts Migrated in an Upgraded Enterprise Manager System
Incidents and Events Created for Different Types of Open Alerts in an Upgraded
Enterprise Manager System
Incidents and Events Created for Different Types of Closed Alerts in an Upgraded
Enterprise Manager System
3.10.2.1 Alerts Migrated in an Upgraded Enterprise Manager System
The following are the ways in which the alerts are migrated:
■
All open alerts are migrated.
Table 3–3 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 3–4 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.
3-12 Oracle Enterprise Manager Cloud Control Upgrade Guide
Notification, Alerts, Jobs, Deployment Procedure Runs, Metrics, EM CLI Clients, and Oracle Exadata Targets in an Upgraded an
■
All open statefull alerts, and open stateless alerts created within 7 days prior to
upgrading or backing up the Management Repository are migrated.
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 3–3). In
addition, all availability records are also migrated as part of the
Accrued Data Migration Process.
Note:
3.10.2.2 Incidents and Events Created for Different Types of Open Alerts in an
Upgraded Enterprise Manager System
Table 3–3 shows how and when incidents and events are created for different types of
open alerts.
Table 3–3
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
3.10.2.3 Incidents and Events Created for Different Types of Closed Alerts in an
Upgraded Enterprise Manager System
Table 3–4 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 3–4
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
Things to Know About Upgrading an Enterprise Manager System 3-13
Notification, Alerts, Jobs, Deployment Procedure Runs, Metrics, EM CLI Clients, and Oracle Exadata Targets in an Upgraded an
3.10.3 Jobs in an Upgraded Enterprise Manager System
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 or 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
3-14 Oracle Enterprise Manager Cloud Control Upgrade Guide
Notification, Alerts, Jobs, Deployment Procedure Runs, Metrics, EM CLI Clients, and Oracle Exadata Targets in an Upgraded an
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.
3.10.4 Deployment Procedures in an Upgraded Enterprise Manager System
After upgrading the entire Enterprise Manager system, none of the 10g Release 5
(10.2.0.5) or 11g Release 1(11.1.0.1) 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
Things to Know About Upgrading an Enterprise Manager System 3-15
Custom Certificates Configured for OMS and Management Agent Are Reused in an Upgraded Enterprise Manager System
3.10.5 Metrics Renamed in an Upgraded Enterprise Manager System
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
3.10.6 Upgrading EM CLI Clients After Upgrading an Enterprise Manager System
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.
3.10.7 Upgrading Oracle Exadata Targets After Upgrading an Enterprise Manager
System
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.
3.11 Custom Certificates Configured for OMS and Management Agent
Are Reused in an Upgraded Enterprise Manager System
When you upgrade to 12c Release 4 (12.1.0.4), all custom certificates configured for the
upload and console ports of the OMS, and all custom certificates configured for the
Management Agents are automatically carried over from the previous release and are
preserved in the upgraded release. You do not have to reconfigure any of these custom
certificates.
3.12 Redoing Customization on Oracle WebLogic Server After Upgrading
an Enterprise Manager System
When you upgrade from 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c
Release 4 (12.1.0.4), all authentication configuration details related to the WebLogic
Server are automatically carried over from the previous release and are preserved in
the upgraded release. You do not have to reconfigure the external authentication after
you upgrade.
3-16 Oracle Enterprise Manager Cloud Control Upgrade Guide
Enabling Force Logging When Oracle Data Guard Is Configured with the Standby Database for an Upgraded Enterprise Man-
However, any other customizations to the WebLogic Server, such as the third-party
custom certificates, must be redone.
3.13 Redoing Customization on Deployment Procedures After Upgrading
an Enterprise Manager System
If you have customized any deployment procedure in 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1), then while upgrading to 12c Release X (12.1.0.X), the customization
is not carried over. You must redo the customization after upgrading to 12c Release X
(12.1.0.X).
Similarly, even the customization done to any deployment procedure within a 12c
release is not carried over when you upgrade to another higher release of 12c. For
example, customization done to a deployment procedure in 12c Release 3 (12.1.0.3) is
not carried over automatically when you upgrade to 12c Release 4 (12.1.0.4). Therefore,
you must redo the customization after upgrading to any higher release of 12c.
3.14 XML DB Feature in the Database After Upgrading an Enterprise
Manager System
Enterprise Manager is not affected when you enable or disable features such as XML
DB on the Oracle Database in which you plan to configure the Management
Repository. Therefore, you can enable or disable any feature in the database because
Enterprise Manager does not rely on them.
3.15 Manually Restarting the OMS and the Management Agent After
Upgrading an Enterprise Manager System
If you install the OMS and the Oracle Database, which houses the Management
Repository, on the same host, then when you reboot the host, the OMS and the
Management Agent installed with it will not automatically start up. You will have to
manually start them.
3.16 Enabling Force Logging When Oracle Data Guard Is Configured with
the Standby Database for an Upgraded Enterprise Manager System
If you have Oracle Data Guard configured with your standby database, then enable
force logging on the database using the following command:
ALTER DATABASE force logging;
If you do not enable force logging on the database, then use of NOLOGGING commands
while upgrading the Enterprise Manager system might corrupt your standby
database.
Things to Know About Upgrading an Enterprise Manager System 3-17
Enabling Force Logging When Oracle Data Guard Is Configured with the Standby Database for an Upgraded Enterprise Man-
3-18 Oracle Enterprise Manager Cloud Control Upgrade Guide
Part II
Part II
Upgrading Enterprise Manager Cloud Control
12c Release 3 (12.1.0.3) or 12c Release 2
(12.1.0.2) to 12c Release 4 (12.1.0.4)
This part describes how you can upgrade Enterprise Manager Cloud Control 12c
Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4).
This part covers the following chapters:
■
■
Chapter 4, "Getting Started with Upgrading Enterprise Manager Cloud Control
12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)"
Chapter 5, "Upgrading Oracle Management Service and Oracle Management
Repository 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
(12.1.0.4)"
■
Chapter 6, "Upgrading Oracle Management Agents"
■
Chapter 7, "Upgrading or Redeploying ADP and JVMD"
4
Getting Started with Upgrading Enterprise
Manager Cloud Control 12c Release 3 (12.1.0.3)
or 12c Release 2 (12.1.0.2) to 12c Release 4
(12.1.0.4)
4
This chapter describes the high-level process for upgrading your Enterprise Manager
12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4).
In particular, this chapter covers the following:
■
■
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c
Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4) in a Single-OMS or Multi-OMS
Non-HA Environment
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c
Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4) in an HA Environment (Primary and
Standby Sites)
Getting Started with Upgrading Enterprise Manager Cloud Control(12.1.0.2)
12c Release
to 12c
3 (12.1.0.3)
Release or
4 (12.1.0.4)
12c Release
4-1
2
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Note:
■
If you have Oracle Management Service 12c Release 1 (12.1.0.1)
[with or without Bundle Patch 1], then first upgrade it to either
12c Release 2 (12.1.0.2) or 12c Release 3 (12.1.0.3), and then
upgrade to 12c Release 4 (12.1.0.4).
For instructions to upgrade to 12c Release 2 (12.1.0.2) or 12c
Release 3 (12.1.0.3), refer to the Oracle Enterprise Manager Cloud
Control Upgrade Guide for the respective release, available in the
Enterprise Manager documentation library:
http://docs.oracle.com/cd/E24628_01/index.htm
■
If you have Oracle Management Agent 12c Release 1 (12.1.0.1) that
communicates with Oracle Management Service 12c Release 2
(12.1.0.2) or 12c Release 3 (12.1.0.3), then before upgrading the
Oracle Management Service to 12c Release 4 (12.1.0.4), make sure
you upgrade your Oracle Management Agent 12c Release 1
(12.1.0.1) to either 12c Release 2 (12.1.0.2) or 12c Release 3 (12.1.0.3)
using the Agent Upgrade Console present within the Enterprise
Manager Cloud Control Console.
This is a prerequisite for upgrading your Oracle Management
Service 12c Release 2 (12.1.0.2) or 12c Release 3 (12.1.0.3) to 12c
Release 4 (12.1.0.4).
■
For additional preparatory steps to be taken for a successful
upgrade, see My Oracle Support note 1682332.1.
Do not upgrade 12c Release 3 (12.1.0.3) or 12c Release 2
(12.1.0.2) while it is undergoing a 2-system upgrade from its earlier
release (10.2.0.5 or 11.1.0.1). Wait until the upgrade completes fully
because there might be some standalone Management Agents in
status pending state while the upgrade is in progress.
WARNING:
4.1 Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3)
or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4) in a Single-OMS or
Multi-OMS Non-HA Environment
Before you begin upgrading the Enterprise Manager system,
Oracle recommends that review the Oracle Enterprise Manager Cloud
Control Basic Installation Guide to learn about the plug-ins released in
September 2014, October 2014, and January 2015, and to understand
the use cases pertaining to this plug-in release. Identify the use case
that best suits your requirement, and follow the high-level instructions
provided against that use case in the table.
Note:
Table 4–1 describes the steps for upgrading your Enterprise Manager to 12c Release 4
(12.1.0.4) in a single-OMS or multi-OMS non-HA (or non-high availability)
environment.
4-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Table 4–1 Upgrading Enterprise Manager Cloud Control to 12c Release 4 (12.1.0.4) in a
Single-OMS Non-HA Environment
Step
No.
Step
Procedure
Step 1 Prepare Yourself
(a)
Learn about the 1-System upgrade approach.
Section 2.1
(b)
Review the important facts you need to know before you begin.
Chapter 3
Step 2 Upgrade Oracle Management Service and Oracle Management
Repository
Getting Started with Upgrading Enterprise Manager Cloud Control(12.1.0.2)
12c Release
to 12c
3 (12.1.0.3)
Release or
4 (12.1.0.4)
12c Release
4-3
2
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Table 4–1 (Cont.) Upgrading Enterprise Manager Cloud Control to 12c Release 4
(12.1.0.4) in a Single-OMS Non-HA Environment
Step
No.
Step
(a)
Meet the following prerequisites:
■
■
■
■
■
■
Procedure
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.
Upgrade to 12c Release 4 (12.1.0.4) is an out-of-place upgrade,
therefore make sure your host meets the hardware requirements
specific to 12c Release 4 (12.1.0.4) as described in Oracle Enterprise
Manager Cloud Control Basic Installation Guide. Here, host refers to the
host on which your current Enterprise Manager, which you want to
upgrade, is running.
Ensure that you are upgrading only on the supported platforms as
listed in Section 3.2.
Ensure that the ports used by Enterprise Manager are not set to a
value lower than or equal to 1024. If they are, then the upgrade will
fail. Ports up to 1024 are typically reserved for root users (super users).
Therefore, make sure the ports are greater than 1024.
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.
Make a copy (using the Create Like action) of the out-of-box rule sets
you are using to receive e-mail notifications. Otherwise, you will lose
the e-mail subscriptions made to the rule sets.
To make a copy, from the Setup menu, select Incidents, then select
Incident Rules. On the Incident Rules - All Enterprise Rules page, in
the table, select the out-of-box rule set you want to copy. Then, from
the Actions menu, select Create Like Rule Set. In the Create Like Rule
Set page, provide the required details and click Save.
■
Ensure that the contents of the following directory across OMS hosts
are the same. If the number of plug-ins and/or their revisions are
different across OMS hosts, then ensure that you copy them over from
one pluginextract_with_rev directory to another to make them
consistent.
<OMS_HOME>/sysman/install/pluginextract_with_rev
For example, on the first OMS host, OMS_Host1, you may have the
following plug-ins and revisions:
oracle.sysman.emfa 12.1.0.1.0 and 12.1.0.2.0; oracle.sysman.bda
12.1.0.1.0, 12.1.0.2.0, and 12.1.0.3.0; and oracle.em.sidb 12.1.0.1.0 and
12.1.0.2.0.
On the additional OMS host, OMS_Host2, you may have the
following plug-ins: oracle.sysman.emfa 12.1.0.1.0 and 12.1.0.2.0;
oracle.sysman.bda 12.1.0.3.0; and oracle.em.sehc 12.1.0.1.0.
In this case, ensure that you copy oracle.sysman.bda 12.1.0.1.0 and
12.1.0.2.0, and oracle.em.sidb 12.1.0.1.0 and 12.1.0.2.0 from the first
OMS host to the additional OMS host, and ensure that you copy
oracle.em.sehc 12.1.0.1.0 from the additional OMS host to the first
OMS host. This way, the plug-ins and their revisions in both OMS
hosts will be consistent.
■
If you done any of the following customization to the OMS, then
ensure that you remove all of them before starting the upgrade
process. Once the upgrade is complete, you can redo the
customization.
■
Configuring additional data source
parameters in Weblogic.
4-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
■
Additional third-party SSL certificate.
■
Smart card authentication for Enterprise
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Table 4–1 (Cont.) Upgrading Enterprise Manager Cloud Control to 12c Release 4
(12.1.0.4) in a Single-OMS Non-HA Environment
Step
No.
(b)
Step
Procedure
If you have Oracle BI Publisher installed on the Enterprise Manager Cloud
Control 12c installation that you are upgrading, then stop the BI Publisher
Managed Server named BIP using the WebLogic Administration Console.
As part of the upgrade to Enterprise Manager Cloud Control 12c Release 4
(12.1.0.4), Oracle BI Publisher 11.1.1.7.0 is automatically installed in the
middleware home. However, although Oracle BI Publisher is installed by
default, it is not configured or upgraded from the earlier version by
default. Therefore, after upgrading to 12c Release 4 (12.1.0.4), you must
manually configure Oracle BI Publisher, and migrate all the data and
reports from the old BI Publisher home to the new one. For instructions,
see Step 4 (f).
(c)
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 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.
(d)
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
owner='<EM_REPOS_USER>
from all_mview_logs where log_
For example,
select master , log_table
owner='SYSMAN'
from all_mview_logs where log_
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
Getting Started with Upgrading Enterprise Manager Cloud Control(12.1.0.2)
12c Release
to 12c
3 (12.1.0.3)
Release or
4 (12.1.0.4)
12c Release
4-5
2
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Table 4–1 (Cont.) Upgrading Enterprise Manager Cloud Control to 12c Release 4
(12.1.0.4) in a Single-OMS Non-HA Environment
Step
No.
(e)
Step
Ensure that you do not have any login or logoff triggers set in the Oracle
Database that houses the Oracle Management Repository.
To verify this, log into the database and run the following query:
■
Verify if any login triggers are set:
SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers WHERE
TRIGGERING_EVENT LIKE 'LOGIN%' AND status='ENABLED';
SQL> SELECT trigger_name FROM sys.dba_triggers WHERE
TRIGGERING_EVENT LIKE 'LOGIN%' AND status='ENABLED';
■
Verify if any logoff triggers are set:
SQL> SELECT COUNT (trigger_name) FROM sys.dba_triggers WHERE
TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';
SQL> SELECT trigger_name FROM sys.dba_triggers WHERE
TRIGGERING_EVENT LIKE 'LOGOFF%' AND status='ENABLED';
If the query results in anything other than zero or no rows selected, then
manually disable the triggers. After completing the upgrade, you can
enable them again.
To disable the triggers, run the following query:
SQL> alter trigger <trigger_name> disable;
For example,
SQL> alter trigger EXPFIL_ALTEREXPTAB_MAINT disable;
(f)
(CRITICAL MANDATORY STEP)
Apply the following patches on the database. You can access My Oracle
Support and search for these patches. For instructions, see the ReadMe file
associated with the patch. If you do not apply these patches, you will run
into upgrade failures that cannot be corrected.
For Oracle Database 11 Release 1 (11.1.0.7)
■
■
On Unix platforms, apply patch 17082366 (Patch Set Update 17). Then
apply patch 9577583 and patch 8405205.
On Microsoft Windows (32 bit and 64 bit) platforms, apply patch
17363760 (Patch 54).
For Oracle Database 11g Release 2 (11.2.0.1)
■
■
On Unix platforms, apply patch 12419378 (Patch Set Update 6).
On Microsoft Windows (64 bit) platforms, apply patch 13423278 (Patch
16).
For Oracle Database 11g Release 2 (11.2.0.2)
■
■
■
On Unix platforms, apply patch 11061801 and patch 9748749.
On Microsoft Windows (32 bit) platforms, apply patch 11061801 and
patch 12429530.
On Microsoft Windows (64-bit) platforms, apply patch 11061801 and
patch 12429531.
For Oracle Database 11g Release 2 (11.2.0.3), 10g Release 2 (10.2.0.5)
On Unix as well as Microsoft Windows platforms, apply the patch
11061801.
Note: Oracle also recommends that you apply patch 13496395. For
information on what database releases you can apply the patch, see the
ReadMe that is packaged with the patch.
4-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Procedure
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Table 4–1 (Cont.) Upgrading Enterprise Manager Cloud Control to 12c Release 4
(12.1.0.4) in a Single-OMS Non-HA Environment
Step
No.
(g)
Step
Procedure
[IN CASE OF MULTI-OMS UPGRADE, PERFORM THIS STEP ONLY
FOR THE FIRST OMS UPGRADE]
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".
(h)
If you have changed the default, out-of-box memory settings for an OMS
instance, then preserve the changes so that they are not lost during
upgrade.
To preserve the changes, follow these steps:
1.
Run the following command on all the OMS instances:
$<OMS_HOME>/bin/emctl set property -name 'JAVA_EM_MEM_ARGS'
-value '<java_memory_arguments>'
For example,
$<OMS_HOME>/bin/emctl set property -name 'JAVA_EM_MEM_ARGS'
-value '-Xms256m -Xmx1740m'
2.
Restart all the OMS instances:
$<OMS_HOME>/bin/emctl stop oms -all
$<OMS_HOME>/bin/emctl start oms
Getting Started with Upgrading Enterprise Manager Cloud Control(12.1.0.2)
12c Release
to 12c
3 (12.1.0.3)
Release or
4 (12.1.0.4)
12c Release
4-7
2
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Table 4–1 (Cont.) Upgrading Enterprise Manager Cloud Control to 12c Release 4
(12.1.0.4) in a Single-OMS Non-HA Environment
Step
No.
(i)
Step
Procedure
Shut down the OMS you are about to upgrade and also the other OMS
instances that connect to it.
IMPORTANT: If you are upgrading a multi-OMS environment using the
software-only upgrade approach, then skip this step. You can stop the
OMS instances after copying the software binaries as described in
Section 5.3.1 or Section 5.4.1.
1.
As a prerequisite, stop the JVMD and ADP engines explicitly:
■
To stop them in silent mode, run the
following commands:
$<OMS_HOME>/bin/emctl extended oms
jvmd stop -all
$<OMS_HOME>/bin/emctl extended oms
adp stop –all
■
2.
To stop them in graphical mode, access
the weblogic console, and stop the JVMD
and ADP weblogic managed servers
manually.
Now shut down the OMS you are about to upgrade and also the other
OMS instances that connect to it:
$<OMS_HOME>/bin/emctl stop oms -all
(j)
Shut down the Management Agent that monitors the Management Services
and Repository target, to prevent the Management Agent from connecting to
the Management Repository for metric collections. Not shutting down this
Management Agent might cause the OMS upgrade to fail.
IMPORTANT: If you are upgrading a multi-OMS environment using the
software-only upgrade approach, then skip this step. You can stop the
Management Agent after copying the software binaries as described in
Section 5.3.1 or Section 5.4.1.
4-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Table 4–1 (Cont.) Upgrading Enterprise Manager Cloud Control to 12c Release 4
(12.1.0.4) in a Single-OMS Non-HA Environment
Step
No.
(k)
Step
Procedure
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.
Section 5.1,
Section 5.2,
Section 5.3, or
Section 5.4
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
For example,
/u01/software/oracle/middleware/oms/bin/emctl config emkey
-copy_to_repos_from_file -repos_conndesc
’"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost.mydomain.com)(PORT=
1521)))(CONNECT_DATA=(SID=emrepos12)))"’ -repos_user sysman
-emkey_file
/u01/software/oracle/middleware/oms/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. To upgrade this Management Agent, use the Agent Upgrade
Console.
Step 3 Upgrade Oracle Management Agent
(a)
Review the important facts you need to know before you begin upgrading
the Management Agents.
Section 6.2
(b)
Meet the prerequisites.
Section 6.3
(c)
Ensure that you restart the Management Agent that you shut down in Step
2 (j).
(d)
Upgrade the Management Agents.
Section 6.4
IMPORTANT: Upgrade the Management Agent that was installed with
the old OMS (that is, central agent) immediately after upgrading the old
OMS. To upgrade this Management Agent, use the Agent Upgrade
Console.
Step 4 Perform Postupgrade Task
(a)
Perform postupgrade tasks.
Section 12.6.1
(b)
Reconfigure Oracle WebLogic Server with custom certificates
Section 12.6.14
(c)
Track the status of deferred data migration jobs.
Section 12.7.2
(d)
Delete unwanted central agents
Section 12.13.2
(e)
Upgrade Application Dependency and Performance (ADP) engines and
JVM Diagnostics (JVMD) engines
Chapter 7
Getting Started with Upgrading Enterprise Manager Cloud Control(12.1.0.2)
12c Release
to 12c
3 (12.1.0.3)
Release or
4 (12.1.0.4)
12c Release
4-9
2
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Table 4–1 (Cont.) Upgrading Enterprise Manager Cloud Control to 12c Release 4
(12.1.0.4) in a Single-OMS Non-HA Environment
Step
No.
(f)
Step
Procedure
As part of the upgrade to Enterprise Manager Cloud Control 12c Release 4
(12.1.0.4), Oracle BI Publisher 11.1.1.7.0 is automatically installed.
Therefore, do not perform a software-only install of any version of Oracle
BI Publisher in the middleware home that contains Enterprise Manager
Cloud Control 12c Release 4 (12.1.0.4). However, although Oracle BI
Publisher is installed by default, it is not configured or upgraded from the
earlier version by default.
For
configuring
the newly
installed
Oracle BI
Publisher, see
Oracle
Enterprise
Manager
Advanced
Installation and
Configuration
Guide.
■
■
If you did not have Oracle BI Publisher in your earlier release, then
configure the newly installed one.
If you already had Oracle BI Publisher in your earlier release, then
upgrade the earlier one, and migrate all the data and reports from the
old Oracle BI Publisher home to new one.
For upgrading
Oracle BI
Publisher and
migrating the
reports, see
Oracle
Enterprise
Manager Cloud
Control
Advanced
Installation and
Configuration
Guide.
(g)
Delete old OMS home
Section 12.15
4.2 Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3)
or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4) in an HA
Environment (Primary and Standby Sites)
This section describes how you can upgrade your primary as well as standby
Enterprise Manager sites to 12c Release 4 (12.1.0.4) in an HA (or high availability)
environment. In particular, this section covers the following:
■
■
Upgrading Primary and Standby OMS Instances When the Standby OMS Is
Created Using Storage Replication
Upgrading Primary and Standby OMS Instances When the Standby OMS Is
Created Using Standby WebLogic Domain
Before you begin upgrading the Enterprise Manager system,
Oracle recommends that review the Oracle Enterprise Manager Cloud
Control Basic Installation Guide to learn about the plug-ins released in
September 2014, October 2014, and January 2015, and to understand
the use cases pertaining to this plug-in release. Identify the use case
that best suits your requirement, and follow the high-level instructions
provided against that use case in the table.
Note:
4-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
4.2.1 Upgrading Primary and Standby OMS Instances When the Standby OMS Is
Created Using Storage Replication
Table 4–2 describes the steps for upgrading your primary and standby OMS instances
when the standby OMS is created using Storage Replication.
You do not have to remove the standby OMS as part of this
procedure.
Note:
Table 4–2 Upgrading Primary and Standby OMS Instances When the Standby OMS Is
Created Using Storage Replication
Step No.
Step
Step 1
Upgrade the Primary OMS
Procedure
Upgrade the primary Enterprise Manager Section 4.1
site, both OMS and Management Agents.
There will be some downtime as the
primary OMS will go down during
upgrade process.
Step 2
Verify the New Middleware Home on
the Standby Storage Server
Contact your system administrator to
make sure that the new middleware home
is also replicated to the standby storage
server.
4.2.2 Upgrading Primary and Standby OMS Instances When the Standby OMS Is
Created Using Standby WebLogic Domain
Table 4–3 describes the steps for upgrading your primary and standby OMS instances
when the standby OMS is created using Standby WebLogic Domain.
Table 4–3 Upgrading Primary and Standby OMS Instances When the Standby OMS Is
Created Using Standby WebLogic Domain
Step No.
Step
Procedure
Step 1
Remove the Standby OMS
(a)
Remove all additional standby OMS
instances.
To remove all additional standby OMS
instances, see the section on removing
additional standby OMS instances in
Oracle Enterprise Manager Advanced
Installation and Configuration Guide.
(b)
Remove the first standby OMS.
To remove the first standby OMS, see
the section on removing the first
standby OMS in Oracle Enterprise
Manager Advanced Installation and
Configuration Guide.
Step 2
Upgrade the Primary OMS
Upgrade the primary Enterprise Manager Section 4.1
site, both OMS and Management Agents.
Step 3
Redeploy the Standby OMS
Getting Started with Upgrading Enterprise Manager Cloud Control
(12.1.0.2)
12c Release
to 12c
3 (12.1.0.3)
Release 4or
(12.1.0.4)
12c Release
4-11
2
Upgrading Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4)
Table 4–3 (Cont.) Upgrading Primary and Standby OMS Instances When the Standby
OMS Is Created Using Standby WebLogic Domain
Step No.
Step
Procedure
Re-create the standby OMS environment
using Standby WebLogic Domain.
To re-create the standby OMS
environment using Standby WebLogic
Domain, see the chapter on disaster
recovery in Oracle Enterprise Manager
Cloud Control Administrator's Guide.
4-12 Oracle Enterprise Manager Cloud Control Upgrade Guide
5
Upgrading Oracle Management Service and
Oracle Management Repository 12c Release 3
(12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c
Release 4 (12.1.0.4)
5
This chapter describes the different ways of upgrading your Oracle Management
Service and Oracle Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2
(12.1.0.2). Select the one that best suits your requirement, and follow the instructions
outlined in the respective section. The upgrade instructions apply to single-OMS as
well as multi-OMS environments.
This chapter describes the following:
■
■
■
■
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or
12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4) in Graphical Mode
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or
12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4) in Silent Mode
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the
Software-Only Method in Graphical Mode
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the
Software-Only Method in Silent Mode
Upgrading Oracle Management Service and Oracle Management
Release 2 Repository
(12.1.0.2) to12c
12cRelease
Release3 4(12.1.0.3)
(12.1.0.4)or 12c
5-1
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
Note:
■
If you have Oracle Management Service 12c Release 1 (12.1.0.1)
[with or without Bundle Patch 1], then first upgrade it to either
12c Release 2 (12.1.0.2) or 12c Release 3 (12.1.0.3), and then
upgrade to 12c Release 4 (12.1.0.4).
For instructions to upgrade to 12c Release 2 (12.1.0.2) or 12c
Release 3 (12.1.0.3), refer to the Oracle Enterprise Manager Cloud
Control Upgrade Guide for the respective release, available in the
Enterprise Manager documentation library:
http://docs.oracle.com/cd/E24628_01/index.htm
■
If you have Oracle Management Agent 12c Release 1 (12.1.0.1) that
communicates with Oracle Management Service 12c Release 2
(12.1.0.2) or 12c Release 3 (12.1.0.3), then before upgrading the
Oracle Management Service to 12c Release 4 (12.1.0.4), make sure
you upgrade your Oracle Management Agent 12c Release 1
(12.1.0.1) to either 12c Release 2 (12.1.0.2) or 12c Release 3 (12.1.0.3)
using the Agent Upgrade Console present within the Enterprise
Manager Cloud Control Console.
This is a prerequisite for upgrading your Oracle Management
Service 12c Release 2 (12.1.0.2) or 12c Release 3 (12.1.0.3) to 12c
Release 4 (12.1.0.4).
■
■
If you are upgrading a multi-OMS environment, then Oracle
recommends that you use the software-only upgrade approach as
described in Section 5.3 or Section 5.4, as this approach minimizes
the downtime of the OMS instances.
For additional preparatory steps to be taken for a successful
upgrade, see My Oracle Support note 1682332.1.
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 Agent Upgrade Console. This is an expected behavior.
For instructions to use the Agent Upgrade Console to upgrade
Management Agents, see Chapter 6.
Note:
WARNING: Do not install Enterprise Manager Cloud Control 12c
on servers of SPARC series: T1000, T2000, T5xx0, and T3-*. For more
information, see My Oracle Support note 1590556.1.
5.1 Upgrading the OMS and the Management Repository of 12c Release 3
(12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4) in
Graphical Mode
To upgrade your Oracle Management Service and Oracle Management Repository of
12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) in graphical mode, follow these steps:
5-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
WARNING: Do not upgrade Enterprise Manager Cloud Control 12c
Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) while it is undergoing a
2-system upgrade from its earlier release (10.2.0.5 or 11.1.0.1). Wait
until the upgrade completes fully because there might be some
standalone Management Agents in status pending state while the
upgrade is in progress.
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
Enterprise Manager system is still undergoing a 2-system upgrade
from its earlier release to 12c Release 3 (12.1.0.3) or 12c Release 2
(12.1.0.2).
Note:
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 3 (12.1.0.3) or 12c Release 2 (12.1.0.2).
Then upgrade to 12c Release 4 (12.1.0.4).
If you are sure you do not want to switch over some Management
Agents from the earlier release to 12c Release 3 (12.1.0.3) or 12c
Release 2 (12.1.0.2), then delete such unwanted Management Agents
as described in Section 5.1.3, before you start the upgrade process.
After upgrading, you can choose to delete the old OMS home
if you do not want it. For instructions, see Appendix K.
Note:
Note: If you see an error message stating that you have not copied
the emkey, do the following:
■
If your OMS is configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_conndesc '"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_
DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd
<pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>
■
If your OMS is not configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_host <host> -repos_port <port> -repos_sid
<sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_
pwd <pwd>] -emkey_file <emkey file>
Here, the Management Repository details are details of the existing or
old Management Repository. You will be prompted for the
administration server password and the repository password if you
do not explicitly specify them in the command line.
Upgrading Oracle Management Service and Oracle Management
Release 2 Repository
(12.1.0.2) to12c
12cRelease
Release3 4(12.1.0.3)
(12.1.0.4)or 12c
5-3
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
If you are upgrading a multi-OMS environment, always start
the upgrade process with the first OMS, where the Admin Server is
running, and not with any of the additional OMS instances.
Note:
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
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
.
.
.
1.
Oracle strongly recommends that you back up the Management Repository, the
OMS, the inventory, the Software Library, and other components that are critical to
the functioning of Enterprise Manager. This will enable you to revert to the
original contents if the upgrade fails.
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.
5-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
Note:
■
■
■
For information about the additional, advanced options you can
pass while invoking the installer, refer to Section 5.1.1.
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.
■
While upgrading on IBM AIX, if you see an error message stating
that your JDK version in the middleware home is not of a
supported version, then make sure you install the supported
version mentioned in the message, and then invoke the installer
passing the -skipJDKValidation argument.
For example,
./runInstaller -skipJDKValidation
■
2.
-invPtrLoc is not supported on Microsoft Windows.
(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.
Beginning with Enterprise Manager Cloud Control 12c Release
3 (12.1.0.3), My Oracle Support accesses support.oracle.com directly.
This means that you must provide network access to this URL, or
grant proxy access to it from any client that will access My Oracle
Support.
Note:
3.
Click Next.
4.
On the Software Updates screen, apply the latest software updates, including the
latest PSU patches.
You can download the software updates in offline mode (if you do not have
Internet connectivity) or online mode (if you have Internet connectivity). For
Upgrading Oracle Management Service and Oracle Management
Release 2 Repository
(12.1.0.2) to12c
12cRelease
Release3 4(12.1.0.3)
(12.1.0.4)or 12c
5-5
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
instructions, see Oracle Enterprise Manager Cloud Control Advanced Installation and
Configuration Guide.
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.
7.
Click Next.
If a prerequisite check fails reporting a missing package, then
make sure you install the required package, and click Rerun. The
installation wizard validates the package name as well as the version,
so make sure you install the packages of the minimum versions
mentioned in Oracle Enterprise Manager Cloud Control Basic Installation
Guide. To understand the logic the installation wizard uses to verify
these packages, see Oracle Enterprise Manager Cloud Control Basic
Installation Guide.
Note:
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:
a.
Enter or validate the Middleware home.
5-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
Note:
■
■
■
■
b.
Upgrade to 12c Release 4 (12.1.0.4) is an out-of-place upgrade,
therefore you must either enter an existing middleware home
where Oracle WebLogic Server and Java Development Kit are
installed, or enter a new middleware home where they can be
installed by the installer.
If you do not have Oracle WebLogic Server 11g Release 1 (10.3.6)
and Java Development Kit 1.6.0.43.0 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.6) and JDK 1.6.0.43.0. 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.
Ensure that the Middleware home you enter or validate 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.
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, do the following:
■
■
Enter the passwords for the SYS and SYSMAN user accounts of the database
that houses the Management Repository for the selected OMS.
Confirm that you have backed up the Management Repository (although the
installer checks only if you have backed up the Management Repository, Oracle
strongly recommends that you back up the OMS, the inventory, the Software Library,
and other components that are critical to the functioning of Enterprise Manager. This
will enable you to revert to the original contents if the upgrade fails). As a
prerequisite, you must back up the Management Repository before starting
the upgrade process. If you have not already taken a backup, then do so
immediately, and then return to the installer to continue with the upgrade.
13. Click Next.
Upgrading Oracle Management Service and Oracle Management
Release 2 Repository
(12.1.0.2) to12c
12cRelease
Release3 4(12.1.0.3)
(12.1.0.4)or 12c
5-7
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
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.
Note:
To identify all running and scheduled deployment procedures, run the
following query, and note down the GUID of the deployment
procedures.
SELECT i.instance_guid FROM SYSMAN.MGMT_PAF_STATES s,
SYSMAN.MGMT_PAF_INSTANCES i, SYSMAN.MGMT_PAF_PROCEDURES p
WHERE p.procedure_guid = i.procedure_guid AND s.instance_
guid = i.instance_guid AND s.state_type = 0 AND s.status in
(0,1)
To stop the running or scheduled deployment procedures, run the
following query, and pass the GUID you noted down from the output
of the preceding command:
emcli stop_instance -instance=<instance id from sql query>
For information about the various prerequisite checks that are
run on the database at this point, see Oracle Enterprise Manager Cloud
Control Basic Installation Guide.
Note:
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, or
when there are any new default plug-ins introduced with a release. Oracle
Cloud Framework Plug-In is an additional default plug-in introduced with 12c
Release 4 (12.1.0.4), so this plug-in is deployed automatically.
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.
IMPORTANT: Before you proceed to the next screen, stop all the
associated OMS instances.
$<OMS_HOME>/bin/emctl stop oms -all
5-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
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.
Access the following Enterprise Manager
download page on Oracle Technology
Network (OTN):
http://www.oracle.com/technetwork/oem/
grid-control/downloads/oem-upgrade-con
sole-502238.html
2.
Expand the section that lists the software
binaries and plug-ins for your upgrade path.
3.
From the Download Plug-ins section,
manually download the plug-ins and store
them in an accessible location.
4.
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>
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.
■
If you see a message stating that you have unsupported plug-ins
on the OMS or on some of the Management Agents, then follow
the instructions outlined in the message to upgrade the plug-ins,
and then retry upgrading the OMS.
15. Click Next.
16. On the Select Plug-ins 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.
Upgrading Oracle Management Service and Oracle Management
Release 2 Repository
(12.1.0.2) to12c
12cRelease
Release3 4(12.1.0.3)
(12.1.0.4)or 12c
5-9
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
If you want to install some plug-ins that are not listed on this
screen, then follow these steps:
Note:
1.
Access the following Enterprise Manager download page on Oracle
Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downlo
ads/oem-upgrade-console-502238.html
2.
Expand the section that lists the software binaries and plug-ins for your
upgrade path.
3.
From the Download Plug-ins section, manually download the plug-ins
and store them in an accessible location.
4.
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>
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.
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.
Note:
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:
<OMS_INSTANCE_HOME>/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. This gc_inst directory must not be your old gc_inst
directory of 12c Release 3 (12.1.0.3), so enter a new directory location. If you
enter the old gc_inst directory, then the installer will display a warning that
the directory is not empty.
Make sure the path you enter leads up to the instance base directory, and is
maintained outside the middleware home.
For example, if the 12.1.0.3 middleware home was
/u01/app/Oracle/Middleware, and the 12.1.0.3 OMS instance base directory
was /u01/app/Oracle/gc_inst, then while upgrading to 12.1.0.4, if you
5-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
entered the middle ware home as /u01/app/Oracle/Middleware12104, then
enter the OMS instance base directory as /u01/app/Oracle/gc_inst12104. As
a result, the directory name is unique and so is the directory location.
If you are installing on an NFS-mounted drive and creating the
OMS instance base directory (gc_inst) on that NFS-mounted drive,
then after you install, move the lock files from the NFS-mounted drive
to a local file system location. Modify the lock file location in the
httpd.conf file to map to a location on a local file system. For
instructions, refer to Section 5.1.4.
Note:
If you want to change the Oracle WebLogic Server password
or the Node Manager password, see My Oracle Support note
1450798.1.
Note:
19. Click Next.
20. On the Review screen, review the details you have provided for the upgrade.
a.
If you want to change the details, click Back repeatedly until you reach the
screen where you want to make the changes.
b.
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.
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-11
12c
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
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.
■
If the Management Repository upgrade fails with the following
error in the schemamanager logs, then restart the database, and
then try the upgrade again.
ORA-04020: deadlock detected while trying to lock object
SYSMAN.MGMT_GLOBAL
■
If the upgrade fails because you did not apply the required
database patches as described in Step 2 (d) of Section 4.1, then see
My Oracle Support note 1568107.1 to verify the error in the log
file, and to resolve the issue and proceed further.
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 have additional OMS instances, then start upgrading each of them
following Step (1) to Step (23) as outlined in Section 5.1 (this section.)
25. After upgrading all the OMS instances, upgrade the Management Agents,
including the one that was installed with the first, old OMS (that is, central agent).
For more information, refer to Chapter 6.
After upgrading the central agent, if you find the agent base
directory of the upgraded central agent in the old Oracle Middleware
home, and if you want to move it outside that old Oracle Middleware
home, then follow the instructions outlined in the My Oracle Support
note 1520010.1.
Note:
26. After upgrading the Enterprise Manager system completely, if some central agents
appear in Activation Pending state in the Enterprise Manager Cloud Control
5-12 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
Console, then delete them by following these steps outlined in Section 12.13.2.
After upgrading, you can choose to delete the old OMS home
if you do not want it. For instructions, see Appendix K.
Note:
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 to see the JVM target that was
associated with the old OMS. This is an expected behavior.
You can 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.1.1 Advanced Installer Options Supported for Installing an Enterprise Manager
System in 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.
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-13
12c
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-up
grade-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
Section 5.1.2.
5.1.2 Limitations with the Advanced Installer Options Supported for Installing an
Enterprise Manager System in Graphical Mode
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 5–1 lists the different combinations of these advanced options, and describes the
workaround to be followed for each combination:
Table 5–1
Advanced Options and Workarounds
Advanced Option
Workaround
START_OMS=false
1.
b_startAgent=false
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 $<OMS_
HOME>/bin directory. To do so, refer to the Oracle
Enterprise Manager Command Line Interface Guide.
START_OMS=true
Start the Management Agent:
b_startAgent=false
$<AGENT_HOME>/bin/emctl start agent
5-14 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
Table 5–1
(Cont.) Advanced Options and Workarounds
Advanced Option
Workaround
START_OMS=false
1.
b_startAgent=true
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 $<OMS_
HOME>/bin directory. To do so, refer to the Oracle
Enterprise Manager Command Line Interface Guide.
5.1.3 Deleting Unwanted Standalone Management Agents Before Upgrading from
12.1.0.3, 12.1.0.2 to 12.1.0.4
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 Enterprise Manager system is still undergoing a 2-system upgrade from its
earlier release (10.2.0.5 or 11.1.0.1) to 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2).
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 3
(12.1.0.3) or 12c Release 2 (12.1.0.2). Then upgrade to 12c Release 4 (12.1.0.4).
If you are sure you do not want to switch over some Management Agents from the
earlier release to 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2), 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 by running the following query as
SYSMAN user in the Management Repository you are about to upgrade (12.1.0.3
or 12.1.0.2 repository):
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:
a.
On the upgraded 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.
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-15
12c
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
$<OMS_HOME>/bin/emcli login -username=SYSMAN
-password=<sysman-passwd>
b.
Synchronize EM CLI:
$<OMS_HOME>/bin/emcli sync
c.
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
For example,
$/u01/software/oracle/middleware/oms/bin/emcli delete_target
-name=example.com:4567 -type=oracle_emd -delete_monitored_targets
3.
Proceed with the upgrade to 12c Release 4 (12.1.0.4).
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 following query on your
12c Release 1 (12.1.0.3) or 12c Release 2 (12.1.0.2) Management
Repository.
Note:
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' );
5.1.4 Moving Lock Files from an NFS-Mounted Drive to a Local File System Location
If you are installing on an NFS-mounted drive and creating the OMS instance base
directory (gc_inst) on that NFS-mounted drive, then after you install, move the lock
files from the NFS-mounted drive to a local file system location. To do so, modify the
lock files location in the httpd.conf file to map to a location on a local file system
1.
Stop the OMS:
<OMS_HOME>/bin/emctl stop oms
2.
Open the following file:
Oracle recommends you to take a backup of this file before
editing it
Note:
<WEBTIER_INSTANCE_HOME>/config/OHS/ohs<#>/httpd.conf
For example,
/u01/Oracle/Middleware/gc_inst/WebTierIH1/config/OHS/ohs1/httpd.conf
5-16 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
3.
Search for sections related to the modules mpm_prefork_module and mpm_worker_
module. In both these sections, for the LockFile parameter, specify the absolute
path to a location on the local file system where Oracle HTTP Server can
automatically create the http_lock file. If the location you specify does not already
exist, then create it first, and then specify the path here.
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
AcceptMutex fcntl
LockFile uo1/em/ohs_locks
</IfModule>
....
<IfModule mpm_worker_module>
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
AcceptMutex fcntl
LockFile uo1/em/ohs_locks
</IfModule>
For example, if you want to specify the location path uo1/em/ohs_locks where
where /u01/em is a location on your local file system, then make sure the directory
ohs_locks already exists. If it does not exit, create it in the following way, and then
specify this path in the httpd.conf file.
mkdir –p /u01/em/ohs_locks
Oracle HTTP Server will automatically create the following lock file:
uo1/em/ohs_locks/http_lock
4.
Save the changes.
5.
Restart the OMS:
<OMS_HOME>/bin/emctl start oms
5.2 Upgrading the OMS and the Management Repository of 12c Release 3
(12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4) in Silent
Mode
To upgrade your Oracle Management Service and Oracle Management Repository of
12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) in silent mode, follow these steps:
WARNING: Do not upgrade Enterprise Manager Cloud Control 12c
Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) while it is undergoing a
2-system upgrade from its earlier release (10.2.0.5 or 11.1.0.1). 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 Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-17
12c
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
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
Enterprise Manager system is still undergoing a 2-system upgrade
from its earlier release to 12c Release 3 (12.1.0.3) or 12c Release 2
(12.1.0.2).
Note:
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 3 (12.1.0.3) or 12c Release 2 (12.1.0.2).
Then upgrade to 12c Release 4 (12.1.0.4).
If you are sure you do not want to switch over some Management
Agents from the earlier release to 12c Release 3 (12.1.0.3) or 12c
Release 2 (12.1.0.2), then delete such unwanted Management Agents
as described in Section 5.1.3, before you start the upgrade process.
After upgrading, you can choose to delete the old OMS home
if you do not want it. For instructions, see Appendix K.
Note:
If you see an error message stating that you have not copied
the emkey, do the following:
Note:
■
If your OMS is configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_conndesc '"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_
DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd
<pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>
■
If your OMS is not configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_host <host> -repos_port <port> -repos_sid
<sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_
pwd <pwd>] -emkey_file <emkey file>
Here, the Management Repository details are details of the existing or
old Management Repository. You will be prompted for the
administration server password and the repository password if you
do not explicitly specify them in the command line.
5-18 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
If you are upgrading a multi-OMS environment, always start
the upgrade process with the first OMS, where the Admin Server is
running, and not with any of the additional OMS instances.
Note:
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
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
.
.
.
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
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-19
12c
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
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 Section 5.2.1.
While upgrading on IBM AIX, if you see an error message stating
that your JDK version in the middleware home is not of a
supported version, then make sure you install the supported
version mentioned in the message, and then invoke the installer
passing the -skipJDKValidation argument.
For example,
./runInstaller -skipJDKValidation
■
If a prerequisite check fails reporting a missing package, then
make sure you install the required package, and retry the
installation. The installer validates the package name as well as
the version, so make sure you install the packages of the
minimum versions mentioned in Oracle Enterprise Manager Cloud
Control Basic Installation Guide. To understand the logic the
installer uses to verify these packages, see Oracle Enterprise
Manager Cloud Control Basic Installation Guide.
4.
If you have additional OMS instances, then start upgrading each of them
following Step (1) to Step (3) as outlined in Section 5.2 (this section.)
5.
After upgrading all the OMS instances, upgrade the Management Agents,
including the one that was installed with the first, old OMS (that is, central agent).
For more information, refer to Chapter 6.
After upgrading the central agent, if you find the agent base
directory of the upgraded central agent in the old Oracle Middleware
home, and if you want to move it outside that old Oracle Middleware
home, then follow the instructions outlined in the My Oracle Support
note 1520010.1.
Note:
6.
After upgrading the Enterprise Manager system completely, if some central agents
appear in Activation Pending state in the Enterprise Manager Cloud Control
Console, then delete them by following these steps outlined in Section 12.13.2.
5-20 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
Note:
■
■
After upgrading, you can choose to delete the old OMS home if
you do not want it. For instructions, see Appendix K.
If the Management Repository upgrade fails with the following
error in the schemamanager logs, then restart the database, and
then try the upgrade again.
ORA-04020: deadlock detected while trying to lock object
SYSMAN.MGMT_GLOBAL
■
If the upgrade fails because you did not apply the required
database patches as described in Step 2 (d) of Section 4.1, then see
My Oracle Support note 1568107.1 to verify the error in the log
file, and to resolve the issue and proceed further.
Caution: (Applicable only for 12.1.0.X to 12.1.0.4 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.
You can 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.2.1 Advanced Installer Options Supported for Installing an Enterprise Manager
System in 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 example, 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.
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-21
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
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
Section 5.1.2.
5.3 Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
Using the Software-Only Method 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.
This upgrade approach is best suited for multi-OMS environments, as it minimizes the
downtime of the OMS instances. This approach consists of three parts, mainly copying
the software binaries, running the root.sh script, and configuring the software
binaries. You can copy the software binaries on all the OMS hosts in parallel without
shutting down the OMS instances. This not only saves time but also enables the earlier
release of the OMS instances to remain up and running at this point. Once the software
binaries are copied, you can shut down all the OMS instances, and configure the
software binaries to upgrade the OMS instances, one after the other. Therefore, the
downtime begins only when you start configuring the OMS instances, and not while
copying the software binaries to the host.
In particular, this section covers the following:
■
■
■
Installing the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software
Binaries Now in Graphical Mode
Running the allroot.sh Script
Configuring the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
Software Binaries in Graphical Mode
WARNING: Do not upgrade Enterprise Manager Cloud Control 12c
Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) while it is undergoing a
2-system upgrade from its earlier release (10.2.0.5 or 11.1.0.1). Wait
until the upgrade completes fully because there might be some
standalone Management Agents in status pending state while the
upgrade is in progress.
5-22 Oracle Enterprise Manager Cloud Control Upgrade Guide
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
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
Enterprise Manager system is still undergoing a 2-system upgrade
from its earlier release to 12c Release 3 (12.1.0.3) or 12c Release 2
(12.1.0.2).
Note:
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 3 (12.1.0.3) or 12c Release 2 (12.1.0.2).
Then upgrade to 12c Release 4 (12.1.0.4).
If you are sure you do not want to switch over some Management
Agents from the earlier release to 12c Release 3 (12.1.0.3) or 12c
Release 2 (12.1.0.2), then delete such unwanted Management Agents
as described in Section 5.1.3, before you start the upgrade process.
After upgrading, you can choose to delete the old OMS home
if you do not want it. For instructions, see Appendix K.
Note:
Note: If you see an error message stating that you have not copied
the emkey, do the following:
■
If your OMS is configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_conndesc '"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_
DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd
<pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>
■
If your OMS is not configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_host <host> -repos_port <port> -repos_sid
<sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_
pwd <pwd>] -emkey_file <emkey file>
Here, the Management Repository details are details of the existing or
old Management Repository. You will be prompted for the
administration server password and the repository password if you
do not explicitly specify them in the command line.
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-23
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
If you are upgrading a multi-OMS environment, always start
the upgrade process with the first OMS, where the Admin Server is
running, and not with any of the additional OMS instances.
Note:
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
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
.
.
.
5.3.1 Installing the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software
Binaries Now in Graphical Mode
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.
-invPtrLoc is not supported on Microsoft Windows.
5-24 Oracle Enterprise Manager Cloud Control Upgrade Guide
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
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.
While installing on IBM AIX, if you see an error message
stating that your JDK version in the middleware home is not of a
supported version, then make sure you install the supported version
mentioned in the message, and then invoke the installer passing the
-skipJDKValidation argument.
Note:
For example,
./runInstaller -skipJDKValidation
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.
Beginning with Enterprise Manager Cloud Control 12c Release
3 (12.1.0.3), My Oracle Support accesses support.oracle.com directly.
This means that you must provide network access to this URL, or
grant proxy access to it from any client that will access My Oracle
Support.
Note:
3.
Click Next.
4.
On the Software Updates screen, apply the latest software updates, including the
latest PSU patches.
You can download the software updates in offline mode (if you do not have
Internet connectivity) or online mode (if you have Internet connectivity). For
instructions, see Oracle Enterprise Manager Cloud Control Advanced Installation and
Configuration Guide.
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.
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-25
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
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.
7.
Click Next.
If a prerequisite check fails reporting a missing package, then
make sure you install the required package, and click Rerun. The
installation wizard validates the package name as well as the version,
so make sure you install the packages of the minimum versions
mentioned in Oracle Enterprise Manager Cloud Control Basic Installation
Guide. To understand the logic the installation wizard uses to verify
these packages, see Oracle Enterprise Manager Cloud Control Basic
Installation Guide.
Note:
8.
On the Installation Types screen, select Install software only.
9.
Click Next.
10. On the Installation Details screen, do the following:
a.
Enter or validate the Middleware home.
Note:
■
■
■
■
Upgrade to 12c Release 4 (12.1.0.4) is an out-of-place upgrade,
therefore you must either enter an existing middleware home
where Oracle WebLogic Server and Java Development Kit are
installed, or enter a new middleware home where they can be
installed by the installer.
If you do not have Oracle WebLogic Server 11g Release 1 (10.3.6)
and Java Development Kit 1.6.0.43.0 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.6) and JDK 1.6.0.43.0. 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.
Ensure that the Middleware home you enter or validate 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.
5-26 Oracle Enterprise Manager Cloud Control Upgrade Guide
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
b.
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.
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).
Note:
c.
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 and delete the agent base directory you created
in Step 10 (b). For instructions, see Oracle Enterprise Manager Cloud Control
Advanced Installation and Configuration Guide.
The Management Agent you installed and the agent base directory you created in
Step 10 (b) is essentially for a fresh installation, and is not used while upgrading
Management Agents using the Agent Upgrade Console. The Agent Upgrade
Console performs an out-of-place upgrade, and creates a new agent home in the
existing agent base directory for every Management Agent that is upgraded.
For example, in Step 10 (b), you might have provided
/software/oracle/agent12104 as the agent base directory. However, the old
agent base directory might be /software/oracle/middleware/agent_base/, and
the old agent home might be /software/oracle/middleware/agent_
base/core/12.1.0.3. In this case, the Agent Upgrade Console that upgrades the
Management Agent does not use the agent base directory
/software/oracle/agent12104 created in Step 10 (b). Instead, it creates a new
agent home /software/oracle/middleware/agent_base/core/12.1.0.4 in the
existing agent base directory /software/oracle/middleware/agent_base/. Since
the agent base directory you provided in Step 10 (b) is no longer required, you can
deinstall the Management Agent and manually delete the agent base directory.
16. If you have additional OMS instances, then copy the software binaries on those
additional OMS hosts as well by following steps outlined in this section
(Section 5.3.1).
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-27
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
5.3.2 Running the 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
If you have additional OMS instances, then run this script on those additional OMS
hosts as well.
If you do not have the permission to run this script at this
point, you can always run it after configuring the software binaries,
but make sure you run it before you start upgrading the Management
Agents.
Note:
5.3.3 Configuring the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
Software Binaries in Graphical Mode
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:
■
■
■
2.
On Microsoft Windows, run ConfigureGC.bat.
While installing the software binaries as described in Section 5.3.1,
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 Section 5.3.3.1.
On the Install Types screen, do the following:
a.
Select Upgrade an Existing Enterprise Manager System, and then, select One
System Upgrade.
b.
Select the OMS home you want to upgrade.
3.
Click Next.
4.
On the Database Connection Details screen, do the following:
■
■
Enter the passwords for the SYS and SYSMAN user accounts of the database
that houses the Management Repository for the selected OMS.
Confirm that you have backed up the Oracle Management Repository
(Management Repository). As a prerequisite, you must back up the
Management Repository before starting the upgrade process. If you have not
already taken a backup, then do so immediately, and then return to the
installer to continue with the upgrade.
5-28 Oracle Enterprise Manager Cloud Control Upgrade Guide
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
For information about the various prerequisite checks that are
run on the database at this point, see Oracle Enterprise Manager Cloud
Control Basic Installation Guide.
Note:
5.
Click Next.
If you see an error about missing plug-ins, then do the
following:
Note:
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.
Access the following Enterprise Manager download page on Oracle
Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downlo
ads/oem-upgrade-console-502238.html
3.
Expand the section that lists the software binaries and plug-ins for your
upgrade path.
4.
From the Download Plug-ins section, manually download the same
plug-in version and the same or higher plug-in update as shown in the
missing plug-ins error message. Store the plug-ins in an accessible
location, and ensure that the location is meant only for these missing
plug-ins.
5.
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, or
when there are any new default plug-ins introduced with a release. Oracle
Cloud Framework Plug-In is an additional default plug-in introduced with 12c
Release 4 (12.1.0.4), so this plug-in is deployed automatically.
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.
Before you proceed to the next screen, stop all the associated
OMS instances.
Note:
$<OMS_HOME>/bin/emctl stop oms -all
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-29
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
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.
Access the following Enterprise Manager
download page on Oracle Technology
Network (OTN):
http://www.oracle.com/technetwork/oem/
grid-control/downloads/oem-upgrade-con
sole-502238.html
2.
Expand the section that lists the software
binaries and plug-ins for your upgrade path.
3.
From the Download Plug-ins section,
manually download the plug-ins and store
them in an accessible location.
4.
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.s
h -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.
■
If you see a message stating that you have unsupported plug-ins
on the OMS or on some of the Management Agents, then follow
the instructions outlined in the message to upgrade the plug-ins,
and then retry upgrading the OMS.
7.
Click Next.
8.
On the Select Plug-ins 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.
5-30 Oracle Enterprise Manager Cloud Control Upgrade Guide
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
If you want to install any additional plug-ins that are not listed
on this screen, then follow these steps:
Note:
1.
Access the following Enterprise Manager download page on Oracle
Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downlo
ads/oem-upgrade-console-502238.html
2.
Expand the section that lists the software binaries and plug-ins for your
upgrade path.
3.
From the Download Plug-ins section, manually download the plug-ins
and store them in an accessible location.
4.
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.
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.
Note:
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. This gc_inst directory must not be your old gc_inst
directory of 12c Release 3 (12.1.0.3), so enter a new directory location. If you
enter the old gc_inst directory, then the installer will display a warning that
the directory is not empty.
Make sure the path you enter leads up to the instance base directory, and is
maintained outside the middleware home.
For example, if the 12.1.0.3 middleware home was
/u01/app/Oracle/Middleware, and the 12.1.0.3 OMS instance base directory
was /u01/app/Oracle/gc_inst, then while upgrading to 12.1.0.4, if you
entered the middle ware home as /u01/app/Oracle/Middleware12104, then
enter the OMS instance base directory as /u01/app/Oracle/gc_inst12104. As
a result, the directory name is unique and so is the directory location.
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-31
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
If you are installing on an NFS-mounted drive and creating the
OMS instance base directory (gc_inst) on that NFS-mounted drive,
then after you install, move the lock files from the NFS-mounted drive
to a local file system location. Modify the lock file location in the
httpd.conf file to map to a location on a local file system. For
instructions, refer to Section 5.1.4.
Note:
If you want to change the Oracle WebLogic Server password
or the Node Manager password, see My Oracle Support note
1450798.1.
Note:
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.
5-32 Oracle Enterprise Manager Cloud Control Upgrade Guide
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Graphical Mode
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.
■
If the Management Repository upgrade fails with the following
error in the schemamanager logs, then restart the database, and
then try the upgrade again.
ORA-04020: deadlock detected while trying to lock object
SYSMAN.MGMT_GLOBAL
■
If the upgrade fails because you did not apply the required
database patches as described in Step 2 (d) of Section 4.1, then see
My Oracle Support note 1568107.1 to verify the error in the log
file, and to resolve the issue and proceed further.
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 have additional OMS instances, then start upgrading each of them by
following steps outlined in this section (Section 5.3.3).
16. After upgrading all the OMS instances, upgrade the Management Agents,
including the one that was installed with the first, old OMS (that is, central
agent).For more information, refer to Chapter 6.
After upgrading the central agent, if you find the agent base
directory of the upgraded central agent in the old Oracle Middleware
home, and if you want to move it outside that old Oracle Middleware
home, then follow the instructions outlined in the My Oracle Support
note 1520010.1.
Note:
17. After upgrading the Enterprise Manager system completely, if some central agents
appear in Activation Pending state in the Enterprise Manager Cloud Control
Console, then delete them by following these steps outlined in Section 12.13.2.
After upgrading, you can choose to delete the old OMS home
if you do not want it. For instructions, see Appendix K.
Note:
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-33
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Silent Mode
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.
You can 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.3.3.1 Advanced Script Options Supported for Software-Only Upgrade to
Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
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
Section 5.1.2.
5.4 Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
Using the Software-Only Method 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 upgrade approach is best suited for multi-OMS environments, as it minimizes the
downtime of the OMS instances. This approach consists of three parts, mainly copying
the software binaries, running the root.sh script, and configuring the software
5-34 Oracle Enterprise Manager Cloud Control Upgrade Guide
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Silent Mode
binaries. You can copy the software binaries on all the OMS hosts in parallel without
shutting down the OMS instances. This not only saves time but also enables the earlier
release of the OMS instances to remain up and running at this point. Once the software
binaries are copied, you can shut down all the OMS instances, and configure the
software binaries to upgrade the OMS instances, one after the other. Therefore, the
downtime begins only when you start configuring the OMS instances, and not while
copying the software binaries to the host.
In particular, this section covers the following:
■
■
■
Installing the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software
Binaries in Silent Mode
Running the allroot.sh Script
Configuring the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
Software Binaries in Silent Mode
WARNING: Do not upgrade Enterprise Manager Cloud Control 12c
Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) while it is undergoing a
2-system upgrade from its earlier release (10.2.0.5 or 11.1.0.1). Wait
until the upgrade completes fully because there might be some
standalone Management Agents in status pending state while the
upgrade is in progress.
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
Enterprise Manager system is still undergoing a 2-system upgrade
from its earlier release to 12c Release 3 (12.1.0.3) or 12c Release 2
(12.1.0.2).
Note:
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 3 (12.1.0.3) or 12c Release 2 (12.1.0.2).
Then upgrade to 12c Release 4 (12.1.0.4).
If you are sure you do not want to switch over some Management
Agents from the earlier release to 12c Release 3 (12.1.0.3) or 12c
Release 2 (12.1.0.2), then delete such unwanted Management Agents
as described in Section 5.1.3, before you start the upgrade process.
After upgrading, you can choose to delete the old OMS home
if you do not want it. For instructions, see Appendix K.
Note:
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-35
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Silent Mode
If you see an error message stating that you have not copied
the emkey, do the following:
Note:
■
If your OMS is configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_conndesc '"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_
DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd
<pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>
■
If your OMS is not configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_host <host> -repos_port <port> -repos_sid
<sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_
pwd <pwd>] -emkey_file <emkey file>
Here, the Management Repository details are details of the existing or
old Management Repository. You will be prompted for the
administration server password and the repository password if you
do not explicitly specify them in the command line.
If you are upgrading a multi-OMS environment, always start
the upgrade process with the first OMS, where the Admin Server is
running, and not with any of the additional OMS instances.
Note:
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
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
.
.
.
5.4.1 Installing the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software
Binaries in Silent Mode
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:
5-36 Oracle Enterprise Manager Cloud Control Upgrade Guide
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Silent Mode
<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 5–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 Section 5.2.1.
While installing on IBM AIX, if you see an error message stating
that your JDK version in the middleware home is not of a
supported version, then make sure you install the supported
version mentioned in the message, and then invoke the installer
passing the -skipJDKValidation argument.
For example,
./runInstaller -skipJDKValidation
4.
Deinstall the Management Agent and delete the agent base directory you created.
For instructions, see Oracle Enterprise Manager Cloud Control Advanced Installation
and Configuration Guide.
The Management Agent you installed and the agent base directory you created is
essentially for a fresh installation, and is not used while upgrading Management
Agents using the Agent Upgrade Console. The Agent Upgrade Console performs
an out-of-place upgrade, and creates a new agent home in the existing agent base
directory for every Management Agent that is upgraded.
For example, in the response file, you might have provided
/software/oracle/agent12104 as the agent base directory. However, the old
agent base directory might be /software/oracle/middleware/agent_base/, and
the old agent home might be /software/oracle/middleware/agent_
base/core/12.1.0.3. In this case, the Agent Upgrade Console that upgrades the
Management Agent does not use the agent base directory
/software/oracle/agent12104 created using the response file. Instead, it creates a
new agent home /software/oracle/middleware/agent_base/core/12.1.0.4 in
the existing agent base directory /software/oracle/middleware/agent_base/.
Since the agent base directory you provided in Step 10 (b) is no longer required,
you can deinstall the Management Agent and manually delete the agent base
directory.
5.
If you have additional OMS instances, then copy the software binaries on those
additional OMS hosts as well by following steps outlined in this section
(Section 5.4.1).
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-37
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Silent Mode
5.4.1.1 Editing the software_only.rsp Response File for Installing the Enterprise
Manager Cloud Control 12c Release 4 (12.1.0.4) Software Binaries in Silent Mode
Table 5–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 5–2 Editing the software_only.rsp Response File for Installing the Enterprise
Manager Cloud Control 12c Release 4 (12.1.0.4) Software Binaries in Silent Mode
Parameter
Data Type
Double Quotes
Required for
Values?
UNIX_GROUP_
NAME
String
Yes
Description
(Required only when central inventory does
not exist) Enter the name of the UNIX
group you belong to.
For example, "dba".
INVENTORY_
LOCATION
String
Yes
(Required only when central inventory does
not exist) Enter the absolute path to the
Central Inventory.
For example,
"/scratch/oracle/oraInventory".
SECURITY_
Boolean
UPDATES_VIA_
MYORACLESUPP
ORT
Yes
■
Enter TRUE if you want to
download and install security
updates. Then, enter the credentials
for the following variables in
double quotes:
MYORACLESUPPORT_USERNAME
MYORACLESUPPORT_PASSWORD
■
DECLINE_
SECURITY_
UPDATES
Boolean
No
■
■
5-38 Oracle Enterprise Manager Cloud Control Upgrade Guide
Enter FALSE if you do not want to
download and install 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.
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Silent Mode
Table 5–2 (Cont.) Editing the software_only.rsp Response File for Installing the
Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software Binaries in Silent
Parameter
Data Type
Double Quotes
Required for
Values?
INSTALL_
UPDATES_
SELECTION
String
Yes
Description
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 in double quotes:
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, in double
quotes.
For this option, as a prerequisite,
you must have already
downloaded the software updates.
For instructions, see Oracle
Enterprise Manager Cloud Control
Advanced Installation and
Configuration Guide.
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-39
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Silent Mode
Table 5–2 (Cont.) Editing the software_only.rsp Response File for Installing the
Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software Binaries in Silent
Parameter
Data Type
Double Quotes
Required for
Values?
ORACLE_
MIDDLEWARE_
HOME_
LOCATION
String
Yes
Description
Upgrade to 12c Release 4 (12.1.0.4) is an
out-of-place upgrade, therefore you
must specify an existing middleware
home where Oracle WebLogic Server
and Java Development Kit are installed,
or enter a new middleware home where
they can be installed by the installer.
Enter the location where you have
installed Oracle WebLogic Server 11g
Release 1 (10.3.6) and Java Development
Kit 1.6.0.43.0.
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.
AGENT_BASE_
DIR
String
Yes
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/agent". Ensure that
this location is empty and has write
permission. Also ensure that it is always
maintained outside the Oracle
Middleware home.
ORACLE_
HOSTNAME
String
Yes
(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.
■
■
FROM_
LOCATION
To accept the default value, leave it
blank.
To install with a different host
name, then enter another host
name.
Not
Applicable
Not Applicable
Ignore this parameter.
DEINSTALL_LIST Not
Applicable
Not Applicable
Ignore this parameter.
REMOVE_
HOMES
Not Applicable
Ignore this parameter.
Not
Applicable
5-40 Oracle Enterprise Manager Cloud Control Upgrade Guide
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Silent Mode
5.4.2 Running the 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
If you have additional OMS instances, then run this script on those additional OMS
hosts as well.
If you do not have the permission to run this script at this
point, you can always run it after configuring the software binaries,
but make sure you run it before you start upgrading the Management
Agents.
Note:
5.4.3 Configuring the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
Software Binaries in Silent Mode
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 Section 5.4.1,
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 Section 5.3.3.1.
If a prerequisite check fails reporting a missing package, then
make sure you install the required package, and retry the
installation. The installer validates the package name as well as
the version, so make sure you install the packages of the
minimum versions mentioned in Oracle Enterprise Manager Cloud
Control Basic Installation Guide. To understand the logic the
installer uses to verify these packages, see Oracle Enterprise
Manager Cloud Control Basic Installation Guide.
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-41
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Silent Mode
If you see an error about missing plug-ins, then do the
following:
Note:
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.
Access the following Enterprise Manager download page on Oracle
Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downlo
ads/oem-upgrade-console-502238.html
3.
Expand the section that lists the software binaries and plug-ins for your
upgrade path.
4.
From the Download Plug-ins section, manually download the plug-ins
and store them in an accessible location.
5.
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 have additional OMS instances, then start upgrading each of them by
following steps outlined in this section (Section 5.4.3).
5.
After upgrading all the OMS instances, upgrade the Management Agents,
including the one that was installed with the first, old OMS (that is, central
agent).For more information, refer to Chapter 6.
After upgrading the central agent, if you find the agent base
directory of the upgraded central agent in the old Oracle Middleware
home, and if you want to move it outside that old Oracle Middleware
home, then follow the instructions outlined in the My Oracle Support
note 1520010.1.
Note:
6.
After upgrading the Enterprise Manager system completely, if some central agents
appear in Activation Pending state in the Enterprise Manager Cloud Control
Console, then delete them by following these steps outlined in Section 12.13.2.
Note:
■
■
After upgrading, you can choose to delete the old OMS home if
you do not want it. For instructions, see Appendix K.
If the Management Repository upgrade fails with the following
error in the schemamanager logs, then restart the database, and
then try the upgrade again.
ORA-04020: deadlock detected while trying to lock object
SYSMAN.MGMT_GLOBAL
■
If the upgrade fails because you did not apply the required
database patches as described in Step 2 (d) of Section 4.1, then see
My Oracle Support note 1568107.1 to verify the error in the log
file, and to resolve the issue and proceed further.
5-42 Oracle Enterprise Manager Cloud Control Upgrade Guide
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Silent Mode
Caution: (Applicable only for 12.1.0.X to 12.1.0.4 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.
You can 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.
Upgrading Oracle Management Service and Oracle Management
Release 2 (12.1.0.2)
Repository
to 12c Release 3
4 (12.1.0.3)
(12.1.0.4) or5-43
12c
Installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Using the Software-Only Method in Silent Mode
5-44 Oracle Enterprise Manager Cloud Control Upgrade Guide
6
Upgrading Oracle Management Agents
6
This chapter describes how you can upgrade your Enterprise Manager Cloud Control
12c Oracle Management Agents (Management Agents). This chapter contains the
following sections:
■
Overview of 12c Management Agent Upgrade
■
Before You Begin Upgrading 12c Management Agents
■
Prerequisites for Upgrading 12c Management Agents
■
Upgrading 12c Management Agents
■
After Upgrading 12c Management Agents
■
Troubleshooting 12c Management Agent Upgrade
6.1 Overview of 12c Management Agent Upgrade
If you are using Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) to manage
your enterprise, Oracle strongly recommends that you upgrade all your Oracle
Management Agents (Management Agents) to 12.1.0.4.
To upgrade your 12c Management Agents, you can either use the Upgrade Agents
page of Agent Upgrade Console (which is part of the Enterprise Manager Cloud
Control console), or use EM CLI. 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 (Software Library).
Agent Upgrade Console consists of the Agent Upgrade Tasks tab, and the Post Agent
Upgrade Tasks tab. You can use the Agent Upgrade Tasks tab to upgrade 12c
Management Agents, view the Management Agents that cannot be upgraded, and
view the summary of Management Agent upgrade jobs. You can use the Post Agent
Upgrade Tasks tab to clean up the old directories of upgraded 12c Management
Agents, and view a summary of the Management Agent clean up jobs. To access the
Agent Upgrade Console, from the Setup menu, select Manage Cloud Control, then
select Upgrade Agents.
Figure 6–1 shows the Agent Upgrade Console.
Upgrading Oracle Management Agents 6-1
Overview of 12c Management Agent Upgrade
Figure 6–1 Agent Upgrade Console
Upgrading a Management Agent modifies its installation base directory structure. The
following is an example of the installation base directory structure of a 12c Release 3
(12.1.0.3) Management Agent, when it is upgraded to 12c Release 4 (12.1.0.4):
Before Upgrade
<agent_base_directory>
|_____sbin
|_____core
|_____12.1.0.3.0
|_____plugins
|_____agent_inst
|_____agentimage.properties
.
.
.
After Upgrade
<agent_base_directory>
|_____sbin
|_____backup_agtup
|_____core
|_____12.1.0.3.0
|_____12.1.0.4.0
|_____plugins
|_____agent_inst
|_____agentimage.properties
.
.
.
6-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Before You Begin Upgrading 12c Management Agents
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.
(For Microsoft Windows hosts) If you upgrade a 12.1.0.x
Management Agent and you want to install another Management
Agent on the same host, which points to a different OMS, ensure
that you specify the s_agentSrvcName parameter while installing
the Management Agent, as described in the Oracle Enterprise
Manager Cloud Control Advanced Installation and Configuration
Guide.
6.2 Before You Begin Upgrading 12c Management Agents
Before you upgrade your 12c Management Agents, you must be aware of the
following:
■
If your Oracle Management Service (OMS) is of version 12c Release 4 (12.1.0.4),
you can use the Agent Upgrade Console or EM CLI to upgrade only 12c Release 2
(12.1.0.2) or 12c Release 3 (12.1.0.3) Management Agents, and not 12c Release 1
(12.1.0.1) Management Agents.
For information about the Management Agent versions that are supported on a
12.1.0.4 OMS, see Oracle Enterprise Manager Cloud Control Basic Installation Guide.
■
You must upgrade the central agent installed along with the old Oracle
Management Service (OMS).
Management Agents, including the central agent installed on the OMS host, are
not upgraded automatically while you upgrade your OMS to 12c Release 4
(12.1.0.4). Ensure that you upgrade the central agent installed on the OMS host
immediately after upgrading the old OMS to 12.1.0.4.
■
You can upgrade a Management Agent using the Agent Upgrade Console or EM
CLI even when you do not have preferred privileged credentials or non-privileged
credentials set, or are not aware of the Management Agent credentials. Privileged
credentials are only required to run the root.sh script 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.4.0/root.sh script.
■
In some cases, the deployed version of a plug-in may not be supported on the
upgraded version of a Management Agent. In these cases, ensure that you either
undeploy the plug-ins that are not supported on the upgraded version of the
Management Agent, or deploy versions of the plug-ins that are supported on the
upgraded Management Agent.
Upgrading Oracle Management Agents 6-3
Prerequisites for Upgrading 12c Management Agents
For information on how to undeploy and deploy a plug-in, see Oracle Enterprise
Manager Cloud Control Administrator's Guide.
■
In Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4), you can save the
Management Agent one-off patches that you want to apply on a particular version
of the Management Agent software, such that these patches are automatically
applied on the software whenever a new Management Agent of the same version
is deployed, or an old Management Agent is upgraded to that version.
For information on how to do this, see Oracle Enterprise Manager Cloud Control
Advanced Installation and Configuration Guide.
Also, you can apply one-off patches on a plug-in and create a custom patched
plug-in, such that this custom patched plug-in is deployed on all the new
Management Agents that you deploy, and all the old Management Agents that
you upgrade.
For information on how to do this, see Oracle Enterprise Manager Cloud Control
Administration Guide.
■
■
■
■
■
Upgrading Management Agents does not require Cygwin, PsExec, or any SSH
connectivity tools, as Enterprise Manager uses the existing Management Agent OMS communication channels to perform the upgrade.
You cannot specify a custom inventory location while upgrading Management
Agents. The upgraded Management Agent uses the inventory location of the old
Management Agent.
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 Management Agent is not reachable
–
The new Management Agent software (of the same version as the OMS
version) is not present in Oracle Software Library (Software Library)
–
The Management Agent Oracle home property is missing
–
The Management Agent is already undergoing an upgrade
See the Management Agent upgrade checklist present in the My Oracle Support
note 1569883.1.
6.3 Prerequisites for Upgrading 12c Management Agents
Before you upgrade your 12c Management Agents, meet the following prerequisites:
■
If you want to upgrade a Management Agent running on a platform different from
the OMS host platform, ensure that the latest Management Agent software for the
platform is downloaded and applied in Software Library, using Self Update.
To access Self Update, from the Setup menu, select Extensibility, then select Self
Update. To check whether the latest Management Agent software for a platform is
downloaded and applied, click Agent Software, then check the Version and the
6-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Prerequisites for Upgrading 12c Management Agents
Status columns for the required platform. The software version for the platform
must be the same as the OMS version. The status must read Applied.
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 Self Update to download and apply the latest
Management Agent software for a platform, see Oracle Enterprise Manager Cloud
Control Basic Installation 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. Check the Secure Upload column of the
required Management Agent.
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
<EMSTATE> refers to the Management Agent instance directory, that is, <AGENT_
BASE_DIRECTORY>/agent_inst
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
■
Ensure that OMS collections are run on all the Management Agents that you want
to upgrade.
If OMS collections are not run on some Management Agents, they are not
upgradable. These Management Agents are displayed on the Not Upgradable
Agents page, with the reason displayed as Oracle Home Property Missing. For
information on how to access this page, see Section 6.4.3.
To run OMS collections on a Management Agent that you want to upgrade, run
the following command from the Management Agent host:
<EMSTATE>/bin/emctl control agent runCollection <TARGET_NAME>:oracle_
home oracle_home_config
<EMSTATE> refers to the Management Agent instance directory, that is, <AGENT_
BASE_DIRECTORY>/agent_inst
<TARGET_NAME> refers to the Management Agent target of target type oracle_home
that is present in <EMSTATE>/sysman/emd/targets.xml
Upgrading Oracle Management Agents 6-5
Upgrading 12c Management Agents
■
Ensure that the old Management Agent does not come up during the Management
Agent upgrade process.
You may have scheduled certain cron jobs, or configured certain notification
managers that start up a Management Agent when it is down. The old
Management Agent is shut down as part of the upgrade process. Ensure that this
Management Agent is not brought up.
■
Ensure that the install user has read permissions on all the files present in Oracle
Inventory, and write permissions on the Oracle Inventory directory.
To grant read permissions on all the files present in Oracle Inventory, run the
following command as the install user:
chmod -R +r $<INVENTORY_LOCATION>
To grant write permissions on the Oracle Inventory directory, run the following
command as the install user:
chmod +rw $<INVENTORY_LOCATION>
■
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.1 GB
of free space, and the agent base directory has at least 750 MB of free space.
6.4 Upgrading 12c Management Agents
This section describes the actions involved in upgrading Management Agents. It
consists of the following:
■
Upgrading 12c Management Agents
■
Additional Parameters for 12c Management Agent Upgrade
■
Viewing 12c Management Agents That Cannot Be Upgraded
■
Performing Postupgrade Clean Up of Old Management Agents
■
Viewing 12c Management Agent Upgrade Clean Up Jobs
6.4.1 Upgrading 12c Management Agents
This section describes the methods you can use to upgrade 12.1.0.x Management
Agents. It consists of the following:
■
Upgrading 12c Management Agents using Agent Upgrade Console
■
Upgrading 12c Management Agents using EM CLI
6.4.1.1 Upgrading 12c Management Agents using Agent Upgrade Console
To upgrade 12.1.0.x Management Agents using Agent Upgrade Console, follow these
steps:
1.
From the Setup menu, select Manage Cloud Control, then select Upgrade Agents.
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.
6-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading 12c Management Agents
The job name can have a maximum length of 64 characters. It can consist of
alphanumeric and special characters, and can begin with either of these.
3.
Click Add to select the Management Agents you want to upgrade.
In the Upgradable Agents window, search for the Management Agents you want
to upgrade, using the Agent, Installed Version, Platform, and Group fields.
Select the Management Agents you want to upgrade. Click OK.
Important:
■
■
4.
In this release, you cannot upgrade your 12c Release 2 (12.1.0.2)
Management Agents to 12c Release 3 (12.1.0.3). You can only
upgrade your 12c Release 2 (12.1.0.2) and 12c Release 3 (12.1.0.3)
Management Agents to 12c Release 4 (12.1.0.4).
If you select a Management Agent that is part of a particular
group for upgrade, the other Management Agents of the group
are not selected for upgrade by default. If you want to upgrade
the other Management Agents of the group, you must select them
in the Upgradable Agents window.
(Optional) For Pre-upgrade Script and Post-upgrade Script, enter the absolute
path of the script that 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 (on all the OMS hosts in case of a
multi-OMS environment), 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.
Note:
■
■
■
5.
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
installed on different platforms in different sessions.
(Optional) For Additional Parameters, enter the additional options you want to
use for the upgrade.
Upgrading Oracle Management Agents 6-7
Upgrading 12c Management Agents
For example, specify -ignorePrereqs to skip running the prerequisite checks and
directly perform the Management Agent upgrade. If you want to specify multiple
additional parameters, separate them using a space.
Refer to Section 6.4.2 for a list of parameters you can specify.
6.
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.
Ensure that the Management Agent host user has write
permission in the custom location.
Note:
The stage location is used to store temporary Management Agent upgrade files.
7.
Click Submit.
Once you click Submit, a Management Agent upgrade job is created, which is sent
to the Enterprise Manager job system. You are automatically taken to the Agent
Upgrade Status page for the job, which displays the details of the job steps.
To view a summary of all the submitted Management Agent upgrade jobs, or
search for and view a particular set of Management Agent upgrade jobs, use the
Agent Upgrade Results page of the Agent Upgrade Console. To access this page,
from the Setup menu, select Manage Cloud Control, then select Upgrade Agents.
Click Agent Upgrade Results.
To revisit the Agent Upgrade Status page for a Management Agent upgrade job,
click the name of the job on the Agent Upgrade Results page.
If you encounter an error during the Management Agent upgrade process, or if the
Management Agent upgrade fails, refer to Section 6.6.
8.
If the root.sh step was skipped, or if this step failed, log in to the Management
Agent host as the root user, navigate to $<AGENT_BASE_DIR>/core/12.1.0.4.0/
and run the root.sh script on the host manually.
After root.sh is run, you can clean up your old Management Agents, as described
in Section 6.4.4.
6.4.1.2 Upgrading 12c Management Agents using EM CLI
To upgrade 12.1.0.x Management Agents using EM CLI, follow these steps:
1.
Log in to EM CLI from the /bin directory present within the OMS home:
$<OMS_HOME>/bin/emcli login -username=<user_name>
For example, /scratch/aime/Oracle/MW/oms/bin/emcli login
-username=sysman
Once you run this command, EM CLI will prompt you for a password. Enter the
password for the user name you specified.
2.
Synchronize EM CLI:
$<OMS_HOME>/bin/emcli sync
6-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading 12c Management Agents
3.
Run the get_upgradable_agents verb to obtain a list of the Management Agents
that can be upgraded:
$<OMS_HOME>/bin/emcli get_upgradable_agents
[-agents]
[-platforms]
[-versions]
[-groups]
[-output_file]
Note that the parameters mentioned in [ ] are optional.
For example, $<OMS_HOME>/bin/emcli get_upgradable_agents
-agents="abc%,xyz.domain.com:1243" -platforms="Linux x86,Microsoft
Windows x64 (64-bit)" -versions="12.1.0.3.0" -output_
file="/scratch/agents_file.txt"
Use the -output_file option to copy the list of upgradable Management Agents
into a file. This file can be used later as an input parameter for the upgrade_agents
verb.
To view more information on the syntax and the usage of the get_upgradable_
agents verb, run the following command:
$<OMS_HOME>/bin/emcli/help get_upgradable_agents
4.
Run the upgrade_agents verb to upgrade your Management Agents:
$<OMS_HOME>/bin/emcli upgrade_agents
-agents | -input_file="agents_file:<absolute_location>" |
-input_file="response_file:<absolute_location>"
[-validate_only]
[-pre_script_loc]
[-pre_script_on_oms]
[-post_script_loc]
[-post_script_on_oms]
[-job_name]
[-override_credential]
[-additional_parameters]
[-stage_location]
Note that the parameters mentioned in [ ] are optional.
Ensure that you specify all the Management Agents that you want to upgrade by
using either -agents, or -input_file="agents_file:<file_name>", or by
specifying agents in a response file, and then using -input_file="response_
file:<absolute_location>".
For example, $<OMS_HOME>/bin/emcli upgrade_agents
-agents="abc%,xyz.domain.com:1243" -input_file="agents_
file:/scratch/agents_file.txt" -input_file="response_
file:/scratch/agent.rsp" -stage_location=/tmp
Use the -input_file="agents_file:<absolute_location>" option to specify a
file containing the list of Management Agents that you want to upgrade. Use the
-input_file="response_file:<absolute_location>" option to specify a
response file containing all the upgrade parameters that you want to use. A
response file contains parameters in name value pairs, as shown:
job_name=UPGRADE_AGENT
additional_parameters="-ignorePrereqs START_PRIORITY_LEVEL=98"
Upgrading Oracle Management Agents 6-9
Upgrading 12c Management Agents
The parameters that you specify with the verb override the parameters that you
specify in the response file.
To view more information on the syntax and the usage of the upgrade_agents
verb, run the following command:
$<OMS_HOME>/bin/emcli help upgrade_agents
If you encounter an error during the Management Agent upgrade process, or if the
Management Agent upgrade fails, refer to Section 6.6.
5.
To view the status of the submitted Management Agent upgrade jobs, run the get_
agent_upgrade_status verb:
$<OMS_HOME>/bin emcli get_agent_upgrade_status
[-agent]
[-job_name]
[-status]
Note that the parameters mentioned in [ ] are optional.
For example, $<OMS_HOME>/bin/emcli get_agent_upgrade_status
-status="Running" will display all the Management Agent upgrade jobs that are
in progress.
You can view the detailed job step status of a particular Management Agent that
was part of a particular upgrade job by using the get_agent_upgrade_status verb
with the -agent and the -job_name options.
For example, $<OMS_HOME>/bin/emcli get_agent_upgrade_status
-agent=abc.example.com:1243 -job_name=UPGRADE_AGT_13603
If a particular Management Agent upgrade job failed, check the inputs and run the
upgrade_agents verb again. If you want to specify a custom job name (using the
-job_name parameter) while retrying the verb, ensure that you provide a unique
job name, and not the name of the job that failed. For Management Agent upgrade
troubleshooting tips, see Section 6.6.
To view more information on the syntax and the usage of the get_agent_upgrade_
status verb, run the following command:
$<OMS_HOME>/bin/emcli/help get_agent_upgrade_status
6.
If the root.sh step was skipped, or if this step failed, log in to the Management
Agent host as the root user, navigate to $<AGENT_BASE_DIR>/core/12.1.0.4.0/
and run the root.sh script on the host manually.
After root.sh is run, you can clean up your old Management Agents, as described
in Section 6.4.4.
For more information on how to use the EM CLI verbs
mentioned in this section, refer to Oracle Enterprise Manager Command
Line Interface.
Note:
6.4.2 Additional Parameters for 12c Management Agent Upgrade
Table 6–1 describes the additional parameters you can use while upgrading 12c
Management Agents using Agent Upgrade Console, or EM CLI. You can enter more
than one parameter, using a whitespace as a separator.
6-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading 12c Management Agents
Table 6–1
List of Additional Parameters for 12c 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.
START_PRIORITY_LEVEL
Use this parameter to specify the priority level of the
Management Agent service when the host is started. This
parameter accepts values between 0 and 99. However, Oracle
recommends that you provide a value between 91 and 99 for this
parameter.
(For Unix based hosts only)
For example, START_PRIORITY_LEVEL=95
If you do not include this parameter, it defaults to 98.
Important: If you had specified a value for this parameter while
installing the Management Agent that you have selected for
upgrade, ensure that you specify the same value while
upgrading the Management Agent.
SHUT_PRIORITY_LEVEL
(For Unix based hosts only)
Use this parameter to specify the priority level of the
Management Agent service when the host is shut down. This
parameter accepts values between 0 and 99.
For example, SHUT_PRIORITY_LEVEL=25
If you do not include this parameter, it defaults to 19.
Important: If you had specified a value for this parameter while
installing the Management Agent that you have selected for
upgrade, ensure that you specify the same value while
upgrading the Management Agent.
6.4.3 Viewing 12c Management Agents That Cannot Be Upgraded
You may not be able to upgrade certain 12c Management Agents using the Agent
Upgrade Console or EM CLI. Table 6–2 describes the reasons for this.
Table 6–2
Why Some Management Agents Cannot Be Upgraded
Reason
Description and Recommended Action
Latest Agent Software
Missing
The latest Management Agent software of the OMS version 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 more information
on using the Self Update console to download and apply the
latest Management Agent software, see Oracle Enterprise Manager
Cloud Control Basic Installation Guide.
Upgrading Oracle Management Agents 6-11
Upgrading 12c Management Agents
Table 6–2
(Cont.) Why Some Management Agents Cannot Be Upgraded
Reason
Description and Recommended Action
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
<EMSTATE> refers to the Management Agent instance directory,
that is, <AGENT_BASE_DIRECTORY>/agent_inst
Oracle Home Property
Missing
The Oracle Home property for the Management Agent is
missing.
This property is required to obtain the platform of the
Management Agent that you want to upgrade. For upgrading
Shared Agents, this property plays a key role in maintaining the
relationship between the Shared Agent and the Master Agent. It is
also required for certain essential Management Agent lifecycle
operations, such as patching.
To upgrade a Management Agent for which the Oracle Home
property is missing, first run OMS collections on the
Management Agent. To run OMS collections on a Management
Agent, run the following command from the Management
Agent host:
<EMSTATE>/bin/emctl control agent runCollection
<TARGET_NAME>:oracle_home oracle_home_config
<EMSTATE> refers to the Management Agent instance directory,
that is, <AGENT_BASE_DIRECTORY>/agent_inst
<TARGET_NAME> refers to the Management Agent target of target
type oracle_home that is present in
<EMSTATE>/sysman/emd/targets.xml
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 restore communication between the OMS and the
Management Agent. 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 displayed error icon, and perform the
recommended actions.
6-12 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading 12c Management Agents
Table 6–2 (Cont.) Why Some Management Agents Cannot Be Upgraded
Reason
Description and Recommended Action
Agent Pending Activation
The Management Agent version is not 12c Release 2 (12.1.0.2) or
later.
You cannot upgrade 10g, 11g, or 12c Release 1 (12.1.0.1)
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.
6.4.4 Performing Postupgrade Clean Up of Old Management Agents
When you upgrade your 12.1.0.x Management Agents, the old agent homes, old
Oracle Home targets, and backup directories of the old Management Agents remain,
and are not deleted automatically. To delete these post upgrade and free up disk space,
you can clean up the old Management Agents using Agent Upgrade Console or EM
CLI.
Important: Ensure that you perform clean up only on those
Management Agents that were upgraded successfully. For information
on verifying whether a Management Agent was upgraded
successfully, see Section 6.5.1.
This section describes the methods you can use to clean up 12.1.0.x Management
Agents after upgrading them. It consists of the following:
■
■
Performing Postupgrade Clean Up of Old Management Agents Using Agent
Upgrade Console
Performing Postupgrade Clean Up of Old Management Agents Using EM CLI
Upgrading Oracle Management Agents 6-13
Upgrading 12c Management Agents
6.4.4.1 Performing Postupgrade Clean Up of Old Management Agents Using Agent
Upgrade Console
To clean up the old directories of your old Management Agents using the Clean Up
Agents page of the Agent Upgrade Console, follow these steps:
1.
From the Setup menu, select Manage Cloud Control, then select Upgrade Agents.
2.
Click Post Agent Upgrade Tasks.
3.
To change the default clean up job name, enter a unique value for Job Name.
A unique job name enables you to identify the clean up job, know details of its
execution, and track its progress.
The job name can have a maximum length of 64 characters. It can consist of
alphanumeric and special characters, and can begin with either of these.
4.
Click Add to add Management Agents for clean up.
5.
In the Agents for Clean Up window, search for the Management Agents you want
to clean up, using the Agent, Platform, Installed Version, and Group fields.
6.
Select the Management Agents you want to clean up. Click OK.
7.
Click Submit.
6.4.4.2 Performing Postupgrade Clean Up of Old Management Agents Using EM
CLI
To clean up the old directories of your old Management Agents using EM CLI, follow
these steps:
1.
Log in to EM CLI from the /bin directory present within the OMS home:
$<OMS_HOME>/bin/emcli login -username=<user_name>
For example, /scratch/aime/Oracle/MW/oms/bin/emcli login
-username=sysman
Once you run this command, EM CLI will prompt you for a password. Enter the
password for the user name you specified.
2.
Synchronize EM CLI:
$<OMS_HOME>/bin/emcli sync
3.
Run the get_signoff_agents verb to obtain a list of the Management Agents for
which clean up can be performed:
$<OMS_HOME>/bin/emcli get_signoff_agents
[-agents]
[-platforms]
[-versions]
[-groups]
[-output_file]
Note that the parameters mentioned in [ ] are optional.
For example, $<OMS_HOME>/bin/emcli get_signoff_agents -output_
file="/scratch/signoff_agents_file.txt"
Use the -output_file option to copy the output of the get_signoff_agents verb
into a file, which you can later use as an input parameter for the signoff_agents
verb.
6-14 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading 12c Management Agents
To view more information on the syntax and the usage of the get_signoff_agents
verb, run the following command:
$<OMS_HOME>/bin/emcli help get_signoff_agents
4.
Run the signoff_agents verb to clean up your Management Agents:
$<OMS_HOME>/bin/emcli/signoff_agents
-agents | -input_file="agents_file:<absolute_location>" |
-input_file="response_file:<absolute_location>"
[-job_name]
Note that the parameters mentioned in [ ] are optional.
Ensure that you specify all the Management Agents that you want to clean up by
using either -agents, or -input_file="agents_file:<file_name>", or by
specifying agents in a response file, and then using -input_file="response_
file:<absolute_location>".
For example, $<OMS_HOME>/bin/emcli signoff_agents
-agents="abc%,xyz.domain.com:1243" -input_file="agents_
file:/scratch/signoff_agents_file.txt" -input_file="response_
file:/scratch/agent.rsp" -job_name=CLEAN_UP_12103
Use the -input_file="agents_file:<absolute_location>" option to specify a
file containing the list of Management Agents that you want to clean up. Use the
-input_file="response_file:<absolute_location>" option to specify a
response file containing all the parameters that you want to use. A response file
contains parameters in name value pairs, as shown:
agents=abc%,xyz%
job_name=CLEAN_UP_AGT_121030
The parameters that you specify with the verb override the parameters that you
specify in the response file.
To view more information on the syntax and the usage of the signoff_agents
verb, run the following command:
$<OMS_HOME>/bin/emcli help signoff_agents
For more information on how to use the EM CLI verbs
mentioned in this section, refer to Oracle Enterprise Manager Command
Line Interface.
Note:
6.4.5 Viewing 12c Management Agent Upgrade Clean Up Jobs
You can use the Clean Up Agents page or EM CLI to delete the old agent homes, old
Oracle Home targets, and backup directories of your old Management Agents, after
upgrading them. Once you select the Management Agents you want to clean up and
click Submit on the Clean Up Agents page, or run the signoff_agents EM CLI verb, a
Management Agent clean up job is created, which is sent to the Enterprise Manager
job system. You can use the Clean Up Agent Results page, or the get_signoff_status
EM CLI verb to search for and view a particular set of Management Agent clean up
jobs.
This section describes the methods you can use to view a particular set of Management
Agent clean up jobs. It consists of the following:
Upgrading Oracle Management Agents 6-15
Upgrading 12c Management Agents
■
■
Viewing 12c Management Agent Upgrade Clean Up Jobs Using Agent Upgrade
Console
Viewing 12c Management Agent Upgrade Clean Up Jobs Using EM CLI
6.4.5.1 Viewing 12c Management Agent Upgrade Clean Up Jobs Using Agent
Upgrade Console
To view a particular set of Management Agent clean up jobs using the Clean Up Agent
Results page of the Agent Upgrade Console, follow these steps:
1.
From the Setup menu, select Manage Cloud Control, then select Upgrade Agents.
2.
Click Post Agent Upgrade Tasks.
3.
Click Clean Up Agent Results.
4.
Enter or select values for parameters that you want to use to search for
Management Agent clean up jobs. You can search for these jobs using the job
name, the Management Agents that were part of the clean up, and the status of the
job.
5.
For Match, select All or Any to search for results that match all the search
parameters, or any of the search parameters, respectively.
6.
Click Search.
6.4.5.2 Viewing 12c Management Agent Upgrade Clean Up Jobs Using EM CLI
To view a particular set of Management Agent clean up jobs using EM CLI, follow
these steps:
1.
Log in to EM CLI from the /bin directory present within the OMS home:
$<OMS_HOME>/bin/emcli login -username=<user_name>
For example, /scratch/aime/Oracle/MW/oms/bin/emcli login
-username=sysman
Once you run this command, EM CLI will prompt you for a password. Enter the
password for the user name you specified.
2.
Synchronize EM CLI:
$<OMS_HOME>/bin/emcli sync
3.
Run the get_signoff_status verb to view a particular set of Management Agent
clean up jobs:
$<OMS_HOME>/bin/emcli get_signoff_status
[-agent]
[-job_name]
[-status]
Note that the parameters mentioned in [ ] are optional.
For example, $<OMS_HOME>/bin/emcli get_signoff_status -status="Success"
displays the Management Agent clean up jobs that succeeded.
To view more information on the syntax and the usage of the get_signoff_status
verb, run the following command:
$<OMS_HOME>/bin/emcli help get_signoff_status
6-16 Oracle Enterprise Manager Cloud Control Upgrade Guide
After Upgrading 12c Management Agents
For more information on how to use the EM CLI verbs
mentioned in this section, refer to Oracle Enterprise Manager Command
Line Interface.
Note:
6.5 After Upgrading 12c Management Agents
This section describes the various tasks you can perform after upgrading your
Management Agents. It consists of the following:
■
■
Verifying 12c Management Agent Upgrade
Moving Central Agent Base Directory Outside Oracle Middleware Home (After
Upgrading 12c Central Agent)
6.5.1 Verifying 12c Management Agent Upgrade
This section describes how to verify the 12c Management Agent upgrade. It consists of
the following sections:
■
Verifying 12c Management Agent Upgrade Using the Enterprise Manager Console
■
Verifying 12c Management Agent Upgrade Using EM CLI
6.5.1.1 Verifying 12c Management Agent Upgrade Using the Enterprise Manager
Console
After you upgrade your Management Agents, follow these methods to verify the
upgrade using the Enterprise Manager console:
■
■
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 that you want to verify the upgrade for, and verify
the Management Agent version. The Management Agent version after the
upgrade must be the same as the OMS version.
Also, on the Agents page, verify that the Management Agent is up and running, is
not blocked, and is not under blackout.
■
From the Setup menu, select Manage Cloud Control, then select Agents. Click the
name of the Management Agent that you want to verify the upgrade for. From the
Agent menu, select Configuration, then select Last Collected. In the
Configuration Properties tab, ensure that none of the configuration properties
mention the old Management Agent home.
6.5.1.2 Verifying 12c Management Agent Upgrade Using EM CLI
After you upgrade your Management Agents, follow these methods to verify the
upgrade using EM CLI:
■
■
Run the get_agent_upgrade_status verb to verify that the job you created to
upgrade the Management Agents succeeded. This is described in detail in Step 5
of Section 6.4.1.2.
Run the get_agent_properties verb to verify the version of the Management
Agent and its configuration properties after the upgrade:
$<OMS_HOME>/bin/emcli get_agent_properties -format=csv -agent_name=<agent_host_
Upgrading Oracle Management Agents 6-17
Troubleshooting 12c Management Agent Upgrade
name>:<agent_port>
For example, $<OMS_HOME>/bin/emcli get_agent_properties -format=csv
-agent_name=abc.example.com:1872
■
Run the get_targets verb to verify the status of the Management Agent (it should
be up and running, and not be blocked, under blackout, etc.):
$<OMS_HOME>/bin/emcli get_targets -format="name:csv" -targets=<agent_host_
name>:<agent_port>:oracle_emd -alerts
For example, $<OMS_HOME>/bin/emcli get_targets -format="name:csv"
-targets=abc.example.com:3872:oracle_emd -alerts
6.5.2 Moving Central Agent Base Directory Outside Oracle Middleware Home (After
Upgrading 12c Central Agent)
After upgrading the central agent, if the agent base directory of the upgraded central
agent resides within the Oracle Middleware home, and you want to move it outside
the Oracle Middleware home, then see Appendix G.
Important:
■
■
Moving the agent base directory is recommended only for the
central agent, and not for the other Management Agents.
Moving the agent base directory is not supported on a host that is
running on Microsoft Windows.
6.6 Troubleshooting 12c Management Agent Upgrade
Table 6–3 describes how to troubleshoot certain errors you may encounter while
upgrading your Management Agents.
6-18 Oracle Enterprise Manager Cloud Control Upgrade Guide
Troubleshooting 12c Management Agent Upgrade
Table 6–3
Problem
Troubleshooting Oracle Management Agent Upgrade
Troubleshooting Tip
When you click Submit on the
Do one of the following:
Upgrade Agents page, you encounter
■
Click OK to continue the upgrade. After the
an error mentioning that root.sh
upgrade, log in to the Management Agent host as
could not be run for a Management
the root user, and run the $<AGENT_BASE_
Agent as the preferred privileged
DIR>/core/12.1.0.4.0/root.sh script on the host.
credentials for the Oracle Home of
the Management Agent are not set.
■
Click Cancel to cancel the upgrade, then do the
following:
1.
Set the preferred
privileged credentials
for the Oracle Home
target of the
Management Agent.
For information on how
to do this, see Oracle
Enterprise Manager
Cloud Control
Administrator’s Guide.
2.
Upgrade the
Management Agent.
If you do not want to set the preferred privileged
credentials for the Oracle Home target of the
Management Agent, when the error message is
displayed, click Cancel, then do the following:
1.
Select Override
Privileged Credentials,
then 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.
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.4.0/root.sh script manually.
Upgrading Oracle Management Agents 6-19
Troubleshooting 12c Management Agent Upgrade
Table 6–3
Problem
(Cont.) Troubleshooting Oracle Management Agent Upgrade
Troubleshooting Tip
When you click Submit on the
Do one of the following:
Upgrade Agents page, you encounter
■
When the error message is displayed, click OK to
an error mentioning that root.sh
continue the upgrade. After the upgrade, log in to
could not be run for a Management
the Management Agent host as the root user, and
Agent as the privilege delegation
run the $<AGENT_BASE_
settings for the Management Agent
DIR>/core/12.1.0.4.0/root.sh script on the host.
host are not set.
■
When the error message is displayed, click Cancel
to cancel the upgrade, then do the following:
1.
Configure privilege
delegation settings on
the Management Agent
host.
For information on how
to do this, see Oracle
Enterprise Manager
Lifecycle Management
Administrator's Guide.
2.
Upgrade the
Management Agent.
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.4.0/root.sh script manually.
When you click Submit on the
Do one of the following:
Upgrade Agents page, you encounter
■
Click OK to continue the upgrade. After the
an error mentioning that root.sh
upgrade, log in to the Management Agent host as
could not be run for a Management
the root user, and run the $<AGENT_BASE_
Agent as Run as root is not set for the
DIR>/core/12.1.0.4.0/root.sh script on the host.
Management Agent Oracle Home
preferred privileged credential.
■
Click Cancel to cancel the upgrade, then do the
following:
1.
Edit the preferred
privileged credentials
for the Oracle Home
target of the
Management Agent to
ensure that the
credential has root
privileges. For
information on how to
do this, see Oracle
Enterprise Manager
Lifecycle Management
Administrator's Guide.
2.
Upgrade the
Management Agent.
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.4.0/root.sh script manually.
6-20 Oracle Enterprise Manager Cloud Control Upgrade Guide
Troubleshooting 12c Management Agent Upgrade
Table 6–3
(Cont.) Troubleshooting Oracle Management Agent Upgrade
Problem
Troubleshooting Tip
When you click Submit on the
Upgrade Agents page, the Upgrade
Agents step fails.
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 failed job step.
2.
View the Management Agent deployment log
available at the following location:
$<AGENT_BASE_
DIRECTORY>/core/12.1.0.4.0/cfgtoollogs/agent
Deploy/agentDeploy_<TIMESTAMP>.log
3.
View the plug-in upgrade configuration log
available at the following location:
$<AGENT_BASE_DIRECTORY>/backup_agtup/backup_
<TIMESTAMP>/agtNew/install/logs/agentplugind
eploy_<TIMESTAMP>.log
The Management Agent cannot be
upgraded as the 32-bit Management
Agent software for the host platform
is not present in 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.
For information on using the Self Update console to
download and apply the latest Management Agent
software, refer to Oracle Enterprise Manager Cloud
Control Basic Installation Guide.
The links on the Agent Upgrade
Status page or the Agent Upgrade
Results page are not working.
Diagnose the problem by viewing the following logs:
■
$<OMS_INSTANCE_HOME>/user_
projects/domains/EMGC_DOMAIN/servers/EMGC_
OMS1/logs/*.out
■
$<OMS_INSTANCE_HOME>/user_
projects/domains/EMGC_DOMAIN/servers/EMGC_
OMS1/logs/*.log
A job step in the Management Agent Diagnose the problem by viewing the following log:
upgrade process hangs or is executed
$<OMS_INSTANCE_HOME>/em/EMGC_
multiple times.
OMS1/sysman/log/*.trc
EM CLI log in or synchronization
fails.
Diagnose the problem by viewing the following log:
The upgraded Management Agent is
blocked.
Raise an Oracle Support service request. Do not
resynchronize the Management Agent.
$<NEW_AGENT_ORACLE_HOME>/EMGC_
OMS1/sysman/emcli/setup/.emcli/*.log
For additional Management Agent troubleshooting tips, see the My Oracle Support
note 1569883.1.
Upgrading Oracle Management Agents 6-21
Troubleshooting 12c Management Agent Upgrade
6-22 Oracle Enterprise Manager Cloud Control Upgrade Guide
7
Upgrading or Redeploying ADP and JVMD
7
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 Enterprise Manager is successfully upgraded to
12c Release 4 (12.1.0.4), the ADP and JVMD Engines that were part of your enterprise
before the upgrade must be re-created. This chapter describes how to upgrade or
redeploy ADP and JVMD.
For information about deploying JVMD Engines and JVMD
Agents with basic and advanced options, see the following guides:
Note:
■
■
Oracle Enterprise Manager Cloud Control Basic Installation Guide
Oracle Enterprise Manager Cloud Control Advanced Installation and
Configuration Guide
For information about deploying ADP Engines 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
This chapter consists of the following sections:
■
Upgrading or Redeploying JVMD and ADP Engine
■
Upgrading or Redeploying JVMD and ADP Agents
■
After Upgrading or Redeploying ADP and JVMD
7.1 Upgrading or Redeploying JVMD and ADP Engine
This section describes the methods to upgrade or redeploy ADP and JVMD Engines. It
consists of the following:
■
Upgrading JVMD Engine
■
Redeploying JVMD Engine
■
Upgrading ADP Engine
■
Redeploying ADP Engine
Upgrading or Redeploying ADP and JVMD
7-1
Upgrading or Redeploying JVMD and ADP Engine
7.1.1 Upgrading JVMD Engine
This section describes the methods to upgrade JVMD Engine. It consists of the
following:
■
Upgrading JVMD Engine Using Application Performance Management Page
■
Upgrading JVMD Engine Manually Using ApmEngineSetup.pl
Important:
■
■
■
When you upgrade the Enterprise Manager for Oracle Fusion
Middleware plug-in to version 12.1.0.6, the deployed JVMD
Engines are not upgraded automatically. You must upgrade them
using the methods described in this section.
You can only upgrade the JVMD Engines that are deployed on
OMS hosts, and not the JVMD Engines that are deployed on
remote hosts.
Before upgrading the deployed JVMD Engines, it is recommended
that you first shut them down manually.
7.1.1.1 Upgrading JVMD Engine Using Application Performance Management Page
To upgrade JVMD Engine deployed on a Managed Server using the Application
Performance Management page, follow these steps:
1.
From the Setup menu, select Middleware Management, then select Application
Performance Management.
2.
On the Application Performance Management page, click the upgrade icon
displayed beside JVM Diagnostics Engines.
The upgrade icon is displayed only if a software version
different from the current deployed version of the JVMD Engine
software is available.
Note:
3.
On the Upgrade JVMD Engines page, select the JVMD Engine you want to
upgrade.
4.
Specify a value for Host Credentials. These credentials are the host credentials of
the host on which the JVMD Engine you selected is deployed. Click Apply.
5.
If you want to upgrade more than one JVMD Engine, on the Upgrade JVMD
Engines page, select the JVMD engines you want to upgrade, then specify and
apply values for Host Credentials, for each one of them.
6.
Specify a value for Admin WebLogic Credentials. These credentials are the
credentials for the Administration Server of the Enterprise Manager WebLogic
domain.
7.
Click Upgrade.
If you encounter any errors during the upgrade, see Oracle Enterprise Manager
Cloud Control Advanced Installation Guide.
7-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading or Redeploying JVMD and ADP Engine
After upgrading a JVMD Engine, if two entries exist for the
same JVMD Engine on the Application Performance Management
page, delete the old entry from the jam_managers table by logging in
to the Enterprise Manager Repository as the sysman user and
executing the following query:
Note:
delete from jam_managers where manager_id =<manager_id_of_
old_jvmd_engine>
7.1.1.2 Upgrading JVMD Engine Manually Using ApmEngineSetup.pl
You can upgrade JVMD Engine manually, using the ApmEngineSetup.pl script. You
can run this script in the following ways:
■
■
In interactive mode, where you are prompted for input details in an interactive
manner
In silent mode, where you specify all the input details using a properties file
To upgrade JVMD Engine manually using the ApmEngineSetup.pl script, follow these
steps:
1.
Navigate to the following location on the OMS host:
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_
12.1.0.6.0/archives/jvmd/deployment_Scripts/engine/
2.
View the README.txt file, for information on using the ApmEngineSetup.pl script.
3.
Run the ApmEngineSetup.pl script.
If you want to run the ApmEngineSetup.pl script in interactive mode, such that
you are prompted for the input details, use the following command:
perl ApmEngineSetup.pl
Ensure that you specify the operation as upgrade, and the Engine Type as JVMD.
If you want to run the ApmEngineSetup.pl script in silent mode, specify all the
input details in a properties file, then use the following command:
perl ApmEngineSetup.pl -silent -file <properties_file_name> -password
<password>
<properties_file_name> is the name of the properties file where the JVMD
Engine and operation details are provided. <password> is the WebLogic console
password.
To learn how to specify the input details in a properties file, view the sample
properties file SAMPLE_engine.properties.
After upgrading a JVMD Engine, if two entries exist for the
same JVMD Engine on the Application Performance Management
page, delete the old entry from the jam_managers table by logging in
to the Enterprise Manager Repository as the sysman user and
executing the following query:
Note:
delete from jam_managers where manager_id =<manager_id_of_
old_jvmd_engine>
Upgrading or Redeploying ADP and JVMD
7-3
Upgrading or Redeploying JVMD and ADP Engine
7.1.2 Redeploying JVMD Engine
To redeploy JVMD Engine deployed on a Managed Server, follow these steps:
You can only redeploy JVMD Engine if a different version of
the JVMD Engine software is not available. If a newer version or an
older version of the JVMD Engine software is available, you can only
upgrade the existing JVMD Engine to the newer version, or
downgrade it to the older version, but not redeploy the existing JVMD
Engine version. For information on how to upgrade JVMD Engine,
refer Section 7.1.1.
Note:
1.
From the Setup menu, select Middleware Management, then select Application
Performance Management.
2.
If you want to redeploy a single JVMD Engine, on the Application Performance
Management page, select the JVMD Engine you want to redeploy, then click
Redeploy.
If you want to redeploy more than one JVMD Engine, on the Application
Performance Management page, select the JVM Diagnostics Engines node, then
click Redeploy.
3.
On the Redeploy JVMD Engines page, select the JVMD Engines you want to
redeploy.
4.
For each JVMD Engine you have chosen to redeploy, specify a value for Host
Credentials. These credentials are the host credentials of the host on which the
JVMD Engine you selected is deployed. Click Apply.
5.
Specify a value for Admin WebLogic Credentials. These credentials are the
credentials for the Administration Server of the Enterprise Manager WebLogic
domain.
6.
Click Redeploy.
If you encounter any errors during the redeployment, see Oracle Enterprise
Manager Cloud Control Advanced Installation Guide.
7.1.3 Upgrading ADP Engine
This section describes the methods to upgrade ADP Engine. It consists of the
following:
■
Upgrading ADP Engine Using Application Performance Management Page
■
Upgrading ADP Engine Manually Using ApmEngineSetup.pl
7-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading or Redeploying JVMD and ADP Engine
Important:
■
■
■
When you upgrade the Enterprise Manager for Oracle Fusion
Middleware plug-in to version 12.1.0.6, the deployed ADP
Engines are not upgraded automatically. You must upgrade them
using the methods described in this section.
You can only upgrade the ADP Engines that are deployed on
OMS hosts, and not the ADP Engines that are deployed on remote
hosts.
Before upgrading the deployed ADP Engines, it is recommended
that you first shut them down manually.
7.1.3.1 Upgrading ADP Engine Using Application Performance Management Page
To upgrade ADP Engine deployed on a Managed Server using the Application
Performance Management page, follow these steps:
1.
From the Setup menu, select Middleware Management, then select Application
Performance Management.
2.
On the Application Performance Management page, click the upgrade icon
displayed beside ADP Engines.
The upgrade icon is displayed only if a software version
different from the current deployed version of the ADP Engine
software is available.
Note:
3.
On the Upgrade ADP Engines page, select the ADP Engine you want to upgrade.
4.
Specify a value for Host Credentials. These credentials are the host credentials of
the host on which the ADP Engine you selected is deployed. Click Apply.
5.
If you want to upgrade more than one ADP Engine, on the Upgrade ADP Engines
page, select the ADP engines you want to upgrade, then specify and apply values
for Host Credentials, for each one of them.
6.
Specify a value for Admin WebLogic Credentials. These credentials are the
credentials for the Administration Server of the Enterprise Manager WebLogic
domain.
7.
Click Upgrade.
If you encounter any errors during the upgrade, see Oracle Enterprise Manager
Cloud Control Advanced Installation Guide.
7.1.3.2 Upgrading ADP Engine Manually Using ApmEngineSetup.pl
You can upgrade ADP Engine manually, using the ApmEngineSetup.pl script. You can
run this script in the following ways:
■
■
In interactive mode, where you are prompted for input details in an interactive
manner
In silent mode, where you specify all the input details using a properties file
To upgrade ADP Engine manually using the ApmEngineSetup.pl script, follow these
steps:
1.
Navigate to the following location on the OMS host:
Upgrading or Redeploying ADP and JVMD
7-5
Upgrading or Redeploying JVMD and ADP Engine
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_
12.1.0.6.0/archives/jvmd/deploymentScripts/engine/
2.
View the README.txt file, for information on using the ApmEngineSetup.pl script.
3.
Run the ApmEngineSetup.pl script.
If you want to run the ApmEngineSetup.pl script in interactive mode, such that
you are prompted for the input details, use the following command:
perl ApmEngineSetup.pl
Ensure that you specify the operation as upgrade, and the Engine Type as ADP.
If you want to run the ApmEngineSetup.pl script in silent mode, specify all the
input details in a properties file, then use the following command:
perl ApmEngineSetup.pl -silent -file <properties_file_name> -password
<password>
<properties_file_name> is the name of the properties file where the ADP Engine
and operation details are provided. <password> is the WebLogic console password.
To learn how to specify the input details in a properties file, view the sample
properties file SAMPLE_engine.properties.
7.1.4 Redeploying ADP Engine
To redeploy ADP Engine deployed on a Managed Server, follow these steps:
You can only redeploy ADP Engine if a different version of the
ADP Engine software is not available. If a newer version or an older
version of the ADP Engine software is available, you can only
upgrade the existing ADP Engine to the newer version, or downgrade
it to the older version, but not redeploy the existing ADP Engine
version. For information on how to upgrade ADP Engine, refer
Section 7.1.3.
Note:
1.
From the Setup menu, select Middleware Management, then select Application
Performance Management.
2.
If you want to redeploy a single ADP Engine, on the Application Performance
Management page, select the ADP Engine you want to redeploy, then click
Redeploy.
If you want to redeploy more than one ADP Engine, on the Application
Performance Management page, select the ADP Engines node, then click
Redeploy.
3.
On the Redeploy ADP Engines page, select the ADP Engines you want to
redeploy.
4.
For each ADP Engine you have chosen to redeploy, specify a value for Host
Credentials. These credentials are the host credentials of the host on which the
ADP Engine you selected is deployed. Click Apply.
5.
Specify a value for Admin WebLogic Credentials. These credentials are the
credentials for the Administration Server of the Enterprise Manager WebLogic
domain.
6.
Click Redeploy.
7-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading or Redeploying JVMD and ADP Agents
If you encounter any errors during the redeployment, see Oracle Enterprise
Manager Cloud Control Advanced Installation Guide.
7.2 Upgrading or Redeploying JVMD and ADP Agents
This section describes the methods to upgrade or redeploy JVMD and ADP Agents. It
consists of the following:
■
Upgrading or Redeploying JVMD and ADP Agents Using Application
Performance Management Page
■
Upgrading or Redeploying JVMD Agents Manually Using deploy_jvmdagent.pl
■
Upgrading or Redeploying ADP Agents Manually Using deploy_adpagent.pl
7.2.1 Upgrading or Redeploying JVMD and ADP Agents Using Application Performance
Management Page
To upgrade or redeploy JVMD and ADP Agents on monitored WebLogic domains
using the Application Performance Management page, follow these steps:
You can only redeploy JVMD and ADP Agents if a different
version of the JVMD or ADP Agent software is not available. If a
newer version or an older version of the JVMD or ADP Agent
software is available, you can only upgrade the existing JVMD or ADP
Agent to the newer version, or downgrade it to the older version, but
not redeploy the existing JVMD or ADP Agent version.
Note:
1.
From the Setup menu, select Middleware Management, then select Application
Performance Management.
2.
On the Application Performance Management page, under the Application
Performance Management Agents section, click Manage Diagnostics Agents.
If no active JVMD or ADP Engines are present, and no JVMD
or ADP Agents are deployed, the Manage Diagnostics Agents button
is disabled.
Note:
3.
For Operation, select Upgrade.
Alternatively, to reach this point, you can click the upgrade
icon displayed beside ADP Agents Count or JVMD Agents Count, on
the Application Performance Management page. Note that this icon is
displayed only if a software version different from the current version
of the ADP or JVMD Agent software is available.
Note:
If you select Expand All from the View menu, you can view the target name,
target type, target host, target status, platform, and so on of all the Managed
Servers on which JVMD or ADP Agents are deployed.
Select the JVMD and ADP Agents you want to upgrade or redeploy. Click Next.
Upgrading or Redeploying ADP and JVMD
7-7
Upgrading or Redeploying JVMD and ADP Agents
4.
On the Target Credentials page, for each WebLogic domain, specify a value for
Oracle WebLogic Administration Server Host Credentials and Oracle WebLogic
Domain Credentials, then click Apply.
Oracle WebLogic Administration Server Host Credentials are the host credentials
for the host on which the Management Agent that is monitoring the selected
WebLogic domain is running. Oracle WebLogic Domain Credentials are the
credentials for the Administration Server of the selected WebLogic domain.
Click Next.
5.
On the ADP Agents Configurations page, for each WebLogic domain, select an
ADP Engine for Available ADP Engines, then click Apply. All the ADP Agents
deployed on the Managed Servers of the selected WebLogic domain will report to
the selected ADP Engine.
You can specify an alternate location for the ADP Agent software, which is used if
the specified Administration Server Host Credentials do not have write
permissions on the default location. To do this, under the Agent Directory section,
select Edit the default ADP Agent Directory location if required, then specify a
value for Agent Directory.
If the WebLogic Home and Middleware Home fields are displayed under the
Additional Configuration section, specify values for them. The WebLogic Home
and Middleware Home fields are displayed if their values could not be obtained
internally.
Also, sometimes when the WebLogic Administration Server is behind a firewall or
on a virtual host, the application may not be able to connect to it, using the default
host value. In this case, you may need to provide some additional information in
the Additional Configuration section. For example, if the WebLogic
Administration Server is on a virtual host, and the application cannot connect to it
using the default host value, you may have to provide the virtual host IP address
in the Additional Configuration section.
Click Next.
6.
On the JVMD Agents Configurations page, for each WebLogic domain, select a
JVMD Engine for Available JVMD Engines, then click Apply. All the JVMD
Agents deployed on Managed Servers of the selected WebLogic domain will
report to this JVMD Engine. Alternatively, you can select Other to connect to a
load balancer in case of multiple engines.
If the WebLogic Home and Middleware Home fields are displayed under the
Additional Configuration section, specify values for them. The WebLogic Home
and Middleware Home fields are displayed if their values could not be obtained
internally.
Also, sometimes when the WebLogic Administration Server is behind a firewall or
on a virtual host, the application may not be able to connect to it, using the default
host value. In this case, you may need to provide some additional information in
the Additional Configuration section. For example, if the WebLogic
Administration Server is on a virtual host, and the application cannot connect to it
using the default host value, you may have to provide the virtual host IP address
in the Additional Configuration section.
Click Next.
7.
On the Enterprise Manager OMS Credentials page, specify a value for Oracle
Enterprise Manager WebLogic Administration Server Host Credentials, and
Oracle Enterprise Manager WebLogic Domain Credentials.
7-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading or Redeploying JVMD and ADP Agents
Note: The Enterprise Manager OMS Credentials page is displayed
when you click Next on the JVMD Agents Configurations page, only
if you have chosen to redeploy or upgrade at least one ADP Agent.
OMS credentials are not required to redeploy or upgrade JVMD
Agents.
Oracle Enterprise Manager WebLogic Administration Server Host Credentials are
the host credentials of the OMS host. The Oracle Enterprise Manager WebLogic
Domain Credentials are the domain credentials of the Enterprise Manager
WebLogic domain.
Click Next.
8.
On the Review page, review all the information, then click Upgrade.
When you click Upgrade, the Diagnostic Agents Deployment Status page appears,
which you can use to monitor the progress of the submitted job.
If you encounter any errors during the upgrade or redeployment, see Oracle
Enterprise Manager Cloud Control Advanced Installation Guide.
7.2.2 Upgrading or Redeploying JVMD Agents Manually Using deploy_jvmdagent.pl
You can upgrade or redeploy JVMD Agents manually, using the deploy_jvmdagent.pl
script. You can run this script only in silent mode, that is, you must specify all the
input details using a properties file.
To upgrade or redeploy JVMD Agents manually using deploy_jvmdagent.pl, follow
these steps:
1.
Ensure that the latest version of javadiagnosticagent.ear or jamagent.war has
been downloaded.
For information on how to download javadiagnosticagent.ear or
jamagent.war, see Oracle Enterprise Manager Cloud Control Advanced Installation
and Configuration Guide.
2.
Navigate to the following location on the OMS host:
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_
12.1.0.6.0/archives/jvmd/deployment_Scripts/agent/jvmd/
3.
View the README.txt file for information on how to use the deploy_jvmdagent.pl
script.
4.
Specify all the inputs in a properties file, then use the following command:
perl deploy_jvmdagent.pl [-appserver <server_type>] [-file <name_of_
properties_file>]
For example, perl deploy_jvmdagent.pl -appserver WLS -file wls_
upgrade.properties.
Using deploy_jvmdagent.pl, you can upgrade or redeploy only those JVMD
Agents that are deployed on WebLogic Server and GlassFish, and not the JVMD
Agents that are deployed on other application servers. The -appserver parameter
specifies the application server on which the JVMD Agent (that you want to
upgrade or redeploy) is deployed. If you are upgrading or redeploying a JVMD
Agent that is deployed on a WebLogic Managed Server, specify WLS for
-appserver. If you are upgrading or redeploying a JVMD Agent that is deployed
Upgrading or Redeploying ADP and JVMD
7-9
After Upgrading or Redeploying ADP and JVMD
on a GlassFish server, specify GF for -appserver. If you do not specify the
-appserver parameter, it is assigned the value WLS by default.
The -file parameter specifies the name of the properties file containing the
upgrade or deployment inputs. If you do not specify this parameter, and have
specified WLS for -appserver, deploy_jvmdagent.pl searches for a properties file
named weblogic_deploy.properties in the folder containing the script. If you do
not specify the -file parameter, and have specified GF for -appserver, deploy_
jvmdagent.pl looks for a properties file named glassfish_deploy.properties in
the folder containing the script. To learn how to specify the input details in a
properties file, view the sample properties files sample_weblogic_
deploy.properties or sample_glassfish_deploy.properties.
7.2.3 Upgrading or Redeploying ADP Agents Manually Using deploy_adpagent.pl
You can upgrade or redeploy ADP Agents manually, using the deploy_adpagent.pl
script. You can run this script only in silent mode, that is, you must specify all the
input details using a properties file.
To upgrade or redeploy ADP Agents manually using deploy_adpagent.pl, follow
these steps:
1.
Navigate to the following location on the OMS host:
$<MIDDLEWARE_HOME>/plugins/oracle.sysman.emas.oms.plugin_
12.1.0.6.0/archives/jvmd/deploymentScripts/agent/adp/
2.
View the README.txt file, for information on using the deploy_adpagent.pl script.
3.
Specify all the inputs in a properties file, then use the following command:
perl deploy_adpagent.pl <properties_file_name>
If you do not pass the name of the properties file as a parameter while running
deploy_adpagent.pl, deploy_adpagent.pl looks for a properties file named
adpagent.properties in the folder containing the script. To learn how to specify
the input details in a properties file, view the sample properties file SAMPLE_
adpagent.properties.
7.3 After Upgrading or Redeploying ADP and JVMD
After upgrading or redeploying your JVMD Engines or JVMD Agents, verify the
deployment of their new versions, as described in Oracle Enterprise Manager Cloud
Control Basic Installation Guide.
After upgrading or redeploying your ADP Engines or ADP Agents, verify the
deployment of their new versions, as described in Oracle Enterprise Manager Cloud
Control Basic Installation Guide.
7-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Part III
Part III
Upgrading Enterprise Manager Grid Control
10g Release 5 (10.2.0.5) or 11g Release 1
(11.1.0.1) to 12c Release 4 (12.1.0.4)
This part describes how you can upgrade 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 4 (12.1.0.4).
This part covers the following chapters:
■
■
■
■
■
Chapter 8, "Getting Started with Upgrading Enterprise Manager Grid Control 10g
Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)"
Chapter 9, "Meeting the Preupgrade Requirements for Upgrading Enterprise
Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c
Release 4 (12.1.0.4)"
Chapter 10, "Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)"
Chapter 11, "Upgrading Oracle Management Service and Oracle Management
Repository 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
(12.1.0.4)"
Chapter 12, "Performing Postupgrade Tasks After Upgrading to Enterprise
Manager Cloud Control 12c Release 4 (12.1.0.4)"
8
Getting Started with Upgrading Enterprise
Manager Grid Control 10g Release 5 (10.2.0.5)
or 11g Release 1 (11.1.0.1) to 12c Release 4
(12.1.0.4)
8
This chapter describes the high-level process for upgrading your Enterprise Manager
Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to Enterprise Manager
Cloud Control 12c Release 4 (12.1.0.4) using different upgrade approaches. In
particular, this chapter describes the following:
■
■
■
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade Approach
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 2-System Upgrade Approach
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade Approach on
a Different Host
8.1 Upgrading an Enterprise Manager Grid Control 10g Release 5
(10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with
1-System Upgrade Approach
Table 8–1 describes the steps for upgrading your Enterprise Manager Grid Control 10g
Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4) with 1-system upgrade approach.
Before you begin upgrading the Enterprise Manager system,
Oracle recommends that review the Oracle Enterprise Manager Cloud
Control Basic Installation Guide to learn about the plug-ins released in
September 2014, October 2014, and January 2015, and to understand
the use cases pertaining to this plug-in release. Identify the use case
that best suits your requirement, and follow the high-level instructions
provided against that use case in the table.
Note:
Getting Started with Upgrading Enterprise Manager Grid Control (11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release or
4 (12.1.0.4)
11g Release
8-1
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–1
Approach
Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Step No.
Step
Step 1
Prepare Yourself
(a)
Learn about the 1-System upgrade approach.
Section 2.2
(b)
Review the important facts you need to know before you begin.
Chapter 3
Step 2
Perform Preupgrade Tasks
(a)
Apply the preupgrade console patch on all your OMS instances to Section 2.2.3.1
get access to the Preupgrade Console.
(b)
Manually download the following software, and stage them to an
accessible location:
■
Oracle Management Agent 12c
■
All the required plug-ins
Procedure
Section 3.6.2.1
(c)
Provide information about the location of the software you
manually downloaded and staged in Step 2 (b)
(d)
Analyze your environment to identify Oracle Management Agents Section 9.6
(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).
(e)
Meet the prerequisites for upgrading the Management Agents as
described in Oracle Enterprise Manager Cloud Control Basic
Installation Guide.
Step 3
Upgrade Oracle Management Agent
(a)
Deploy and configure the software binaries of Oracle
Management Agent 12c.
Section 10.1
(b)
Generate a health report and check the readiness of the
predeployed Management Agents.
Section 10.2
(c)
Verify and sign off the health check report.
Section 10.3
(d)
Switch over the old Management Agents to the newly deployed
ones so that they can communicate with the upgraded Enterprise
Manager Cloud Control.
Section 10.4
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.
Step 4
Upgrade Oracle Management Service and Oracle Management
Repository
8-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Section 9.4
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–1 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach
Step No.
Step
(a)
Meet the following prerequisites:
■
■
■
■
■
■
Procedure
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.
Upgrade to 12c Release 4 (12.1.0.4) is an out-of-place upgrade,
therefore make sure your host meets the hardware
requirements specific to 12c Release 4 (12.1.0.4) as described
in Oracle Enterprise Manager Cloud Control Basic Installation
Guide. Here, host refers to the host on which your current
Enterprise Manager, which you want to upgrade, is running.
Meet the Management Agent-related prerequisites described
in Oracle Enterprise Manager Cloud Control Basic Installation
Guide.
Ensure that you are upgrading only on the supported
platforms as listed in Section 3.2.
Ensure that the ports used by Enterprise Manager are not set
to a value lower than or equal to 1024. If they are, then the
upgrade will fail. Ports up to 1024 are typically reserved for
root users (super users). Therefore, make sure the ports are
greater than 1024.
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.
Getting Started with Upgrading Enterprise Manager Grid Control (11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release or
4 (12.1.0.4)
11g Release
8-3
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–1 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach
Step No.
Step
(b)
On the Management Repository, meet the following prerequisites:
■
Procedure
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
log_owner='SYSMAN'
from all_mview_logs where
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
8-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–1 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach
Step No.
Step
(c)
(CRITICAL MANDATORY STEP)
Procedure
Apply the following patches on the database. You can access My
Oracle Support and search for these patches. For instructions, see
the ReadMe file associated with the patch. If you do not apply
these patches, you will run into upgrade failures that cannot be
corrected.
For Oracle Database 11 Release 1 (11.1.0.7)
■
■
On Unix platforms, apply patch 17082366 (Patch Set Update
17). Then apply patch 9577583 and patch 8405205.
On Microsoft Windows (32 bit and 64 bit) platforms, apply
patch 17363760 (Patch 54).
For Oracle Database 11g Release 2 (11.2.0.1)
■
■
On Unix platforms, apply patch 12419378 (Patch Set Update 6).
On Microsoft Windows (64 bit) platforms, apply patch
13423278 (Patch 16).
For Oracle Database 11g Release 2 (11.2.0.2)
■
■
■
On Unix platforms, apply patch 11061801 and patch 9748749.
On Microsoft Windows (32 bit) platforms, apply patch
11061801 and patch 12429530.
On Microsoft Windows (64-bit) platforms, apply patch
11061801 and patch 12429531.
For Oracle Database 11g Release 2 (11.2.0.3), 10g Release 2
(10.2.0.5)
On Unix as well as Microsoft Windows platforms, apply the patch
11061801.
Note: Oracle also recommends that you apply patch 13496395. For
information on what database releases you can apply the patch,
see the ReadMe that is packaged with the patch.
(d)
Stop all running and scheduled deployment procedures in your
existing Enterprise Manager system before upgrading the system.
To verify this, run the following query, and note down the GUID
of the running or scheduled deployment procedures.
SELECT i.instance_guid FROM SYSMAN.MGMT_PAF_STATES s,
SYSMAN.MGMT_PAF_INSTANCES i, SYSMAN.MGMT_PAF_PROCEDURES p
WHERE p.procedure_guid = i.procedure_guid AND s.instance_
guid = i.instance_guid AND s.state_type = 0 AND s.status
in (0,1)
To stop the running or scheduled deployment procedures, run the
following query, and pass the GUID you noted down from the
output of the preceding command:
emcli stop_instance -instance=<instance id from sql
query>
Getting Started with Upgrading Enterprise Manager Grid Control (11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release or
4 (12.1.0.4)
11g Release
8-5
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–1 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach
Step No.
Step
(e)
(Only if you have Application Dependency and Performance (ADP) or
JVM Diagnostics (JVMD) installed)
Perform the following steps before the upgrade:
1.
Take an inventory of the JVMs and WebLogic domains being
monitored by JVMD and/or ADP.
To view a list of deployed JVMD Agents, run the following
query:
select * from jam_jvm;
To view a list of the WebLogic domains being monitored by
ADP, access the ADP home page. In the Enterprise Manager
console, from the Targets menu, select Middleware. From the
Middleware Features menu on the Middleware page, select
Application Dependency and Performance.
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 (or by using the
Oracle WebLogic Scripting Tool).
3.
Take an inventory of the deployed ADP and JVMD Engines.
Shut down all of your ADP and JVMD Engines using the
WebLogic Administration Console or the Oracle WebLogic
Scripting Tool (WLST).
To view a list of deployed JVMD Engines, run the following
query:
select * from jam_managers;
To view a list of deployed ADP Engines, run the following
query:
select * from ocamm_manager_configuration;
4.
Remove all the ADP and JVMD managed servers from the
GCDomain using the WebLogic Administration Console.
Perform the following steps after the upgrade:
1.
Run the purge scripts for JVMD:
(a) Navigate to the following location:
<middleware_
home>/plugins/oracle.sysman.emas.oms.plugin__
12.1.0.4.0/archives/jvmd/
(b) Extract the file jvmd.zip.
(c) View README.txt.
(d) Run the script jvmd_monitoringupgrade11_12.sql.
(e) Run the script jvmd_traceupgrade11_12.sql if there are
existing Thread Snapshots from Enterprise Manager 11g Grid
Control Release 1 (11.1.0.1).
2.
Run the following upgrade script for a schema upgrade:
<middleware_
home>/plugins/oracle.sysman.emas.oms.plugin_
12.1.0.4.0/sql/ias/12.1.0.3/camm_product/camm_schema_
upgrade.sql
8-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Procedure
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–1 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach
Step No.
Step
(f)
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.
Procedure
$<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".
(g)
Stop the OMS you are about to upgrade and also the other OMS
instances that connect to it.
■
If you are upgrading from Enterprise Manager 11g Grid
Control Release 1 (11.1.0.1), then first run this command:
$<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:
$<OMS_HOME>/opmn/bin/opmnctl stopall
(h)
Shut down the Management Agent that monitors the Management
Services and Repository target, to prevent the Management Agent
from connecting to the Management Repository for metric
collections. Not shutting down this Management Agent might
cause the OMS upgrade to fail.
Getting Started with Upgrading Enterprise Manager Grid Control (11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release or
4 (12.1.0.4)
11g Release
8-7
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–1 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach
Step No.
Step
Procedure
(i)
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.
For
single-OMS
environment,
see:
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 example,
■
Section 11.1.1
■
Section 11.2.1
■
Section 11.3.1
■
Section 11.4.1
For
multi-OMS
environment
(with additional
OMS
instances), see
Section 11.6
/u01/software/oracle/middleware/oms11g/bin/emctl
config emkey -copy_to_repos_from_file -repos_conndesc
’"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost.mydomain.com
)(PORT=1521)))(CONNECT_DATA=(SID=emrepos12)))"’
-repos_user sysman -emkey_file
/u01/software/oracle/middleware/oms11g/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.
Step 5
Perform Postupgrade Task
(a)
If you have a Server Load Balancer (SLB) configured, then modify
the settings of your monitors.
Appendix E
(b)
Check agent upgrade status.
Section 12.5
(c)
Perform the general post-upgrade tasks.
Section 12.6
(d)
Track the status of deferred data migration jobs.
Section 12.7
(e)
Sign off agent migration process.
Section 12.11
(f)
Sign off the upgrade process and exit the upgrade mode.
Section 12.12
8-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–1 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach
Step No.
Step
(g)
(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:
Procedure
(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.
(h)
Configure Oracle BI Publisher if required.
Oracle
Enterprise
Manager Cloud
Control
Advanced
Installation and
Configuration
Guide
(i)
Delete the old OMS home.
Section 12.15
8.2 Upgrading an Enterprise Manager Grid Control 10g Release 5
(10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with
2-System Upgrade Approach
Table 8–2 describes the steps for upgrading your Enterprise Manager Grid Control 10g
Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4) with 2-system upgrade approach.
Before you begin upgrading the Enterprise Manager system,
Oracle recommends that review the Oracle Enterprise Manager Cloud
Control Basic Installation Guide to learn about the plug-ins released in
September 2014, October 2014, and January 2015, and to understand
the use cases pertaining to this plug-in release. Identify the use case
that best suits your requirement, and follow the high-level instructions
provided against that use case in the table.
Note:
Getting Started with Upgrading Enterprise Manager Grid Control (11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release or
4 (12.1.0.4)
11g Release
8-9
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–2
Approach
Step
No.
Upgrading Enterprise Manager Grid Control with 2-System Upgrade
Step
Procedure
Step 1 Prepare Yourself
(a)
Learn about the 2-System upgrade approach.
Section 2.2
(b)
Review the important facts you need to know before you begin.
Chapter 3
Step 2 Perform Preupgrade Tasks
(a)
Apply the preupgrade console patch on all your OMS instances to get
access to the Preupgrade Console.
Section 2.2.3.1
(b)
Provide information about the host where you plan to upgrade your
existing OMS.
Section 9.2
(c)
Manually download the following software, and stage them to an
accessible location:
Section 3.6.2.1
■
Oracle Management Agent 12c
■
All the required plug-ins
(d)
Provide information about the location of the software you manually
downloaded and staged in Step 2 (c)
Section 9.4
(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 2 (c) and
Step 2 (d).
Section 9.6
(f)
Meet the prerequisites for upgrading the Management Agents as
described in Oracle Enterprise Manager Cloud Control Basic Installation
Guide.
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 (o).
(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.
Make sure your host meets the hardware requirements specific to
12c Release 4 (12.1.0.4) as described in Oracle Enterprise Manager
Cloud Control Basic Installation Guide.
Meet the Management Agent-related prerequisites as described in
Oracle Enterprise Manager Cloud Control Basic Installation Guide.
Ensure that you are upgrading only on the supported platforms
as listed in Section 3.2.
Ensure that the ports used by Enterprise Manager are not set to a
value lower than or equal to 1024. If they are, then the upgrade
will fail. Ports up to 1024 are typically reserved for root users
(super users). Therefore, make sure the ports are greater than
1024.
8-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–2 (Cont.) Upgrading Enterprise Manager Grid Control with 2-System Upgrade
Approach
Step
No.
(b)
Step
Procedure
Stop all running and scheduled deployment procedures in your
existing Enterprise Manager system before upgrading the system.
To verify this, run the following query, and note down the GUID of the
running or scheduled deployment procedures.
SELECT i.instance_guid FROM SYSMAN.MGMT_PAF_STATES s,
SYSMAN.MGMT_PAF_INSTANCES i, SYSMAN.MGMT_PAF_PROCEDURES p
WHERE p.procedure_guid = i.procedure_guid AND s.instance_
guid = i.instance_guid AND s.state_type = 0 AND s.status in
(0,1)
To stop the running or scheduled deployment procedures, run the
following query, and pass the GUID you noted down from the output
of the preceding command:
emcli stop_instance -instance=<instance id from sql query>
Getting Started with Upgrading Enterprise Manager Grid Control(11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release 4or
(12.1.0.4)
11g Release
8-11
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–2 (Cont.) Upgrading Enterprise Manager Grid Control with 2-System Upgrade
Approach
Step
No.
(c)
Step
(Only if you have Application Dependency and Performance (ADP) or JVM
Diagnostics (JVMD) installed)
Perform the following steps before the upgrade:
1.
Take an inventory of the JVMs and WebLogic domains being
monitored by JVMD and/or ADP.
To view a list of deployed JVMD Agents, run the following query:
select * from jam_jvm;
To view a list of the WebLogic domains being monitored by ADP,
access the ADP home page. In the Enterprise Manager console,
from the Targets menu, select Middleware. From the Middleware
Features menu on the Middleware page, select Application
Dependency and Performance.
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 (or by using the Oracle WebLogic
Scripting Tool).
3.
Take an inventory of the deployed ADP and JVMD Engines. Shut
down all of your ADP and JVMD Engines using the WebLogic
Administration Console or the Oracle WebLogic Scripting Tool
(WLST).
To view a list of deployed JVMD Engines, run the following
query:
select * from jam_managers;
To view a list of deployed ADP Engines, run the following query:
select * from ocamm_manager_configuration;
4.
Remove all the ADP and JVMD managed servers from the
GCDomain using the WebLogic Administration Console.
Perform the following steps after the upgrade:
1.
Run the purge scripts for JVMD:
(a) Navigate to the following location:
<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_
_12.1.0.4.0/archives/jvmd/
(b) Extract the file jvmd.zip.
(c) View README.txt.
(d) Run the script jvmd_monitoringupgrade11_12.sql.
(e) Run the script jvmd_traceupgrade11_12.sql if there are
existing Thread Snapshots from Enterprise Manager 11g Grid
Control Release 1 (11.1.0.1).
2.
Run the following upgrade script for a schema upgrade:
<middleware_home>/plugins/oracle.sysman.emas.oms.plugin_
12.1.0.4.0/sql/ias/12.1.0.3/camm_product/camm_schema_
upgrade.sql
8-12 Oracle Enterprise Manager Cloud Control Upgrade Guide
Procedure
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–2 (Cont.) Upgrading Enterprise Manager Grid Control with 2-System Upgrade
Approach
Step
No.
(d)
Step
Procedure
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 5 (b)] 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.
Getting Started with Upgrading Enterprise Manager Grid Control(11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release 4or
(12.1.0.4)
11g Release
8-13
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–2 (Cont.) Upgrading Enterprise Manager Grid Control with 2-System Upgrade
Approach
Step
No.
(f)
Step
Clone (or 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 clone (or back up) the repository on the host where your
existing OMS is running only if you have sufficient space to
accommodate it.
Then, restore it and create a new database instance out of it so that the
repository configured in it can be upgraded.
Note:
■
■
■
■
■
■
■
■
■
Before cloning (or backing up) the database, ensure that you stop
all the running and scheduled deployment procedures in your
existing Enterprise Manager system as described in Step 3 (b).
Oracle recommends using the RMAN utility to clone (or back up)
the database.
Ensure that the character set is not changed in the cloned (or
backed up) Management Repository before it is upgraded.
If you clone (or 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 clone (or 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 clone (or back up) while you are in the daylight saving
window.
Oracle recommends that you unblock all blocked Management
Agents before taking a clone (or backup) of the Management
Repository.
Any Management Agent or target added to the existing
Enterprise Manager system after cloning (or 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 Section 12.9.
Do not make any configuration changes, for example, the metric
thresholds, job definitions, templates, and so on, after you have
cloned (or taken the backup). If you do, then those changes will
not be carried over to the new Enterprise Manager system; only
historical data will be migrated.
8-14 Oracle Enterprise Manager Cloud Control Upgrade Guide
Procedure
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–2 (Cont.) Upgrading Enterprise Manager Grid Control with 2-System Upgrade
Approach
Step
No.
(g)
Step
Procedure
On the cloned (or 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
log_owner='SYSMAN'
from all_mview_logs where
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
Getting Started with Upgrading Enterprise Manager Grid Control(11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release 4or
(12.1.0.4)
11g Release
8-15
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–2 (Cont.) Upgrading Enterprise Manager Grid Control with 2-System Upgrade
Approach
Step
No.
Step
(h)
(CRITICAL MANDATORY STEP)
Apply the following patches on the database. You can access My
Oracle Support and search for these patches. For instructions, see the
ReadMe file associated with the patch. If you do not apply these
patches, you will run into upgrade failures that cannot be corrected.
For Oracle Database 11 Release 1 (11.1.0.7)
■
■
On Unix platforms, apply patch 17082366 (Patch Set Update 17).
Then apply patch 9577583 and patch 8405205.
On Microsoft Windows (32 bit and 64 bit) platforms, apply patch
17363760 (Patch 54).
For Oracle Database 11g Release 2 (11.2.0.1)
■
■
On Unix platforms, apply patch 12419378 (Patch Set Update 6).
On Microsoft Windows (64 bit) platforms, apply patch 13423278
(Patch 16).
For Oracle Database 11g Release 2 (11.2.0.2)
■
■
■
On Unix platforms, apply patch 11061801 and patch 9748749.
On Microsoft Windows (32 bit) platforms, apply patch 11061801
and patch 12429530.
On Microsoft Windows (64-bit) platforms, apply patch 11061801
and patch 12429531.
For Oracle Database 11g Release 2 (11.2.0.3), 10g Release 2 (10.2.0.5)
On Unix as well as Microsoft Windows platforms, apply the patch
11061801.
Note: Oracle also recommends that you apply patch 13496395. For
information on what database releases you can apply the patch, see
the ReadMe that is packaged with the patch.
(i)
Ensure that the character set in the cloned (or 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.
(j)
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>]
8-16 Oracle Enterprise Manager Cloud Control Upgrade Guide
Procedure
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–2 (Cont.) Upgrading Enterprise Manager Grid Control with 2-System Upgrade
Approach
Step
No.
(k)
Step
Procedure
Provide the date and time when the Management Repository was
cloned (or backed up).
Section 9.7
Note: Any Management Agent or target added to the existing
Enterprise Manager system after cloning (or 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 .Section 12.9.
(l)
If you have a Server Load Balancer (SLB) configured, then configure
the settings of your monitors and keep the SLB ready.
Appendix E
Getting Started with Upgrading Enterprise Manager Grid Control(11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release 4or
(12.1.0.4)
11g Release
8-17
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–2 (Cont.) Upgrading Enterprise Manager Grid Control with 2-System Upgrade
Approach
Step
No.
(m)
Step
Procedure
Install Enterprise Manager Cloud Control on the remote host and
upgrade the Management Repository in the database you cloned (or
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.
For
single-OMS
environment,
see:
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 deploy 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 cloned (or 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
For example,
/u01/software/oracle/middleware/oms11g/bin/emctl config
emkey -copy_to_repos_from_file -repos_conndesc
’"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost.mydomain.com)(P
ORT=1521)))(CONNECT_DATA=(SID=emrepos12)))"’ -repos_
user sysman -emkey_file
/u01/software/oracle/middleware/oms11g/sysman/config/emk
ey.ora
Note: Here, the Management Repository details are the details of
the cloned Management Repository, the one you cloned (or
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.
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.
Clone (or back up) the Management Repository as described in
Step 3 (f).
3.
Meet the prerequisites on the cloned (or backed up) Management
Repository as described in Step 3 (g).
4.
Remove the emkey from the old Management Repository as
described in Step 3 (j).
5. Try upgrading the OMS and the Management Repository again.
8-18 Oracle Enterprise Manager
Control
(Note: IfCloud
you had
chosenUpgrade
to deployGuide
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
■
Section 11.1.2
■
Section 11.2.2
■
Section 11.3.2
■
Section 11.4.2
For multi-OMS
environment
(with additional
OMS
instances), see
Section 11.6
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–2 (Cont.) Upgrading Enterprise Manager Grid Control with 2-System Upgrade
Approach
Step
No.
(n)
Step
Procedure
If your database domain name has any characters other than A-Z
(letters), 0-9 (numerals), _ (underscore), # (hash), $ (dollar),. (period),
or @ (at the rate), then the Run Presync step of the switchover
operation might fail, and you will see the following error in the
emoms.trc trace file. For example, a database domain name with a
hyphen (-) can result in this issue.
Appendix L
ORA-20000: Found exception Error Message :ORA-02083:
database name has illegal character '-' Error Number ;-2083
To avoid this issue, as a prerequisite, follow the instructions outlined
in Section L.1. If the database domain name has an illegal character,
such as a hyphen, then correct it.
(o)
Link the earlier release of the Management Repository with the
upgraded Management Repository.
Section 12.2
Step 4 Upgrade Oracle Management Agent
(a)
Deploy and configure the software binaries of Oracle Management
Agent 12c.
Section 10.1
Note: After deploying and configuring the Management Agents, do
not make any configuration changes, for example, the metric
thresholds, job definitions, templates, and so on, in the old
Management Repository. If you do, then those changes will not be
carried over when you switch over to the new Management Agents;
the only way to transfer the changes is to reconfigure the new
Management Agents. For information about reconfiguring them, see
the note in Step (6) of Section 10.1.2.
(b)
Generate a health report and check the readiness of the predeployed
Management Agents.
Section 10.2
(c)
Verify and sign off the health check report.
Section 10.3
(d)
Switch over the old Management Agents to the newly deployed ones
so that they can communicate with the upgraded Enterprise Manager
Cloud Control.
Section 10.4
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.
Step 5 Perform Postupgrade Task
(a)
Verify the host on which you installed Enterprise Manager Cloud
Control.
Section 12.1
(b)
(Only if your old Enterprise Manager had Software Library configured)
Section 12.4
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.
(c)
Secure the central agent [the Management Agent installed by default
with the new OMS you installed as part of Step 3 (m)].
(d)
Check the agent upgrade status.
Section 12.5
(e)
Perform the general post-upgrade tasks.
Section 12.6
(f)
Track the status of deferred data migration jobs.
Section 12.7
(g)
Track the status of accrued data migration jobs.
Section 12.8
Getting Started with Upgrading Enterprise Manager Grid Control(11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release 4or
(12.1.0.4)
11g Release
8-19
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–2 (Cont.) Upgrading Enterprise Manager Grid Control with 2-System Upgrade
Approach
Step
No.
Step
Procedure
(h)
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.
Section 12.9
(i)
View a list of targets that are currently inactive in the upgraded
Enterprise Manager system.
Section 12.10
(j)
Sign off agent migration process.
Section 12.11
(k)
Sign off the upgrade process and exit the upgrade mode.
Section 12.12
(l)
Delete unwanted central agents.
Section 12.13.1
(m)
(Optional) Monitor the targets that were monitored by the deleted
central agent.
Section 12.14
(n)
(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 jamagenth
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.
(o)
Configure Oracle BI Publisher if required.
Oracle
Enterprise
Manager Cloud
Control
Advanced
Installation and
Configuration
Guide
(p)
Delete the old OMS home.
Section 12.15
8-20 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
8.3 Upgrading an Enterprise Manager Grid Control 10g Release 5
(10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with
1-System Upgrade Approach on a Different Host
Table 8–3 describes the steps for upgrading your Enterprise Manager Grid Control 10g
Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4) with 1-system upgrade approach on a different host.
Before you begin upgrading the Enterprise Manager system,
Oracle recommends that review the Oracle Enterprise Manager Cloud
Control Basic Installation Guide to learn about the plug-ins released in
September 2014, October 2014, and January 2015, and to understand
the use cases pertaining to this plug-in release. Identify the use case
that best suits your requirement, and follow the high-level instructions
provided against that use case in the table.
Note:
Table 8–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.
Section 2.2
(b)
Review the important facts you need to know before you begin.
Chapter 3
Step 2
Perform Preupgrade Tasks
(a)
Apply the preupgrade console patch on all your OMS instances to
get access to the Preupgrade Console.
(b)
Provide information about the host where you plan to upgrade your Section 9.2
existing OMS.
(c)
Manually download the following software, and stage them to an
accessible location:
■
Oracle Management Agent 12c
■
All the required plug-ins
Section 2.2.3.
1
Section 3.6.2.
1
(d)
Provide information about the location of the software you
manually downloaded and staged in Step 2 (c).
Section 9.4
(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).
Section 9.6
(f)
Meet the prerequisites for upgrading the Management Agents as
described in Oracle Enterprise Manager Cloud Control Basic Installation
Guide.
Step 3
Upgrade Oracle Management Agent
(a)
Deploy and configure the software binaries of Oracle Management
Agent 12c.
(b)
Generate a health report and check the readiness of the predeployed Section 10.2
Management Agents.
(c)
Verify and sign off the health check report.
Section 10.1
Section 10.3
Getting Started with Upgrading Enterprise Manager Grid Control(11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release 4or
(12.1.0.4)
11g Release
8-21
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–3 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach on a Different Host
Step No. Step
Procedure
(d)
Section 10.4
Switch over the old Management Agents to the newly deployed
ones so that they can communicate with the upgraded 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.
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.
Make sure your host meets the hardware requirements specific
to 12c Release 4 (12.1.0.4) as described in Oracle Enterprise
Manager Cloud Control Basic Installation Guide.
Meet the Management Agent-related prerequisites as described
in Oracle Enterprise Manager Cloud Control Basic Installation
Guide.
Ensure that you are upgrading only on the supported platforms
as listed in Section 3.2.
Ensure that the ports used by Enterprise Manager are not set to
a value lower than or equal to 1024. If they are, then the
upgrade will fail. Ports up to 1024 are typically reserved for root
users (super users). Therefore, make sure the ports are greater
than 1024.
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.
8-22 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–3 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach on a Different Host
Step No. Step
(b)
Procedure
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
log_owner='SYSMAN'
from all_mview_logs where
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
Getting Started with Upgrading Enterprise Manager Grid Control(11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release 4or
(12.1.0.4)
11g Release
8-23
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–3 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach on a Different Host
Step No. Step
(c)
(CRITICAL MANDATORY STEP)
Apply the following patches on the database. You can access My
Oracle Support and search for these patches. For instructions, see
the ReadMe file associated with the patch. If you do not apply these
patches, you will run into upgrade failures that cannot be
corrected.
For Oracle Database 11 Release 1 (11.1.0.7)
■
■
On Unix platforms, apply patch 17082366 (Patch Set Update 17).
Then apply patch 9577583 and patch 8405205.
On Microsoft Windows (32 bit and 64 bit) platforms, apply
patch 17363760 (Patch 54).
For Oracle Database 11g Release 2 (11.2.0.1)
■
■
On Unix platforms, apply patch 12419378 (Patch Set Update 6).
On Microsoft Windows (64 bit) platforms, apply patch 13423278
(Patch 16).
For Oracle Database 11g Release 2 (11.2.0.2)
■
■
■
On Unix platforms, apply patch 11061801 and patch 9748749.
On Microsoft Windows (32 bit) platforms, apply patch 11061801
and patch 12429530.
On Microsoft Windows (64-bit) platforms, apply patch 11061801
and patch 12429531.
For Oracle Database 11g Release 2 (11.2.0.3), 10g Release 2 (10.2.0.5)
On Unix as well as Microsoft Windows platforms, apply the patch
11061801.
Note: Oracle also recommends that you apply patch 13496395. For
information on what database releases you can apply the patch, see
the ReadMe that is packaged with the patch.
(d)
Stop all running and scheduled deployment procedures in your
existing Enterprise Manager system before upgrading the system.
To verify this, run the following query, and note down the GUID of
the running or scheduled deployment procedures.
SELECT i.instance_guid FROM SYSMAN.MGMT_PAF_STATES s,
SYSMAN.MGMT_PAF_INSTANCES i, SYSMAN.MGMT_PAF_PROCEDURES p
WHERE p.procedure_guid = i.procedure_guid AND s.instance_
guid = i.instance_guid AND s.state_type = 0 AND s.status
in (0,1)
To stop the running or scheduled deployment procedures, run the
following query, and pass the GUID you noted down from the
output of the preceding command:
emcli stop_instance -instance=<instance id from sql query>
8-24 Oracle Enterprise Manager Cloud Control Upgrade Guide
Procedure
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–3 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach on a Different Host
Step No. Step
(e)
Procedure
(Only if you have Application Dependency and Performance (ADP) or
JVM Diagnostics (JVMD) installed)
Perform the following steps before the upgrade:
1.
Take an inventory of the JVMs and WebLogic domains being
monitored by JVMD and/or ADP.
To view a list of deployed JVMD Agents, run the following
query:
select * from jam_jvm;
To view a list of the WebLogic domains being monitored by
ADP, access the ADP home page. In the Enterprise Manager
console, from the Targets menu, select Middleware. From the
Middleware Features menu on the Middleware page, select
Application Dependency and Performance.
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 (or by using the Oracle WebLogic
Scripting Tool).
3.
Take an inventory of the deployed ADP and JVMD Engines.
Shut down all of your ADP and JVMD Engines using the
WebLogic Administration Console or the Oracle WebLogic
Scripting Tool (WLST).
To view a list of deployed JVMD Engines, run the following
query:
select * from jam_managers;
To view a list of deployed ADP Engines, run the following
query:
select * from ocamm_manager_configuration;
4.
Remove all the ADP and JVMD managed servers from the
GCDomain using the WebLogic Administration Console.
Perform the following steps after the upgrade:
1.
Run the purge scripts for JVMD:
(a) Navigate to the following location:
<middleware_
home>/plugins/oracle.sysman.emas.oms.plugin__
12.1.0.4.0/archives/jvmd/
(b) Extract the file jvmd.zip.
(c) View README.txt.
(d) Run the script jvmd_monitoringupgrade11_12.sql.
(e) Run the script jvmd_traceupgrade11_12.sql if there are
existing Thread Snapshots from Enterprise Manager 11g Grid
Control Release 1 (11.1.0.1).
2.
Run the following upgrade script for a schema upgrade:
<middleware_
home>/plugins/oracle.sysman.emas.oms.plugin_
12.1.0.4.0/sql/ias/12.1.0.3/camm_product/camm_schema_
upgrade.sql
Getting Started with Upgrading Enterprise Manager Grid Control(11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release 4or
(12.1.0.4)
11g Release
8-25
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–3 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach on a Different Host
Step No. Step
(f)
Procedure
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".
(g)
If you have a Server Load Balancer (SLB) configured, then configure Appendix E
the settings of your monitors and keep the SLB ready.
(h)
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 file
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.
(i)
Install Enterprise Manager Cloud Control on the remote host and
upgrade the Management Repository in the existing database.
Step 5
Perform Postupgrade Task
(a)
Secure the central agent [the Management Agent installed by default
with the new OMS you installed as part of Step 4 (i)].
(b)
Check the agent upgrade status.
Section 12.5
(c)
Perform the general post-upgrade tasks.
Section 12.6
(d)
Track the status of deferred data migration jobs.
Section 12.7
(e)
Sign off agent migration process.
Section 12.11
(f)
Sign off the upgrade process and exit the upgrade mode
Section 12.12
(g)
Deleted unwanted central agents.
Section 12.13.
1
(h)
(Optional) Monitor the targets that were monitored by the deleted
central agent.
Section 12.14
8-26 Oracle Enterprise Manager Cloud Control Upgrade Guide
Section 11.5
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
Table 8–3 (Cont.) Upgrading Enterprise Manager Grid Control with 1-System Upgrade
Approach on a Different Host
Step No. Step
(i)
Procedure
(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.
(j)
Configure Oracle BI Publisher if required.
Oracle
Enterprise
Manager
Cloud Control
Advanced
Installation
and
Configuration
Guide
(k)
(Optional) Delete the old OMS home.
Section 12.15
Getting Started with Upgrading Enterprise Manager Grid Control(11.1.0.1)
10g Release
to 12c
5 (10.2.0.5)
Release 4or
(12.1.0.4)
11g Release
8-27
1
Upgrading an Enterprise Manager Grid Control 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
8-28 Oracle Enterprise Manager Cloud Control Upgrade Guide
9
Meeting the Preupgrade Requirements for
Upgrading Enterprise Manager Grid Control
10g Release 5 (10.2.0.5) or 11g Release 1
(11.1.0.1) to 12c Release 4 (12.1.0.4)
9
This chapter describes the preupgrade requirements you must meet. In particular, this
part covers the following:
■
Applying the Preupgrade Console Patch
■
Identifying a Host and Port for the New Enterprise Manager System
■
Disabling the Auto-Runs of DDMP Jobs
■
■
■
■
Managing and Validating the Location of the Management Agent Software and Its
Associated Plug-ins
Cloning (or Backing Up) Your Existing Database Before Upgrading an Enterprise
Manager System
Analyzing Your Environment Before Upgrading an Enterprise Manager System
Providing Repository Backup Details for Upgrading an Enterprise Manager
System
9.1 Applying the Preupgrade Console Patch
For instructions to apply the Preupgrade Console patch, see Section 2.2.3.1.
9.2 Identifying a Host and Port for the New Enterprise Manager System
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.
Note:
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.
Meeting the Preupgrade Requirements for Upgrading Enterprise
11g Release
Manager
1 (11.1.0.1)
Grid Control
to 12c10g
Release
Release
4 (12.1.0.4)
5 (10.2.0.5)9-1
or
Identifying a Host and Port for the New Enterprise Manager System
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 4 (12.1.0.4.0). Then, enter
the fully qualified name, and then 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.
■
6.
Once you enter the secure and unsecure upload ports here, avoid
changing them once the deployment starts.
In the Configure Postupgrade Tasks section, select one of the following options:
9-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Disabling the Auto-Runs of DDMP Jobs
■
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 Section 12.7.2—select
each component and click Start.
If you disable the DDMP jobs, the ADMP jobs are also
disabled by default.
Note:
■
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 Section 12.8.2.
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.
9.3 Disabling the Auto-Runs of DDMP Jobs
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.
Note:
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 Section 12.7.1.
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.
Meeting the Preupgrade Requirements for Upgrading Enterprise
11g Release
Manager
1 (11.1.0.1)
Grid Control
to 12c10g
Release
Release
4 (12.1.0.4)
5 (10.2.0.5)9-3
or
Managing and Validating the Location of the Management Agent Software and Its Associated Plug-ins
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.
If you want to run the DDMP jobs explicitly after upgrading to
Enterprise Manager Cloud Control, perform Step (3) as described in
Section 12.7.2—select each component and click Start.
Note:
9.4 Managing and Validating the Location of the Management Agent
Software and Its Associated Plug-ins
Perform these steps in the Enterprise Manager Grid Control
console of the earlier release.
Note:
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 Chapter 2.
■
■
■
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.
9-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Managing and Validating the Location of the Management Agent Software and Its Associated Plug-ins
For example, /john/software/oracle/em/.
And then, click Validate to register that location with the Enterprise Manager
system.
Meeting the Preupgrade Requirements for Upgrading Enterprise
11g Release
Manager
1 (11.1.0.1)
Grid Control
to 12c10g
Release
Release
4 (12.1.0.4)
5 (10.2.0.5)9-5
or
Managing and Validating the Location of the Management Agent Software and Its Associated Plug-ins
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/downlo
ads/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 is accessible and 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 4 (12.1.0.4), 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 4 (12.1.0.4). 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.
9-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Analyzing Your Environment Before Upgrading an Enterprise Manager System
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.
9.5 Cloning (or Backing Up) Your Existing Database Before Upgrading an
Enterprise Manager System
If you are performing a 2-system upgrade, then make sure you clone (or back up) your
existing database that houses the Management Repository. For instructions, refer to
Step 3 (f) of Table 8–2 of Section 8.2.
If you want to recover the cloned or backed up Oracle
Database 11g Release 1 (11.1.0.7) or 10g Release 2 (10.2.0.5) from
Microsoft Windows 32-bit to Microsoft Windows 64-bit, then see
Appendix J.
Note:
9.6 Analyzing Your Environment Before Upgrading an Enterprise
Manager System
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 Oracle Management Agents with Valid Inventory
■
Identifying Oracle Management Agents with Invalid Inventory
■
Checking the Upgradability Status of Oracle Management Agents
■
Checking the Upgradability Status of Targets
Meeting the Preupgrade Requirements for Upgrading Enterprise
11g Release
Manager
1 (11.1.0.1)
Grid Control
to 12c10g
Release
Release
4 (12.1.0.4)
5 (10.2.0.5)9-7
or
Analyzing Your Environment Before Upgrading an Enterprise Manager System
■
Identifying Problematic Oracle Management Agents
■
Identifying Oracle Management Agents That Need to Be Reconfigured
■
Identifying Oracle Management Agents That are Not Supported in Enterprise
Manager 12c
■
Identifying Oracle Management Agents That are Installed after Repository Backup
■
Identifying Broken Targets
Perform these steps in the Enterprise Manager Grid Control
console of the earlier release.
Note:
9.6.1 Identifying Oracle 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 Section 9.6.2. 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.
9-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Analyzing Your Environment Before Upgrading an Enterprise Manager System
9.6.2 Identifying Oracle 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:
1.
To resolve this issue, follow these steps:
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.
9.6.3 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.
Meeting the Preupgrade Requirements for Upgrading Enterprise
11g Release
Manager
1 (11.1.0.1)
Grid Control
to 12c10g
Release
Release
4 (12.1.0.4)
5 (10.2.0.5)9-9
or
Analyzing Your Environment Before Upgrading an Enterprise Manager System
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.
9.6.4 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.
9-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Analyzing Your Environment Before Upgrading an Enterprise Manager System
–
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.
9.6.5 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.
–
Central agent - Lists the central agents (Management Agents installed
with the first OMS) that cannot be upgraded for 2-system upgrade.
–
All - Lists all the Management Agents that have one or more issues listed
in the Reason list.
9.6.6 Identifying Oracle 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.
Meeting the Preupgrade Requirements for Upgrading Enterprise
11g Release
Manager
1 (11.1.0.1)
Grid Control
to 12c 10g
Release
Release
4 (12.1.0.4)
5 (10.2.0.5)
9-11
or
Analyzing Your Environment Before Upgrading an Enterprise Manager System
■
■
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.
9.6.7 Identifying Oracle 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.
9-12 Oracle Enterprise Manager Cloud Control Upgrade Guide
Providing Repository Backup Details for Upgrading an Enterprise Manager System
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.
9.6.8 Identifying Oracle Management Agents That are Installed after Repository Backup
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.
9.6.9 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.
9.7 Providing Repository Backup Details for Upgrading an Enterprise
Manager System
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.
Note:
To provide information on when you backed up your Oracle Management Repository,
follow these steps:
1.
In Grid Control, click Deployments.
Meeting the Preupgrade Requirements for Upgrading Enterprise
11g Release
Manager
1 (11.1.0.1)
Grid Control
to 12c 10g
Release
Release
4 (12.1.0.4)
5 (10.2.0.5)
9-13
or
Providing Repository Backup Details for Upgrading an Enterprise Manager System
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 Chapter 2.
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.
Ensure that the backup time you enter is based on the time
zone to which your existing Management Repository belongs.
Note:
If you are noting down the backup time stamp from your clock in a
time zone that is different from the time zone of the region where the
Management Repository resides, then make sure you change the time
stamp to the time zone to which the Management Repository belongs.
For example, to convert the time stamp "1999-12-01 11:00:00" in the
America/Newyork time zone to America/LosAngeles time zone, run the
following query. The result of this query displays the time in
'America/LosAngeles' time zone.
SELECT FROM_TZ(CAST(TO_DATE('1999-12-01 11:00:00',
'YYYY-MM-DD HH:MI:SS') AS TIMESTAMP), 'America/New_York') AT
TIME ZONE 'America/Los_Angeles' "West Coast Time" FROM DUAL;
6.
Click Save.
9-14 Oracle Enterprise Manager Cloud Control Upgrade Guide
10
Upgrading Oracle Management Agents 10g
Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1)
to 12c Release 4 (12.1.0.4)
10
This chapter describes how you can upgrade your Oracle Management Agents. In
particular, this part covers the following:
■
■
■
■
Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4)
Generating a Health Report of Deployed Oracle Management Agents 12c Release 4
(12.1.0.4)
Verifying and Signing Off the Health Report of Deployed Oracle Management
Agents 12c Release 4 (12.1.0.4)
Switching Over to Oracle Management Agent 12c Release 4 (12.1.0.4)
10.1 Deploying and Configuring Oracle Management Agents 12c Release
4 (12.1.0.4)
This section covers the following:
■
■
Before You Begin Deploying and Configuring Oracle Management Agents 12c
Release 4 (12.1.0.4)
Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4)
10.1.1 Before You Begin Deploying and Configuring Oracle Management Agents 12c
Release 4 (12.1.0.4)
Before you deploy and configure Oracle Management Agent, keep these point in
mind:
■
■
■
You cannot deploy and configure Oracle Management Agent 12c for problematic
Management Agents. To identify the problematic Management Agents, see
Section 9.6.5.
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 Section 9.6.3.
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.
Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to
(12.1.0.4)
12c Release
10-1
4
Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4)
■
For 1-system upgrade, use the Preupgrade Console to deploy Oracle Management
Agent 12c for the central agent. Central agent is the Management Agent installed
with the old OMS.
However, for 2-system upgrade and 1-system upgrade on a different host, do NOT
use the Preupgrade Console to deploy Oracle Management Agent 12c as the
central agent on that remote host. Instead, use the Enterprise Manager Cloud
Control Installation Wizard to install the Management Agent along with the OMS.
In the Preupgrade Console, you will be able to select the central agents, but not
proceed with the deployment and configuration job. When you try to submit the
job, the selected central agents are validated and reported as problematic agents,
which cannot be upgraded. If you want to continue monitoring the targets that
were monitored by the central agent, then follow the instructions outlined in
Section 12.14.
■
You need the Management Agent credentials to deploy and configure the software
binaries, and the root credentials to run the root.sh script. In this regard, the
following use cases are supported:
–
Use Case 1: You have the agent as well as the root credentials. In this case, you
can deploy and configure successfully.
–
Use Case 2: You have the agent user name and root user name, but not their
passwords. However, you have SUDO or PowerBroker utility installed in your
environment that can enable you to switch over to another user.
In this case, you can still deploy and configure successfully. You can use SUDO
or PowerBroker, depending on what is installed in your environment, to
switch over to another user account that has the required privileges.
–
Use Case 3: You have the agent credentials, but not the root credentials, and
you do not have SUDO or PowerBroker utility in your environment.
In this case, you can still deploy and configure successfully. In the Deploy and
Configure Agents Wizard, in the Agent Credentials section, enter the agent
credentials as described in Step (10) and as shown in Figure 10–1.
Figure 10–1
Agent Credentials
Then, on the Optional Details page of the wizard, in the Root Credentials
section as described in Step (16) and as shown in Figure 10–2, enter any
dummy user name and password.
10-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4)
Figure 10–2
Root Credentials
Proceed with the deployment and configuration. Note that the deployment
will succeed, but the root.sh script will not run. One of the steps in the
upgrade job will fail stating that the root password was incorrect and that the
root script was not run. Ignore the error and proceed.
After the deployment, contact the adminitrator who has the root credentials,
and request him or her to manually run this root.sh script on each of the
Management Agents.
Note: The root.sh script can be run any time after the deployment,
and not necessarily immediately after the deployment. Even if the
script is not run, the upgrade process will not be affected in any
way—the health check, sign-off, and switchover operations will work
without any issues. However, Oracle strongly recommends that you
run the script before using the Enterprise Manager Cloud Control.
Otherwise, you will not be able to run jobs on the Management
Agents and you will see nmo errors.
■
■
■
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.
For 2-system upgrade, after cloning the old Management Repository (or taking a
backup), do not make any configuration changes to the Management Agent. If you
do, then you must redeploy and reconfigure the Management Agents. Despite
redeploying and reconfiguring the Management Agents if you 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.
10.1.2 Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4)
To deploy Oracle Management Agent 12c, follow these steps:
Perform these steps in the Enterprise Manager Grid Control
console of the earlier release.
Note:
Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to
(12.1.0.4)
12c Release
10-3
4
Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4)
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 Chapter 2.
■
■
■
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.
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.
Note:
6.
In the Select Operation Type section, select Deploy Agent and Plug-In Software
and Configure Agent and Plug-In Software.
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.
Note:
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.
10-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4)
Note:
■
■
■
■
8.
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.
For 2-system upgrade and 1-system upgrade on a different host,
the central agents are listed for selection, but when you select and
try to submit the deployment and configuration job, the selected
central agents are validated and reported as problematic agents.
Therefore, they cannot be deployed and configured, and as a
result, cannot be switched over. If you want to continue
monitoring the targets that were monitored by those central
agents, then follow the instructions outlined in Section 12.14.
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.
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.
Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to
(12.1.0.4)
12c Release
10-5
4
Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4)
Select these additional options if required:
■
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.
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.
Note:
■
■
■
9.
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.
If you want to ignore any deployment and configuration-related prerequisite
checks, then select Ignore Deploy Prerequisites. To ensure successful
deployment, you must manually perform all the agent installation prerequisite
checks, as described in Oracle Enterprise Manager Cloud Control Basic Installation
Guide, before attempting an agent deployment with the Ignore Deploy
Prerequisites option selected.
If you want to clean up all the traces for failed deployments, then select
Cleanup Failed Deployments. Note that this will clean up all the files,
directories, and even log files for failed deployments. So select this option only
if you are sure you want to lose all the data.
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.
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 Section F.
Note:
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.
Ensure that you use the same credentials that you used for the
existing, earlier release of the Management Agent
Note:
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.
10-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4)
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.
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.
Note:
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.
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.
Note:
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.
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.
Note:
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.
Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to
(12.1.0.4)
12c Release
10-7
4
Deploying and Configuring Oracle Management Agents 12c Release 4 (12.1.0.4)
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.
Note:
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.
WARNING: After deploying and configuring the Management
Agents, do not make any configuration changes, for example, the
metric thresholds, job definitions, templates, and so on. If you do,
then those changes will not be carried over when you switch over to
the new Enterprise Manager system; the only way to transfer the
changes is to reconfigure the new Management Agents. To
reconfigure them, see the note in Step (6).
10-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Generating a Health Report of Deployed Oracle Management Agents 12c Release 4 (12.1.0.4)
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.
In case you have issues, review the log files mentioned in
Appendix M.
10.2 Generating a Health Report of Deployed Oracle Management Agents
12c Release 4 (12.1.0.4)
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.
Perform these steps in the Enterprise Manager Grid Control
console of the earlier release.
Note:
Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to
(12.1.0.4)
12c Release
10-9
4
Generating a Health Report of Deployed Oracle Management Agents 12c Release 4 (12.1.0.4)
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:
a.
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.
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.
Note:
b.
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:
■
■
6.
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.
After you add the Management Agents, select each of them from the Select
column.
10-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Generating a Health Report of Deployed Oracle Management Agents 12c Release 4 (12.1.0.4)
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.
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 F.
Note:
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.
Ensure that you use the same credentials that you used for the
existing, earlier release of the Management Agent
Note:
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
At this stage, you can ignore these errors and proceed further.
However, ensure that you provide the database credentials for this
target as described in Section 12.6.
■
In case you have issues, review the log files mentioned in
Appendix M.
Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1)(12.1.0.4)
to 12c Release
10-11
4
Verifying and Signing Off the Health Report of Deployed Oracle Management Agents 12c Release 4 (12.1.0.4)
10.3 Verifying and Signing Off the Health Report of Deployed Oracle
Management Agents 12c Release 4 (12.1.0.4)
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.
Perform these steps in the Enterprise Manager Grid Control
console of the earlier release.
Note:
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.
10-12 Oracle Enterprise Manager Cloud Control Upgrade Guide
Verifying and Signing Off the Health Report of Deployed Oracle Management Agents 12c Release 4 (12.1.0.4)
Note:
For 1-System upgrade approach and and 1-System upgrade approach
on a different host, 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:
<Agent_Instance_Home>/sysman/config/emd.properties
For example,
/u01/app/Oracle/agent/agent_
inst/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
For example,
/u01/app/Oracle/agent/agent_inst/sysman/log/gcagent.log
Here, <Agent_Instance_Home> refers to the 12c agent instance
directory as described in Oracle Enterprise Manager Cloud Control
Advanced Installation and Configuration Guide.
■
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
For example,
/u01/app/Oracle/Middleware/oms/bin/emctl secure unlock
-console
$<OMS_HOME>/bin/emctl secure unlock -upload
For example
/u01/app/Oracle/Middleware/oms/bin/emctl secure unlock
-upload
Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1)(12.1.0.4)
to 12c Release
10-13
4
Verifying and Signing Off the Health Report of Deployed Oracle Management Agents 12c Release 4 (12.1.0.4)
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.
10-14 Oracle Enterprise Manager Cloud Control Upgrade Guide
Switching Over to Oracle Management Agent 12c Release 4 (12.1.0.4)
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
At this stage, you can ignore these errors and proceed further.
10.4 Switching Over to Oracle Management Agent 12c Release 4
(12.1.0.4)
This section covers the following:
■
■
Switching Over to Oracle Management Agent 12c Release 4 (12.1.0.4)
Troubleshooting Issues Related to Switching Over to Oracle Management Agent
12c Release 4 (12.1.0.4)
10.4.1 Switching Over to Oracle Management Agent 12c Release 4 (12.1.0.4)
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:
Perform these steps in the Enterprise Manager Grid Control
console of the earlier release.
Note:
Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1)(12.1.0.4)
to 12c Release
10-15
4
Switching Over to Oracle Management Agent 12c Release 4 (12.1.0.4)
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, then follow the instructions
outlined in Section 12.14.
■
■
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.
Do not stop or cancel a switchover job and resubmit it
immediately for the same set of Management Agents. If you are
forced to do so, then first restart the database to make sure all
lingering process are cleaned before a resubmission of the
swichover operation.
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:
a.
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
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.
Note:
b.
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:
10-16 Oracle Enterprise Manager Cloud Control Upgrade Guide
Switching Over to Oracle Management Agent 12c Release 4 (12.1.0.4)
■
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 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 follow the
instructions outlined in Section 12.14.
Note:
■
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.
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 F.
Note:
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.
Ensure that you use the same credentials that you used for the
existing, earlier release of the Management Agent
Note:
8.
Click Submit.
If you have any issues with the switchover operation, then
troubleshoot them as described in Section 10.4.2. In case of other
issues, review the log files mentioned in Appendix M.
Note:
9.
(Applicable Only for 2-System Upgrade Approach and 1-System Upgrade Approach on a
Different Host) After the switchover, delete the central agents as described in
Section 12.13.
After deleting the central agents, if you want to continue monitoring the targets
that were monitored by them, then follow the instructions outlined in
Section 12.14.
Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1)(12.1.0.4)
to 12c Release
10-17
4
Switching Over to Oracle Management Agent 12c Release 4 (12.1.0.4)
10.4.2 Troubleshooting Issues Related to Switching Over to Oracle Management Agent
12c Release 4 (12.1.0.4)
The following are some common issues and workarounds related to the switchover
operation:
■
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) of
Section 10.1.
Local Authentication Failed...Attempt PAM authentication...PAM failed . . .
■
If the Run Presync step of the switchover operation fails, then you will see the
following error in the emoms.trc trace file. This is possible if your database
domain name has any characters other than A-Z (letters), 0-9 (numerals), _
(underscore), # (hash), $ (dollar),. (period), or @ (at the rate). For example, a
database domain name with a hyphen (-) can result in this issue.
ORA-20000: Found exception Error Message :ORA-02083: database name has illegal
character '-' Error Number ;-2083
To resolve this issue, follow the instructions outlined in Section L.2. If the database
domain name has an illegal character, such as a hypen, then correct it.
■
■
■
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
10-18 Oracle Enterprise Manager Cloud Control Upgrade Guide
Switching Over to Oracle Management Agent 12c Release 4 (12.1.0.4)
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.
In case of other issues, review the log files mentioned in Appendix M.
Upgrading Oracle Management Agents 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1)(12.1.0.4)
to 12c Release
10-19
4
Switching Over to Oracle Management Agent 12c Release 4 (12.1.0.4)
10-20 Oracle Enterprise Manager Cloud Control Upgrade Guide
11
Upgrading Oracle Management Service and
Oracle Management Repository 10g Release 5
(10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c
Release 4 (12.1.0.4)
11
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 the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) in Graphical Mode
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) in Silent Mode
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only
Upgrade Method in Graphical Mode
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only
Upgrade Method in Silent Mode
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade
Approach on a Different Host
Upgrading a Multi-OMS Environment of 10g Release 5 (10.2.0.5) or 11g Release 1
(11.1.0.1) to 12c Release 4 (12.1.0.4)
11.1 Upgrading the OMS and the Management Repository of 10g Release
5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) 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) to 12c Release 4
(12.1.0.4) in graphical mode using one of the upgrade approaches.
In particular, this section describes the following:
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 10g
12c Release
Release 54 (10.2.0.5)
(12.1.0.4) or11-1
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
■
■
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade
Approach in Graphical Mode
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 2-System Upgrade
Approach in Graphical Mode
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, do the following:
Note:
■
If your OMS is configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_conndesc '"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_
DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd
<pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>
■
If your OMS is not configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_host <host> -repos_port <port> -repos_sid
<sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_
pwd <pwd>] -emkey_file <emkey file>
Here, the Management Repository details are details of the existing or
old Management Repository. You will be prompted for the
administration server password and the repository password if you
do not explicitly specify them in the command line.
11.1.1 Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5)
or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade Approach
in Graphical Mode
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.
Note:
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.
11-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
<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 Section 5.1.1.
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.
■
While upgrading on IBM AIX, if you see an error message stating
that your JDK version in the middleware home is not of a
supported version, then make sure you install the supported
version mentioned in the message, and then invoke the installer
passing the -skipJDKValidation argument.
For example,
./runInstaller -skipJDKValidation
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.
Beginning with Enterprise Manager Cloud Control 12c Release
3 (12.1.0.3), My Oracle Support accesses support.oracle.com directly.
This means that you must provide network access to this URL, or
grant proxy access to it from any client that will access My Oracle
Support.
Note:
3.
Click Next.
4.
On the Software Updates screen, apply the latest software updates, including the
latest PSU patches.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 10g
12c Release
Release 54 (10.2.0.5)
(12.1.0.4) or11-3
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
You can download the software updates in offline mode (if you do not have
Internet connectivity) or online mode (if you have Internet connectivity). For
instructions, see Oracle Enterprise Manager Cloud Control Advanced Installation and
Configuration Guide.
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.
7.
Click Next.
If a prerequisite check fails reporting a missing package, then
make sure you install the required package, and click Rerun. The
installation wizard validates the package name as well as the version,
so make sure you install the packages of the minimum versions
mentioned in Oracle Enterprise Manager Cloud Control Basic Installation
Guide. To understand the logic the installation wizard uses to verify
these packages, see Oracle Enterprise Manager Cloud Control Basic
Installation Guide.
Note:
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:
a.
Enter or validate the Middleware home.
11-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
Note:
■
■
■
b.
If you do not have Oracle WebLogic Server 11g Release 1 (10.3.6)
and Java Development Kit 1.6.0.43.0 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.6) and JDK 1.6.0.43.0. 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.6) and Java Development Kit 1.6.0.43.0 yourself, then follow
the guidelines outlined in Chapter 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 Database Connection Details screen, do the following:
■
■
Enter the passwords for the SYS and SYSMAN user accounts of the database
that houses the Management Repository for the selected OMS.
Confirm that you have backed up the Oracle Management Repository
(Management Repository). As a prerequisite, you must back up the
Management Repository before starting the upgrade process. If you have not
already taken a backup, then do so immediately, and then return to the
installer to continue with the upgrade
For information about the various prerequisite checks that are
run on the database at this point, see Oracle Enterprise Manager Cloud
Control Basic Installation Guide.
Note:
13. Click Next.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 10g
12c Release
Release 54 (10.2.0.5)
(12.1.0.4) or11-5
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.
Note:
To identify all running and scheduled deployment procedures, run the
following query, and note down the GUID of the deployment
procedures.
SELECT i.instance_guid FROM SYSMAN.MGMT_PAF_STATES s,
SYSMAN.MGMT_PAF_INSTANCES i, SYSMAN.MGMT_PAF_PROCEDURES p
WHERE p.procedure_guid = i.procedure_guid AND s.instance_
guid = i.instance_guid AND s.state_type = 0 AND s.status in
(0,1)
To stop the running or scheduled deployment procedures, run the
following query, and pass the GUID you noted down from the output
of the preceding command:
emcli stop_instance -instance=<instance id from sql query>
14. On the Select Plug-ins 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.
Oracle Cloud Framework Plug-In is an additional default
plug-in introduced with 12c Release 4 (12.1.0.4), so this plug-in is
deployed automatically.
Note:
11-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
The pre-selected rows might also include the plug-ins you
installed while predeploying Oracle Management Agent 12c using the
Preupgrade Console.
Note:
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.
Access the following Enterprise Manager download page on Oracle
Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downlo
ads/oem-upgrade-console-502238.html
2.
Expand the section that lists the software binaries and plug-ins for your
upgrade path.
3.
From the Download Plug-ins section, manually download the plug-ins
and store them in an accessible location.
4.
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 4 (12.1.0.4). 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 4
(12.1.0.4). 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.
If you are installing on an NFS-mounted drive and creating the
OMS instance base directory (gc_inst) on that NFS-mounted drive,
then after you install, move the lock files from the NFS-mounted
drive to a local file system location. Modify the lock file location in
the httpd.conf file to map to a location on a local file system. For
instructions, refer to Section 5.1.4.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 10g
12c Release
Release 54 (10.2.0.5)
(12.1.0.4) or11-7
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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 installing on an NFS-mounted drive and creating the
OMS instance base directory (gc_inst) on that NFS-mounted drive,
then after you install, move the lock files from the NFS-mounted drive
to a local file system location. Modify the lock file location in the
httpd.conf file to map to a location on a local file system. For
instructions, refer to Section 5.1.4.
Note:
■
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.
Note:
■
■
The password you enter in this screen is not validated by the
installer, so make sure you enter the correct password.
IIf you are installing on an NFS-mounted drive and creating the
OMS instance base directory (gc_inst) on that NFS-mounted drive,
then after you install, move the lock files from the NFS-mounted
drive to a local file system location. Modify the lock file location in
the httpd.conf file to map to a location on a local file system. For
instructions, refer to Section 5.1.4.
If you want to change the Oracle WebLogic Server password
or the Node Manager password, see My Oracle Support note
1450798.1.
Note:
17. Click Next.
18. On the Tablespace Location screen, validate the location where the data file (mgmt_
deepdive.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).
11-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
This screen appears only if you are upgrading from Enterprise
Manager 10g Grid Control Release 5 (10.2.0.5).
Note:
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.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 10g
12c Release
Release 54 (10.2.0.5)
(12.1.0.4) or11-9
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
22. On the Review screen, review the details you have provided for the upgrade.
a.
If you want to change the details, click Back repeatedly until you reach the
screen where you want to make the changes.
b.
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.
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:
Note:
$<OMS_HOME>/bin/emctl stop oms -all
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.
Note:
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.
If the Management Repository upgrade fails with the
following error in the schemamanager logs, then restart the database,
and then try the upgrade again.
Note:
ORA-04020: deadlock detected while trying to lock object
SYSMAN.MGMT_GLOBAL
11-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
11.1.2 Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5)
or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 2-System Upgrade Approach
in Graphical Mode
Caution: For 2-system upgrade approach, Oracle recommends that
you use a clean, fresh host for installing Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4). Therefore, ensure that the host does
not already have any Management Agent installed on it.
If you attempt to install on a host that already has a Management
Agent, then the new Management Agent installed as part of the
2-system upgrade process will not be able to register the same host
again as a target. This is because the existing Management Agent
would have already registered the host as a target in your old
Management Repository, and when you clone this Management
Repository and upgrade it as part of the 2-system upgrade process,
the entry for this host will continue to exist, that is, even after the
cloned Management Repository is upgraded. And as a result, when
the new Management Agent attempts to upload data, it will not be
able to register this host again.
If you are forced to use a host that already has a Management Agent
installed on it, then first deinstall the existing Management Agent, and
clean up information related to it and the targets monitored by it, from
the Management Repository. And then start the 2-system upgrade on
that host. For instructions to deinstall and clean up the existing
Management Agent, see the Oracle Enterprise Manager Cloud Control
Advanced Installation and Configuration Guide.
If you accidentally installed Enterprise Manager Cloud Control 12c
Release 3 (12.1.0.3) on a host that already has a Management Agent on
it, then follow the workaround provided in Section 12.1.
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.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-11
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
Note:
■
■
■
For information about the additional, advanced options you can
pass while invoking the installer, refer to Section 5.1.1.
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
Section 9.2.
(b) On the Deploy and Configure Agents
page, reconfigure the Management Agents
that have already been deployed. For
instructions, see Section 10.1.
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.
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.
Note:
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.
11-12 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
While upgrading on IBM AIX, if you see an error message
stating that your JDK version in the middleware home is not of a
supported version, then make sure you install the supported version
mentioned in the message, and then invoke the installer passing the
-skipJDKValidation argument.
Note:
For example,
./runInstaller -skipJDKValidation
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.
Beginning with Enterprise Manager Cloud Control 12c Release
3 (12.1.0.3), My Oracle Support accesses support.oracle.com directly.
This means that you must provide network access to this URL, or
grant proxy access to it from any client that will access My Oracle
Support.
Note:
3.
Click Next.
4.
On the Software Updates screen, apply the latest software updates, including the
latest PSU patches.
You can download the software updates in offline mode (if you do not have
Internet connectivity) or online mode (if you have Internet connectivity). For
instructions, see Oracle Enterprise Manager Cloud Control Advanced Installation and
Configuration Guide.
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.
a.
Enter the full path to a directory where the inventory files and directories can
be placed.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-13
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
Note:
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.
b.
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.
9.
Click Next.
If a prerequisite check fails reporting a missing package, then
make sure you install the required package, and click Rerun. The
installation wizard validates the package name as well as the version,
so make sure you install the packages of the minimum versions
mentioned in Oracle Enterprise Manager Cloud Control Basic Installation
Guide. To understand the logic the installation wizard uses to verify
these packages, see Oracle Enterprise Manager Cloud Control Basic
Installation Guide.
Note:
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:
a.
Enter or validate the Middleware home where you want to install the OMS
and other core components.
11-14 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.6) and JDK
1.6.0.43.0. 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.
If you do not have Oracle WebLogic Server 11g Release 1 (10.3.6)
and JDK 1.6.0.43.0, 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.6) and Java Development Kit 1.6 v24 yourself, then follow
the guidelines outlined in Chapter 3.
b.
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.
c.
Validate the name of the host where you want to configure the OMS.
The host name appears as a fully qualified name, or as a virtual host name if
your host is configured with virtual machine. If the installation wizard was
invoked with a value for ORACLE_HOSTNAME, then this field is
prepopulated with that name.
Accept the default host name, or enter a fully qualified domain name that is
registered in DNS and is accessible from other network hosts. Oracle
recommends that you use a fully qualified domain name.
The host name must resolve to the local host because the host
name is used for the local Oracle WebLogic Server as well as the
Oracle Management Service. Do not provide a remote host or a load
balancer virtual host in this field. Do not enter an IP address. Do not
use underscores in the name. Short names are allowed, but you will
see a warning, so Oracle recommends that you enter a fully qualified
domain name instead.
Note:
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.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-15
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.
For information about the various prerequisite checks that are
run on the database at this point, see Oracle Enterprise Manager Cloud
Control Basic Installation Guide.
Note:
14. Click Next.
11-16 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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 Select Plug-ins 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.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-17
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
The pre-selected rows might also include the plug-ins you
installed while predeploying Oracle Management Agent 12c using the
Preupgrade Console.
Note:
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.
Access the following Enterprise Manager download page on Oracle
Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downlo
ads/oem-upgrade-console-502238.html
2.
Expand the section that lists the software binaries and plug-ins for your
upgrade path.
3.
From the Download Plug-ins section, manually download the plug-ins
and store them in an accessible location.
4.
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 4 (12.1.0.4). 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 4
(12.1.0.4). 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.
If you are installing on an NFS-mounted drive and creating the
OMS instance base directory (gc_inst) on that NFS-mounted drive,
then after you install, move the lock files from the NFS-mounted
drive to a local file system location. Modify the lock file location in
the httpd.conf file to map to a location on a local file system. For
instructions, refer to Section 5.1.4.
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
11-18 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.
Typically, the connect string is prepopulated. However, if it is
not prepopulated, then enter it in the following format:
Note:
■
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_
deepdive.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).
This screen appears only if you are upgrading from Enterprise
Manager 10g Grid Control Release 5 (10.2.0.5).
Note:
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-19
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.
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:
Note:
■
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.
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.
Note:
24. Click Next.
25. On the Review screen, review the details you provided for the selected installation
type.
11-20 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
■
■
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.
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.
Note:
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
If the Management Repository upgrade fails with the
following error in the schemamanager logs, then restart the database,
and then try the upgrade again.
Note:
ORA-04020: deadlock detected while trying to lock object
SYSMAN.MGMT_GLOBAL
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-21
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
11.2 Upgrading the OMS and the Management Repository of 10g Release
5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) 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 the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade
Approach in Silent Mode
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 2-System Upgrade
Approach in Silent Mode
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, do the following:
Note:
■
If your OMS is configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_conndesc '"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_
DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd
<pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>
■
If your OMS is not configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_host <host> -repos_port <port> -repos_sid
<sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_
pwd <pwd>] -emkey_file <emkey file>
Here, the Management Repository details are details of the existing or
old Management Repository. You will be prompted for the
administration server password and the repository password if you
do not explicitly specify them in the command line.
11-22 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
11.2.1 Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5)
or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 1-System Upgrade Approach
in Silent Mode
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.
Note:
To upgrade your existing OMS and Management Repository with 1-System upgrade
approach in silent mode, refer to Section 5.2.
11.2.2 Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5)
or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with 2-System Upgrade Approach
in Silent Mode
Caution: For 2-system upgrade approach, Oracle recommends that
you use a clean, fresh host for installing Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4). Therefore, ensure that the host does
not already have any Management Agent installed on it.
If you attempt to install on a host that already has a Management
Agent, then the new Management Agent installed as part of the
2-system upgrade process will not be able to register the same host
again as a target. This is because the existing Management Agent
would have already registered the host as a target in your old
Management Repository, and when you clone this Management
Repository and upgrade it as part of the 2-system upgrade process,
the entry for this host will continue to exist, that is, even after the
cloned Management Repository is upgraded. And as a result, when
the new Management Agent attempts to upload data, it will not be
able to register this host again.
If you are forced to use a host that already has a Management Agent
installed on it, then first deinstall the existing Management Agent, and
clean up information related to it and the targets monitored by it, from
the Management Repository. And then start the 2-system upgrade on
that host. For instructions to deinstall and clean up the existing
Management Agent, see the Oracle Enterprise Manager Cloud Control
Advanced Installation and Configuration Guide.
If you accidentally installed Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4) on a host that already has a Management Agent on
it, then follow the workaround provided in Section 12.1.
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
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-23
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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:
./runInstaller -silent -responseFile <absolute_path>/upgrade.rsp
-staticPortsIniFile <absolute_path_to_staticports.ini_file> [-invPtrLoc
<absolute_path_to_inventory_directory>] [ALLOW_ONLY_SECURE_ACCESS_TO_
CONSOLE=FALSE LOCK_ORACLE_MANAGEMENT_SERVICE=FALSE]
Note:
■
■
■
For information about the additional, advanced options you can pass
while invoking the installer, refer to Section 5.2.1.
To invoke the installation wizard on UNIX platforms, run runInstaller.
To invoke on Microsoft Windows platforms, run setup.exe.
-invPtrLoc is not supported on Microsoft Windows.
While upgrading on IBM AIX, if you see an error message
stating that your JDK version in the middleware home is not of a
supported version, then make sure you install the supported version
mentioned in the message, and then invoke the installer passing the
-skipJDKValidation argument.
Note:
For example,
./runInstaller -skipJDKValidation
11-24 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.
If a prerequisite check fails reporting a missing package, then
make sure you install the required package, and retry the installation.
The installer validates the package name as well as the version, so
make sure you install the packages of the minimum versions
mentioned in Oracle Enterprise Manager Cloud Control Basic Installation
Guide. To understand the logic the installer uses to verify these
packages, see Oracle Enterprise Manager Cloud Control Basic Installation
Guide.
Note:
If the Management Repository upgrade fails with the
following error in the schemamanager logs, then restart the database,
and then try the upgrade again.
Note:
ORA-04020: deadlock detected while trying to lock object
SYSMAN.MGMT_GLOBAL
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-25
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
11.3 Upgrading the OMS and the Management Repository of 10g Release
5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using
the Software-Only Upgrade Method 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 the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only
Upgrade Method for 1-System Upgrade Approach in Graphical Mode
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only
Upgrade Method for 2-System Upgrade Approach in Graphical Mode
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, do the following:
Note:
■
If your OMS is configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_conndesc '"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_
DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd
<pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>
■
If your OMS is not configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_host <host> -repos_port <port> -repos_sid
<sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_
pwd <pwd>] -emkey_file <emkey file>
Here, the Management Repository details are details of the existing or
old Management Repository. You will be prompted for the
administration server password and the repository password if you
do not explicitly specify them in the command line.
11.3.1 Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5)
or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only Upgrade
Method for 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:
11-26 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
■
■
■
Installing the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software
Binaries for 1-System Upgrade Approach in Graphical Mode
Running the allroot.sh Script After Installing the Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4) Software Binaries for 1-System Upgrade Approach
in Graphical Mode
Configuring and Upgrading the Enterprise Manager Cloud Control 12c Release 4
(12.1.0.4) Software Binaries for 1-System Upgrade Approach in Graphical Mode
11.3.1.1 Installing the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
Software Binaries for 1-System Upgrade Approach in Graphical Mode
To install the software binaries of Enterprise Manager Cloud Control, refer to
Section 5.3.1.
11.3.1.2 Running the allroot.sh Script After Installing the Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4) Software Binaries for 1-System Upgrade Approach
in Graphical Mode
To run the allroot.sh script, refer to Section 5.3.2.
11.3.1.3 Configuring and Upgrading the Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4) Software Binaries for 1-System Upgrade Approach in Graphical
Mode
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:
■
■
2.
While installing the software binaries as described in
Section 11.3.1.1, 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 Section 5.3.3.1.
On the Install Types screen, do the following:
a.
Select Upgrade an Existing Enterprise Manager System, and then, select One
System Upgrade.
b.
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.
Confirm that you have backed up the Oracle Management Repository
(Management Repository). As a prerequisite, you must back up the
Management Repository before starting the upgrade process. If you have not
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-27
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
already taken a backup, then do so immediately, and then return to the
installer to continue with the upgrade.
For information about the various prerequisite checks that are
run on the database at this point, see Oracle Enterprise Manager Cloud
Control Basic Installation Guide.
Note:
5.
Click Next.
If you see an error about missing plug-ins, then do the
following:
Note:
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.
Access the following Enterprise Manager download page on Oracle
Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downlo
ads/oem-upgrade-console-502238.html
3.
Expand the section that lists the software binaries and plug-ins for your
upgrade path.
4.
From the Download Plug-ins section, manually download the plug-ins
and store them in an accessible location.
5.
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 4 (12.1.0.4). 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 4
(12.1.0.4). After you upgrade, you can deploy the higher version
directly from the Plug-In Manager.
6.
On the Select Plug-ins 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.
11-28 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
If you want to install any additional plug-ins that are not listed
on this screen, then follow these steps:
Note:
1.
Access the following Enterprise Manager download page on Oracle
Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downlo
ads/oem-upgrade-console-502238.html
2.
Expand the section that lists the software binaries and plug-ins for your
upgrade path.
3.
From the Download Plug-ins section, manually download the plug-ins
and store them in an accessible location.
4.
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.
IIf you are installing on an NFS-mounted drive and creating the
OMS instance base directory (gc_inst) on that NFS-mounted drive,
then after you install, move the lock files from the NFS-mounted
drive to a local file system location. Modify the lock file location in
the httpd.conf file to map to a location on a local file system. For
instructions, refer to Section 5.1.4.
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.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-29
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
If you are installing on an NFS-mounted drive and creating the
OMS instance base directory (gc_inst) on that NFS-mounted drive,
then after you install, move the lock files from the NFS-mounted drive
to a local file system location. Modify the lock file location in the
httpd.conf file to map to a location on a local file system. For
instructions, refer to Section 5.1.4.
Note:
■
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.
Note:
■
■
The password you enter in this screen is not validated by the
installer, so make sure you enter the correct password.
If you are installing on an NFS-mounted drive and creating the
OMS instance base directory (gc_inst) on that NFS-mounted drive,
then after you install, move the lock files from the NFS-mounted
drive to a local file system location. Modify the lock file location in
the httpd.conf file to map to a location on a local file system. For
instructions, refer to Section 5.1.4.
If you want to change the Oracle WebLogic Server password
or the Node Manager password, see My Oracle Support note
1450798.1.
Note:
9.
Click Next.
10. On the Tablespace Location screen, validate the location where the data file (mgmt_
deepdive.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).
This screen appears only if you are upgrading from Enterprise
Manager 10g Grid Control Release 5 (10.2.0.5).
Note:
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.
11-30 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.
Note:
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.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-31
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.
Note:
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.
If the Management Repository upgrade fails with the
following error in the schemamanager logs, then restart the database,
and then try the upgrade again.
Note:
ORA-04020: deadlock detected while trying to lock object
SYSMAN.MGMT_GLOBAL
11.3.2 Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5)
or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only Upgrade
Method for 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 the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software
Binaries for 2-System Upgrade Approach in Graphical Mode
Running the allroot.sh Script After Installing the Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4) Software Binaries for 2-System Upgrade Approach
in Graphical Mode
Configuring and Upgrading the Enterprise Manager Cloud Control 12c Release 4
(12.1.0.4) Software Binaries for 2-System Upgrade Approach in Graphical Mode
11-32 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
Caution: For 2-system upgrade approach, Oracle recommends that
you use a clean, fresh host for installing Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4). Therefore, ensure that the host does
not already have any Management Agent installed on it.
If you attempt to install on a host that already has a Management
Agent, then the new Management Agent installed as part of the
2-system upgrade process will not be able to register the same host
again as a target. This is because the existing Management Agent
would have already registered the host as a target in your old
Management Repository, and when you clone this Management
Repository and upgrade it as part of the 2-system upgrade process,
the entry for this host will continue to exist, that is, even after the
cloned Management Repository is upgraded. And as a result, when
the new Management Agent attempts to upload data, it will not be
able to register this host again.
If you are forced to use a host that already has a Management Agent
installed on it, then first deinstall the existing Management Agent, and
clean up information related to it and the targets monitored by it, from
the Management Repository. And then start the 2-system upgrade on
that host. For instructions to deinstall and clean up the existing
Management Agent, see the Oracle Enterprise Manager Cloud Control
Advanced Installation and Configuration Guide.
If you accidentally installed Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4) on a host that already has a Management Agent on
it, then follow the workaround provided in Section 12.1.
11.3.2.1 Installing the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
Software Binaries for 2-System Upgrade Approach in Graphical Mode
To install the software binaries, follow the steps outlined in Section 5.3.1.
11.3.2.2 Running the allroot.sh Script After Installing the Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4) Software Binaries for 2-System Upgrade Approach
in Graphical Mode
To run the allroot.sh script, Section 5.3.2.
11.3.2.3 Configuring and Upgrading the Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4) Software Binaries for 2-System Upgrade Approach in Graphical
Mode
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>]
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-33
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
Note:
■
■
While installing the software binaries as described in
Section 11.3.2.1, 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 Section 5.3.3.1.
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.
For information about the various prerequisite checks that are
run on the database at this point, see Oracle Enterprise Manager Cloud
Control Basic Installation Guide.
Note:
5.
Click Next.
11-34 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-35
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
If you see an error about missing plug-ins, then do the
following:
Note:
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.
Access the following Enterprise Manager download page on Oracle
Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downlo
ads/oem-upgrade-console-502238.html
3.
Expand the section that lists the software binaries and plug-ins for your
upgrade path.
4.
From the Download Plug-ins section, manually download the plug-ins
and store them in an accessible location.
5.
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 4 (12.1.0.4). 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 4
(12.1.0.4). After you upgrade, you can deploy the higher version
directly from the Plug-In Manager.
6.
On the Select Plug-ins 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.
If you want to install any additional plug-ins that are not listed
on this screen, then follow these steps:
Note:
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/downlo
ads/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.
11-36 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.
If you are installing on an NFS-mounted drive and creating the
OMS instance base directory (gc_inst) on that NFS-mounted drive,
then after you install, move the lock files from the NFS-mounted
drive to a local file system location. Modify the lock file location in
the httpd.conf file to map to a location on a local file system. For
instructions, refer to Section 5.1.4.
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.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-37
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
Typically, the connect string is prepopulated. However, if it is
not prepopulated, then enter it in the following format:
Note:
■
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_
deepdive.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).
This screen appears only if you are upgrading from Enterprise
Manager 10g Grid Control Release 5 (10.2.0.5).
Note:
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.
11-38 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.
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.
Note:
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.
If the Management Repository upgrade fails with the
following error in the schemamanager logs, then restart the database,
and then try the upgrade again.
Note:
ORA-04020: deadlock detected while trying to lock object
SYSMAN.MGMT_GLOBAL
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-39
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
11.4 Upgrading the OMS and the Management Repository of 10g Release
5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using
the Software-Only Upgrade Method 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 the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only
Upgrade Method for 1-System Upgrade Approach in Silent Mode
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only
Upgrade Method for 2-System Upgrade Approach in Silent Mode
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, do the following:
Note:
■
If your OMS is configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_conndesc '"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_
DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd
<pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>
■
If your OMS is not configured with a service name, then run the
following command:
<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_
file -repos_host <host> -repos_port <port> -repos_sid
<sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_
pwd <pwd>] -emkey_file <emkey file>
Here, the Management Repository details are details of the existing or
old Management Repository. You will be prompted for the
administration server password and the repository password if you
do not explicitly specify them in the command line.
11.4.1 Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5)
or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only Upgrade
Method for 1-System Upgrade Approach in Silent Mode
To upgrade in software-only mode with 1-System upgrade approach, refer to
Section 5.4.
11-40 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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 4 (12.1.0.4). 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 4 (12.1.0.4). After you upgrade, you
can deploy the higher version directly from the Plug-In Manager.
Note:
11.4.2 Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5)
or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) Using the Software-Only Upgrade
Method for 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 the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4) Software
Binaries for 2-System Upgrade Approach in Silent Mode
Running the allroot.sh Script After Installing the Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4) Software Binaries for 2-System Upgrade Approach
in Silent Mode
Configuring and Upgrading the Enterprise Manager Cloud Control 12c Release 4
(12.1.0.4) Software Binaries for 2-System Upgrade Approach in Silent Mode
Caution: For 2-system upgrade approach, Oracle recommends that
you use a clean, fresh host for installing Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4). Therefore, ensure that the host does
not already have any Management Agent installed on it.
If you attempt to install on a host that already has a Management
Agent, then the new Management Agent installed as part of the
2-system upgrade process will not be able to register the same host
again as a target. This is because the existing Management Agent
would have already registered the host as a target in your old
Management Repository, and when you clone this Management
Repository and upgrade it as part of the 2-system upgrade process,
the entry for this host will continue to exist, that is, even after the
cloned Management Repository is upgraded. And as a result, when
the new Management Agent attempts to upload data, it will not be
able to register this host again.
If you are forced to use a host that already has a Management Agent
installed on it, then first deinstall the existing Management Agent, and
clean up information related to it and the targets monitored by it, from
the Management Repository. And then start the 2-system upgrade on
that host. For instructions to deinstall and clean up the existing
Management Agent, see the Oracle Enterprise Manager Cloud Control
Advanced Installation and Configuration Guide.
If you accidentally installed Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4) on a host that already has a Management Agent on
it, then follow the workaround provided in Section 12.1.
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-41
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
11.4.2.1 Installing the Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
Software Binaries for 2-System Upgrade Approach in Silent Mode
To install the software binaries of Enterprise Manager Cloud Control, follow the steps
outlined in Section 5.4.1.
11.4.2.2 Running the allroot.sh Script After Installing the Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4) Software Binaries for 2-System Upgrade Approach
in Silent Mode
To run the allroot.sh script, Section 5.4.2.
11.4.2.3 Configuring and Upgrading the Enterprise Manager Cloud Control 12c
Release 4 (12.1.0.4) Software Binaries for 2-System Upgrade Approach in Silent
Mode
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
Section 11.4.2.1, 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 Section 5.3.3.1.
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.
11-42 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
If a prerequisite check fails reporting a missing package, then
make sure you install the required package, and retry the installation.
The installer validates the package name as well as the version, so
make sure you install the packages of the minimum versions
mentioned in Oracle Enterprise Manager Cloud Control Basic Installation
Guide. To understand the logic the installer uses to verify these
packages, see Oracle Enterprise Manager Cloud Control Basic Installation
Guide.
Note:
If you see an error about missing plug-ins, then do the
following:
Note:
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.
Access the following Enterprise Manager download page on Oracle
Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downlo
ads/oem-upgrade-console-502238.html
3.
Expand the section that lists the software binaries and plug-ins for your
upgrade path.
4.
From the Download Plug-ins section, manually download the plug-ins
and store them in an accessible location.
5.
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.
If the Management Repository upgrade fails with the
following error in the schemamanager logs, then restart the database,
and then try the upgrade again.
Note:
ORA-04020: deadlock detected while trying to lock object
SYSMAN.MGMT_GLOBAL
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-43
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
11.5 Upgrading the OMS and the Management Repository of 10g Release
5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4) with
1-System Upgrade Approach on a Different Host
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
Section 11.3.1.1.
For instructions to install them in silent mode, see Section 11.4.1.
Note that Step (15) in Section 11.3.1.1 (graphical mode) and Step (4) in
Section 11.4.1 (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.
This remote host must be different from the host where your
existing, earlier release of Enterprise Manager is running.
Note:
2.
Deploy the plug-ins:
$<OMS_HOME>/sysman/install/PluginInstall.sh
On the Select Plug-ins 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.
11-44 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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.
Access the following Enterprise Manager
download page on Oracle Technology
Network (OTN):
http://www.oracle.com/technetwork/oem/
grid-control/downloads/oem-upgrade-con
sole-502238.html
2.
Expand the section that lists the software
binaries and plug-ins for your upgrade path.
3.
From the Download Plug-ins section,
manually download the plug-ins and store
them in an accessible location.
4.
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 Select Plug-ins 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>
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-45
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
Note:
On Microsoft Windows, run the following commands:
set ORACLE_HOME=<absolute_path_to_oms_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) is ready for upgrade:
a.
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
b.
Run the prerequisite checks:
$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType
upgrade -prerequisiteXMLRootDir $ORACLE_
HOME/install/requisites/list -prereqResultLoc <prereq_result_
location> -connectString "(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=listenerport)))(CO
NNECT_DATA=(SID=<sid>)))" -dbUser SYS -dbPassword <db_password>
-dbRole sysdba -configurationType <MINI/SMALL/MEDIUM/LARGE>
-runPrerequisites -reposUser SYSMAN
Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat
-executionType upgrade -prerequisiteXMLRootDir %ORACLE_
HOME%\install\requisites\list -prereqResultLoc <prereq_
result_location> -connectString "(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=listenerpor
t)))(CONNECT_DATA=(SID=<sid>)))" -dbUser SYS -dbPassword
<db_password> -dbRole sysdba -configurationType
<MINI/SMALL/MEDIUM/LARGE> -runPrerequisites -reposUser
SYSMAN
For example,
$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType
upgrade -prerequisiteXMLRootDir $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
-configurationType SMALL -runPrerequisites -reposUser SYSMAN
11-46 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
Note:
Example for Microsoft Windows:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat
-executionType upgrade -prerequisiteXMLRootDir %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 -configurationType SMALL -runPrerequisites
-reposUser SYSMAN
Note:
■
■
6.
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.
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
-prerequisiteXMLRootDir $ORACLE_HOME/install/requisites/list
-prereqResultLoc <prereq_result_location> -connectString
"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=listenerport)))(CONNEC
T_DATA=(SID=<sid>)))" -dbUser SYS -dbPassword <db_password> -dbRole
sysdba -useHistory -runCorrectiveActions -reposUser SYSMAN
Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat
-executionType upgrade -prerequisiteXMLRootDir %ORACLE_
HOME%\install\requisites\list -prereqResultLoc <prereq_
result_location> -connectString "(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=listenerpor
t)))(CONNECT_DATA=(SID=<sid>)))" -dbUser SYS -dbPassword
<db_password> -dbRole sysdba -useHistory
-runCorrectiveActions -reposUser SYSMAN
For example,
$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade
-prerequisiteXMLRootDir $ORACLE_HOME/install/requisites/list
-prereqResultLoc $ORACLE_HOME/prerequisiteResults -connectString
"(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-47
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
DATA=(SID=dbview)))" -dbUser SYS -dbPassword dbpass -dbRole sysdba
-useHistory -runCorrectiveActions -reposUser SYSMAN
Note:
Example for Microsoft Windows:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat
-executionType upgrade -prerequisiteXMLRootDir %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 -runCorrectiveActions -reposUser
SYSMAN
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.
Note:
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
7.
2.
Review the passed and failed tests and their corresponding corrective
actions.
3.
For the failed tests, manually take corrective actions.
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"
The plug-ins to be mentioned for the <pluginslist> argument
can be found in the following file:
Note:
$ORACLE_HOME/sysman/install/plugins_installed.txt
11-48 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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,o
racle.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.sy
sman.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 /net/example.com/software/oracle/oms10g -installMode
gcUpgrade -client gcinstaller -customParams
"connectString=(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT_
DATA=(SID=dbview))),username=sysman"
Ensure that the old OMS home is accessible from the remote
host where you are running this command.
Note:
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,ora
cle.sysman.emas=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,orac
le.em.sat=12.1.0.1.0,oracle.em.sidb=12.1.0.1.0,oracle.em.smd
n=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 <REPOSITORY_HOST>
<PORT> <REPOSITORY_SID> -doPurging yes -action preupgrade -dbUser SYS
-reposName sysman -mwHome $MW_HOME -mwOraHome $ORACLE_HOME -oracleHome
$ORACLE_HOME
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-49
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\sysman\admin\emdrep\bin\RepManager
<REPOSITORY_HOST> <PORT> <REPOSITORY_SID> -doPurging yes
-action preupgrade -dbUser SYS -reposName sysman -mwHome
%MW_HOME% -mwOraHome %ORACLE_HOME% -oracleHome %ORACLE_HOME%
For example,
$ORACLE_HOME/sysman/admin/emdrep/bin/RepManager example.com 1521 dbview
-doPurging yes -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 example.com
1521 dbview -doPurging yes -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
11-50 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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
-prerequisiteXMLRootDir $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 -reposUser SYSMAN
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-51
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
Note:
On Microsoft Windows, run the following command:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat
-executionType upgrade -prerequisiteXMLRootDir %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 -reposUser SYSMAN
For example,
$ORACLE_HOME/install/requisites/bin/emprereqkit -executionType upgrade
-prerequisiteXMLRootDir $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 -reposUser SYSMAN
Note:
Example for Microsoft Windows:
%ORACLE_HOME%\install\requisites\bin\emprereqkit.bat
-executionType upgrade -prerequisiteXMLRootDir %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
-reposUser SYSMAN
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
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.0.43.0
(64-bit version for 64-bit platforms and 32-bit version for 32-bit
platforms).
Note:
12. Create MDS schema in the Management Repository:
11-52 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
$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_
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-53
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
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>]
The argument -RESPONSE_FILE <absolute_location_to_
response_file> is optional.
Note:
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 11–1
Response File Format for UNIX
-AS_HOST=example.com
-AS_USERNAME=weblogic
-AS_HTTPS_PORT=7101
-MSPORT=7201
-MS_HTTPS_PORT=7301
11-54 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
-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 11–2
Response 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,
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-55
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
$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,o
racle.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.sy
sman.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 /net/example.com/software/oracle/middleware/oms11g
-installMode gcupgrade
Ensure that the old OMS home is accessible from the remote
host where you are running this command.
Note:
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,ora
cle.sysman.emas=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,orac
le.em.sat=12.1.0.1.0,oracle.em.sidb=12.1.0.1.0,oracle.em.smd
n=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:
a.
Log in to the upgraded Management Repository as SYSMAN user either from
the old OMS or from the new OMS.
From the Old OMS
To log in from the old OMS, follow these steps:
- 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
11-56 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
To log in from the new OMS, follow these steps:
- 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)))"
b.
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
home,
LOOP
FOR rec in ( select plugin_id, plugin_version, target_guid, plugin_
plugin_type from PRE_UPGC_DEP_PLUGINS )
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;
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-57
11g
Upgrading the OMS and the Management Repository of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4
/
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/agent/core/12.1.0.4.0/sysman/install/agentDeploy.sh
AGENT_BASE_DIR=/u01/app/Oracle/agent OMS_HOST=example.com EM_UPLOAD_
PORT=1159 AGENT_REGISTRATION_PASSWORD=2bornot2b -configOnly
Ensure that you enter the secure (HTTPS) upload port number
for the argument EM_UPLOAD_PORT.
Note:
Note:
Example for Microsoft Windows:
C:\Oracle\agent\core\12.1.0.4.0\sysman\install\agentDeploy.b
at AGENT_BASE_DIR=C:\Oracle\agent OMS_HOST=example.com EM_
UPLOAD_PORT=1159 AGENT_REGISTRATION_PASSWORD=2bornot2b
-configOnly
11-58 Oracle Enterprise Manager Cloud Control Upgrade Guide
Upgrading a Multi-OMS Environment of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
If the Management Repository upgrade fails with the
following error in the schemamanager logs, then restart the database,
and then try the upgrade again.
Note:
ORA-04020: deadlock detected while trying to lock object
SYSMAN.MGMT_GLOBAL
11.6 Upgrading a Multi-OMS Environment of 10g Release 5 (10.2.0.5) or
11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
To upgrade an Enterprise Manager system of 10g Release 5 (10.2.0.5) or 11g Release 1
(11.1.0.1) that has multiple OMS instances, follow these steps:
1.
Upgrade the first OMS. You can use any of the upgrade approaches described in
this guide — Section 11.1, Section 11.2, Section 11.3, or Section 11.4.
Always start the upgrade process with the first OMS, where
the Admin Server is running, and not with any of the additional OMS
instances.
Note:
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
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,
Upgrading Oracle Management Service and Oracle Management
Release 1 (11.1.0.1)
Repository
to 12c
10gRelease
Release45(12.1.0.4)
(10.2.0.5) or
11-59
11g
Upgrading a Multi-OMS Environment of 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4)
and then, select One System Upgrade. Then, select the OMS home you want
to upgrade.
11-60 Oracle Enterprise Manager Cloud Control Upgrade Guide
12
Performing Postupgrade Tasks After
Upgrading to Enterprise Manager Cloud
Control 12c Release 4 (12.1.0.4)
12
This chapter describes the postinstallation tasks you must perform. In particular, this
part covers the following:
■
Verifying the Host on Which Enterprise Manager Is Installed
■
Creating a Link to the Upgraded Management Repository
■
Discovering the Database Where the Management Repository Was Upgraded
■
Reconfiguring the Software Library
■
Checking the 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 the Accrued Data Migration Process
■
Signing Off the Migration Processes and Exiting the Upgrade Mode
■
Deleting Old Central Agents and the Associated Targets
■
(Optional) Monitoring Targets That Were Monitored by the Deleted Central Agent
■
(Optional) Deleting the Old OMS Home
■
Migrating the SYSMAN Schema to a Database Configured with CDB and PDB
■
Resolving Custom Roles Issue When Custom Roles Do Not Appear in the Console
12.1 Verifying the Host on Which Enterprise Manager Is Installed
Follow these instructions only if you are upgrading using the
2-System upgrade approach.
Note:
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
12-1
Verifying the Host on Which Enterprise Manager Is Installed
For 2-system upgrade approach, Oracle recommends that you use a clean, fresh host
for installing Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4). Verify that
you have installed on a fresh host.
To do so, on the Management Services and Repository page, click the information icon
adjacent to the page title. In the Target Information region that appears, as shown in
Figure 12–1, validate the host name and make sure it reflects the host on which you
have installed the new 12c OMS. Also verify that the same host name appears on the
top-right corner of the page, right below the Search Target Name text box, as shown in
Figure 12–1.
Figure 12–1
Verifying the Host
If the host names match and if they reflect the host on which you have installed the
new 12c OMS, then it is a confirmation that you have installed on a fresh host.
If one of them reflects a different host name, then it is a confirmation that you have
installed on a host that already has a Management Agent. Under such circumstances,
follow these steps:
1.
Deinstall the Management Agent that already exists. Clean up or remove
information related to this Management Agent and the targets monitored by it,
from the Management Repository. For instructions, see Oracle Enterprise Manager
Cloud Control Advanced Installation and Configuration Guide.
2.
Add the host as a target to the new Management Agent, which was installed with
the new 12c OMS as part of the 2-system upgrade.
To do so, run the following command from the new Management Agent home:
$<AGENT_HOME>/bin/emctl config agent addInternaltargets
3.
Verify that the host is added as a target in Enterprise Manager Cloud Control
Console. To do so, on the Management Agent home page, in the Monitoring
section, in the Monitored Targets tab, verify that the host is listed.
4.
Relocate the Management Services and Repository target, which is monitored by
the Management Agent installed with the old OMS host, to the new Management
Agent, which was installed with the new 12c OMS as part of the 2-system
upgrade.
To do so, log in as SYSMAN and run the following command from any host where
EM CLI is installed:
emcli relocate_targets -src_agent="<agent_installed_with_old_OMS>"
-dest_agent="<new_agent_installed_with_new_12c_OMS>" -target_
name="Management Services and Repository" -target_type=oracle_emrep
-copy_from_src
12-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Creating a Link to the Upgraded Management Repository
5.
Set the connect descriptor and credentials of the new, upgraded Management
Repository as the monitoring configuration settings of the Management Services
and Repository target.
To do so, on the Management Services and Repository Home page, from the OMS
and Repository menu, select Target Setup, then select Monitoring Configuration.
On the Monitoring Configuration page, enter the connect descriptor and the
credentials of the new, upgraded Management Repository. Click OK.
12.2 Creating a Link to the Upgraded Management Repository
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.
Note:
As a prerequisite for upgrading your Enterprise Manager system using the 2-System
upgrade approach, you are required to clone (or 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 Chapter 2.
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.
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
12-3
Discovering the Database Where the Management Repository Was Upgraded
5.
On the Create Upgraded Oracle Management Repository Link page, in the
Repository Link Details section, do the following:
a.
Enter the connect string to connect to the upgraded Management Repository
that will be used by Enterprise Manager Cloud Control.
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.
Note:
For example, the value in the emgc.properties file might be:
(DESCRIPTION\=(ADDRESS_
LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=example.com)(PORT\=152
1)))(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.
6.
b.
Enter the SYSMAN password of the upgraded Management Repository that
will be used by Enterprise Manager Cloud Control.
c.
Enter the SYS password of the old Management Repository.
Click Create DB Link.
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.
Note:
12.3 Discovering the Database Where the Management Repository Was
Upgraded
Follow these instructions only if you are upgrading using the
2-System upgrade approach.
Note:
After completing the 2-System upgrade, manually discover the database where you
upgraded the Management Repository so that the database can be monitored in the
Enterprise Manager Cloud Control Console.
For instructions, see Oracle Enterprise Manager Cloud Control Administrator’s Guide.
12-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Reconfiguring the Software Library
12.4 Reconfiguring the Software Library
Follow these instructions only if you are upgrading using the
2-System upgrade approach.
Note:
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 sometimes 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 Section 8.1 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.
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
12-5
Reconfiguring the Software Library
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 12–2
Two-System Reconfiguration
12-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Checking the Agent Upgrade Status
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.
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.
Note:
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.
a.
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.
b.
After a successful validation, click Confirm to reconfigure the Software
Library. A job starting with SwlibUpgradeLocations is submitted, which must
be tracked to successful completion, following which you should initiate any
patching or provisioning tasks.
12.5 Checking the Agent Upgrade Status
Perform these steps in the Enterprise Manager Grid Control
console of the earlier release.
Note:
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:
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
12-7
Checking the Agent Upgrade Status
■
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.
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.
Note:
–
To deploy the agent software, select one or more Management Agent from
the table, and click Deploy and Configure Agent.
You cannot deploy and configure Oracle Management Agent
12c for problematic Management Agents. To identify problematic
Management Agents, see Section 9.6.5.
Note:
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 Section 9.6.3.
–
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.
12-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Performing General Postupgrade Tasks
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.
12.6 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 After Upgrading to Enterprise Manager
Cloud Control 12c Release 4 (12.1.0.4)
■
Patching Oracle WebLogic Server
■
Upgrading Oracle Exalogic System Targets
■
Restarting the Central Agent When Additional OMS Is Upgraded
■
Stopping the OCM Scheduler
■
Deleting Obsolete Targets
■
Cleaning Up Stale Compliance Standards of Deleted Targets
■
Updating Incident Rules
■
Disabling Incident Rule Sets
■
Resolving Metric Collection Errors for SOA Target
■
Enabling Linux Patching After Upgrading Enterprise Manager
■
Updating the Console URL
■
Redoing the Customization on Deployment Procedures
■
Reconfiguring Oracle WebLogic Server with Custom Certificates
■
Restarting the Management Agent After Upgrading an Additional OMS
■
Enabling the Compliance Standards That Were Disabled in the Previous Release
12.6.1 Performing General Postupgrade Steps After Upgrading to Enterprise Manager
Cloud Control 12c Release 4 (12.1.0.4)
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_processes parameter.
3.
(Only for 1-System Upgrade Approach) Start the Management Agent that monitors
the Management Services and Repository target. Before starting the 2-system
upgrade, you would have shut it down to prevent it from connecting to the
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control 12c Release 4 (12.1.0.4)
12-9
Performing General Postupgrade Tasks
Management Repository for metric collections. After upgrade, make sure you start
it.
4.
Upgrade to 12c Release 4 (12.1.0.4) is an out-of-place upgrade, and therefore, any
customization done on the WebLogic Server, which is configured with the earlier
release of the Enterprise Manager system, is not carried over by the upgrade
process. You will have to redo the customization on the upgraded system.
12.6.2 Patching Oracle WebLogic Server
While upgrading the Enterprise Manager system, in the installer if you had provided a
middleware home location that already contained an Oracle WebLogic Server of the
supported version, which you had installed yourself before invoking the installer, then
make sure you apply the patches 14482558, 13349651, and 16080294 on that Oracle
WebLogic Server. Without these patches, the additional OMS installation will fail.
These patches are required only if you are using an Oracle WebLogic Server that you
installed yourself. They are not required if you provided an empty middleware home
location and let the installer install the Oracle WebLogic Server while performing the
upgrade.
12.6.3 Upgrading Oracle Exalogic System Targets
This section is NOT applicable for upgrade from 10g Release 5
(10.2.0.5).
Note:
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 the following supported release so that they contain 12.1.0.3 or later
versions of the Oracle Fusion Middleware Plug-in.
■
■
■
If you upgraded from Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3),
and if you had not performed this step when you upgraded to 12c Release 3
(12.1.0.3), then perform this step now in 12c Release 4 (12.1.0.4). Ensure that the
Management Agent in this case is either 12c Release 4 (12.1.0.4), 12c Release 3
(12.1.0.3), or 12c Release 2 (12.1.0.2).
If you upgraded from Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2),
and if you had not performed this step when you upgraded to 12c Release 2
(12.1.0.2), then perform this step now in 12c Release 4 (12.1.0.4). Ensure that the
Management Agent in this case is either 12c Release 4 (12.1.0.4) or 12c Release 2
(12.1.0.2).
If you upgraded from 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4), then the
Management Agent must be 12c Release 4 (12.1.0.4).
If one or more such Management Agents are not upgraded yet to any of these
supported releases, 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.
12-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Performing General Postupgrade Tasks
12.6.4 Restarting the Central Agent When Additional OMS Is Upgraded
After you upgrade an additional OMS of 10g Release 5 (10.2.0.5) to 12c Release 4
(12.1.0.4) using 1-system upgrade approach, the targets that begin with /EMGC_
GCDomain/GCDomain might appear as if they are down (see Example 12–1).
Example 12–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)
To resolve this issue, first check if the Management Agent on the additional OMS host
is up, then refresh the Weblogic domain in the Enterprise Manager Cloud Control
Console, and then restart the Management Agent on the additional OMS host.
12.6.5 Stopping the 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 upgraded 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
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.
Note:
■
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>
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-11
4
Performing General Postupgrade Tasks
3.
Stop the OCM scheduler:
$ORACLE_HOME/ccr/bin/emCCR stop
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.
Note:
12.6.6 Deleting Obsolete Targets
Targets that were created to monitor 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.
This section describes how you can delete these obsolete targets. In particular, this
section covers the following:
■
Deleting the Obsolete Targets After 1-System Upgrade
■
Deleting the Obsolete Targets After 2-System Upgrade
12.6.6.1 Deleting the Obsolete Targets After 1-System Upgrade
■
■
■
After upgrading from Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3)
or 12c Release 2 (12.1.0.2), you will not have any obsolete targets to delete. In this
case, you can ignore this section.
After 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
–
Microsoft Operations Manager Connector Target (generic_mom_managed_host)
–
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
After 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
–
Microsoft Operations Manager Connector Target (generic_mom_managed_host)
–
The following targets of each old OMS. You can manually delete these by
deleting the top-level farm target secFarm_GCDomain.
12-12 Oracle Enterprise Manager Cloud Control Upgrade Guide
Performing General Postupgrade Tasks
*
Oracle Fusion Middleware Farm
*
Oracle Weblogic Domain
*
Application Deployment
*
Metadata Repository
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.
Note:
12.6.6.2 Deleting the Obsolete Targets After 2-System Upgrade
■
■
Manually delete these targets:
–
EM Website
–
EM Website System
–
Microsoft Operations Manager Connector Target (generic_mom_managed_host)
As part of 2-system upgrade, the central agent and the targets monitored by it are
automatically deleted, and therefore, you need not manually delete the old central
agent.
If you want to continue to monitor some of the targets that were automatically
deleted, then install Oracle Management Agent 12c on that host. For instructions,
see Oracle Enterprise Manager Cloud Control Basic Installation Guide.
12.6.7 Cleaning Up Stale Compliance Standards of Deleted Targets
From the Enterprise Manager Cloud Control Console (or from EM CLI), when you
delete a target that is associated with a user-defined compliance standard, the target is
deleted from the Enterprise Manager system but its user-defined compliance standard
is not removed completely. This causes an issue when attempting to edit this
compliance standard later on. To circumvent this issue, after upgrading the Enterprise
Manager system, manually delete all stale compliance-related data for the deleted
targets.
To verify if you have any stale, compliance-related data for the deleted targets, run the
following SQL query manually as SYSMAN user on the Management Repository. If
the result of the query is greater than zero, then manually delete the stale data.
select count(*) from em_cs_tgt_assoc_txf_req where root_target_guid not in
(select target_guid from mgmt_targets);
To manually delete all stale compliance-related data for the deleted targets, follow
these steps:
1.
Log in to the database, which houses the Management Repository, as SYSMAN
user.
2.
Run the cleanup script uploaded to My Oracle Support note 1643222.1:
SQL>@cleanup_stale_data.sql
3.
Run the following SQL query manually, and make sure the output is zero:
SQL> select count(*) from sysman.em_cs_tgt_assoc_txf_req where root_
target_guid not in (select target_guid from mgmt_targets);
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-13
4
Performing General Postupgrade Tasks
12.6.8 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 section describes
how you can manually adjust the rulesets.
In particular, this section covers the following:
■
About Updating the Incident Rules
■
Updating the Incident Rules for Moved Metrics
■
Updating the Incident Rules for Renamed Metrics
■
Deleting Incident Rules
12.6.8.1 About Updating the 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 12–1 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.
12-14 Oracle Enterprise Manager Cloud Control Upgrade Guide
Performing General Postupgrade Tasks
Table 12–1
Changes to Metrics and Updates to Be Done
Change
Type
Change
Description
Retained
Some metrics have The following metrics have been
been retained for
retained:
the same target type
■
Collections Waiting To Run
—OMS and
Repository.
■
DBMS Job Invalid Schedule
Affected Metrics
■
DBMS Job UpDown
■
Dequeue Status
■
Enqueue Status
■
Job Step Backlog
■
Notification UpDown
■
Number of Active Agents
■
■
■
■
Moved
Some metrics have
been moved to the
individual target
type—Oracle
Management Service.
No changes required.
DBMS Job Processing Time (%
of Last Hour)
■
■
Action to Be Taken
by You
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)
The following metrics have been
moved:
■
■
■
■
Set up new incident
rules to respond to
the metrics that have
Loader Throughput (rows per
been moved to
second)
different target types.
Total Loader Runtime in the
See Section 12.6.8.2
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]
Renamed
Some metrics have
been renamed for
easy undersanding.
The following metrics have
beenhave been renamed:
■
■
Update the incident
rules set to the metrics
that have been
Average Notification Delivery
renamed.
Time (ms) Per Method
[Renamed to Average
See Section 12.6.8.3
Notification Time (seconds)]
Notifications Waiting
[Renamed to Pending
Notifications Count]
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-15
4
Performing General Postupgrade Tasks
Table 12–1 (Cont.) Changes to Metrics and Updates to Be Done
Change
Type
Change
Description
Affected Metrics
Decommiss Some metrics have The following metrics have been
ioned
been
decommissioned:
decommissioned
■
Number of Duplicate Targets
due to lack of
support in
■
Notification Processing Time
Enterprise Manager
(% of Last Hour)
Cloud Control.
■
Overall Files Pending Load Loader
■
Action to Be Taken
by You
Remove
decommissioned
metrics from the
incident rules.
See Section 12.6.8.4
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.)
12.6.8.2 Updating the 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.
5.
In the Edit Rule Wizard, do the following:
a.
On the Select Events page, select the metrics listed in the second row of
Table 12–1, and click Remove.
b.
Click Next.
c.
On the Add Actions page and the Specify Name and Description page, click
Next without making any change.
d.
On the Review page, click Continue.
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.
12-16 Oracle Enterprise Manager Cloud Control Upgrade Guide
Performing General Postupgrade Tasks
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:
a.
On the Select Events page, from the Event Type list, select Metric Alert.
For the metric Management Service Status, select Target
Availability from the Event Type list.
Note:
b.
Select Specific metric alerts, and click Add.
c.
In the Select Specific Metric Alert dialog, do the following:
a.
In the Search region, from the Target Type list, select Oracle Management
Service, and then, click Search.
b.
From the table, select the moved metrics listed in the second row of
Table 12–1.
c.
In the Severity and Corrective Action Status region, from the Severity list,
select an appropriate severity level.
d.
Click OK.
d.
Click Next.
e.
On the Add Actions page and the Specify Name and Description page, click
Next without making any change.
f.
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.
12.6.8.3 Updating the 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:
a.
On the Select Events page, select the metrics listed in the third row of
Table 12–1, and click Remove.
b.
Click Add.
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-17
4
Performing General Postupgrade Tasks
c.
In the Select Specific Metric Alert dialog, do the following:
a.
In the Search region, from the Target Type list, select OMS and
Repository, and then, click Search.
b.
From the table, select the renamed metrics listed in the third row of
Table 12–1.
c.
In the Severity and Corrective Action Status region, from the Severity list,
select an appropriate severity level.
d.
Click OK.
d.
Click Next.
e.
On the Add Actions page and the Specify Name and Description page, click
Next without making any change.
f.
On the Review page, click Continue.
Note:
Repeat the procedure for all other incident rules created for the
OMS.
12.6.8.4 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:
a.
On the Select Events page, select the metrics listed in the last row of
Table 12–1, and click Remove.
b.
Click Next.
c.
On the Add Actions page and the Specify Name and Description page, click
Next without making any change.
d.
On the Review page, click Continue.
Note:
Repeat the procedure for all other incident rules created for the
OMS.
12.6.9 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:
12-18 Oracle Enterprise Manager Cloud Control Upgrade Guide
Performing General Postupgrade Tasks
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.
12.6.10 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 Section 10.2, 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.
12.6.11 Enabling Linux Patching After Upgrading Enterprise Manager
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.
Note:
If you had scheduled any jobs of the types DownloadLatestPkgs or
UpdateHostPackages in the previous release, then after upgrading to 12c Release 4
(12.1.0.4), those jobs will fail due to missing credentials. Therefore, to resolve this issue,
you can do one of the following:
■
■
Resubmitting All Active Linux Patching Jobs After Stopping the Jobs and
Resetting their Credentials
Resubmitting All Active Linux Patching Jobs After Resetting the Credentials, but
without Stopping the Jobs
12.6.11.1 Resubmitting All Active Linux Patching Jobs After Stopping the Jobs and
Resetting their Credentials
After the upgrade, you must stop all active Linux patching jobs that were submitted
prior to the upgrade, reset their credentials, and then resubmit the jobs on the same
targets. To do so, follow the instructions outlined in the following sections:
■
■
Resubmitting DownloadLatestPackages Jobs After Stopping them and Resetting
their Credentials
Resubmitting UpdateHostPackages Jobs After Stopping Them and Resetting their
Credentials
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-19
4
Performing General Postupgrade Tasks
Note: If you do not want to stop the active Linux patching jobs, then
see Section 12.6.11.2.
12.6.11.1.1 Resubmitting DownloadLatestPackages Jobs After Stopping them and Resetting
their Credentials
To stop and resubmit all DownloadLatestPackages jobs, follow these steps:
1.
2.
Stop active jobs which were scheduled prior to upgrade as follows:
a.
From the Enterprise menu, select Job and then Activity. The Job Activity page
is displayed.
b.
In the Job Activity page, click the Advanced Search link.
c.
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.
d.
In the Advanced Search result, select each job listed in the table and click Stop.
For each host target on which an active DownloadLatestPkgs job was stopped,
resubmit a new DownloadLatestPkgs job on it as follows:
a.
From the Setup menu, select Provisioning and Patching and then Linux
Patching. The Patching Setup page is displayed.
b.
In the Patching Setup page, click Setup RPM Repository.
c.
In the Setup RPM Repository page, select the Host target and set Normal Host
Credentials and Privileged Host Credentials for this host target.
d.
Click Apply to submit the new job.
12.6.11.1.2 Resubmitting UpdateHostPackages Jobs After Stopping Them and Resetting their
Credentials
To stop and resubmit all UpdateHostPackages jobs, follow these steps:
1.
2.
Stop active jobs which were scheduled prior to upgrade as follows:
a.
From the Enterprise menu, select Job and then Activity. The Job Activity page
is displayed.
b.
In the Job Activity page, click the Advanced Search link.
c.
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.
d.
In the Advanced Search result, select each job listed in the table and click Stop.
For each group target on which an active UpdateHostPackages job was stopped,
resubmit a new UpdateHostPackages job on it as follows:
a.
From the Setup menu, select Provisioning and Patching and then Linux
Patching.
b.
In the Patching Setup page, click Setup Groups. The Setup Groups page is
displayed.
c.
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.
d.
In the Edit Group: Properties page, click Next.
12-20 Oracle Enterprise Manager Cloud Control Upgrade Guide
Performing General Postupgrade Tasks
e.
In the Edit Group: Package Repositories page, click Next.
f.
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.
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.
Note:
g.
In the Edit Group: Review page, click Finish to submit the new job.
12.6.11.2 Resubmitting All Active Linux Patching Jobs After Resetting the
Credentials, but without Stopping the Jobs
After upgrade, you must reset the credentials of all active Linux patching jobs that
were submitted prior to the upgrade, and then resubmit the jobs. To do so, follow
these steps:
1.
From the Enterprise menu, select Job, then select Activity.
2.
On the Job Activity page, click Advanced Search.
3.
In the Advanced Search region, in the Name field, enter the job name PACKAGES
UPDATE%, and from the Job Type list, select UpdateHostPackages. Click Go.
4.
In the search results table, select the job and click Edit.
5.
On the Edit 'UpdateHostPackages' Job page, click the Credentials tab.
6.
In the Credentials tab, set the necessary credentials.
7.
Click Submit.
8.
Repeat Step (3) to Step (7) for the job name DOWNLOADLATESTPKGS% of the job type
DownloadLatestPkgs.
12.6.12 Updating the Console URL
If you have a multi-OMS environment with a Server Load Balancer (SLB) configured
for the upgraded OMS instances, then make sure you update the console URL on the
Management Services and Repository page. The console URL you enter here is used to
compose links pointing back to the Enterprise Manager Cloud Control Console in the
e-mails sent by Enterprise Manager.
To update the Console URL, follow these steps:
1.
From the Setup menu, select Manage Cloud Control, then select Health
Overview.
2.
On the Management Services and Repository page, in the Overview section, click
Edit against the Console URL label, and modify the URL to the SLB URL.
For example, http://www.example.com, https://www.example.com:4443.
Note:
Do NOT end the Console URL with /em.
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-21
4
Performing General Postupgrade Tasks
3.
Verify if the updated console URL appears correctly in the e-mails sent by
Enterprise Manager.
12.6.13 Redoing the Customization on Deployment Procedures
Customization done on deployment procedures in 10g Release 5 (10.2.0.5) or 11g
Release 1 (11.1.0.1) are not carried over when they are upgraded to 12c Release X
(12.1.0.X). Therefore, if you had done some customization on the deployment
procedures before upgrading, then after upgrading, redo the customization.
12.6.14 Reconfiguring Oracle WebLogic Server with Custom Certificates
Note:
■
■
This section is applicable only if you are upgrading from 12c
Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
(12.1.0.4).
This section is applicable only for Oracle WebLogic Server custom
certificates, and not applicable for Enterprise Manager Console
certificates. The Enterprise Manager Console certificates are
automatically copied over during upgrade.
If custom certificates were configured for Oracle WebLogic Servers (admin server as
well as managed servers) in 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2), then
after upgrading to 12c Release 4 (12.1.0.4), the custom certificates are not carried over,
and Oracle WebLogic Servers are configured with Demo Certificates. Therefore, after
upgrading, make sure you reconfigure the Oracle WebLogic Servers with custom
certificates. To do so, follow these steps:
1.
Run the following command on all the OMS instances. For information on the
command and the options you can pass, see the Oracle Enterprise Manager Cloud
Control Security Guide.
$<OMS_Home>/bin/emctl secure wls <options>
2.
Stop all the OMS instances:
$<OMS_Home>/bin/emctl stop oms -all
3.
Start all the OMS instances:
$<OMS_Home>/bin/emctl start oms
12.6.15 Restarting the Management Agent After Upgrading an Additional OMS
After upgrading the first OMS of 12c Release X (12.1.0.X) to 12c Release 4 (12.1.0.4),
Oracle strongly recommends that you immediately upgrade the central agent on that
host as described in Chapter 4.
However, if you did not upgrade the central agent on that host, and instead proceeded
with the upgrade of an additional OMS from 12c Release X (12.1.0.X) to 12c Release 4
(12.1.0.4), then verify the version of that upgraded additional OMS on the Managed
Services page. To do so, from the Setup menu, select Manage Cloud Control, then
select Management Services. Verify the OMS version.
If it still shows the older version and not the upgraded version, then restart the
Management Agent on the additional OMS host.
12-22 Oracle Enterprise Manager Cloud Control Upgrade Guide
Tracking the Status of Deferred Data Migration Jobs
12.6.16 Enabling the Compliance Standards That Were Disabled in the Previous
Release
After you upgrade to 12c Release 4 (12.1.0.4), the compliance standards that were
disabled in the previous release are automatically enabled in 12c Release 4 (12.1.0.4). If
you want to continue to have these compliance standards disabled, then manually
disable them for each target in 12c Release 4 (12.1.0.4) after you upgrade. To do so,
follow these steps:
1.
From the Enterprise menu, select Compliance, then Library.
2.
On the Compliance Library page, click the Compliance Standards tab.
3.
In the Compliance Standards tab, select a compliance standard and click Associate
Targets.
4.
On the Compliance Standard Target Association page, select a target and click
Edit.
5.
On the Target Settings for Compliance Standard page, in the left tree view, select
the rule node, and in the right panel, from the Compliance Standard Rule
Evaluation Status list, select Disabled. Click OK.
6.
On the Compliance Standard Target Association page, click OK.
12.7 Tracking the Status of Deferred Data Migration Jobs
This section describes the following:
■
About Deferred Data Migration Jobs
■
Tracking the Status of Deferred Data Migration Jobs
12.7.1 About Deferred Data Migration Jobs
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
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-23
4
Tracking the Status of Accrued Data Migration Jobs
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 Section 9.3 and Section 9.2 (Step 6).
Canceling or stopping of a running DDMP job is not
recommended.
WARNING: Do not shut down or restart the OMS or the
Management Repository while DDMP jobs are running.
12.7.2 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.
12.8 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:
■
About Accrued Data Migration Jobs
12-24 Oracle Enterprise Manager Cloud Control Upgrade Guide
Tracking the Status of Accrued Data Migration Jobs
■
Tracking the Status of Accrued Data Migration Jobs
12.8.1 About Accrued Data Migration Jobs
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.
The Accrued Data Migration process does not migrate any of
the following changes if they were done after the Management
Repository was backed up. If you want these changes in the upgraded
Enterprise Manager system, you must manually redo these changes
after upgrade.
Note:
■
Security data (new users created, passwords changed)
■
Jobs created, deleted, or submitted
■
Customized deployment procedures
■
Patches
■
Targets added or deleted
■
Reports created, modified, or deleted
■
Software Library configuration changes
■
Templates created, modified, or deleted
■
User-defined metrics
Check the Diff Report as described in Section 12.9 to know what all
changes are not migrated via the ADMP process and what needs to be
migrated manually.
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
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-25
4
Tracking the Status of Accrued Data Migration Jobs
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.
12-26 Oracle Enterprise Manager Cloud Control Upgrade Guide
Tracking the Status of Accrued Data Migration Jobs
Note:
■
■
■
If you want to prevent the ADMP jobs from running immediately
by default, then see Section 9.2 (Step 6).
Do NOT change any database link-related settings during ADMP
process. If you do, the ADMP process will fail to use the database
link.
ADMP uses DBMS_SCHEDULER, so make sure all
scheduler-related settings are turned on (on the server) to submit
any jobs using DBMS_SCHEDULER.
To verify this, run the following query:
select value from dba_scheduler_global_attribute where
attribute_name='SCHEDULER_DISABLED'
If the query returns TRUE, then run the following query:
exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_
DISABLED','FALSE');
12.8.2 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 Components, 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.
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-27
4
Generating and Viewing Diff Reports
■
■
–
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.
12.9 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:
■
About Diff Reports
■
Generating and Viewing Diff Reports
12.9.1 About 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 add additional Software Library entity, new jobs, new
deployment procedures, and so on.
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.
12.9.2 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.
All the changes shown in the diff report are not migrated by
the upgrade process from old to new Enterprise Manager system, so
you must migrate them manually. Ensure that the database
link-related settings are intact while you use the diff report.
Note:
12-28 Oracle Enterprise Manager Cloud Control Upgrade Guide
Viewing Inactive Targets in the Upgraded 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.
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.
Note:
■
■
■
■
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.
12.10 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.
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-29
4
Signing Off the Accrued Data Migration Process
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 Section 10.4.
Note:
12.11 Signing Off the Accrued Data Migration Process
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.
Note:
After you switch over the Oracle Management Agents (Management Agent) to the
new Enterprise Manager system, you can deinstall the earlier release of Management
Agents. Instead of manually deinstalling the Management Agents, you can formally
sign off the Accrued Data Migration Process (ADMP) for each of the Management
Agents and have the Post Upgrade Console automatically deinstall them for you.
Caution: The sign-off process requires you to have all the credentials
set to run file system-related operations on the Management Agent, so
make sure you have set all the required credentials.
To sign off the ADMP 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.
By default, the page lists all the Management Agents regardless of their sign-off
status.
3.
On this page, search Management Agents for which you have signed off the
ADMP process or for which you are yet to sign off.
(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.
4.
Select Management Agents you want to formally sign off. To select all the
Management Agents in one attempt, enable Select All.
If you are selecting a Master Agent to sign off, then make sure
you sign it off only after all its Shared Agents have been signed off. If
they have not already been signed off, then select those Shared Agents
to be signed off along with the Master Agent.
Note:
5.
Click Sign off Agents.
12-30 Oracle Enterprise Manager Cloud Control Upgrade Guide
Deleting Old Central Agents and the Associated Targets
6.
Provide credentials to access the hosts on which the selected Management Agents
were running.
7.
Click Submit.
Once you sign off, the selected 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
the new Enterprise Manager system.
Note:
12.12 Signing Off the Migration Processes and Exiting the Upgrade Mode
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.
Note:
After the Deferred Data Migration Process (DDMP), the Management Agent
switchover, the Accrued Data Migration Process (ADMP), the manual data migration
as calculated by the diff report, you can formally sign off the migration process, and
exit upgrade mode.
WARNING: Sign-off must be the last step of the upgrade process.
Once this is done, all upgrade-related processes and resources are
cleaned up, and you must not run any ADMP or DDMP jobs, or
generate any diff reports.
To sign off the migration processes and formally exit the upgrade mode, 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.
On this page, select Sign off Migration, and click Go. This option is placed at the
bottom-left corner below the table.
4.
(Applicable Only for 2-System Upgrade Approach and 1-System Upgrade Approach on a
Different Host) After exiting the upgrade mode, delete the old central agents as
described in Section 12.13.
After deleting the central agents, if you want to continue monitoring the targets
that were monitored by them, then follow the instructions outlined in
Section 12.14.
12.13 Deleting Old Central Agents and the Associated Targets
This section describes the following procedures for deleting the old central agents and
their associated targets.
■
Deleting Unwanted Central Agents After Upgrading from 10.2.0.5/11.1.0.1 to
12.1.0.4
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-31
4
Deleting Old Central Agents and the Associated Targets
■
Deleting Unwanted Central Agents After Upgrading from 12.1.0.2/12.1.0.3 to
12.1.0.4
12.13.1 Deleting Unwanted Central Agents After Upgrading from 10.2.0.5/11.1.0.1 to
12.1.0.4
This section is applicable only for 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.
Note:
If you upgraded 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) using the 2-system
upgrade approach or the 1-system upgrade approach on a different host, then delete
the old central agent that was not switched over. You do not require this central agent.
In the Preupgrade Console, the central agents are listed for
selection, but when you select and try to submit a deployment and
configuration job, the selected central agents are validated and
reported as problematic agents. Therefore, they cannot be deployed
and configured, and as a result, cannot be switched over. Since these
central agents are no longer required, you must delete them.
Note:
To delete the old central agent and the associated targets, follow these steps:
1.
As a prerequisite, verify the host where you installed Enterprise Manager Cloud
Control as described in Section 12.1.
2.
Identify the central agents by running the following query as SYSMAN user in the
upgraded Management Repository (12.1.0.4 repository). The query reports central
agents and the targets monitored by them, but make note of only the central agent
names. Deleting the central agents anyway deletes the targets monitored by them.
SELECT ag.target_name agent_name, t.target_name target_name, t.target_
type target_type FROM sysman.mgmt_targets ag, sysman.em_current_
availability eca, sysman.PRE_UPGC_AGT_STAT_MGMT puasm, sysman.mgmt_
targets t WHERE ag.target_guid = eca.target_guid AND eca.current_status
= 4 AND eca.current_sub_status = 1 AND ag.target_type='oracle_emd' AND
puasm.target_guid = ag.target_guid AND puasm.UPGRADE_STATUS !='IGNORE_
UPGRADE' AND ag.emd_url IN (SELECT emd_url FROM mgmt_targets WHERE
target_type = 'host' AND target_name IN (SELECT value FROM mgmt_oms_
parameters WHERE name = 'HOST_NAME')) AND ag.emd_url NOT IN (SELECT
emd_url FROM sysman.mgmt_targets WHERE target_type='oracle_emrep') AND
t.emd_url = ag.emd_url ORDER BY ag.target_name, t.target_type,
t.target_name
3.
Delete the identified, old central agent:
a.
On the remote host where you installed the new Enterprise Manager Cloud
Control, 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>
b.
Synchronize EM CLI:
12-32 Oracle Enterprise Manager Cloud Control Upgrade Guide
Deleting Old Central Agents and the Associated Targets
$<OMS_HOME>/bin/emcli sync
c.
Delete the central agent. Here, agentName is the name of the central agent you
want to delete.
$<OMS_HOME>/bin/emcli delete_target -name=<agentName> -type=oracle_
emd -delete_monitored_targets
For example,
$/u01/software/oracle/middleware/oms/bin/emcli delete_target
-name=example.com:4567 -type=oracle_emd -delete_monitored_targets
4.
(Optional) After deleting the central agent, if you want to continue monitoring the
targets that were monitored by it, then follow the instructions outlined in
Section 12.14.
12.13.2 Deleting Unwanted Central Agents After Upgrading from 12.1.0.2/12.1.0.3 to
12.1.0.4
Note: This section is applicable only for 1-system upgrade from 12c
Release 3 (12.1.0.3) and 12c Release 2 (12.1.0.2).
After upgrading from 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4
(12.1.0.4), if central agents that existed in the pre-12c release appear in Activation
Pending state in the Enterprise Manager Cloud Control Console, then delete them by
following these steps:
1.
As a prerequisite, verify the host where you installed/upgraded Enterprise
Manager Cloud Control as described in Section 12.1.
2.
Identify the unwanted central agents to be deleted by running the following query
as SYSMAN user in the upgraded Management Repository (12.1.0.4 repository).
The query reports central agents and the targets monitored by them, but make
note of only the cental agent names. Deleting the central agents anyway deletes
the targets monitored by them.
SELECT ag.target_name agent_name, t.target_name target_name, t.target_
type target_type FROM sysman.mgmt_targets ag, sysman.em_current_
availability eca, sysman.PRE_UPGC_AGT_STAT_MGMT puasm, sysman.mgmt_
targets t WHERE ag.target_guid = eca.target_guid AND eca.current_status
= 4 AND eca.current_sub_status = 1 AND ag.target_type='oracle_emd' AND
puasm.target_guid = ag.target_guid AND puasm.UPGRADE_STATUS !='IGNORE_
UPGRADE' AND ag.emd_url NOT IN (SELECT emd_url FROM sysman.mgmt_targets
WHERE target_type='oracle_emrep') AND t.emd_url = ag.emd_url ORDER BY
ag.target_name, t.target_type, t.target_name
3.
Delete the unwanted central agents:
a.
On the upgraded 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>
b.
Synchronize EM CLI:
$<OMS_HOME>/bin/emcli sync
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-33
4
(Optional) Monitoring Targets That Were Monitored by the Deleted Central Agent
c.
Delete the unwanted central agents. Here, agentName is the name of the
central agent you want to delete.
$<OMS_HOME>/bin/emcli delete_target -name=<agentName> -type=oracle_
emd -delete_monitored_targets
For example,
$/u01/software/oracle/middleware/oms/bin/emcli delete_target
-name=example.com:4567 -type=oracle_emd -delete_monitored_targets
12.14 (Optional) Monitoring Targets That Were Monitored by the Deleted
Central Agent
This section is applicable only for 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.
Note:
If you upgraded 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) using the 2-system
upgrade approach or the 1-system upgrade approach on a different host, then you are
required to delete the unwanted old central agent as described in Section 12.13. After
deleting this central agent, if you want to continue monitoring the targets that were
monitored by the deleted central agent, then follow these steps:
1.
Install a fresh Oracle Management Agent 12c using the Add Host Targets Wizard
from the new OMS, on the old central agent host.
2.
Discover all the targets running on that host so that they can be monitored in the
new OMS.
12.15 (Optional) Deleting the Old OMS Home
After upgrading your Enterprise Manager system completely, if you want to delete
your old OMS home, follow these steps:
■
■
■
If you upgraded from 12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c
Release 4 (12.1.0.4), either full release or an additional OMS, then follow the
instructions outlined in Appendix K.
If you upgraded from 11g Release 1 (11.1.0.1) to 12c Release 4 (12.1.0.4), 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 4 (12.1.0.4), either full
release or an additional OMS, then follow the instructions outlined in the Oracle
Enterprise Manager Grid Control Installation and Configuration Guide.
12.16 Migrating the SYSMAN Schema to a Database Configured with CDB
and PDB
If you plan to migrate the SYSMAN schema to a database configured with CDB and
PDB, then ensure that you meet the following requirements:
1.
Upgrade the database to a non-CDB-based database. During the database upgrade
process, ensure that the character set of the non-CDB-based database is the same
12-34 Oracle Enterprise Manager Cloud Control Upgrade Guide
Resolving Custom Roles Issue When Custom Roles Do Not Appear in the Console
as the CDB. Then, migrate the SYSMAN schema from the upgraded
non-CDB-based database to a new PDB in the CDB.
2.
Correct the connect descriptor with updated database details. To do so, follow
these steps on each OMS instance:
a.
Stop all the OMS instances.
emctl stop oms -all
b.
Start the administration server on the first OMS.
emctl start oms -admin-only
c.
On each OMS instance, modify the connect descriptor for the Management
Repository:
emctl config oms -store_repos_details -repos_conndesc
"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<host_
name>)(PORT=<port>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_
NAME=<service_name>)))"
For example,
emctl config oms -store_repos_details -repos_conndesc
"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost.example.com)(PORT
=1522))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_
NAME=pdb2.example.com)))"
d.
Stop and start all the OMS instances.
emctl stop oms -all
emctl start oms
e.
Modify the monitoring configuration of the OMS and the Management
Repository target.
emctl config emrep -conn_desc
12.17 Resolving Custom Roles Issue When Custom Roles Do Not Appear
in the Console
After you upgrade to 12c Release 4 (12.1.0.4), some of the custom roles you previously
created might not appear on the Roles page, and the members of the previously
created roles might now appear as owners of those roles (to access the Roles page,
from the Setup menu, select Security, then select Roles.)
This is an expected behavior and this behavior does not affect the Role or the
Administrator functionality, and does not cause any security violations in Enterprise
Manager Cloud Control. The roles, and the target privileges and resources privileges
as defined for these roles before upgrading to 12c Release 4 (12.1.0.4) are not affected
in any way. The roles might not appear on the Roles page and therefore cannot be
maintained using the Enterprise Manager Cloud Control Console, but they are present
in the Oracle Management Repository.
Administrators with these roles should still be able to log in, view, and access their
resources and targets, and should still be able to perform their tasks as expected, as
they did before upgrading.
For more information on this issue and to resolve the issue if you face it, see My Oracle
Support note 1905392.1.
Performing Postupgrade Tasks After Upgrading to Enterprise Manager Cloud Control
(12.1.0.4)
12c Release
12-35
4
Resolving Custom Roles Issue When Custom Roles Do Not Appear in the Console
12-36 Oracle Enterprise Manager Cloud Control Upgrade Guide
Part IV
Part IV
Appendixes
This part contains the following appendixes:
■
■
■
■
Appendix A, "Editing the Response File for Upgrading Oracle Management
Service and Oracle Management Repository in Silent Mode"
Appendix B, "Overview of the Notification System in Enterprise Manager Cloud
Control"
Appendix C, "Overview of the Metric Changes in Enterprise Manager Cloud
Control"
Appendix D, "Identifying the Jobs That Will Not Run in Enterprise Manager for
2-System Upgrade Approach"
■
Appendix E, "Updating Server Load Balancer Configuration Settings"
■
Appendix F, "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 Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft
Windows 32-bit Host to Microsoft Windows 64-bit Host"
Appendix K, "Deleting the Old OMS Home"
Appendix M, "Reviewing Log Files Related to the Upgrade of an Enterprise
Manager System"
A
Editing the Response File for Upgrading
Oracle Management Service and Oracle
Management Repository in Silent Mode
A
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 Parameters of the upgrade.rsp File for Upgrading OMS in Silent Mode
Parameter Name
UNIX_GROUP_
NAME
INVENTORY_
LOCATION
SECURITY_
UPDATES_VIA_
MYORACLESUPP
ORT
DECLINE_
SECURITY_
UPDATES
Applicable Upgrade
Approach
Data
Type
Are
Double
Quotes
Needed
for the
Values?
Applicable to all upgrade
approaches for normal
upgrade as well as
software-only upgrade.
String
Yes
Applicable to all upgrade
approaches for normal
upgrade as well as
software-only upgrade.
String
Applicable to all upgrade
approaches for normal
upgrade.
Boolean
Not applicable to
software-only upgrade.
Therefore, comment out
this parameter for this
upgrade approach.
(Required only when central inventory does not exist)
Enter the name of the UNIX group you belong to.
For example, "dba".
Yes
(Required only when central inventory does not exist)
Enter the absolute path to the Central Inventory.
For example, "/scratch/oracle/oraInventory".
Yes
Not applicable to
software-only upgrade.
Therefore, comment out
this parameter for this
upgrade approach.
Applicable to all upgrade
approaches for normal
upgrade.
Description
■
Enter TRUE if you want to download and install
security updates. Then, enter the credentials for
the following variables in double quotes:
MYORACLESUPPORT_USERNAME
MYORACLESUPPORT_PASSWORD
■
Boolean
No
■
■
Enter FALSE if you do not want to download and
install 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.
Editing the Response File for Upgrading Oracle Management Service and Oracle Management Repository
Mode
in Silent
A-1
Table A–1
(Cont.) Editing Parameters of the upgrade.rsp File for Upgrading OMS in Silent Mode
Parameter Name
Applicable Upgrade
Approach
Data
Type
Are
Double
Quotes
Needed
for the
Values?
INSTALL_
UPDATES_
SELECTION
Applicable to all upgrade
approaches of normal
upgrade.
String
Yes
Not applicable to
software-only upgrade.
Therefore, comment out
this parameter for this
upgrade approach.
Description
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 in double quotes:
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, in double quotes.
For this option, as a prerequisite, you must have
already downloaded the software updates. For
instructions, see Oracle Enterprise Manager Cloud
Control Advanced Installation and Configuration
Guide.
ORACLE_
MIDDLEWARE_
HOME_
LOCATION
Applicable to all upgrade
approaches of normal
upgrade.
String
Yes
Not applicable to
software-only upgrade.
Therefore, comment out
this parameter for this
upgrade approach.
Upgrade to 12c Release 4 (12.1.0.4) 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.6) and Java
Development Kit 1.6.0.43.0. 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.
A-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Table A–1 (Cont.) Editing Parameters of the upgrade.rsp File for Upgrading OMS in Silent Mode
Parameter Name
Applicable Upgrade
Approach
Data
Type
Are
Double
Quotes
Needed
for the
Values?
ORACLE_
INSTANCE_
HOME_
LOCATION
Applicable to all upgrade
approaches for normal
upgrade as well as
software-only upgrade.
String
Yes
Description
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 outside
the Middleware home.
■
■
To accept the default location and the directory
name, leave the variable blank.
To have a custom location and a custom directory
name, enter the absolute path to the custom
location leading up to the custom directory name.
Important: If you are installing on an NFS-mounted
drive and creating the OMS instance base directory
(gc_inst) on that NFS-mounted drive, then after you
install, move the lock files from the NFS-mounted
drive to a local file system location. Modify the lock
file location in the httpd.conf file to map to a location
on a local file system. For instructions, refer to
Section 5.1.4.
OLD_BASE_DIR
Applicable only to 1-system
upgrade approach for
normal upgrade as well
software-only upgrade.
String
Yes
Enter the base directory of the OMS you want to
upgrade. If you are upgrading from 10g Release 5
(10.2.0.5), then it is the old OMS base directory. If you
are upgrading from 11g Release 1 (11.1.0.1) or within
the 12c series, then it is the middleware home.
String
Yes
By default, the fully qualified name of the host on
which you have invoked the installer, is considered.
Not applicable to 2-system
upgrade approach and
1-system upgrade approach
on a different host.
Therefore, comment out
this parameter for these
upgrade approaches.
ORACLE_
HOSTNAME
Applicable only to 2-system
upgrade approach and
1-system upgrade approach
on a different host for
normal upgrade.
■
■
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade. Not
applicable for 2-system
upgrade approach and
1-system upgrade approach
on a different host for
software-only upgrade.
Therefore, comment out this
parameter for these upgrade
approaches.
ONE_SYSTEM
Applicable to all upgrade
approaches for normal
upgrade as well as
software-only upgrade.
Boolean
No
To accept the default value, leave it blank.
To install with a different host name, then enter
another host name.
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.
Editing the Response File for Upgrading Oracle Management Service and Oracle Management Repository
Mode
in Silent
A-3
Table A–1
(Cont.) Editing Parameters of the upgrade.rsp File for Upgrading OMS in Silent Mode
Parameter Name
AGENT_BASE_
DIR
Applicable Upgrade
Approach
Data
Type
Are
Double
Quotes
Needed
for the
Values?
Applicable only to 2-system
upgrade approach and
1-system upgrade approach
on a different host for
normal upgrade.
String
Yes
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade. Not
applicable to 2-system
upgrade approach and
1-system upgrade approach
on a different host for
software-only upgrade. Also
not applicable for additional
OMS upgrade. Therefore,
comment out this parameter
for these upgrade
approaches.
A-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Description
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.
Table A–1 (Cont.) Editing Parameters of the upgrade.rsp File for Upgrading OMS in Silent Mode
Parameter Name
Applicable Upgrade
Approach
OLD_DATABASE_ Applicable only to 2-system
CONNECTION_
upgrade approach and
DESCRIPTION
1-system upgrade approach
on a different host for
normal upgrade as well as
software-only upgrade.
Data
Type
Are
Double
Quotes
Needed
for the
Values?
String
Yes
Description
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:
■
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade. Also
not applicable for additional
OMS upgrade. Therefore,
comment out this parameter
for this upgrade approach.
To connect using SID, enter the connect string in
the following format:
"(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.
Editing the Response File for Upgrading Oracle Management Service and Oracle Management Repository
Mode
in Silent
A-5
Table A–1
(Cont.) Editing Parameters of the upgrade.rsp File for Upgrading OMS in Silent Mode
Parameter Name
Applicable Upgrade
Approach
OLD_DATABASE_ Applicable only to 2-system
SYSMAN_
upgrade approach and
PASSWORD
1-system upgrade approach
on a different host for
normal upgrade as well as
software-only upgrade.
Data
Type
Are
Double
Quotes
Needed
for the
Values?
String
Yes
Applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
10.2.0.5. Applicable to
2-system upgrade approach
and 1-system upgrade
approach on a different host
for normal upgrade as well
as software-only upgrade of
10.2.0.5 and 11.1.0.1.
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.
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade. Also
not applicable for additional
OMS upgrade. Therefore,
comment out this parameter
for this upgrade approach.
WLS_ADMIN_
SERVER_
USERNAME
Description
String
Yes
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.
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
12.1.0.3, 12.1.0.2, and
11.1.0.1. Not applicable to
additional OMS upgrade.
Therefore, comment out
this parameter for these
upgrade approaches.
WLS_ADMIN_
SERVER_
PASSWORD
Applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
10.2.0.5. Applicable to
2-system upgrade approach
and 1-system upgrade
approach on a different host
for normal upgrade as well
as software-only upgrade of
10.2.0.5 and 11.1.0.1.
String
Yes
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
12.1.0.3, 12.1.0.2, and
11.1.0.1. Not applicable to
additional OMS upgrade.
Therefore, comment out
this parameter for these
upgrade approaches.
A-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
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.
Table A–1 (Cont.) Editing Parameters of the upgrade.rsp File for Upgrading OMS in Silent Mode
Parameter Name
WLS_ADMIN_
SERVER_
CONFIRM_
PASSWORD
Applicable Upgrade
Approach
Data
Type
Are
Double
Quotes
Needed
for the
Values?
Applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
10.2.0.5. Applicable to
2-system upgrade approach
and 1-system upgrade
approach on a different host
for normal upgrade as well
as software-only upgrade of
10.2.0.5 and 11.1.0.1.
String
Yes
Confirm the password for the WebLogic user account.
String
Yes
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.
Description
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
12.1.0.3, 12.1.0.2, and
11.1.0.1. Not applicable to
additional OMS upgrade.
Therefore, comment out
this parameter for these
upgrade approaches.
NODE_
MANAGER_
PASSWORD
Applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
10.2.0.5. Applicable to
2-system upgrade approach
and 1-system upgrade
approach on a different host
for normal upgrade as well
as software-only upgrade of
10.2.0.5 and 11.1.0.1.
Ensure that your password contains at least 8
characters without any spaces, begins with a letter,
and includes at least one numeric value.
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
12.1.0.3, 12.1.0.2, and
11.1.0.1. Not applicable to
additional OMS upgrade.
Therefore, comment out
this parameter for these
upgrade approaches.
Editing the Response File for Upgrading Oracle Management Service and Oracle Management Repository
Mode
in Silent
A-7
Table A–1
(Cont.) Editing Parameters of the upgrade.rsp File for Upgrading OMS in Silent Mode
Parameter Name
NODE_
MANAGER_
CONFIRM_
PASSWORD
Applicable Upgrade
Approach
Data
Type
Are
Double
Quotes
Needed
for the
Values?
Applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
10.2.0.5. Applicable to
2-system upgrade approach
and 1-system upgrade
approach on a different host
for normal upgrade as well
as software-only upgrade of
10.2.0.5 and 11.1.0.1.
String
Yes
Confirm the password for the node manager user
account.
String
Yes
Enter the password for the WebLogic user account you
had created for the old Enterprise Manager system.
String
Yes
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_deepdive.dbf)
for this tablespace can be stored. Ensure that the
entered path leads up to the file name.
Description
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
12.1.0.3, 12.1.0.2, and
11.1.0.1. Not applicable to
additional OMS upgrade.
Therefore, comment out
this parameter for these
upgrade approaches.
WLS_ADMIN_
SERVER_
PASSWORD
Applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
12.1.0.3, 12.1.0.2, and
11.1.0.1. Applicable to
additional OMS upgrade of
12.1.0.3, 12.1.0.2, 11.1.0.1,
and 10.2.0.5.
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade of
10.2.0.5. Not applicable to
2-system upgrade approach
and 1-system upgrade
approach on a different host
for normal upgrade as well
as software-only upgrade of
10.2.0.5 and 11.1.0.1.
Therefore, comment out
this parameter for these
upgrade approaches.
JVM_
DIAGNOSTICS_
TABLESPACE_
LOCATION
Applicable to all upgrade
approaches for normal
upgrade as well as
software-only upgrade of
10.2.0.5.
Not applicable to any of the
upgrade approaches for
normal upgrade as well as
software-only upgrade of
12.1.0.2, 12.1.0.3, and
11.1.0.1. Therefore,
comment out this parameter
for these upgrade
approaches.
A-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
For example, "/home/john/oradata/mgmt_
deepdive.dbf".
Table A–1 (Cont.) Editing Parameters of the upgrade.rsp File for Upgrading OMS in Silent Mode
Parameter Name
DATABASE_
HOSTNAME
Applicable Upgrade
Approach
Data
Type
Are
Double
Quotes
Needed
for the
Values?
Applicable to 2-system
upgrade approach and
1-system upgrade approach
on a different host for
normal upgrade as well as
software-only upgrade.
String
Yes
Description
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.
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade.
Therefore, comment out
this parameter for this
approach.
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.
LISTENER_PORT
Applicable to 2-system
upgrade approach and
1-system upgrade approach
on a different host for
normal upgrade as well as
software-only upgrade.
String
Yes
Enter the other nodes for the variable EM_RESPOS_
CONNECTDESCRIPTOR.
Enter the listener port to connect to the existing
database.
For example, "1532".
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade.
Therefore, comment out
this parameter for this
approach.
SERVICENAME_
OR_SID
Applicable to 2-system
upgrade approach and
1-system upgrade approach
on a different host for
normal upgrade as well as
software-only upgrade.
String
Yes
Enter the service name or the system ID (SID) of the
existing database.
For example, "orcl".
Not applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade.
Therefore, comment out
this parameter for this
approach.
SYS_PASSWORD
Applicable to all upgrade
approaches for normal
upgrade as well as
software-only upgrade.
String
Yes
Enter the SYS user account's password.
Editing the Response File for Upgrading Oracle Management Service and Oracle Management Repository
Mode
in Silent
A-9
Table A–1
(Cont.) Editing Parameters of the upgrade.rsp File for Upgrading OMS in Silent Mode
Applicable Upgrade
Approach
Data
Type
Are
Double
Quotes
Needed
for the
Values?
SYSMAN_
PASSWORD
Applicable to all upgrade
approaches for normal
upgrade as well as
software-only upgrade.
String
Yes
Enter the SYSMAN user account’s password.
REPOSITORY_
BACKUP_DONE
Applicable to 1-system
upgrade approach for
normal upgrade as well as
software-only upgrade.
Boolean
No
As a prerequisite, you must back up the Management
Repository before you start upgrading your Enterprise
Manager system. If you have taken a backup, then set
this parameter to TRUE. Otherwise, set it to FALSE
Parameter Name
Not applicable to 2-system
upgrade approach and
1-system upgrade approach
on a different host for
normal upgrade as well as
software-only upgrade.
A-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
Description
Table A–1 (Cont.) Editing Parameters of the upgrade.rsp File for Upgrading OMS in Silent Mode
Parameter Name
PLUGIN_
SELECTION
Applicable Upgrade
Approach
Data
Type
Applicable to all upgrade
approaches for normal
upgrade as well as
software-only upgrade.
String
List
Are
Double
Quotes
Needed
for the
Values?
Yes
(A
comma-se
parated
list of
plug-in
names,
where the
plug-in
names
must be in
double
quotes)
Description
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, Oracle Exadata
Management Plug-In, and Oracle Cloud Framework
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.
Access the following Enterprise Manager
download page on Oracle Technology Network
(OTN):
http://www.oracle.com/technetwork/oem/grid
-control/downloads/oem-upgrade-console-502
238.html
2.
Expand the section that lists the software binaries
and plug-ins for your upgrade path.
3.
From the Download Plug-ins section, manually
download the plug-ins and store them in an
accessible location.
4.
Update this variable (PLUGIN_SELECTION) to
the names of those plug-ins you downloaded.
5.
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 4 (12.1.0.4). 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 4 (12.1.0.4). After you upgrade, you can
deploy the higher version directly from the Plug-In
Manager.
Editing the Response File for Upgrading Oracle Management Service and Oracle Management Repository
Modein Silent
A-11
A-12 Oracle Enterprise Manager Cloud Control Upgrade Guide
B
Overview of the Notification System in
Enterprise Manager Cloud Control
B
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).
Note:
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:
■
About Events, Incidents, and Incident Rulesets
■
Accessing Incident Rulesets in Enterprise Manager 12c
■
■
Notification Rules Migrated to Incident Rulesets After Upgrading to Enterprise
Manager 12c
Notification Methods and Actions After Upgrading to Enterprise Manager 12c
B.1 About 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.
Overview of the Notification System in Enterprise Manager Cloud Control
B-1
Accessing Incident Rulesets in Enterprise Manager 12c
■
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.
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.
For more information about events, incidents, and incident
rulesets, see the Oracle Enterprise Manager Cloud Control Administrator’s
Guide.
Note:
B.2 Accessing Incident Rulesets in Enterprise Manager 12c
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:
B-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Notification Rules Migrated to Incident Rulesets After Upgrading to Enterprise Manager 12c
Figure B–1 Viewing Incident Rulesets
B.3 Notification Rules Migrated to Incident Rulesets After Upgrading to
Enterprise Manager 12c
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
Overview of the Notification System in Enterprise Manager Cloud Control
B-3
Notification Methods and Actions After Upgrading to Enterprise Manager 12c
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.
For situations where the target type modeling has changed in
Enterprise Manager Cloud Control, you must manually adjust the
rules as described in Section 12.6.8.
Note:
B.4 Notification Methods and Actions After Upgrading to Enterprise
Manager 12c
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.
The OS commands, and the PL/SQL and SNMP Trap
notification methods created in the pre-12c version will have the Event
Compatible column set to No on the Notification Methods page. To
access this page, from the Setup menu, select Notifications, then
select Notification Methods.
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. For instructions, see Oracle Enterprise Manager
Cloud Control Administrator’s Guide.
Note:
B-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
C
Overview of the Metric Changes in Enterprise
Manager Cloud Control
C
This appendix describes the changes to the metrics of the following targets:
■
Changes to Oracle SOA Infrastructure Metrics in Enterprise Manager Cloud
Control
■
Changes to Oracle SOA Composite Metrics in Enterprise Manager Cloud Control
■
Changes to Oracle Service Bus Metrics in Enterprise Manager Cloud Control
■
Changes to Oracle WebLogic Server Metrics in Enterprise Manager Cloud Control
■
Changes to JBoss Application Server Metrics in Enterprise Manager Cloud Control
■
Changes to Siebel Enterprise Metrics in Enterprise Manager Cloud Control
■
Changes to Siebel Server Metrics in Enterprise Manager Cloud Control
C.1 Changes to Oracle SOA Infrastructure Metrics in Enterprise Manager
Cloud Control
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 12.
C.2 Changes to Oracle SOA Composite Metrics in Enterprise Manager
Cloud Control
The following are the changes to the metrics related to Oracle SOA Composite:
Overview of the Metric Changes in Enterprise Manager Cloud Control
C-1
Changes to Oracle Service Bus Metrics in Enterprise Manager Cloud Control
■
■
■
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.
C.3 Changes to Oracle Service Bus Metrics in Enterprise Manager Cloud
Control
■
■
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.
C.4 Changes to Oracle WebLogic Server Metrics in Enterprise Manager
Cloud Control
■
■
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
C-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Changes to Siebel Enterprise Metrics in Enterprise Manager Cloud Control
■
■
■
■
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.
C.5 Changes to JBoss Application Server Metrics in Enterprise Manager
Cloud Control
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.
C.6 Changes to Siebel Enterprise Metrics in Enterprise Manager Cloud
Control
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.
Overview of the Metric Changes in Enterprise Manager Cloud Control
C-3
Changes to Siebel Server Metrics in Enterprise Manager Cloud Control
C.7 Changes to Siebel Server Metrics in Enterprise Manager Cloud
Control
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
C.7.1 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
To do so, in Cloud Control, from the Setup menu, select Security, and
Credentials for Siebel then, click Preferred Credentials. On the Preferred Credentials page,
Server
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.
C.7.2 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.
C-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Changes to Siebel Server Metrics in Enterprise Manager Cloud Control
Server Manager
To do so, in Cloud Control, from the Setup menu, select Security, and
Credentials for Siebel then, click Preferred Credentials. On the Preferred Credentials page,
Gateway Server
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.
C.7.3 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.
Overview of the Metric Changes in Enterprise Manager Cloud Control
C-5
Changes to Siebel Server Metrics in Enterprise Manager Cloud Control
C-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
D
Identifying the Jobs That Will Not Run in
Enterprise Manager for 2-System Upgrade
Approach
D
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 the Jobs That Will Not Run in the New, Upgraded Enterprise Manager
System
Identifying the Jobs That Will Not Run in the Existing Enterprise Manager System
D.1 Identifying the 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 3, "Things to Know
About Upgrading an Enterprise Manager System"
SET
SET
SET
SET
TRIMSPOOL ON
VERIFY
OFF
LINESIZE 80
PAGESIZE 500
PROMPT
PROMPT
PROMPT
PROMPT
PROMPT
PROMPT
======================
Valid on "new" 12.1 EM
======================
List jobs that will not be run on either system
due to a partially migrated target list
======================
WITH
-- list of migrated targets
migrated_targets AS
(
SELECT
target_guid
Identifying the Jobs That Will Not Run in Enterprise Manager for 2-System Upgrade Approach D-1
Identifying the Jobs That Will Not Run in the New, Upgraded Enterprise Manager System
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
*/
D-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Identifying the Jobs That Will Not Run in the Existing Enterprise Manager System
D.2 Identifying the 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 3, "Things to Know About Upgrading an
Enterprise Manager System"
SET
SET
SET
SET
TRIMSPOOL ON
VERIFY
OFF
LINESIZE 80
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)
Identifying the Jobs That Will Not Run in Enterprise Manager for 2-System Upgrade Approach D-3
Identifying the Jobs That Will Not Run in the Existing Enterprise Manager System
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)
D-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Identifying the Jobs That Will Not Run in the Existing Enterprise Manager System
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.example.com'));
but DO NOT COMMIT
rollback when done.
*/
Identifying the Jobs That Will Not Run in Enterprise Manager for 2-System Upgrade Approach D-5
Identifying the Jobs That Will Not Run in the Existing Enterprise Manager System
D-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
E
Updating Server Load Balancer Configuration
Settings
E
If you have a Server Load Balancer (SLB) configured, make the changes described in
Table E–1 to your monitors.
The HTTPS and HTTP ports you must associated with can be
found by running the following command:
Note:
$<OMS_HOME>/bin/emctl status oms -details
Table E–1
SLB-Specific Configuration Changes to SLB Monitors
Monitor Name
Configuration
Type
Associate With
Interval
Timeout
Send String
Receive String
mon_emcc_
https
secure_
upload<https_
port>
60
181
GET
/empbs/uplo
ad
Http Receiver
Servlet active!
mon_emcc_
unsecure_
agent_
reg<http_
port>
(optional)
60
http
181
HostA:<https_upload_
port>
HostB:<https_upload_
port>
GET
GenWallet
/empbs/genw Servlet
allet
activated
HostA:<http_upload_
port>
HostB:<http_upload_
port>
mon_emcc_
https
secure_
console<https_
console_port>
5
16
GET
Enterprise
/em/consoleS Manager
tatus.jsp
Console is UP
HostA:<https_upload_
port> HostB:<https_
upload_port>
mon_emcc_
unsecure_
console<http_
console_port>
(optional)
5
16
GET
Enterprise
/em/consoleS Manager
tatus.jsp
Console is UP
HostA:<http_upload_
port>
http
HostB:<http_upload_
port>
Some Load Balancers require <CR><LF> characters to be
added explicitly to the Send String using literal "\r\n". This is
vendor-specific. Refer to your SLB documentation for details.
Note:
Updating Server Load Balancer Configuration Settings E-1
E-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
F
Setting Preferred Credentials Using EM CLI
F
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"
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.
Note:
Setting Preferred Credentials Using EM CLI F-1
F-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
G
Moving the Central Agent Base Directory
Outside Oracle Middleware Home
G
When you upgrade Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2) or 12c
Release 3 (12.1.0.3) to 12c Release 4 (12.1.0.4), and upgrade the central agent (that is,
the Management Agent deployed on the OMS host) to 12.1.0.4, the agent base
directory of the upgraded central agent may reside within the old Oracle Middleware
home. This appendix describes how to move the agent base directory of a 12.1.0.4
central agent outside the Oracle Middleware home.
If a central agent was upgraded to 12.1.0.2 or 12.1.0.3 from 12.1.0.1, and then upgraded
to 12.1.0.4, the agent base directory of the central agent will reside within the Oracle
Middleware home, and you can choose to move it to a different location. However, if a
central agent of version 12.1.0.2 or 12.1.0.3 was newly installed, or upgraded from
12.1.0.2 (in the case of a 12.1.0.3 central agent), and then upgraded to 12.1.0.4, the agent
base directory of the central agent resides outside the Oracle Middleware home by
default. Note that moving the agent base directory of a central agent outside the
Oracle Middleware home is a one-time activity. Once the agent base directory of a
central agent is moved outside the Oracle Middleware home, it remains at the same
location even after subsequent upgrades.
If a central agent was upgraded to 12.1.0.2 (from 12.1.0.1) or 12.1.0.3 (from 12.1.0.1 or
12.1.0.2), and you want to move the agent base directory of the central agent outside
the Oracle Middleware home, then follow the instructions outlined in the My Oracle
Support note 1520010.1.
If you want to move the agent base directory of a 12.1.0.4 central agent (which was
initially of version 12.1.0.1, then upgraded to 12.1.0.2 or 12.1.0.3, and finally upgraded
to 12.1.0.4) to a location outside the Oracle Middleware home, follow these steps:
Important:
■
■
1.
Moving the agent base directory is recommended only for the
central agent, and not for the other Management Agents.
Moving the agent base directory is not supported on a host that is
running on Microsoft Windows.
Set the $OLD_AGENT_HOME environment variable to location of the current
Management Agent home (which is within the Oracle Middleware home):
export OLD_AGENT_HOME=<location_of_current_agent_home>
For example, run export OLD_AGENT_
HOME=/u01/app/oracle/Middleware/agent/core/12.1.0.4.0/
Moving the Central Agent Base Directory Outside Oracle Middleware Home G-1
2.
Delete the backup* directory present within the central agent base directory. If
multiple backup* directories are present within the central agent base directory,
ensure that you delete all of them.
3.
Run the following command from the current Management Agent home to
migrate the agent base directory:
$OLD_AGENT_HOME/perl/bin/perl $OLD_AGENT_HOME/sysman/install/AgentMigrate.pl
-oldAgentBaseDir <current_location_of_agent_base_dir> -newAgentBaseDir <new_
location_of_agent_base_dir> -oldOracleHome <current_location_of_agent_home>
-newOracleHome <new_location_of_agent_home> -agentInstanceHome <current_
location_of_agent_instance_home>
-oldAgentBaseDir specifies the current location of the agent base directory.
-newAgentBaseDir specifies the location to which you want to migrate the agent
base directory.
-oldOracleHome specifies the current location of the Management Agent home.
-newOracleHome specifies the location to which you want to migrate the
Management Agent home.
-agentInstanceHome specifies the current location of the Management Agent
instance home.
For example, if you want to move the central agent base directory from
/u01/app/oracle/Middleware/agent/core/12.1.0.4.0 to
/u01/app/oracle/agent/core/12.1.0.4.0, run the following command:
/u01/app/oracle/Middleware/agent/core/12.1.0.4.0/perl/bin/perl $OLD_AGENT_
HOME/install/AgentMigrate.pl -oldAgentBaseDir /u01/app/oracle/Middleware/agent
-newAgentBaseDir /u01/app/oracle/agent -oldOracleHome
/u01/app/oracle/Middleware/agent/core/12.1.0.4.0 -newOracleHome
/u01/app/oracle/agent/core/12.1.0.4.0 -agentInstanceHome
/u01/app/oracle/Middleware/agent/agent_inst
After you move the central agent base directory, you will be prompted to delete
the old Management Agent home.
4.
5.
Switch to the Cloud Control console. In Cloud Control, perform the following
steps to verify whether the migration was successful:
1.
From the Targets menu, select All Targets. Select the central agent target. On
the Management Agent home page, in the Summary section, verify the Oracle
home path and the agent state directory path. Ensure that both these paths
point to the new locations.
2.
Access the home pages of the targets monitored by the central agent. Check
the status of these targets. Ensure that they are up and running.
Switch back to the command prompt. Confirm that you want to delete the old
Management Agent home.
G-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
H
Searching and Adding Oracle Management
Agents
H
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.
Searching and Adding Oracle Management Agents H-1
H-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
I
Securing Oracle Management Agents After
Backing Up Oracle Management Repository
I
Before you deploy and configure Oracle Management Agents 12c (Management
Agent) as described in Section 10.1, 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 Section 10.4.
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;
Securing Oracle Management Agents After Backing Up Oracle Management Repository I-1
I-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
J
Recovering Oracle Database 11.1.0.7 or
10.2.0.5 from Microsoft Windows 32-bit Host to
Microsoft Windows 64-bit Host
J
This appendix describes how you can recover the backed up Oracle Database 11g
Release 1 (11.1.0.7) or 10g Release 2 (10.2.0.5) from Microsoft Windows 32-bit to
Microsoft Windows 64-bit. This appendix is based on the following 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 (21) of Section J.2, follow the
steps mentioned in Note [ID 386990.1].
This appendix contains the following sections:
■
■
■
Steps to Perform on the Source Host (Microsoft Windows 32-bit) for Recovering
Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to
Microsoft Windows 64-bit Host
Steps to Perform on the Destination Host (Microsoft Windows 64-bit) for
Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit
Host to Microsoft Windows 64-bit Host
Final Steps to Perform for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from
Microsoft Windows 32-bit Host to Microsoft Windows 64-bit
J.1 Steps to Perform on the Source Host (Microsoft Windows 32-bit) for
Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows
32-bit Host to Microsoft Windows 64-bit Host
To recover the backed up Oracle Database 11g Release 1 (11.1.0.7) or 10g Release 2
(10.2.0.5) from Microsoft Windows 32-bit to Microsoft Windows 64-bit, follow these
steps on source host:
1.
Access the database home <DB_HOME>\bin\sqlplus /NOLOG
2.
Run the following command:
SQL> CONNECT / AS SYSDBA :
Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft Windows
Host64-bit
J-1
Steps to Perform on the Source Host (Microsoft Windows 32-bit) for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from
Note:
■
■
If you are using Oracle Database 10g Release 2 (10.2.0.5):
Access <DB HOME>/admin/<SID>/udump, and make a backup of this
in your local system.
Run the following command:
<OMS_HOME>\bin>
emctl config emkey -copy_to_repos -sysman_pwd <sysman_
password>
For example:
C:\Oracle\Middleware\oms\BIN>emctl config emkey -copy_to_
repos -sysman_pwd Welcome1
3.
Run the following command:
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
Note:
■
■
If you are using Oracle Database 10g Release 2 (10.2.0.5), 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 that will be
performed later on the destination host on Microsoft Windows
64-bit.
If you are using Oracle Database 11g Release 1 (11.1.0.7) 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).
5.
Run the following commands:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
J-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Steps to Perform on the Destination Host (Microsoft Windows 64-bit) for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from
J.2 Steps to Perform on the Destination Host (Microsoft Windows 64-bit)
for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft
Windows 32-bit Host to Microsoft Windows 64-bit Host
To recover Oracle Database 11g Release 1 (11.1.0.7) or 10g Release 2 (10.2.0.5) from
Microsoft Windows 32-bit to Microsoft Windows 64-bit, follow these steps on the
destination host:
1.
Perform a software-only installation of the Oracle Database software on the
computer.
Ensure that the database being installed has the same path as
the database on the source host that is on Microsoft Windows 32-bit.
This ensures speedy recovery.
Note:
2.
Copy the entire <DB_Base>\oradata directory from Microsoft Windows 32-bit
source host to the <DB_Base>\ directory of Microsoft Windows 64-bit destination
host.
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
For example:
C:\DB\db\BIN>oradim.exe -new -sid orcl -maxusers 3 -startmode auto -pfile
C:\DB\db\database\initorcl.ora
Note:
■
■
MAXUSERS may not work with Oracle Database 10g Release 2
(10.2.0.5).
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 Microsoft Windows 32-bit source
host to the <DB_Base>\ directory of Microsoft Windows 64-bit destination host.
5.
Copy the entire <DB_Base>\fast_recovery_area directory from Microsoft
Windows 32-bit source host to the <DB_Base>\ directory of Microsoft Windows
64-bit destination host.
6.
Copy <DBHOME>\database\*.* files from Microsoft Windows 32-bit source host to
the <DBHOME>\database\ directory of Microsoft Windows 64-bit destination host.
If you are using Oracle Database 10g Release 2 (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:
Note:
C:\DB\db\dbs\SPFILEORCL.ORA
7.
Set the following environment variables:
Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft Windows
Host64-bit
J-3
Steps to Perform on the Destination Host (Microsoft Windows 64-bit) for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from
8.
■
set ORACLE_HOME=<DB_home>
■
set ORACLE_SID=<SID>
Access the DB_HOME\rdbms\admin directory.
If you cannot find sqlplus inside this, then go to <DB_
HOME>\bin
Note:
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 Oracle Database 10g Release 5 (10.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';
■
If you are using Oracle Database 11g Release 1 (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.
J-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Steps to Perform on the Destination Host (Microsoft Windows 64-bit) for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from
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 Step (3) of Section J.1. Perform
Step (15), Step (16), and Step (17) 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_deepdive.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;
Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft Windows
Host64-bit
J-5
Steps to Perform on the Destination Host (Microsoft Windows 64-bit) for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from
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;
J-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
Steps to Perform on the Destination Host (Microsoft Windows 64-bit) for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from
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
If you are using sqlplus from <DB_HOME>\bin\ then, run
the following command:
Note:
SQL> @ <DB_HOME>\RDBMS\ADMIN\utlrp.sql
or
SQL> @ ?/RDBMS/ADMIN?utlrp.sql
If it succeeds, then continue to Step (28). Otherwise, if you receive an error, do the
following:
a.
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.
b.
Remove olap by running the following commands:
SQL>
@?/olap/admin/catnoamd.sql
If you get an error related to files not found then, for each of
those files, use the following command:
Note:
SQL>@C:\DB\db\olap\admin\<filename>.sql;
However, even if you receive errors, you can just continue.
Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft Windows
Host64-bit
J-7
Final Steps to Perform for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft
SQL> @?/olap/admin/catnoaps.sql
SQL> @?/olap/admin/olapidrp.plb
c.
Add olap by running the following commands:
SQL> connect SYS as SYSDBA
SQL> spool olap.log
SQL> @?/olap/admin/olap.sql SYSAUX TEMP;
d.
Reenter the following command:
SQl> @utlrp.sql
: If you are using sqlplus from <DB_HOME>\bin\ then, run
the following command:
Note:
SQL> @ <DB_HOME>\RDBMS\ADMIN\utlrp.sql
or
SQL> @ ?/RDBMS/ADMIN?utlrp.sql
e.
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;
J.3 Final Steps to Perform for Recovering Oracle Database 11.1.0.7 or
10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft Windows 64-bit
To finalize the process, do the following:
J.3.1 Final Steps to Perform on the Microsoft Windows 32-bit Host for Recovering
Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft
Windows 64-bit Host
On the Microsoft Windows 32-bit source host, do the following:
J-8 Oracle Enterprise Manager Cloud Control Upgrade Guide
Final Steps to Perform for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft
1.
Access <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\oms\BIN>emctl config emkey -remove_from_repos
3.
Access <DB_HOME>\bin.
sqlplus "/as sysdba"
shutdown immediate;
startup;
J.3.2 Final Steps to Perform on the Microsoft Windows 64-bit Host for Recovering
Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft
Windows 64-bit Host
On Microsoft Windows 64-bit destination host, 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;
J.3.3 Troubleshooting Issues with Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from
Microsoft Windows 32-bit Host to Microsoft Windows 64-bit Host
If you still face any issues, follow these steps:
Note:
1.
These steps have been tested with Database 10.2.0.5.
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:
Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft Windows
Host64-bit
J-9
Final Steps to Perform for Recovering Oracle Database 11.1.0.7 or 10.2.0.5 from Microsoft Windows 32-bit Host to Microsoft
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = host.example.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl.example.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)
J-10 Oracle Enterprise Manager Cloud Control Upgrade Guide
K
Deleting the Old OMS Home
K
This chapter describes how you can delete the old OMS home after upgrading from
12c Release 3 (12.1.0.3) or 12c Release 2 (12.1.0.2) to 12c Release 4 (12.1.0.4). In
particular, this chapter covers the following:
■
Deinstalling the Old OMS Home in Graphical Mode
■
Deinstalling the Old OMS Home in Silent Mode
K.1 Deinstalling the Old OMS Home in Graphical Mode
To deinstall the old OMS home in graphical mode, follow these steps:
IMPORTANT:
1.
Deinstall the components in the order described in this procedure.
Otherwise, the installation wizard displays an error.
2.
Ensure that you do NOT remove the Management Agent that is present
in the old middleware home.
For information on moving the agent base directory of this
Management Agent (that is, the central agent) outside the old
Oracle Middleware home, refer the My Oracle Support note
1520010.1.
1.
Invoke the installer from the OMS home by running the following command:
$<OMS_HOME>/oui/bin/runInstaller -deinstall [-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.
Deleting the Old OMS Home
K-1
Deinstalling the Old OMS Home in Graphical Mode
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 /stage, which a subdirectory in the Disk1 directory of the
Enterprise Manager software.
Note:
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.
On the Inventory screen, select only the OMS-related plug-in homes, and click
Remove.
Caution: Make sure you have selected only the OMS-related plug-in
homes, and not any agent-related plug-ins.
3.
On the Inventory screen, select the Java Development Kit (JDK) home, and click
Remove.
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:
Note:
1.
Manually download and install JDK 1.6.0.43.0 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>]
4.
On the Inventory screen, select the Oracle WebTier home, and click Remove.
5.
On the Inventory screen, select the following, and click Remove.
■
OMS home
■
Oracle Common directory
If BI publisher was installed in the prior version of Enterprise
Manager, also select the BI publisher Oracle home (Oracle_BI1).
Note:
K-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Deinstalling the Old OMS Home in Silent Mode
6.
On the Inventory screen, click Close to exit the wizard.
K.2 Deinstalling the Old OMS Home in Silent Mode
To deinstall the old OMS home in silent mode, follow these steps:
IMPORTANT:
1.
Deinstall the components in the order described in this procedure.
Otherwise, the installation wizard displays an error.
2.
Ensure that you do NOT remove the Management Agent that is present
in the old middleware home.
For information on moving the agent base directory of this
Management Agent (that is, the central agent) outside the old
Oracle Middleware home, refer the My Oracle Support note
1520010.1.
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,
Deleting the Old OMS Home
K-3
Deinstalling the Old OMS Home in Silent Mode
$<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
Deinstall JDK only if it was installed by the installation wizard
while installing the Enterprise Manager system. Otherwise, you can
skip this step.
Note:
3.
Manually download and install JDK 1.6.0.43.0 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_and_bip_
home_to_be_deinstalled}" -jreLoc <JDK_HOME> ORACLE_HOME=<absolute_path_
to_oms_home> [-removeAllFiles] [-invPtrLoc <absolute_path_to_
oraInst.loc>]
The argument REMOVE_HOMES accepts more than one path
separated by a comma.
Note:
For example, in this scenario, BI Publisher had been installed and is now being
deinstalled.
$<OMS_HOME>/oui/bin/runInstaller -deinstall -silent "REMOVE_
HOMES={/home/oracle/middleware/oms,/home/oracle/middleware/oracle_
common,/home/oracle/middleware/Oracle_BI1}" -jreLoc </home/oracle/jdk>
ORACLE_HOME=/home/oracle/middleware/oms -removeAllFiles -invPtrLoc
/home/oracle/oraInst.loc
K-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
L
Correcting the Database Domain Name to
Avoid or Resolve Database Link Error
L
If your database domain name has any characters other than A-Z (letters), 0-9
(numerals), _ (underscore), # (hash), $ (dollar),. (period), or @ (at the rate), then the
Run Presync step of the switchover operation might fail, and you will see the following
error in the emoms.trc trace file. For example, a database domain name with a hyphen
(-) can result in this issue.
ORA-20000: Found exception Error Message :ORA-02083: database name has illegal
character '-' Error Number ;-2083
This appendix describes how you can circumvent this error if you have not already
started your upgrade, and how you can work around this error if you have already
started the upgrade and if you are seeing an error on the Create Upgraded Oracle
Management Repository Link page.
In particular, this section covers the following:
■
■
Avoiding the Database Link Error Before Starting the Upgrade Process
Resolving the Database Link Error That Appears While the Upgrade Process Is in
Progress
L.1 Avoiding the Database Link Error Before Starting the Upgrade
Process
To circumvent the database link issue, as a prerequisite, follow these steps:
1.
Run the following SQL commands as SYS user on the old as well as the new
Management Repository:
a.
Verify the domain name:
show parameters db_domain;
b.
If the domain name has any characters other than A-Z (letters), 0-9 (numerals),
_ (underscore), # (hash), $ (dollar),. (period), or @ (at the rate), for example, a '-'
(hyphen), then change the domain name.
alter system set db_domain='<domain_name_with_illegal_char_
replaced_with_legal_char>' scope=spfile sid='*';
c.
Verify the service name:
show parameters service_names;
Correcting the Database Domain Name to Avoid or Resolve Database Link Error L-1
Resolving the Database Link Error That Appears While the Upgrade Process Is in Progress
d.
If the service name has any characters other than A-Z (letters), 0-9 (numerals),
_ (underscore), # (hash), $ (dollar),. (period), or @ (at the rate), for example, a '-'
(hyphen), then change the service name.
alter system set service_names='service_name_with_illegal_char_
replaced_with_legal_char' scope=both sid='*';
e.
Verify the global name:
select * from global_name;
f.
If the global name has any characters other than A-Z (letters), 0-9 (numerals), _
(underscore), # (hash), $ (dollar),. (period), or @ (at the rate), for example, a '-'
(hyphen), then change global name.
alter database rename GLOBAL_NAME to "global_name_with_illegal_
char_replaced_with_legal_char";
2.
Update the SERVICE_NAME value with the changed or corrected service name in the
following files:
$<DB_HOME>/network/admin/listener.ora
$<DB_HOME>/network/admin/tnsnames.ora
3.
Perform these steps on the old as well as the new OMS:
a.
Verify the connect descriptor for OMS:
$<OMS_HOME>/bin/emctl config oms -list_repos_details
b.
If the service name in the connect descriptor has any characters other than A-Z
(letters), 0-9 (numerals), _ (underscore), # (hash), $ (dollar),. (period), or @ (at
the rate), for example, a '-' (hyphen), then change the connect descriptor.
$<OMS_HOME>/bin/emctl config oms -store_repos_details -repos_
conndesc '(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL =
TCP)(HOST = example.com)(PORT = 1521)))(CONNECT_DATA = (SERVICE_
NAME = service_name_with_illegal_char_replaced_with_legal_char)))'
-repos_user sysman
c.
Restart the OMS.
$<OMS_HOME>/bin/emctl stop oms -all
$<OMS_HOME>/bin/emctl start oms
4.
Restart the database:
SQL>shutdown immediate;
SQL>start the database
L.2 Resolving the Database Link Error That Appears While the Upgrade
Process Is in Progress
To resolve the database link issue if you see an error on the Create Link to Upgraded
Repository page of the Preupgrade Console, run the following commands as SYS user:
1.
Drop the database link:
■
If the database link is already created in the old repository, run the following
command:
drop public database link PREUPGTO_NG_LINK;
L-2 Oracle Enterprise Manager Cloud Control Upgrade Guide
Resolving the Database Link Error That Appears While the Upgrade Process Is in Progress
■
If the database link is already created in the new repository, run the following
command:
drop public database link PREUPG_EMREPO_LINK;
2.
Run the following SQL commands as SYS user on the old as well as the new
Management Repository:
a.
Verify the domain name:
show parameters db_domain;
b.
If the domain name has any characters other than A-Z (letters), 0-9 (numerals),
_ (underscore), # (hash), $ (dollar),. (period), or @ (at the rate), for example, a '-'
(hyphen), then change the domain name.
alter system set db_domain='domain_name_with_illegal_char_replaced_
with_legal_char' scope=spfile sid='*';
c.
Verify the service name:
show parameters service_names;
d.
If the service name has any characters other than A-Z (letters), 0-9 (numerals),
_ (underscore), # (hash), $ (dollar),. (period), or @ (at the rate), for example, a '-'
(hyphen), then change the service name.
alter system set service_names='service_name_with_illegal_char_
replaced_with_legal_char' scope=both sid='*';
e.
Verify the global name:
select * from global_name;
f.
If the global name has any characters other than A-Z (letters), 0-9 (numerals), _
(underscore), # (hash), $ (dollar),. (period), or @ (at the rate), for example, a '-'
(hyphen), then change global name.
alter database rename GLOBAL_NAME to "global_name_with_illegal_
char_replaced_with_legal_char";
3.
Update the SERVICE_NAME value with the changed/corrected service name in
the following files:
$<DB_HOME>/network/admin/listener.ora
$<DB_HOME>/network/admin/tnsnames.ora
4.
Perform these steps on the old as well as the new OMS:
a.
Verify the connect descriptor for OMS:
For 11g and 12c OMS, run the following command:
$<OMS_HOME>/bin/emctl config oms -list_repos_details
For 10g OMS, open the emoms.properties file.
b.
If the service name in the connect descriptor has any characters other than A-Z
(letters), 0-9 (numerals), _ (underscore), # (hash), $ (dollar),. (period), or @ (at
the rate), for example, a '-' (hyphen), then change the connect descriptor.
For 11g and 12c OMS, run the following command:
$<OMS_HOME>/bin/emctl config oms -store_repos_details -repos_
conndesc '(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL =
TCP)(HOST = example.com)(PORT = 1521)))(CONNECT_DATA = (SERVICE_
Correcting the Database Domain Name to Avoid or Resolve Database Link Error L-3
Resolving the Database Link Error That Appears While the Upgrade Process Is in Progress
NAME = service_name_with_illegal_char_replaced_with_legal_char)))'
-repos_user sysman
For 10g OMS, edit the connect descriptor directly in the emoms.properties
file, and save the file.
c.
Restart the OMS:
$<OMS_HOME>/bin/emctl stop oms -all
$<OMS_HOME>/bin/emctl start oms
5.
Restart the database:
SQL>shutdown immediate;
SQL>start the database
6.
Create or re-create the database link from the Create Link to Upgraded Repository
page of the Preupgrade Console. For instructions, see Section 12.2.
7.
Create the database link in the new Management Repository.
a.
Verify the global names parameter:
show parameters global_names;
If global_names is set to FALSE, then use the database link name PREUPG_
EMREPO_LINK.If it is set to TRUE, then use the database link name <value_of_
"select * from global_name"_from_the_old_Management_Repository>.
Run the following command to use the database link:
CREATE PUBLIC DATABASE LINK <db_link_name> CONNECT TO SYSMAN
IDENTIFIED BY welcome1 using '(DESCRIPTION=(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1521)))(CONNECT
_DATA=(SID=orcl)))';
b.
Update the database link name in the new Management Repository:
UPDATE sysman.MGMT_UPGRADEUTIL_PROPS SET property_value='<db_link_
name>' WHERE property_name = 'PREUPG_EMREPO_DBLINK_NAME'
8.
Verify the database link in the old as well as the new Management Repository:
■
Run the following SQL commands on the old Management Repository:
DECLARE
l_count number;
begin
select count(*) into l_count from mgmt_targets@PREUPGTO_NG_LINK;
end;
/
■
Run the following SQL commands on the new Management Repository:
DECLARE
l_count number;
begin
select count(*) into l_count from mgmt_targets@<db_link_name>;
end;
L-4 Oracle Enterprise Manager Cloud Control Upgrade Guide
Resolving the Database Link Error That Appears While the Upgrade Process Is in Progress
/
Correcting the Database Domain Name to Avoid or Resolve Database Link Error L-5
Resolving the Database Link Error That Appears While the Upgrade Process Is in Progress
L-6 Oracle Enterprise Manager Cloud Control Upgrade Guide
M
Reviewing Log Files Related to the Upgrade of
an Enterprise Manager System
M
Table M–1 lists the log files to be reviewed for various upgrade operations.
Table M–1
Log Files to Review for Various Upgrade Operations
Upgrade Operation
Console Name
Log Files to Review
Agent Health Check and
Startup
Preupgrade
Console1
Review the gcagent.log file in the following
location of the 12c Management Agent:
$<AGENT_INSTANCE_
DIR>/sysman/log/gcagent.log
Agent Deployment and
Configuration
Jobs
(Agent Deployment and
Configuration Jobs, Health
Check Jobs, Switchover Jobs)
Preupgrade
Console
Preupgrade
Console
Review the log files in the following locations of
the 12c Management Agent:
■
$<AGENT_BASE_
DIR>/core/<version>/cfgtoollogs/agent
Deploy/
■
$<AGENT_BASE_
DIR>/core/<version>/cfgtoollogs/cfgfw
/
Review the job output logs. To do so, follow
these steps:
1.
Go to the Jobs page.
2.
Search for the job name.
3.
Click the job name, and then click on each
step name to view the output logs for each
step.
Plug-In Deployment
Agent Upgrade
(While upgrading
Console
Management Agents using
the Agent Upgrade Console)
To troubleshoot plug-in deployment issues,
review the log files in the following location of
the 12c Management Agent:
Ping Tests
Review the gcagent.log file in the following
location of the 12c Management Agent:
Preupgrade
Console
$<AGENT_INSTANCE_DIR>/install/logs/
$<AGENT_INSTANCE_
DIR>/sysman/log/gcagent.log
1
Preupgrade Console is essentially the Enterprise Manager 12c Upgrade Console accessed from the earlier
release of Enterprise Manager.
Reviewing Log Files Related to the Upgrade of an Enterprise Manager System
M-1
M-2
Oracle Enterprise Manager Cloud Control Upgrade Guide
Index
Numerics
1-system upgrade approach
default ports assigned, 3-6
in graphical mode, 11-2
in silent mode, 11-23
installing software-only
in graphical mode, 11-26, 11-32, 11-40, 11-41
overview, 2-8
process, 8-1, 8-21
using Oracle Software Library, 3-10
1-system upgrade approach on a different host
in graphical mode, 11-44
overview, 2-8
using Oracle Software Library, 3-10
2-system upgrade approach
default ports assigned, 3-6
in graphical mode, 11-11
in silent mode, 11-23
process, 8-9
A
accrued data, 12-26
accrued data migration, 12-25
accrued data migration jobs
migrating ECM history data, 12-26
overview, 12-25
tracking, 12-27
alerts, 3-12
closed alerts, 3-12
creating incidents and events, 3-13
migration methods, 3-12
open alerts
creating incidents and events, 3-13
migration, 3-12
allroot.sh script, 5-12, 11-10
Application Dependency and Performance, 8-6,
8-12, 8-25, 8-27
C
central inventory, 9-8
commands
Enterprise Manager commands
deinstalling in GUI mode, K-1, K-2
deinstalling in silent mode, K-4
configuration assistants, 2-7, 2-18, 2-20, 2-22
connectors, 3-11
critical data migration, 12-23
D
data format migration, 12-23
database
backing up database, 8-14
backing up with DBCA, 8-14
providing repository backup details, 9-13
database upgrade, 3-3
deferred data migration jobs
deferred data migration, 12-23
overview, 12-23
tracking, 12-24
deploy operations, 2-17
deployment procedures, 2-10, 8-5, 8-11, 8-24
destination host, J-1
diff reports
generating and viewing, 12-28
overview, 12-28
downtime
minimum or zero downtime, 2-9
reasonable, 2-9
reasonable downtime, 2-9
E
EM CLI, F-1
EM CLI clients, 3-16
EM_UPLOAD_HTTP_PORT parameter, 9-2
EM_UPLOAD_HTTPS_PORT parameter, 9-2
emgc.properties file, 9-2
emkey, 4-7, 8-16
copying
before upgrading OMS, 8-7, 8-26
before uprading OMS, 8-13
handling errors, 8-8, 8-18
removing emkey from the repository, 8-16
verifying if emkey is copied, 8-26
verifying whether emkey is copied, 8-7, 8-13
Enterprise Manager Cloud Control
supported upgrade paths,
3-2
Index-1
accessing preupgrade console, 2-12
deinstallation
silent mode, K-3
installation wizard, 2-4, 2-14
postupgrade console, 2-15
postupgrade steps, 12-9
preupgrade console, 2-11
supported platforms for upgrade, 3-3
upgrade approaches, 2-8
upgrade scope, 3-3
upgrade utilities, 2-11
upgrading multi-OMS environment, 11-59
Enterprise Manager Cloud Control Installation
Wizard, 2-4, 2-14
enterprise rulesets, B-2
events, 3-12, B-1
overview, B-1
default version installed, 3-4
manual download, 3-4
JDK, 2-17
jobs
1-system upgrade approach, 3-14
2-system upgrade approach, 3-14
aborted jobs, 3-14
jobs on multiple targets, 3-15
management, 3-14
repeating jobs, 2-11, 3-14, 3-15
running, 2-10
scheduled jobs, 2-11, 3-14
suspended jobs, 3-14
JROCKIT, 3-4
JVM Diagnostics, 8-6, 8-12, 8-25, 8-27
F
linux patching, 12-19
lockd account
using locked account,
locked account
power broker, 10-7
SUDO, 10-7
failed jobs, 3-14
firewall settings, 2-10, 3-6
G
gc_inst directory, 2-18
GCDomain, 2-18
H
health report, 10-9
generating, 10-9
signing off, 10-12
verifying, 10-12
I
identifying host for upgrade, 9-1
inactive targets, 12-29
incident rule sets
deleting rule sets, 12-18
incident rules, 12-14
deleting, 12-18
overview, 12-14
updating for moved metrics, 12-16
updating for renamed metrics, 12-17
Incident rulesets, B-1
incident rulesets, 3-12, 12-14, B-1
accessing, B-2
classification, B-2
migrating notification rules, B-3
incidents, B-1
overview, B-2
incidents and events, 3-13
installation base directory, 10-5
inventory.xml file, 9-8, 9-9
L
M
managed server, 2-18
management repository
creating link to upgraded repository, 12-3
managing software, 9-4
master agents, 10-5
metric changes, C-1
metric collection errors, 10-11, 12-19
metrics
changes, 12-14
collecting metrics, 3-16
decommissioned, 12-16
moved, 12-15
renamed, 12-15
renamed metrics, 3-16
retained, 12-15
migration activity, 12-23, 12-25
minimal monitoring loss, 2-1
missing agent or plug-in software, 9-10
multi-OMS environment, 9-2, 11-59
N
near-zero downtime, 2-1
node manager, 2-18
not supported, 9-9, 9-10
notification, 3-12
notification methods, B-4
notification rules, 3-12, 12-14, B-1
notifications, B-1
J
O
Java Development Kit, 2-17
default version, 2-19, 2-21
obsolete targets, 12-12
OCM scheduler, 12-11
Index-2
10-6
operation name, 10-4
Oracle JRF, 2-21
Oracle Management Agent
agent upgradability, 9-4
analyzing environment, 9-7
checking agent upgradability status, 9-9
configuring, 10-1
deploying, 10-1
generating health report, 10-9
manual download, 9-6
problematic agents, 9-11
reconfiguring, 10-9
target upgradability, 9-4
upgradable, 9-9
upgrade status, 12-7
upgrading
installing plug-ins, 3-9
with invalid inventory, 9-9
with valid inventory, 9-8
Oracle Management Repository
upgrading
in graphical mode, 11-1
Oracle Management Service
installing software-only
in graphical mode, 11-26
in silent mode, 11-40
stopping OMS instances, 5-8
stopping OMSes, 5-29
upgrading
in graphical mode, 11-1
in silent mode, 11-22
installing plug-ins, 3-9
Oracle Software Library, 3-10
backing up software library, 8-13
NFS-mounted drive accessible, 8-26
reconfigure software library, 8-19
using the library
1-system upgrade approach, 3-10
1-system upgrade approach on a different
host, 3-10
2-system upgrade approach, 3-10
Oracle Software Library Reconfigure Locations
page, 12-5
Oracle Web Tier, 2-17, 2-22
Oracle WebLogic domain, 2-18
Oracle WebLogic Server, 2-19, 2-21
default version installed, 2-17, 3-4
manual installation, 3-4, 3-5
typical installation, 3-5
oracle_common directory, 2-17, 2-19, 2-21
ORACLE_COMMON property, 3-5
Oracle_WT directory, 2-17, 2-19, 2-22
oraInst.loc file, 9-9
out-of-place upgrade, 3-3
P
pie charts, 9-4
ping, 10-12
ping test, 10-3, 10-12
plug-ins
downloading required plug-ins, 3-9, 9-6
identifying required plug-ins, 3-8
installed by default, 2-20, 2-22
installing, 3-7
installing while upgrading Management
Agent, 3-9
installing while upgrading OMS, 3-9
manual download, 5-13
manual installation, 5-14
selecting plug-ins, 11-17, 11-44
ports
default ports assigned, 3-6
HTTP upload ports, 9-2
HTTPs upload ports, 9-2
reusing existing ports, 3-6
secure, 9-2
unsecure, 9-2
Post Upgrade Reconfiguration, 12-5
post-config options, 10-7
post-upgrade activity, 12-25
postupgrade console, 2-15
postupgrade steps
disabling incident rule sets, 12-18
enabling linux patching, 12-19
general, 12-9
resolving metric collection errors, 12-19
stopping OCM scheduler, 12-11
postupgrade tasks, 12-9
power broker, 10-7
pre-deploy options, 10-7
preferred credentials, 10-6, F-1
default selection, 10-6
overriding preferred credentials, 10-6
registering
as default credentials, F-1
as preferred credentials, F-1
registering with EMCLI, 10-6
preupgrade console
applying patch, 8-2, 8-10, 8-21
private rulesets, B-2
problematic agents, 9-11
process
1-system upgrade approach, 8-1, 8-21
2-system upgrade approach, 8-9
processes
1-system upgrade, 2-16
1-system upgrade on a different host, 2-21
2-system upgrade, 2-19
R
readiness check, 10-10
reconfiguration Software Library validation
errors, 12-7
reconfiguring Oracle Software Library, 12-5
confirmation step, 12-7
validation step, 12-7
recovering database
destination host, J-3
Index-3
source host, J-1
registering, 9-4
repository backup details,
root.sh script, 10-9
9-13
S
secure ports, 9-2
securing the OMS, 2-20
server load balancer
updating configuration, E-1
server load balancers, 8-26
shared agents, 10-5
signing off accrued data migration jobs, 12-30
skipped jobs, 3-14
SOA targets, 10-11, 10-15
software library
See Oracle Software Library, 3-10
software location
validating, 9-4
stage location, 9-6
status pending state, 4-2, 5-3, 5-17, 5-22, 5-35
SUDO, 10-7
supported upgrade paths, 3-2
suspended on event, 10-9, 10-11
switch over operations, 2-17
switchover
generating health report, 10-9
signing off health report, 10-12
switching over, 10-15
verifying health report, 10-12
-system upgrade approach
using Oracle Software Library, 3-10
T
target types added, 12-14
targets
checking the upgradability status, 9-10
upgradable, 9-10
two-system upgrade
reconfiguring Oracle Software Library, 12-5
two-system reconfiguration, 12-6
U
unsecure upload ports, 9-2
upgrade
1-system upgrade in graphical mode, 11-2
1-system upgrade in silent mode, 11-23
1-system upgrade on a different host in graphical
mode, 11-44
2-system upgrade in graphical mode, 11-11
2-system upgrade in silent mode, 11-23
agent upgrade status, 12-7
installing software-only
1-system upgrade in graphical mode, 11-26
1-system upgrade in silent mode, 11-40
2-system upgrade in graphical mode, 11-32
2-system upgrade in silent mode, 11-41
Upgrade Agents page, 6-1
Index-4
Not Upgradable Agents, 6-11
upgrade approaches, 2-8
1-system upgrade approach, 2-8
1-system upgrade approach on a different
host, 2-8
1-system upgrade process on a different
host, 2-21
2-system upgrade approach, 2-8
2-system upgrade process, 2-19
differences, 2-9
overview, 2-8
upgrade options, 2-1
upgrade scope, 3-3
upgrade.rsp file, 5-19
Upgrading 12c Management Agents
additional parameters, 6-10
post upgrade tasks, 6-17
procedure, 6-6
upgrade job status and progress, 6-17
user accounts
SYS, 5-7, 11-5
SYSMAN, 5-7, 11-5
V
valid inventory, 9-8
W
with missing agents software, 9-9
with missing plug-ins, 9-9
WLS_DOMAIN_NAME option, 5-13
wls1036_generic.jar file, 3-4