7 Getting Started

Step 1

Prepare Yourself

(a)

Learn about the 1-System upgrade approach.

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

(b)

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

Chapter 2

Step 2

Perform Preupgrade Tasks

(a)

Apply the preupgrade console patch on all your OMS instance to get access to the Preupgrade Console.

Preupgrade Console

(b)

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

• Oracle Management Agent 12c

• All the required plug-ins

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

(c)

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

Managing Software

(d)

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

Analyzing Your Environment

(e)

Meet the prerequisites for upgrading the Management Agents.

Appendix E

Step 3

Upgrade Oracle Management Agent

(a)

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

Deploying and Configuring Oracle Management Agent

(b)

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

Generating Health Report of Deployed Oracle Management Agents

(c)

Verify and sign off the health check report.

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

(d)

Switch over the old Management Agents to the newly deployed ones so that they can communicate with Enterprise Manager Cloud Control.

Note: If you have a large number of agents, then you can choose to upgrade one set of Oracle Management Agents in one attempt, and the next set in the subsequent attempt. In this case, you can repeat Step 3 (a) to Step 3 (d) for each attempt.

Switching Over to Oracle Management Agent 12c

(e)

If you have a Server Load Balancer (SLB) configured, then modify the settings of your monitors.

Appendix F

Step 4

Upgrade Oracle Management Service and Oracle Management Repository

(a)

Meet the following prerequisites:

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

• Meet the Management Agent-related prerequisites described in Appendix E.

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

• Back up the OMS, the Management Repository, and the Software Library. In case the upgrade fails, you can always restore using the backup.

  For instructions to back up, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

(b)

On the Management Repository, meet the following prerequisites:

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

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

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

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

  commit;

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

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

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

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

  For example,

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

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

  SQL> master log_table

  em-violations em$violation_log

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

  SQL> Drop snapshot log on <master>

  For example,

  SQL> Drop snapshot log on em-violations

(c)

Stop all running and scheduled deployment procedures in your existing Enterprise Manager system before upgrading the system.

(d)

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

1. Take an inventory of the JVMs and WebLogic Domains being monitored by JVMD and/or ADP.

2. Deinstall the JVMD and ADP applications from your inventory by logging into the WebLogic Administration Console for each monitored domain and removing the jamagent and Acsera application deployments.

3. Shut down all of your ADP and JVMD managers.

4. Remove all ADP and JVMD managed servers from the GCDomain using the WebLogic Administration Console.

5. Run purge scripts for JVMD:

   (a) Navigate to the following location:

   <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

   (b) Extract the file jvmd.zip.

   (c) Run the script jvmd_monitoringupgrade11_12.sql.

   (d) Run the script jvmd_traceupgrade11_12.sql if there are existing Thread Snapshots from Enterprise Manager 11g Grid Control Release 1 (11.l.0.1).

(e)

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

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

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

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

<OMS_HOME>/bin/emctl status emkey

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

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

(f)

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

• If you are upgrading in graphical mode, then you can stop the OMS later as described in Step (12) of Upgrading with 1-System Upgrade Approach in Graphical Mode.

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

• If you are upgrading in silent mode, then stop the OMS now:

  • If you are upgrading from Enterprise Manager 11g Grid Control Release 1 (11.1.0.1), then first run this command on the first OMS you are upgrading. This command stops only the OMS, and not the Admin Server or any of its associated components. The Admin Server and other associated components must be running so that the WebLogic Server credentials can be validated.

    $<OMS_HOME>/bin/emctl stop oms

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

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

  • If you are upgrading from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then run this command from the OMS home:

    $<OMS_HOME>/opmn/bin/opmnctl stopall

(g)

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

(h)

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

