9 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 5 (12.1.0.5)

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 5 (12.1.0.5) using different upgrade approaches. In particular, this chapter describes the following:

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 5 (12.1.0.5) with 1-System Upgrade Approach

Table 9-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 5 (12.1.0.5) with 1-system upgrade approach.

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

Step No. Step Procedure

Step 1

Prepare Yourself

  

(a)

Learn about the 1-System upgrade approach.

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)

Manually download the following software, and stage them to an accessible location:

  • Oracle Management Agent 12c

  • All the required plug-ins

Section 3.7.2.1

(c)

Provide information about the location of the software you manually downloaded and staged in Step 2 (b)

Section 10.4

(d)

Analyze your environment to identify Oracle Management Agents (Management Agent) with valid and invalid inventory, check their upgradability status, and identify the problematic Management Agents. If a required software is missing, then repeat Step (b) and Step (c).

Section 10.6

(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 11.1

(b)

Generate a health report and check the readiness of the predeployed Management Agents.

Section 11.2

(c)

Verify and sign off the health check report.

Section 11.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.

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.

Section 11.4

Step 4

Upgrade Oracle Management Service and Oracle Management Repository

  

(a)

Meet the following prerequisites:

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

  • Upgrade to 12c Release 5 (12.1.0.5) is an out-of-place upgrade, therefore make sure your host meets the hardware requirements specific to 12c Release 5 (12.1.0.5) 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.

  • If you want to upgrade your database, which houses the Management Repository, to 12c Release 1(12.1.0.2), then make sure you upgrade the database ONLY after you upgrade the Enterprise Manager system.

  • 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.3.

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

  

(b)

On the Management Repository, meet the following prerequisites:

  • Ensure that the MGMT_CONNECTOR_CONFIG table does not have any NULL rows. To verify this, run the following SQL query.

    select * from mgmt_cntr_config where connector_type_guid IS NULL and connector_guid IS null;

    Typically, the command must not return any rows. If it does return any rows, then run the following SQL query to clean the table:

    delete from mgmt_cntr_config where connector_guid IS NULL or connector_type_guid IS NULL;

    commit;

  • Ensure that there are no custom-created materialized views in the Management Repository. To verify this, run the following SQL query. Typically, the command must not return any rows. If it does return any rows, then contact Oracle Support.

    select count(1) from ALL_MVIEW_LOGS where log_owner=<EM_REPOS_USER>

  • Ensure that the tables do not have any snapshots created. To verify this, log in to the Management Repository and run the following SQL query as SYSMAN user:

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

    For example,

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

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

    SQL> master log_table

    em-violations em$violation_log

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

    SQL> Drop snapshot log on <master>

    For example,

    SQL> Drop snapshot log on em-violations

  

(c)

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

For Oracle Database 11g Release 2 (11.2.0.4) and 12c Release 1 (12.1.0.2)

No patches required for these releases.

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>

  

(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.8.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.8.0/sql/ias/12.1.0.3/camm_product/camm_schema_upgrade.sql

  

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

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

  

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

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,

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

For single-OMS environment, see:

For multi-OMS environment (with additional OMS instances), see Section 12.6

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 13.5

(c)

Perform the general post-upgrade tasks.

Section 13.6

(d)

Track the status of deferred data migration jobs.

Section 13.7

(e)

Sign off agent migration process.

Section 13.11

(f)

Sign off the upgrade process and exit the upgrade mode.

Section 13.12

(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:

    (a) Navigate to the following location:

    <middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.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.8.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 13.15

9.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 5 (12.1.0.5) with 2-System Upgrade Approach

Table 9-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 5 (12.1.0.5) with 2-system upgrade approach.

Table 9-2 Upgrading Enterprise Manager Grid Control with 2-System Upgrade Approach

Step No. Step Procedure

Step 1

Prepare Yourself

  

(a)

Learn about the 2-System upgrade approach.

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 10.2

(c)

Manually download the following software, and stage them to an accessible location:

  • Oracle Management Agent 12c

  • All the required plug-ins

Section 3.7.2.1

(d)

Provide information about the location of the software you manually downloaded and staged in Step 2 (c)

Section 10.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 10.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 5 (12.1.0.5) 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.3.

  • If you want to upgrade your database, which houses the Management Repository, to 12c Release 1(12.1.0.2), then make sure you upgrade the database ONLY after you upgrade the Enterprise Manager system.

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

  

(b)

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>

  

(c)

(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.8.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.8.0/sql/ias/12.1.0.3/camm_product/camm_schema_upgrade.sql

  

(d)

Copy the emkey from the existing OMS, either the Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), to the existing Management Repository before creating a backup of the Management Repository. To do so, run the following command on the old OMS home you are trying to upgrade. The following command is applicable for both releases.

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

Note: When the following command is run on Enterprise Manager 11g Grid Control (11.1.0.1), you will be prompted for an admin password.

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

<OMS_HOME>/bin/emctl status emkey

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

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

(e)

(Only if your old Enterprise Manager system has Oracle Software Library configured)

If you have Oracle Software Library (Software Library) configured, then back up each of the configured Software Library directories to a location accessible from the remote host where you plan to install Enterprise Manager Cloud Control.

The location to which you back up the directories is required for reconfiguring the Software Library [as described in Step 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.

  

(f)

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

  

(g)

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 from all_mview_logs where log_owner='SYSMAN'

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

    SQL> master log_table

    em-violations em$violation_log

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

    SQL> Drop snapshot log on <master>

    For example,

    SQL> Drop snapshot log on em-violations

  

(h)

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

For Oracle Database 11g Release 2 (11.2.0.4) and 12c Release 1 (12.1.0.2)

No patches required for these releases.

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>]

  

(k)

Provide the date and time when the Management Repository was cloned (or backed up).

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

Section 10.7

(l)

If you have a Server Load Balancer (SLB) configured, then configure the settings of your monitors and keep the SLB ready.

Appendix E

(m)

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.

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 Preupgrade 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)(PORT=1521)))(CONNECT_DATA=(SID=emrepos12)))"' -repos_user sysman -emkey_file /u01/software/oracle/middleware/oms11g/sysman/config/emkey.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.

