Skip Headers
Oracle® Enterprise Manager Cloud Control Upgrade Guide
12c Release 2 (12.1.0.2)
Part Number E22625-11
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Feedback page
Contact Us
Go to previous page
Previous		 Go to next page
Next
PDF · Mobi · ePub

2 Things to Know

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

Supported Upgrade Paths

The following upgrade paths are supported:

Table 2-1 Supported Upgrade Paths

From To

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

12c Release 2 (12.1.0.2)

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

12c Release 2 (12.1.0.2)

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

12c Release 2 (12.1.0.2)

11g Release 1 (11.1.0.1)

12c Release 2 (12.1.0.2)

10g Release 5 (10.2.0.5)

12c Release 2 (12.1.0.2)

10g Release 4 (10.2.0.4) or lower

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

10g Release 1 (10.1)

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

Supported Upgrade Approaches

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

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

Supported Platforms for Upgrade

The following platforms are supported:

Upgrade Scope

The following are some facts about the upgrade approaches:

Reusing Existing Ports

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

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

Note:

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

Upgrading Plug-Ins

This section describes the following:

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

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

In particular, this section describes the following:

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

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

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

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

  • Plug-ins are upgraded when newer versions exist

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

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

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

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

  • Manually download the plug-ins from the Enterprise Manager download page on Oracle Technology Network (OTN), and store them in an accessible location:

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

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

    For UNIX Platforms:

    ./runInstaller -pluginLocation <absolute_path_to_plugin_software_location>

    For Microsoft Windows Platforms:

    setup.exe -pluginLocation <absolute_path_to_plugin_software_location>

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

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

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

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

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

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

  1. Access the following URL:

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

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

  3. Download all the required plug-ins to the same location. Plug-ins are generic, so they are common for all platforms.

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

    Note:

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

    Note:

    To identify what plug-ins are required, in the Preupgrade Console, in the Preupgrade Steps section, from the table, click Manage Software. On the Manage Software page, in the Plug-In Software section, see the required plug-ins.

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

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

See:

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

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

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

Note:

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

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

Using Oracle Software Library

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

Using Connectors

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

Updating PDP Configuration File

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

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

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

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

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

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

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

Note:

This section is applicable only for upgrade from Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) or Enterprise Manager 11g Grid Control Release 1 (11.1.0.1).

You can ignore this section if you are upgrading from Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1).

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

In particular, this section describes the following:

Managing Notification

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

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

Managing Alerts

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

This section covers the following:

Migrating Alerts

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

  • All open alerts are migrated.

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

  • All alerts that were closed 180 days prior to upgrading or backing up the Management Repository are migrated as part of the Deferred Data Migration Process. This period of 180 days can be changed by the administrator.

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

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

Note:

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

Creating Incidents and Events for Different Types of Open Alerts

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

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

Open Alert Type Incident Created Event Created

Critical Alert

Yes

Yes

Warning Alert

No

Yes

Critical Alert with Ticket

Yes

Yes (with Ticket)

Warning Alert with Ticket

Yes

Yes (with Ticket)

Warning Alert with Notification Pending

Yes

Yes

Warning Alert without Notification Pending

No

Yes

Critical Alert with Acknowledgement

Yes

Yes

Warning Alert with Acknowledgement

Yes

Yes

Creating Incidents and Events for Different Types of Closed Alerts

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

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

Closed Alert Type Incident Created Event Created

Critical Alert

No

Yes

Warning Alert

No

Yes

Critical Alert with Ticket

No

Yes (without Ticket)

Warning Alert with Ticket

No

Yes (without Ticket)

Warning Alert with Notification Pending

No

Yes

Warning Alert without Notification Pending

No

Yes

Critical Alert with Acknowledgement

No

Yes

Warning Alert with Acknowledgement

No

Yes

Managing Jobs

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

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

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

  • A job running in the old Enterprise Manager system at the time of the backup either aborts or fails in Enterprise Manager Cloud Control. Once the Management Agent is migrated, a future job appears as a suspended job on the Management Agent unavailable in the old Enterprise Manager system, but appears as a scheduled job in Enterprise Manager Cloud Control. If the Management Agent is subsequently removed from the old Enterprise Manager system, then that job is removed as well.

    If the backup of the old Enterprise Manager system did not require a downtime, then the jobs running at the time of the backup continue to run. (If the backup required a downtime, then the job may abort due to the downtime.) Such jobs appear as aborted, failed, or skipped jobs in Enterprise Manager Cloud Control.

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

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

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

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

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

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

    • Jobs can be created in Enterprise Manager Cloud Control before the Management Agent for its target is migrated, but they will be in suspended mode on Management Agent unavailable until the Management Agent is migrated.

      This is particularly useful when a new job is created in the old Enterprise Manager system and a copy of it is desired in Enterprise Manager Cloud Control for use after the target is migrated. Usually, this will be a repeating job.

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

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

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

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

  • For jobs with multiple executions, one job per target, some targets may be suspended, while others run.

    Consider a job against two databases, dbA monitored by Management Agent A, and dB monitored by Management Agent B. If only Management Agent B is migrated, then the execution for dbA is suspended, while the execution for dB runs when it reaches its scheduled time. If this is a repeating job, then the execution for dbA is skipped. Once the Management Agent A is migrated, then both executions are run as usual.

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

  • For jobs on multiple targets, one job for many targets, the jobs can neither run in the old Enterprise Manager system nor in Enterprise Manager Cloud Control unless the Management Agents for all the targets are migrated at one time. To determine the correct set of Management Agents to migrate at one time to address this, run the SQL queries described in Appendix D.

    The alternative is to migrate the Management Agents independently, and then, once the last Management Agent is migrated, the job may run if the grace period allows it to run or if the scheduled time was after the last agent migration.

Managing Deployment Procedure Runs

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

get_instance_data_xml

Collecting Metrics

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

  • Oracle SOA Infrastructure

  • Oracle SOA Composite

  • Oracle Service Bus

  • Oracle WebLogic Server

  • JBoss Application Server

  • Siebel Enterprise

  • Siebel Server

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

Upgrading EM CLI Clients

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

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

Upgrading Oracle Exadata Targets

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

Go to previous page
Previous		 Go to next page
Next
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Feedback page
Contact Us