If you see an error message stating that you have not copied the emkey, then do the following:

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

   For 11g Release 1 (11.1.0.1)

   $<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc <conndesc> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

   For 10g Release 5 (10.2.0.5)

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

   Note: Here, the Management Repository details are the details of the existing Management Repository you are trying to upgrade. <OMS_HOME> is the OMS home you are trying to upgrade. When you upgrade from 11.1.0.1, you will be prompted for the Admin Server password.

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

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

Step 5

Perform Postupgrade Task

(a)

Perform the general post-upgrade tasks.

Performing General Postupgrade Tasks

(b)

Track the status of deferred data migration jobs.

Tracking the Status of Deferred Data Migration Jobs

(c)

Sign off agent migration process.

Signing Off Agent Migration Process

(d)

Update the incident rules for metrics associated with the OMS.

Updating Incident Rules

(e)

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

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

2. Delete all ad4jTarget targets:

   (a) Navigate to the following location:

   <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

   (b) Extract the file jvmd.zip.

   (c) Run the script jvmd_targetupgrade11_12.sql.

3. Delete all OCAMM Manager targets:

   (a) Navigate to the following location:

   <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/ocamm/

   (b) Extract the file ADPManager.zip.

   (c) Run the script adp_targetupgrade11_12.sql.

4. Deploy new JVMD and ADP managers.

5. Deploy new JVMD and ADP agents based on your inventory.

Step 1

Prepare Yourself

(a)

Learn about the 2-System upgrade approach.

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

(b)

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

Chapter 2

Step 2

Perform Preupgrade Tasks

(a)

Apply the preupgrade console patch on all your OMS instances to get access to the Preupgrade Console.

Preupgrade Console

(b)

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

Identifying Host for Enterprise Manager Cloud Control

(c)

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

• Oracle Management Agent 12c

• All the required plug-ins

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

(d)

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

Managing Software

(e)

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

Analyzing Your Environment

(f)

Meet the prerequisites for upgrading the Management Agents.

Appendix E

Step 3

Upgrade Oracle Management Service and Oracle Management Repository

Note: Optionally, you can choose to deploy and configure your Oracle Management Agents before upgrading the Oracle Management Service and Oracle Management Repository. In this case, perform Step 4 (a) before Step 3 (a) to Step 3 (l).

(a)

On the remote host where you plan to install Enterprise Manager Cloud Control, meet the following prerequisites:

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

• Meet the Management Agent-related prerequisites described in Appendix E.

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

(b)

Stop all running and scheduled deployment procedures in your existing Enterprise Manager system before upgrading the system.

(c)

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

1. Take an inventory of the JVMs and WebLogic Domains being monitored by JVMD and/or ADP.

2. Deinstall the JVMD and ADP applications from your inventory by logging into the WebLogic Administration Console for each monitored domain and removing the jamagent and Acsera application deployments.

3. Shut down all of your ADP and JVMD managers.

4. Remove all ADP and JVMD managed servers from the GCDomain using the WebLogic Administration Console.

5. Run purge scripts for JVMD:

   (a) Navigate to the following location:

   <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

   (b) Extract the file jvmd.zip.

   (c) Run the script jvmd_monitoringupgrade11_12.sql.

   (d) Run the script jvmd_traceupgrade11_12.sql if there are existing Thread Snapshots from Enterprise Manager 11g Grid Control Release 1 (11.l.0.1) .

(d)

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

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

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

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

<OMS_HOME>/bin/emctl status emkey

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

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

(e)

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

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

The location to which you back up the directories is required for reconfiguring the Software Library [as described in Step 3 (l)] once you install Enterprise Manager Cloud Control.

For example, if your Software Library was configured in /programs/swlib and /software/swlib, then create two separate archives, one for each configured directory. In this case, create programs_swlib.zip and software_swlib.zip, respectively.

(f)

Back up your existing database, which houses the Management Repository, using the RMAN utility, to a host that can be either a completely new host or the host where your existing OMS is running.

Choose to back up the repository on the host where your existing OMS is running only if you have sufficient space to accommodate it.