(Note: If you had chosen to deploy your Management Agents before upgrading the OMS, and if you see this error, then after running the previous command, make sure you deploy all the Management Agents again. However, after running the command, and before re-deploying the Management Agents, Oracle recommends that you run the installer to ensure that the error about emkey does not reoccur.)

For single-OMS environment, see:

For multi-OMS environment (with additional OMS instances), see Section 12.6

(n)

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

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.

Appendix L

(o)

Link the earlier release of the Management Repository with the upgraded Management Repository.

Section 13.2

Step 4

Upgrade Oracle Management Agent

  

(a)

Deploy and configure the software binaries of Oracle Management Agent 12c.

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

Section 11.1

(b)

Generate a health report and check the readiness of the predeployed Management Agents.

Section 11.2

(c)

Verify and sign off the health check report.

Section 11.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.

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.

Section 11.4

Step 5

Perform Postupgrade Task

  

(a)

Verify the host on which you installed Enterprise Manager Cloud Control.

Section 13.1

(b)

(Only if your old Enterprise Manager had Software Library configured)

Reconfigure the Software Library in Enterprise Manager Cloud Control so that it is independent of the Software Library configured for the old Enterprise Manager system.

Section 13.4

(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 13.5

(e)

Perform the general post-upgrade tasks.

Section 13.6

(f)

Track the status of deferred data migration jobs.

Section 13.7

(g)

Track the status of accrued data migration jobs.

Section 13.8

(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 13.9

(i)

View a list of targets that are currently inactive in the upgraded Enterprise Manager system.

Section 13.10

(j)

Sign off agent migration process.

Section 13.11

(k)

Sign off the upgrade process and exit the upgrade mode.

Section 13.12

(l)

Delete unwanted central agents.

Section 13.13.1

(m)

(Optional) Monitor the targets that were monitored by the deleted central agent.

Section 13.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.8.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.8.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 13.15

9.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.5) with 1-System Upgrade Approach on a Different Host

Table 9-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 5 (12.1.0.5) with 1-system upgrade approach on a different host.

Table 9-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.

Section 2.2.3.1

(b)

Provide information about the host where you plan to upgrade your existing OMS.

Section 10.2

(c)

Manually download the following software, and stage them to an accessible location:

  • Oracle Management Agent 12c

  • All the required plug-ins

Section 3.7.2.1

(d)

Provide information about the location of the software you manually downloaded and staged in Step 2 (c).

Section 10.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 10.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.

Section 11.1

(b)

Generate a health report and check the readiness of the predeployed Management Agents.

Section 11.2

(c)

Verify and sign off the health check report.

Section 11.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.

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.

Section 11.4

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 5 (12.1.0.5) 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.

  • If you want to upgrade your database, which houses the Management Repository, to 12c Release 1(12.1.0.2), then make sure you upgrade the database ONLY after you upgrade the Enterprise Manager system.

  • Ensure that you are upgrading only on the supported platforms as listed in Section 3.3.

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

  

(b)

On the Management Repository, meet the following prerequisites:

  • Ensure that the MGMT_CONNECTOR_CONFIG table does not have any NULL rows. To verify this, run the following SQL query.

    select * from mgmt_cntr_config where connector_type_guid IS NULL and connector_guid IS null;

    Typically, the command must not return any rows. If it does return any rows, then run the following SQL query to clean the table:

    delete from mgmt_cntr_config where connector_guid IS NULL or connector_type_guid IS NULL;

    commit;

  • Ensure that there are no custom-created materialized views in the Management Repository. To verify this, run the following SQL query. Typically, the command must not return any rows. If it does return any rows, then contact Oracle Support.

    select count(1) from ALL_MVIEW_LOGS where log_owner=<EM_REPOS_USER>

  • Ensure that the tables do not have any snapshots created. To verify this, log in to the Management Repository and run the following SQL query as SYSMAN user:

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

    For example,

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

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

    SQL> master log_table

    em-violations em$violation_log

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

    SQL> Drop snapshot log on <master>

    For example,

    SQL> Drop snapshot log on em-violations

  

(c)

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

For Oracle Database 11g Release 2 (11.2.0.4) and 12c Release 1 (12.1.0.2)

No patches required for these releases.

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>

  

(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.8.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.8.0/sql/ias/12.1.0.3/camm_product/camm_schema_upgrade.sql

  

(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 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 the settings of your monitors and keep the SLB ready.

Appendix E

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

Section 12.5

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 13.5

(c)

Perform the general post-upgrade tasks.

Section 13.6

(d)

Track the status of deferred data migration jobs.

Section 13.7

(e)

Sign off agent migration process.

Section 13.11

(f)

Sign off the upgrade process and exit the upgrade mode

Section 13.12

(g)

Deleted unwanted central agents.

Section 13.13.1

(h)

(Optional) Monitor the targets that were monitored by the deleted central agent.

Section 13.14

(i)

(Only if you have Application Dependency and Performance (ADP) or JVM Diagnostics (JVMD) installed)

  1. If you have not deinstalled the JVMD and ADP applications from your inventory by logging into the WebLogic Administration Console for each monitored domain and removing the jamagent and Acsera application deployments, then do so now.

  2. Delete all ad4jTarget targets:

    (a) Navigate to the following location:

    <middleware_home>/plugins/oracle.sysman.emas.oms.plugin_12.1.0.8.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.8.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 13.15