Then, create a new database instance out of it so that the repository configured in it can be upgraded.

Note:

- Before backing up the database, ensure that you stop all the running and scheduled deployment procedures in your existing Enterprise Manager system.

- Oracle recommends using the RMAN utility to back up the database.

- If you back up the database using DBCA, then ensure that you unlock all the user accounts, except for MGMT_VIEW user, before installing Enterprise Manager Cloud Control.

- Do not back up the repository using the DB cloning feature in the Enterprise Manager console. If you do, then you will not see the cloned database discovered in the Enterprise Manager console.

- Do not backup while you are in the daylight saving window.

- Any Management Agent or target added to the existing Enterprise Manager system after backing up the Management Repository will not be upgraded and will need to be manually added to the upgraded Enterprise Manager system. To identify the targets that need to be manually added to the upgraded system, see the diff report as described in . Generating and Viewing Diff Reports.

(g)

On the backed up Management Repository, meet the following prerequisites:

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

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

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

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

  commit;

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

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

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

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

  For example,

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

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

  SQL> master log_table

  em-violations em$violation_log

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

  SQL> Drop snapshot log on <master>

  For example,

  SQL> Drop snapshot log on em-violations

(h)

Ensure that the character set in the backed up Management Repository is the same as the one in the original Management Repository.

If they are different, you will see the following error:

ERROR emschema.wpxegn6m8wkg - ERROR:ORA-06502: PL/SQL: numeric or value error: character to number conversion error
ORA-06512: at "SYSMAN.EM_CRYPTO", line 62
ORA-06512: at "SYSMAN.EM_CRYPTO", line 229
ORA-06512: at line 1
ORA-06512: at line 24

To verify if the character set is the same, run the following query on the Management Repository:

select * from nls_database_parameters where parameter like '%CHARACTERSET'

If the character set is not the same, then make them identical.

(i)

Remove the emkey from the old Management Repository by running the following command from the old OMS home, either Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1):

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

(j)

Provide the date and time when the Management Repository was backed up.

Note: Any Management Agent or target added to the existing Enterprise Manager system after backing up the Management Repository will not be upgraded and will need to be manually added to the upgraded Enterprise Manager system. To identify the targets that need to be manually added to the upgraded system, see the diff report as described in . Generating and Viewing Diff Reports.

Providing Repository Backup Details

(k)

Install Enterprise Manager Cloud Control on the remote host and upgrade the Management Repository in the database you backed up in Step 3 (f). You can choose to install in graphical or silent mode. You can also choose to install the software binaries at one point and upgrade them later in graphical or silent mode.

If you see an error message that states that you cannot upgrade your OMS because the host on which you are performing the 2-system upgrade does not match with the host name you have entered in the Preupgrade Console, go to the Prepgrade Console and provide the correct host name.

(Note: If you had chosen to deploy your Management Agents before upgrading the OMS, and if you see this error, fix the error in the Preupgrade Console, and then dploy your Management Agents again, before upgrading the OMS.)

If you see an error message stating that you have not copied the emkey, then do the following:

For 11g Release 1 (11.1.0.1)

1. Copy the emkey from the old OMS to the cloned Management Repository, the one you backed up in Step 3 (f). To do so, run the following command from the old OMS home you are trying to upgrade:

   $<OMS_HOME>/bin/emctl config emkey -copy_to_repos_from_file -repos_conndesc <conndesc> -repos_user <username> [-repos_pwd <pwd>] -emkey_file <OMS_HOME>/sysman/config/emkey.ora

   Note: Here, the Management Repository details are the details of the cloned Management Repository, the one you backed up in Step 3 (f). <OMS_HOME> is the OMS home you are trying to upgrade. You will be prompted for the Admin Server password.

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

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

For 10g Release 5 (10.2.0.5)

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

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

2. Back up the Management Repository as described in Step 3 (f).

3. Meet the prerequisites on the backed up Management Repository as described in Step 3 (g).

4. Remove the emkey from the old Management Repository as described in Step 3 (i).

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

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

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

(l)

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

Creating Link to Upgraded Oracle Management Repository

(m)

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

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

Reconfiguring Oracle Software Library

Step 4

Upgrade Oracle Management Agent

(a)

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

Deploying and Configuring Oracle Management Agent

(b)

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

Generating Health Report of Deployed Oracle Management Agents

(c)

Verify and sign off the health check report.

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

(d)

Switch over the old Management Agents to the newly deployed ones so that they can communicate with Enterprise Manager Cloud Control.

Note: If you have a large number of agents, then you can choose to upgrade one set of Oracle Management Agents in one attempt, and the next set in the subsequent attempt. In this case, you can repeat Step 4 (a) to Step 4 (d) for each attempt.

Switching Over to Oracle Management Agent 12c

Step 5

Perform Postupgrade Task

(a)

Check the agent upgrade status

Checking Agent Upgrade Status

(b)

Perform the general post-upgrade tasks.

Performing General Postupgrade Tasks

(c)

Track the status of deferred data migration jobs.

Tracking the Status of Deferred Data Migration Jobs

(d)

Track the status of accrued data migration jobs.

Tracking the Status of Accrued Data Migration Jobs

(e)

Generate diff reports to identify all configuration or setup-related changes that were manually made to the earlier release of the Enterprise Manager system while it was being upgraded.

Generating and Viewing Diff Reports

(f)

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

Viewing Inactive Targets in the Upgraded Enterprise Manager System

(g)

Sign off agent migration process.

Signing Off Agent Migration Process

(h)

Update the incident rules for metrics associated with the OMS.

Updating Incident Rules

(i)

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

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

2. Delete all ad4jTarget targets:

   (a) Navigate to the following location:

   <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

   (b) Extract the file jvmd.zip.

   (c) Run the script jvmd_targetupgrade11_12.sql.

3. Delete all OCAMM Manager targets:

   (a) Navigate to the following location:

   <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/ocamm/

   (b) Extract the file ADPManager.zip.

   (c) Run the script adp_targetupgrade11_12.sql.

4. Deploy new JVMD and ADP managers.

5. Deploy new JVMD and ADP agents based on your inventory.

Step 1

Prepare Yourself

(a)

Learn about the 1-System upgrade approach on a different host.

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

(b)

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

Chapter 2

Step 2

Perform Preupgrade Tasks

(a)

Apply the preupgrade console patch on all your OMS instances to get access to the Preupgrade Console.

Preupgrade Console

(b)

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

Identifying Host for Enterprise Manager Cloud Control

(c)

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

• Oracle Management Agent 12c

• All the required plug-ins

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

(d)

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

Managing Software

(e)

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

Analyzing Your Environment

(f)

Meet the prerequisites for upgrading the Management Agents.

Appendix E

Step 3

Upgrade Oracle Management Agent

(a)

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

Deploying and Configuring Oracle Management Agent

(b)

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

Generating Health Report of Deployed Oracle Management Agents

(c)

Verify and sign off the health check report.

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

(d)

Switch over the old Management Agents to the newly deployed ones so that they can communicate with Enterprise Manager Cloud Control.

Note: If you have a large number of agents, then you can choose to upgrade one set of Oracle Management Agents in one attempt, and the next set in the subsequent attempt. In this case, you can repeat Step 3 (a) to Step 3 (d) for each attempt.

Switching Over to Oracle Management Agent 12c

Step 4

Upgrade Oracle Management Service and Oracle Management Repository

(a)

On the remote host where you plan to install Enterprise Manager Cloud Control, meet the following prerequisites:

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

• Meet the Management Agent-related prerequisites described in Appendix E.

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

• Back up the OMS, the Management Repository, and the Software Library. In case the upgrade fails, you can always restore using the backup.

  For instructions to back up, refer to Oracle Enterprise Manager Cloud Control Administrator's Guide.

• Oracle recommends that you identify the deployment size (small, medium, or large) of your Enterprise Manager system, and fine-tune the database parameters as required for your deployment size. For instructions to identify the deployment size and set these database parameters, refer to the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

  While upgrading the OMS and the Management Repository using the Enterprise Manager Installation Wizard, the EM Prerequisite Kit is run automatically to verify if the database parameters are set as required for your deployment size. If they are not set to the desired values, then the EM Prerequisite Kit displays a warning against such prerequisite checks. There is a possibility that you might not notice these warnings, or you might notice them but choose to ignore them for a reason—this will increase the upgrade time exponentially. Therefore, Oracle recommends that you set these database parameters as required for your deployment size beforehand.

(b)

On the Management Repository, meet the following prerequisites:

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

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

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

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

  commit;

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

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

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

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

  For example,

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

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

  SQL> master log_table

  em-violations em$violation_log

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

  SQL> Drop snapshot log on <master>

  For example,

  SQL> Drop snapshot log on em-violations

(c)

Stop all running and scheduled deployment procedures in your existing Enterprise Manager system before upgrading the system.

(d)

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

1. Take an inventory of the JVMs and WebLogic Domains being monitored by JVMD and/or ADP.

2. Deinstall the JVMD and ADP applications from your inventory by logging into the WebLogic Administration Console for each monitored domain and removing the jamagent and Acsera application deployments.

3. Shut down all of your ADP and JVMD managers.

4. Remove all ADP and JVMD managed servers from the GCDomain using the WebLogic Administration Console.

5. Run purge scripts for JVMD:

   (a) Navigate to the following location:

   <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

   (b) Extract the file jvmd.zip.

   (c) Run the script jvmd_monitoringupgrade11_12.sql.

   (d) Run the script jvmd_traceupgrade11_12.sql if there are existing Thread Snapshots from Enterprise Manager 11g Grid Control Release 1 (11.l.0.1).

(e)

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

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

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

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

<OMS_HOME>/bin/emctl status emkey

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

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

(f)

If you have a Server Load Balancer (SLB) configured, then make changes to your monitors.

Appendix F

(g)

If your old Enterprise Manager has Oracle Software Library (Software Library) configured on a shared, NFS-mounted drive, then ensure that the shared drive is accessible from the remote host where you plan to install Enterprise Manager Cloud Control.

However, if the Software Library is configured on the local system where the existing, earlier release of Enterprise Manager is running, then copy the Software Library to the remote host where you plan to install Enterprise Manager Cloud Control, in the same directory path as the one maintained in the old Enterprise Manager system.

(h)

Install Enterprise Manager Cloud Control on the remote host and upgrade the Management Repository in the existing database.

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

Step 5

Perform Postupgrade Task

(a)

Check the agent upgrade status.

Checking Agent Upgrade Status

(b)

Perform the general post-upgrade tasks.

Performing General Postupgrade Tasks

(c)

Track the status of deferred data migration jobs.

Tracking the Status of Deferred Data Migration Jobs

(d)

Sign off agent migration process.

Signing Off Agent Migration Process

(e)

Update the incident rules for metrics associated with the OMS.

Updating Incident Rules

(f)

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

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

2. Delete all ad4jTarget targets:

   (a) Navigate to the following location:

   <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/jvmd/

   (b) Extract the file jvmd.zip.

   (c) Run the script jvmd_targetupgrade11_12.sql.

3. Delete all OCAMM Manager targets:

   (a) Navigate to the following location:

   <middleware_home>/plugins/oracle.sysman.emas.oms.plugin__12.1.0.3.0/archives/ocamm/

   (b) Extract the file ADPManager.zip.

   (c) Run the script adp_targetupgrade11_12.sql.

4. Deploy new JVMD and ADP managers.

5. Deploy new JVMD and ADP agents based on your inventory.